[erlang-questions] How small could an Erlang emulator be?

[James Hague]

>When someone asks "how small could AN Erlang emulator be",
>that means something quite different from "how small could THE Erlang
>emulator be".

There are a lot of possibilities here.  One of the largest, most
complex modules in the emulator is the one that turns generic BEAM
code into a list of threaded superinstructions.  Most of this could be
moved out to the compiler, but it would lock various optimizations
into the BEAM format itself.  If you're wanting to reduce the raw size
of the emulator, you could remove all support for these
superinstructions (a.k.a. combined instructions) at the expense of
performance.

Another option is to rewrite the core of the emulator in assembly
language for each processor (I'd write a custom mini-assembler in
Erlang first).  The advantage here is that you'd have tight control
over register usage and subroutine calling mechanisms and could strip
out unecessary fluff.  This likely wouldn't reduce code size by that
much, however.  It would be interesting to try to keep the entire
emulator in 16K or 32K so the whole thing fits in the instruction
cache.

Bjorn already suggested switching to 16-bit threaded code internally,
which would cut the size of loaded BEAM files in half (as it stands,
they get substantially inflated after loading).  If you hand-crafted
the emulator, this would be easy.

My biggest concern would be memory management.  Once you start
thinking about small memory systems, ones without memory mapping
hardware, then heap fragmentation becomes an issue.  On the
Playstation 2 projects I've worked on, there was no heap at all,
because all 32MB was packed with data and critical buffers.