[I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?
It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.
Those don't sound very P2 specific. Couldn't Spin2 be made to target P1 as well?
[I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?
It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.
Those don't sound very P2 specific. Couldn't Spin2 be made to target P1 as well?
Certainly, it could be made to work, minus the CORDIC stuff.
Spin2 should be as far as possible a superset of Spin1, while fixing the gotchas.
This helps those of us who program both P1 and P2 transition back and forth easier.
I don’t expect Spin2 to ever target P1. There are too many extras in P2. Just forget this one.
I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.
[I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?
It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.
Those don't sound very P2 specific. Couldn't Spin2 be made to target P1 as well?
Certainly, it could be made to work, minus the CORDIC stuff.
I wasn't actually suggesting that you should create a Spin2 runtime environment for P1 immediately, just that it ought to be possible. My guess is that Eric will probably do it in fastspin once there is a stable definition of Spin2.
Certainly, it could be made to work, minus the CORDIC stuff.
I wasn't actually suggesting that you should create a Spin2 runtime environment for P1 immediately, just that it ought to be possible. My guess is that Eric will probably do it in fastspin once there is a stable definition of Spin2.
I don't know; it depends on how different Spin2 is from Spin1. I'm getting a bit nervous about how many changes there may be in Spin2. Chip can work on this full time, but I can't afford to, I'm afraid.
Certainly, it could be made to work, minus the CORDIC stuff.
I wasn't actually suggesting that you should create a Spin2 runtime environment for P1 immediately, just that it ought to be possible. My guess is that Eric will probably do it in fastspin once there is a stable definition of Spin2.
I don't know; it depends on how different Spin2 is from Spin1. I'm getting a bit nervous about how many changes there may be in Spin2. Chip can work on this full time, but I can't afford to, I'm afraid.
Eric, I really don't think it amounts to a whole lot. I'm just spending a lot of time on implementation details now. In the end, it'll be what you'd imagine with a few tweaks. Nothing crazy. There's just not much to Spin, anyway.
I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.
Does this Spin 1.5? have a conditional compile support, to allow one source file to target both P1 & P2 ?
I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.
Does this Spin 1.5? have a conditional compile support, to allow one source file to target both P1 & P2 ?
It’s the interpreter, not the compiler.
Having said that, bst and homespun both support conditional compilation and IIRC they can output just the spin bytecode section. OpenSpin supports conditional compilation too.
Having said that, bst and homespun both support conditional compilation and IIRC they can output just the spin bytecode section. OpenSpin supports conditional compilation too.
Do any of those support P2 ?
This is for the teaching situation post from above, where there is appeal for a single source file, that can run on either/any Parallax hardware platform the class may have.
Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
Eric's fastspin covers this case and exists already.
While it covers the case, it is NOT the same as it compiles to PASM. Thus, anything that is RAM critical, or even with some RAM free, may not work due to larger code size.
I am talking about a Spin1 interpreter running on P2. I stopped working on it a couple of months age when I thought there was no need. I am now convinced otherwise, so I'll finish it when I get time, which is currently short atm.
I believe all 3 can and will co-exist (fastspin, spin1 on P2, spin2) for P2. Each will have their audience.
I think it's a good idea to have a Spin1 interpreter for the P2. This will allow P1 Spin programs to run on the P2 with little or no changes to the Spin source code. The programs would have to run in the lower 64K of RAM, but the upper RAM could be used for display memory and user data. Now that Chip has posted his Spin2 interpreter it should be fairly easy to modify it to run Spin1 bytecodes.
No need to use Chip's Spin2. I have already done most of the bytecode spin1 interpreter in P2ASM and it uses skip and will use skip/skipf/execf once its fully debugged. Fortunately I already had my Spin Fast Interpreter using a vector table for all bytecodes which meant that using execf is a breeze.
I am known to be a PITA sometimes, but a P1 PASM emulator could allow to run not just Spin1 but also PASM1 on the P2. But the main point here is to have Spin2 not being completely different.
[I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?
It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.
This sounds nice, my pledge here is to not change basic things like the assignment operator from := to = this would be simply silly and complete unneeded.
I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.
Does this Spin 1.5? have a conditional compile support, to allow one source file to target both P1 & P2 ?
I am known to be a PITA sometimes, but a P1 PASM emulator could allow to run not just Spin1 but also PASM1 on the P2.
Another possibility would be to assemble P1 assembly source directly into P2 machine code. For the most part P1 assembly is just a subset of P2 assembly with some changes that have been made to the symbol names. There are also some P1 instructions that are implemented differently on the P2, such as WAITCNT and the LOCK instructions. The tricky part would be to implement the P1 counters and video functionality on the P2.
...
This sounds nice, my pledge here is to not change basic things like the assignment operator from := to = this would be simply silly and complete unneeded.
The latter case can be handled fairly easily. As an example, a WAITCNT would generate an ADDCT1 followed by a WAITCT1.
Self-modifying code for the source or destination values should work OK, except that extra delay may need to be added. A MOVI could be handled as long as an immediate source value is specified. The assembler would have to map the P1 opcode to the appropriate P2 opcode. If an immediate value is not specified the mapping would have to happen at run time. In this case the assembler would have to signal that it couldn't handle the instruction.
C programmers are already familiar with line continuation using the backslash "\" char but maybe this is not possible if this char gets used elsewhere as an operator in Spin2 (does it?).
I guess like a book splits words over lines using hyphens, Spin2 can similarly split its commands over two or more lines with underscores. I sort of get it but it'll be weird to see at first, as a C programmer anyway. But people adapt.
C programmers are already familiar with line continuation using the backslash "\" char but maybe this is not possible if this char gets used elsewhere as an operator in Spin2 (does it?).
I guess like a book splits words over lines using hyphens, Spin2 can similarly split its commands over two or more lines with underscores. I sort of get it but it'll be weird to see at first, as a C programmer anyway. But people adapt.
Underscores look like minus signs: - _
Who will know what that character is dangling out there?
Having said that, bst and homespun both support conditional compilation and IIRC they can output just the spin bytecode section. OpenSpin supports conditional compilation too.
Do any of those support P2 ?
This is for the teaching situation post from above, where there is appeal for a single source file, that can run on either/any Parallax hardware platform the class may have.
[/quote]
No, although OpenSpin may at some time in the future. You'll need to ask Roy.
Could be a nice project for you
...
This sounds nice, my pledge here is to not change basic things like the assignment operator from := to = this would be simply silly and complete unneeded.
Mike
Agreed.
I am not so sure.
== should definitely stay.
:= vs = I am on the fence because it's used in a lot of other languages.
I am all for trying to use consistent behaviour between different languages.
For instance, I am currently coding in Python. Great, lots of those horrid { } in C are gone. But then they add : after if xyz: and else: and then they use elif xxx: Since Python is indented like spin, why the need for ":"?
Oh why can't the basics be the same...
if...elseif...else...
case...opt1...opt2...else/other/whatever
pub/pri/sub/def/
I am known to be a PITA sometimes, but a P1 PASM emulator could allow to run not just Spin1 but also PASM1 on the P2.
Another possibility would be to assemble P1 assembly source directly into P2 machine code. For the most part P1 assembly is just a subset of P2 assembly with some changes that have been made to the symbol names. There are also some P1 instructions that are implemented differently on the P2, such as WAITCNT and the LOCK instructions. The tricky part would be to implement the P1 counters and video functionality on the P2.
Been there, done that...
JMPRET (JMPRET/CALL/RET) is a major stumbling block, and its heavily used in P1
Nothing is going to turn people off any less now than it did 10 years ago, and thats YAFPL.
I think having special glyphs or non-standard assignment/equals testing, etc is yet again cutting off one's nose in the Not Invented Here syndrome seen here last decade with Interrupts.
..
..
..Actually, maybe just forget everything I wrote.
If there is a Basic available for P2, I would expect education to jump on that vs Spin. Maybe Python if its ready.
If there really was a focus on Education, then Parallax would simply focus on Python first and foremost, or whatever else if the big, current draw in the edu sector, blockly, wiring, ?
Spin is most likely the realm of enthusiasts, and as such focusing on speed, etc and being Chip's baby is fine.
Trying to sell it as for the edu market is just not realistic.
..Actually, maybe just forget everything I wrote.
If there is a Basic available for P2, I would expect education to jump on that vs Spin. Maybe Python if its ready.
...
last reports had Python running VGA+USB, via `The Spin/C part runs in Risc-V emulation. The PASM part runs in another COG, natively`, which is sounding quite impressive really.
If there really was a focus on Education, then Parallax would simply focus on Python first and foremost, or whatever else if the big, current draw in the edu sector, blockly, wiring, ?
Blockly ? - and with that, comes C. I'm not sure if the P2 fastspin C can compile Blockly-generated-C yet, IIRC from comments the main issue was around libraries, rather than compiler depth.
Nothing is going to turn people off any less now than it did 10 years ago, and thats YAFPL.
I think having special glyphs or non-standard assignment/equals testing, etc is yet again cutting off one's nose in the Not Invented Here syndrome seen here last decade with Interrupts.
..
..
..Actually, maybe just forget everything I wrote.
If there is a Basic available for P2, I would expect education to jump on that vs Spin. Maybe Python if its ready.
If there really was a focus on Education, then Parallax would simply focus on Python first and foremost, or whatever else if the big, current draw in the edu sector, blockly, wiring, ?
Spin is most likely the realm of enthusiasts, and as such focusing on speed, etc and being Chip's baby is fine.
Trying to sell it as for the edu market is just not realistic.
My brother Ken is flying back from a teacher training he just did in Chicago and they used MicroBit Python over the web. The teachers loved it because no app was required. Having teachers and students install apps to do something is always a protracted nightmare.
Comments
This is the best approach, I agree.
+1
Certainly, it could be made to work, minus the CORDIC stuff.
Spin2 should be as far as possible a superset of Spin1, while fixing the gotchas.
This helps those of us who program both P1 and P2 transition back and forth easier.
I don’t expect Spin2 to ever target P1. There are too many extras in P2. Just forget this one.
I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.
I don't know; it depends on how different Spin2 is from Spin1. I'm getting a bit nervous about how many changes there may be in Spin2. Chip can work on this full time, but I can't afford to, I'm afraid.
Eric, I really don't think it amounts to a whole lot. I'm just spending a lot of time on implementation details now. In the end, it'll be what you'd imagine with a few tweaks. Nothing crazy. There's just not much to Spin, anyway.
Does this Spin 1.5? have a conditional compile support, to allow one source file to target both P1 & P2 ?
It’s the interpreter, not the compiler.
Having said that, bst and homespun both support conditional compilation and IIRC they can output just the spin bytecode section. OpenSpin supports conditional compilation too.
ie like the C #define, #ifdef, #include et al.
Do any of those support P2 ?
This is for the teaching situation post from above, where there is appeal for a single source file, that can run on either/any Parallax hardware platform the class may have.
I am known to be a PITA sometimes, but a P1 PASM emulator could allow to run not just Spin1 but also PASM1 on the P2. But the main point here is to have Spin2 not being completely different.
This sounds nice, my pledge here is to not change basic things like the assignment operator from := to = this would be simply silly and complete unneeded.
Mike
yes, FastSpin does this already.
Mike
Agreed.
Self-modifying code for the source or destination values should work OK, except that extra delay may need to be added. A MOVI could be handled as long as an immediate source value is specified. The assembler would have to map the P1 opcode to the appropriate P2 opcode. If an immediate value is not specified the mapping would have to happen at run time. In this case the assembler would have to signal that it couldn't handle the instruction.
I guess like a book splits words over lines using hyphens, Spin2 can similarly split its commands over two or more lines with underscores. I sort of get it but it'll be weird to see at first, as a C programmer anyway. But people adapt.
Underscores look like minus signs: - _
Who will know what that character is dangling out there?
Do any of those support P2 ?
This is for the teaching situation post from above, where there is appeal for a single source file, that can run on either/any Parallax hardware platform the class may have.
[/quote]
No, although OpenSpin may at some time in the future. You'll need to ask Roy.
Could be a nice project for you
That is true. A backslash would at least separate the confusion with minus.
I am not so sure.
== should definitely stay.
:= vs = I am on the fence because it's used in a lot of other languages.
I am all for trying to use consistent behaviour between different languages.
For instance, I am currently coding in Python. Great, lots of those horrid { } in C are gone. But then they add : after if xyz: and else: and then they use elif xxx: Since Python is indented like spin, why the need for ":"?
Oh why can't the basics be the same...
if...elseif...else...
case...opt1...opt2...else/other/whatever
pub/pri/sub/def/
JMPRET (JMPRET/CALL/RET) is a major stumbling block, and its heavily used in P1
And the backslash is also compatible with C preprocessors if they get used for conditional compilation in any toolchain at some point.
-or-
PUB writeStringAtPos(parString as string, parX=2, parY=3)
Enjoy!
Mike
My personal preference is to have the clkfreq first, as that is the `dominant` parameter here, but it does not really matter in the big picture...
I agree with msrobots, insofar as :=/=, etc.
Nothing is going to turn people off any less now than it did 10 years ago, and thats YAFPL.
I think having special glyphs or non-standard assignment/equals testing, etc is yet again cutting off one's nose in the Not Invented Here syndrome seen here last decade with Interrupts.
..
..
..Actually, maybe just forget everything I wrote.
If there is a Basic available for P2, I would expect education to jump on that vs Spin. Maybe Python if its ready.
If there really was a focus on Education, then Parallax would simply focus on Python first and foremost, or whatever else if the big, current draw in the edu sector, blockly, wiring, ?
Spin is most likely the realm of enthusiasts, and as such focusing on speed, etc and being Chip's baby is fine.
Trying to sell it as for the edu market is just not realistic.
see:
https://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2-assembly-spin-basic-and-c-in-one-compiler/p1
https://forums.parallax.com/discussion/169862/micropython-for-p2/p1
last reports had Python running VGA+USB, via `The Spin/C part runs in Risc-V emulation. The PASM part runs in another COG, natively`, which is sounding quite impressive really.
Blockly ? - and with that, comes C. I'm not sure if the P2 fastspin C can compile Blockly-generated-C yet, IIRC from comments the main issue was around libraries, rather than compiler depth.
My brother Ken is flying back from a teacher training he just did in Chicago and they used MicroBit Python over the web. The teachers loved it because no app was required. Having teachers and students install apps to do something is always a protracted nightmare.