David's program is pretty neat, but the format it prints is not the one I use in spin2cpp, so either way I would have to make code changes. And I really am tired of keeping up with instruction set changes. I don't think anyone uses spin2cpp for P2, or at least I've had no feedback about it, so there's really no need to keep it up to date. If/when there's silicon, I may support P2 in fastspin/spin2cpp, but for now I'm just going to sit this one out.
Understood.
If it helps, Chip has just mentioned this summary of changes
"The only changes were that RET/RETA/RETB (I=1) were folded into the CALL/CALLA/CALLB encodings (I = 0), which made room for SKIP/SKIPF/EXECF.
The spreadsheet has been updated, but its layout is still the same."
You probably do not use SKIPx, so that is just RETx changes ?
Note that although Propeller2 support was up to date at one point, the instruction set has changed again and so spin2cpp --p2 may or may not work for you. I don't really want to chase a moving target, so if you want to try the P2 support you're on your own. Most likely the PASM output for P2 will work (the instructions that spin2cpp uses still have the same names) but binary output probably won't work.
Hmm, yes.
Note that David Betz has neatly solved this 'following binary changes' issue, where he has written a program to parse P2 instruction spreadsheet to generate the tables to drive the assembler.
David's program is pretty neat, but the format it prints is not the one I use in spin2cpp, so either way I would have to make code changes. And I really am tired of keeping up with instruction set changes. I don't think anyone uses spin2cpp for P2, or at least I've had no feedback about it, so there's really no need to keep it up to date. If/when there's silicon, I may support P2 in fastspin/spin2cpp, but for now I'm just going to sit this one out.
Eric
What does your format look like? Maybe I can add that as an option. In fact, my format doesn't match what gas uses either so I'll probably have to change it before I make any changes to gas or gcc.
David's program is pretty neat, but the format it prints is not the one I use in spin2cpp, so either way I would have to make code changes. And I really am tired of keeping up with instruction set changes. I don't think anyone uses spin2cpp for P2, or at least I've had no feedback about it, so there's really no need to keep it up to date. If/when there's silicon, I may support P2 in fastspin/spin2cpp, but for now I'm just going to sit this one out.
What does your format look like? Maybe I can add that as an option. In fact, my format doesn't match what gas uses either so I'll probably have to change it before I make any changes to gas or gcc.
I've actually got additional semantic info in there that the compiler and optimizer use, which isn't in the original spreadsheet. So no matter what we do I'm going to have to massage the output. Probably it makes sense for me to make the tables more like the ones gas has so that this will be easier, but as I said earlier I'm not feeling very motivated to work on P2 stuff right now. If there's a user who actually wants P2 support perhaps I can provide it, but so far I think I'm the only person who's ever used it.
David's program is pretty neat, but the format it prints is not the one I use in spin2cpp, so either way I would have to make code changes. And I really am tired of keeping up with instruction set changes. I don't think anyone uses spin2cpp for P2, or at least I've had no feedback about it, so there's really no need to keep it up to date. If/when there's silicon, I may support P2 in fastspin/spin2cpp, but for now I'm just going to sit this one out.
What does your format look like? Maybe I can add that as an option. In fact, my format doesn't match what gas uses either so I'll probably have to change it before I make any changes to gas or gcc.
I've actually got additional semantic info in there that the compiler and optimizer use, which isn't in the original spreadsheet. So no matter what we do I'm going to have to massage the output. Probably it makes sense for me to make the tables more like the ones gas has so that this will be easier, but as I said earlier I'm not feeling very motivated to work on P2 stuff right now. If there's a user who actually wants P2 support perhaps I can provide it, but so far I think I'm the only person who's ever used it.
Eric
It's surprising that no one seems interested in using your P2 compiler. Instead everyone seems to be obsessed with a byte code version of Spin. I had thought that the larger memory of the P2 would let us leave byte codes behind. I guess not.
It's surprising that no one seems interested in using your P2 compiler. Instead everyone seems to be obsessed with a byte code version of Spin. I had thought that the larger memory of the P2 would let us leave byte codes behind. I guess not.
I'm not sure no one is interested, but it is a rather hidden feature.
Also, the possible user base is limited to those running FPGAs, so it is not large.
Having a P2 compiler would increase the possible test coverage, but I guess if the PASM pathway still works, not having Binary is not actually a brick-wall to any testing - is that correct ?
I've updated spin2cpp to version 3.6.2. This version has a number of bug fixes (including fixing a nasty optimizer bug that could convert INA in source position to dest position, which does not work correctly!). It also has updated P2 support. P2 instructions have mostly been updated to v18. Not all P2 instructions and addressing modes are supported, but most are (enough to run compiled code). "fastspin -2" is able to produce P2 binaries now, suitable for loading with Dave Hein's loadp2 program, or any other tool that can download binaries to the P2.
As usual, the release is on the spin2cpp releases page.
I've updated spin2cpp to version 3.6.2. This version has a number of bug fixes (including fixing a nasty optimizer bug that could convert INA in source position to dest position, which does not work correctly!). It also has updated P2 support. P2 instructions have mostly been updated to v18. Not all P2 instructions and addressing modes are supported, but most are (enough to run compiled code). "fastspin -2" is able to produce P2 binaries now, suitable for loading with Dave Hein's loadp2 program, or any other tool that can download binaries to the P2.
As usual, the release is on the spin2cpp releases page.
This is impressive.
spin2cpp is a converter from the Parallax Spin programming language to C, C++, or PASM. fastspin is a front end for spin2cpp that produces LMM executable binaries from Spin files; it has the same syntax as openspin, but the output programs are up to 4x bigger (bad) and 10x faster (good). spincvt is a GUI front end for spin2cpp that may be more comfortable to use; it will interactively show you the C, C++, or PASM equivalent of some Spin code.
spincvt.zip is the GUI, for Windows only, and has everything you should need if you're just starting out.
fastspin.zip has just the (Windows) command line replacement for openspin.
spin2cpp.zip has the Windows and Linux command line utility.
This release has a number of bug fixes, plus some improvements in the Prop2 support. fastspin -2 is now able to compile binaries for P2, which may be downloaded to the board with Dave Hein's loadp2 program. Not all Prop2 instructions and addressing modes are supported yet, but the ones used by the PASM output are.
Suggestion: Can you add some simple flow lines, to show what other tools are needed to get from source into chip, for each path.
Just mentioning that there is a version 3.6.6 of spin2cpp (and fastspin and spincvt) available on the Spin2cpp releases page. Mostly this version is bug fixes (including making the compiler not crash in recent 64 bit Linuxes).
For those not familiar with it, the spin2cpp family of tools convert Spin files to other forms, such as C or PASM. fastspin is a simple interface to spin2cpp that can convert a Spin file to an executable binary. Unlike other Spin compilers (like openspin or bstc) fastspin produces direct machine instructions instead of bytecode. This means that binaries compiled with fastspin are much faster than those produced by "regular" Spin compilers, but also quite a bit larger.
There is also a basic GUI called "spinconvert.exe" (see spincvt.zip) which allows you to interactively see how Spin is converted to C, C++, or PASM. I think this could be a very useful tool for learning PASM or C if you already know Spin, or for learning Spin if you know C. I also haven't documented it very well, but spinconvert.exe can serve as a very simple Spin IDE -- it has a "run on device" menu option that uses David Betz's prop loader to download built binaries.
Newly documented is the previously hidden feature that if fastspin is named something that starts with the letters "bstc" then it tries to act like the bstc compiler, at least enough to make PropellerIDE happy. This allows you to easily try out fastspin in PropellerIDE (just rename fastspin.exe to bstc.exe), and also provides a way to support PropBASIC on machines that don't have bstc (since the fastspin assembler supports @@@, which openspin doesn't have and PropBASIC needs).
Here are some screenshots of spinconvert.exe in action:
...
Newly documented is the previously hidden feature that if fastspin is named something that starts with the letters "bstc" then it tries to act like the bstc compiler, at least enough to make PropellerIDE happy. This allows you to easily try out fastspin in PropellerIDE (just rename fastspin.exe to bstc.exe), and also provides a way to support PropBASIC on machines that don't have bstc (since the fastspin assembler supports @@@, which openspin doesn't have and PropBASIC needs).
Sounds very nifty, so I tried this, on Bean's PBasic examples....
C:\..\Spin2cpp\bstc_fastspin --binary -Os "Freq Counter3.spin"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2016 Total Spectrum Software Inc.
Version 3.6.4 Compiled on: Aug 16 2017
Freq Counter3.spin
Done.
Program size is 1116 bytes
Compiled 415 Lines of Code
works, but that seems to create a LMM program ?
Then I try this, seems to give an error, and also no binary visible ?
C:\..\Spin2cpp\bstc_spin2cpp --binary -mcmm -Os "Freq Counter3.spin"
Freq Counter3.spin:377: error: offset for the @@@ operator is not known
Freq Counter3.spin:378: error: offset for the @@@ operator is not known
DOCs suggest this should do this ? You can output a .binary file (like bstc and openspin do with the -b option) instead of .elf:
spin2cpp --binary -mcmm -Os test.spin
will create "test.binary", ready to be run with propeller-load or with any other Spin loader.
What is the secret to getting PropBASIC created .spin to binary ? - ie just work like a @@@ aware assembler ?
C:\..\Spin2cpp\bstc_fastspin --binary -Os "Freq Counter3.spin"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2016 Total Spectrum Software Inc.
Version 3.6.4 Compiled on: Aug 16 2017
Freq Counter3.spin
Done.
Program size is 1116 bytes
Compiled 415 Lines of Code
works, but that seems to create a LMM program ?
The only LMM code will be the one small Spin method that Bean's compiler inserts at the very beginning to load up the PropBASIC code. For a small example like this the overhead is noticeable, but it's a fixed amount of code. If you look at "Freq Counter3.spin" there's very little Spin in there, it's pretty much all PASM, and fastspin just assembles that.
By the way, you don't need those `--binary` or `-Os` switches for fastspin. Just "fastspin whatever.spin" and get "whatever.binary" as output. It seems like I need to make the documentation a bit clearer, sorry about that.
Then I try this, seems to give an error, and also no binary visible ?
C:\..\Spin2cpp\bstc_spin2cpp --binary -mcmm -Os "Freq Counter3.spin"
Freq Counter3.spin:377: error: offset for the @@@ operator is not known
Freq Counter3.spin:378: error: offset for the @@@ operator is not known
spin2cpp is a different program from fastspin, and it doesn't have the bstc support. You're also asking for CMM mode, which is a C compiler thing, and the gas assembler that PropGCC uses is not completely PASM compatible.
For assembling PASM I'd just stick with fastspin. spin2cpp is the swiss army knife that can do everything, but as a result it's a bit awkward to use. fastspin is pretty simple: you give it Spin + PASM, it produces a binary you can run. It's designed to be just like openspin, except that instead of compiling Spin to bytecode it compiles to LMM PASM.
Just for the record, to use spin2cpp as an assembler for bstc I'd do:
The options mean "produce assembly directly (rather than C code)", "produce a binary file", and "put all code in COG space" respectively. The --code=cog will slightly reduce the Spin overhead compared to LMM mode, which is --code=hub and which is what fastspin always uses.
spin2cpp is a different program from fastspin, and it doesn't have the bstc support. You're also asking for CMM mode, which is a C compiler thing, and the gas assembler that PropGCC uses is not completely PASM compatible.
I thought bits of that looked suss, but the DOCs actually gave that command line as a bstc binary example.
You can output a .binary file (like bstc and openspin do with the -b option) instead of .elf:
spin2cpp --binary -mcmm -Os test.spin
The options mean "produce assembly directly (rather than C code)", "produce a binary file", and "put all code in COG space" respectively. The --code=cog will slightly reduce the Spin overhead compared to LMM mode, which is --code=hub and which is what fastspin always uses.
That seems cleaner, & makes a smaller binary than I get with fastspin, but still seems to add code on top of the PropBASIC code ?
Seems that imposes a size limit on what PropBASIC code it can manage ?
Addit:: comparing the PropIDE flow, that gives 746 bytes binary, vs spin2cpp flow that gives 848 bytes binary, that 102 bytes/13% difference is what I'm unclear on ?
spin2cpp is a different program from fastspin, and it doesn't have the bstc support. You're also asking for CMM mode, which is a C compiler thing, and the gas assembler that PropGCC uses is not completely PASM compatible.
I thought bits of that looked suss, but the DOCs actually gave that command line as a bstc binary example.
You can output a .binary file (like bstc and openspin do with the -b option) instead of .elf:
spin2cpp --binary -mcmm -Os test.spin
That line would actually work for most .spin files, but it does so by calling PropGCC to produce the binary, and PropGCC can't handle PropBASIC output (its @@@ support is incomplete). It would likely add more fixed overhead to the file than the --asm version, since you'd get the C support code in the binary.
That seems cleaner, & makes a smaller binary than I get with fastspin, but still seems to add code on top of the PropBASIC code ?
Seems that imposes a size limit on what PropBASIC code it can manage ?
Addit:: comparing the PropIDE flow, that gives 746 bytes binary, vs spin2cpp flow that gives 848 bytes binary, that 102 bytes/13% difference is what I'm unclear on ?
The PropBASIC output does contain one Spin method, and compiling that Spin method with fastspin / spin2cpp will produce a bigger binary than with bstc. It's a fixed overhead though -- it's not a 13% difference, it's a fixed 102 bytes difference. So yes, if you have a PropBASIC program that needs exactly 32K of memory when compiled with bstc then it won't work when compiled with fastspin / spin2cpp. If your PropBASIC program has at least 102 bytes free then it will work. I think the latter scenario is more common in practice .
Another way to think of it is that bstc is also adding overhead on top of the PropBASIC code (the size of the byte compiled PUB method), but its overhead is smaller than fastspin's because (a) it's using bytecode instead of PASM for the method, and (b) it uses support code from ROM instead of needing it in RAM.
Addit:: comparing the PropIDE flow, that gives 746 756 bytes binary, vs spin2cpp flow that gives 848 bytes binary, that 102 bytes/13% difference is what I'm unclear on ?
The PropBASIC output does contain one Spin method, and compiling that Spin method with fastspin / spin2cpp will produce a bigger binary than with bstc. It's a fixed overhead though -- it's not a 13% difference, it's a fixed 102 bytes difference. So yes, if you have a PropBASIC program that needs exactly 32K of memory when compiled with bstc then it won't work when compiled with fastspin / spin2cpp. If your PropBASIC program has at least 102 bytes free then it will work. I think the latter scenario is more common in practice .
Another way to think of it is that bstc is also adding overhead on top of the PropBASIC code (the size of the byte compiled PUB method), but its overhead is smaller than fastspin's because (a) it's using bytecode instead of PASM for the method, and (b) it uses support code from ROM instead of needing it in RAM.
is that 32k limit valid, when we are talking about COG Code ?
Just noticed 102 bytes is not a long multiple, so I rechecked my file sizes, and found a typo, should be 756 bytes, giving 92B or 23L difference.
If that is a known, and fixed overhead, perhaps it should be documented ?
is that 32k limit valid, when we are talking about COG Code ?
Yes. The overhead is in startup code that's in HUB memory. The actual COG code that runs (assuming you asked PropBASIC to output COG code) still has the full 2K of COG memory available.
Ah, I think I see the cause of your command line confusion, jmg. I accidentally included the spin2cpp documentation in the fastspin zip. Please ignore the README.md for any fastspin info; it should all be in README.fastspin. Sorry about that, and I'll fix those zip files soon (I have some further optimization improvements I'm working on so there will be a new release shortly).
Comments
Understood.
If it helps, Chip has just mentioned this summary of changes
"The only changes were that RET/RETA/RETB (I=1) were folded into the CALL/CALLA/CALLB encodings (I = 0), which made room for SKIP/SKIPF/EXECF.
The spreadsheet has been updated, but its layout is still the same."
You probably do not use SKIPx, so that is just RETx changes ?
I've actually got additional semantic info in there that the compiler and optimizer use, which isn't in the original spreadsheet. So no matter what we do I'm going to have to massage the output. Probably it makes sense for me to make the tables more like the ones gas has so that this will be easier, but as I said earlier I'm not feeling very motivated to work on P2 stuff right now. If there's a user who actually wants P2 support perhaps I can provide it, but so far I think I'm the only person who's ever used it.
Eric
I'm not sure no one is interested, but it is a rather hidden feature.
Also, the possible user base is limited to those running FPGAs, so it is not large.
Having a P2 compiler would increase the possible test coverage, but I guess if the PASM pathway still works, not having Binary is not actually a brick-wall to any testing - is that correct ?
As usual, the release is on the spin2cpp releases page.
spin2cpp is a converter from the Parallax Spin programming language to C, C++, or PASM. fastspin is a front end for spin2cpp that produces LMM executable binaries from Spin files; it has the same syntax as openspin, but the output programs are up to 4x bigger (bad) and 10x faster (good). spincvt is a GUI front end for spin2cpp that may be more comfortable to use; it will interactively show you the C, C++, or PASM equivalent of some Spin code.
spincvt.zip is the GUI, for Windows only, and has everything you should need if you're just starting out.
fastspin.zip has just the (Windows) command line replacement for openspin.
spin2cpp.zip has the Windows and Linux command line utility.
This release has a number of bug fixes, plus some improvements in the Prop2 support. fastspin -2 is now able to compile binaries for P2, which may be downloaded to the board with Dave Hein's loadp2 program. Not all Prop2 instructions and addressing modes are supported yet, but the ones used by the PASM output are.
Suggestion: Can you add some simple flow lines, to show what other tools are needed to get from source into chip, for each path.
Good idea. For now, these are the paths I use for ZOG to go from source to running on the chip:
P1:
P2:
This works because the code in debug_zog.spin has #ifdef __P2__ around the propeller2 specific parts (e.g. the PASM objects), like:
Jim
Do you have any specific questions? Have you tried converting your spin code with spincvt?
Eric
I know nothing about spincvt. Where do I find info on it?
Jim
So I just went to gethub and found that spincvt is a GUI! So as soon as I can get to my win7 machine, I will download and try the programs.
Jim
For those not familiar with it, the spin2cpp family of tools convert Spin files to other forms, such as C or PASM. fastspin is a simple interface to spin2cpp that can convert a Spin file to an executable binary. Unlike other Spin compilers (like openspin or bstc) fastspin produces direct machine instructions instead of bytecode. This means that binaries compiled with fastspin are much faster than those produced by "regular" Spin compilers, but also quite a bit larger.
There is also a basic GUI called "spinconvert.exe" (see spincvt.zip) which allows you to interactively see how Spin is converted to C, C++, or PASM. I think this could be a very useful tool for learning PASM or C if you already know Spin, or for learning Spin if you know C. I also haven't documented it very well, but spinconvert.exe can serve as a very simple Spin IDE -- it has a "run on device" menu option that uses David Betz's prop loader to download built binaries.
Newly documented is the previously hidden feature that if fastspin is named something that starts with the letters "bstc" then it tries to act like the bstc compiler, at least enough to make PropellerIDE happy. This allows you to easily try out fastspin in PropellerIDE (just rename fastspin.exe to bstc.exe), and also provides a way to support PropBASIC on machines that don't have bstc (since the fastspin assembler supports @@@, which openspin doesn't have and PropBASIC needs).
Here are some screenshots of spinconvert.exe in action:
Sounds very nifty, so I tried this, on Bean's PBasic examples....
PropBasic Version 00.01.44 Jul 13, 2014
Finished Compile. 137 Lines Read, 252 Lines Generated, 0 Warnings, 0 Errors.
C:\..\Spin2cpp\bstc_fastspin --binary -Os "Freq Counter3.spin"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2016 Total Spectrum Software Inc.
Version 3.6.4 Compiled on: Aug 16 2017
Freq Counter3.spin
Done.
Program size is 1116 bytes
Compiled 415 Lines of Code
works, but that seems to create a LMM program ?
Then I try this, seems to give an error, and also no binary visible ?
C:\..\Spin2cpp\bstc_spin2cpp --binary -mcmm -Os "Freq Counter3.spin"
Freq Counter3.spin:377: error: offset for the @@@ operator is not known
Freq Counter3.spin:378: error: offset for the @@@ operator is not known
DOCs suggest this should do this ?
You can output a .binary file (like bstc and openspin do with the -b option) instead of .elf:
spin2cpp --binary -mcmm -Os test.spin
will create "test.binary", ready to be run with propeller-load or with any other Spin loader.
What is the secret to getting PropBASIC created .spin to binary ? - ie just work like a @@@ aware assembler ?
By the way, you don't need those `--binary` or `-Os` switches for fastspin. Just "fastspin whatever.spin" and get "whatever.binary" as output. It seems like I need to make the documentation a bit clearer, sorry about that.
spin2cpp is a different program from fastspin, and it doesn't have the bstc support. You're also asking for CMM mode, which is a C compiler thing, and the gas assembler that PropGCC uses is not completely PASM compatible.
For assembling PASM I'd just stick with fastspin. spin2cpp is the swiss army knife that can do everything, but as a result it's a bit awkward to use. fastspin is pretty simple: you give it Spin + PASM, it produces a binary you can run. It's designed to be just like openspin, except that instead of compiling Spin to bytecode it compiles to LMM PASM.
Just for the record, to use spin2cpp as an assembler for bstc I'd do: The options mean "produce assembly directly (rather than C code)", "produce a binary file", and "put all code in COG space" respectively. The --code=cog will slightly reduce the Spin overhead compared to LMM mode, which is --code=hub and which is what fastspin always uses.
I thought bits of that looked suss, but the DOCs actually gave that command line as a bstc binary example.
You can output a .binary file (like bstc and openspin do with the -b option) instead of .elf:
spin2cpp --binary -mcmm -Os test.spin
That seems cleaner, & makes a smaller binary than I get with fastspin, but still seems to add code on top of the PropBASIC code ?
Seems that imposes a size limit on what PropBASIC code it can manage ?
Addit:: comparing the PropIDE flow, that gives 746 bytes binary, vs spin2cpp flow that gives 848 bytes binary, that 102 bytes/13% difference is what I'm unclear on ?
That line would actually work for most .spin files, but it does so by calling PropGCC to produce the binary, and PropGCC can't handle PropBASIC output (its @@@ support is incomplete). It would likely add more fixed overhead to the file than the --asm version, since you'd get the C support code in the binary.
The PropBASIC output does contain one Spin method, and compiling that Spin method with fastspin / spin2cpp will produce a bigger binary than with bstc. It's a fixed overhead though -- it's not a 13% difference, it's a fixed 102 bytes difference. So yes, if you have a PropBASIC program that needs exactly 32K of memory when compiled with bstc then it won't work when compiled with fastspin / spin2cpp. If your PropBASIC program has at least 102 bytes free then it will work. I think the latter scenario is more common in practice
Another way to think of it is that bstc is also adding overhead on top of the PropBASIC code (the size of the byte compiled PUB method), but its overhead is smaller than fastspin's because (a) it's using bytecode instead of PASM for the method, and (b) it uses support code from ROM instead of needing it in RAM.
Just noticed 102 bytes is not a long multiple, so I rechecked my file sizes, and found a typo, should be 756 bytes, giving 92B or 23L difference.
If that is a known, and fixed overhead, perhaps it should be documented ?