From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D61BCBB9C for ; Fri, 2 Dec 2005 04:29:27 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jB23TREo001767 for ; Fri, 2 Dec 2005 04:29:27 +0100 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 EAA17493 for ; Fri, 2 Dec 2005 04:29:26 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jB23TPIS001762 for ; Fri, 2 Dec 2005 04:29:26 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id jB23TIC9025775; Fri, 2 Dec 2005 12:29:19 +0900 (JST) Date: Fri, 02 Dec 2005 12:29:14 +0900 (JST) Message-Id: <20051202.122914.122623939.garrigue@math.nagoya-u.ac.jp> To: rich@annexia.org Cc: caml-list@inria.fr Subject: Re: [Caml-list] How to compile different implementations of the same lib From: Jacques Garrigue In-Reply-To: <20051201200944.GA30251@furbychan.cocan.org> References: <438F2CE5.9030105@univ-savoie.fr> <1133459647.9266.20.camel@rosella> <20051201200944.GA30251@furbychan.cocan.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 438FBF97.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 438FBF95.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 lib:01 cmx:01 cmx:01 ocaml:01 runtime:01 pointer:01 pointer:01 pointers:01 arity:01 arity:01 sub-optimal:01 inlining:01 closures:01 partial:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 From: Richard Jones > I don't quite understand this. I get that if the .cmx isn't > available, then one obviously cannot inline the code. But why is it > that you cannot use a simple call instruction even if the .cmx isn't > available? There are many causes: The first one is that functions in ocaml are represented as closures, which are data generated at runtime, including a code pointer. When you access a function without the .cmx, you're just extracting data at a certain offset from an array representing the module the function belongs to. The name of the code pointer, on which C linking is usually based, doesn't appear in this scheme: everything is extracted from a single data pointer to the module. If you want to call functions directly, you would first have to reveal the names of their code pointers, which is currently generated in a code dependent way, and stored in the cmx. The generation could be made uniform for exported functions (not as easy as it seems), but this would still be the easy part. The hard part is that you also need to know which representation the optimized version of the function is using. Has it a closure? For many functions, you need to pass them some environment data as an extra parameter. However not all functions need this extra parameter (some functions don't access any external data), and in that case there optimized form doesn't expect such an extra parameter. If you don't know that, you can only call the non-optimized form, looking up the data, which happens to be empty. What is its arity? Because of currying, the arity of the type of a function is not necessarily equal to the arity of its implementation. That is, some partial applications might actually produce side-effects. The optimized version of the function is based on the actual arity, not that of the type. So you cannot call it wihout knowing this arity. All this might be solved in one way or another, but the solution would be sub-optimal, and would not allow for the inlining one would expect for native code. Jacques Garrigue