fastspin compiler for P2

124»

Comments

  • To save me the task of re-reading the whole thread again please...

    I want to run my Prop OS for the P1 on P2. It's mostly spin. So what is the best/quickest way to get this to P2? Will fastspin do this for me, and if so, link please? Thanks heaps guys.
    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)
  • https://github.com/totalspectrum/spin2gui/releases/latest/

    Download and unzip spin2gui.zip, then run spin2gui.exe. That's the GUI for fastspin (which is included in that archive). I hope it's fairly self explanatory, but not a lot of people have tried it yet so please feel free to ask any questions at all. I haven't tried PropOS, but it compiles most Spin programs (obviously the PASM has to be modified for P2). fastspin produces hubexec machine code rather than Spin bytecode, so anything timing dependent or otherwise relying on properties of the Spin interpreter may need changing.

    Eric
  • I tried compiling PropOS for P1 using fastspin, and it runs into a problem with running out of COG space (which you won't get in P2, since everything is hubexec; on P1 fastspin puts some utility functions like strcopy in COG memory). I've had that with some other P1 programs too, so I'm going to look and see what I can do to save COG memory. For P2 the Spin seems to compile, but the PASM has issues. In P2 mode temporary labels are ".foo" instead of ":foo". That's a bit of a pain; I wonder if we should make the assembler accept either form?
  • Would it be useful for PropOS (and similar purposes) to have a "relocatable output" flag for fastspin? Right now things in the DAT section are loaded via absolute HUB addresses. I think we could either create a simple relocatable executable format, or else generate code that fetches the PC at run time and uses that plus an offset to access data.
  • Thanks for the info Eric. I need to get my head back into the OS and work out how I want to use the stay resident hub code. Some of this is now in HUB ROM of course. I won't have a lot of time over the next week, but I am wanting to workout the best plan of attack.
    Many thanks for you help and fastspin. It certainly will beat having to recode spin into P2ASM.
    Ultimately though for this application, I think a spin Interpreter will be better placed, as code density is much better and speed here is unimportant.
    However, the compiler (basically it's a slightly modified version of Michael Park's Sphinx compiler) might be better done using fastspin as compiling on the P2 will likely be slow otherwise.
    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)
  • There's a new release for fastspin/spin2cpp (version 3.8.7). It's mostly bugfixes.

    Is anyone using spin2gui? The fastspin included with that is slightly out of date (it's 3.8.7-beta). I can update it if there's demand, but I haven't had any feedback so I'm not sure if there's a "market" for new releases.
  • I want to. May actually get freed up enough to setup again this weekend.

    Can just use last revision too.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • OK, since there may actually be a customer I have updated spin2gui to the latest fastspin. This version of spin2gui also includes propeller-load so you can use it on P1 as well as P2. You'll have to use the "Configure Commands..." menu item to switch between P2 and P1 development.

    Any feedback would be helpful. I know the GUI is pretty Spartan. I don't really think it should become a full fledged PropellerIDE type environment, but if adding one or two features can make it more usable I'd certainly be open to that.

    Eric
  • Eric,
    Just haven't had time to continue yet. I will be trying it out to build a P2 OS.
    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)
  • Aargh! I had prepared a 1.1.2 release for https://github.com/totalspectrum/spin2gui/releases, but I accidentally left it as a "Draft" release so it wasn't showing up. That's fixed now. It's not very different from 1.1.1, except for a few compiler bug fixes and the inclusion of propeller-load.exe for use on the P1.

    Eric
  • I've uploaded a new version of fastspin (and of spin2gui) that fixes the missing P2 "popa" instruction and supports "wrlong ptra++[5]". This version of fastspin can compile the Spin2 interpreter, which is kind of meta :).

    Besides the P2 fixes there are a few minor optimizations and other bug fixes. Under the hood there are big changes coming (such as support for the BASIC language as well as Spin) but that's not really ready yet.
  • ersmithersmith Posts: 2,420
    edited September 14 Vote Up0Vote Down
    Although the BASIC isn't ready (it's unfinished and undocumented) it is possible to run simple programs written in it on P2. I'm not sure if there's already a BASIC compiler or interpreter for P2; probably there is, but if not then perhaps this is the first BASIC program to run on P2 (the FPGA of course, although Chipmas is coming :) )
    '
    ' simple fibonacci demo
    '
    
    function fibo(n)
      if (n < 2) return n
      return fibo(n-1) + fibo(n-2)
    end function
    
    dim as uinteger cycles
    
    waitcnt(getcnt() + 80_000_000)
    print "BASIC fibo demo"
    
    let start = getcnt()
    
    for i = 1 to 10
      cycles = getcnt()
      let x = fibo(i)
      cycles = getcnt() - cycles
      print "fibo "; i; " = "; x,
      print "took "; cycles, "cycles ("; cycles / 80.0; " us)"
    next i
    

    Which produced this output:
    $ ./loadp2 fibo.binary -t
    [ Entering terminal mode.  Press ESC to exit. ]
    BASIC fibo demo
    fibo 1 = 1      took 147        cycles (1.8359 us)
    fibo 2 = 1      took 380        cycles (4.7500 us)
    fibo 3 = 2      took 600        cycles (7.5000 us)
    fibo 4 = 3      took 1048       cycles (13.0937 us)
    fibo 5 = 5      took 1732       cycles (21.6250 us)
    fibo 6 = 8      took 2876       cycles (35.9375 us)
    fibo 7 = 13     took 4708       cycles (58.7500 us)
    fibo 8 = 21     took 7656       cycles (95.6250 us)
    fibo 9 = 34     took 12380      cycles (154.7500 us)
    fibo 10 = 55    took 20060      cycles (250.5000 us)
    

    I have to confess to cheating a bit on the print: the floating point support isn't plugged in yet, but instead there is a dummy 16.16 fixed point framework. So I could print microseconds, but not milliseconds (80.0 fits in a fixed point number, 80000.0 does not).
  • ersmith wrote: »
    Although the BASIC isn't ready (it's unfinished and undocumented) it is possible to run simple programs written in it on P2. I'm not sure if there's already a BASIC compiler or interpreter for P2; probably there is, but if not then perhaps this is the first BASIC program to run on P2 (the FPGA of course, although Chipmas is coming :) )

    Wow, quite a milestone :)

    Can you include the sizes of the output choices, with those numbers ?

  • ersmith wrote: »
    Which produced this output:
    $ ./loadp2 fibo.binary -t
    [ Entering terminal mode.  Press ESC to exit. ]
    BASIC fibo demo
    fibo 1 = 1      took 147        cycles (1.8359 us)
    fibo 2 = 1      took 380        cycles (4.7500 us)
    fibo 3 = 2      took 600        cycles (7.5000 us)
    fibo 4 = 3      took 1048       cycles (13.0937 us)
    fibo 5 = 5      took 1732       cycles (21.6250 us)
    fibo 6 = 8      took 2876       cycles (35.9375 us)
    fibo 7 = 13     took 4708       cycles (58.7500 us)
    fibo 8 = 21     took 7656       cycles (95.6250 us)
    fibo 9 = 34     took 12380      cycles (154.7500 us)
    fibo 10 = 55    took 20060      cycles (250.5000 us)
    

    A quick port to FreeBASIC and a PC run gives this (no idea of the time precision, but I think I cloned getcnt() so it 80MHz Sysclk scaled .

    This is looking impressive :)
    BASIC fibo demo
    fibo 1 = 1    took 0        cycles ( 0 us)
    fibo 2 = 1    took 51       cycles ( 0.6375 us)
    fibo 3 = 2    took 26       cycles ( 0.325 us)
    fibo 4 = 3    took 51       cycles ( 0.6375 us)
    fibo 5 = 5    took 51       cycles ( 0.6375 us)
    fibo 6 = 8    took 51       cycles ( 0.6375 us)
    fibo 7 = 13   took 52       cycles ( 0.65 us)
    fibo 8 = 21   took 102      cycles ( 1.275 us)
    fibo 9 = 34   took 129      cycles ( 1.6125 us)
    fibo 10 = 55  took 154      cycles ( 1.925 us)
    
    The print's do not quite seem to have the same formatting ?

    Yours seems to have a couple of unexpected white spaces ?


  • .. and a larger run, seems to expand in time as expected ?
    BASIC fibo demo FreeBasic on PC Version
    fibo 1 = 1    took 0        cycles ( 0 us)
    fibo 2 = 1    took 26       cycles ( 0.325 us)
    fibo 3 = 2    took 26       cycles ( 0.325 us)
    fibo 4 = 3    took 26       cycles ( 0.325 us)
    fibo 5 = 5    took 51       cycles ( 0.6375 us)
    fibo 6 = 8    took 51       cycles ( 0.6375 us)
    fibo 7 = 13   took 51       cycles ( 0.6375 us)
    fibo 8 = 21   took 77       cycles ( 0.9625 us)
    fibo 9 = 34   took 103      cycles ( 1.2875 us)
    fibo 10 = 55  took 153      cycles ( 1.9125 us)
    fibo 11 = 89  took 179      cycles ( 2.2375 us)
    fibo 12 = 144 took 256      cycles ( 3.2 us)
    fibo 13 = 233 took 410      cycles ( 5.125 us)
    fibo 14 = 377 took 770      cycles ( 9.625 us)
    fibo 15 = 610 took 1104     cycles ( 13.8 us)
    fibo 16 = 987 took 1719     cycles ( 21.4875 us)
    fibo 17 = 1597              took 2771     cycles ( 34.6375 us)
    fibo 18 = 2584              took 4413     cycles ( 55.1625 us)
    fibo 19 = 4181              took 7210     cycles ( 90.125 us)
    fibo 20 = 6765              took 7697     cycles ( 96.21250000000001 us)
    fibo 21 = 10946             took 12496    cycles ( 156.2 us)
    fibo 22 = 17711             took 20142    cycles ( 251.775 us)
    fibo 23 = 28657             took 32560    cycles ( 407 us)
    fibo 24 = 46368             took 53471    cycles ( 668.3875000000001 us)
    fibo 25 = 75025             took 85314    cycles ( 1066.425 us)
    
  • That looks awesome, Eric!

    I added +/ and +//, like you suggested. Those are going to be important.

    Also, I added +>, +>=, +<, and +<= for unsigned comparisons.

    Whatever languages you make are going to be good, I'm sure.
  • jmg wrote: »
    Can you include the sizes of the output choices, with those numbers ?

    Default (hubexec mode) is 1920 bytes, cog mode is 1120 bytes. I wouldn't read too much into that, I suspect the hubexec just has some padding. The timings are pretty similar for small numbers (hubexec actually comes out slightly ahead for the first few calculations) but after a while cog mode pulls ahead; for fibo 10 it needs only 12773 cycles.

  • jmg wrote: »
    The print's do not quite seem to have the same formatting ?

    Yours seems to have a couple of unexpected white spaces ?

    I think FreeBASIC is putting a space in before the number (where a "-" would go if it were negative). fastspin isn't doing that. We can tweak it either way at some point, although personally I like having explicit control over the spaces.


  • jmgjmg Posts: 12,445
    edited September 14 Vote Up0Vote Down
    ersmith wrote: »
    I think FreeBASIC is putting a space in before the number (where a "-" would go if it were negative). fastspin isn't doing that. We can tweak it either way at some point, although personally I like having explicit control over the spaces.
    FB has that option, but the padding is not being done there and it seems your basic has more padding than FB ?

  • jmg wrote: »
    FB has that option, but the padding is not being done there and it seems your basic has more padding than FB ?

    Oh, I see. Yeah, mine is just printing a tab character whenever it sees a ',', so the tabbing is being done by the terminal program (to the nearest 8 character boundary, probably). FB does the tabbing itself using 14 character fields, if I recall correctly, so they won't match up. It's something that we can fix, but it's kind of low right now on the list of things that don't work properly :).
  • ersmithersmith Posts: 2,420
    edited September 14 Vote Up0Vote Down
    cgracey wrote: »
    That looks awesome, Eric!

    I added +/ and +//, like you suggested. Those are going to be important.

    Also, I added +>, +>=, +<, and +<= for unsigned comparisons.

    Whatever languages you make are going to be good, I'm sure.

    Thanks, Chip! Between Tachyon, fastspin, Dave's p2gcc, and your Spin interpreter the language situation for P2 is looking up.

    Eric
  • Just a note that I've updated fastspin and its GUI spin2gui. fastspin has some alpha quality support for compiling BASIC programs now, as well as continuing to support Spin for both P1 and P2. The version of the Spin language that fastspin compiles is something like Spin 1.5 (it has some Spin2 features but not all.) The BASIC language supported by fastspin is similar to FreeBasic, but not identical. You can use Spin objects in BASIC, and vice-versa.

    spin2gui should have everything you need to develop on an FPGA for P2, or a generic P1 development board.
  • Am I seeing it right that the same BASIC code can run on P1 or P2?

    It's interesting how BASIC can have .spin objects... Is this true also for P2 mode?

    Will future versions support both .spin and .spin2 objects in P2 mode?
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Am I seeing it right that the same BASIC code can run on P1 or P2?
    Yes. The only thing to watch out for is that inline assembly can be machine dependent (but I would think that should be obvious).
    It's interesting how BASIC can have .spin objects... Is this true also for P2 mode?
    Yes.
    Will future versions support both .spin and .spin2 objects in P2 mode?

    Not quite sure what you're asking. In P2 mode it can already compile existing .spin objects as long as they don't use PASM that's P1 specific. So generic Spin code can already be compiled on the P2, but any PASM parts will have to be translated to PASM2 (you can use #ifdef to keep the P1 support in there too).

    If you're asking whether fastspin will be completely compatible with Spin2 someday, it probably will but that will in part depend on what Spin2 looks like.
  • I saw that people are using FSRW.spin with BASIC in P1 mode.
    What are chances that would work as-is in P2 mode?
    Probably zero, right?

    But maybe just a P2 version of safe_spi.spin would fix it...
    Can object files have a .spin2 extension in BASIC?
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    I saw that people are using FSRW.spin with BASIC in P1 mode.
    What are chances that would work as-is in P2 mode?
    Probably zero, right?

    But maybe just a P2 version of safe_spi.spin would fix it...
    Right, you'd need to translate the PASM code in safe_spi.spin into PASM2 (or into generic Spin) before it could work. fsrw.spin itself seems to be pretty generic Spin and probably would be OK on P2.
    Can object files have a .spin2 extension in BASIC?

    Yes. Any extension other than ".bas" is treated as Spin code. As far as fastspin is concerned there's no difference between a ".spin" file and a ".spin2" file. The Spin parts are compiled to the appropriate processor based on whether the -2 flag is given, and the PASM parts have to match the processor or you'll probably get errors (some simple PASM might be able to compile on both, but that would be rare).

  • I have used FSRW on the P2, and it works fine. However, I use the original C version rather than the Spin code. FSRW was first written in C, and then it was converted to Spin using a Perl program. For the SPI driver I used sdspi.spin converted to a C file. This driver was written entirely in Spin, and contains no PASM. At some point I want to convert the SPI driver to pasm2 to increase the speed.
  • mmm, smartpin interrupt ... we can all have nightmares now.
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • There is a new fastspin release (version 3.9.9) at the usual locations:

    fastspin command line: https://github.com/totalspectrum/spin2cpp/releases
    spin2gui: https://github.com/totalspectrum/spin2gui/releases

    This release is mainly a bug fix one, although there are some P2 improvements (such as taking advantage of the ENCOD instruction).

    fastspin can compile Spin (with some Spin2 additions), PASM (either PASM1 or PASM2, depending on the processor selected), and BASIC (a FreeBASIC like dialect) into either P1 or P2 binary executables. Spin and BASIC objects may be freely mixed, so BASIC can call out to Spin objects and vice-versa. There is some facility for compiling C code as well, but that is still in extremely early stages and not really usable yet. On P1 the generated code uses LMM. On P2 the code is hubexec. In both cases there is an option (--code=cog) to compile into COG memory, but only very small programs will fit.

Sign In or Register to comment.