[gambit-list] Gambit and termite on an embedded system (Nintendo DS)?

Christian Jaeger christian at pflanze.mine.nu
Sun Jan 27 09:39:37 EST 2008


Raoul Duke wrote:
> hi,
>
> I'm curious to know how folks have fared in attempting to get things
> onto sundry embedded systems. E.g there are inexpensive-but-limited
> things like the Parallax Propeller which would be possibly neat to
> program via something like Termite.
>   

You should probably describe more precisely what you want to do.

 From what I read, the Parallax Propeller currently has 2KiB (512 32-bit 
words) of per-core memory, and 32KiB of global RAM which, if I 
understand correctly, is not directly executable by the cpu. (The next 
version of the Propeller is said to get 256KiB of global RAM.) This 
directly leads to two conclusions:

- you need to use an interpreter to be able to run bigger programs (i.e. 
run them from the global RAM (if you don't want to be copying position 
independent code chunkwise into the per-core memory)). So you need a mix 
of a fast and very small library (asm) routines, and interpreted code.

- I'm pretty sure you won't be able to squeeze the Gambit interpreter 
nor any other 'standard' Scheme interpreter into 2KiB RAM (including the 
necessary library routines like the GC, and stack memory); at least, you 
could probably get away with putting the heap into global memory.

- having to put the heap into global memory means that all cores have 
equally fast access to it. So that's already giving up on a 
multiprocessing approach where each process (or process group) has it's 
own copy of the data (to avoid synchronization overhead for heap 
accesses between the cpu's). You need to share the data because the only 
place big enough to hold it is shared ;). That means, you'd want a 
Scheme system which garbage collects a single heap which is being used 
by multiple cpu's. AFAIK there's currently no such Scheme system (they 
all use an approach where only one cpu is running the Scheme code at any 
one time and the same cpu is doing garbage collection; that's part of 
the reason why Termite and similar systems are interesting, they enable 
using multiple processors without requiring a global garbage collector).

So creating a Scheme system which is making good use of such chips will 
be the challenge here.

Maybe you wanted to suggest using multiple Propellers connected over an 
SPI bus and only run one Scheme system per Propeller and have them 
interoperate over SPI? Then the PICBIT Scheme system (*) may be the 
right starting point. (Of course you could then as well be using, say, 
multiple single-core PIC, AVR, ARM.. chips and interconnect them.)

(*) http://www.google.de/search?q=picbit+scheme
 
Also note the paper "Towards a Portable and Mobile Scheme Interpreter" 
by Adrien Piérard and Marc Feeley. That may provide a reference 
implementation (or maybe directly runnable on PICBIT) and a standard 
data encoding of Termite style multiprocessing (so you could send data 
and programs between a Propeller and a Scheme system running on a PC).

Of course you could be using Scheme for different tasks than run it 
directly on those chips, for example you could use a Scheme program to 
output assembler code instead of writing assembler manually (i.e. you 
could write a compiler for a small language of your choice in Scheme).

Christian.




More information about the Gambit-list mailing list