Spin & PropellerForth observations
Peter Jakacki
Posts: 10,193
I have just gotten back into playing with the Propeller and PropellerForth and would like to share some observations I have made.
Working with Spin is very easy but not very interactive but I also found that the Spin interpreter is very slow especially when accessing port pins in a bit-bashing fashion. This is what led me to consider writing a Forth for the Propeller but as a binary was available from Cliff I have been doing some tests with it.
For the purposes of ascertaining whether I could write a driver in high-level code I must know how well the code performs at the bit-bashing level. A simple way to test this is to toggle a port pin and see how fast it runs. If I toggle a pin at maximum rate from Spin the best that I get is a dismal 7.375kHz signal. Here is the code:-
From Cliff's PropellerForth I have written three different routines with interesting results as the one that I thought would be most efficient is not.
As you can see the TOGGLE3 routine achieves 172.4kHz which is certainly a lot faster than the Spin implementation but still has a lot of room for improvement. This however shows that it can be more efficient to write a bit-bashing driver in Forth than in Spin although of course assembler wins hands-down.
To achieve higher-speed I may write my own version of Forth anyway but I think even so that when Cliff gets his Forth a little more workable that it is something that is worth looking at.
Cliff, thanks for the play with Forth, however the serial driver is woeful, it doesn't matter how many zillion tasks could be run, it has to be loaded with code in the first place, something that requires very long delays between characters and does not always work reliably. Can you update this as a priority? TIA.
*Peter*
Working with Spin is very easy but not very interactive but I also found that the Spin interpreter is very slow especially when accessing port pins in a bit-bashing fashion. This is what led me to consider writing a Forth for the Propeller but as a binary was available from Cliff I have been doing some tests with it.
For the purposes of ascertaining whether I could write a driver in high-level code I must know how well the code performs at the bit-bashing level. A simple way to test this is to toggle a port pin and see how fast it runs. If I toggle a pin at maximum rate from Spin the best that I get is a dismal 7.375kHz signal. Here is the code:-
{{Output.spin
Toggles Pin without delay}}
CON
Pin = 0 { I/O pin to toggle on/off }
PUB Toggle
''Toggle Pin forever - output freq is 7.375kHz
dira[noparse][[/noparse]Pin]~~ 'Set I/O pin to output direction
repeat 'Repeat following endlessly
!outa[noparse][[/noparse]Pin] ' Toggle I/O Pin
From Cliff's PropellerForth I have written three different routines with interesting results as the one that I thought would be most efficient is not.
HEX
: TOGGLE1 \ 75.76kHz
DIRA L@ 1 OR DIRA L!
OUTA L@ DUP 1 OR SWAP 1 INVERTAND OUTA
BEGIN 2DUP L! ROT SWAP AGAIN ;
: TOGGLE2 \ 86.2kHz
DIRA L@ 1 OR DIRA L!
BEGIN
OUTA L@ 1 OR OUTA L!
OUTA L@ 1 INVERTAND OUTA L!
AGAIN ;
: TOGGLE3 \ 172.4kHz
DIRA L@ 1 OR DIRA L!
OUTA L@ DUP 1 OR SWAP 1 INVERTAND
BEGIN OVER OUTA L! DUP OUTA L! AGAIN ;
As you can see the TOGGLE3 routine achieves 172.4kHz which is certainly a lot faster than the Spin implementation but still has a lot of room for improvement. This however shows that it can be more efficient to write a bit-bashing driver in Forth than in Spin although of course assembler wins hands-down.
To achieve higher-speed I may write my own version of Forth anyway but I think even so that when Cliff gets his Forth a little more workable that it is something that is worth looking at.
Cliff, thanks for the play with Forth, however the serial driver is woeful, it doesn't matter how many zillion tasks could be run, it has to be loaded with code in the first place, something that requires very long delays between characters and does not always work reliably. Can you update this as a priority? TIA.
*Peter*
Comments
Glad to see someone's actually working with PropellerForth!
Version 3 may be the fastest because it sticks almost entirely to primitive ops (no colon definitions called). In the current PropellerForth, 2DUP is a colon definition, implemented as OVER OVER, because I'm awfully short on Cog RAM.
Colon definitions aren't that much slower, but the overall number of words executed is lower in versions 2 and 3, with 3 the lowest.
As I've mentioned in some other threads, I'm working on the serial driver now. I have a prototype of the Forth driver working, but my day job's been dampening my hacking speed. The current driver hasn't been holding me back, because I have the sources and can just cross-compile.
Edit: It may seem strange that I worked on (and released) the multi-tasking code before the serial driver. There's a good reason for it: without UART interrupts, the only reliable way to do full-duplex buffered serial communications is to spin it off into a separate Cog. The tasking code had to be stable to support this.
Post Edited (Cliff L. Biffle) : 11/24/2006 4:32:04 AM GMT
you have it running at the default 12mhz use xtal1 pll16 freq 5mhz setting
cheers
Ronald Nollet
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
You should get much better results
Ronald Nollet Australia
See, I need to play with this chip a bit more. (There is no such thing as work when it comes to processors, they do the work, we just poke them and prod them)
*Peter*
PropellerForth currently fixes the clock speed at 80MHz, assuming a 5MHz clock. This is a limitation in the assembler.
Has the "day job" stopped your work on FORTH?
I'm really looking forward to getting my hands on the source - so I build an application, with out streaming the text.
Really appreciate the job you are doing here.
Mike
Very nearly. Well, and there was a holiday in there too, in the states.
I've been trying to get better support for the Hydra, which uses a different crystal and has required changes to my assembler. I hope to get the sources up soon, but I'm short on time.
I have downloaded Cliff Biffle's PropellerForth and received a .binary file.
How do I get the propeller .spin loader to accept it?
EdKirkh
EdK@wi.rr.com
Gerry
And if I do succeed in loading the PropellerForth.binary, how do I interact with it?
In other words do I use the Spin Editor or must I go to one of the VGA thingies?
If so do I need another monitor program?
EdKirk
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
That seems to load my PropStick!
Good.
Now, How do I interact with it?
EdKirk