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.
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.
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.
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.
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.
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.
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.
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).
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 ?
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.
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.
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 ?
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 .
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?
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...
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.
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.
Comments
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.
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
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.
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.
Can just use last revision too.
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
Just haven't had time to continue yet. I will be trying it out to build a P2 OS.
Eric
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.
' ' 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 iWhich produced this output:
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).
Wow, quite a milestone
Can you include the sizes of the output choices, with those numbers ?
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
The print's do not quite seem to have the same formatting ?
Yours seems to have a couple of unexpected white spaces ?
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.
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.
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.
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
Thanks, Chip! Between Tachyon, fastspin, Dave's p2gcc, and your Spin interpreter the language situation for P2 is looking up.
Eric
spin2gui should have everything you need to develop on an FPGA for P2, or a generic P1 development board.
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?
Yes.
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.
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?
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).
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.
This is doing something, Pin#0 is toggling and I think there may be VGA output, but screen is black...
This VGA demo from Chip works from fastspin without the added Spin...