SPIN compiler...?
QUARKSPIN
Posts: 36
Would it be possible to precompile SPIN to ASM before downloading? I bet you could speed up your code a lot.(If it was smaller than 2kb.)
Comments
http://forums.parallax.com/showthread.php?t=124949#post932433
That link to Mike Green's comment is very interesting - I see that catalina and imagecraft and propbasic are using LMM (which enables the code to expand bigger than the space in a cog, and potentially to megabytes if using external ram, or gigabytes if using ram and an sd card).
To me, it seems that Basic and C are not very different to Spin. Kudos to those who wrote propbasic and C using LMM - that is not a task for the faint hearted. Doing something similar for Spin would be a fantastic achievement.
I've sometimes pondered a 'poor man's alternative - something that takes Spin and translates it to basic or C, then feed that code through the existing compilers.
Propbasic syntax guide is at the bottom of the first post of this thread http://forums.parallax.com/showthread.php?t=118611&highlight=propbasic
Even the very simplest bit of code would be a fantastic demonstration eg, Do/Loop, For/Next, If/EndIf and variables like A=5.
I suppose with Spin you would need to count the indents (tab or spaces) to work out where an If/Do/For finishes.
It can handle expressions, varible assignment, and whatever basic syntax just so happens to be the same as spin. It is less than a page of code, so don't expect anything fancy.
My error about BST. Since it is available for Linux I assumed the source was available.
Higher level operations, such as multiply, divide, bytemove, strsize and lookup could be implemented as calls into PASM routines that execute those functions. They would essentially be copies of the existing Spin interpreter code.
The converted Spin programs would have to be pretty small or they would use up the cog memory. A converted Spin program would probably run 2 or 3 times faster than interpreted Spin. It could be made even faster if cog memory was used instead of the stack. A peephole optimizer could be written to speed up the generated PASM even more by eliminating redundant stack pushes and pops.
Edit: I re-read the thread and it seems like my suggestion is just restating the last few posts. However, it does seem like the easiest way to generate PASM from Spin source.
For Prop2, why not just have Spin compiled to PASM or LMM via the Propeller tool, and use the silicon real estate for something more useful? Or load the Spin interpreter via binary from the Prop tool?
Note, I'm not saying get rid of Spin, just suggesting taking it out of the ROM.
Interesting thought.
Of course if it is not in ROM it would have to be loaded from RAM. Taking up 4K of the 32K on the Prop I would not be nice but on the Prop II might be reasonable.
Taking it out of ROM and having a mechanism that loads it from RAM at start up would make it replaceable, we could boot straight into Catalina's LMM interpreter or Zog and run C/C++ instead of Spin:)
As the ROM is so much bigger on the Prop II I would not worry about the space the Spin interpreter takes.
What "more useful" thing would you put in that space?
What I did suggest seriously is that Parallax might think about creating a better VM, that is more suited to C/C++ than the Spin VM, and target a standards compliant C compiler at that.
The reason I dared to make the suggestion is that Zog at least shows it is possible.
No.
Well, yes but...
Zog is a software "emulation" of the ZPU processor core designed by ZyLin Inc. for FPGA's.
Zog only exists because:
a) It's implementation is small enough to fit into one COG.
b) ZyLin targeted the GCC compiler at the ZPU.
Item b) is the main point here. If one were to add to the ZPU instruction set or change it in any way then one would have to modify the zpu-gcc compiler to make use of it. I do not have the skills, time or patients to undertake such a big endeavour.
Aside: Having got the first ever C code working on the Prop via the ZiCog Z80 emulator and the BDS C compiler (Still the only one that compiles C code on the Prop itself) I had tried to find a 16 or 32 bit CPU that could be easily emulated on the Prop and had an existing C compiler. I had just given up when I stumbled across the ZPU.
That said there are things I would change about the ZPU. It uses memory mapped IO which is a pain as the interpreter has to check every memory access for IO addresses thus slowing things down a bit.
The tea encryption algorithm performs modulus operations on unsigned ints for which there is no instruction, instead long winded ZPU subroutines are compiled in to do it. So unsigned mod and div would be nice.
But then again there are very few free opcodes to adopt for such things.
Well, I don't know... how about some A/D circuitry? Floating point circuitry? Something?
Having Spin hardcoded seems a bit against the minimalist-customize-your-own-device that the Propeller is promoting. Probably 75%+ of all of the threads here have something to do with bypassing Spin for either PASM, LMM, or some other language. PropBASIC compiles to PASM, other languages compile to LMM, and Spin seems like the minority choice. Heck, there are even improved Spin interpreters out there that people are loading instead.
As I said, don't get rid of it. Just take it out of the silicon, and use the space for something else that makes more sense to implement in hardware.
I might agree. Only on the Prop I having the interpreter not in ROM means it world be loaded into RAM at boot time, eating valuable RAM space. That's not such an issue with the bigger PROP II RAM but presumably it makes sense to have the Prop II as software compatible as possible.
May be 75% of posts here are related to developing alternate languages, compilers, interpreters. But I'm not sure we can conclude that 75% of users are building their projects with anything other than Spin/PASM.