fastspin: an LMM compiler for Spin

ersmith

Here is fastspin v3.0.5, an LMM compiler for Spin. fastspin is (mostly) command line compatible with openspin, bstc, and similar tools, but instead of producing spin bytecodes it produces LMM PASM code. This means that the binary files produced by fastspin are much faster (typically 4-5x faster) but also much bigger (typically 2-3 times bigger) than "ordinary" Spin binary files.

fastspin is a custom version of spin2cpp, which is a tool to convert Spin code to C, C++, or PASM. The spincvt GUI for spin2cpp may be of interest to you if you like fastspin, but fastspin doesn't need any other tools.

Phil Pilgrim (PhiPi)

This sounds really cool! Thanks for making it a reality!

-Phil

msrobots

@ersmith,

luckily you have some free time on your hands. FastSpin might come in handy for me, I like PASM but SPIN just has is own charm. I played around with used PropBasic to create some code to study, but doing it with SPIN will be quite nicer for me.

Following the thread about spin2cpp you really are on the run there. I really hope you can get your code generator to produce PASM2 code also, because that would allow a lot of projects out of code-space (hub) to move over to the P2 whenever it will be there.

Not using specific P2 features, just porting over easy. with 512KB the bigger code size does not matter.

Do you use the same LMM kernel as in PropGCC? It would be nice if external memory could be supported, so the increased binary size would not be a problem for a P1. Just add some SPI ram to the board.

I tried it on two of my projects but - run out of the 32K.

I will test more next weekend, but anyways I am bowing deep to you.

Thanks,

Mike

jmg

msrobots wrote: »

I tried it on two of my projects but - run out of the 32K.

Can you give some numbers, always nice to get real reference points ?

ersmith

msrobots wrote: »

Following the thread about spin2cpp you really are on the run there. I really hope you can get your code generator to produce PASM2 code also, because that would allow a lot of projects out of code-space (hub) to move over to the P2 whenever it will be there.

The P2 code generator is coming along, but taking longer than I had hoped. The P2 adds a lot of new instruction formats, and a lot of new instructions, and it's a bit of a pain supporting them all.

Do you use the same LMM kernel as in PropGCC? It would be nice if external memory could be supported, so the increased binary size would not be a problem for a P1. Just add some SPI ram to the board.

No, the fastspin LMM kernel is quite a bit simpler than PropGCC's, and there's no external memory support. XMM would be a fairly big undertaking, so I don't think it will happen anytime soon.

Thanks for your kind words,
Eric

jmg

ersmith wrote: »

The P2 code generator is coming along, but taking longer than I had hoped. The P2 adds a lot of new instruction formats, and a lot of new instructions, and it's a bit of a pain supporting them all.

Then just start with a subset ? Enough to get something 'ticking over' ?
If you could list the opcode coverage of the created output, that could help test coverage.

Heater.

Awesome Eric. Have to try and find time to check it out.

Sorry but with my blurry eyes this morning I read the the threads title as "fatspin: an LMM compiler for Spin".

Which I guess is true, fast and fat

avsa242

@ersmith

Should function pointers declared in a child object be callable from the parent in spin1? (or is it a no-no related to the parent having only read-only access to the child vars?)

If I try something like the below, I get either what looks like nothing happening, or what looks like memory corruption (serial terminal gets spammed).
I have been able to work around it by creating a middleman method in the child object, which in turn calls the plot function. Calling the middleman from the parent works fine.

'child object
var

    long plot    ' calling directly from the parent causes problems

pub init(pptr)

    plot := pptr

pub middleman(x,y,c) ' OK

    plot(x,y,c)

'parent object
obj

    disp:"some.display.driver"
    ch:"child"

pub main()

    ch.init(@disp.plot)
    ch.plot(1, 2, 3) ' fails
    ch.middleman(1, 2, 3) ' OK

BTW sorry for the resurrection...this seemed like the closest to appropriately titled existing thread.

Cheers

ersmith

It seems to work for me; I tried both with the ASM and bytecode output modes and the attached example works. Note that function pointers do take some heap space, so if you're using heap for anything else you may need to increase the heap size (particularly on P1).