headers
Corrado Santoro | 3 Jul 16:19

Small Erlang VM

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.

Could anyone have some suggestions or pointers for such an idea?

Thanks.

All the best,
--Corrado

--

-- 
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty

Tel: +39 095 7382380        VoIP: sip:7035 <at> voicegw2.diit.unict.it

Personal Home Page: http://www.diit.unict.it/users/csanto
     NUXI Home Page: http://nuxi.diit.unict.it
==================================================================
Permalink | Reply |
headers
Mikael Pettersson | 3 Jul 17:57

Re: Small Erlang VM

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?

 > 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
- high-level VM instructions
- don't do excessive special-casing of simple instructions,
  that eats a lot of code space
- configurable set of BIFs and libraries
- maybe consider dropping some high-level language features,
  like live code upgrades
- if you're _really_ pressed for space, drop flonums
  (dropping bignums might be difficult if your implementation
  uses fixnums, but could save a lot of code space; for an
  embedded system you might be better off with a plain 32-bit
  integer type with overflow detection rather than sub-32-bit
  fixnums plus bignums, although the language wouldn't quite
(Continue reading)

Permalink | Reply |
headers
Corrado Santoro | 3 Jul 18:35

Re: Small Erlang VM

Mikael Pettersson wrote:
> Forget about BEAM, for a system this small you need to design
> the entire compiler/VM/interpreter from scratch for small space.
I was quite sure that I had to design the VM from scratch, but my idea 
was not to do the same for the compiler; I would like to start from the 
.beam file and write the interpreter, but, as far as I know, an official 
  specification of .beam and of the instruction set does not exist.

In any case, I'll follow your suggestions.

Thanks!

--Corrado

--

-- 
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty

Tel: +39 095 7382380        VoIP: sip:7035 <at> voicegw2.diit.unict.it

Personal Home Page: http://www.diit.unict.it/users/csanto
     NUXI Home Page: http://nuxi.diit.unict.it
==================================================================
Permalink | Reply |
headers
Robert Raschke | 3 Jul 18:48

Re: Small Erlang VM

Hmm, are you sure you meant Kilo in your mem sizes? The ARM7 sounds
likely to be used more in the Mega category (iPod etc.).

Robby
Permalink | Reply |
headers
Corrado Santoro | 3 Jul 19:35

Re: Small Erlang VM

Robert Raschke wrote:
> Hmm, are you sure you meant Kilo in your mem sizes? The ARM7 sounds
> likely to be used more in the Mega category (iPod etc.).
Yes, kilo kilo... I'm talking about the NXT Processor of the Lego 
Mindstorm robotic kit; there is a Java VM (leJOS) and I'm using it, but 
I wonder if I could do the same thing with Erlang :-)

--Corrado

--

-- 
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty

Tel: +39 095 7382380        VoIP: sip:7035 <at> voicegw2.diit.unict.it

Personal Home Page: http://www.diit.unict.it/users/csanto
     NUXI Home Page: http://nuxi.diit.unict.it
==================================================================
Permalink | Reply |
headers
Edwin Fine | 3 Jul 18:52

Re: Small Erlang VM

I understand why you would want to use Erlang, but instead of writing an entire interpreter with all the complexity that entails, would you consider using another language that is very good in extremely resource-restricted environments? FORTH comes to mind. If you just want to Get Things Done, that is; if you are constrained to use Erlang, that's a different matter.

On Thu, Jul 3, 2008 at 12:35 PM, Corrado Santoro <csanto <at> diit.unict.it> wrote:
Mikael Pettersson wrote:
> Forget about BEAM, for a system this small you need to design
> the entire compiler/VM/interpreter from scratch for small space.
I was quite sure that I had to design the VM from scratch, but my idea
was not to do the same for the compiler; I would like to start from the
.beam file and write the interpreter, but, as far as I know, an official
 specification of .beam and of the instruction set does not exist.

In any case, I'll follow your suggestions.

Thanks!

--Corrado

--
==================================================================
Eng. Corrado Santoro, Ph.D.
University of Catania - ITALY - Engineering Faculty

Tel: +39 095 7382380        VoIP: sip:7035 <at> voicegw2.diit.unict.it

Personal Home Page: http://www.diit.unict.it/users/csanto
    NUXI Home Page: http://nuxi.diit.unict.it
==================================================================

_______________________________________________



--
The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963) 
<div>
<p>I understand why you would want to use Erlang, but instead of writing an entire interpreter with all the complexity that entails, would you consider using another language that is very good in extremely resource-restricted environments? FORTH comes to mind. If you just want to Get Things Done, that is; if you are constrained to use Erlang, that's a different matter.<br><br></p>
<div class="gmail_quote">On Thu, Jul 3, 2008 at 12:35 PM, Corrado Santoro &lt;<a href="mailto:csanto <at> diit.unict.it">csanto <at> diit.unict.it</a>&gt; wrote:<br><blockquote class="gmail_quote">
<div class="Ih2E3d">Mikael Pettersson wrote:<br>
&gt; Forget about BEAM, for a system this small you need to design<br>
&gt; the entire compiler/VM/interpreter from scratch for small space.<br>
</div>I was quite sure that I had to design the VM from scratch, but my idea<br>
was not to do the same for the compiler; I would like to start from the<br>
.beam file and write the interpreter, but, as far as I know, an official<br>
 &nbsp;specification of .beam and of the instruction set does not exist.<br><br>
