Small Erlang VM

View: New views
15 Messages — Rating Filter:   Alert me  

Small Erlang VM

by Corrado Santoro :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

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

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Mikael Pettersson-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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
  be Erlang)
- 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

Google. Look for ACM's PLDI and various functional programming
conference proceedings, and maybe ASPLOS as well. OOPSLA is a
load of crap nowadays, but older ones can have interesting
implementation papers. I've seen some papers on small Scheme
systems from Guy Feeley's students that be interesting.

For GC consider some mark-sweep variation with compaction,
as copying collectors use more address space.
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Corrado Santoro :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

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

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Robert Raschke-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Edwin Fine-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...> 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%3A7035@...

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)
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Corrado Santoro :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

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

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Alpár Jüttner-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM [for Lego NXT]

by Bugzilla from roger.larsson@e-gatan.se :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM [for Lego NXT]

by Mikael Pettersson-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM [for Lego NXT]

by Richard A. O'Keefe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.


_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Edwin Fine-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

On Thu, Jul 3, 2008 at 6:22 PM, Alpár Jüttner <alpar@...> 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@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Joseph Stewart :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...>:
Good luck!! Who knows, maybe you will create a "picoErlang" :)


On Thu, Jul 3, 2008 at 6:22 PM, Alpár Jüttner <alpar@...> 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@...
http://www.erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Parent Message unknown Small Erlang VM

by johnspwolter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Joseph,

These all sound like good informational leads.  Considering the age of OCCAM I'd look to contrast it with Erlang as to whether Erlang offers newer features.  Many considerations would go into development environment selection.  As I look back over the last two decades the distributed and hard real-time control issue has been an ongoing for me and industry.  Today because of all the gadgets and sytems, this marketplace is huge.  Add to this the desire to be transparently interconnected locally and worldwide there appears to be an opportunity.

[Tangent Alert -- Here's a radical statement that should be a separate discussion thread.  Right now I think all the Object-Oriented language systems need an underlying runtime that is transparently current with a messaging infrastructure.   It may be that Erlang or the likes would be the way to provide that.  O-O needs a automatically distributed place(s) for object instances to run.  Bertrand Meyer in his book "Object-Oriented Software Construction" has a couple of chapter dedicated to runtime issues.  He does a fine job of linking O-O design needs to actual runtime behaviors needed.  Maybe all the distributed O-O runtimes at the core, should be based on Erlang like features.]

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/

The OCCAM came out of the Transputer developments of INMOS in the early 1980's.  I looked at it as a solution to distributed control at that time.  I have a complete copy of the original data books for the processor and as I recall I believe I have a microprocessor set in my chip collection.   They are almost 23 years old.

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.

Here's the Wikipedia link about Transputers for those interested, http://en.wikipedia.org/wiki/Transputer .

Here is one about OCCAM, http://en.wikipedia.org/wiki/Occam_programming_language .

It would be interesting to see some comparisons of concurrent languages.  Here's Wikipedia's short article which is interesting in that it lists many different languages.
http://en.wikipedia.org/wiki/Concurrent_programming

Intel created another specialized microprocessor that had messaging and features to support object-oriented environments.  It was the iAPX-432, it was a commercial failure.  Here is the Wikipedia link, http://en.wikipedia.org/wiki/Intel_iAPX_432   I think I also have a data book set and a chip set of this.

It appears to me that Erlang could find an important application range for use in hard real-time systems.


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


On Thu, Jul 3, 2008 at 6:22 PM, Alpár Jüttner <alpar@...> 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@...
http://www.erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions



--
John S. Wolter President
Wolter Works
Mailto:johnswolter@...
Desk 1-734-665-1263
Cell: 1-734-904-8433



--
John S. Wolter President
Wolter Works
Mailto:johnswolter@...
Desk 1-734-665-1263
Cell: 1-734-904-8433
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by Raoul Duke :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> way to provide that.  O-O needs a automatically distributed place(s) for
> object instances to run.

also look at http://www.mozart-oz.org/ which recently updated the
distribution mechanism used.
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

Re: Small Erlang VM

by johnspwolter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Raoul,

Thanks for the heads-up.  As I recall about Mozart it is more a soft-realtime system.  I'm starting to get the idea after looking around that no one open system has yet focused on the distributed realtime control problem as of yet.

I've more searches ahead.

On Sat, Jul 5, 2008 at 2:52 PM, Raoul Duke <raould@...> wrote:
> way to provide that.  O-O needs a automatically distributed place(s) for
> object instances to run.

also look at http://www.mozart-oz.org/ which recently updated the
distribution mechanism used.
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions



--
John S. Wolter President
Wolter Works
Mailto:johnswolter@...
Desk 1-734-665-1263
Cell: 1-734-904-8433
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions