That's the impact of it. I know you don't mean that jmg.
Chip is making one unified thjng, lean, mean, etc... That really needs to exist. Tons of P1 users are expecting it. Not a darn thing wrong with anything being done so far.
As for a mode switch, let those who want one, do it once this all gets done.
That can all compete. No reason to complicate, delay and clutter now.
That's the impact of it. I know you don't mean that jmg.
Actually, the 'impact' is quite the opposite: Anyone who has a real investment in Spin, would embrace features that make it easier to maintain.
Other languages evolve, usually to make them easier to maintain and/or add features - Spin is no different.
Evolution is not always a good thing. You really should ask around on this.
SPIN is getting some new features this go around. All welcome. What worked well the first time around does not need to change. It's all lean and potent.
There are a lot of people, myself included, who want and will value a "core" SPIN that is complete and effective. Same as P1. Once that learning is done, library code, snippets, templates complete, it's nice and productive.
Stays that way without requiring ongoing investment.
This set of integrated tools will be all a lot of people need or want. Offering that value proposition is just as valid as other ones being proposed.
When they end up self hosted, it's going to be very nice. And, on that front, keeping it lean and mean as is being done, matters. Things get built on that once, and they are largely done.
Again, worth having. Once a C port gets done, that track can do all sorts of things. That is worth it too.
Spin *should be* no different (IE, it should be able to evolve), and it's already getting a bunch of new stuff for P2, and won't be backward compatible anyway.
I've always hated the <=, >=, =>, =<, >>=, <<= operators in Spin because I code C/C++ by day, and the overlap (but different meanings) of those is maddening.
<<= and >>= should be arithmetic shifts (left always is anyway), and ~>= should be an unsigned (logical) shift.
I've been bitten before by "if( a<-5 )" because <- is an operator, and takes precedence over negation. You need the space, but only in Spin.
<>= is Spin's version of != in C. != doesn't exist in Spin as another operator, so not sure why that was left out, particularly given that !(unary) is the NOT operator.
I would honestly have less of an issue with it if there wasn't so much overlap of the operators. It's as though it was meant to be identical to C/C++ except in a couple specific cases (like ~, !, <, >, <<, >>). Nearly all other operators are the same. C, Java, C#, and Python all use basically identical operators too, and I use all of those regularly, so having *one* language that uses the same syntax but with different meanings can be maddening.
The spin operators trip me up all the time and it's maddening. They need to be made standard for all the ones that overlap with every other language. There can be extras, but anything that is "standard" from C/C++, C#, Java, Python, and every other language in existence except Spin, should be made to be the same as the standard ones.
I would add that if you care at all about adoption, making something that directly conflicts with existing standards without having a DAMN good reason is going to work against you. It's incredibly frustrating when the code you're reading is correct for all other languages you're fluent in *except* Spin. It's friction that isn't necessary.
Evolution is not always a good thing. You really should ask around on this.
I'm not sure who I would ask about that or what exactly the question would be.
Evolution does not care about good and bad. It happens anyway. If a species does not change it's environment will. 99.9999...% of evolutionary steps are failures. We happy alive creatures had a vanishingly small chance of making it this far!
Anyway, when it comes to Spin. We have to face the fact that almost nothing anyone ever wrote in Spin will work on the P2 without a lot of work.
Why? Because Spin includes PASM and the instruction set has totally evolved.
Or am I missing a point. Is it so that old PASM code will run as is on the P2? Give or take some timing differences?
Changing to operators changes the language totally. Might as well add curly braces for block delimiting!
I think what I am getting at is that my Z80 emulator, or PullMoll's emulator, which have no critical timing or I/O needs but are written mostly in PASM for speed should be usable on the P2 without a massive lot of work.
I would add that if you care at all about adoption, making something that directly conflicts with existing standards without having a DAMN good reason is going to work against you. It's incredibly frustrating when the code you're reading is correct for all other languages you're fluent in *except* Spin. It's friction that isn't necessary.
Changing to operators changes the language totally. Might as well add curly braces for block delimiting!
I think what I am getting at is that my Z80 emulator, or PullMoll's emulator, which have no critical timing or I/O needs but are written mostly in PASM for speed should be usable on the P2 without a massive lot of work.
Or my Fast Fourier Transform for example.
Ha, @Heater, I didn't want to go there after you stated 'no more emulator'
But since Pullmoll is missing in action you are the only one who can get CPM running on the P2.
Why should Spin operators be changed to attract users of other processors? Why wouldn't those users just use C which will be just like what they use everywhere else. It isn't just Spin operators that are different. It's an entirely different language. If Parallax supports C on the P2 then I don't see a need to make Spin more C-like. I'd prefer it to be a strict superset of P1 Spin aside from the necessary differences in PASM.
I side with not changing the Spin operators. I think it is more important to make the syntax of Spin2 as close to Spin1 as possible, rather than making Spin2 more like C. I think Spin1 syntax should be a subset of Spin2. This will make it easier to port existing Spin1 code to the P2.
It isn't just Spin operators that are different. It's an entirely different language.
Sure, but it is when those operators conflict with wide standards, that the time is lost.
The business of selling silicon is a simple 'bums on seats' game, designers have many choices, do not annoy, or alienate them, if you want them as customers.
It isn't just Spin operators that are different. It's an entirely different language.
Sure, but it is when those operators conflict with wide standards, that the time is lost.
The business of selling silicon is a simple 'bums on seats' game, designers have many choices, do not annoy, or alienate them, if you want them as customers.
I seriously doubt that anyone will reject P2 because the Spin operators aren't more like C. They are more likely to reject it because it doesn't support C itself. If they are open minded enough to consider a new language like Spin I suspect they'll be willing to accept its differences from other languages. And changing the operators between Spin1 and Spin2 will just make life harder for Spin1 programmers attempting to adopt Spin2. I don't like that the operators break from common practice either but I think it's probably better to leave them as they are for P2.
.... I don't like that the operators break from common practice either but I think it's probably better to leave them as they are for P2.
Then we are actually in agreement.
Notice I have never said to remove the old operators entirely, just add a mode switch/pragma that allows user choice between 'legacy' and 'sensible' syntax forms. Other tool chains already do this.
Spin is likely to exist quite a while before P2 gets a C/C++ compiler, and quite a long while before that compiler gets to the maturity level that PropGcc is now. (I'd love to be wrong here, btw).
P1 has failed to get a foothold as a "serious" chip, at least in part because of Spin being a proprietary language, and until relatively late in its existence, the only decent/stable/supported choice. Their loss, sure, but also Parallax's.
Will I live with it? Sure. Will I recommend it to others? Of course. Will they use it? That's the important one. If the level of friction is too high, no. They won't. P2 already has numerous advantages over P1, like speed, hardware debugging, more RAM, more cores, and more everything else, so it seems a shame to saddle it with the same baggage.
Mode switch isn't a bad idea, but it causes problems for things like Obex code. If I publish code that expects the switch enabled, that's bad - it'll cause as much confusion as it'll cure. Change them or don't. I can deal either way, it's just one of those things that has always driven me bat$h!t crazy.
Mode switch isn't a bad idea, but it causes problems for things like Obex code. If I publish code that expects the switch enabled, that's bad
Not if the mode switch is a source pragma (as it is in many tools).
The setting is defined in the source, there are no "expects the switch enabled" problems...
Most of what we are talking about needing to change is the oddball assignment stuff.
Most of them are never used (judging by the pile of obex spin files, I had to make my own tests for all the assignment variants). Things like >= and <= are so odd. It's do a comparison operation then assign the result of the compare to the left. Who does that ever?
Also, we can just add != to mean not equal (<>). By the way, <>= is an assignment (perform the not equal comparison and assign to the left operand). Really it boils down to just removing a couple of the assignment operators and making them just be the comparison equivalent.
I think half the people here arguing about them don't even know what half the operators are, or what they do. =<= and =>= are legal Spin assignment operations. === is too (perform comparison operation ==, then assign the result to the left). You can do AND= and OR= too (they are assignments). I'd venture to say that half of the operators in Spin are never used, and not even known to even expert Spin coders. I know about them because of making and testing OpenSpin.
Whenever explaining Spin operators to people you always have to explain these oddball differences, and it's just silly. If you always have to explain something because of something no one even uses, then you have a fundamental problem and it should be fixed.
Will I live with it? Sure. Will I recommend it to others? Of course. Will they use it? That's the important one. If the level of friction is too high, no. They won't.
Agreed. Sometimes that choice is made by managers, not programmers.
P2 already has numerous advantages over P1, like speed, hardware debugging, more RAM, more cores, and more everything else, so it seems a shame to saddle it with the same baggage.
..and keep in mind, most evaluating P2, will not be looking at P1, but at the myriad of choices out there for a similar price.
eg I see NXP now has 1MByte RAM and 2 MByte of Flash in their K28 series MCUs, so P2 is going to be looking 'small' when it finally does ship.
Changing to operators changes the language totally. Might as well add curly braces for block delimiting!
I think what I am getting at is that my Z80 emulator, or PullMoll's emulator, which have no critical timing or I/O needs but are written mostly in PASM for speed should be usable on the P2 without a massive lot of work.
Or my Fast Fourier Transform for example.
The basic PASM operators are the same in P2, except thay have different binary opcodes. There is no "NR" so that will require a fix.
JMPRET (JMP/CALL/RET) is different so we will just have to look at that one. Not sure about its implication.
So, I don't really think there will be much work other than to recompile.
Of course there will be a lot of optimisation that can be done later
Why can't we have both old and new, using a declaration option?
A lot of P1 Spin will just recompile as is. It would be a pity to change that.
For newer spin, why not call it "SPINC" or "SPIN++" using the more standard C/C++ operators?
It just becomes a compiler option. And, it would be better if this could also work back on P1.
But none of this matters for getting P2 silicon. This can, and should be, a new thread.
FWIW this new bytecode interpreter is going to fly compared to Spin on P1.
Therefore, it may make sense to use it as a small/simple C/C++ compiler output, Basic, Python, Forth, etc, etc.
FWIW this new bytecode interpreter is going to fly compared to Spin on P1.
Therefore, it may make sense to use it as a small/simple C/C++ compiler output, Basic, Python, Forth, etc, etc.
If the bytecode engine can be made good enough to manage a CIL version, then a great many languages come for free
FWIW this new bytecode interpreter is going to fly compared to Spin on P1.
Therefore, it may make sense to use it as a small/simple C/C++ compiler output, Basic, Python, Forth, etc, etc.
I had thought of that as well. We have CMM mode in PropGcc largely because the PNut interpreter has a lot of Spin-centric things that make it difficult to use as a general purpose interpreter. At the very least, the P2Gcc runtime interpreter could steal a lot of tricks from Spin2, but it'd be *really* cool if it could just target those opcodes directly. It would mean the possibility of compiled P2Gcc code and Spin2 code being able to share data structures, calling one another's functions, etc. There'd be limits of course, but the same is true of calling C functions from C# or Python on a PC.
....
Check out these equality operators. 70% code size reduction:
op_binary0 setq #2-1 'pop a b c d e f a: <
rdlong x,ptra[--2] ' a b c d e f b: =<,<=
cmps x,y wc,wz ' a | c d e | c: ==
cmps y,x wc,wz ' | b | | | f d: <>
muxc x,_FFFFFFFF ' a | | | | f e: =>,>=
muxnc x,_FFFFFFFF ' | b | | e | f: >
muxz x,_FFFFFFFF ' | | c | | |
muxnz x,_FFFFFFFF ' | | | d | |
_ret_ pusha x 'push a b c d e f
This code snippet suggests that Chip has already changed the meaning of the >= and <= operators in Spin2. They are the most worse.
Comments
Let them compete.
Or, hey let's just hose everyone who has an investment in SPIN.
Chip is making one unified thjng, lean, mean, etc... That really needs to exist. Tons of P1 users are expecting it. Not a darn thing wrong with anything being done so far.
As for a mode switch, let those who want one, do it once this all gets done.
That can all compete. No reason to complicate, delay and clutter now.
Actually, the 'impact' is quite the opposite: Anyone who has a real investment in Spin, would embrace features that make it easier to maintain.
Other languages evolve, usually to make them easier to maintain and/or add features - Spin is no different.
SPIN is getting some new features this go around. All welcome. What worked well the first time around does not need to change. It's all lean and potent.
There are a lot of people, myself included, who want and will value a "core" SPIN that is complete and effective. Same as P1. Once that learning is done, library code, snippets, templates complete, it's nice and productive.
Stays that way without requiring ongoing investment.
This set of integrated tools will be all a lot of people need or want. Offering that value proposition is just as valid as other ones being proposed.
When they end up self hosted, it's going to be very nice. And, on that front, keeping it lean and mean as is being done, matters. Things get built on that once, and they are largely done.
Again, worth having. Once a C port gets done, that track can do all sorts of things. That is worth it too.
I've always hated the <=, >=, =>, =<, >>=, <<= operators in Spin because I code C/C++ by day, and the overlap (but different meanings) of those is maddening.
<<= and >>= should be arithmetic shifts (left always is anyway), and ~>= should be an unsigned (logical) shift.
I've been bitten before by "if( a<-5 )" because <- is an operator, and takes precedence over negation. You need the space, but only in Spin.
<>= is Spin's version of != in C. != doesn't exist in Spin as another operator, so not sure why that was left out, particularly given that !(unary) is the NOT operator.
I would honestly have less of an issue with it if there wasn't so much overlap of the operators. It's as though it was meant to be identical to C/C++ except in a couple specific cases (like ~, !, <, >, <<, >>). Nearly all other operators are the same. C, Java, C#, and Python all use basically identical operators too, and I use all of those regularly, so having *one* language that uses the same syntax but with different meanings can be maddening.
The spin operators trip me up all the time and it's maddening. They need to be made standard for all the ones that overlap with every other language. There can be extras, but anything that is "standard" from C/C++, C#, Java, Python, and every other language in existence except Spin, should be made to be the same as the standard ones.
Enjoy!
Mike
Evolution does not care about good and bad. It happens anyway. If a species does not change it's environment will. 99.9999...% of evolutionary steps are failures. We happy alive creatures had a vanishingly small chance of making it this far!
Anyway, when it comes to Spin. We have to face the fact that almost nothing anyone ever wrote in Spin will work on the P2 without a lot of work.
Why? Because Spin includes PASM and the instruction set has totally evolved.
Or am I missing a point. Is it so that old PASM code will run as is on the P2? Give or take some timing differences?
I think that ship has sailed. If there is anything that should be similar between P1 and P2, it is the Spin language...
Changing to operators changes the language totally. Might as well add curly braces for block delimiting!
I think what I am getting at is that my Z80 emulator, or PullMoll's emulator, which have no critical timing or I/O needs but are written mostly in PASM for speed should be usable on the P2 without a massive lot of work.
Or my Fast Fourier Transform for example.
Depends on what Parallax want to target ?
a) Existing P1 Spin users (who will not be able to actually 'just run' their P1 Spin, on P2 )
b) Users of other languages & MCUs, who may design in a P2
Those pools have many orders of magnitude different sizes.
See the example posted above, in most cases today, developers work in more than just one language.
^This is the reality.
Ha, @Heater, I didn't want to go there after you stated 'no more emulator'
But since Pullmoll is missing in action you are the only one who can get CPM running on the P2.
Without a massive lot of work, you just stated.
Enjoy!
Mike
It is not about simply attract, it is also day to day productivity. (see above posts, showing how this suffers now)
Spin will allow a byte-code language, and by all time-lines here, will exist first.
Other versions will follow, but not quickly.
Sure, but it is when those operators conflict with wide standards, that the time is lost.
The business of selling silicon is a simple 'bums on seats' game, designers have many choices, do not annoy, or alienate them, if you want them as customers.
Notice I have never said to remove the old operators entirely, just add a mode switch/pragma that allows user choice between 'legacy' and 'sensible' syntax forms. Other tool chains already do this.
P1 has failed to get a foothold as a "serious" chip, at least in part because of Spin being a proprietary language, and until relatively late in its existence, the only decent/stable/supported choice. Their loss, sure, but also Parallax's.
Will I live with it? Sure. Will I recommend it to others? Of course. Will they use it? That's the important one. If the level of friction is too high, no. They won't. P2 already has numerous advantages over P1, like speed, hardware debugging, more RAM, more cores, and more everything else, so it seems a shame to saddle it with the same baggage.
Not if the mode switch is a source pragma (as it is in many tools).
The setting is defined in the source, there are no "expects the switch enabled" problems...
Most of them are never used (judging by the pile of obex spin files, I had to make my own tests for all the assignment variants). Things like >= and <= are so odd. It's do a comparison operation then assign the result of the compare to the left. Who does that ever?
Also, we can just add != to mean not equal (<>). By the way, <>= is an assignment (perform the not equal comparison and assign to the left operand). Really it boils down to just removing a couple of the assignment operators and making them just be the comparison equivalent.
I think half the people here arguing about them don't even know what half the operators are, or what they do. =<= and =>= are legal Spin assignment operations. === is too (perform comparison operation ==, then assign the result to the left). You can do AND= and OR= too (they are assignments). I'd venture to say that half of the operators in Spin are never used, and not even known to even expert Spin coders. I know about them because of making and testing OpenSpin.
Whenever explaining Spin operators to people you always have to explain these oddball differences, and it's just silly. If you always have to explain something because of something no one even uses, then you have a fundamental problem and it should be fixed.
Agreed. Sometimes that choice is made by managers, not programmers.
..and keep in mind, most evaluating P2, will not be looking at P1, but at the myriad of choices out there for a similar price.
eg I see NXP now has 1MByte RAM and 2 MByte of Flash in their K28 series MCUs, so P2 is going to be looking 'small' when it finally does ship.
JMPRET (JMP/CALL/RET) is different so we will just have to look at that one. Not sure about its implication.
So, I don't really think there will be much work other than to recompile.
Of course there will be a lot of optimisation that can be done later
=========
Why can't we have both old and new, using a declaration option?
A lot of P1 Spin will just recompile as is. It would be a pity to change that.
For newer spin, why not call it "SPINC" or "SPIN++" using the more standard C/C++ operators?
It just becomes a compiler option. And, it would be better if this could also work back on P1.
But none of this matters for getting P2 silicon. This can, and should be, a new thread.
FWIW this new bytecode interpreter is going to fly compared to Spin on P1.
Therefore, it may make sense to use it as a small/simple C/C++ compiler output, Basic, Python, Forth, etc, etc.
If the bytecode engine can be made good enough to manage a CIL version, then a great many languages come for free
I had thought of that as well. We have CMM mode in PropGcc largely because the PNut interpreter has a lot of Spin-centric things that make it difficult to use as a general purpose interpreter. At the very least, the P2Gcc runtime interpreter could steal a lot of tricks from Spin2, but it'd be *really* cool if it could just target those opcodes directly. It would mean the possibility of compiled P2Gcc code and Spin2 code being able to share data structures, calling one another's functions, etc. There'd be limits of course, but the same is true of calling C functions from C# or Python on a PC.
This code snippet suggests that Chip has already changed the meaning of the >= and <= operators in Spin2. They are the most worse.
Andy