From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: 64-bit lossage Date: Wed, 24 Jul 2002 09:34:23 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200207021945.g62JjkK01982@aztec.santafe.edu> <200207181455.g6IEt2n24982@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027517722 8559 127.0.0.1 (24 Jul 2002 13:35:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Jul 2002 13:35:22 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17XMIS-0002Dw-00 for ; Wed, 24 Jul 2002 15:35:20 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17XMXH-0004Tr-00 for ; Wed, 24 Jul 2002 15:50:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XMId-00058p-00; Wed, 24 Jul 2002 09:35:31 -0400 Original-Received: from 208-59-178-90.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([208.59.178.90] helo=raeburn.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XMHa-00055r-00; Wed, 24 Jul 2002 09:34:26 -0400 Original-Received: from kal-el.raeburn.org (mail@kal-el.raeburn.org [18.101.0.230]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g6ODYNf14702; Wed, 24 Jul 2002 09:34:24 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17XMHX-0002Ui-00; Wed, 24 Jul 2002 09:34:23 -0400 Original-To: Dave Love In-Reply-To: (Dave Love's message of "23 Jul 2002 23:09:37 +0100") Original-Lines: 63 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.3.50 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6010 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6010 Dave Love writes: >> I'll try to get some builds done on them more often, but I'll note one >> thing right off -- the m/alpha.h file breaks the USE_LISP_UNION_TYPE >> code because it unconditionally redefines some of the macros for >> picking apart an integer used as a Lisp_Object. > > Yes. Why is that a problem in practice? (Also, lisp.h doesn't always > undef such things before re-defining them, with possible warning > storms as a consequence.) I'm using the Lisp union type to ensure we've got reasonable type handling, that we're not confusing Lisp objects and actual integer values we want to use. In the current representation the bit patterns are the same for non-negative integers, but if we ever want to be able to change the representation -- not necessarily switching to Guile, but perhaps moving the tag bits to the low bits that are always zero in a properly aligned struct pointer -- we still need to fix all those cases. A necessary early step in the Guile work I want to do is to get the ability to make such changes. Even if we never switch to Guile, I believe that ability is important to have. >From what I've seen so far, on all the platforms where the Lisp object manipulation macros were redefined, there are probably better ways to do it. And sometimes the reason for the redefinition is just bogus; for example, MARKBIT was redefined on the alpha because of some problem with an #if test that as far as I can see, doesn't exist now. Generally the macros duplicate values that lisp.h or config.h would've selected anyways. I could work on these changes without changing m/alpha.h; I just couldn't work on them on the Alpha. As far as Joe Random downloading and building Emacs, it's not directly causing any problem at all, aside from those redefinition warnings. >> I'd say the macros in lisp.h need revising to better support 64-bit >> architectures; > > As far as I know, they currently work, but there are probably more > serious 64-bit problems elsewhere unless someone has re-done what > eggert and I both started on. > > Adding long long support (per TODO) seems most useful in that area. On most (all?) of the 64-bit configurations I've worked on, "long" is 64 bits; "long long" is mostly interesting only if "long" isn't as big as a pointer, or we really really want to store more information than a pointer. If we hit a platform where only "long long" is pointer sized, yes, we'll need to use it. But if the lisp-union code compiles without complaint, I bet "long long" can be made to work quite easily. Ken P.S. I'm running an Emacs binary right now that was built to use a union for a Lisp_Object, compiled for x86. Most of what I'm doing is interactive, but I haven't noticed any performance issues. I did one timing test with "make autoloads", and out of about four minutes of CPU time, the "union" version was slower by about five seconds. That's probably doing lots of searching in the regexp code; byte-compiling might be a better test case to look for worst-case results, but I haven't tried it yet.