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 QAA07049; Fri, 3 Aug 2001 16:30:58 +0200 (MET DST) 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 QAA07041 for ; Fri, 3 Aug 2001 16:30:57 +0200 (MET DST) Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f73EUt917082; Fri, 3 Aug 2001 16:30:56 +0200 (MET DST) Received: from checkerlap.d6.com ([64.160.54.87]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GHH00KCZXMIJG@mta5.snfc21.pbi.net>; Fri, 03 Aug 2001 07:30:18 -0700 (PDT) Date: Fri, 03 Aug 2001 07:31:28 -0700 From: Chris Hecker Subject: Re: [Caml-list] calling native code from bytecode? In-reply-to: <20010803140351.A3307@pauillac.inria.fr> X-Sender: def6@shell16.ba.best.com To: Xavier Leroy Cc: caml-list@inria.fr Message-id: <4.3.2.7.2.20010803065549.02761be0@shell16.ba.best.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200108012345.QAA29668@smtp3-cm.mail.eni.net> <200108012345.QAA29668@smtp3-cm.mail.eni.net> Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Just a couple clarification questions (in case I decide to try to hack a prototype of this into the compiler): >One solution would be to have two code pointers per closure, one >bytecode and one native-code. I think, if I was just trying to do leaf functions (that don't take closures as parms) in native code to start with, that I'd just make another bytecode instruction for native calls. Having two pointers does seem like it'd be better if you were trying the complete solution, but I think you're right that it would be hard to implement. It seems like the OC_CALL* instruction could mostly mirror the implementation of C_CALL* up to the point of call, because currying and whatnot would work the same way. 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? 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? I wonder if there would be issues between the standard library functions that are implemented in C, although I'd assume they'd link, would there be sync issues? I assume threads would be a mess, too, so I'd disable them as well. Since bytecode and native code both use .cmi files, I assume module structure and signature layouts are compatible? >> 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. You mean for the shim solution in that sentence, not if I was just passing values straight to the native code? Thanks, Chris ------------------- 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