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

Spin2 Operator Syntax

1235718

Comments

  • Cluso99Cluso99 Posts: 18,066
    Just to further muddy the waters,,,

    BGT, BGE, BLT, BLE, BEQ, BNE are common in many assemblers.

    This is my background, so operators such as GT, GE, LT, LE, EQ, NE make more sense to me. I am not necessarily advocating these, but rather illustrating the preferences are coloured by your background.
  • Heater.Heater. Posts: 21,230
    Yes, and sign extend should be "SEX". As it was in the Motorola 6809 assembler we had back in the day :)
  • cgraceycgracey Posts: 14,131
    jmg wrote: »
    cgracey wrote: »
    Potatohead pointed out a conflict with % and binary number declarations. I don't want to loose %0101_1111, so % cannot be modulus. What about using // or MOD for modulus?

    // is already widely used, in many languages, as a comment to end of line.

    I'm not sure % is entirely lost ? - as 12 MOD 4 or 12 % 4 is understood by the parser.
    ie the white space makes it quite clear what use % has ?


    As long as there was whitespace, it would work. Better not type "x%10". Actually, the parser would know that a binary operator was to be expected, not a term that could be a binary number. We'll just go with MOD. Most people like that.
  • Heater. wrote: »
    Yes, and sign extend should be "SEX". As it was in the Motorola 6809 assembler we had back in the day :)
    The only SEX many programmers get? :-)

  • cgraceycgracey Posts: 14,131
    edited 2017-04-11 20:47
    David Betz wrote: »
    Heater. wrote: »
    Yes, and sign extend should be "SEX". As it was in the Motorola 6809 assembler we had back in the day :)
    The only SEX many programmers get? :-)

    I was looking at the RISC V instruction set the other day, wondering what some of their mnemonics mean.

    FSGNJN - Floating-point to floating-point sign injection instructions.
    AMOSWAP - I really like this one, as it kind of goes with the "fast, stealthy, gaijin ninja" one above. AMO means atomic memory operation, not ammo or amor/amour.

    Today, nobody but the C compiler writer is expected to get familiar with assembly language. Kind of like having a face made for radio - the chip, that is.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    As long as there was whitespace, it would work. Better not type "x%10". Actually, the parser would know that a binary operator was to be expected, not a term that could be a binary number. We'll just go with MOD. Most people like that.
    I'm fine with MOD.
    You could check the error messages, should someone miss-use, or accidentally paste, %

    One other thing done for binary-strings, is check for MOD 8 on string length, so that spits an error on %0001111, or %000011110

  • Cluso99Cluso99 Posts: 18,066
    jmg wrote: »
    cgracey wrote: »
    As long as there was whitespace, it would work. Better not type "x%10". Actually, the parser would know that a binary operator was to be expected, not a term that could be a binary number. We'll just go with MOD. Most people like that.
    I'm fine with MOD.
    You could check the error messages, should someone miss-use, or accidentally paste, %

    One other thing done for binary-strings, is check for MOD 8 on string length, so that spits an error on %0001111, or %000011110
    XXX LONG %1010
    Why should this be invalid?
  • Heater.Heater. Posts: 21,230
    To be fair most RISC V instructions are pretty straight forward. And there are few enough of them to have to remember. AMOSWAP sounds great, sounds like a Intel X86 XCHG instruction with the LOCK prefix.

    Mind, I have yet to fathom what FSGNJN is supposed to do. That is a rare odd ball in the pack.

    I think you are right, back in the day instruction sets were designed to make life comfortable for assembler programmers.

  • cgraceycgracey Posts: 14,131
    Here is what I've got now. I think the aliases are important, though I got rid of them and put them back in a few times. This supports all the C operators. I kind of don't like C precedence, though, since too many parentheses wind up being needed - like NOT, for example, seems like it should have lower precedence, in order to work well with AND and OR. I almost want to separate ! and NOT and give them different precedence.
    Operator	Term Usage	Assign Usage	Type		Description
    ----------------------------------------------------------------------------------------------------------------
    :=		x := y		x := y		assign		Set x to y
    
    ++ (pre)	++x		++x		var prefix	Pre-increment
    -- (pre)	--x		--x		var prefix	Pre-decrement
    ?? (pre)	??x		??x		var prefix	PRNG reverse, var must be long
    ++ (post)	x++		x++		var postfix	Post-increment
    -- (post)	x--		x--		var postfix	Post-decrement
    ?? (post)	x??		x??		var postfix	PRNG forward, var must be long
    !  (post)	x!		x!		var postfix	Post-boolean NOT
    ~  (post)	x~		x~		var postfix	Post-bitwise NOT
    \  (post)	x\y		x\y		var postfix	Post-set to y
    
    !, NOT		!x		!= x		unary		Boolean NOT (0 = -1, non-0 = 0)
    ~		~x		~= x		unary		Bitwise NOT, 1's complement
    -		-x		-= x		unary		Negation, 2's complement
    ABS		ABS x		ABS= x		unary		Absolute value
    ENC		ENC x		ENC= x		unary		Encode MSB, 31..0
    DEC		DEC x		DEC= x		unary		Decode, 1 shl (x & $1F)
    SQRT		SQRT x		SQRT= x		unary		Square root
    LOG2		LOG2 x		LOG2= x		unary		Unsigned to logarithm-base2
    EXP2		EXP2 x		EXP2= x		unary		Logarithm-base2 to unsigned
    
    &&, AND		x && y		x &&= y		binary		Boolean AND  (x <> 0 AND y <> 0, returns 0 or -1)
    ||, OR		x || y		x ||= y		binary		Boolean OR   (x <> 0 OR  y <> 0, returns 0 or -1)
    &		x & y		x &= y		binary		Bitwise AND
    |		x | y		x |= y		binary		Bitwise OR
    ^		x ^ y		x ^= y		binary		Bitwise XOR
    >>, SAR		x >> y		x >>= y		binary		Shift right, preserve sign
    <<, SHL		x << y		x <<= y		binary		Shift left
    SHR		x SHR y		x SHR= y	binary		Shift right, 0's into MSB's
    ROR		x ROR y		x ROR= y	binary		Rotate right
    ROL		x ROL y		x ROL= y	binary		Rotate left
    REV		x REV y		x REV= y	binary		Reverse y LSBs of x and zero-extend
    AT_LEAST	x AT_LEAST y	x AT_LEAST= y	binary		Ensure x => y
    AT_MOST		x AT_MOST y	x AT_MOST= y	binary		Ensure x <= y
    +		x + y		x += y		binary		Add
    -		x - y		x -= y		binary		Subtract
    *		x * y		x *= y		binary		Multiply
    /		x / y		x /= y		binary		Divide, return quotient
    MOD		x MOD y		x MOD= y	binary		Divide, return remainder
    SCAL		x SCAL y	x SCAL= y	binary		Scale, unsigned (x * y) >> 32
    FRAC		x FRAC y	x FRAC= y	binary		Fraction, unsigned {x, 32'b0}/y
    SIGNX		x SIGNX y	x SIGNX= y	binary		Sign-extend from bit y
    
    <		x < y		n/a		equality	Check less than,		(returns 0 or -1)
    <=		x <= y		n/a		equality	Check equal or less than,	(returns 0 or -1)
    ==		x == y		n/a		equality	Check equal,			(returns 0 or -1)
    !=, <>		x != y		n/a		equality	Check not equal,		(returns 0 or -1)
    >=		x >= y		n/a		equality	Check equal or greater than,	(returns 0 or -1)
    >		x > y		n/a		equality	Check greater than,		(returns 0 or -1)
    
    ? :		x ? y : z	n/a		ternary		Choose between y and z
    
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    jmg wrote: »
    One other thing done for binary-strings, is check for MOD 8 on string length, so that spits an error on %0001111, or %000011110
    XXX LONG %1010
    Why should this be invalid?
    The reason is to catch typos, which are mostly off-by-one, so you could just as easily use MOD 4, if you plan on using a lot of nibbles...
    I've been glad to have this feature, far more often than I've been bothered by trying to type less.
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-04-12 02:27
    Chip,
    These seem inconsistent, and conflict currently with the x~ and x~~
    !  (post)	x!		x!		var postfix	Post-boolean NOT
    ~  (post)	x~		x~		var postfix	Post-bitwise NOT
    
    !, NOT		!x		!= x		unary		Boolean NOT (0 = -1, non-0 = 0)
    ~		~x		~= x		unary		Bitwise NOT, 1's complement
    
    &&, AND		x && y		x &&= y		binary		Boolean AND  (x <> 0 AND y <> 0, returns 0 or -1)
    ||, OR		x || y		x ||= y		binary		Boolean OR   (x <> 0 OR  y <> 0, returns 0 or -1)
    &		x & y		x &= y		binary		Bitwise AND
    |		x | y		x |= y		binary		Bitwise OR
    ^		x ^ y		x ^= y		binary		Bitwise XOR
    
    So, why not use...
    !!  (post)	x!!		x!!		var postfix	Post-boolean NOT
    !  (post)	x!		x!		var postfix	Post-bitwise NOT
    
    !!, NOT		!!x		!!= x		unary		Boolean NOT (0 = -1, non-0 = 0)
    &&, AND		x && y		x &&= y		binary		Boolean AND  (x <> 0 AND y <> 0, returns 0 or -1)
    ||, OR		x || y		x ||= y		binary		Boolean OR   (x <> 0 OR  y <> 0, returns 0 or -1)
    
    !		!x		!= x		unary		Bitwise NOT, 1's complement
    &		x & y		x &= y		binary		Bitwise AND
    |		x | y		x |= y		binary		Bitwise OR
    ^		x ^ y		x ^= y		binary		Bitwise XOR
    
    ie Boolean uses double operators, bitwise uses single operators.
  • cgraceycgracey Posts: 14,131
    edited 2017-04-12 02:34
    Cluso99,

    I got rid of the var~ and var~~ operators, in favor of the new var\value, which sets the var to value after it's been read as a term. You'll be able to post-clear via 'var\0' or post-set via 'var\-1'.

    So, do you think it's still an issue?
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-04-12 02:52
    To me, the MAX and MIN in PASM P1 are wrong (reversed).

    So
    AT_LEAST	x AT_LEAST y	x AT_LEAST= y	binary		Ensure x => y
    AT_MOST		x AT_MOST y	x AT_MOST= y	binary		Ensure x <= y
    
    to keep similar to PASM P2, why not use
    LMIN         	x LMIN y	x LMIN= y	binary		Ensure x => y (limit minimum)
    LMAX		x LMAX y	x LMAX= y	binary		Ensure x <= y (limit maximum)
    

    Perhaps P2 PASM could use LMIN and LMAX instead of MIN and MAX to avoid errors too ???
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    To me, the MAX and MIN in PASM P1 are wrong (reversed).

    So
    AT_LEAST	x AT_LEAST y	x AT_LEAST= y	binary		Ensure x => y
    AT_MOST		x AT_MOST y	x AT_MOST= y	binary		Ensure x <= y
    
    to keep similar to PASM P2, why not use
    LMIN         	x LMIN y	x LMIN= y	binary		Ensure x => y (limit minimum)
    LMAX		x LMAX y	x LMAX= y	binary		Ensure x <= y (limit maximum)
    

    Good ideas. I'll change to those.
  • Cluso99Cluso99 Posts: 18,066
    IMHO, rather than these
    <=		x <= y		n/a		equality	Check equal or less than,	(returns 0 or -1)
    >=		x >= y		n/a		equality	Check equal or greater than,	(returns 0 or -1)
    
    I think I would rather
    =<		x =< y		n/a		equality	Check equal or less than,	(returns 0 or -1)
    =>		x => y		n/a		equality	Check equal or greater than,	(returns 0 or -1)
    
    so that the use of <= and >= throws an error. This avoids confusion from P1 and potentially from incorrect P2 usage.
  • jmgjmg Posts: 15,140
    edited 2017-04-12 03:08
    Cluso99 wrote: »
    IMHO, rather than these
    <=		x <= y		n/a		equality	Check equal or less than,	(returns 0 or -1)
    >=		x >= y		n/a		equality	Check equal or greater than,	(returns 0 or -1)
    
    I think I would rather
    =<		x =< y		n/a		equality	Check equal or less than,	(returns 0 or -1)
    =>		x => y		n/a		equality	Check equal or greater than,	(returns 0 or -1)
    
    so that the use of <= and >= throws an error. This avoids confusion from P1 and potentially from incorrect P2 usage.

    ? but that rather defeats the purpose of the 'clean-up' which was to remove surprises and divergences from wider standards.
    I've not seen any other language that uses =< as an operator, so that is guaranteed to confuse just about everyone.

    Even a quite young novice student, can write and read ( A >= B ) and understand what that will do.

  • Cluso, I disagree with that last one.

    P2 should have both versions of the less than or equal and greater than or equal ops. P1 code is going to need conversion to work on P2, and in the 1 in a million rare case that someone used the assignment form of those from P1, then that can be handled at conversion time. Last I checked, obex has zero instances, but it's been a while maybe someone snuck it in someplace. It's just such an odd operation to want to perform, do a logic comparison and assign the true/false result to the left operand.
  • jmgjmg Posts: 15,140
    edited 2017-04-12 03:31
    Cluso99 wrote: »
    to keep similar to PASM P2, why not use
    LMIN         	x LMIN y	x LMIN= y	binary		Ensure x => y (limit minimum)
    LMAX		x LMAX y	x LMAX= y	binary		Ensure x <= y (limit maximum)
    

    Perhaps P2 PASM could use LMIN and LMAX instead of MIN and MAX to avoid errors too ???

    How do these work on Signed and unsigned vars ?

    The way I'd expect MIN, MAX to work, is exactly as found on the web :
    Min : Return smallest of two values.
    Max : Return largest of 2 values

    The wording you have above seems the opposite, for the result to be X >= Y, that requires extract of the highest value.

    ie the root name of any opcode, should reflect the action of that opcode.
    To me that also makes PASM backwards, in the DOCs, so it should be fixed too.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Here is what I've got now. I think the aliases are important, though I got rid of them and put them back in a few times.
    Looks good, & I agree the aliases are important.
    The only missing detail I can see is XOR seems to not be there ?
  • cgraceycgracey Posts: 14,131
    Woops. I forgot to put it back as an alias for ^.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-04-12 04:24
    I hate AT_LEAST, AT_MOST, LMIN, and LMAX. Spin's #> and <# are beautifully descriptive. Why jettison them?

    I prefer <> to !=, just because it's easier to type. Also, I would add a <=> operator, which returns -1 on less than, 0 on equals, and +1 on greater than.

    And, please, say no to aliases. Just make up your mind which one you want to use, and stick to it. You can't please everyone, so there's no point in trying.

    Chip, I didn't agree with all of your choices for Spin1 operators, but the choices you made were at least coherent, the product of a singular vision, and the result was a thing of beauty. Putting this issue up for discussion could be a mistake that will result in a committee-based mishmash. Please just go with your gut and shut out the noise -- including C.

    Thanks,
    -Phil
  • jmgjmg Posts: 15,140
    edited 2017-04-12 05:12
    And, please, say no to aliases. Just make up your mind which one you want to use, and stick to it. You can't please everyone, so there's no point in trying.

    Aliases are not about being indecisive at all, far from it.
    They are done in other languages, and represent a careful choice to improve code clarity and code portability across programmers.

    I can scan code written either way, and it really does not slow me down, but I can also understand that cryptic operators could confuse someone who had never encountered them before.

    Spin's #> and <# are beautifully descriptive. Why jettison them?
    QED. 'beautifully descriptive' to who ? I have to reach for the manual, as I have no idea what they might do ?
    Google of
    "#>" Spin operator
    is no help either...


  • Cluso99Cluso99 Posts: 18,066
    edited 2017-04-12 05:23
    cgracey wrote: »
    Cluso99,

    I got rid of the var~ and var~~ operators, in favor of the new var\value, which sets the var to value after it's been read as a term. You'll be able to post-clear via 'var\0' or post-set via 'var\-1'.

    So, do you think it's still an issue?
    Agreed, your new method is clearer/better.

    However, I still think the use of x!! and x! is better. ie all boolean use the symbol repeated wheraeas the binary uses the symbol once. Makes for consistency.
  • Chip, please do not listen to Phil about shutting out C. That is a mistake.

    Also, the Spin1 operators cause nothing but confusion and problems for new and old alike. Calling them a thing of beauty is a GIANT stretch. It's painful having to look up the operators every time I have to write Spin code, because they are so far from what EVERY other language uses.

    I think it would be a serious mistake to repeat that again, if anything copying the operators of C/Verilog/Perl/EVERY-OTHER-LANGUAGE-IN-EXISTENCE except Spin1 is a good and much needed change.

    Spin2 is NOT compatible with Spin1, everyone needs to stop trying to make it so. It's made with a similar intent, but it's not meant to be, and CAN'T, be the same.
  • Cluso99Cluso99 Posts: 18,066
    Roy Eltham wrote: »
    Cluso, I disagree with that last one.

    P2 should have both versions of the less than or equal and greater than or equal ops. P1 code is going to need conversion to work on P2, and in the 1 in a million rare case that someone used the assignment form of those from P1, then that can be handled at conversion time. Last I checked, obex has zero instances, but it's been a while maybe someone snuck it in someplace. It's just such an odd operation to want to perform, do a logic comparison and assign the true/false result to the left operand.
    I just recall that being discussed as a gotcha in P1 spin. That's why I thought it better to remove all doubt. But likewise, <= and >= are more common for LTE and GTE.
    If they are not being used (or extremely rare) then I too would prefer the <= and >= way.
  • Cluso99Cluso99 Posts: 18,066
    jmg wrote: »
    Cluso99 wrote: »
    to keep similar to PASM P2, why not use
    LMIN         	x LMIN y	x LMIN= y	binary		Ensure x => y (limit minimum)
    LMAX		x LMAX y	x LMAX= y	binary		Ensure x <= y (limit maximum)
    

    Perhaps P2 PASM could use LMIN and LMAX instead of MIN and MAX to avoid errors too ???

    How do these work on Signed and unsigned vars ?

    The way I'd expect MIN, MAX to work, is exactly as found on the web :
    Min : Return smallest of two values.
    Max : Return largest of 2 values

    The wording you have above seems the opposite, for the result to be X >= Y, that requires extract of the highest value.

    ie the root name of any opcode, should reflect the action of that opcode.
    To me that also makes PASM backwards, in the DOCs, so it should be fixed too.
    Normally I would agree. But the P1 (and probably the P2 - I didn't do a check) in PASM use MAX and MIN but are reversed to the way I think they should be. Hence my use of LMIN and LMAX and P2 PASM should also use this.

    I don't think we should alienate the P1 programmers to get clarity!
  • Cluso99Cluso99 Posts: 18,066
    jmg wrote: »
    Cluso99 wrote: »
    to keep similar to PASM P2, why not use
    LMIN         	x LMIN y	x LMIN= y	binary		Ensure x => y (limit minimum)
    LMAX		x LMAX y	x LMAX= y	binary		Ensure x <= y (limit maximum)
    

    Perhaps P2 PASM could use LMIN and LMAX instead of MIN and MAX to avoid errors too ???

    How do these work on Signed and unsigned vars ?

    The way I'd expect MIN, MAX to work, is exactly as found on the web :
    Min : Return smallest of two values.
    Max : Return largest of 2 values

    The wording you have above seems the opposite, for the result to be X >= Y, that requires extract of the highest value.

    ie the root name of any opcode, should reflect the action of that opcode.
    To me that also makes PASM backwards, in the DOCs, so it should be fixed too.
    MAX == LMIN and MIN == LMAX
    Setting the maximum of two values is the same as limiting the minimum.
    x=5 and y=2 then MAX/LMIN will give x=5
    x=5 and y=8 them MAX/LMIN will give x=8

    Agreed PASM P1 is backward which is why I suggested using LMIN and LMAX there too for the P2.

    Otherwise, we have P1 and P2 doing opposite things for MIN and MAX !!!!!
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    ...and probably the P2 - I didn't do a check) in PASM use MAX and MIN but are reversed to the way I think they should be.

    You are right they are reversed to the way most people think.

    Current P2 DOCs say this

    MIN S,D Ensure D => S. If D < S then D = S and C = 1, else D same and C = 0. * ie Get Largest Of
    MAX S,D Ensure D =< S. If D > S then D = S and C = 1, else D same and C = 0. * ie get Smallest Of
    that's reverse English, so certainly needs fixing.

    from above - the way I'd expect MIN, MAX worded opcodes to work, is exactly as found on the web :
    Min : Return smallest of two values.
    Max : Return largest of 2 values


    This may mean choosing a different mnemonic, like MAX_OF, MIN_OF or GETMAX, GETMIN or ?
  • kwinnkwinn Posts: 8,697
    David Betz wrote: »
    kwinn wrote: »
    David Betz wrote: »
    kwinn wrote: »
    cgracey wrote: »
    What about supporting both <> and != for inequality? Just go with != ?

    If both symbols are used in other languages then it makes sense to support both. Either one seems clear enough to me.
    By that logic Spin2 should also support {} and BEGIN / END for block structure in addition to indentation. I think each language makes its own choices about these syntax issues. It doesn't make sense to try to be all things to all people.

    I was referring to this list of operators.
    !       NOT
    &&      AND
    ||      OR
    ^       XOR
    <<      SHL
    %       MOD
    [b]=<   <=
    =>      >=[/b]
    <>      !=
    
    Based on the single character operators != is just as clear if not more so than <> as the not equal operator. The same is true of other logically consistent combinations. How is >= for greater than or equal any less valid or harder to understand than => equal to or greater than. Same is true of other combinations. That does not mean that a lot of illogical or poorly chosen symbols should be added just because they are used in other languages.
    They are all easy enough to understand. However, having only a single operator per operation will make it easier for one person to read another's code and also make it easier for people coming from languages with similar operators.

    How do you say "=>" in English? Do you really say "equal to or greater than"? I've always said "greater than or equal to".

    I say it as I read it, from left to right, so equal to or greater than, although by habit would use >= in my own code. I really have no axe to grind on this, I just think that if it is a logically consistent combination and makes coding simpler for someone coming from another language then why not allow both.
  • kwinnkwinn Posts: 8,697
    David Betz wrote: »
    jmg wrote: »
    cgracey wrote: »
    What about supporting both <> and != for inequality? Just go with != ?
    Is there a conflict here ?
    Why not support both ?
    A Math teacher will understand <>, whilst a C programmer will understand != (aka not equal)
    Which is your main audience here, people already immersed and skilled in C ? or those in Education, and a broader audience ?
    A math teach will not use either. He/she will use an equal sign with a slash through it.

    Probably true, but a math teacher is not writing code on a computer with the limited number of characters a keyboard provides.
Sign In or Register to comment.