Shop OBEX P1 Docs P2 Docs Learn Events
fastspin: an LMM compiler for Spin — Parallax Forums

fastspin: an LMM compiler for Spin

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.

Comments

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

    -Phil
  • @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



  • jmgjmg Posts: 15,140
    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 ?

  • 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
  • jmgjmg Posts: 15,140
    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.Heater. Posts: 21,230
    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 :)
  • avsa242avsa242 Posts: 424
    edited 2023-05-25 22:47

    @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

  • 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).

Sign In or Register to comment.