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.