FORTH based Propeller assember for PropellerForth
Bazmundi
Posts: 3
Hey team,
I am a FORTH nut from way back and have had my interest rekindled because of the propeller chip and propelerForth.
It doesn't appear to have an assembler.
No problem, one of my favourite passtimes was writing assemblers in Forth.
Problem is I have found a piece of information on the bit fields for op codes used in the propeller but not the bit field contents and how they relate to op codes.
Has anyone got a table of propeller op codes and their bit field values?
Cheers,
Baz
I am a FORTH nut from way back and have had my interest rekindled because of the propeller chip and propelerForth.
It doesn't appear to have an assembler.
No problem, one of my favourite passtimes was writing assemblers in Forth.
Problem is I have found a piece of information on the bit fields for op codes used in the propeller but not the bit field contents and how they relate to op codes.
Has anyone got a table of propeller op codes and their bit field values?
Cheers,
Baz
Comments
When I was a Propeller newbie I had a go at writing a Forth for it. It didn't look pretty. Recently I revisited the Forth compiler as I had been doing some work with an ARM Forth that I had written a few years ago and I really wanted this kind of functionality with the Prop. On the ARM system I could hook up a keyboard and a monitor and access the SD card so it was a complete O/S as well, all with a CPU that costs the same as the Prop.
Sp using my honed PASM skills I tried a few different angles, even reading 4 byte tokens per long to keep the hub overhead down and keeping track of it all. Everything I tried so far shows up the inadequacies of the Prop architecture for a truly efficient Prop Forth. The best I think I could manage would be around 1 to 2 million Forth instructions per second. Ok, that's faster than Spin maybe but it felt kludgey. The hub access really slows things down but even the address interpreter takes way too many cycles. In ARM this is what it looks like:
NextIP: ldrb r1,[noparse][[/noparse]IP],#1 ; read the next byte TOKEN mov r0,#TOKENS ; create aligned pointer to token lookup table ldr pc,[noparse][[/noparse]r0,r1,lsl #2] ; execute token codeBear in mind I was running the ARM at 66MHz which meant that each instruction took around 15ns so the whole address interpreter executes faster than a single PASM instruction. But what about the primitives, take the SWAP instruction for instance, here it is in ARM:
H$ "SWAP" ,( n1 n2 -- n2 n1) ASMCODE _SWAP ldr sec,[noparse][[/noparse]PSP,#SEC] ; Get 2nd item str tos,[noparse][[/noparse]PSP,#SEC] ; save tos into 2nd str sec,[noparse][[/noparse]PSP,#TOS] ; save 2nd into tos mov tos,sec NEXTCompare this with a good Propeller Forth "PropForth" by Sal Sanci:
a_swap call #a_stpoptreg mov treg2, stTOS mov stTOS, treg1 call #a_stPush mov stTOS, treg2 jmp #a_nextThat doesn't look too bad although each instruction is much slower than ARM and there are more instructions including the subroutines. How about those subroutines then?
a_stpoptreg mov treg1, stTOS a_stPop if_never jmpret a_stPop_ret, # a_stPop_ret ' when task manager is loaded these addresses wil be patched add stPtr, #1 movs a_stPop1, stPtr cmp stPtr, #stTop wc,wz if_ae jmp # a_reset a_stPop1 mov stTOS, stPtr a_stPop_ret a_stpoptreg_ret retMy new version in PASM looks very efficient (used a simple PLUS primitive rather than my incomplete SWAP):
:addt movd :addt1,sp ' create destination field (TOS) add sp,#2 ' pop and point to second stack item (ascending stack) movs :addt1,sp ' create source field nop ' wait :addt1 add 0_0,0_0 ' add source to destination ret ' return to address interpreter (or caller) res 2 ' alll kernel primitves are multiples of 8 longs for fast direct token indexingBut all this is further let down by the limited assembler code that can be run in a cog, except for a handful of primitives the rest of the kernel has to be coded in high level tokens which are already slow.
My feeling is that the best Forth that can be implemented on the Propeller would still be a crippled Forth as well as hog resources and not leave room for much else. This is also a reason I advocate using a cheap ARM chip alongside the Propeller as Co-processors together. Let the Prop do what it does best as it is an I/O wizard but still a microcontroller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
While everyone else is flashing LEDs [noparse]:)[/noparse]
Even I was doing more advanced things back then. I was flashing the LED's backwards,.
@Peter
I always enjoy reading your posts and have learn plenty from your efforts. Thanks!
The best I can do is flash the LED's upside down. [noparse];)[/noparse]
Maybe we'll see some additional FORTH development.
We should encourage Peter to pick up work again on his version.
He has a brilliant mind when occupied by projects like this!