From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Windows 64 port Date: Fri, 02 Mar 2012 12:35:38 -0800 Organization: UCLA Computer Science Department Message-ID: <4F512F1A.7080806@cs.ucla.edu> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1330720573 27691 80.91.229.3 (2 Mar 2012 20:36:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Mar 2012 20:36:13 +0000 (UTC) Cc: fabrice.popineau@supelec.fr, emacs-devel@gnu.org, ajmr@ilovetortilladepatatas.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 02 21:36:11 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 1S3ZD0-00015i-ER for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2012 21:36:10 +0100 Original-Received: from localhost ([::1]:41874 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3ZCz-0007hi-M8 for ged-emacs-devel@m.gmane.org; Fri, 02 Mar 2012 15:36:09 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3ZCu-0007hC-Vo for emacs-devel@gnu.org; Fri, 02 Mar 2012 15:36:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3ZCb-0000l3-1w for emacs-devel@gnu.org; Fri, 02 Mar 2012 15:36:04 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:55798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3ZCY-0000jv-0h; Fri, 02 Mar 2012 15:35:42 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 44C16A6000D; Fri, 2 Mar 2012 12:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ5MvkhoQE5E; Fri, 2 Mar 2012 12:35:38 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id CC21FA6000B; Fri, 2 Mar 2012 12:35:38 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 In-Reply-To: <83ty27bbmn.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:148875 Archived-At: 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. 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. I'm not saying the code can't be cleaned up -- it's pretty messy and this one line is just one corner of the mess. But any cleanup can and should be done independently of the Windows 64 port, and should be systematic rather than just fiddling with this one line and making this line inconsistent with the (ab)use of ABLOCKS_BUSY in the rest of the module. My compilation was an optimized one, not that this matters much.