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 KAA04013; Wed, 8 Aug 2001 10:46:19 +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 KAA03982 for ; Wed, 8 Aug 2001 10:46:18 +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 f788kF912615; Wed, 8 Aug 2001 10:46:16 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA03965; Wed, 8 Aug 2001 10:46:15 +0200 (MET DST) Date: Wed, 8 Aug 2001 10:46:15 +0200 From: Xavier Leroy To: Chris Hecker Cc: caml-list@inria.fr Subject: Re: [Caml-list] calling native code from bytecode? Message-ID: <20010808104615.A3590@pauillac.inria.fr> References: <200108012345.QAA29668@smtp3-cm.mail.eni.net> <200108012345.QAA29668@smtp3-cm.mail.eni.net> <20010803140351.A3307@pauillac.inria.fr> <4.3.2.7.2.20010803065549.02761be0@shell16.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.3.2.7.2.20010803065549.02761be0@shell16.ba.best.com>; from checker@d6.com on Fri, Aug 03, 2001 at 07:31:28AM -0700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > So, just to be excruciatingly clear, assuming there are no closures > in any of the parameters to a function call, the "values" passed in > and any native code and GC operations on those values are completely > compatible? Even for arbitrarily complex datastructures, as long as > no closures are in the mix? As far as I can remember, yes. > If I constrained the problem to just leaf functions (where leaf is > defined as never calling back into bytecode) then it would work, > runtime library-wise? No :-) From the standpoint of the runtime system, Caml-generated native code and the bytecode interpreter differ in several points: - the location of GC roots (e.g. native stack vs. bytecode interpreter stack); - how to raise exceptions from C code; - how to call back from C to Caml. To handle these differences, the runtime system comes in two variants (libcamlrun.a and libasmrun.a), with suitable #ifdefs, different definitions of some runtime functions, etc. Linking with only one version of the runtime system (e.g. libcamlrun.a) will result in wrong behavior for mixed-mode code, e.g. the GC will overlook memory roots residing in the native code stack. Linking with both versions is not possible, as they define differently the same function names... (It might be possible to play linker tricks so that there are actually two copies of the runtime system in the executable, but then you'd have two different Caml heaps, one for the bytecode system and one for the native code, and you'd need to copy all data structures when switching between bytecode and native code. Quite messy.) My advice is: don't do it. If all you need is to have the efficiency of native code and the debugging comfort of bytecode, just compile all your sources twice, to native-code and to bytecode. For dynamic loading of bytecode in a native-code application, Fabrice Le Fessant's asmdynlink library (or something similar) should suffice. And I can't see any other reason why you'd want mixed-mode execution. - 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