Version française
Home     About     Download     Resources     Contact us    
Browse thread
Best way to choose an implementation of a lib ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@m...>
Subject: Re: [Caml-list] How to compile different implementations of the same lib
From: Richard Jones <rich@annexia.org>

> I don't quite understand this.  I get that if the .cmx isn't
> available, then one obviously cannot inline the code.  But why is it
> that you cannot use a simple call instruction even if the .cmx isn't
> available?

There are many causes:
The first one is that functions in ocaml are represented as closures,
which are data generated at runtime, including a code pointer.
When you access a function without the .cmx, you're just extracting
data at a certain offset from an array representing the module the
function belongs to. The name of the code pointer, on which C linking
is usually based, doesn't appear in this scheme: everything is extracted
from a single data pointer to the module.

If you want to call functions directly, you would first have to reveal
the names of their code pointers, which is currently generated in a code
dependent way, and stored in the cmx. The generation could be made
uniform for exported functions (not as easy as it seems), but this
would still be the easy part.

The hard part is that you also need to know which representation the
optimized version of the function is using.

Has it a closure? For many functions, you need to pass them some
environment data as an extra parameter. However not all functions need
this extra parameter (some functions don't access any external data),
and in that case there optimized form doesn't expect such an extra
parameter. If you don't know that, you can only call the non-optimized
form, looking up the data, which happens to be empty.

What is its arity? Because of currying, the arity of the type of a
function is not necessarily equal to the arity of its
implementation. That is, some partial applications might actually
produce side-effects. The optimized version of the function is based
on the actual arity, not that of the type. So you cannot call it
wihout knowing this arity.

All this might be solved in one way or another, but the solution would
be sub-optimal, and would not allow for the inlining one would expect
for native code.

Jacques Garrigue