Forum Update - Announcement about May 10th, 2018 update and your password.

fastspin compiler for P2

24

Comments

  • I've updated the first post with a new version of the compiler, with a few bug fixes. The compiler is starting to use the new ptra/ptrb addressing modes. I'm using ptra for the stack, and push/pop uses ptra++ and --ptra respectively. This helps quite a bit with recursive function timings (Fibonacci).

    Eric
  • This line: clkset(Mode, NewFreq) ' Switch to new clock mode immediately (and set new frequency) ' │ XTAL3 │ 32 │ 5 │

    Gives the following error: Propeller Board of Education.spin:96: error: expected function symbol 1

    John Abshier
  • Missing " in code below gives an appropriate error message. syntax error, unexpected identifier, expecting string. But it lock up the command prompt window. Ctl-c, Ctl-d, Ctl-z, enter or esc do not unfreeze the window. The only thing to do is close the window.
    ''Displays measurement from A3 input
    ''as number of 1024ths of 5 V.
    
    OBJ
                                      
      system : "Propeller Board of Education"
      adc    : "PropBOE ADC"                  
    '  pst    : "Parallax Serial Terminal Plus"
       pst : SimpleSerial"
    PUB Go | adcVal
                          
      system.Clock(80_000_000)  ' Clock -> 80 MHz 
    
      adcVal := adc.In(3)       'Measure A3      
      pst.Dec(adcVal)           'Display value   
                                '(1024ths of 5 V)
    
  • Servo32_Ramp_v2.spin (from the Propeller library) does not compile for the Prop 2 (-2 option) It has a syntax error, unexpected identifier on line 212. My guess is that it is ServoWidth1 which is a RES later. There is no error if I compile for Prop 1.

    John Abshier
  • Thanks for the bug reports, John! Most of these have been fixed in the git repository, and I hope to make a new binary release soon.
  • Just fabulous.

    Thanks
  • The new beta is posted in the first message. I think everything is almost complete now, except that the cog control functions (coginit/cognew/cogstop) are not implemented yet for P2; I have to track down the documentation on how those have changed.
  • cgraceycgracey Posts: 9,139
    edited May 2016 Vote Up0Vote Down
    ersmith wrote: »
    The new beta is posted in the first message. I think everything is almost complete now, except that the cog control functions (coginit/cognew/cogstop) are not implemented yet for P2; I have to track down the documentation on how those have changed.

    I'll get the 'COGINIT D/#,S/#' docs updated with the new release. In short:

    S/# = address or start of program

    D/# = exec mode, cog selector:

    %0_x_xxxx = load cog longs from hub at S[19:0] and jump to cog $000

    %1_x_xxxx = cog/lut/hub exec, no load

    %x_0_CCCC = Start cog %CCCC

    %x_1_xxx0 = start new single cog, C=1 if fail, D=cogid

    %x_1_xxx1 = start new even & odd cog pair, C=1 if fail, D=cogid of even cog (odd is +1)
  • Thanks, Chip. The other piece is the replacement for PAR. My recollection is that the initiating COG can use SETQ to put a value in the new COG's PTRA, and that the new COG's PTRB is set to the original S value (initial address or start of program). Is that (still) correct?

    Eric
  • ersmith wrote: »
    Thanks, Chip. The other piece is the replacement for PAR. My recollection is that the initiating COG can use SETQ to put a value in the new COG's PTRA, and that the new COG's PTRB is set to the original S value (initial address or start of program). Is that (still) correct?

    Eric

    Here's my doc-in-progress for the next release. There's a section on starting and stopping cogs:

    https://docs.google.com/a/parallax.com/document/d/1WVk_NHejFVTZzYv33SL1xPU5lHQXCiVwYS7DXK3Um2Y/edit?usp=sharing
  • ersmith wrote: »
    ... You could use inline assembly in fastspin though, something like:
    ...
    Not sure if this has already been asked - can fastspin use some conditional control, to inline both P1 and P2 ASM code, in a single source file ?
    Of course, only one or the other is actually compiled.

  • jmg wrote: »
    ersmith wrote: »
    ... You could use inline assembly in fastspin though, something like:
    ...
    Not sure if this has already been asked - can fastspin use some conditional control, to inline both P1 and P2 ASM code, in a single source file ?
    Of course, only one or the other is actually compiled.
    Yes. fastspin supports #ifdef/#else/#endif, and has a number of predefined symbols as specified in the README. One of them is __P2__ which is only defined if compiling for P2.

  • I've updated the first post with new versions of fastspin (the simple, openspin like interface to the compiler) and spin2cpp (the full featured interface). fastspin converts Spin code into PASM. With the "-2" switch it will produce P2 PASM (in a file with an extension of .p2asm) suitable for loading by PNUT. This version of fastspin implements object pointers using the syntax tentatively proposed in the Spin2 thread, and has preliminary support for the v16a instruction set. Theoretically it should compile all the instructions correctly, but that's not well tested and probably has bugs -- so the .binary files it produces are suspect, but PNUT can't load .binary at the moment anyway, so just use the .p2asm output.
  • I was curious about the performance difference between COG and HUB exec, so I ran the Fibo test program in both modes. I've attached the source code (fibo.spin and SimpleSerial.spin) and the compiled .p2asm for both versions. Results on my DE2-115 are:
    COG: fibo(28) = 317811 time  86390392 cycles (1079 ms)
    HUB: fibo(28) = 317811 time 149883709 cycles (1873 ms)
    

    At the same 80 MHz clock speed the P1 takes 1748 ms in COG mode and 6170 ms in HUB mode.
  • That's pretty good results. I imagine as you get more familiar with more of the P2 instructions and features, you might be able to get a bit more perf out of it.

    Also, is that running on the latest FPGA image? If so, nice work dude! Very cool.

    hubexec being only ~80% worse perf is also nice to see.
  • Roy Eltham wrote: »
    That's pretty good results. I imagine as you get more familiar with more of the P2 instructions and features, you might be able to get a bit more perf out of it.
    Yes, there's certainly still room for improvement.
    Also, is that running on the latest FPGA image? If so, nice work dude! Very cool.
    That's with the v16 FPGA image -- I think that's the latest one. Thanks. Fortunately the instruction set changes from the last version I supported in fastspin weren't too bad. Some instructions changed encoding, but mainly there were just instructions added (which fastspin doesn't use yet, obviously, but then compilers tend not to use most of the instructions in CISC computers).

    Eric

  • Nice work. Thank you. Play time ahead for me. :D
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • Excellent results for hub-exe vs cog-exec !!!
  • Good work on fastspin. It will be nice when the FPGA has the capability to load binaries. Maybe then you could add a loader and we could run Spin programs directly from fastspin.
  • Dave Hein wrote: »
    Good work on fastspin. It will be nice when the FPGA has the capability to load binaries. Maybe then you could add a loader and we could run Spin programs directly from fastspin.
    But the FPGA must already have the ability to load binaries. Someone just has to write a loader that uses the same protocol as Chip uses in PNut. Has he defined that anywhere? Is it similar to the P1 protocol?

  • David Betz wrote: »
    But the FPGA must already have the ability to load binaries. Someone just has to write a loader that uses the same protocol as Chip uses in PNut. Has he defined that anywhere? Is it similar to the P1 protocol?
    Only broadly similar.
    IIRC Chip changed to a 64b encode scheme, and uses an AutoBaud CHAR, and can support in the region of 2MBd max link speeds.
    The AutoBaud char is a NOP in the command map.
    At one stage, the plan was to support 2 AutoBaud chars, to indicate either one-pin, or two-pin modes.

  • Good work, ersmith! You may beat me to finishing a compiler.
  • OK, a year has passed and there have been many changes to the P2. I think I've caught up with them all though, and I've updated the first post with a new fastspin binary that supports the v32b instruction set.

    fastspin compiles a slightly extended version of the Spin1 language into binary for the Prop1 and/or Prop2. Rather than Spin bytecodes it produces PASM: LMM for the Prop1, and hubexec for the Prop2. The assembly languge it supports depends on the processor targetted (so it doesn't try to convert Prop1 instructions into Prop2 ones!). It does support #ifdef so you can include DAT sections for both processors, with #ifdef __P2__ for the Prop2 specific code.

    It does produce pretty fast code. In general I expect PropGCC to produce better results, but fastspin will usually be competitive. In fact it beats p2gcc on the fftbench benchmark :).
    Benchmark results:
    
    fftbench
    
    fastspin -2     42581 us
    p2gcc           56433 us
    riscvjit_p2     62489 us
    zog_p2	       239606 us
    
    xxtea
    
    p2gcc          12948 cycles
    fastspin -2    17523 cycles
    riscvjit_p2    61252 cycles
    zog_p2        169324 cycles
    

    riscvjit_p2 is the RiscV emulator for P2, running code compiled for RiscV with gcc. It uses a JIT compilation scheme where the RiscV instructions are translated to P2 instructions and kept in a cache in LUT.

    zog_p2 is, similarly, the ZPU interpreter for P2. It uses an XBYTE based interpreter which is more straightforward.
  • jmgjmg Posts: 11,659
    ersmith wrote: »
    It does produce pretty fast code. In general I expect PropGCC to produce better results, but fastspin will usually be competitive. In fact it beats p2gcc on the fftbench benchmark :).
    Looks nice,
    Is it easy to add P1 numbers in another column, so people can also do a P1-P2 comparison over like-tool-flows ?

  • jmg wrote: »
    ersmith wrote: »
    It does produce pretty fast code. In general I expect PropGCC to produce better results, but fastspin will usually be competitive. In fact it beats p2gcc on the fftbench benchmark :).
    Looks nice,
    Is it easy to add P1 numbers in another column, so people can also do a P1-P2 comparison over like-tool-flows ?

    I'll only quote the fastspin numbers, because those are apples to apples (there's a RiscV emulator for P1, but it has a completely different architecture):
          xxtea   fftbench
    P1:   34688    158597
    P2:   17523     42571
    


  • A question for everybody: I'm looking at updating the fastspin parser to handle more Spin2 elements. In particular, it seems the proposal for conditional assignment in Spin2 is to use
      a := (x > 0) ? x : -x
    
    rather than what fastspin currently supports:
      a := if x > 0 then x else -x
    
    There's some ambiguity around the use of ? as a random number operator. The parser will be able to handle it if we require that the condition always have parentheses around it, so:
      a := x ? y : z   ' this produces a syntax error because x? looks like a random number assignment.
      a := (x) ? y : z ' this is OK
    
    Does that seem acceptable? I think for complex expressions like (x<y) the parentheses are natural, so it's really only an issue for simple boolean variables.

    The other alternative is to break Spin1 compatibility and use something else for random numbers, but I'd really rather not do that.
  • rjo__rjo__ Posts: 1,945
    a := (x > 0) ? x : -x
    

    The more like Verilog that Spin2 can be ... the better.

    On the other hand... the more compatible Spin2 is with Spin1... the better.

    I guess sometimes you just can't win:)

    It is your baby, clean her up and throw her out.

    ...

    ...and

    THANKS
  • Will the original Propeller Tool be able to execute P2 Spin?(Spin2, I think)
  • The Propeller Tool hasn't been updated for 7 years, so I doubt that it will support P2 Spin. SimpleIDE, and then later, PropellerIDE were developed to support the P1. The PropellerIDE may be updated to support P2 Spin, or maybe a whole new IDE will be developed.

    It is possible to run P1 Spin on the P2. I got that working a few years ago for P2-Hot. So in that way it would be possible to use the 7-year old version of the Propeller Tool to write and run Spin programs on the P2.
  • Awesome! I really like the simplicity and functionality of the Propeller Tool, so it is good to know that some Spin1 stuff will work on the P2.
Sign In or Register to comment.