From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 B95DDBC88 for ; Mon, 7 Feb 2005 14:07:28 +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 j17D7SYF011726 for ; Mon, 7 Feb 2005 14:07:28 +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 OAA03730 for ; Mon, 7 Feb 2005 14:07:25 +0100 (MET) Received: from qrnik.knm.org.pl (paf87.warszawa.sdi.tpnet.pl [217.96.225.87]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j17D7Ost011719 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 7 Feb 2005 14:07:25 +0100 Received: from qrczak by qrnik.knm.org.pl with local (Exim 3.36 #1) id 1Cy8br-0004nA-00 for caml-list@inria.fr; Mon, 07 Feb 2005 14:07:23 +0100 To: caml-list@inria.fr Subject: Re: [Caml-list] The boon of static type checking X-Face: OW>RV&gN+&b-aiNY|U)f=S%w+/rK!);f>/W9IXg})]&F>ht.1Up8@04+_!gOp(_/l_-+E^. 2\vI)1=D,%HWiq)r(M/V~dr^5T^KF/[w5YZ4<0Sus3+O>l3uA/&W_21m?.s,Po8{pb0@ References: From: "Marcin 'Qrczak' Kowalczyk" Mail-Followup-To: caml-list@inria.fr Date: Mon, 07 Feb 2005 14:07:23 +0100 In-Reply-To: (Brian Hurt's message of "Sun, 6 Feb 2005 23:34:02 -0600 (CST)") Message-ID: <874qgo8qno.fsf@qrnik.zagroda> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Marcin 'Qrczak' Kowalczyk" X-Miltered: at concorde with ID 42076810.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4207680C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 compiler:01 gcc:01 callee:01 extern:01 callee:01 gcc:01 compiler:01 writes:01 tail:01 tail:01 slower:01 slower:01 functions:01 functions:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: Brian Hurt writes: > Hint: I've yet to meet a compiler that couldn't turn x/32 into > x >> 5. Actually this is incorrect when x is a signed type (and might be negative). Strictly speaking, the sign of the quotient when either argument is negative is implementation-defined in C++, but GCC prefers to be consistent (it's the sign of the dividend when idiv is used, but shifting would yield the sign of the divisor). This means that when I care about performance and perform division of a number that I know is non-negative by a number which might be a constant power of 2, I cast the divisor to an unsigned type. The same applies to remainder. > Actually, g++ does do tail call optimization (in the 3.x tree). It's > actually not that hard to do, just not that beneficial (for C++). It is hard: - With the default C/C++ calling convention it's impossible if parameters of the callee take more space than parameters of the caller. - On x86 in PIC it would make calls from extern functions to some static functions slower. Because the callee assumes that %ebx allows to find data of our module, yet *our* caller in general assumes that we will restore %ebx. Instead of making these functions slower for all calls (by setting up and restoring %ebx in the callee too), GCC doesn't perform tail call optimization in this case. - It requires from the compiler to infer that addresses of our local variables don't leak to code which might use them while the tail-called function is running. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/