[<<][libprim][>>][..]
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
out though:

  - 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.

Possible roads:

  - 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.



[Reply][About]
[<<][libprim][>>][..]