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.
gut feeling says the rules should be so that this is all possible without parentheses:
IF A>5 AND ++B<=6 OR NOT C OR D - 1 <> E + 5 * 5
meaning:
( (A>5) AND ( (++B)<=6) ) OR (NOT C) OR ( (D-1) <> (E + (5*5) ) )
This seems pretty much in line with what Spin1 does.
Seriously, much has happened since C was invented, and I think the Spin1 precedence is much more intuitive.
As for the second part, that's a tough one but my vote is a definite no on ! and NOT acting different. There are already different symbols for a 1's complement and 2's complement.
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.
Roy, you're so used to programming in a truly ugly language (C), that you're apparently blind to the elegance of what Chip created in Spin. And I have never considered the Spin operators to be either confusing or problematic. Chip needs to forge his own path with Spin2. Based upon what he accomplished with Spin, I hope that he has the courage to follow his heart once again and ignore the influences -- including some of my own -- rampant in this thread. Spin is not C; C is not Spin. They do not need to have anything in common. Programming in C is work. Programming in Spin should remain fun.
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 !!!!!
Yes, if P1 has effectively defined these bass-ackwards, then a new name is needed, but it needs to be quite clear on what the new one does.
'Limiting the minimum' is too vague and verbose to turn into an opcode.
Sorry, Phil, but I strongly disagree. It's not just C. It's every other language out there for the most part. Every common language.
Spin's operators have caused numerous problems for MANY users novice and expert. Just because you don't have an issue, doesn't mean MANY others don't.
Chip has already got it working with the C/Verilog set of operators, and I think that is good. He seems to think so too.
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.
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.
I wonder why no language uses /= for not equal? That is the closest you can get to the standard mathematical notation. Of course, it wouldn't work for C because that is an assignment operator.
I presume we are not thinking about operator overloading in C++. Nor the contortions you can perform with Forth. I don't count things like "#define PLUS +" in C etc which is just a bad idea.
I presume we are not thinking about operator overloading in C++. Nor the contortions you can perform with Forth. I don't count things like "#define PLUS +" in C etc which is just a bad idea.
Well, there is no #define in Spin so I think you're safe there.
I wonder why no language uses /= for not equal? That is the closest you can get to the standard mathematical notation. Of course, it wouldn't work for C because that is an assignment operator.
I think one of the ML variants uses "=/=" for not equal, but it's a little unusual. I think either "<>" or "!=" would be fine. I don't like the idea of aliases, though -- just pick one and stick with it.
You know, people keep saying here that Spin2 has to be different from Spin. I don't see why that has to be true except that PASM2 is different from PASM. There is no real reason that the high-level part of Spin has to be different. It seems to me that if Spin2 is the only language available for P2 at launch and with Spin2 being fairly different from Spin you end up with a processor that can't easily be adopted by either existing P1 users or people coming from another MCU. Isn't this shooting yourself in the foot? I know we are all experts and can make the transition from Spin to Spin2 pretty easily but what about the non-experts who are using P1? I would suggest keeping the high-level part of Spin2 a strict superset of Spin.
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.
What other languages have aliases for operators?
Here is a listing file, for an Assembler I just generated
564: 008D 11 8C CALL SFR_Init
565: 008F 80 FE SJMP $
566: 0091 3E 2A DB ">","*"
567: 0093 1F DB 0x1f
568: 0094 1F db 01fH
569: 0095 0F db 0000_1111b
570: 0096 08 db 1 << 3
571: 0097 08 db 1 SHL 3
572: 0098 10 db 128 >> 3
573: 0099 10 db 128 SHR 3
574: 009A 03 db 15 AND 3
575: 009B 03 db 15 & 3
576: 009C 0C db 15 XOR 3
577: 009D 0C db 15 ^ 3
578: 009E 0B db 8 OR 3
579: 009F 0B db 8 | 3
580: if 1 <= 4
581: 00A0 0E db 14
582: else
583: db 4
584: endif
585:
586: if 1 LE 4
587: 00A1 0E db 14
588: else
589: db 4
590: endif
591: if 1 GT 4
592: db 14
593: else
594: 00A2 04 db 4
595: endif
These are both very similar to Chip's proposals, but probably a superset, as you can see LE,GT etc supported too, which means Chip could add more aliases, and still not be pioneering ahead of what is already done.
(except the ASM also allows both HEX numeric forms, of 12H and 0x12, that was added because tables often are generated in C-Hex form, and it is more common for C-tools to include assemblers that can accept 0x12 numbers too)
You know, people keep saying here that Spin2 has to be different from Spin. I don't see why that has to be true except that PASM2 is different from PASM. There is no real reason that the high-level part of Spin has to be different. It seems to me that if Spin2 is the only language available for P2 at launch and with Spin2 being fairly different from Spin you end up with a processor that can't easily be adopted by either existing P1 users or people coming from another MCU. Isn't this shooting yourself in the foot? I know we are all experts and can make the transition from Spin to Spin2 pretty easily but what about the non-experts who are using P1? I would suggest keeping the high-level part of Spin2 a strict superset of Spin.
You make a *very* good point here David. I wonder how much (non-PASM) Spin1 could be made to work on Spin2? I suspect most of it.
You know, people keep saying here that Spin2 has to be different from Spin. I don't see why that has to be true except that PASM2 is different from PASM. There is no real reason that the high-level part of Spin has to be different. It seems to me that if Spin2 is the only language available for P2 at launch and with Spin2 being fairly different from Spin you end up with a processor that can't easily be adopted by either existing P1 users or people coming from another MCU. Isn't this shooting yourself in the foot? I know we are all experts and can make the transition from Spin to Spin2 pretty easily but what about the non-experts who are using P1? I would suggest keeping the high-level part of Spin2 a strict superset of Spin.
To cover exactly this case, I did earlier suggest a mode switch, for where that 'strict superset' collides/conflicts with other demands.
For those who are averse to a mode switch, a simple translator should be possible, that does P1_Spin to P2_Spin, to allow harvest of code, without forcing conflicts.
...
I wonder why no language uses /= for not equal? That is the closest you can get to the standard mathematical notation. Of course, it wouldn't work for C because that is an assignment operator.
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.
What other languages have aliases for operators?
Here is a listing file, for an Assembler I just generated
564: 008D 11 8C CALL SFR_Init
565: 008F 80 FE SJMP $
566: 0091 3E 2A DB ">","*"
567: 0093 1F DB 0x1f
568: 0094 1F db 01fH
569: 0095 0F db 0000_1111b
570: 0096 08 db 1 << 3
571: 0097 08 db 1 SHL 3
572: 0098 10 db 128 >> 3
573: 0099 10 db 128 SHR 3
574: 009A 03 db 15 AND 3
575: 009B 03 db 15 & 3
576: 009C 0C db 15 XOR 3
577: 009D 0C db 15 ^ 3
578: 009E 0B db 8 OR 3
579: 009F 0B db 8 | 3
580: if 1 <= 4
581: 00A0 0E db 14
582: else
583: db 4
584: endif
585:
586: if 1 LE 4
587: 00A1 0E db 14
588: else
589: db 4
590: endif
591: if 1 GT 4
592: db 14
593: else
594: 00A2 04 db 4
595: endif
These are both very similar to Chip's proposals, but probably a superset, as you can see LE,GT etc supported too, which means Chip could add more aliases, and still not be pioneering ahead of what is already done.
(except the ASM also allows both HEX numeric forms, of 12H and 0x12, that was added because tables often are generated in C-Hex form, and it is more common for C-tools to include assemblers that can accept 0x12 numbers too)
How about some examples from mainstream languages that some of us may have actually heard of?
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 !!!!!
oh - LMIN is not LONG MIN ??
another option for confusion
I always wondered why in SPIN MAX and MIN are reversed ... compared to all the other languages I know ... (even Tachyon I use most on the Prop)
so for 'universal' clarity ;-)
MIN(x,y) gives the smallest of both (x,y) ... please
then no LMIN and no mindbending needed ..
If the language is called SPIN2 then it should be as close to SPIN1 as possible.
Otherwise it needs a new name.
Switching between Propeller 1 und Propeller 2 programming in Spin will get much more tedious than switching between C and Spin now.
Changing the operator precedence can result in hard to find errors in code translated from Spin1 to Spin2. You will need to check every expression with the old and new prededence in mind and set additional parentheses or remove them.
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.
I wonder why no language uses /= for not equal? That is the closest you can get to the standard mathematical notation. Of course, it wouldn't work for C because that is an assignment operator.
Coming from a more hardware oriented background /= instead of != for not equal would have been fine by me. A / followed by characters is a common way of naming low true signals. Unfortunately it is already in use.
A point I made early on. If we diverge too much, people will just fork SPIN 1, add PASM in line and go that way. Ersmith already put the basics for this out there.
Honestly, I think people can live with the operator change. SPIN predicence rules are better kept though.
Go beyond that, and it's an increasing worry.
Not saying don't do it. Am saying it needs to be sweet, or it may not be adopted.
Sorry, Phil, but I strongly disagree. It's not just C. It's every other language out there for the most part. Every common language.
Spin's operators have caused numerous problems for MANY users novice and expert. Just because you don't have an issue, doesn't mean MANY others don't.
Chip has already got it working with the C/Verilog set of operators, and I think that is good. He seems to think so too.
I never learn precedence rules because after the natural priority of the simple math operators, (+, - vs *, / etc) there is nothing obvious and I give up and bracket everything to make it clear what I want.
I never learn precedence rules because after the natural priority of the simple math operators, (+, - vs *, / etc) there is nothing obvious and I give up and bracket everything to make it clear what I want.
I never learn precedence rules because after the natural priority of the simple math operators, (+, - vs *, / etc) there is nothing obvious and I give up and bracket everything to make it clear what I want.
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
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:
That looks quite good.
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
IF (A >30) AND (A < 40)
versus numbers, for bit-wise as in
A := A AND $AA
Other tools manage this ok.
Other items besides operators :
a) // is not allocated, and is now pretty much universal as a comment to end of line
b) In the ASM example I gave above, all of $AA, 0xAA, 0AAH are valid hex numbers.
The merit in supporting 0xAA form, is many tools export arrays in C-syntax hex, and being able to parse 0xAA means no editing of the lists is needed,
Here is one example, from Silabs Clock generator tools
Comments
gut feeling says the rules should be so that this is all possible without parentheses:
This seems pretty much in line with what Spin1 does.
Seriously, much has happened since C was invented, and I think the Spin1 precedence is much more intuitive.
As for the second part, that's a tough one but my vote is a definite no on ! and NOT acting different. There are already different symbols for a 1's complement and 2's complement.
-Phil
Yes, if P1 has effectively defined these bass-ackwards, then a new name is needed, but it needs to be quite clear on what the new one does.
'Limiting the minimum' is too vague and verbose to turn into an opcode.
Spin's operators have caused numerous problems for MANY users novice and expert. Just because you don't have an issue, doesn't mean MANY others don't.
Chip has already got it working with the C/Verilog set of operators, and I think that is good. He seems to think so too.
I presume we are not thinking about operator overloading in C++. Nor the contortions you can perform with Forth. I don't count things like "#define PLUS +" in C etc which is just a bad idea.
I think one of the ML variants uses "=/=" for not equal, but it's a little unusual. I think either "<>" or "!=" would be fine. I don't like the idea of aliases, though -- just pick one and stick with it.
Here is a listing file, for an Assembler I just generated
and see this PDF for IEC61131 which shows applied alias lists
http://calc1.kss.ia.polsl.pl/content/dydaktyka/PC/PLC_IEC61131-3.pdf
These are both very similar to Chip's proposals, but probably a superset, as you can see LE,GT etc supported too, which means Chip could add more aliases, and still not be pioneering ahead of what is already done.
(except the ASM also allows both HEX numeric forms, of 12H and 0x12, that was added because tables often are generated in C-Hex form, and it is more common for C-tools to include assemblers that can accept 0x12 numbers too)
You make a *very* good point here David. I wonder how much (non-PASM) Spin1 could be made to work on Spin2? I suspect most of it.
For those who are averse to a mode switch, a simple translator should be possible, that does P1_Spin to P2_Spin, to allow harvest of code, without forcing conflicts.
Looks like a good chunk of such a Translator already exists here
https://forums.parallax.com/discussion/166470/can-t-wait-for-propgcc-on-the-p2
This s2p does the somewhat harder ASM translation.
VHDL uses this Also Python has aliases it supports both != and <> but != is recommended.
Andy
another option for confusion
I always wondered why in SPIN MAX and MIN are reversed ... compared to all the other languages I know ... (even Tachyon I use most on the Prop)
so for 'universal' clarity ;-)
MIN(x,y) gives the smallest of both (x,y) ... please
then no LMIN and no mindbending needed ..
Otherwise it needs a new name.
Switching between Propeller 1 und Propeller 2 programming in Spin will get much more tedious than switching between C and Spin now.
Changing the operator precedence can result in hard to find errors in code translated from Spin1 to Spin2. You will need to check every expression with the old and new prededence in mind and set additional parentheses or remove them.
Andy
Coming from a more hardware oriented background /= instead of != for not equal would have been fine by me. A / followed by characters is a common way of naming low true signals. Unfortunately it is already in use.
A point I made early on. If we diverge too much, people will just fork SPIN 1, add PASM in line and go that way. Ersmith already put the basics for this out there.
Honestly, I think people can live with the operator change. SPIN predicence rules are better kept though.
Go beyond that, and it's an increasing worry.
Not saying don't do it. Am saying it needs to be sweet, or it may not be adopted.
Sorry Phil, I strongly agree with Roy and the others on this.
Operator precedence is only important if you don't have to remember it.
So... it isn't really important. Is it?
I have no idea what the operator precedence is for Spin 1 and I'm certainly not going
to learn it for Spin 2:)
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.
That what I do, too.
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 yCan AND OR XOR NOT be made to apply to both Boolean and Bitwise ?
Should be possible to know if you have boolean as in
IF (A >30) AND (A < 40)
versus numbers, for bit-wise as in
A := A AND $AA
Other tools manage this ok.
Other items besides operators :
a) // is not allocated, and is now pretty much universal as a comment to end of line
b) In the ASM example I gave above, all of $AA, 0xAA, 0AAH are valid hex numbers.
The merit in supporting 0xAA form, is many tools export arrays in C-syntax hex, and being able to parse 0xAA means no editing of the lists is needed,
Here is one example, from Silabs Clock generator tools