|
View:
New views
15 Messages
—
Rating Filter:
Alert me
|
|
|
Small Erlang VMDear 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 VMCorrado 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 VMMikael 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 VMHmm, 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 VMI 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:
-- 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 VMRobert 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 VMOn 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]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? > > > 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]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]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 VMGood luck!! Who knows, maybe you will create a "picoErlang" :)
On Thu, Jul 3, 2008 at 6:22 PM, Alpár Jüttner <alpar@...> wrote:
-- 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 VMDon'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" :) _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
|
|
|
|
|
Re: Small Erlang VM> 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 VMRaoul,
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:
-- 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 |
| Free Forum Powered by Nabble | Forum Help |