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).
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.
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.
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?
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:
... 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.
... 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.
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).
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.
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?
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.
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.
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 ?
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):
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.
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.
Comments
Eric
Gives the following error: Propeller Board of Education.spin:96: error: expected function symbol 1
John Abshier
''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)John Abshier
Thanks
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)
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
Of course, only one or the other is actually compiled.
At the same 80 MHz clock speed the P1 takes 1748 ms in COG mode and 6170 ms in HUB mode.
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.
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
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.
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
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.
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):
The other alternative is to break Spin1 compatibility and use something else for random numbers, but I'd really rather not do that.
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
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.