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

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

[Nuutti Kotivuori]

It took me a while to realize this - and I just wish to make sure that
I haven't misunderstood anything.

The byterun and asmrun parts cannot co-exist in a single executable?

It's possible to *compile* native code with a compiler in bytecode,
and to compile bytecode with a compiler in native code, but it is not
possible to *run* bytecode with an executable that isn't bytecode? 
That is, a native compiled version of ocamlrun could never exist -
eg. no ocamlrun.opt nor ocaml.opt (native toplevel)?

I never thought of this before - it seems rather natural, but it's
still a bit of a bummer. This means that if a program needs to
interpret bytecode, no ocaml code in it may be natively compiled -
which in turn means any performance sensitive code needs to be hand
written in C.

Well, I'm not counting in the possibility of dynamically loading both
camlrun and asmrun and calling them directly - but even still they
couldn't share values and there would be two separate garbage
collectors.

I expect that this is a rather fundamental restriction and not easily
removed?

Bummed out,
-- 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

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

[Alain.Frisch]

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.

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

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?

-- Alain

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

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

[Nuutti Kotivuori]

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