Re: [Caml-list] Co-existence of byterun and asmrun impossible?

[Nuutti Kotivuori <naked+caml@naked.iki.fi>]

Alain Frisch wrote:
> On Fri, 12 Dec 2003, Nuutti Kotivuori wrote:
>
>> That is, a native compiled version of ocamlrun could never exist -
>> eg. no ocamlrun.opt nor ocaml.opt (native toplevel)?
>
> ocamlrun is written in C (no Caml at all), so the question does not
> make sense.

Right

> As for ocaml.opt, indeed, it cannot exist currently. AFAIK, there
> are some small differences between native and bytecode GC, that
> makes it impossible to have both at runtime in parallel.

I wonder if it could be this bit?

,----
| #ifndef NATIVE_CODE
| #define Is_atom(v) ((v) >= Atom(0) && (v) <= Atom(255))
| #else
| CAMLextern char * static_data_start, * static_data_end;
| #define Is_atom(v) \
|   ((((char *)(v) >= static_data_start && (char *)(v) < static_data_end) || \
|    ((v) >= Atom(0) && (v) <= Atom(255))))
| #endif
`----

Well, atleast that bit.

> Another consequence is that it is not possible to dynlink bytecode
> into a native compiled program (without the issue above, it would be
> enough to include the bytecode interpreter in the main program). In
> particular, no camlp4.opt, which is sad since it could greatly
> improve compile times (well, it is possible to build a custom
> camlp4.opt linked statically with .cmx syntax extensions, but this
> is not the usual way to use camlp4).

Right.

> Fabrice Le Fessant wrote the AsmDynlink library to load .cmo modules
> from a native program (including wrappers to make the values of the
> two world compatible). Fabrice: any news about an updated release?

Well, actually...

I went around and looked for AsmDynlink, and noticed it was a part of
CDK - and that it seems to be offering just the thing I was looking
for. All I needed for was the ability to compile the important bits
natively in the executable - and load bytecode dynamically during
execution, which doesn't have to be that fast at all.

I shall have to do some testing though to really believe it works :-)

So, ignore my whines before - I came to the conclusion that the only
reasonable combination of linking I was hoping for was bytecode
loading to a native code executable. Loading native code in native
code would ofcourse be cool as well, but I'm not sure how feasible
that is at all, considering that loading .o files to a running
executable, and manually doing the link phase for them at that point,
sounds like something people don't usually do :-)

-- Naked

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