Re: Small Erlang VM [for Lego NXT]

I have also been looking into running Erlang on a NXT brick...
It would be extra cool since  Erlang was Danish mathematician
  http://en.wikipedia.org/wiki/Agner_Krarup_Erlang

On Thursday 03 July 2008, Mikael Pettersson wrote:
> Corrado Santoro writes:
>  > Dear all,
>  >
>  > I would like to have an erlang VM onto a small embedded system, that is
>  > an ARM7 machine, with 256K of flash and 64K or RAM. I have in mind
>  > something like the BEAM emulator and only a minimal subset of libraries
>  > and OTP system.
>
> Forget about BEAM, for a system this small you need to design
> the entire compiler/VM/interpreter from scratch for small space.
>
> I assume the ARM7 has Thumb(-1) but not Thumb-2?
It is a AT91SAM7S256. I find no reference to Thumb-2.

>
>  > Could anyone have some suggestions or pointers for such an idea?
>
> Off the top of my head:
> - stack-based VM with implicit operands, easy to compile
>   to and quite compact
Yes, but it is important to remember that the programs that will run on the 
NXT brick is a lot smaller in itself than most Erlang programs. I would say 
thousands lines of code rather than millions, short lists - lengths of ten.
Number of processes probably less than ten too... But Corrado Santoro might 
have actual application sizes for this type of applications.

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?

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

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

> - don't do excessive special-casing of simple instructions,
>   that eats a lot of code space
> - configurable set of BIFs and libraries
Not only set of libraries, configurable function lists of each library...
Can Compiler/dialyzer produce a list of used libraries and functions, 
recursively?
Then this could be done automagically - regenerate all modules whose lists 
differs, not generating unlisted functions.

> - maybe consider dropping some high-level language features,
>   like live code upgrades
Probably, since this would require a flash file system, to be able to 
"replace" an old module with a new bigger one - it would be cool!

> - 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.

/RogerL