In any case, I'll follow your suggestions.<br><br>
Thanks!<br><div class="Ih2E3d">
<br>
--Corrado<br><br>
--<br>
==================================================================<br>
Eng. Corrado Santoro, Ph.D.<br>
University of Catania - ITALY - Engineering Faculty<br><br>
Tel: +39 095 7382380 &nbsp; &nbsp; &nbsp; &nbsp;VoIP: <a href="mailto:sip%3A7035 <at> voicegw2.diit.unict.it">sip:7035 <at> voicegw2.diit.unict.it</a><br><br>
Personal Home Page: <a href="http://www.diit.unict.it/users/csanto" target="_blank">http://www.diit.unict.it/users/csanto</a><br>
 &nbsp; &nbsp; NUXI Home Page: <a href="http://nuxi.diit.unict.it" target="_blank">http://nuxi.diit.unict.it</a><br>
==================================================================<br><br>
_______________________________________________<br>
</div>
<div>
<div></div>
<div class="Wj3C7c">erlang-questions mailing list<br><a href="mailto:erlang-questions <at> erlang.org">erlang-questions <at> erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br><br>
</div>
</div>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
</div>
Permalink | Reply |
headers
Alpár Jüttner | 4 Jul 00:22

Re: Small Erlang VM

On Thu, 2008-07-03 at 12:52 -0400, Edwin Fine wrote:
> I understand why you would want to use Erlang, but instead of writing
> an entire interpreter with all the complexity that entails, would you
> consider using another language that is very good in extremely
> resource-restricted environments? FORTH comes to mind. If you just
> want to Get Things Done, that is;

I don't think so. For example I'm working on a controlling application
which could probably run on the weakest possible hardware, but would be
a great struggle to implement in any sequential programming language
(because I need the various timers and complex scheduling of action and
handing of events).

For these kinds of tasks, Erlang fits extremely well. I think a
lightweight version of the erlang emulator could find a lot of
applications in this area. 

Best regards,
Alpar
Permalink | Reply |
headers
Edwin Fine | 4 Jul 05:16

Re: Small Erlang VM

Good luck!! Who knows, maybe you will create a "picoErlang" :)

On Thu, Jul 3, 2008 at 6:22 PM, Alpár Jüttner <alpar <at> cs.elte.hu> wrote:
On Thu, 2008-07-03 at 12:52 -0400, Edwin Fine wrote:
> I understand why you would want to use Erlang, but instead of writing
> an entire interpreter with all the complexity that entails, would you
> consider using another language that is very good in extremely
> resource-restricted environments? FORTH comes to mind. If you just
> want to Get Things Done, that is;

I don't think so. For example I'm working on a controlling application
which could probably run on the weakest possible hardware, but would be
a great struggle to implement in any sequential programming language
(because I need the various timers and complex scheduling of action and
handing of events).

For these kinds of tasks, Erlang fits extremely well. I think a
lightweight version of the erlang emulator could find a lot of
applications in this area.

Best regards,
Alpar





--
The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963) 
<div>
<p>Good luck!! Who knows, maybe you will create a "picoErlang" :)<br><br></p>
<div class="gmail_quote">On Thu, Jul 3, 2008 at 6:22 PM, Alp&aacute;r J&uuml;ttner &lt;<a href="mailto:alpar <at> cs.elte.hu">alpar <at> cs.elte.hu</a>&gt; wrote:<br><blockquote class="gmail_quote">
<div class="Ih2E3d">On Thu, 2008-07-03 at 12:52 -0400, Edwin Fine wrote:<br>
&gt; I understand why you would want to use Erlang, but instead of writing<br>
&gt; an entire interpreter with all the complexity that entails, would you<br>
&gt; consider using another language that is very good in extremely<br>
&gt; resource-restricted environments? FORTH comes to mind. If you just<br>
&gt; want to Get Things Done, that is;<br><br>
</div>I don't think so. For example I'm working on a controlling application<br>
which could probably run on the weakest possible hardware, but would be<br>
a great struggle to implement in any sequential programming language<br>
(because I need the various timers and complex scheduling of action and<br>
handing of events).<br><br>
For these kinds of tasks, Erlang fits extremely well. I think a<br>
lightweight version of the erlang emulator could find a lot of<br>
applications in this area.<br><br>
Best regards,<br>
Alpar<br><br><br>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
</div>
Permalink | Reply |
headers
Joseph Stewart | 5 Jul 19:07

Re: Small Erlang VM

