Spin and Forth hybrid idea - obex + interactiveness + speed
Peter Jakacki
Posts: 10,193
A few weeks ago we were talking a little bit about Forth on this forum. It got me thinking at the time about an implementation that would still give me the best of both worlds, Spin and it's obex, and the speed and interactiveness of Forth. Well I have just posted a message on a Forth group about this very thing. I thought I would just repost it here along with the little introduction I used for the Propeller chip. I know there are some Forth people here.
Copy of message posted to tech.groups.yahoo.com/group/microcontrollerforth/
If any of you are not familiar with the Propeller chip then the best way to describe it is to think of eight 32-bit RISC cores with 512x32-bits of RAM each all connected to a central hub sharing a common 32K of RAM, 32K of ROM, and 32 fully shared I/O as well as ancillary functions such as clock etc.
As a microcontroller it is a fantastic chip but it is not the friendliest of architectures that I have come across for porting a Forth to. Some have implemented Forths but I haven't been satisfied with these implementations for a variety of reasons.
The 32K of RAM is loaded from a 32K I2C EEPROM on boot so this hub memory holds a stack based (at runtime) interpreted code with an interpreter loaded into the first core or cog. If any cog needs to be loaded with assembly code then this takes a 2K byte chunk out of that 32K bytes. Each cog is deterministic and runs at 20MIPS, no interrupts, and has 2x 32-bit counter/timers and a video hardware, not bad for an $8 chip!
So what happens is you start running out of RAM and if you want to do video then you are limited with what is remaining and remember, this is a microcontroller, not a general-purpose CPU so there is no external memory bus to add more memory.
The other thing is that there is tremendous support for software "objects" written in "Spin" and when you see what's there you have got to be *so crazy* not to use them. The forum itself never sleeps and I have just counted 12,400 topics alone, not just posts. So some objects load into a dedicated cog(s) and might just do something simple like buffered serial coms or modulated TV video, or play wav files.
What to do, what to do. Well, I have been thinking about this and harking back to the old RSC Forth we can see that it had a usable Forth in as little as 3K for the kernel plus I think it was 8K for the development ROM.
If I write a bare bones MISC style Forth kernel to run from the 512 longs of cog RAM then I have the modern equivalent of an R65F11 (kinda). Then rather than a development ROM running from the same CPU I could use the start-up cog which runs a Spin interpreter as the shell so it would interpret the text input and also provide the interface to the Spin objects. To conserve RAM I would keep a copy of the Forth headers in the top of the EEPROM taking advantage of the fact that this shadows the RAM which normally needs buffers for coms and video etc somewhere and the top of the 32K is a good place, so no code.
All that happens then is that a copy of the headers gets loaded into RAM at boot but then that normally gets wiped by the drivers using those buffers but we can still access the EEPROM directly for the headers.
So, it's a hybrid Forth in that we are using Spin to handle the development side of things but Forth in a cog or cogs for the runtime. BTW, Spin byte code is slow and you don't have the interactiveness that comes with Forth, although compile and load only takes a second or two.
In many of my systems I have SD Flash interfaced so it is just as easy to use that for storing headers and source code etc and there are plenty of objects that handle video and keyboards/mice etc so it is quite possible to have a single-chip (not including EEPROM) stand-alone Forth computer using an $8 chip. Of course there is always the option of combining an ARM and a Propeller which I have done before, but this is for those single-chip applications and playing directly with Propeller hardware.
Anyone interested? Any thoughts? Actually, what about a poll to see what hardware and software members are using and why.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Copy of message posted to tech.groups.yahoo.com/group/microcontrollerforth/
If any of you are not familiar with the Propeller chip then the best way to describe it is to think of eight 32-bit RISC cores with 512x32-bits of RAM each all connected to a central hub sharing a common 32K of RAM, 32K of ROM, and 32 fully shared I/O as well as ancillary functions such as clock etc.
As a microcontroller it is a fantastic chip but it is not the friendliest of architectures that I have come across for porting a Forth to. Some have implemented Forths but I haven't been satisfied with these implementations for a variety of reasons.
The 32K of RAM is loaded from a 32K I2C EEPROM on boot so this hub memory holds a stack based (at runtime) interpreted code with an interpreter loaded into the first core or cog. If any cog needs to be loaded with assembly code then this takes a 2K byte chunk out of that 32K bytes. Each cog is deterministic and runs at 20MIPS, no interrupts, and has 2x 32-bit counter/timers and a video hardware, not bad for an $8 chip!
So what happens is you start running out of RAM and if you want to do video then you are limited with what is remaining and remember, this is a microcontroller, not a general-purpose CPU so there is no external memory bus to add more memory.
The other thing is that there is tremendous support for software "objects" written in "Spin" and when you see what's there you have got to be *so crazy* not to use them. The forum itself never sleeps and I have just counted 12,400 topics alone, not just posts. So some objects load into a dedicated cog(s) and might just do something simple like buffered serial coms or modulated TV video, or play wav files.
What to do, what to do. Well, I have been thinking about this and harking back to the old RSC Forth we can see that it had a usable Forth in as little as 3K for the kernel plus I think it was 8K for the development ROM.
If I write a bare bones MISC style Forth kernel to run from the 512 longs of cog RAM then I have the modern equivalent of an R65F11 (kinda). Then rather than a development ROM running from the same CPU I could use the start-up cog which runs a Spin interpreter as the shell so it would interpret the text input and also provide the interface to the Spin objects. To conserve RAM I would keep a copy of the Forth headers in the top of the EEPROM taking advantage of the fact that this shadows the RAM which normally needs buffers for coms and video etc somewhere and the top of the 32K is a good place, so no code.
All that happens then is that a copy of the headers gets loaded into RAM at boot but then that normally gets wiped by the drivers using those buffers but we can still access the EEPROM directly for the headers.
So, it's a hybrid Forth in that we are using Spin to handle the development side of things but Forth in a cog or cogs for the runtime. BTW, Spin byte code is slow and you don't have the interactiveness that comes with Forth, although compile and load only takes a second or two.
In many of my systems I have SD Flash interfaced so it is just as easy to use that for storing headers and source code etc and there are plenty of objects that handle video and keyboards/mice etc so it is quite possible to have a single-chip (not including EEPROM) stand-alone Forth computer using an $8 chip. Of course there is always the option of combining an ARM and a Propeller which I have done before, but this is for those single-chip applications and playing directly with Propeller hardware.
Anyone interested? Any thoughts? Actually, what about a poll to see what hardware and software members are using and why.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The advantages then of using Forth are basically:
1) Speed and compactness of high-level code
2) Language Extensibility
3) Interactive development and debugging (great for what if's and tinkering with the guts of the hardware)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*