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.
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.
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.
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
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
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.
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
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.
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.
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'.
<= 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.
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.
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.
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.
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...
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.
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.
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!
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 !!!!!
...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 ?
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.
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.
Comments
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.
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 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.
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
Why should this be invalid?
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.
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 zI've been glad to have this feature, far more often than I've been bothered by trying to type less.
These seem inconsistent, and conflict currently with the x~ and x~~ So, why not use... ie Boolean uses double operators, bitwise uses single operators.
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?
So to keep similar to PASM P2, why not use
Perhaps P2 PASM could use LMIN and LMAX instead of MIN and MAX to avoid errors too ???
Good ideas. I'll change to those.
? 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.
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.
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.
The only missing detail I can see is XOR seems to not be there ?
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
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.
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...
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.
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.
If they are not being used (or extremely rare) then I too would prefer the <= and >= way.
I don't think we should alienate the P1 programmers to get clarity!
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 !!!!!
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 ?
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.
Probably true, but a math teacher is not writing code on a computer with the limited number of characters a keyboard provides.