At this point, I'd go so far as to suggest leaving SPIN a P1-only language (for now). Focus on getting another well-known interpreted language ported. With this, I'd also simplify the structure for P2 Assembler files:
* Get rid of CON and DAT.
* add a "con" directive to define constants.
* for those few constants that are actually controlling boot configuration, make them directives as well.
* Use file extension "pasm" (assuming the P2 official name starts with "P").
I may have to agree. SPIN is a good language, except for the bytecode part. Or at least it should be possible to compile it to PASM instead, and not the Java kind of compilation.
Eric Smith (ersmith) has a way to compile Spin to PASM for P1 and is working on P2. It's a feature of his spin2cpp tool and he even has a GUI interface to it so you can examine the code it generates.
My main issue with C (done correctly) is that you have to declare all your variables and methods in advance of their use. Means the main routines wind up all the way at the bottom of the code. And, if you want to add a variable, you need to go back up to the top to do it. I just requires too much to be proper for my taste.
Also, for doing a GUI, you're going to want classes, at least I think so.
And, polymorphism is very useful sometimes.
At this point, I'd go so far as to suggest leaving SPIN a P1-only language (for now).
Oooh! I'm going to have to go get some popcorn to watch this one with!!
Hah! Actually, I don't think what I'm suggesting is that provocative. Here's why:
* It would be trivial to port the existing SPIN interpreter. However, only pure SPIN programs would likely be able to run.
* Even if you did port the existing interpreter, you would gain very little functionality. You certainly wouldn't be able to take advantage of most of the new P2 capabilities.
* Based on past discussions of what a "new" SPIN would look like, it will be a significant undertaking to develop it in time for release with the P2.
* Conversely, for a similar amount of effort, we are much more likely attract people to the P2 by adding support for one or more well-known/popular languages.
Note, also, that I suggested this approach "for now". I'm not suggesting that SPIN should never be ported to the P2, just that it should not be a priority.
At this point, I'd go so far as to suggest leaving SPIN a P1-only language (for now). Focus on getting another well-known interpreted language ported. With this, I'd also simplify the structure for P2 Assembler files:
* Get rid of CON and DAT.
* add a "con" directive to define constants.
* for those few constants that are actually controlling boot configuration, make them directives as well.
* Use file extension "pasm" (assuming the P2 official name starts with "P").
I may have to agree. SPIN is a good language, except for the bytecode part. Or at least it should be possible to compile it to PASM instead, and not the Java kind of compilation.
Eric Smith (ersmith) has a way to compile Spin to PASM for P1 and is working on P2. It's a feature of his spin2cpp tool and he even has a GUI interface to it so you can examine the code it generates.
Interesting! Does it translates Spin to C, and then compiles the C code? I'm asking this because the name "spin2cpp" suggests that. Well, at least I'm on the right track by using C (sadly, as I wanted to learn Spin, but now I don't see the purpose considering that I already know C).
My main issue with C (done correctly) is that you have to declare all your variables and methods in advance of their use. Means the main routines wind up all the way at the bottom of the code. And, if you want to add a variable, you need to go back up to the top to do it. I just requires too much to be proper for my taste.
Also, for doing a GUI, you're going to want classes, at least I think so.
I don't recall a programming language where you don't need to declare vars beforehand. Just follow the good practices (using C to make a console program is a good way, and then rinse and repeat) and you'll get used to it. C enforces good programming and discourages spaghetti code.
Eric Smith (ersmith) has a way to compile Spin to PASM for P1 and is working on P2. It's a feature of his spin2cpp tool and he even has a GUI interface to it so you can examine the code it generates.
Interesting! Does it translates Spin to C, and then compiles the C code? I'm asking this because the name "spin2cpp" suggests that. Well, at least I'm on the right track by using C (sadly, as I wanted to learn Spin, but now I don't see the purpose considering that I already know C).
Yes, it can compile Spin to either C++ or C as its name suggests. However, it can also compile Spin directly to PASM to run natively in a COG or to LMM to run from hub memory. It seems spin2cpp may need a new name! :-)
C is fine for small programs, which is really all you can do easily on P1 anyway.
But, C++ gives you things you need to do big programs in a more organized way.
Interesting! Does it translates Spin to C, and then compiles the C code? I'm asking this because the name "spin2cpp" suggests that. Well, at least I'm on the right track by using C (sadly, as I wanted to learn Spin, but now I don't see the purpose considering that I already know C).
Spin makes everything (except reusing code from other projects written in C) so much easier on the Propeller. You and everyone else should definitely learn it.
I don't recall a programming language where you don't need to declare vars beforehand. Just follow the good practices (using C to make a console program is a good way, and then rinse and repeat) and you'll get used to it. C enforces good programming and discourages spaghetti code.
You can declare anything in whatever order you like in Spin.
Note, also, that I suggested this approach "for now". I'm not suggesting that SPIN should never be ported to the P2, just that it should not be a priority.
P2 Spin should definitely be a priority, but it shouldn't be started (by Chip at least) until the P2 is done and we're just waiting for the chip fab. If I ever get around to finishing my compiler , it will be able to compile Spin on the P2, most likely to PASM but maybe also to bytecode, probably using the P2 Tachyon kernel.
>My main issue with C (done correctly) is that you have to declare all your variables and methods in advance of their use.
>Means the main routines wind up all the way at the bottom of the code.
That is done incorrectly or lazy, to have int main(void) on top you have to do function declarations,
You should put these in the .h file so your main can start on 3rd line.
Vars can be declared pretty much anywhere, if done inside a function the compiler will use a scratch register for it (efficient)
Global Vars (e.g RAM usage) on reset/boot will be set to a value or set to zero, not saying either is the same a zero.
The compiler will then sort them so all zero are in one block and all pre-valued in one, the zero is of course just a loop clearing them,
the one with values are copied from a flash block to the ram block.
...
You can declare anything in whatever order you like in Spin.
...
Enlightening and mesmerizing at the same time. I guess I'll give it a go, although I am to see if I can generate a good enough prime number generator using Spin. I can implement isqrt by using bitshifting, if Spin supports bitwise operations. The rest, I think it may have almost direct correspondence when using the C code as a basis for the Spin code. It is an interesting exercise for me.
...
P2 Spin should definitely be a priority, but it shouldn't be started (by Chip at least) until the P2 is done and we're just waiting for the chip fab. If I ever get around to finishing my compiler , it will be able to compile Spin on the P2, most likely to PASM but maybe also to bytecode, probably using the P2 Tachyon kernel.
That seems sensible, IMHO. Also, are you planning to port PropTool to Linux and MacOSX? SimpleIDE has been good for me, not only because it supports C, but it runs natively on Linux too. It would be good if PropTool could be ported to run there too.
Since it appears we're having a cathartic moment, I'd like to throw a marketing suggestion into the mix . . .
Two weeks ago, in some other thread someone said something about creating a "family" of devices. I will try to find the thread and link to it here.
This is basically the state of the MCU world as my blind eyes are currently seeing it :
1) Mainstream (or old dogs) : 8051 (billions of vendors/sizes/features); PIC, Atmel AVR, MSP430 (single vendor, but billions of sizes/features
2) New mainstream : ARM cortex M3, M0, M4, etc ... (from ST, NXP, TI, etc) Also billions of packages, and features with the added bonus of similar programing enviroment (C language and libraries).
3) Others : FTDI FT900, FTDI eve, Cypress PSOC, XMOS, Intel D2000 (yes, even intel now wants to make MCUs), Propeller, etc ...
The first group don't need to find a niche. They are general purpose and they serve any application. They are available in any package size, and with one hundred different features. Those MCUs have a huge famlily of devices and prices.
The second group also don't need a niche. The ARM Cortex M3/M0/M4 have been wrapped with a huge amount of software libraries and tools to make as easy as possible for enginners to change from old designs into new ones. They aims to replace any other legacy MCU. And it seems that they are doing a good job with it. They also have a huge family of devices and prices.
The third type are searching for some niche. And they don't necessarily need a huge family of devices or prices. FTDI are using their USB knowledge and also are directed towards LCD/touch panels (with their EVE). XMOS made a big invesment in applications (Networking, USB, Audio, ...). Cypress are mixing programable logic with the first two groups (PSOC3 with 8051, and PSOC4&5 with ARM Cortex). And Intel D2000 ... uh? Well, I don't know what to say about Intel D2000 ...
And then we have the propeller. This MCU is probably (for all of you that are reading this post) the most important MCU, the best MCU, and the most fun of all MCU that have ever (and never) been made. But yet, it is still a great unknown MCU. I even think that Parallax had released the Verilog code of their MCU but nobody yet has made a clone of their chip !!! This is quite disturbing, as I cannot find the propeller at US $1 on Ebay or Taobao. How comes that one of the best microcontrollers ever made has not been cloned in millions, like those FTDI USB ICs?
Can it be that maybe the propeller aims to be generic or general purpose and with no application specific restrictions but at the same time there is no flexibility on packages/cores?
You only have one option P1 with 8 cogs/cores and 44 pins. And maybe this christmas another "option" : P2 (not code compatible with P1, yes NOT code compatible with P1) with 16 cogs and 100 pins.
I found the reading about the "family" of devices a great post. I will try to find it and link it here.
And then we have the propeller. ...(and never) ...... I even think that Parallax had released the Verilog code of their MCU but nobody yet has made a clone of their chip !!! This is quite disturbing, as I cannot find the propeller at US $1 on Ebay or Taobao. How comes that one of the best microcontrollers ever made has not been cloned in millions, like those FTDI USB ICs?
That sheds light to the semiconductor industry. They follow the mainstream and don't look to the left and right. Even the investment of cloning the chip (improving the same moment) is not done, maybe due to the fact, that the I/O-Pin have to be designed from scratch. I also believe, no one even asked Parallax for a license.
And then we have the propeller. ...(and never) ...... I even think that Parallax had released the Verilog code of their MCU but nobody yet has made a clone of their chip !!! This is quite disturbing, as I cannot find the propeller at US $1 on Ebay or Taobao. How comes that one of the best microcontrollers ever made has not been cloned in millions, like those FTDI USB ICs?
That sheds light to the semiconductor industry. They follow the mainstream and don't look to the left and right. Even the investment of cloning the chip (improving the same moment) is not done, maybe due to the fact, that the I/O-Pin have to be designed from scratch. I also believe, no one even asked Parallax for a license.
Maybe they don't like the fact that it is GPL. Doesn't that mean they'd have to release source for any improvements they might make?
And then we have the propeller. ...(and never) ...... I even think that Parallax had released the Verilog code of their MCU but nobody yet has made a clone of their chip !!! This is quite disturbing, as I cannot find the propeller at US $1 on Ebay or Taobao. How comes that one of the best microcontrollers ever made has not been cloned in millions, like those FTDI USB ICs?
That sheds light to the semiconductor industry. They follow the mainstream and don't look to the left and right. Even the investment of cloning the chip (improving the same moment) is not done, maybe due to the fact, that the I/O-Pin have to be designed from scratch. I also believe, no one even asked Parallax for a license.
Maybe they don't like the fact that it is GPL. Doesn't that mean they'd have to release source for any improvements they might make?
That would hardly stop cheap clones from flooding the market. The only thing that's stopping it is the lack of market.
...
You can declare anything in whatever order you like in Spin.
...
Enlightening and mesmerizing at the same time. I guess I'll give it a go, although I am to see if I can generate a good enough prime number generator using Spin. I can implement isqrt by using bitshifting, if Spin supports bitwise operations. The rest, I think it may have almost direct correspondence when using the C code as a basis for the Spin code. It is an interesting exercise for me.
Spin certainly supports bitwise operations - it has more than C. It also has a builtin sqrt operator that's part of the Spin interpreter, so you don't need to worry about finding an isqrt. Just do ^^x to take the square root of x. However, I wouldn't expect great performance from a prime number generator in Spin - speed is not Spin's main advantage, although it's always been fast enough for top-level code for me, and the Propeller wasn't designed for prime number generation or homogeneous parallel processing.
I may have to agree. SPIN is a good language, except for the bytecode part. Or at least it should be possible to compile it to PASM instead, and not the Java kind of compilation.
I've started work on a P2 code generator, but the P2 instruction formats are more complicated than the P1 ones, and it'll take a while to get them all integrated. I hate to say it, but I'm not sure how useful a lot of the new instructions are. Obviously the ones that do I/O are wonderful, but we have a plethora of choices w.r.t. function calls (at least 4 different forms of call/ret), bit manipulation, and so on that seem kind of like overkill. *Not* that I'm suggesting changing anything at this late date, I think we're all eager to see the P2 shipped.
That sheds light to the semiconductor industry. They follow the mainstream and don't look to the left and right.
May be.
Foundries don't care, they make what you want.
Chip designers can start from scratch, or perhaps it's more efficient to use IP blocks designed by others. Like ARM and all the peripherals around it.
A huge expense in all this is software, compilers and such, much cheaper to use something for which tools are available.
On the other hand there is the ESPwhatever WIFI chips, which are all the rage today, what on Earth processor architecture is in there?
@David Betz
Maybe they don't like the fact that it is GPL.
This is not an issue. Parallax owns the thing. If anyone wanted to make a P1 chip from the released Verilog they could negotiate for a different license deal.
@potatohead
Hi Spud,
There is no ROM on the P2 holding a Spin interpreter. As such the gates are open for whatever people want.
I'm sure there will be a Spin for the P2. I'm also sure that the availability of Spin will not help P2 sales.
I oppose SPIN being a P1 only language. SPIN and PASM together are a potent combination.
If SPIN and PASM go, I'm out hard.
The C discussion and tools are a good one! These are not mutually exclusive things.
Carry on kids.
That's right. They are not exclusive. If we can springboard off Javascript and Python early, that would help get into the market, but long-term, I want to get Spin/PASM running and even have them self-hosting from the chip, itself, which makes no sense to a lot of people, but interests me, greatly.
Python might be nice for some. I don't see why you'd want JavaScript when you have C++ though.
To me, JavaScript is just C++ with some web browser stuff added to it...
I oppose SPIN being a P1 only language. SPIN and PASM together are a potent combination.
If SPIN and PASM go, I'm out hard.
I never suggested getting rid of PASM! That would be even worse than getting rid of SPIN! In fact, PASM is the first (and most critical) language that the P2 supported. I do think it should be stand-alone, though (i.e. it should not require SPINisms to be mixed in just to use it). And I don't think that anyone has suggested getting rid of SPIN for P2 altogether, just to focus on other languages first.
Wonder if Spin in ROM would be good for education applications... Seems like if you could just connect USB keyboard, mouse and monitor and be able to program it to control LEDs and servos, etc. could be low cost and simple to setup up. Also don't have to worry about installing stuff or viruses or networking...
I disagree searirh. SPIN and PASM are one thing. We can totally have a stand alone PASM. That is good for a lot of reasons.
But, the unified syntax, etc... SPASM has, as well as having true inline now possible with HUB code, needs to exist. That combination has huge advantages! I'm short on time right now, but I will come back to this.
Make other and more mainstream stacks all day. I don't care and may even use them from time to time, but let's don't break SPASM. There is a methodology embodied in SPASM not duplicated elsewhere.
It needs to exist.
Anyone who uses that approach will benefit for a very long time. The primary benefit is fully exploiting the chip features without having to know more about the tools than the code steps and problem at hand. The secondary one is rapidly reaching a point where that is all well understood and not needing constant updates for that to remain true.
At this point, I'd go so far as to suggest leaving SPIN a P1-only language (for now). Focus on getting another well-known interpreted language ported.....
Actually, I don't think what I'm suggesting is that provocative. Here's why:
* It would be trivial to port the existing SPIN interpreter. However, only pure SPIN programs would likely be able to run.
* Even if you did port the existing interpreter, you would gain very little functionality. You certainly wouldn't be able to take advantage of most of the new P2 capabilities.
* Based on past discussions of what a "new" SPIN would look like, it will be a significant undertaking to develop it in time for release with the P2.
* Conversely, for a similar amount of effort, we are much more likely attract people to the P2 by adding support for one or more well-known/popular languages.
Note, also, that I suggested this approach "for now". I'm not suggesting that SPIN should never be ported to the P2, just that it should not be a priority.
I'd largely agree, but it comes down to semantics.
You missed that having a P1 Compatible Spin, gives an important Code-base porting tool, and shows you thought about existing customers.
So I think port the existing SPIN interpreter, is useful, and you say is trivial - that much is worth doing.
Expanding to Spin 2.0, I agree, would be placed further down the to-do list.
ersmith's Spin2cpp work looks great to me, as it gives another way to use existing code.
With this, I'd also simplify the structure for P2 Assembler files:
* Get rid of CON and DAT.
* add a "con" directive to define constants.
* for those few constants that are actually controlling boot configuration, make them directives as well.
* Use file extension "pasm" (assuming the P2 official name starts with "P").
Certainly, yes, the Assembler needs a clean-up pass.
PASM is the first (and most critical) language that the P2 supported.
I do think it should be stand-alone, though (i.e. it should not require SPINisms to be mixed in just to use it).
Wonder if Spin in ROM would be good for education applications... Seems like if you could just connect USB keyboard, mouse and monitor and be able to program it to control LEDs and servos, etc. could be low cost and simple to setup up. Also don't have to worry about installing stuff or viruses or networking...
If you meant 'virtual ROM', then yes, that can easily be done by whoever makes the Board.
Comments
Oooh! I'm going to have to go get some popcorn to watch this one with!!
Also, for doing a GUI, you're going to want classes, at least I think so.
And, polymorphism is very useful sometimes.
Hah! Actually, I don't think what I'm suggesting is that provocative. Here's why:
* It would be trivial to port the existing SPIN interpreter. However, only pure SPIN programs would likely be able to run.
* Even if you did port the existing interpreter, you would gain very little functionality. You certainly wouldn't be able to take advantage of most of the new P2 capabilities.
* Based on past discussions of what a "new" SPIN would look like, it will be a significant undertaking to develop it in time for release with the P2.
* Conversely, for a similar amount of effort, we are much more likely attract people to the P2 by adding support for one or more well-known/popular languages.
Note, also, that I suggested this approach "for now". I'm not suggesting that SPIN should never be ported to the P2, just that it should not be a priority.
I don't recall a programming language where you don't need to declare vars beforehand. Just follow the good practices (using C to make a console program is a good way, and then rinse and repeat) and you'll get used to it. C enforces good programming and discourages spaghetti code.
But, C++ gives you things you need to do big programs in a more organized way.
You can declare anything in whatever order you like in Spin.
P2 Spin should definitely be a priority, but it shouldn't be started (by Chip at least) until the P2 is done and we're just waiting for the chip fab. If I ever get around to finishing my compiler
>Means the main routines wind up all the way at the bottom of the code.
That is done incorrectly or lazy, to have int main(void) on top you have to do function declarations,
You should put these in the .h file so your main can start on 3rd line.
Declaration is not needed if the compiler see the Definition before any calls is made to it, that is why many (lazy) programmers do put main on bottom.
http://www.tutorialspoint.com/cprogramming/c_functions.htm
Vars can be declared pretty much anywhere, if done inside a function the compiler will use a scratch register for it (efficient)
Global Vars (e.g RAM usage) on reset/boot will be set to a value or set to zero, not saying either is the same a zero.
The compiler will then sort them so all zero are in one block and all pre-valued in one, the zero is of course just a loop clearing them,
the one with values are copied from a flash block to the ram block.
That seems sensible, IMHO. Also, are you planning to port PropTool to Linux and MacOSX? SimpleIDE has been good for me, not only because it supports C, but it runs natively on Linux too. It would be good if PropTool could be ported to run there too.
PropellerIDE is the PropTool for Linux and Mac.
The actual Prop Tool cannot be ported to anything because it uses some GUI component that is not closed source and only available for Windows.
Two weeks ago, in some other thread someone said something about creating a "family" of devices. I will try to find the thread and link to it here.
This is basically the state of the MCU world as my blind eyes are currently seeing it :
1) Mainstream (or old dogs) : 8051 (billions of vendors/sizes/features); PIC, Atmel AVR, MSP430 (single vendor, but billions of sizes/features
2) New mainstream : ARM cortex M3, M0, M4, etc ... (from ST, NXP, TI, etc) Also billions of packages, and features with the added bonus of similar programing enviroment (C language and libraries).
3) Others : FTDI FT900, FTDI eve, Cypress PSOC, XMOS, Intel D2000 (yes, even intel now wants to make MCUs), Propeller, etc ...
The first group don't need to find a niche. They are general purpose and they serve any application. They are available in any package size, and with one hundred different features. Those MCUs have a huge famlily of devices and prices.
The second group also don't need a niche. The ARM Cortex M3/M0/M4 have been wrapped with a huge amount of software libraries and tools to make as easy as possible for enginners to change from old designs into new ones. They aims to replace any other legacy MCU. And it seems that they are doing a good job with it. They also have a huge family of devices and prices.
The third type are searching for some niche. And they don't necessarily need a huge family of devices or prices. FTDI are using their USB knowledge and also are directed towards LCD/touch panels (with their EVE). XMOS made a big invesment in applications (Networking, USB, Audio, ...). Cypress are mixing programable logic with the first two groups (PSOC3 with 8051, and PSOC4&5 with ARM Cortex). And Intel D2000 ... uh? Well, I don't know what to say about Intel D2000 ...
And then we have the propeller. This MCU is probably (for all of you that are reading this post) the most important MCU, the best MCU, and the most fun of all MCU that have ever (and never) been made. But yet, it is still a great unknown MCU. I even think that Parallax had released the Verilog code of their MCU but nobody yet has made a clone of their chip !!! This is quite disturbing, as I cannot find the propeller at US $1 on Ebay or Taobao. How comes that one of the best microcontrollers ever made has not been cloned in millions, like those FTDI USB ICs?
Can it be that maybe the propeller aims to be generic or general purpose and with no application specific restrictions but at the same time there is no flexibility on packages/cores?
You only have one option P1 with 8 cogs/cores and 44 pins. And maybe this christmas another "option" : P2 (not code compatible with P1, yes NOT code compatible with P1) with 16 cogs and 100 pins.
I found the reading about the "family" of devices a great post. I will try to find it and link it here.
That sheds light to the semiconductor industry. They follow the mainstream and don't look to the left and right. Even the investment of cloning the chip (improving the same moment) is not done, maybe due to the fact, that the I/O-Pin have to be designed from scratch. I also believe, no one even asked Parallax for a license.
That would hardly stop cheap clones from flooding the market. The only thing that's stopping it is the lack of market.
Spin certainly supports bitwise operations - it has more than C. It also has a builtin sqrt operator that's part of the Spin interpreter, so you don't need to worry about finding an isqrt. Just do ^^x to take the square root of x. However, I wouldn't expect great performance from a prime number generator in Spin - speed is not Spin's main advantage, although it's always been fast enough for top-level code for me, and the Propeller wasn't designed for prime number generation or homogeneous parallel processing.
That's already possible. See the spincvt GUI at https://github.com/totalspectrum/spin2cpp/releases/download/v3.0.4/spincvt.zip. It can translate Spin to PASM (running in a COG or in HUB with LMM), C, or C++. The Spin to PASM translation it does directly, not going through C.
I've started work on a P2 code generator, but the P2 instruction formats are more complicated than the P1 ones, and it'll take a while to get them all integrated. I hate to say it, but I'm not sure how useful a lot of the new instructions are. Obviously the ones that do I/O are wonderful, but we have a plethora of choices w.r.t. function calls (at least 4 different forms of call/ret), bit manipulation, and so on that seem kind of like overkill. *Not* that I'm suggesting changing anything at this late date, I think we're all eager to see the P2 shipped.
I oppose SPIN being a P1 only language. SPIN and PASM together are a potent combination.
If SPIN and PASM go, I'm out hard.
The C discussion and tools are a good one! These are not mutually exclusive things.
Carry on kids.
Foundries don't care, they make what you want.
Chip designers can start from scratch, or perhaps it's more efficient to use IP blocks designed by others. Like ARM and all the peripherals around it.
A huge expense in all this is software, compilers and such, much cheaper to use something for which tools are available.
On the other hand there is the ESPwhatever WIFI chips, which are all the rage today, what on Earth processor architecture is in there?
@David Betz This is not an issue. Parallax owns the thing. If anyone wanted to make a P1 chip from the released Verilog they could negotiate for a different license deal.
@potatohead
Hi Spud,
There is no ROM on the P2 holding a Spin interpreter. As such the gates are open for whatever people want.
I'm sure there will be a Spin for the P2. I'm also sure that the availability of Spin will not help P2 sales.
That's right. They are not exclusive. If we can springboard off Javascript and Python early, that would help get into the market, but long-term, I want to get Spin/PASM running and even have them self-hosting from the chip, itself, which makes no sense to a lot of people, but interests me, greatly.
To me, JavaScript is just C++ with some web browser stuff added to it...
I never suggested getting rid of PASM! That would be even worse than getting rid of SPIN! In fact, PASM is the first (and most critical) language that the P2 supported. I do think it should be stand-alone, though (i.e. it should not require SPINisms to be mixed in just to use it). And I don't think that anyone has suggested getting rid of SPIN for P2 altogether, just to focus on other languages first.
But, the unified syntax, etc... SPASM has, as well as having true inline now possible with HUB code, needs to exist. That combination has huge advantages! I'm short on time right now, but I will come back to this.
Make other and more mainstream stacks all day. I don't care and may even use them from time to time, but let's don't break SPASM. There is a methodology embodied in SPASM not duplicated elsewhere.
It needs to exist.
Anyone who uses that approach will benefit for a very long time. The primary benefit is fully exploiting the chip features without having to know more about the tools than the code steps and problem at hand. The secondary one is rapidly reaching a point where that is all well understood and not needing constant updates for that to remain true.
I'd largely agree, but it comes down to semantics.
You missed that having a P1 Compatible Spin, gives an important Code-base porting tool, and shows you thought about existing customers.
So I think port the existing SPIN interpreter, is useful, and you say is trivial - that much is worth doing.
Expanding to Spin 2.0, I agree, would be placed further down the to-do list.
ersmith's Spin2cpp work looks great to me, as it gives another way to use existing code.
Certainly, yes, the Assembler needs a clean-up pass.
Agreed, done as part of that clean-up pass.