[erlang-questions] How small could an Erlang emulator be?
Tue Mar 13 23:32:23 CET 2007
On 13 Mar 2007, at 11:11 pm, Kenneth Lundin wrote:
> If is should be possible to run Erlang on the microkernels we are
> talking about a completely new Erlang VM with nothing in common with
> the one we have to day.
YES! That is exactly what I explicitly asked about!
> I even doubt if it is possible in practice to run it in a very limited
> environment like that.
Maybe, maybe not. If memory serves me correctly, Xerox Quintus
Prolog ran in
4 k-instructions of microcode on the Xerox D-machines (Dandelion,
Daybreak, ...) Erlang *ought* to be easier to emulate than Prolog,
doesn't have unification, trailing, or choice-points. Emulating on a
machine *ought* to be easier than emulating on the D-machines (at
110 and 1109), where the Smalltalk, Lisp, and Prolog VMs were 32-bit,
hardware memory interface was 16-bit, so each memory reference
ONE fetch page table entry and check it
TWO fetch/store one half of word
THREE fetch/store other half of word
Yes, virtual memory was actually done in the microcode. On a machine
IXP12xx, you would not bother with virtual memory. So we could
expect big savings..
> Another approach that is realistic is to run the Erlang VM and an
> Operating system
> on the general purpose processor and having some kind of linked in
> driver which supports execution of special code on the microkernels. I
> don't think we are talking about Erlang code executing there.
Running some form of Linux or OS/Kit on a 266Mhz (or slower)
StrongArm is not an
interesting problem. I don't say it isn't USEFUL, just that it
should not be any
kind of challenge. (Hullo, Mr 32-bit byte-addressed RISC! Hullo, Mr
operating system! ./configure; make; make install)
YOU may not be talking about executing Erlang code on the micro-
engines, but I *AM*.
That's the whole *POINT* of thinking about the question: COULD A
SUBSET OF ERLANG
BE A USEFUL LANGUAGE FOR HANDLING CONCURRENCY ON THE MICRO-ENGINES
OF A NETWORK PROCESSOR? Hmm, here's the actual focal sentence of my
> How could you make parallel programming EASY on one of these things?
Your answer appears to be "no, certainly not". But is there any
than emulator sizewhich would make it so? Is there any reason to
*couldn't* be done in 4 k-instructions (IXP 2xxx size)?
> So if we are interested in the minimal footprint of todays
> implementation (or something derived from that)
I can't speak for you, but I am NOT interested in that at all. As
long as the
emulator is smaller than my processor's I-cache, I'm happy. I see
no reason to
expect an abstract machine designed for speed to permit a specially
so I don't see an emulator derived from BEAM as >obviously< relevant,
though it would
be nice to be wrong.
> I think it is the
> memory limitations of the general purpose processor (ARM) that is
The StrongARM processor has no special limitations. If memory serves
(which it may
not), it has 128k on-chip I-cache, 128k D-cache, and can accept as
much off-chip DDR
SDRAM as any other StrongArm could.
Remember, the entire point of this thread is NOT "hey, if I had a
chip like this,
could I run Erlang on it, somehow, anyhow?", but "look, people are
trying to do
things with chips like these and they have to deal with concurrency
in remarkably unpleasant languages; Erlang looks as if it would be
useful to these
people if only they *could* use it; could they?"
So there are three questions of interest.
1. Would it be possible to use Erlang *at all* on these machines?
(At least for the IXP2xxx series, I am pretty sure that the
answer is "yes",
but it is *possible* that the answer might be "yes" for the
machines as well.)
2. Could Erlang be fast *enough* to be useful on these machines?
(For some applications, I suspect that the answer is NO. Why
else would the
IXP2xxx series have been made so much faster than the IXP12xx
series? But for
other applications, maybe.)
3. Would Erlang be a *good* language for expressing concurrency and
(I am very confident that the answer is "yes", but the only way
to really prove
it would be for someone to really try it. And they could only
try it if the
answer to Q1 were "yes".)
4. If performance isn't good enough, what would it be like to make
that ran an Erlang instruction set directly?
(But this is only an interesting question if Erlang is a good
language for the job.)
The guy who was trying to design an Erlang "standard cell" obviously
Erlang WOULD be a good language for low-level message handling. Was
More information about the erlang-questions