[Caml-list] Bytecode size-RFC (Embedded ocaml)

[Christian Gillot <cgillot@gruposbd.com>]

Hi,

  Because of its inherent safety I think Ocaml is a good candidate
for embedded Linux (ie 32bit processor and good memory size,
not hard embedded applications, by example the iPAQ).
  I've setup a cross-compiler and apart some problems on floats
(hopefully resolved thanks to Xavier) it works great.
  There's a problem though : the code size. It's not a big deal,
because run time consume 150k and standards dlls (dllunix.so,
etc.) another 150k. 
  If you compile a hello world program you get a 10k program (that's OK)
  If you compile a hello world program that use a Unix module function
you get a 50k program (not so OK)
  And if you compile a lablgtk hello world program you get a 250k
(that's not OK).

Note that if you use a function or more of a module it does not
really increase the code size of the program.

So AFAIK there's two solution :
  1. at the compilation time get off all the functions of a module
that aren't used. (I'm not really sure that Ocaml links all
the functions of .cma in a program but it seems so.)
  2. Dynamically load ocaml-side of modules. It seems to be the
right solution but far more difficult to implement than the first one.
At the run time the program would load all the required functions
of a module from the .cma. At compilation time one must sign in
a way all the dynamic module functions. This could be done by
using as a signature the whole qualified name of the function, by
example Unix.getenv. (but would put UnixLabels if the programmer
would have put a module Unix = UnixLabels. What matters is the
whole qualified name for the runtime). To insure safety a module
could include a version number, so that bytecode doesn't need
to include type information.

I'm not asking Ocaml implementors to do it but rather :
- is there somebody working on such issue ?
- how could it be done in theory ? (Request For Comments ,o)

I'm willing to do it and would appreciate any hint. 
Note that embedded linux would definitely be a nice playground for ocaml
IMHO.

Best regards,

-- 
Christian Gillot <cgillot@gruposbd.com>
GNU/Linux programmer
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners