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: Tue, 30 Jul 2002 10:56:28 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028041024 12788 127.0.0.1 (30 Jul 2002 14:57:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 30 Jul 2002 14:57:04 +0000 (UTC) Cc: 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 17ZYQo-0003K6-00 for ; Tue, 30 Jul 2002 16:57:02 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17ZYiZ-0007sQ-00 for ; Tue, 30 Jul 2002 17:15:24 +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 17ZYR8-00071Q-00; Tue, 30 Jul 2002 10:57:22 -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 17ZYQS-00070P-00 for ; Tue, 30 Jul 2002 10:56:40 -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 g6UEuTf19183; Tue, 30 Jul 2002 10:56:29 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17ZYQH-0002J4-00; Tue, 30 Jul 2002 10:56:29 -0400 Original-To: Dave Love In-Reply-To: (Dave Love's message of "29 Jul 2002 23:43:11 +0100") Original-Lines: 82 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1.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:6178 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6178 Dave Love writes: > Ken Raeburn writes: >> I don't think I've got access to an Irix64 system to test with; > For what it's worth, any remotely-recent system can run 64-bit (r4000 > up, probably with Irix 5.2 up, but I can't remember for sure that for > back). At work, we've got R5000s running 32-bit kernels, and I don't control them. >> Per-machine definitions of macros dependent on low-level details of >> the lisp implementation. It's cleaner if the lisp implementation is >> based on information about the architecture, and not partially >> rewritten for some architectures. > > The machine and system files are a horrible mess in general, and that > often leads to real problems. Yes, some of the OS stuff does look pretty messy, but simple architecture issues can be cleaned up. >> The macros as they stand in lisp.h do appear to be fairly clean for >> 64-bit support. They assume that "long" will be 64 bits when pointers >> are, and that "_LP64" is defined in that case, but switching to "long >> long" if "long" isn't big enough should actually be quite easy. > > Good but it wasn't trivial when we last tried. There shouldn't be any cases of mixing int and EMACS_INT values that could inadvertently create broken lisp objects, and the pure numeric manipulation should be fine. Conversions between pointers and integers in Emacs all seem to assume that EMACS_INT is the same size as a pointer, and that would need fixing, mostly outside of lisp.h. Probably an Emacs version of C99's intptr_t would do the trick. >> It wasn't trying to fix one problem. The patches I had in progress >> made the problem disappear for me; > > Not for me, for what it's worth. Only disabling use of mmap did. Interesting. I'd like to look into that further. Should I try out the unicode branch? >> 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. > I don't think that needs to be done specifically on Alpha, though. Only if I want to test things on 64-bit platforms. >> Generally the macros duplicate values that lisp.h or config.h would've >> selected anyways. > I know there's lots of that sort of thing in the build system overall, > but we were forbidden to clean it up in the past. Oh? I don't want to go traipsing around in areas we're not supposed to mess with... >> On most (all?) of the 64-bit configurations I've worked on, "long" is >> 64 bits; > Of course. The idea was to be able to use long long on 32-bit > systems. Ah. To get the full range of pointer values, and larger integers? Having just heard from someone who wants to edit a 300M file on a 32-bit platform, I may look a little more closely at this, but it's not a priority. If we used something more like the Guile object representation -- tag bits at the bottom instead of the top, and more of the type info in the pointed-to structure -- we might be able to get 31-bit integers and 32-bit word pointers. Since structure pointers are -- or can be made to be -- aligned on 4- or 8-byte boundaries, we can produce the pointers by masking off those bits, without interfering with the upper bits of the pointer at all. I think XEmacs does this too. Ken