fastspin compiler for P2

2»

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: 7,744
    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 !!!
    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)
  • 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?

  • jmgjmg Posts: 10,247
    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.
Sign In or Register to comment.