From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 5908FBC29 for ; Sat, 6 Nov 2004 10:37:49 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iA69bm8M030928 for ; Sat, 6 Nov 2004 10:37:49 +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 KAA02331 for ; Sat, 6 Nov 2004 10:37:48 +0100 (MET) Received: from yquem.inria.fr (yquem.inria.fr [128.93.8.37]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iA69bmK6015268; Sat, 6 Nov 2004 10:37:48 +0100 Received: by yquem.inria.fr (Postfix, from userid 18180) id 46D3EBC29; Sat, 6 Nov 2004 10:37:48 +0100 (CET) Date: Sat, 6 Nov 2004 10:37:48 +0100 From: Xavier Leroy To: Aaron Bohannon Cc: caml-list@inria.fr Subject: Re: [Caml-list] native code and ZINC machine Message-ID: <20041106093748.GA26835@yquem.inria.fr> References: <418B8D56.5010109@seas.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <418B8D56.5010109@seas.upenn.edu> User-Agent: Mutt/1.3.28i X-Miltered: at nez-perce with ID 418C9B6C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 418C9B6C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 compiler:01 implements:01 bytecode:01 native-code:01 compiler:01 bytecode:01 corrected:01 inlined:01 ocamlopt:01 bug:01 ocaml:01 model:01 runtime:01 overlooking:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: > I was quite surprised, recently, when I found out that the native code > compiler implements left-to-right evaulation, as opposed to the > right-to-left evaulation of the bytecode. This isn't quite right. The native-code compiler is essentially neutral w.r.t. evaluation order, meaning that it can implement any given evaluation order without singificant changes or performance impact. However, following the principle of least surprise, it tries to enforce the same evaluation order as the bytecode compiler, that is, right-to-left. There is one mistake in 3.08 (corrected in the main branch) that causes left-to-right evaluation for arguments to certain inlined functions (see PR#2910). If you observe left-to-right evaluation with ocamlopt, please report it. It's not really a bug according to the OCaml manual (which leaves evaluation order undefined), but it's certainly a "quality of implementation" issue that we'd like to be aware of. > You see, I am quite familiar with the ZINC machine and the benefits of > its design, and I thought that the design could be adapted in some way > or another to the native code setting. I am interested in finding out > what factors prevented this, or what made the ZINC machine execution > model impractical in the native runtime. My knowledge of systems is > perhaps somewhat weak, so maybe I am overlooking some obvious point. The ZINC / OCaml VM handling of curried function application (an instance of the push-enter model) pretty much requires that parameters are passed on a stack. For native code generation, it is much more efficient to pass the first N parameters in processor registers. This doesn't fit the ZINC model at all. - Xavier Leroy