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

Spin2 Operator Syntax

11213141618

Comments

  • Heater.Heater. Posts: 21,230
    Ariba,
    ..much greater than..
    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 ">>>".

    :)
  • Tor wrote: »
    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.
    jmg wrote: »
    AJL wrote: »
    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.
    jmg wrote: »
    AJL wrote: »
    jmg wrote: »
    Err, has everyone fully grasped this new !< !> syntax now imposes restrictions on the operator order ?
    That restriction was not there on the old syntax.
    AJL wrote: »
    ... 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.

    Regards,
    Anthony.
  • cgraceycgracey Posts: 14,133
    edited 2018-01-17 16:53
    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.
  • What did you end up deciding about object pointers or references? Will they be included in Spin2?
  • cgraceycgracey Posts: 14,133
    David Betz wrote: »
    What did you end up deciding about object pointers or references? Will they be included in Spin2?

    Yes, and the interpreter code's already written for that. I'll be back into that soon, hopefully.
  • cgracey wrote: »
    David Betz wrote: »
    What did you end up deciding about object pointers or references? Will they be included in Spin2?

    Yes, and the interpreter code's already written for that. I'll be back into that soon, hopefully.
    Nice!

  • cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    Ah, I was looking for that word, but did not realize it. Thanks. I will change the document.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-01-17 20:04
    If "?" is being used as a random operator, how are you planning to signify the trinary operator? It's usually denoted x ? y : z.

    Nevermind. I neglected to scroll down. D'oh!

    -Phil
  • cgraceycgracey Posts: 14,133
    edited 2018-01-17 20:20
    If "?" is being used as a random operator, how are you planning to signify the trinary operator? It's usually denoted x ? y : z.

    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 "??".
  • ElectrodudeElectrodude Posts: 1,614
    edited 2018-01-17 20:20
    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?
  • cgraceycgracey Posts: 14,133
    edited 2018-01-17 20:24
    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.
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2018-01-17 20:50
    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.
  • I second Roy. Make it lean, mean. Target existing developers.

    No issues with a return to originals here.

  • jmgjmg Posts: 15,140
    Roy Eltham wrote: »
    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.
    Roy Eltham wrote: »
    Especially since it looks like we'll have decent C/C++ from the get go.

    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' ?

  • 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.

  • jmgjmg Posts: 15,140
    edited 2018-01-17 21:29
    cgracey wrote: »
    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.


  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-01-17 22:08
    cgracey wrote:
    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
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-01-17 22:17
    cgracey wrote:
    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.

    -Phil
  • cgraceycgracey Posts: 14,133
    cgracey wrote:
    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
    

  • rjo__rjo__ Posts: 2,114
    I think C/C++ is a foregone conclusion. There is no further need to pander to Spin deniers.

    Exotic? 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!!!














  • jmgjmg Posts: 15,140
    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.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-01-17 22:44
    Might I suggest another operator?

    "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
  • cgraceycgracey Posts: 14,133
    Might I suggest another operator?

    "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.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • Heater.Heater. Posts: 21,230
    Am I missing a point here?

    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.


  • cgraceycgracey Posts: 14,133
    Roy Eltham wrote: »
    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?
  • I like x :=: y for SWAP, with the scalar expression returning the new value of x.

    -Phil
Sign In or Register to comment.