[erlang-questions] How small could an Erlang emulator be?
Tue Mar 13 01:34:36 CET 2007
On 13 Mar 2007, at 4:31 am, Thomas Lindgren wrote:
> A basic Prolog emulator can literally fit in the L1
> cache of a modern processor -- it's just a handful of
> kilobytes of code. But a mature, realistic language
> implementation also has a lot of other cruft, not just
> bignums and floats.
> For example, the largest object files for R10B10 on my
> computer are (obj.beam):
What they *are* is completely irrelevant to the question.
Remember the context: network processors where an ARM core controls
6 (IXP12xx) or
8 (IXP 2xxx) microengines, each microengine having 1 kword or 2
kwords (IXP12xx) or
4kwords (IXP 2xxx) of control store, and all of them sharing access
to possibly quite large
SRAM and SDRAM memories. This makes the size of the compiled .beam
files about as
irrelevant as possible (up to a few MB) because that's not the code
that has to fit into
2048 40-bit microinstructions. Only the EMULATOR has to do that.
Furthermore, the question is not "could we fit full Erlang/OTP on
these machines" but
"could we fit *enough* of Erlang on these machines to make Erlang a
good choice of
programming language, rather than the crippled C they actually
use". The IXP1200
hardware doesn't support floating point, and while the IXP2400 has a
multiplier, I don't
think the IXP12xx machines do. Certainly they have no divide. The
size of bigum support
does matter, because that has to be part of the emulator.
The rather vague thinking goes like this:
Erlang was designed for making reliable communication and
computing systems using
distribution and concurrency.
These machines are hardware designed for high-performance
concurrency, BUT the existing programming models (assembler and
crippled C) do not
make that easy to do.
Some recent PhD theses from Berkeley have done impressive things
trying to develop
design approaches to make it easier to produce effective
concurrent software for these
machines (and others like them). They talk about Click a lot.
Surely Erlang should be a good match for this problem domain IF
it can be squeezed onto
Of course these machines will only get bigger and faster with time,
so it's just a matter of waiting
until Erlang *can* run on them. But I remember there was someone
(whose name I have forgotten)
at Ericsson who was designing what was intended to become an Erlang
'standard cell'. Whatever
happened to that work? It's interesting to ask what "Erlang" (or a
could be useful on *now*.
More information about the erlang-questions