[Caml-list] avoiding native call from bytecode issue via dynamic linking

["Jeff Henrikson" <jehenrik@yahoo.com>]

Has anybody considered sidestepping the native/bytecode compatablity issue in favor of an all native toplevel?  That is, one which
takes an expression, compiles it to native code, and loads it back in to code space?  For example, write it out to a shared lib,
either one for each expression (or more likely for efficiency) one for some reasonably sized history of expressions.  Then dlopen
and dlsym the symbols into place.

Once upon a time when I briefly tried to work with SML/NJ, I saw little temp files being written to disk all the time when I was
evaluating expressions from an sml session in emacs.  I presumed their purpose was getting code to cross the data/code barrier.  I
don't think they were standard shared libs under windows or linux because they were often only a few hundreded bytes- too small to
be a real shared lib.


Jeff Henrikson


Markus Mottl [markus@mail4.ai.univie.ac.at] on 9/25/01
>It would be really nice if there were ways to call OCaml-native code
>from OCaml-byte code. This question has popped up in the past, but it's
>not an easy thing to do due to issues with the runtime:
>  http://caml.inria.fr/archives/200108/msg00026.html
>Any news in this respect? A toplevel that could run a high-performance,
>OCaml-native code string matching engine would give a terrific scripting
>environment!

Chris Hecker [checker@d6.com] on 9/25/01:
> I was going to reply to that same quote and reiterate my desire to link native and bytecode!  :) That was the thread I
> started you've linked to, here's the beginning: http://caml.inria.fr/archives/200108/msg00008.html.
>
> It's such a shame that we're pushing ocaml code into C because of this limitation.  This seems incredibly ironic and sad to me.







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