From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier " Newsgroups: gmane.emacs.help Subject: Re: Reading portions of large files Date: 12 Jan 2003 15:38:39 -0500 Organization: Yale University Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <5lbs2mdrxs.fsf@rum.cs.yale.edu> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1042442236 10912 80.91.224.249 (13 Jan 2003 07:17:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 13 Jan 2003 07:17:16 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18XyqP-0002pp-00 for ; Mon, 13 Jan 2003 08:17:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18Xypq-0001Ue-05 for gnu-help-gnu-emacs@m.gmane.org; Mon, 13 Jan 2003 02:16:38 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!news.ycc.yale.edu!rum.cs.yale.edu!rum.cs.yale.edu Original-Newsgroups: gnu.emacs.help Original-Lines: 22 Original-NNTP-Posting-Host: rum.cs.yale.edu User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Original-NNTP-Posting-Host: rum.cs.yale.edu X-Original-Trace: 12 Jan 2003 15:38:39 -0500, rum.cs.yale.edu Original-Xref: shelby.stanford.edu gnu.emacs.help:108890 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:5420 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:5420 > BTW, would it be terribly complicated to extend the range of Lisp > integers to 31bit? Currently a cons cell takes 2 words. Each word has 3 tag bits and 1 mark bit. When marking a cons cell, the GC sets the mark bit of the first word of the cell. The mark bit of the second word is unused (i.e. wasted). Since at least 1 bit of tag is needed, that means that to get 31bit integers we'd need to move the mark bit somewhere else. XEmacs decided to use 3-word cons cells (and I know they're still regularly wondering whether it was a good idea). Another approach is to use a separate mark-bit array. Lots of trade offs, a fair bit of coding, even more testing, ... Anybody interested is welcome to tried it out. My opinion is that maybe it would be nice, but since the only application I'm aware of is "editing files between 128MB and 1GB on 32bit systems", I don't think it's worth the trouble. Stefan