From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: 64-bit lossage Date: Fri, 09 Aug 2002 03:07:08 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200208090707.g79778V11531@rum.cs.yale.edu> References: <200207310555.g6V5t4X16532@aztec.santafe.edu> <200208012119.g71LJfE28426@green.twinsun.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028876843 15177 127.0.0.1 (9 Aug 2002 07:07:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 9 Aug 2002 07:07:23 +0000 (UTC) Cc: raeburn@raeburn.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.35 #1 (Debian)) id 17d3rl-0003wg-00 for ; Fri, 09 Aug 2002 09:07:21 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17d4ED-000639-00 for ; Fri, 09 Aug 2002 09:30:34 +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 17d3sU-0005Mc-00; Fri, 09 Aug 2002 03:08:06 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17d3rb-0005Kb-00 for ; Fri, 09 Aug 2002 03:07:11 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g79778V11531; Fri, 9 Aug 2002 03:07:08 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Paul Eggert 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:6379 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6379 > > But after looking at it a little, I think doubling the size of a > > Lisp_Object is probably not worth it. > > I agree in general, but Emacs on x86 is quite popular, and the current > 28-bit address limit is starting to bite. A few years ago I started > to work on supporting 64-bit Lisp_Object on 32-bit hosts and I got > about half the way through. It's not that hard, but it is a bit > tedious (among other things, every function really needs to be > prototyped). There are 4 limits: - the number of objects we can point to - the largest elisp integer - the actual address space available to the Emacs process - the largest buffer that Emacs can handle correctly The first one (such as using lower bits for tagging) is irrelevant to this discussion. The second one is currently set at 128MB for 32bit systems. The third one is usually around 2GB but can be close to 4GB if you're lucky (on 32bit systems as well) and Emacs really can't do much about it. The fourth one can be 4GB even on 64bit systems because the Emacs C code often uses `int' to represent buffer positions. We can try to change the tagging system to move the 128MB limit closer to the 2-4GB "hard" limit, but I don't see the point: a 129MB file is most likely program-generated rather than human-generated, so next week's file might just as well be 4.1GB instead and we won't be able to do anything about that one. So I think if we want to deal with "large files on 32bit systems" we'd better try to see how to allow Emacs to view/edit files piecemeal (where only part of the file is in memory at any point in time). This said, adding arbitrary-integer support to Emacs (see the gerd-gmp branch for a start) might be a good thing as well. Stefan