fastspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

191011121315»

Comments

  • Rayman wrote: »
    If you do this with "OBJ", then you must need some kind of Spin "Start" function to start the assembly cog, right?

    Sounds like you're saying to just do it the same way as with P1...

    Yes. The P1 way of doing objects seems to work well, and provides good namespace isolation and modularity. Did you have something else in mind?
  • Maybe it's OK. I'll have to try it out and see...
    Prop Info and Apps: http://www.rayslogic.com/
  • Are there version of FastSpin, Spin2CPP, and Spin2gui available for or planned for Linux?
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • Ah, yep, that's the native development environ. I see mention of Debian and Ubuntu explicitly.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • kwinn wrote: »
    Are there version of FastSpin, Spin2CPP, and Spin2gui available for or planned for Linux?

    There are no pre-packaged binaries, but the default for the source code is to build for Linux. I used to provide pre-built binaries for Linux, but nobody was downloading them. I think most Linux users prefer to build code themselves.

    The build process for fastspin/spin2cpp is very straightforward:
      git clone https://github.com/totalspectrum/spin2cpp
      cd spin2cpp
      make
    
    Binaries are placed in the "build" directory.

  • I've been working on getting my USB "boot protocol" mouse/keyboard host/drive converted to a spin object. I've got the USB controlRead/controlWrite transfer routines working and I can enumerate a device. Currently the code is all cog/lut execution, but I'm out of space. To get a device configured and transferring mouse/keyboard data will require hub execution too, and my first attempts at implementing it haven't gone well.

    Is "native" p2 hub execution in a DAT block supported by fastspin?

    I'm sure my woes are due to not fully understanding which addressing mode to use when calling hub code from cog/lut, but trying to determine the "right" way has me scratching my head::

    CALL #hubsub fails.
    CALL #\hubsub fails.
    CALL #@hubsub works.

    Aren't #2 and #3 essentially the same?

    #2 compiles to:
    01690     BC 0B A0 FD |                 call    #\testsub
    
    and #3:
    01690     D0 21 A0 FD |                 call    #@testsub
    

    I haven't found anything in the fastspin docs regarding hub execution in a DAT block of a spin object. If it is doable, IMO a "Cliff Notes" regarding JMP/CALL addressing "gotchas" for cog/lut/hub regions would be a welcome addition.

    Any insight would be greatly appreciated!
    Thanks!
    garryj
  • The four calls
       call #testsub
       call #\testsub
       call #@testsub
       call #\@testsub
    
    are potentially all different. "\" forces the call to be compiled as an absolute address rather than PC relative, and "@" forces the assembler to use the HUB address of testsub rather than the default address. The default address is the same as the HUB address after an ORGH, but is not the same after ORG. For example:
       ORGH $400
       ORG 0
       call #label1
       call #\label1
       call #@label1
       call #\@label1
    label1
       ret
    
    There "label1" is located in HUB memory at address $410, but its COG address is 4 (COG memory is addressed by longwords). So this is basically assembled the same as:
       call #4    ' will be assembled as a relative call in COG memory
       call #\4   ' will be assembled as an absolute call in COG memory
       call #$410  ' will jump to HUB memory (absolute call if we start in COG)
       call #\$410 ' always an absolute jump to HUB memory
    

    All this is the same in both fastspin and PNut, by the way.

    If you want to use hubexec in a Spin object, which is only available in fastspin, then I would recommend (a) using the most recent version of fastspin (3.9.25), and (b) always putting @ in front of labels used for HUB calls. (b) isn't always necessary in pure PASM code: if the last ORG type directive before a label was an ORGH then the label will have its HUB value by default, so label and @label are the same. But in Spin objects the compiler may not compute the HUB address of "label" correctly if there's no @ in front of it. It's not clear yet what the "official" Spin2 compiler will do in this case.
  • I think the backslash means absolute address.
    Don’t think that can work with spin...
    Prop Info and Apps: http://www.rayslogic.com/
  • garryjgarryj Posts: 265
    edited 2019-04-28 - 00:24:32
    ersmith wrote: »
    All this is the same in both fastspin and PNut, by the way.

    If you want to use hubexec in a Spin object, which is only available in fastspin, then I would recommend (a) using the most recent version of fastspin (3.9.25), and (b) always putting @ in front of labels used for HUB calls. (b) isn't always necessary in pure PASM code: if the last ORG type directive before a label was an ORGH then the label will have its HUB value by default, so label and @label are the same. But in Spin objects the compiler may not compute the HUB address of "label" correctly if there's no @ in front of it. It's not clear yet what the "official" Spin2 compiler will do in this case.
    Thanks, your info has removed the scales from mine eyes :smile:. It's been at least a decade since I last did anything meaningful in spin, and my aging brain is taking longer than I'd like to get back in the groove :blush:

    Thanks again for the quick response!
    garryj
  • IIRC there is details of the / @ etc label prefixes in the Tricks and Traps Reference thread and followup discussion in the Tricks and Traps Discussion thread. There are some gotchas here where the compilers seem to do different things. There is also reference to a further thread where its' discussed in more detail. I suggest you look at the listing to see what has been used where it really matters.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • @ersmith Here's a bug submission for SELECT CASE in BASIC.

    Code written in this manner only runs the code in ELSE, despite similar code listed in the basic.pdf manual.
    Issue: It will always just print "Something Other Than A or B Was Pressed" despite sending an A or B keypress over serial.
        PRINT "PRESS A or B"
        K$ = INPUT$(1)
        KEYPRESS = ASC(K$)
        PRINT " "; KEYPRESS
    
        SELECT CASE K$
        CASE "A"
          PRINT "KEY A Was Pressed"
        CASE "B"
          PRINT "KEY B Was Pressed"
        CASE "a"
          PRINT "KEY a Was Pressed"
        CASE "b"
          PRINT "KEY b Was Pressed"
        CASE ELSE
          PRINT "Something Other Than A or B Was Pressed"
        END SELECT
    
    PRESS A or B
    C 67
    Something Other Than A or B Was Pressed
    PRESS A or B
    B 66
    Something Other Than A or B Was Pressed
    PRESS A or B
    A 65
    Something Other Than A or B Was Pressed
    PRESS A or B
    
  • whicker wrote: »
    @ersmith Here's a bug submission for SELECT CASE in BASIC.

    Thanks for the bug report! The code wasn't at all doing what I wanted it to. I think I see how to fix it though, so it should work properly in the next release.

  • There are new versions available now of (3.9.26) of spin2gui and fastspin. The changes are:

    - Added DEF FNA(X)=X form to BASIC
    - Fixed declarations of functions inside other C functions
    - Fixed SELECT CASE in BASIC when the test is on strings or floats
    - Fixed an optimizer bug that affected local arrays
    - Fixed space allocation for local arrays in C functions
    - On P2, default to 160MHz and 230400 baud if no explicit clkset is given
    - Made BASIC read functions support base 16 and base 2 numbers
    - Implemented struct assignment for C
    - Experimental -z option to compress the code (produces smaller but slower code)

    The -z flag is only supported for P1 now, and is still quite buggy, so not ready for production, but eventually it will allow for smaller but slower code (like PropGCC's CMM mode).

    On P2 if no explicit clkset() is given before any output, we default to 160 MHz with 230400 baud. This makes porting programs much simpler (no need to add in the clkset and _setbaud calls).

    The C compiler support in fastspin is quite a bit better now, and is able to compile the dhrystone, xxtea, and fftbench benchmarks properly. I hope to update the C compiler benchmarks threads later.
Sign In or Register to comment.