[Caml-list] Runtime (native) compilation

[Caml-list] Runtime (native) compilation

[Walid Taha]

Hello,

We've been working on a while on building MetaOCaml, which provides three
basic constructs for contructing programs at runtime and compiling them.
This seems to be working well in the context of the bytecode compiler.
For the native code compiler, though, things seems to be more tricky.  In
particular, the native code compiler produces assembly code.  This has to
be assembled, linked, and loaded to memory.  Does any one know of a fast
way to do the last three steps (other than calling the assembler, linker,
and loader).  Also, has anyone dealt with the issue of coordinating the
runtime for the original running image and the newly produced runnable
image (in particular, has anyone dealt with the garbage collection
issues?)

Walid.

-------------------
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] Runtime (native) compilation

[Dmitry Lomov]

Walid,

although Dynamic Caml does not (yet) work on native code, we have 
implemented (a while ago actually) a very preliminary prototype
implementation of it for i386. We do not use ocamlopt for code
generation however - we implemented a custom code generator. Do you
think it is difficult to make ocamlopt generate machine code instead of
assembler, and why do you think one needs linking at all? (Probably it
all different in MetaOCaml - I have not studied the internals)

As to dealing with runtime, I do not see much differences between 
bytecode and native code case - at least in Dynamic Caml. What problems
do you perceive?

Friendly,
Dmitry
 

> 
> Hello,
> 
> We've been working on a while on building MetaOCaml, which provides three
> basic constructs for contructing programs at runtime and compiling them.
> This seems to be working well in the context of the bytecode compiler.
> For the native code compiler, though, things seems to be more tricky.  In
> particular, the native code compiler produces assembly code.  This has to
> be assembled, linked, and loaded to memory.  Does any one know of a fast
> way to do the last three steps (other than calling the assembler, linker,
> and loader).  Also, has anyone dealt with the issue of coordinating the
> runtime for the original running image and the newly produced runnable
> image (in particular, has anyone dealt with the garbage collection
> issues?)
> 
> Walid.
> 
-- 
Dmitry Lomov
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

-------------------
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] Runtime (native) compilation

[Walid Taha]

Dear Dmitry,

In MetaOCaml, a call to run (or "eval", written ".!") invokes the compiler
(be it bytecode or native).  So far, we've been able to make things work
reasonably well for the bytecode compiler.  In the bytecode setting, a
call to run generates new bytecode, and using the same machinary that is
used for the top level read-eval-print loop in OCaml, we add this new
bytecode to the running bytecode, and then just jump to it.  With the
native code it is not completely clear to me what needs to be done to
mimic this.  I don't know if it would be difficult or easy to make
ocamlopt generate machine code directly.  If you have some insights into
this, I would be very interested.  Regarding linking, I had assumed that
the assembly code (or machine code) generated will have some stubs
missing, and some kind of linking will be needed to fill those in.  But
now that you've raised a doubt about that, I have to admit that I'm not a
100% sure that some kind of linking will be needed.  I will look into this
question.

Incidently, your dynamic caml systems is very interesting (I just found
the users manual).  Does its "eval" invoke the compiler at runtime like
MetaOCamls?  If so, I would be very interested in the details of your
experience generating code for the i386.

Best regards,

Walid.

On 17 Oct 2002, Dmitry Lomov wrote:

|Walid,
|
|although Dynamic Caml does not (yet) work on native code, we have
|implemented (a while ago actually) a very preliminary prototype
|implementation of it for i386. We do not use ocamlopt for code
|generation however - we implemented a custom code generator. Do you
|think it is difficult to make ocamlopt generate machine code instead of
|assembler, and why do you think one needs linking at all? (Probably it
|all different in MetaOCaml - I have not studied the internals)
|
|As to dealing with runtime, I do not see much differences between
|bytecode and native code case - at least in Dynamic Caml. What problems
|do you perceive?
|
|Friendly,
|Dmitry
|
|
|>
|> Hello,
|>
|> We've been working on a while on building MetaOCaml, which provides three
|> basic constructs for contructing programs at runtime and compiling them.
|> This seems to be working well in the context of the bytecode compiler.
|> For the native code compiler, though, things seems to be more tricky.  In
|> particular, the native code compiler produces assembly code.  This has to
|> be assembled, linked, and loaded to memory.  Does any one know of a fast
|> way to do the last three steps (other than calling the assembler, linker,
|> and loader).  Also, has anyone dealt with the issue of coordinating the
|> runtime for the original running image and the newly produced runnable
|> image (in particular, has anyone dealt with the garbage collection
|> issues?)
|>
|> Walid.
|>
|--
|Dmitry Lomov
|IntelliJ Labs / JetBrains Inc.
|http://www.intellij.com
|"Develop with pleasure!"
|

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