From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: 64-bit lossage Date: Thu, 1 Aug 2002 14:19:41 -0700 (PDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200208012119.g71LJfE28426@green.twinsun.com> References: <200207310555.g6V5t4X16532@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1028239696 10198 127.0.0.1 (1 Aug 2002 22:08:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2002 22:08:16 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from hermes.netfonds.no ([80.91.224.195]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17aNzn-0001jU-01 for ; Fri, 02 Aug 2002 00:00:40 +0200 Original-Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hermes.netfonds.no (8.12.1/8.12.1) with ESMTP id g71LK9ff024504 for ; Thu, 1 Aug 2002 23:20:09 +0200 (CEST) Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by mail-relay.eunet.no (8.12.2/8.12.2/GN) with ESMTP id g71LK9xt059712 for ; Thu, 1 Aug 2002 23:20:09 +0200 (CEST) (envelope-from emacs-devel-admin@gnu.org) Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17aNex-0001SG-00 for ; Thu, 01 Aug 2002 23:39:03 +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 17aNMY-0004vs-00; Thu, 01 Aug 2002 17:20:02 -0400 Original-Received: from alcor.twinsun.com ([198.147.65.9]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17aNME-0004vd-00 for ; Thu, 01 Aug 2002 17:19:42 -0400 Original-Received: from green.twinsun.com ([192.54.239.71]) by alcor.twinsun.com (8.12.1/8.12.1) with ESMTP id g71LJfgt026769; Thu, 1 Aug 2002 14:19:41 -0700 (PDT) Original-Received: (from eggert@localhost) by green.twinsun.com (8.11.6+Sun/8.11.6) id g71LJfE28426; Thu, 1 Aug 2002 14:19:41 -0700 (PDT) Original-To: raeburn@raeburn.org In-Reply-To: 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:6234 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6234 > From: Ken Raeburn > Date: Thu, 01 Aug 2002 13:19:44 -0400 > > 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). Changing the subject slightly, can't we increase address space and improve performance on both 32- and 64-bit hosts, without widening Lisp_Object, by moving the 4 tag bits to the low-order end of the Lisp_Object, and ensuring that all non-Lisp_Int objects are aligned at a multiple of 16? That way, we would get all of the 32-bit address space. Lisp_Int addition and subtraction would still be fast, since the Lisp_Int code is zero. (Multiplication and division would be slower, but that's rare.) And we would speed up access to non-Lisp_Int objects, since the tag bits in many cases could be removed at zero cost during normal address arithmetic. > Wider integer support on a 32-bit platform, so larger files can be > supported, buffer offsets can still be described, etc.... This would require 64-bit ints, yes. But I'm more worried about the current 28-bit limit on Lisp object addresses on 32-bit hosts. That's only 256 MB.