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

[ok]

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,  
Dandetiger,
Daybreak, ...)  Erlang *ought* to be easier to emulate than Prolog,  
as Erlang
doesn't have unification, trailing, or choice-points.  Emulating on a  
32-bit
machine *ought* to be easier than emulating on the D-machines (at  
least the
110 and 1109), where the Smalltalk, Lisp, and Prolog VMs were 32-bit,  
but the
hardware memory interface was 16-bit, so each memory reference  
involved the
"D-machine waltz"
	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  
like the
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  
Unix-like
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  
message:

 > How could you make parallel programming EASY on one of these things?

Your answer appears to be "no, certainly not".  But is there any  
reason *other*
than emulator sizewhich would make it so?  Is there any reason to  
believe it
*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  
compact emulator,
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
> interesting.

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  
and communication
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  
smaller slower
      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  
communication of
     this kind?
      (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  
micro-engines
     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  
thought that
Erlang WOULD be a good language for low-level message handling.  Was  
he wrong?