From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: 64-bit lossage Date: 29 Jul 2002 23:43:11 +0100 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 1027982637 9410 127.0.0.1 (29 Jul 2002 22:43:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 29 Jul 2002 22:43:57 +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 17ZJF6-0002Rf-00 for ; Tue, 30 Jul 2002 00:43:56 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17ZJWX-0001fH-00 for ; Tue, 30 Jul 2002 01:01:57 +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 17ZJFU-0003vx-00; Mon, 29 Jul 2002 18:44:20 -0400 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17ZJEP-0003kX-00 for ; Mon, 29 Jul 2002 18:43:13 -0400 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 17ZJEN-0006fp-00; Mon, 29 Jul 2002 23:43:11 +0100 Original-To: Ken Raeburn Original-Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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:6153 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6153 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). > 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. > 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. > I think the make_gap_smaller code is new on the trunk since the > current release branch was started; that's what caused mmap_realloc to > be called to unmap some pages. I want to look a bit more closely, > though, and see if there are other cases that could cause similar > problems on the release branch. Good. (I use the released version in anger on tru64 without problems.) > 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.