Running bytecode...

Running bytecode...

[Jonathan Roewen]

How can I load & run ocaml bytecode from my ocaml program that's built
with the nativecode compiler tools?

Jon

Re: [Caml-list] Running bytecode...

[Alex Baretta]

Jonathan Roewen wrote:
> How can I load & run ocaml bytecode from my ocaml program that's built
> with the nativecode compiler tools?
> 
> Jon

The short answer is you can't. It's a pity, but to the present day the
vanilla Ocaml distribution does not support mixing native and byte-code.
Also, it is not possibile to Dynlink native code, which is even more of
a pity.

There are libraries and patches to achieve this; however, they are
hardly maintained. I remember Asmdynlink, which was in the now defunct
CDK (Caml develpment kit). There is a also a patch to the compiler (3.07
last time I looked at it) which also allows native dynlink.

Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

Re: [Caml-list] Running bytecode...

[Jonathan Roewen]

> The short answer is you can't. It's a pity, but to the present day the
> vanilla Ocaml distribution does not support mixing native and byte-code.
> Also, it is not possibile to Dynlink native code, which is even more of
> a pity.

Well, dynlink with native code probably isn't desirable, as can't
really verify it.

How about embedding the bytecode interpreter in an ocaml native
program? How would one go about that?

Re: [Caml-list] Running bytecode...

[Alex Baretta]

Jonathan Roewen wrote:
>>The short answer is you can't. It's a pity, but to the present day the
>>vanilla Ocaml distribution does not support mixing native and byte-code.
>>Also, it is not possibile to Dynlink native code, which is even more of
>>a pity.
> 
> 
> Well, dynlink with native code probably isn't desirable, as can't
> really verify it.

Actually, this is very desirable. Ask Jon Skaller, who is developing the
Felix language mainly because Ocaml does not have this feature. It also
very desirable to us for the AS/Xcaml project, where server side
applications (Xlets) are dynlinked upon client request for their
execution. In order to run a native instance of an AS/Xcaml application,
the code for all the relevant xlets must be statically linked into the
xcaml daemon.

Scaml does this, but there is no correctness proof for it. It is a patch
to 3.07. Unluckily Xavier wants to have an provably perfect solution to
this problem, which is definitely a good thing, but this delays such a
great feature as native dynlink.

> How about embedding the bytecode interpreter in an ocaml native
> program? How would one go about that?


This is exactly what Asmdynlink did. It was a bytecode interpreter
written in Ocaml and ideally compiled with Ocamlopt. I do not believe
that is has been ported to 3.08, though.


Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

Re: [Caml-list] Running bytecode...

[John Skaller]

On Fri, 2005-06-17 at 11:57 +0200, Alex Baretta wrote:
> Jonathan Roewen wrote:
> >>The short answer is you can't. It's a pity, but to the present day the
> >>vanilla Ocaml distribution does not support mixing native and byte-code.
> >>Also, it is not possibile to Dynlink native code, which is even more of
> >>a pity.
> > 
> > 
> > Well, dynlink with native code probably isn't desirable, as can't
> > really verify it.
> 
> Actually, this is very desirable. Ask Jon Skaller, who is developing the
> Felix language mainly because Ocaml does not have this feature. 

> Scaml does this, but there is no correctness proof for it. It is a patch
> to 3.07. Unluckily Xavier wants to have an provably perfect solution to
> this problem, which is definitely a good thing, but this delays such a
> great feature as native dynlink.

My opinion of the situation is:

INRIA people like to have a mathematical basis for things, 
but that isn't the same as
requiring a perfect solution or demanding a correctness proof.
The usual reason for liking a constructive proof is that
it actually tells the algorithm.

I believe there are two reasons for not supporting native
code dynamic loading in Ocaml:

(1) It is a lot of work. The first step, dynamic loading
of C parts of the system, has already been implemented.
It makes sense to deal with the issues arising from this
first.

(2) A too hasty design would preclude a better one
permanently .. an example is the -pack switch ;(

As to Felix: it is designed to inter-operate with C/C++
on both source and binary levels. At this stage you
can 'dlopen()' any C library and 'dlsym()' any function
in it. However the binding is exactly as in C: you have
to use string names for functions, which basically means
you have to use extern "C" names.

This is not very safe: the only error check is whether
a symbol exists. There's no type checking, even less
than what C++ would provide with typesafe linkage.

The main difference to Ocaml is that it can actually
be done, albeit unsafely, which is a correct first
order solution for Felix, since binding to non-Felix
C libraries is a requirement (and that can't be safe
because C isn't).

I will be working on better solutions, in particular
leveraging C++ type safe linkage, however a full
scale native Felix-Felix dynamic linkage has
as a precondition separate compilation, which is
currently not supported: Felix can generate and
call C libraries of course: the compiler targets
shared libraries, a program is just a library
with an init function.

There is an example of Felix plugins in the 
tutorial and in the Alioth Shootout.

-- 
John Skaller <skaller at users dot sf dot net>
Download Felix: http://felix.sf.net