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 WAA25684; Wed, 2 Oct 2002 22:59:57 +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 WAA25744 for ; Wed, 2 Oct 2002 22:59:56 +0200 (MET DST) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id g92KxtD05621 for ; Wed, 2 Oct 2002 22:59:55 +0200 (MET DST) Received: (qmail 60227 invoked from network); 2 Oct 2002 20:59:53 -0000 Received: from node-d8e9cca2-sfo-onnet.worldcom.com (HELO checkerlap.d6.com) (216.233.204.162) by relay1.pair.com with SMTP; 2 Oct 2002 20:59:53 -0000 X-pair-Authenticated: 216.233.204.162 Message-Id: <4.3.2.7.2.20021002123446.019b8770@mail.d6.com> X-Sender: checker@mail.d6.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Oct 2002 13:57:57 -0700 To: Dave Mason , Alessandro Baretta From: Chris Hecker Subject: Re: [Caml-list] choosing modules at runtime Cc: Ocaml In-Reply-To: <200210021328.g92DSwh23908@sarg.ryerson.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > And finally, a mixed byte-native runtime is not supported. >This is definitely something I'd like to see. As I understand it, >there are 2 problems: bytecode vs. native function dispatch, and GC. >Trying to resolve this is on my list of things to do, but it's a long >list, so I'd love to hear that someone else has done it first! I looked into this a fair amount and there were some threads on this topic on the list. It's totally possible to do, but it looks like a mess. Xavier explained the problems in the old thread. I looked into how to do the function dispatch without requiring an if statement or two pointers in the closures, and it seems doable by being wacky with nop instructions on the various supported architectures (for better or for worse). Here's the thread: http://groups.google.com/groups?th=d0d0f6e6592e11ea A unification of the GC between bytecode and native would be good for the other wacky feature I'd like to see implemented: coroutines/fibers/cooperative-threads/whatever-your-pet-name-is. These require allocating a block of memory, treating it as a stack and switching to it to run a coroutine. All of the allocated stacks have to be visible to the GC so it doesn't treat as garbage something living on a non-running stack. I haven't looked into this at all, but I assume there's something in there for the preemptive threads, but I wonder how different it is for bytecode versus native. Coroutines are useful in games for writing AI code so you don't have to write it as an FSM to spread it across frames. Chris ------------------- 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