What is Spin2?
David Betz
Posts: 14,516
in Propeller 2
What is Spin2? Is it a version of Spin for the P2 or is it just a revision of Spin that will be available for either P1 or P2? Parallax will soon (I hope!) have two versions of the Propeller. I'm wondering if people will have to learn two subtly different languages if they hope to program both P1 and P2. Also, some of the changes that are being proposed for Spin2 would be equally welcome when programming the P1. Are P2 and Spin2 linked or is each separately an evolution of its predecessor?
Comments
And simply, parallax just included a directive to tell the compiler what was what.
I didn't even know spin2 was a thing...
Considering the p2 is not a simple dip capable platform, it changes the accessibility to many. (1.5v and 3.3v)
The biggest thing I am seeing here with parallax, is they aren't offering many variants of the P1, like they did with the stamp and the sx.
I think they should make many variants of the P1, because it means the platform stays accessible in a dip...
This would allow the p2 features to be backward engineered into a p1 variant that has a different hardware config than the p1, thus needing a spin2 language to work.
Hack the p2 up into many p1 variants when its done, and put it all under a spin2 language standard.
That would then align with the history of parallax's profit model, which HAS been successful.
I suppose it could be made to work on the Prop1, but it's maybe not worth the effort.
If that is the target, (ie people who want to use both ), then best call it "Spin1 for P2", rather than Spin2, and include a P1 code generator and conditionals, so ONE SOURCE really can run on P1 or P2.
Now it can be called Spin1 for P2 and P1, from a single executable.
The conditionals are used for handling those Timer/Counter/PASM areas, where P2 silicon is not actually anything like P1.
Anything less risks falling between two stools - it fails to be a (single) language that can actually be used for both.
Also, don't start with a compiler written in x86 assembly language. Have Roy work with Chip to create Spin2 in C++ from the start. Why go through the extra step of having Chip write in x86 code and Roy translate that to C++? Chip should just stick with language design and let Roy do the implementation.
I made that kind of mistake once... biggest mistake of my life. I would encourage Chip to not do this.
What happens when Roy gets sick or decides he isn't happy with Parallax?
As a product owner, you have to absolutely be the master of your own product.
...or the future is whatever happens next, not what you plan.
If that means using an old assembly language that you know like the back of your hand... so what?
I consider Spin1 to be a macro language, closely tied to the functionality of the P1.
I expect Spin2 to be similar but better because of more experience and a fabulous target.
About the syntax... there is an issue. If the exact same syntax in Spin2 has a different meaning in Spin1... it will
cause a problem... so that syntax will have to be warned... which sounds painful for everyone.
Anything else will be flagged by the compiler and after seeing it a couple of times, you will
stop doing it.
Someone else takes over the C++ code? If it's open source from the start then that won't be a problem. And C++, while sometimes ugly, is generally a lot easier to maintain than x86 assembly.
All of this makes a lot of sense to me. Changing the syntax means making people learn yet another language, and write yet another set of tools (e.g. syntax highlighters for editors).
I don't know that it will be open sourced from the start. Seems to me that we are at the start and I haven't seen any
'86 assembly floating around.
OK... so you find another C++ programmer, maybe have a couple sitting around, given jobs they think are important.
Just to be safe.... $500,000 per year... just to be safe.
I have to admit that since Apple dropped Pascal without notice to me, I have hated all computer languages.
Maybe a bit of an over-reaction on my part(sort of a prejudice)...just stating the fact.
It seems to me that modernity in C might come with a bit of overhead?
When we are counting clocks, down to the clock... doesn't all of that overhead have any impact?
That is an honest question, I really don't know.
Thanks
?? I think David was NOT meaning 'hand ownership over', he was meaning "get someone who knows what they are doing, to quickly make a framework that can be improved.."
Ownership is never 3rd-party-only.
Yes, if your primary focus is to cover both P1 and P2 bases here, a single compiler (& simulator?) that can emit both P2 and P1 code seems the only way.
Two separate tool flows will always diverge in the parser details... creating many nasty bugs where code compiles without errors, but is not quite the same...
Yikes, I was assuming x86 was well off the table by now. Surely Chip is not still coding in that ?
Sorry
I should have used a different word... "you have to know it better than anyone else." There can't be any black holes.
"Yikes, I was assuming x86 was well off the table by now. Surely Chip is not still coding in that ?"
You need to pay more attention:)
absolutely kidding.
Yes he does.
Mike
Honestly, I don't have the time available in order to have it work where I implement Chip's design, bypassing the x86 step. For things to work that way I'd basically need to work almost full time with Chip. However, I intend to get updates as Chip goes, and incrementally update OpenSpin with the changes. It's also possible that after a certain point new things would just be done in OpenSpin instead of x86. In any case, I think it's very likely we will have OpenSpin for Spin2 available (and used as the main compiler) from the start. It may be that someone else here can jump in and help? That's kind of up to Chip/Ken/etc.
However, they still aren't using OpenSpin as the "official" compiler for P1. I did a bunch of changes so that we could integrate it into PropTool, but Jeff Martin hasn't had time (or priority) for it. Which is fine, we should drop PropTool anyway, since it's windows only. Last I saw Propeller IDE was using bstc by default (but you could switch it to OpenSpin (A variant Brett made of it anyway)), and that seems to be stagnant now too. All the focus seems to be on Blockly, which targets C.
If Roy says he can post it in a reasonable time, great!
I, for one, want Chip to apply the tools to this SPIN + PASM iteration the same way it was done before.
The product, on P1, is great. I would expect nothing less this time.
Let @Chip get Spin2 and Pasm2 meld together. I am very sure that someone will build a P1-emulator for the P2 or one just uses Spin2cpp and output for P2.
The stamps had also different languages, somehow, but programmers adapted to this quite easy. Same will go for people used to Spin with Spin2 and those not used too, will find a lot of similarities.
Let Spin2 be Spin2 not Spin++ BUT wee need C/C++ so how to get GCC or CLANG development running again?
I love the way Spin2 is forming and @Chip may even enjoy this part of his work more then we think. Thankfully Spin2 will not be in the ROM so it will not delay anything. @Chip is out of the fire line and can relax while doing it.
perfect.
Mike
??? This one totally seems like a non-sequitor. I wasn't proposing hiring people in advance just in case you need them. I was just pointing out that if for some reason Roy (or whoever was working with Chip) was not able to continue, that then you could hire someone else to work on the code. Roy's openspin code is nice code. He's definitely the first choice for extending it, but if he's not available someone else could do the job. Heck, Chip can write Verilog, so he could write C code!
x86 assembly code, on the other hand, is *much* harder for another programmer to pick up and maintain.
However, I still like the idea of a Spin2 that can target either P1 or P2. That makes it much more reasonable to change the Spin syntax a bit for Spin2. A programmer who wants to use both P1 and P2 can just migrate to Spin2 and not have to keep track of which operators work in which version of Spin. I assume that Parallax wants to continue to support both P1 and P2 going forward. I believe they've already promised that P1 will continue to be available far after P2 is launched.
I have wanted that since first getting involved. I think We should plan to make Spin2 have the ability to target P1 and P2. Obviously, the PASM inside of it will be specific to the target chip, and any other chip specific features in the Spin side of things would be different depending on the target, but all the syntax, operators, etc. should be able to be the same on both. Any new stuff that can't be made to work using the existing P1 bytecode are just not there for that target.
Chip,
Yes, we should plan on this. I for one intend to continue using P1 along side P2, and my coding experiences would be much better if I had all the new Spin features that can work on P1 available there.
Agreed, This will be important to any 'Spin Eco system' - a old and frozen language does not appeal to managers approving design directions.
I think that 'maybe..eventually' focus is quite wrong, as Roy says (and does already in his flow) New Spin should emit for BOTH P1 and P2, from the start.
Some conditional defines around Timer/PASM blocks, and you should be able to have single source file, that compiles/runs on either P1/P2.
Where to spend time? I suppose I could spend the rest of my life making sure that one Spin file compiles for both Prop1 and Prop2.
Yup, tool vendors merely need to give designers the tool-flows, and control - the designers will decide themselves where to place the effort.
We have had single-source-file target more than one MCU here, sure, it's not common, but is useful, especially around libraries.
This sort of thing "demos well" to potential customers, as they can see a 'family effort' being put in by the vendor. Buyers like to know there is a step up, or down, from where they are.