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

[ok]

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

On 14 Mar 2007, at 11:36 am, Robert Virding wrote:
> As Kenneth mentioned if you want a really small emulator it would be
> best to build a completely new one with that as the first priority.

Yes, exactly.  That's why the question used the indefinite article (AN
Erlang emulator), not the definite one (THE Erlang emulator that we  
have now).
[Yes, I remember JAM, and I think someone did another as well, plus  
of course
there's EtoS and GERL.  is anything but BEAM seeing active use/ 
development?]

> I wonder if the most compact wouldn't be to have a small byte code
> emulator based on a stack machine. No registers and stuff just
> operations on the top stack. Very regular and minimal. You would
> probably have to have a serious think about the memory model as  
> well to
> keep the memory management code small.

There is previous work on Scheme implementations for tiny machines.   
It did
seem possible that someone might have actually tried to make a small  
Erlang VM
at some point.  As for GC, it seemed to me that the simplest thing  
might be to
have a micro-engine dedicated to GC, and a thread that wants a GC  
would drop
out of the active thread pool into the GC thread pool.  Indeed, in a  
larger
system, one might have multiple micro-engines running GCs.  The  
possibility of
Erlang processes without shared heaps makes this architecturally  
pleasant.

> Trimming BIFs and library functions implemented in C would save some
> space removing network stuff and the general port mechanism. Maybe  
> even
> ETS but then would have difficulty running OTP.

If the question were "given a goal of running Erlang/OTP, how could  
these
machines be made to supply that need", running OTP would be an  
interesting
question.  Since my question is "given a goal of running concurrent
communication stuff on these machines, could Erlang be made to supply  
that
need", OTP is not interesting at all.  It would be much more useful  
to have
a library that could use the on-chip hashing support than ETS.

Think of an Erlang/IXP "system" as coming in pairs of nodes.  Each  
IXP chip
would have an Erlang/OTP node running a normal distribution, plus an IXP
node running on the micro-engines.  Processes in the IXP node would  
be able
to talk to each other, to the wires, and to the OTP node on the same  
chip.
If an IXP process wanted ETS services it would have a helper process  
running
on the OTP node acting on its behalf.  There's no need, therefore, to  
put
*everything* on the micro-engines.  The question is whether one can put
*enough* to make a pleasant language for doing packet filtering and  
routing
and whatever else people do with these chips.