Sun Oct 10 16:29:30 CEST 2010
Answer original question: better GC for SC? NO.
It doesn't seem to be straightforward to add a CELL based GC to SC.
It seems better to write a compacting vector GC, which will make it
even slower. Then it really needs a more compact code representation
in the form of a byte code interpreter.
I think I'm going to give up on the idea. EX/SC/PF are for
"linux-size" hosts: couple of MB of RAM. Small embedded hosts need a
different architecture like CELL.
CELL can use LEAF, but probably it's best to refactor LEAF to remove
the dependency on malloc.
So where am I at? Is it worth writing a compacting vector GC?
Probably not, as I don't think it would bring me to the real target:
run the whole interpreter on an ARM target using about 32kB of RAM.
That really needs a different approach.
It would be interesting to figure out how much memory it uses on a
linux arm target with static libc.
Anyways.. It was a fun detour but the original idea seems to be a
no-no: there is no simple way to make it work on the AT91. That needs
a different approach. There are 2 interesting other things that came
- cell based GC is quite simple to implement
- a tree-walking ANF interpreter is also simple
- the road to a working byte-code version doesn't seem too hard to
walk, but is paved with a million trade-offs if efficiency is key.
- find the relation between the ANF treewalker and a straightforward
byte code version.
- see how this relates to the compiler. can the ANF be an
intermediate form so we can compile to a treewalker and a byte
code version without much extra effort?
- do the same for VM2 on top of EX.
- once the bytecode machine can work on SC _and_ reduce memory usage
(and increase speed?) then see about implementing a memory
efficient compacting vector GC.