From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA18620; Fri, 12 Dec 2003 23:49:56 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA18609 for ; Fri, 12 Dec 2003 23:49:54 +0100 (MET) Received: from smtp3.pp.htv.fi (smtp3.pp.htv.fi [213.243.153.173]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hBCMnr120380 for ; Fri, 12 Dec 2003 23:49:53 +0100 (MET) Received: from posti.pp.htv.fi (posti.pp.htv.fi [212.90.64.50]) by smtp3.pp.htv.fi (Postfix) with ESMTP id 7A63D27B404; Sat, 13 Dec 2003 00:49:53 +0200 (EET) Received: from oro (aka.pp.htv.fi [213.243.183.115]) by posti.pp.htv.fi (8.11.1 (Revision 1.5+JAGae91741+JAGae92668) /8.11.1) with ESMTP id hBCMnrT09712; Sat, 13 Dec 2003 00:49:53 +0200 (EET) Received: from naked by oro with local (Exim 3.36 #1 (Debian)) id 1AUw6a-0008Ev-00; Sat, 13 Dec 2003 00:49:52 +0200 To: Alain.Frisch@ens.fr Cc: Caml list Subject: Re: [Caml-list] Co-existence of byterun and asmrun impossible? References: From: Nuutti Kotivuori Date: Sat, 13 Dec 2003 00:49:51 +0200 In-Reply-To: (Alain Frisch's message of "Fri, 12 Dec 2003 22:58:18 +0100 (MET)") Message-ID: <874qw57isw.fsf@naked.iki.fi> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 byterun:01 asmrun:01 alain:01 frisch:01 ocamlrun:01 ocamlrun:01 runtime:01 ifndef:01 atom:01 atom:01 camlextern:01 char:01 char:01 dynlink:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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