From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Making --with-wide-int the default Date: Fri, 16 Oct 2015 11:18:31 +0200 Message-ID: <87pp0ftbmg.fsf@fencepost.gnu.org> References: <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444987684 3968 80.91.229.3 (16 Oct 2015 09:28:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 09:28:04 +0000 (UTC) Cc: lekktu@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 11:28:03 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 1Zn1It-0005ST-2o for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 11:27:59 +0200 Original-Received: from localhost ([::1]:52112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn1In-0007j2-C0 for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 05:27:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn19o-000462-Uo for emacs-devel@gnu.org; Fri, 16 Oct 2015 05:18:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn19o-0002la-0l for emacs-devel@gnu.org; Fri, 16 Oct 2015 05:18:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn19k-0002jg-TZ; Fri, 16 Oct 2015 05:18:32 -0400 Original-Received: from localhost ([127.0.0.1]:54879 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Zn19j-0000o1-S7; Fri, 16 Oct 2015 05:18:32 -0400 Original-Received: by lola (Postfix, from userid 1000) id 5C7C9E239A; Fri, 16 Oct 2015 11:18:31 +0200 (CEST) In-Reply-To: <83d1wf6v47.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Oct 2015 12:06:00 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:191729 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: Eli Zaretskii , Juanma Barranquero >> , emacs-devel@gnu.org >> Date: Fri, 16 Oct 2015 10:18:26 +0200 >> >> Instead of going to 64-bit unilaterally it would seem to make more sense >> to me to degrade gracefully into gmp. > > How can GMP help extend the maximum size of buffers and strings beyond > what a 32-bit EMACS_INT allows? By choosing an appropriate data type for representing buffer/string sizes in C and converting back-and-forth from the Lisp type as needed. Pretty much the same way we do it now. I think it would be a reasonable restriction to keep to 2GB size of strings and buffers when working with a 32bit executable. That's what people expect on a 32-bit architecture. > And how can GMP be faster than (or even close to) the native 64-bit > integral types supported by the C compiler? GMP will not get to see the vast majority of numbers passing through Emacs, and on a 32-bit system 32-bit integral types will be faster than 64-bit integral types. When you are editing gigabyte files, at some point of time, the Lisp representation of the respective offsets in the high part of the buffer will become the responsibility of GMP, yes. I'm not worried about that. -- David Kastrup