From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly. Date: Sun, 8 Dec 2019 16:35:13 -0800 Organization: UCLA Computer Science Department Message-ID: References: <20191117183828.82379-1-phst@google.com> <089f3d06-e227-27da-c8fe-afcbbbbc934a@cs.ucla.edu> <10cefdff-38ce-438b-881d-15d2fe816a8b@cs.ucla.edu> <3d727645-911e-fc71-1f86-364aa82d06ba@cs.ucla.edu> <287b5f71-75eb-bae2-4f6e-01cce6f07b02@cs.ucla.edu> <87sgmdmxn9.fsf@hase.home> <3479c610-17b7-579c-8109-f7f5d237dcc2@cs.ucla.edu> <83k17aj0je.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="106896"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 Cc: phst@google.com, schwab@linux-m68k.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii , Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 09 01:37:02 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ie72r-000Re6-Ex for ged-emacs-devel@m.gmane.org; Mon, 09 Dec 2019 01:37:01 +0100 Original-Received: from localhost ([::1]:34666 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ie72p-0002Kj-NO for ged-emacs-devel@m.gmane.org; Sun, 08 Dec 2019 19:36:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35116) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ie71Q-0002KV-Vc for emacs-devel@gnu.org; Sun, 08 Dec 2019 19:35:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ie71O-0006L5-Bt for emacs-devel@gnu.org; Sun, 08 Dec 2019 19:35:31 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34194) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ie71F-0006EN-Gu; Sun, 08 Dec 2019 19:35:21 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3F3211600CC; Sun, 8 Dec 2019 16:35:14 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mIfaDFT5lJ7h; Sun, 8 Dec 2019 16:35:13 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 65E9A1600E7; Sun, 8 Dec 2019 16:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id I7gNitUPPjri; Sun, 8 Dec 2019 16:35:13 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 4467A1600CC; Sun, 8 Dec 2019 16:35:13 -0800 (PST) In-Reply-To: <83k17aj0je.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:243250 Archived-At: On 12/5/19 6:43 AM, Eli Zaretskii wrote: > this: > > #if ULONG_MAX == 0xFFFFFFFF > typedef unsigned long long emacs_limb_t; > # define EMACS_LIMB_MAX ULLONG_MAX > #else > typedef unsigned long emacs_limb_t; > # define EMACS_LIMB_MAX ULONG_MAX > #endif > > seems to punish every 32-bit build of Emacs (and on MS-Windows even > the 64-bit builds, AFAIU). Is there a reason for doing this? Testing > for the native size of an 'unsigned long' data type is not > significantly more complicated than the above, and GMP goes with that > when it determines the type of mp_limb_t, AFAIK. Actually GMP uses a more complicated way to determine the type of mp_limb_t. The builder of GMP can select 'unsigned long long' or 'unsigned long', and although the default GMP limb type is typically 'unsigned long' there are some notable exceptions (including 64-bit mingw and cygwin, 32-bit powerpc, etc.) that exploit the 64-bit registers of certain platforms. Are your concerns about "punishing" based on choosing a different limb size from GMP's? But emacs-module.h doesn't attempt to mimic GMP's limb size. Instead, it is intended to be portable and reliable and "fast enough". It is not a high-performance API; for example, if you write a simple GMP-based module function to add 1 to a bignum, calling the function will copy all the integer's bits four times (in addition to the work that libgmp itself does to add 1). Since performance is not a big deal in this interface, choice of limb size is not a big deal either. With that in mind, perhaps we should replace the above 7 lines with these 2 lines: typedef unsigned long long emacs_limb_t; #define EMACS_LIMB_MAX ULLONG_MAX This should address the point you raise (for mingw and cygwin, anyway), and would be even simpler and more reliable than what we have now. For example, it'd let modules format limb values with "%llx" instead of requiring something more complicated (as the current master does). As I mentioned in a previous email I'm not a fan of a module API for bignums that requires so much copying. If modules hardly ever use bignums then converting via text should be good enough; and if they use bignums a lot then the extra copying will make for poor performance for large bignums. But I suppose that if the latter becomes an issue, we can add a better API later and support the current API "forever" for older modules.