From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Making --with-wide-int the default Date: Fri, 16 Oct 2015 19:01:52 +0300 Message-ID: <83io666bv3.fsf@gnu.org> References: <5610ED13.1010406@dancol.org> <56117F37.9060808@dancol.org> <83oag087gs.fsf@gnu.org> <83oafz70im.fsf@gnu.org> <5620AF43.4050401@cs.ucla.edu> <8737xbusz1.fsf@fencepost.gnu.org> <83d1wf6v47.fsf@gnu.org> <87pp0ftbmg.fsf@fencepost.gnu.org> <831tcv6s6f.fsf@gnu.org> <87d1wft8g7.fsf@fencepost.gnu.org> <83vba754rq.fsf@gnu.org> <87zizisyg2.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1445011371 7893 80.91.229.3 (16 Oct 2015 16:02:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 16:02:51 +0000 (UTC) Cc: lekktu@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 18:02:36 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zn7Sh-0000RW-JI for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 18:02:31 +0200 Original-Received: from localhost ([::1]:54743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn7Sg-0002mm-Ol for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 12:02:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn7S9-0002AQ-QZ for emacs-devel@gnu.org; Fri, 16 Oct 2015 12:01:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn7S8-0003H8-ME for emacs-devel@gnu.org; Fri, 16 Oct 2015 12:01:57 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:57392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn7S3-0003Bw-JO; Fri, 16 Oct 2015 12:01:51 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NWB00L00LOTV700@mtaout28.012.net.il>; Fri, 16 Oct 2015 19:01:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWB00IHXLTVFN30@mtaout28.012.net.il>; Fri, 16 Oct 2015 19:01:08 +0300 (IDT) In-reply-to: <87zizisyg2.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191773 Archived-At: > From: David Kastrup > Cc: eggert@cs.ucla.edu, lekktu@gmail.com, emacs-devel@gnu.org > Date: Fri, 16 Oct 2015 16:03:09 +0200 > > >> Isn't that also changing the size of a Lisp cell? And of integer > >> arithmetic? > > > > Part of it, yes. But since a Lisp cell can hold buffer or string > > position, what else can you expect? > > That buffer or string positions not representable in the 29 bits or so > available for integers in a Lisp cell are instead represented using a > gpm number for which there is a reference in the Lisp cell. But a GPM number is nothing more or less that some C data type. It's not some magic wand that can solve problems just by being there. > You are apparently unable to deal with the concept of a Lisp type being > represented by fewer bits than the integral type used in C for things > like buffer/string positions outside of the 29-bit integer range. Let's agree to keep such comments out of this discussion, OK? Otherwise, I will simply end it. > How do you think Emacs managed 64-bit doubles "inside" of a 32-bit > integral type used for representing Lisp cells? So you are suggesting to make a Lisp integer represented like a Lisp float, i.e. accessible via a pointer? But that in itself will slow down integer arithmetics, due to the need to dereference the pointer, won't it? > GMP needs to be called only when leaving the range of "small integers" > (which is all we even have right now). 64-bit arithmetic in your plan > would be required for every single operation. Yes, when GMP kicks in, > it will be slower than operations using exactly 64-bit (not more, not > less). But it's the exception rather than the rule. But there has to be a test for when the exception happens, and that test is going to exert its price on every operation, whether it succeeds or fails the test. I'm not at all sure it will be a net win. > So much the > exception that we could entirely make do without it so far. It _will_ > occur frequently when editing files larger than 1GB or so. But only in > the _Lisp_ representations of those buffer positions. Everything > implemented in C will use the integral data type we choose for that, > throwing an error when it gets exceeded. So you are suggesting to give up the transparent exposure of members of Lisp objects that are integers? > Yes, not all of the possible offsets will be representable in one > Lisp cell. So you are suggesting that a buffer position will not always be a simple number, but will sometimes be a cons cell?