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: Fri, 2 Aug 2002 17:03:42 -0700 (PDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200208030003.g7303g815713@green.twinsun.com> References: <200207310555.g6V5t4X16532@aztec.santafe.edu> <200208012119.g71LJfE28426@green.twinsun.com> <200208022213.g72MDa201780@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1028333015 27426 127.0.0.1 (3 Aug 2002 00:03:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 3 Aug 2002 00:03:35 +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.33 #1 (Debian)) id 17amOM-00078F-00 for ; Sat, 03 Aug 2002 02:03:34 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17amhl-0005aH-00 for ; Sat, 03 Aug 2002 02:23:37 +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 17amOp-00045K-00; Fri, 02 Aug 2002 20:04:03 -0400 Original-Received: from alcor.twinsun.com ([198.147.65.9]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17amOV-00044u-00; Fri, 02 Aug 2002 20:03:44 -0400 Original-Received: from green.twinsun.com ([192.54.239.71]) by alcor.twinsun.com (8.12.1/8.12.1) with ESMTP id g7303ggt011015; Fri, 2 Aug 2002 17:03:42 -0700 (PDT) Original-Received: (from eggert@localhost) by green.twinsun.com (8.11.6+Sun/8.11.6) id g7303g815713; Fri, 2 Aug 2002 17:03:42 -0700 (PDT) Original-To: rms@gnu.org In-Reply-To: <200208022213.g72MDa201780@aztec.santafe.edu> (rms@gnu.org) 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:6257 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6257 > Date: Fri, 2 Aug 2002 16:13:36 -0600 (MDT) > From: Richard Stallman > > 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? > > A cons cell is 8 bytes, so it would have to be a multiple of 8. That could be arranged by sort of a Huffman coding for type bits, as Ken Raeburn suggested. E.g., if M denotes a mark bit and XX...X denotes 28 value bits, we could do this: XX...X000M Lisp_Int XX...XX01M Lisp_Cons (note that it has 29 value bits) XX...X010M Lisp_Symbol XX...X011M Lisp_Misc XX...X100M Lisp_String XX...X110M Lisp_VectorLike XX...X111M Lisp_Float Lisp_Symbol etc. would need to be on 16-byte boundaries, but that could be arranged too. Of course we don't need such niceties on 64-bit hosts, but even there I think it would be a performance win to move the tag bits to the low-order end. > Anyway, is the limiting factor really address space for Lisp objects? > If the issue is the size of a single buffer, that is concerned > with the range of integers, not addresses of Lisp objects. To represent Elisp integers that do not fit in 28 bits, we could use floating point. IEEE-floating-point hosts will give us integers up to 2**51, which is enough. There is room for a marker bit in 'struct Lisp_Float.type' to say "This number is really an integer, and operations like integerp should treat it as one". (Another possibility is to use bignums, but I assume you've already considered this.) At the C level, buffer-size-related integers are currently 'int' or 'EMACS_INT'. We need to change this to a size_t-width int. This will require a lot of C-level coding cleanup but should be invisible to the Elisp user. This low-level work needs to be done anyway, since currently Emacs doesn't work with buffers larger than 2GB even on 64-bit hosts, since such hosts typically have 32-bit 'int'.