Re: [Caml-list] Writing a JIT compiler

["Basile Starynkevitch [local]" <basile.starynkevitch@inria.fr>]

On Fri, Jun 25, 2004 at 01:25:15PM +0100, Jon Harrop wrote:

> If ocamljitrun is based upon a GNU library then it must be GPL, is
> that right?

Ocamljitrun & GNU lightning - the library used by Ocamljitrun - are
under LGPL = GNU *lesser* general public license. Also, ocamljitrun is
slower (on running your Ocaml source code) than code compiled with
ocamlopt, but faster than bytecode interpreted by
ocamlrun. Ocamljitrun has the usual LGPL exception common in Ocaml
INRIA code. (I don't know if it apply to the GNU lightning itself).

Because of a bug in GNU lightning, ocamljitrun currently crashes on
PowerPC.


I am definitely not a lawyer (and the constitution, laws and contracts
I am under - french law and INRIA temporary work contract - are
probably not the laws and contracts which govern you - probably US
laws) - but as far as I know ocamjitrun is under GNU LGPL - ie Lesser
GPL licence, like GNU lightning which it is using.

However, the usual meta-advice is that for legal advice, you should
ask professional lawyers. Never take any word I am telling on legal
stuff seriously - I AM NOT A LAWYER!




> On Friday 25 June 2004 10:59, Basile Starynkevitch wrote:

>> You did not explain why are you writing a JIT (speed issues?)

> Yes, purely for speed.

J-M.Eber also have similar concerns (he is writing a commercial
product in and with Ocaml). I think that his company (Lexifi) is
member of the Ocaml consortium.... His concern is to accelerate a
function doing many floating point operations and a few Ocaml function
application. The function is dynamically generated at runtime by his
complex product. I suggested him to generate C code (calling the
appropriate OCaml caml_callback* when needed to apply functions) and
then compile it (by forking a gcc command) as a shared library, and
then dlopen it and using dlsym to get the function pointer and at last
call it. You'll have to dlclose the library after using it. In
principle, it is like using the Dynlink module, but ugly details
differ.


>> and what is the target language (x86 machine code, assembler, C,
>> Ocaml?)  of your JIT.


> Anything which can be efficiently compiled into x86 and PPC machine
> code using tools which are free for commercial use. Currently, I'm
> outputting OCaml and using ocamlopt which produces great code but
> isn't free (enough) and can't dynamically link the JIT compiled code
> back in. I should probably investigate more efficient ways to
> marshal data between two programs.

I believe that existing marshalling routines are quite fast. I'm not
sure you'll easily recode equivalent functionality (in particular
polymorphism) running much faster.


> I think that the bits which I want to compile are quite simple -
> just functions to do tree manipulations which I want to partially
> specialise over the manipulations which they perform.

>> You might generate "lambda" representation (see
>> ocaml/bytecomp/lambda.mli) of the compiler, or at least typed trees
>> (see ocaml/typedtree.mli).
 
> I'll check these out, thank you.
> 
> > You might use MetaOcaml see http://metaocaml.org/

> AFAIK there still isn't a native-code version.

I suppose that next version of MetaOcaml should be compatible with
Ocamljitrun (because it is compatible with next release of Ocaml).

> > You might generate C-- code: see http://cminusminus.org/

> This seems to be my best bet so far. How easy would be it to retarget 
> ocamljitrun to use C-- (it's totally free)?

It is not worth doing it (and it should be boring). My suggestion was
to generate C-- code independently of ocamljitrun. But details are
probably clever. Regarding licensing issues of C--, go the C-- web
page or mailing list.


>> So your interpreter might generate Ocaml bytecode (perhaps reusing
>> the "lambda" representation of Ocamlc) - and ocamljitrun will, when
>> interpreting it, translate the bytecode to machine code.

> The two main problems with that are the speed hit that my
> interpreter would take (because it could no longer be from ocamlopt)
> and, I assume, the GPL on GNU lightning.

You should be aware that GNU lightning is LGPL not GPL and that there
are big licensing differences between both. Also, ocamljitrun is a
standalone executable - which you can run in many ways, much like you
can use GNU emacs (which is under GPL, not LGPL) to edit whatever
material you want.

Ask your lawyer about LGPL licensing issues - from my "academic" point
of view, I see none. but I am not a lawyer!

Also note that ocamljitrun is a binary which is a plugin replacement
for ocamlrun, this means that (as far as I understand your needs) you
don't need to link it with your program. This means that the
hypothetical linking issues of the LGPL is not a concern. In my
non-lawyer opinion, ocamljitrun is like ocamlrun so can run any
program you like, including commercial ones.

But I tend to believe that asking a lawyer or a legal expert is the
best solution to legal problems. Before going to your lawyer, read
careful the many materials on GPL & LGPL available on the Web.

All opinions here are mine only....


-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - phone +33 1 3963 5197 - mobile 6 8501 2359
http://cristal.inria.fr/~starynke --- all opinions are only mine 

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