[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