Don't know if this helps, but there's a project leveraging the concurrency in the Occam-pi language by running a transputer interpreter on the Lego Mindstorm NXT and RCX(!!).

More details at:

http://www.transterpreter.org/

I'm a fairly new follower of this mailing list. Has the topic of transputers come up before? My understanding of the transputer architecture (and by consequence the transterpreter) is that it's stack-based rather than register-based... so performance may suffer compared to the Erlang VM.

-joe

If it ain't broke, break it. How else are you going to figure out how it works?

2008/7/3 Edwin Fine <erlang-questions_efine <at> usa.net>:
Good luck!! Who knows, maybe you will create a "picoErlang" :)


On Thu, Jul 3, 2008 at 6:22 PM, Alpár Jüttner <alpar <at> cs.elte.hu> wrote:
On Thu, 2008-07-03 at 12:52 -0400, Edwin Fine wrote:
> I understand why you would want to use Erlang, but instead of writing
> an entire interpreter with all the complexity that entails, would you
> consider using another language that is very good in extremely
> resource-restricted environments? FORTH comes to mind. If you just
> want to Get Things Done, that is;

I don't think so. For example I'm working on a controlling application
which could probably run on the weakest possible hardware, but would be
a great struggle to implement in any sequential programming language
(because I need the various timers and complex scheduling of action and
handing of events).

For these kinds of tasks, Erlang fits extremely well. I think a
lightweight version of the erlang emulator could find a lot of
applications in this area.

Best regards,
Alpar





--
The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)

_______________________________________________
erlang-questions mailing list
erlang-questions <at> erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions

<div>
<p>Don't know if this helps, but there's a project leveraging the concurrency in the Occam-pi language by running a transputer interpreter on the Lego Mindstorm NXT and RCX(!!).<br><br>More details at:<br><br><a href="http://www.transterpreter.org/">http://www.transterpreter.org/</a><br><br>I'm a fairly new follower of this mailing list. Has the topic of transputers come up before? My understanding of the transputer architecture (and by consequence the transterpreter) is that it's stack-based rather than register-based... so performance may suffer compared to the Erlang VM.<br><br>-joe<br><br clear="all">If it ain't broke, break it. How else are you going to figure out how it works?
<br><br></p>
<div class="gmail_quote">2008/7/3 Edwin Fine &lt;<a href="mailto:erlang-questions_efine <at> usa.net">erlang-questions_efine <at> usa.net</a>&gt;:<br><blockquote class="gmail_quote">
Good luck!! Who knows, maybe you will create a "picoErlang" :)<div class="Ih2E3d">
<br><br><div class="gmail_quote">On Thu, Jul 3, 2008 at 6:22 PM, Alp&aacute;r J&uuml;ttner &lt;<a href="mailto:alpar <at> cs.elte.hu" target="_blank">alpar <at> cs.elte.hu</a>&gt; wrote:<br><blockquote class="gmail_quote">
<div>On Thu, 2008-07-03 at 12:52 -0400, Edwin Fine wrote:<br>
&gt; I understand why you would want to use Erlang, but instead of writing<br>
&gt; an entire interpreter with all the complexity that entails, would you<br>
&gt; consider using another language that is very good in extremely<br>
&gt; resource-restricted environments? FORTH comes to mind. If you just<br>
&gt; want to Get Things Done, that is;<br><br>
</div>I don't think so. For example I'm working on a controlling application<br>
which could probably run on the weakest possible hardware, but would be<br>
a great struggle to implement in any sequential programming language<br>
(because I need the various timers and complex scheduling of action and<br>
handing of events).<br><br>
For these kinds of tasks, Erlang fits extremely well. I think a<br>
lightweight version of the erlang emulator could find a lot of<br>
applications in this area.<br><br>
Best regards,<br>
Alpar<br><br><br>
</blockquote>
</div>
<br><br clear="all"><br>
</div>
<div>
<div></div>
<div class="Wj3C7c">-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>

John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
</div>
</div>
<br>_______________________________________________<br>
erlang-questions mailing list<br><a href="mailto:erlang-questions <at> erlang.org">erlang-questions <at> erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote>
</div>
<br>
</div>
Permalink | Reply |
headers
Roger Larsson | 4 Jul 02:07

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
Permalink | Reply |
headers
Mikael Pettersson | 4 Jul 04:22

Re: Small Erlang VM [for Lego NXT]

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.
Permalink | Reply |
headers
Richard A. O'Keefe | 4 Jul 05:02

Re: Small Erlang VM [for Lego NXT]

I remember asking in this very mailing list, was it last year,
about optimising an Erlang system for small cores.  Since the
Erlang-on-FPGA project appears to have been abandoned, it's a
pity that the code has not been released.

I note that the PDP-11, with its 64 kB address space, had a
Prolog system, a Lisp, and a Pop-2.  Erlang on a smart card
(or NXT) would not be unreasonable.
Permalink | Reply |

Gmane