Spin2 Operator Syntax

145791016

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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • 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: 20,920
    edited April 12 Vote Up0Vote Down
    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • jmgjmg Posts: 9,846
    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,104
    edited April 12 Vote Up0Vote Down
    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • 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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Roy Eltham wrote: »
    jmg, I don't like that idea at all. I think they should be boolean only.
    +1

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 9,846
    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: 9,846
    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...)
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • 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.
  • 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
    
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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: 12,523
    edited April 13 Vote Up0Vote Down
    #>		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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Roy Eltham wrote: »
    jmg, I don't like that idea at all. I think they should be boolean only.
    +1
    garryj
  • 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.
  • 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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 20,920
    edited April 13 Vote Up0Vote Down
    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • jmgjmg Posts: 9,846
    edited April 13 Vote Up0Vote Down
    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,056
    edited April 13 Vote Up0Vote Down
    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: 20,920
    edited April 13 Vote Up0Vote Down
    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • jmgjmg Posts: 9,846
    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!

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • cgraceycgracey Posts: 7,605
    edited April 13 Vote Up0Vote Down
    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.
  • 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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
Sign In or Register to comment.