[erlang-questions] Small Erlang VM [for Lego NXT]

[Mikael Pettersson]

Roger Larsson writes:
 > Target VM could even be an improved variant of the current NXT VM!
 > Download "MINDSTORMS NXT Executable File Specification.pdf" from
 >  http://mindstorms.lego.com/Overview/nxtreme.aspx
 > OK, no perfect fit to Erlang, but on the other hand you might see what is 
 > necessary to fit a VM on the NXT brick...
 > [No registers, static data - could be used as registers, and dynamic arrays]
 > 
 > Could the hipe code generator [otp_src_*/lib/hipe] be used for this by adding 
 > such an architecture?

The HW is ARM. HiPE has supported ARMv5 for several years now.
I run that natively reasonably often on my XScale boxes.
(Though right now my ARM boxes are busy building a glibc upgrade.
Yes I build everything native, cross-compilation is for lame wankers.)

 > But probably it is better to generate from Core Erlang (cerl) then from 
 > icode/rtl as we do not want registers anyway...

BEAM, ICode, and RTL are all heavily register-oriented. The
difference between them is that RTL is machine level, while
BEAM and ICode are imaginary Erlang-level assembly languages.

BEAM differs from ICode only in that ICode is the common entry
point into the HiPE compiler, and previously the system could
generate either BEAM or JAM VM code, both of which would be
translated to ICode before HiPE took over.

>From (Core) Erlang to a stack VM would be easy, then to a compact
byte-coded interpreter would also be easy.

 > > - high-level VM instructions
 > Some high-level VM constructs are compiled by hipe - to few?
 > cerl is better here too.

By high-level VM insns in this context I mean insns that would occur
during compilation to a high-level VM, but which do not currently
occur because the VM is too low level == requires too many insns for
simple or common operations.

BEAM actually is a quite low-level VM in terms of that kinds of
operations it offers. It _is_ suitable to translation to native
code or optimised direct-threaded code (what most Erlang users run),
but it isn't suited to a compact VM code representation.

 > > - build the application into the VM, so you can store the compiled
 > >   Erlang code in flash rather than RAM, leaving RAM used only for
 > >   dynamically allocated data
 > Could be done from a flash file system too - as done by the NXT today.

Only as an optimisation. If you want to really exploit the difference
between static and dynamic data (as would be necessary to fit a system
in 64KB of RAM), you need to describe such differences at compile-time.
And that IMO requires a different VM.

Not that I care that much. 64KB of RAM is so restrictive that I only
consider this an academic exercise. 1MB RAM would be a different story;
a couple of 100 KBs of flash plus 1MB RAM should be enough for a fairly
competent Erlang system.