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.

thanks for any news.

There are two problems there:

1) Termite seems to be stagnant. Maybe stuff is going on behind the scenes, but it's not very visible.

2) DSGambit needs someone to pull it up to the latest version of Gambit.

Everybody would love to see it done, but nobody wants to do the work. ;)

If you want to give it a shot, we have a VMWare image of a Linux machine sitting around that has Linux, the DS development tools, and the patches up to 4.0b20 as a starting point. Just ask.

-a

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.