From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Windows 64 port Date: Sat, 03 Mar 2012 00:06:24 +0200 Message-ID: <83k432bqu7.fsf@gnu.org> References: <20120219211800.0000558f@unknown> <834numv7js.fsf@gnu.org> <83ty2ltep0.fsf@gnu.org> <4F4EEBC2.5070704@cs.ucla.edu> <4F4F3A1A.4020808@cs.ucla.edu> <83ty27bbmn.fsf@gnu.org> <4F512F1A.7080806@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1330725887 1525 80.91.229.3 (2 Mar 2012 22:04:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Mar 2012 22:04:47 +0000 (UTC) Cc: fabrice.popineau@supelec.fr, emacs-devel@gnu.org, ajmr@ilovetortilladepatatas.com To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 02 23:04:45 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S3aai-00089m-Tn for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2012 23:04:45 +0100 Original-Received: from localhost ([::1]:58164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3aah-0004ff-Tv for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2012 17:04:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3aad-0004fW-IL for emacs-devel@gnu.org; Fri, 02 Mar 2012 17:04:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3aab-0003Z5-Ad for emacs-devel@gnu.org; Fri, 02 Mar 2012 17:04:39 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3aab-0003Yv-2Z for emacs-devel@gnu.org; Fri, 02 Mar 2012 17:04:37 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M0A00E0020BKM00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 03 Mar 2012 00:04:14 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.228.20.191]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M0A00ESO2N1J550@a-mtaout22.012.net.il>; Sat, 03 Mar 2012 00:04:14 +0200 (IST) In-reply-to: <4F512F1A.7080806@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148877 Archived-At: > Date: Fri, 02 Mar 2012 12:35:38 -0800 > From: Paul Eggert > CC: fabrice.popineau@supelec.fr, ajmr@ilovetortilladepatatas.com, > emacs-devel@gnu.org > > On 03/02/2012 01:22 AM, Eli Zaretskii wrote: > > it is beyond ridiculous to say that a single extra clock cycle > > in a program such as Emacs should be seriously considered as an > > important factor to weigh against code cleanness and maintainability. > > My primary objection to the change has always been maintainability > and cleanness; any extra instructions are in the noise. Then why did you bring up that argument in the first place? If nothing else, it had Fabrice and myself waste some of our time trying to look at the code emitted by the compiler. > ABLOCKS_BUSY is sometimes a pointer and sometimes an integer > (converted to a pointer). At the point when this code is executed: > > int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase); > > ABLOCKS_BUSY is an integer. Changing the code to look like this: > > int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL); > > would cause a reader of the code to naturally make the > incorrect assumption that ABLOCKS_BUSY is a pointer. On > this ground alone the patch is dubious. The facts that > the patch is not needed for Windows 64 and that it might > slow things down a bit on some platforms are merely > icing on the cake. See, there's no cake here to ice. The way I see it, Fabrice is trying to contribute, and you discourage him on false pretenses. That comes nowhere near any cakes; that's simply unfair.