>>, 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,
>> 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...
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
>> 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,
>> 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.
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.
>>, 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.
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.
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:)
>> 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?
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.
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.
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.
.... 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.
Comments
-Phil
-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...
-Phil
Anyway, elegance lies in complementary construction. If >> preserves the sign bit, by complementarity, << should also preserve the LSB, right?
-Phil
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 ?
>> 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.
Do boolean AND and OR short circuit? That is, in: 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.
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...
>> 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.
So we write Looks wrong to me, but it is compatible to P1.
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.
Spin2 ... ditto.
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.
-Phil
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
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.
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
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
It certainly helps save precious COG memory, and is already done in MCUs like the 8051.
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!
SAR can be the arithmetic version. This means we don't need SHR and SHL, since >> and << cover those.
Thanks,
-Phil