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 OAA03593; Fri, 3 Aug 2001 14:03:55 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA03506 for ; Fri, 3 Aug 2001 14:03:54 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f73C3qD24227; Fri, 3 Aug 2001 14:03:52 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA03577; Fri, 3 Aug 2001 14:03:51 +0200 (MET DST) Date: Fri, 3 Aug 2001 14:03:51 +0200 From: Xavier Leroy To: Chris Hecker Cc: caml-list@inria.fr Subject: Re: [Caml-list] calling native code from bytecode? Message-ID: <20010803140351.A3307@pauillac.inria.fr> References: <200108012345.QAA29668@smtp3-cm.mail.eni.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200108012345.QAA29668@smtp3-cm.mail.eni.net>; from checker@d6.com on Wed, Aug 01, 2001 at 04:45:40PM -0700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Is there any way to compile part of a project in bytecode and another > part with the native compiler and link them? It seems odd that you > can call C from bytecode but not other caml code. The gc and > everything is the same between the asm and bytecode runtimes, no? Are > datastructures in memory (except code, of course) compatible? Yes, they are compatible, except function closures, which contain native code pointers for ocamlopt and byte-code pointers for ocamlc. But that's where the problem is for mixed-mode execution: treating pointers to bytecode and pointers to native-code differently. One solution would be to have two code pointers per closure, one bytecode and one native-code. For a bytecode closure, the native-code pointer would point to the bytecode interpreter. For a native-code closure, the bytecode pointer would point to a special "switch mode" instruction of the virtual machine. But that's far from easy to implement. Another approach is Fabrice Le Fessant's asmdynlink library, which basically is a bytecode interpreter written in Caml and compiled with ocamlopt. This gives native-code programs the ability to execute bytecode, albeit at a fairly large cost in execution speed. > Basically, I've got some numerical code that I'd like to compile to > native code for performance, but I'd like to keep most of the > non-performance stuff in bytecode so I can use the toplevel and > whatnot. I suppose I could do some sort of heinous bytecode -> C -> > native code shim Besides problems with potential callbacks from native-code to bytecode, there are also (non-essential, but intricate) GC issues that would come in the way. > Obviously, the holy grail would be complete intermingling of bytecode > and native code, and the linker just figures it out and does the right > thing. That would rock. But, I'd settle for bytecode -> native calls > only at this point. > Thoughts? Nothing is impossible, but I shudder at the idea of implementing all this. - Xavier Leroy ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr