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

Christian Jaeger christian at pflanze.mine.nu
Mon Jan 28 21:22:20 EST 2008


I wrote:
> (Of course you could then as well be using, say, 
> multiple single-core PIC, AVR, ARM.. chips and interconnect them.)
>   

It occurred to me that maybe the Propeller would best be used in the 
following way and could then potentially offer an advantage in the 
responsiveness area in comparison to single-core cpus:

dedicate:
- one core (or more) to reading and interpreting byte code [and doing 
memory allocation]
- one core to handling serialization requests and doing SPI writes
- one core to handling SPI reads and deserialization and handing back 
the data to the interpreter core
- one core to garbage collection (preferably in a way that never 
requires the above cores to stop processing [except possibly in out of 
memory situations])
- other cores to running asm library routines (triggered by the interpreter)

This way there may be enough per-core memory for each task, and the 
multiprocessing might actually speed things up a bit; the most 
interesting thing might be that since garbage collection would run 
concurrently all the time, iff the allocator is running in deterministic 
time, you'd get a Scheme system which would satisfy hard realtime 
requirements. (Well, you could get almost the same thing from a 
single-core cpu and a real-time operating system with a lower-priority 
thread dedicated to garbage collection [maybe with scheduling of the 
lower-priority thread postponed to safe points in the interpreter?]. The 
difference being the time required for the task switch (but that 
shouldn't be very relevant compared to the speed of an interpreter).) I 
don't know how to write a GC right now so that the interpreter can 
resume execution at any point in time, though (look into the incremental 
GC paper from Marc from a few years ago).

(Back to other work.)

Christian.




More information about the Gambit-list mailing list