[erlang-questions] How small could an Erlang emulator be?
Wed Mar 14 00:38:10 CET 2007
When someone asks "how small could AN Erlang emulator be",
that means something quite different from "how small could THE Erlang
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
[Yes, I remember JAM, and I think someone did another as well, plus
there's EtoS and GERL. is anything but BEAM seeing active use/
> 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.
seem possible that someone might have actually tried to make a small
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
out of the active thread pool into the GC thread pool. Indeed, in a
system, one might have multiple micro-engines running GCs. The
Erlang processes without shared heaps makes this architecturally
> Trimming BIFs and library functions implemented in C would save some
> space removing network stuff and the general port mechanism. Maybe
> ETS but then would have difficulty running OTP.
If the question were "given a goal of running Erlang/OTP, how could
machines be made to supply that need", running OTP would be an
question. Since my question is "given a goal of running concurrent
communication stuff on these machines, could Erlang be made to supply
need", OTP is not interesting at all. It would be much more useful
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
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
to talk to each other, to the wires, and to the OTP node on the same
If an IXP process wanted ETS services it would have a helper process
on the OTP node acting on its behalf. There's no need, therefore, to
*everything* on the micro-engines. The question is whether one can put
*enough* to make a pleasant language for doing packet filtering and
and whatever else people do with these chips.
More information about the erlang-questions