[Caml-list] embedded caml?

[A Joseph Koshy]

I am trying to get O'Caml to run in an extremely resource constrained
environment. To this end I am interested in getting the O'Caml
program to run in as small a memory footprint as possible (GC induced
latencies are not a problem).

Today using OCaml 3.02 on FreeBSD 4.3, a simple hello world program
like, >> print_endline "Hello World";; << translates to

o 8554 bytes of interpreter bytecode, and,
o 111945 bytes of executable code (using the -custom switch to
"ocamlc")

I would like to ask if anyone has considered Caml for embedded
applications?

Any suggestions as to where I should start looking?

Regards,
Koshy
<ko...@india.hp.com> Technical Consultant, HP-ISO, Bangalore.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr

[SooHyoung Oh]

I've thinking about using O'Caml in embedded system, too.

(1) Caml light
How about using caml light instead of o'caml?
A document says:
The runtime system (the part written in C) is about 100K, plus another 100K
of bytecode for the compiler.
The compiler itself is written in Caml Light and ``bootstrapped'' --
compiled by itself.

camlrun: ~50K
camltop: ~152K
stdlib.zo: ~400K
lib: *.zi, *.zix: ~318K

(2) Interpreter: ocaml
It seems that it needs "ocamlrun" at least.

ocaml: ~825K (compressed 169K)
ocamlrun: ~138K (compressed 55K)

(3) How to reference physical address.
Through Ocaml -> C interface.

---
SooHyoung Oh

[Christopher Quinn]

A Joseph Koshy wrote:
> Any suggestions as to where I should start looking?

Gerd Stolpmann does a re-package of the runtime part of the distribution which allows selective use of library modules, so that should bring down the static code size - about 20k without any modules I think.

try here:
http://www.ocaml-programming.de/packages/ocamlre

[Xavier Leroy]

> I am trying to get O'Caml to run in an extremely resource constrained
> environment. To this end I am interested in getting the O'Caml
> program to run in as small a memory footprint as possible (GC induced
> latencies are not a problem).
>
> Today using OCaml 3.02 on FreeBSD 4.3, a simple hello world program
> like, >> print_endline "Hello World";; << translates to
>
> o 8554 bytes of interpreter bytecode, and,

The ocaml bytecode linker, like the C linker, eliminates unused
compilation units; but as soon as you reference a function from the
Pervasives unit (e.g. print_endline), all of Pervasives gets linked
in. It is possible to construct a lightweight version of the standard
library, and/or bypass its use altogether. With that kind of hacks
you could get to less than 1K for "hello world".

> o 111945 bytes of executable code (using the -custom switch to
> "ocamlc")

Same answer. Some of the runtime system services (e.g. marshalling,
debugger interface, etc) can be eliminated if you don't need them.
However, more than half of these 111K are composed of the bytecode
interpreter and the GC / memory manager; you can't eliminate those :-)

> I would like to ask if anyone has considered Caml for embedded
> applications?

I don't think this has been considered much (unless you count as
"embedded" the Palm Pilot port of Caml Light that François Rouaix did
a while ago).

Generally speaking, I think Caml (and especially the Objective Caml
implementation) is not really suitable if you don't have a 32-bit process=
or
and at least a few hundred kilobytes of RAM. If your memory
constraints are tighter than this, I'm afraid a lower-level language
is required.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.f=
r/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.in=
ria.fr

[Alwyn Goodloe]

Xavier,

You are probably right BUT many embedded environments are approaching
what you describe. J2ME for example is intended to run in such an
environment. I've always said anything that Java can do OCAML
can do faster with less resources. Also note that OHaskell also
seems intended for similar apps. Seems like OCAML would work
just as well.

Alwyn Goodloe
agoo...@gradient.cis.upenn.edu

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr

[Xavier Leroy]

> You are probably right BUT many embedded environments are approaching
> what you describe. J2ME for example is intended to run in such an
> environment. I've always said anything that Java can do OCAML
> can do faster with less resources. Also note that OHaskell also
> seems intended for similar apps. Seems like OCAML would work
> just as well.

This is probably getting off-topic for this list. At any rate, I have
some experience working with smart cards, which are fairly small
embedded systems (a state-of-the-art smart card has an 8-bit
processor, 5 Mhz clock, 2K RAM, 16K EEPROM, 64K ROM), and I can say
with some confidence that all the system you mention (J2ME, etc)
definitely do not fit in such a small embedded system.

Like OCaml, J2ME won't work well unless you have a 32-bit processor
and a few hundred K of RAM. For Java, it's a big improvement over the
regular JDK implementation, which requires a few megabytes of RAM just
to start up. But viewed from a Caml standpoint, it basically took Sun
5 years to shrink their JVM to the point where Caml Light and OCaml
have been since the beginning. Don't be fooled by their marketing.

For smaller systems such as smart cards, Sun had to develop Java Card,
which is a much smaller subset of the JVM, where they throw out
garbage collection, threads, floating-point arithmetic, long integers,
and about 95% of the Java standard library. With these drastic cuts,
it fits on a smart card, but programming in Java Card is definitely
much lower-level than in full Java, and the benefits of using Java in
this context, as opposed to (say) UCSD Pascal, are not obvious.

So, I stand with my claim that if the original poster is interested in
embedded systems that do not have a 32-bit processor and at least a
few hundred K of RAM, then Caml is not appropriate, and C might remain
his best bet.

This said, there are plenty of bigger embedded systems where OCaml
could make sense. PDAs are a well-known example; network routers are
another. Heck, even the electronic ignition system in your car
probably consists in a PowerPC with a few megabytes of RAM.

- Xavier Leroy
-------------------

[A Joseph Koshy]

>>>> "Xavier Leroy" <xavier...@inria.fr> writes

A short summary of the information I received on my question,
and some stuff I found out after asking the question (for the
archives and for the curious).

o Squeezing the CAML runtime

Gerd Stolpmann's repackaging of the CAML runtime can bring the core
interpreter down to 20KB or so, with the needed modules being
dynamically linked in:

[ http://www.ocaml-programming.de/packages/ocamlre ]

o A proposed variant of ML that tracks memory usage using programmer
supplied annotations

Recursion and dynamic data-structures in bounded space: towards embedded ML programming
John Hughes, Lars Pareto
ICFP 1999

o The MLKit [ http://www.it-c.dk/research/mlkit/ ] supports SML'97 with the
compiler inferring memory allocation patterns.

Thanks to all who responded to my question.

Regards,
Koshy