I love it. Could be useful for implementing fuzzy logic systems. I expect Spin 2 to have such a thing. After all, we have to keep up with Javascript which has a "much much greater than" operator ">>>".
In any case: Operators are of course a useful programming concept. Not so much, in my opinion, when you stretch that to multi-operator semantics to achieve your one-operation result (clamp a value).
Except that on this processor applying both upper and lower limits is a concatenation of two operations.
Some OBEX objects include circuit diagrams or waveforms, and there's no hope of reading these without the Parallax font, yet they are in many cases critical to understanding of the function or purpose of the code.
Surely that is now deprecated, and in a serious manner.
Tried posting that to the forum, for example ?
I've not found any circuit diagrams or waveforms I could not render fine in Courier Font.
A pity if is deprecated for the OBEX. I'd say that doing it in Courier is good enough for the forum given the font restrictions, but Parallax font is excellent as it was developed with that in mind.
Err, has everyone fully grasped this new !< !> syntax now imposes restrictions on the operator order ?
That restriction was not there on the old syntax.
... I don't think the restriction on operator order is a problem.
My key point was, that restriction is new, it was not there before.
That means simple translation from Spin1 to Spin2, is no longer quite so simple..
Maybe all hope of harvesting Spin1 was lost some time back, but to me it seems important to try to have some easily equivalent mapping, as many of the improvements could easily back-apply to Spin1.5 (ie that means improved syntax Spin, running on P1)
Harvesting Spin1 code will require rework of many elements. I would think that if a tool were developed for such a task it would need to flag many language and architecture elements that will require attention. MIN and MAX will require that regardless of any operand order restrictions.
I've been working on the Spin2 interpreter, getting the math operators into order:
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 Pre-xoro32, iterate x and return pseudo-random
++ (post) x++ x++ var postfix 1 Post-increment
-- (post) x-- x-- var postfix 1 Post-decrement
!! (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
ENCOD ENCOD x ENCOD= x unary 2 Encode MSB, 31..0
DECOD DECOD x DECOD= x unary 2 Decode, 1 << (x & $1F)
ONES ONES x ONES= x unary 2 Count ones
SQRT SQRT x SQRT= x unary 2 Square root of unsigned x
LOG LOG x LOG= x unary 2 Unsigned to logarithm
EXP EXP x EXP= x unary 2 Logarithm to unsigned
>> x >> y x >>= y binary 3, 16 Shift right, insert 0's
<< x << y x <<= y binary 3, 16 Shift left
SAR x SAR y x SAR= y binary 3, 16 Shift right, insert MSB's
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
ZEROX x ZEROX y x ZEROX= y binary 3, 16 Zero-extend above bit y
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 Signed multiply
/ x / y x /= y binary 7, 16 Signed divide, return quotient
REM x REM y x REM= y binary 7, 16 Signed divide, return remainder
SCA x SCA y x SCA= y binary 7, 16 Unsigned scale (x * y) >> 32
SCAS x SCAS y x SCAS= y binary 7, 16 Signed scale (x * y) >> 30
FRAC x FRAC y x FRAC= y binary 7, 16 Unsigned fraction {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, signed
!> x !> y x !>= y binary 9, 16 Ensure x <= y, signed
< x < y equality 10 Signed less than (returns 0 or -1)
<= x <= y equality 10 Signed less than or equal (returns 0 or -1)
== x == y equality 10 Equal (returns 0 or -1)
<> x <> y equality 10 Not equal (returns 0 or -1)
>= x >= y equality 10 Signed greater than or equal (returns 0 or -1)
> x > y equality 10 Signed 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 ternary 15 Choose between y and z
:= x := y x := y assign 16 Set x to y
Math procedures
---------------------------------------------------------------------------------------------
ROTXY(x,y,t : x2,y2) Rotate cartesian (x,y) by t and write to variables (x2,y2)
XYPOL(x,y : r,t) Convert cartesian (x,y) to polar and write to variables (r,t)
POLXY(r,t : x,y) Convert polar (r,t) to cartesian and write to variables (x,y)
SWAP(x,y) Swap variables x and y
Since MIN and MAX are such charged words, I went back to !< and !> for the range-limiting operators.
I also changed MOD to REM, since MOD is not exactly remainder.
I tried keep textual operator names close to the assembler mnemonics' names. REV does a little more in Spin2 and SCA/SCAS deal with 64-bit results, not 32-bit results.
New are the "?" XORO32 operator, along with ZEROX, ONES, and SCA/SCAS.
I've been working on the Spin2 interpreter, getting the math operators into order:
Operator Term Usage Assign Usage Type Prior Description
-------------------------------------------------------------------------------------------------------------------------
[...]
< x < y equality 10 Signed less than (returns 0 or -1)
<= x <= y equality 10 Signed less than or equal (returns 0 or -1)
== x == y equality 10 Equal (returns 0 or -1)
<> x <> y equality 10 Not equal (returns 0 or -1)
>= x >= y equality 10 Signed greater than or equal (returns 0 or -1)
> x > y equality 10 Signed greater than (returns 0 or -1)
Hi Chip,
Regarding Type="equality", maybe the word you were looking for is "relational".
The relational operators are always binary, of course.
Some operators, such as !< !>, are renames of old ones. In the interest of backwards-compatibility, can you make the spin2 compiler accept the old #> and <#, but have it also emit a warning about them suggesting that they be changed to the new ones? The fact that these operators exist could either be undocumented or in a footnote or separate table somewhere.
Some operators, such as !< !>, are renames of old ones. In the interest of backwards-compatibility, can you make the spin2 compiler accept the old #> and <#, but have it also emit a warning about them suggesting that they be changed to the new ones? The fact that these operators exist could either be undocumented or in a footnote or separate table somewhere.
Also, why did you rename // to REM?
I like "//" better. I remember people saying that "//" is nowadays commonly used to begin comments, so there was pressure to not use it. You know, I like "//" better, along with the old "#>" and "<#". I would like to change all three back. Any issues, anyone? Sorry for all the vacillation.
Chip,
For operators, I think you have two choices, either switch completely to something more standard (the C/C++ one is used by a great deal of other languages), or stick with the oddball Spin1 set.
A lot of people here will prefer the Spin1 operators, but most of the world will understand standard operators more.
So the question is, are you trying to make Spin2 for existing Spin1 users, or for the masses?
I think that P2 will have C/C++ (and other standard languages) for the masses, so I think Spin2 should probably aim for the Spin1 users. So You should stick with the existing Spin1 operators as much as possible (except for special cases like ?). That will make going from Spin1 to Spin2 easier for most. I think in general, Spin2 should try to be a superset of Spin1, except of course where the underlying hardware makes that impractical.
Edit: this may be different than what I have said in the past. It's what I think would be best now. Especially since it looks like we'll have decent C/C++ from the get go.
For operators, I think you have two choices, either switch completely to something more standard (the C/C++ one is used by a great deal of other languages), or stick with the oddball Spin1 set.
A lot of people here will prefer the Spin1 operators, but most of the world will understand standard operators more.
So the question is, are you trying to make Spin2 for existing Spin1 users, or for the masses?
Surely any language should target the masses, otherwise it risks culture shock/aversion, and forever being niche.
Spin1 is already niche, and Spin2 that targets 'ex Spin 1 users' has an even smaller catchment,
Forth is terse because it has to be, but there is no excuse to design a compiled language to be less readable.
That's why '//' as an operator, when pretty much everyone else sees 'comment' (including many editors) is clearly nuts.
Limiting the catchment of P2, automatically limits the sales.
jmg,
Spin fundamentally is different enough to put off most people that want C/C++ or other standard languages. It's a language that is highly intertwined with the hardware capabilities of the chip. I think Parallax needs to cater to both existing users and try to expand to the masses. I don't think Spin2 is the path to the masses. The initial customers of the P2 are going to be existing P1 users, and alienating them takes away a potential jump start for the P2. I think it's much better to target having Spin2 be attractive to existing customers, and at the same time have a decent C/C++ option for new customers.
As for C/C++, the P2 lends itself to being a C/C++ target much better than P1. People like Dave Hein already have stuff working to some levels. Ken has stated in the past that he want's it from the start, and I think he will take the steps to make that happen as best as he can, given all the variables.
I think you are being silly when you say it should already be in late testing right now, since we won't even have first samples until July, and the design only just really locked down. I think it's quite reasonable to think that we'll have at least propgcc up and running for P2, if not more than that by the time full production rolls around in the early fall.
I like "//" better. I remember people saying that "//" is nowadays commonly used to begin comments, so there was pressure to not use it. You know, I like "//" better, along with the old "#>" and "<#". I would like to change all three back. Any issues, anyone? Sorry for all the vacillation.
It all depends on WHO you target.
If I was doing this, I would chase the larger slice of the pie, every time, and that means looking out to wider industry, and the huge number of potential users. (rather than looking back in time, to what is a shrinking user base)
Key point:
You want any curious new user to glance at a web-example, nicely highlighted using standard highlighters, and think
'yeah, I could modify that to do what I need'.
It's the same as the classic 'elevator pitch' - someone only has a very short attention span, and if the language looks too strange, they
will simply move on.
It should be simple enough to make a Spin1 to Spin2 script, that takes any Spin1 code and outputs Spin2.
That just requires a unique equivalent operator in both languages, and that Spin2 is a comfortable superset of Spin1.
I think both of those are true (or can be true).
That script covers those still actively using Spin1, who also want to start new designs in Spin2.
I'm also not sure why the need to squash things into cryptic glyphs, when humans are more used to reading words ?
Storage is cheap, and editors are well able to highlight keywords.
I like "//" better. I remember people saying that "//" is nowadays commonly used to begin comments, so there was pressure to not use it. You know, I like "//" better, along with the old "#>" and "<#". I would like to change all three back. Any issues, anyone?
No issues here. Please keep "//", "#>", and "<#" they way they were in Spin1. If the C people want more traditional operators, they can just program in C and don't need to have a say about Spin2.
I do believe that the purported inability of programmers to adapt to a non-traditional language is way overstated.
Contextually, it looks like maybe there is no conflict, after all, but I'm still changing the XORO32 operator to "??".
That's probably a good call. Although I'm not yet able to come up with a statement using "?" in both contexts that's ambiguous, doing so could make parsing more difficult.
I like "//" better. I remember people saying that "//" is nowadays commonly used to begin comments, so there was pressure to not use it. You know, I like "//" better, along with the old "#>" and "<#". I would like to change all three back. Any issues, anyone?
No issues here. Please keep "//", "#>", and "<#" they way they were in Spin1. If the C people want more traditional operators, they can just program in C and don't need to have a say about Spin2.
I do believe that the purported inability of programmers to adapt to a non-traditional language is way overstated.
-Phil
Currently:
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 Pre-xoro32, iterate x and return pseudo-random
++ (post) x++ x++ var postfix 1 Post-increment
-- (post) x-- x-- var postfix 1 Post-decrement
!! (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
ENCOD ENCOD x ENCOD= x unary 2 Encode MSB, 31..0
DECOD DECOD x DECOD= x unary 2 Decode, 1 << (x & $1F)
ONES ONES x ONES= x unary 2 Count ones
SQRT SQRT x SQRT= x unary 2 Square root of unsigned x
LOG LOG x LOG= x unary 2 Unsigned to logarithm
EXP EXP x EXP= x unary 2 Logarithm to unsigned
>> x >> y x >>= y binary 3, 16 Shift right, insert 0's
<< x << y x <<= y binary 3, 16 Shift left
SAR x SAR y x SAR= y binary 3, 16 Shift right, insert MSB's
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
ZEROX x ZEROX y x ZEROX= y binary 3, 16 Zero-extend above bit y
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 Signed multiply
/ x / y x /= y binary 7, 16 Signed divide, return quotient
// x // y x //= y binary 7, 16 Signed divide, return remainder
SCA x SCA y x SCA= y binary 7, 16 Unsigned scale (x * y) >> 32
SCAS x SCAS y x SCAS= y binary 7, 16 Signed scale (x * y) >> 30
FRAC x FRAC y x FRAC= y binary 7, 16 Unsigned fraction {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, signed
<# x <# y x <#= y binary 9, 16 Ensure x <= y, signed
< x < y relational 10 Signed less than (returns 0 or -1)
<= x <= y relational 10 Signed less than or equal (returns 0 or -1)
== x == y relational 10 Equal (returns 0 or -1)
<> x <> y relational 10 Not equal (returns 0 or -1)
>= x >= y relational 10 Signed greater than or equal (returns 0 or -1)
> x > y relational 10 Signed 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 ternary 15 Choose between y and z
:= x := y x := y assign 16 Set x to y
Math procedures
---------------------------------------------------------------------------------------------
ROTXY(x,y,t : x2,y2) Rotate cartesian (x,y) by t and write to variables (x2,y2)
XYPOL(x,y : r,t) Convert cartesian (x,y) to polar and write to variables (r,t)
POLXY(r,t : x,y) Convert polar (r,t) to cartesian and write to variables (x,y)
SWAP(x,y) Swap variables x and y
I do believe that the purported inability of programmers to adapt to a non-traditional language is way overstated.
Sure, some small few can manage that, but the vast majority are simply too lazy to be bothered. (human nature) To deliberately strive to limit yourself to the small few, makes no commercial sense at all.
Remember, it is not only programmers themselves, that make commercial decisions, but often the PHM get into the mix to.
Often, a new chip gets a leg in the door solving some one-off / small volume problem, and then the programmers get confident to use it in volumes, and those volumes are what Parallax & P2 need.
"x <=> y" returns -1 if x < y; 0, if x == y; and 1 if x > y.
BTW, I still prefer the Spin1 glyphs to their three-letter equivalents in Spin2. Although I would've preferred ~> and <~ for rotate and -> for sign-extended shift, they're too well established in Spin1 to change.
Also, I'm a little concerned about the pseudo-function notations for ROTXY, etc. Since Spin is call-by-value, a functional notation that entails call-by-reference could lead to confusion. Would it be hard to implement vector assignments?
"x <=> y" returns -1 if x < y; 0, if x == y; and 1 if x > y.
BTW, I still prefer the Spin1 glyphs to their three-letter equivalents in Spin2. Although I would've preferred ~> and <~ for rotate and -> for sign-extended shift, they're too well established in Spin1 to change.
Also, I'm a little concerned about the pseudo-function notations for ROTXY, etc. Since Spin is call-by-value, a functional notation that entails call-by-reference could lead to confusion. Would it be hard to implement vector assignments?
(x2, y2) := ROTXY(x, y, t)
In a scalar context, you could still do
x2 := ROTXY(x, y, t)[0]
-Phil
I'll add <=>. Good idea.
I like the glyphs, too. Yours even better, but I'll keep what we have for now.
We could do vector assignments. This is where checking becomes a lot of pain and something like FORTH, where there is no checking, would be a dream. Having functions with parameters looks sensible, and the compiler can catch number-of-arguments errors, but it really complicates things. I would love to find a way around that. A compiler without all the checking would be so fun to write.
IMHO, there is no reason that SPIN2 could not serve both SPIN1 users and new users alike.
Just do SPIN2 as an upgrade to SPIN1.
Later, a new top level syntax (and compiler or compiler option) could be done that is more 'BASIC' like. Why BASIC? Well you will have C/C++, so why not?
Anyway, these options are all syntaxes, provided you have the underlying support in the SPIN2 interpreter.
Chip,
Why is SWAP(X, Y) using that syntax instead of X SWAP Y ? You already have several other X <word> Y operators, why not just have SWAP be one too?
I agree with Phil on the ROTXY (and others). I think "X2, Y2 := ROTXY(X, Y, T)" is better than "ROTXY(X, Y, T : X2, Y2)". That or maybe "ROTXY(X, Y, T) : X2, Y2" instead?
Also, I think you should allow the ~>, <~, and -> for the rotates and signed shift along with the new syntax.
Chip,
Why is SWAP(X, Y) using that syntax instead of X SWAP Y ? You already have several other X <word> Y operators, why not just have SWAP be one too?
I agree with Phil on the ROTXY (and others). I think "X2, Y2 := ROTXY(X, Y, T)" is better than "ROTXY(X, Y, T : X2, Y2)". That or maybe "ROTXY(X, Y, T) : X2, Y2" instead?
Also, I think you should allow the ~>, <~, and -> for the rotates and signed shift along with the new syntax.
Can you picture getting rid of parameter counting, somehow? That would be a really big win. It would also make function pointers a lot simpler.
I've been wondering whether the Spin1 interpreter would actually run almost as-is on the P2. Ie if you dropped the Spin1 Interpreter source into Pnut, what would need to be tweaked for it to run?
I know the P2 didn't set out to be P1 compatible but I think a lot of the P1 core assembler mnemonics are pretty compatible with P2.
I looked at this briefly about a year ago. My hazy memory is ABSNEG might be an issue, and Waitvid/waitpne etc of course. But we have the LUT area to break out small routines where necessary
I know Spin2 is going to be super. But perhaps this might provide some backward compatibility. What would the issues be?
Comments
Except that on this processor applying both upper and lower limits is a concatenation of two operations.
A pity if is deprecated for the OBEX. I'd say that doing it in Courier is good enough for the forum given the font restrictions, but Parallax font is excellent as it was developed with that in mind.
Harvesting Spin1 code will require rework of many elements. I would think that if a tool were developed for such a task it would need to flag many language and architecture elements that will require attention. MIN and MAX will require that regardless of any operand order restrictions.
Regards,
Anthony.
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 Pre-xoro32, iterate x and return pseudo-random ++ (post) x++ x++ var postfix 1 Post-increment -- (post) x-- x-- var postfix 1 Post-decrement !! (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 ENCOD ENCOD x ENCOD= x unary 2 Encode MSB, 31..0 DECOD DECOD x DECOD= x unary 2 Decode, 1 << (x & $1F) ONES ONES x ONES= x unary 2 Count ones SQRT SQRT x SQRT= x unary 2 Square root of unsigned x LOG LOG x LOG= x unary 2 Unsigned to logarithm EXP EXP x EXP= x unary 2 Logarithm to unsigned >> x >> y x >>= y binary 3, 16 Shift right, insert 0's << x << y x <<= y binary 3, 16 Shift left SAR x SAR y x SAR= y binary 3, 16 Shift right, insert MSB's 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 ZEROX x ZEROX y x ZEROX= y binary 3, 16 Zero-extend above bit y 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 Signed multiply / x / y x /= y binary 7, 16 Signed divide, return quotient REM x REM y x REM= y binary 7, 16 Signed divide, return remainder SCA x SCA y x SCA= y binary 7, 16 Unsigned scale (x * y) >> 32 SCAS x SCAS y x SCAS= y binary 7, 16 Signed scale (x * y) >> 30 FRAC x FRAC y x FRAC= y binary 7, 16 Unsigned fraction {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, signed !> x !> y x !>= y binary 9, 16 Ensure x <= y, signed < x < y equality 10 Signed less than (returns 0 or -1) <= x <= y equality 10 Signed less than or equal (returns 0 or -1) == x == y equality 10 Equal (returns 0 or -1) <> x <> y equality 10 Not equal (returns 0 or -1) >= x >= y equality 10 Signed greater than or equal (returns 0 or -1) > x > y equality 10 Signed 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 ternary 15 Choose between y and z := x := y x := y assign 16 Set x to y Math procedures --------------------------------------------------------------------------------------------- ROTXY(x,y,t : x2,y2) Rotate cartesian (x,y) by t and write to variables (x2,y2) XYPOL(x,y : r,t) Convert cartesian (x,y) to polar and write to variables (r,t) POLXY(r,t : x,y) Convert polar (r,t) to cartesian and write to variables (x,y) SWAP(x,y) Swap variables x and ySince MIN and MAX are such charged words, I went back to !< and !> for the range-limiting operators.
I also changed MOD to REM, since MOD is not exactly remainder.
I tried keep textual operator names close to the assembler mnemonics' names. REV does a little more in Spin2 and SCA/SCAS deal with 64-bit results, not 32-bit results.
New are the "?" XORO32 operator, along with ZEROX, ONES, and SCA/SCAS.
Yes, and the interpreter code's already written for that. I'll be back into that soon, hopefully.
Hi Chip,
Regarding Type="equality", maybe the word you were looking for is "relational".
The relational operators are always binary, of course.
Nevermind. I neglected to scroll down. D'oh!
-Phil
Phil, you are right in your concern. There is a syntactic conflict there. I will change the "?" to "??" for the XORO32 operator.
EDIT: Contextually, it looks like maybe there is no conflict, after all, but I'm still changing the XORO32 operator to "??".
Also, why did you rename // to REM?
I like "//" better. I remember people saying that "//" is nowadays commonly used to begin comments, so there was pressure to not use it. You know, I like "//" better, along with the old "#>" and "<#". I would like to change all three back. Any issues, anyone? Sorry for all the vacillation.
For operators, I think you have two choices, either switch completely to something more standard (the C/C++ one is used by a great deal of other languages), or stick with the oddball Spin1 set.
A lot of people here will prefer the Spin1 operators, but most of the world will understand standard operators more.
So the question is, are you trying to make Spin2 for existing Spin1 users, or for the masses?
I think that P2 will have C/C++ (and other standard languages) for the masses, so I think Spin2 should probably aim for the Spin1 users. So You should stick with the existing Spin1 operators as much as possible (except for special cases like ?). That will make going from Spin1 to Spin2 easier for most. I think in general, Spin2 should try to be a superset of Spin1, except of course where the underlying hardware makes that impractical.
Edit: this may be different than what I have said in the past. It's what I think would be best now. Especially since it looks like we'll have decent C/C++ from the get go.
No issues with a return to originals here.
Surely any language should target the masses, otherwise it risks culture shock/aversion, and forever being niche.
Spin1 is already niche, and Spin2 that targets 'ex Spin 1 users' has an even smaller catchment,
Forth is terse because it has to be, but there is no excuse to design a compiled language to be less readable.
That's why '//' as an operator, when pretty much everyone else sees 'comment' (including many editors) is clearly nuts.
Limiting the catchment of P2, automatically limits the sales.
Where exactly is this 'decent C/C++', it needs to be in late testing right now, if anyone is going to claim 'from the get go' ?
Spin fundamentally is different enough to put off most people that want C/C++ or other standard languages. It's a language that is highly intertwined with the hardware capabilities of the chip. I think Parallax needs to cater to both existing users and try to expand to the masses. I don't think Spin2 is the path to the masses. The initial customers of the P2 are going to be existing P1 users, and alienating them takes away a potential jump start for the P2. I think it's much better to target having Spin2 be attractive to existing customers, and at the same time have a decent C/C++ option for new customers.
As for C/C++, the P2 lends itself to being a C/C++ target much better than P1. People like Dave Hein already have stuff working to some levels. Ken has stated in the past that he want's it from the start, and I think he will take the steps to make that happen as best as he can, given all the variables.
I think you are being silly when you say it should already be in late testing right now, since we won't even have first samples until July, and the design only just really locked down. I think it's quite reasonable to think that we'll have at least propgcc up and running for P2, if not more than that by the time full production rolls around in the early fall.
It all depends on WHO you target.
If I was doing this, I would chase the larger slice of the pie, every time, and that means looking out to wider industry, and the huge number of potential users. (rather than looking back in time, to what is a shrinking user base)
Key point:
You want any curious new user to glance at a web-example, nicely highlighted using standard highlighters, and think
'yeah, I could modify that to do what I need'.
It's the same as the classic 'elevator pitch' - someone only has a very short attention span, and if the language looks too strange, they
will simply move on.
It should be simple enough to make a Spin1 to Spin2 script, that takes any Spin1 code and outputs Spin2.
That just requires a unique equivalent operator in both languages, and that Spin2 is a comfortable superset of Spin1.
I think both of those are true (or can be true).
That script covers those still actively using Spin1, who also want to start new designs in Spin2.
I'm also not sure why the need to squash things into cryptic glyphs, when humans are more used to reading words ?
Storage is cheap, and editors are well able to highlight keywords.
I do believe that the purported inability of programmers to adapt to a non-traditional language is way overstated.
-Phil
-Phil
Currently:
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 Pre-xoro32, iterate x and return pseudo-random ++ (post) x++ x++ var postfix 1 Post-increment -- (post) x-- x-- var postfix 1 Post-decrement !! (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 ENCOD ENCOD x ENCOD= x unary 2 Encode MSB, 31..0 DECOD DECOD x DECOD= x unary 2 Decode, 1 << (x & $1F) ONES ONES x ONES= x unary 2 Count ones SQRT SQRT x SQRT= x unary 2 Square root of unsigned x LOG LOG x LOG= x unary 2 Unsigned to logarithm EXP EXP x EXP= x unary 2 Logarithm to unsigned >> x >> y x >>= y binary 3, 16 Shift right, insert 0's << x << y x <<= y binary 3, 16 Shift left SAR x SAR y x SAR= y binary 3, 16 Shift right, insert MSB's 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 ZEROX x ZEROX y x ZEROX= y binary 3, 16 Zero-extend above bit y 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 Signed multiply / x / y x /= y binary 7, 16 Signed divide, return quotient // x // y x //= y binary 7, 16 Signed divide, return remainder SCA x SCA y x SCA= y binary 7, 16 Unsigned scale (x * y) >> 32 SCAS x SCAS y x SCAS= y binary 7, 16 Signed scale (x * y) >> 30 FRAC x FRAC y x FRAC= y binary 7, 16 Unsigned fraction {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, signed <# x <# y x <#= y binary 9, 16 Ensure x <= y, signed < x < y relational 10 Signed less than (returns 0 or -1) <= x <= y relational 10 Signed less than or equal (returns 0 or -1) == x == y relational 10 Equal (returns 0 or -1) <> x <> y relational 10 Not equal (returns 0 or -1) >= x >= y relational 10 Signed greater than or equal (returns 0 or -1) > x > y relational 10 Signed 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 ternary 15 Choose between y and z := x := y x := y assign 16 Set x to y Math procedures --------------------------------------------------------------------------------------------- ROTXY(x,y,t : x2,y2) Rotate cartesian (x,y) by t and write to variables (x2,y2) XYPOL(x,y : r,t) Convert cartesian (x,y) to polar and write to variables (r,t) POLXY(r,t : x,y) Convert polar (r,t) to cartesian and write to variables (x,y) SWAP(x,y) Swap variables x and yExotic? Yep/just a bit of techno_lust for the crusties out there.
Spin2 should inspire craven behavior at the machine level. Circles within circles... spirals of all kinds.
(And I'm still sober:)
GO CHIP!!!
Remember, it is not only programmers themselves, that make commercial decisions, but often the PHM get into the mix to.
Often, a new chip gets a leg in the door solving some one-off / small volume problem, and then the programmers get confident to use it in volumes, and those volumes are what Parallax & P2 need.
"x <=> y" returns -1 if x < y; 0, if x == y; and 1 if x > y.
BTW, I still prefer the Spin1 glyphs to their three-letter equivalents in Spin2. Although I would've preferred ~> and <~ for rotate and -> for sign-extended shift, they're too well established in Spin1 to change.
Also, I'm a little concerned about the pseudo-function notations for ROTXY, etc. Since Spin is call-by-value, a functional notation that entails call-by-reference could lead to confusion. Would it be hard to implement vector assignments?
(x2, y2) := ROTXY(x, y, t)
In a scalar context, you could still do
x2 := ROTXY(x, y, t)[0]
-Phil
I'll add <=>. Good idea.
I like the glyphs, too. Yours even better, but I'll keep what we have for now.
We could do vector assignments. This is where checking becomes a lot of pain and something like FORTH, where there is no checking, would be a dream. Having functions with parameters looks sensible, and the compiler can catch number-of-arguments errors, but it really complicates things. I would love to find a way around that. A compiler without all the checking would be so fun to write.
Just do SPIN2 as an upgrade to SPIN1.
Later, a new top level syntax (and compiler or compiler option) could be done that is more 'BASIC' like. Why BASIC? Well you will have C/C++, so why not?
Anyway, these options are all syntaxes, provided you have the underlying support in the SPIN2 interpreter.
Why is SWAP(X, Y) using that syntax instead of X SWAP Y ? You already have several other X <word> Y operators, why not just have SWAP be one too?
I agree with Phil on the ROTXY (and others). I think "X2, Y2 := ROTXY(X, Y, T)" is better than "ROTXY(X, Y, T : X2, Y2)". That or maybe "ROTXY(X, Y, T) : X2, Y2" instead?
Also, I think you should allow the ~>, <~, and -> for the rotates and signed shift along with the new syntax.
Surely the number 1 requirement of Spin 2 is that it is backwards compatible with Spin 1? No matter what new features Spin 2 may have.
Why alienate those who have taken the trouble to learn Spin, by tweaking the operators or higher level syntax/semantics?
Ideally this backwards compatibility would extend to PASM as well, but I guess that might be harder to pull off.
What C/C++/C#/Java/Javascript/whatever does is neither here nor there in the Spin world.
Can you picture getting rid of parameter counting, somehow? That would be a really big win. It would also make function pointers a lot simpler.
I know the P2 didn't set out to be P1 compatible but I think a lot of the P1 core assembler mnemonics are pretty compatible with P2.
I looked at this briefly about a year ago. My hazy memory is ABSNEG might be an issue, and Waitvid/waitpne etc of course. But we have the LUT area to break out small routines where necessary
I know Spin2 is going to be super. But perhaps this might provide some backward compatibility. What would the issues be?
-Phil