Re: [Caml-list] calling native code from bytecode?

[Chris Hecker <checker@d6.com>]

>To handle these differences, the runtime system comes in two variants
>(libcamlrun.a and libasmrun.a), with suitable #ifdefs, different
>definitions of some runtime functions, etc.

Oh.  Bummer.

> My advice is: don't do it.  If all you need is to have the
>efficiency of native code and the debugging comfort of bytecode, just
>compile all your sources twice, to native-code and to bytecode.

It's not quite that simple.  I'm working on a video game, which is by nature a realtime simulation, and its behavior changes depending on how long frames take to compute.  So, if I can't optimize enough stuff in the bytecode version to keep it playable, I'm just going to have to switch to native code and give up on bytecode completely (giving up "debugging comfort" and the toplevel, which I've grown fond of).

The shame is that a few specific pieces of leaf code are taking the time, and since linking native code into bytecode is turning out not to be possible, they're going to force my entire project into native code.

If I get a complex bug that won't reproduce in the bytecode version because of the time-dependence and feedback, then I'm screwed.  Well, I'd be stuck debugging with printfs, which is actually what I'm doing now (plus #trace in the toplevel, which is very useful), but I was planning on getting the bytecode debugger to work under Windows as soon as I ran into something truly heinous.  That won't be an option if I have to switch to native code.

It seems like the right thing to do from an engineering standpoint is to rewrite these leaf functions in C because that will allow me to continue with bytecode and native code (plus I can debug the C trivially).  However, my entire "experiment" was to see if I could develop a commercial quality game in ocaml without dropping to C very often.  I find it slightly ironic that ocaml's environment is in some ways more friendly towards C than other ocaml code.

It does sound like I'm the only person who's ever requested this, so maybe others don't run into this problem.  

If I am actually insane enough to try to make this work correctly (fixing the closure problem and the runtime problem), would this be something that could make it into the distribution?

Chris


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