Shop OBEX P1 Docs P2 Docs Learn Events
Spin2 Operator Syntax - Page 7 — Parallax Forums

Spin2 Operator Syntax

145791018

Comments

  • cgracey wrote:
    >>, SAR		x >> y		x >>= y		binary		3, 16	Shift right, preserve sign
    <<, SHL		x << y		x <<= y		binary		3, 16	Shift left
    SHR		x SHR y		x SHR= y	binary		3, 16	Shift right, MSB's = 0
    
    Seriously, Chip? >> for SAR instead of SHR is not only non-complementary to << but runs against all convention. Please reconsider!

    -Phil
  • jmg, you need to write a compiler and see just how much of a pain all these context based things you are suggesting really are...
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-04-12 23:13
    jmg wrote:
    Can AND OR XOR NOT be made to apply to both Boolean and Bitwise ?
    Should be possible to know if you have boolean as in ...
    Absolutely not! Having the compiler infer the semantics from an otherwise ambiguous syntax is always a recipe for disaster.

    -Phil
  • jmgjmg Posts: 15,140
    Roy Eltham wrote: »
    jmg, I don't like that idea at all. I think they should be boolean only.
    What is the technical or usage problem you see ? - 'like' is too vague ?

  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2017-04-12 23:28
    Phil,
    >> is SAR and << is SHL in many other languages for signed numbers. For example, in C/C++, which I know you hate, but it's what most of the other copy.
    So it doesn't run against all convention...
  • cgracey wrote: »
    Okay. I feel good about this set, now. It's not entirely in agreement with anything else, but it makes the most sense to me. I want to know what you guys think:
    Operator	Term Usage	Assign Usage	Type		Prior	Description
    -------------------------------------------------------------------------------------------------------------------------
    ++ (pre)	++x		++x		var prefix	1	Pre-increment
    -- (pre)	--x		--x		var prefix	1	Pre-decrement
    ?? (pre)	??x		??x		var prefix	1	PRNG reverse (var must be long)
    
    ++ (post)	x++		x++		var postfix	1	Post-increment
    -- (post)	x--		x--		var postfix	1	Post-decrement
    ?? (post)	x??		x??		var postfix	1	PRNG forward (var must be long)
    !! (post)	x!!		x!!		var postfix	1	Post-boolean NOT
    !  (post)	x!		x!		var postfix	1	Post-bitwise NOT
    \  (post)	x\y		x\y		var postfix	1	Post-set to y
    
    !		!x		!= x		unary		2	Bitwise NOT, 1's complement
    -		-x		-= x		unary		2	Negation, 2's complement
    ABS		ABS x		ABS= x		unary		2	Absolute value
    NCOD		NCOD x		NCOD= x		unary		2	Encode MSB, 31..0
    DCOD		DCOD x		DCOD= x		unary		2	Decode, 1<<(x & $1F)
    SQRT		SQRT x		SQRT= x		unary		2	Square root
    LOG2		LOG2 x		LOG2= x		unary		2	Unsigned to logarithm-base2
    EXP2		EXP2 x		EXP2= x		unary		2	Logarithm-base2 to unsigned
    
    >>, SAR		x >> y		x >>= y		binary		3, 16	Shift right, preserve sign
    <<, SHL		x << y		x <<= y		binary		3, 16	Shift left
    SHR		x SHR y		x SHR= y	binary		3, 16	Shift right, MSB's = 0
    ROR		x ROR y		x ROR= y	binary		3, 16	Rotate right
    ROL		x ROL y		x ROL= y	binary		3, 16	Rotate left
    REV		x REV y		x REV= y	binary		3, 16	Reverse y LSBs of x and zero-extend
    SIGNX		x SIGNX y	x SIGNX= y	binary		3, 16	Sign-extend from bit y
    
    &		x & y		x &= y		binary		4, 16	Bitwise AND
    ^		x ^ y		x ^= y		binary		5, 16	Bitwise XOR
    |		x | y		x |= y		binary		6, 16	Bitwise OR
    
    *		x * y		x *= y		binary		7, 16	Multiply
    /		x / y		x /= y		binary		7, 16	Divide, return quotient
    MOD		x MOD y		x MOD= y	binary		7, 16	Divide, return remainder
    SCAL		x SCAL y	x SCAL= y	binary		7, 16	Scale, unsigned (x * y) >> 32
    FRAC		x FRAC y	x FRAC= y	binary		7, 16	Fraction, unsigned {x, 32'b0}/y
    
    +		x + y		x += y		binary		8, 16	Add
    -		x - y		x -= y		binary		8, 16	Subtract
    
    #>		x #> y		x #>= y		binary		9, 16	Ensure x => y
    <#		x <# y		x <#= y		binary		9, 16	Ensure x <= y
    
    <		x < y		n/a		equality	10	Check less than			(returns 0 or -1)
    <=		x <= y		n/a		equality	10	Check less than or equal	(returns 0 or -1)
    ==		x == y		n/a		equality	10	Check equal			(returns 0 or -1)
    <>		x <> y		n/a		equality	10	Check not equal			(returns 0 or -1)
    >=		x >= y		n/a		equality	10	Check greater than or equal	(returns 0 or -1)
    >		x > y		n/a		equality	10	Check greater than		(returns 0 or -1)
    
    !!, NOT		!!x		!!= x		unary		11	Boolean NOT  (x == 0,            returns 0 or -1)
    &&, AND		x && y		x &&= y		binary		12	Boolean AND  (x <> 0 AND y <> 0, returns 0 or -1)
    ^^, XOR		x ^^ y		x ^^= y		binary		13	Boolean XOR  (x <> 0 XOR y <> 0, returns 0 or -1)
    ||, OR		x || y		x ||= y		binary		14	Boolean OR   (x <> 0 OR  y <> 0, returns 0 or -1)
    
    ? :		x ? y : z	n/a		ternary		15	Choose between y and z
    
    :=		x := y		x := y		assign		16	Set x to y
    
    Looks good.

  • jmg wrote:
    What is the technical or usage problem you see ?
    I've often written: x := a AND b, when I want x to return TRUE if a and b are both non-zero, FALSE otherwise. Nuff said, jmg?

    -Phil
  • Roy Eltham wrote:
    >> is SAR and << is SHL in many other languages for signed numbers. For example, in C/C++, which I know you hate, but it's what most of the other copy.
    In a typical microcontroller app, where most shifts are binary instead of arithmetic, I think it's justifiable to give that task to >>, rather than relegate it to SHR. Anyway, I never saw anything wrong with ~> for SAR (except that I would've used -> or ->> instead, since it has a minus sign as part of the operator).

    Anyway, elegance lies in complementary construction. If >> preserves the sign bit, by complementarity, << should also preserve the LSB, right?

    -Phil
  • Cluso99Cluso99 Posts: 18,066
    Roy Eltham wrote: »
    jmg, I don't like that idea at all. I think they should be boolean only.
    +1

  • jmgjmg Posts: 15,140
    jmg wrote:
    Can AND OR XOR NOT be made to apply to both Boolean and Bitwise ?
    Should be possible to know if you have boolean as in ...
    Absolutely not! Having the compiler infer the semantics from an otherwise ambiguous syntax is always a recipe for disaster.
    I do not see anything ambiguous in my examples, and FreePascal manages that just fine, no disaster in sight ?
    jmg wrote:
    What is the technical or usage problem you see ?
    I've often written: x := a AND b, when I want x to return TRUE if a and b are both non-zero, FALSE otherwise. Nuff said, jmg?
    So what you really meant (which is what your words explain) was x := (a<>0) AND (b<>0) ?
    That clear form works just fine for me ?


  • jmgjmg Posts: 15,140
    Roy Eltham wrote: »
    Phil,
    >> is SAR and << is SHL in many other languages for signed numbers. For example, in C/C++, which I know you hate, but it's what most of the other copy.
    So it doesn't run against all convention...

    >> is SAR and << is SHL makes sense to me, this was covered earlier with a link I gave to Microsoft C
    SHR exists to cover all cases.

  • I prefer boolean only too. (AND, OR...)
  • Looks good, Chip.

    Do boolean AND and OR short circuit? That is, in:
    c := 0 AND foo(1)
    
    does the foo() function get called? In C it doesn't for &&, but of course does for &.

    jmg: boolean AND and binary AND are different, so they should have different operators. If Spin had a boolean type then perhaps we could rely on the compiler to infer which is intended, but with all variables being 32 bit integers this isn't really possible.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote:
    >>, SAR		x >> y		x >>= y		binary		3, 16	Shift right, preserve sign
    <<, SHL		x << y		x <<= y		binary		3, 16	Shift left
    SHR		x SHR y		x SHR= y	binary		3, 16	Shift right, MSB's = 0
    
    Seriously, Chip? >> for SAR instead of SHR is not only non-complementary to << but runs against all convention. Please reconsider!

    -Phil
    In all my programming in spin, I had not realised that >> was SAR, not SHR :(
    Fortunately I never got into trouble, so obviously when I did it the msb was 0.

    Before posting, I checked spin on P1. Sure enough >> is SHR

    This is going to be a big bugbear between spin on P1 and P2 !!!
    Who do you want to support the most, P1 users or non-P1 users ???

    Why not keep the P1 syntax here...
    >>, SHR		x >> y		x >>= y		binary		3, 16	Shift right
    <<, SHL		x << y		x <<= y		binary		3, 16	Shift left
    ~>, SAR		x ~> y		x ~>= y    	binary		3, 16	Shift right, preserve sign
    
  • Phil,
    >> is SHR on C/C++(and others) when the value is unsigned, but SAR when the value is signed. Spin stuff is signed, right?
    Also, the complement of SAR is SAL, not some odd keep the LSB thing.
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-04-13 00:33
    #>		x #> y		x #>= y		binary		9, 16	Ensure x => y
    <#		x <# y		x <#= y		binary		9, 16	Ensure x <= y
    
    Are these signed, as P1 was ??? if yes, then can it be written (and same for other signed operators)
    #>		x #> y		x #>= y		binary signed	9, 16	Ensure x => y
    <#		x <# y		x <#= y		binary signed	9, 16	Ensure x <= y
    

    So we write
      min #> x <# max  'limit x between min and max
    
    Looks wrong to me, but it is compatible to P1.
  • Roy Eltham wrote: »
    jmg, I don't like that idea at all. I think they should be boolean only.
    +1
  • Most recent list passes the gut check.

    Glad you saw the need for XOR being between AND and OR in priority, and for the pseudo-functions ABS and SQRT to be only after pre- and post-increment type operations, but before all others.
  • rjo__rjo__ Posts: 2,114
    Spin1 ... unabstracted fun.
    Spin2 ... ditto.
    potatohead wrote: »
    Right!

    You didn't learn it because it made obvious sense. Whatever we do, preserving that is desirable, IMHO.

    I don't know, nor needed to know all of SPIN 1 rules, and for this reason.

    I never learned it because Jesus gave me "( )":)

    If you guys are writing for yourselves, feel free to use your syntactic memories... but if you are coding for the rest of
    us, please don't assume the reader has any sense of operator precedence. I don't:)

    Love you guys.



  • Roy Eltham wrote:
    >> is SHR on C/C++(and others) when the value is unsigned, but SAR when the value is signed. Spin stuff is signed, right?
    So what? Signed is all we've got. But most of the time anything is shifted in Spin it's some kind of bit mask or serial I/O data, not a signed number. Why complicate things by making what's logically >> into some alphabet-soup mnemonic?

    -Phil
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-04-13 04:21
    jmg,

    Another case:

    IF (pins AND mask)

    What does your "smart" compiler do?

    IF (pins <> 0 AND mask <> 0)

    or

    IF ((pins & mask) <> 0)

    Maybe time to quit digging a deeper hole for yourself?

    -Phil
  • jmgjmg Posts: 15,140
    edited 2017-04-13 05:42
    Maybe time to quit digging a deeper hole for yourself?
    Giving working examples, is a very long way from digging a hole for myself .... :)

    Another case:

    IF (pins AND mask)

    What does your "smart" compiler do?
    Depends on the types, if neither is boolean, then a bitwise AND is performed, but it also coughs a message,
    Error: Incompatible types: got "Word" expected "Boolean"
    because you have not completed the test expression as written.

    If you really meant to say

    IF (pins <> 0) AND (mask <> 0)

    then that also compiles just fine, as too is this alternative

    IF (pins AND mask) <> 0

    but one cannot be too terse or cryptic in code, which is just fine with me.

  • jmg, Spin doesn't have types, everything is a long for operations.
  • AribaAriba Posts: 2,682
    edited 2017-04-13 05:48
    For me >> should be a bitwise shift, not arithmetic. From a microcontroller you just expect to shift bits.
    An arithmetic right shift is only rarely used for divide by 2^n. In most cases you will use Divide for that.

    In C you would normally define a variable as unsigned int, that you use for bit handling, like shifts. This is not possible in Spin, but changing >> to the unusal SAR because of that, makes not much sense.

    Exept of that, I'm happy with the operator table, Chip has posted.

    Andy
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-04-13 05:48
    On second thought, we could load the complier with the entire English lexicon -- and those of other languages, too -- so that that it can infer from variable and function names what the programmer is thinking. So if one writes

    IF (pins AND mask)

    it looks up "pins" and "mask" and infers correctly from their usual meaning in a programming context that it must be a bitwise AND.

    OTOH, if one writes

    IF (net_pay AND taxable)

    if looks up "net," "pay," and "taxable" to infer -- again correctly! -- that it must be a Boolean AND.

    Such a compiler would be pure genius!

    -Phil
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    .... If Spin had a boolean type then perhaps we could rely on the compiler to infer which is intended, but with all variables being 32 bit integers this isn't really possible.
    Fair point, given P2 has BIT operators, perhaps adding a boolean type makes solid sense ?
    It certainly helps save precious COG memory, and is already done in MCUs like the 8051.

  • How about we just take the simple path we are on now?

    Seriously, it's nice overall, save for the shift discussion. Seems like we can either live with it, or resolve it, and move on, done!

  • cgraceycgracey Posts: 14,133
    edited 2017-04-13 06:35
    I agree that for Spin, >> should just be a simple shift right. I should have realized that.

    SAR can be the arithmetic version. This means we don't need SHR and SHL, since >> and << cover those.
  • cgraceycgracey Posts: 14,133
    Any beefs with the precedence order? It's different than C, but I've got to say that C precedence seems a little 'off' in places.
  • Keep the Spin precedence order, Chip. I concur with your assessment that C's is a bit off.

    Thanks,
    -Phil
Sign In or Register to comment.