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: Mon, 25 Nov 2019 13:03:02 -0800 Organization: UCLA Computer Science Department Message-ID: <3479c610-17b7-579c-8109-f7f5d237dcc2@cs.ucla.edu> 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> 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="11533"; 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: Philipp Stephani , Philipp Stephani , Stefan Monnier , Emacs developers To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 25 22:04:56 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 1iZLXQ-0002hT-Ji for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2019 22:04:52 +0100 Original-Received: from localhost ([::1]:48106 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZLXP-0003kw-Ak for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2019 16:04:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55989) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZLVn-0003io-UU for emacs-devel@gnu.org; Mon, 25 Nov 2019 16:03:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZLVl-0003S4-CE for emacs-devel@gnu.org; Mon, 25 Nov 2019 16:03:11 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33056) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iZLVk-0003QZ-In for emacs-devel@gnu.org; Mon, 25 Nov 2019 16:03:08 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7481B160084; Mon, 25 Nov 2019 13:03:04 -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 6l8Ayvzqv3BN; Mon, 25 Nov 2019 13:03:03 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AAA7C1600CC; Mon, 25 Nov 2019 13:03:03 -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 ywUhi7-x9WmA; Mon, 25 Nov 2019 13:03:03 -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 02555160084; Mon, 25 Nov 2019 13:03:03 -0800 (PST) In-Reply-To: <87sgmdmxn9.fsf@hase.home> 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:242719 Archived-At: On 11/24/19 1:28 AM, Andreas Schwab wrote: > It's like compiling for a completely different architecture. Yes, and that's the point. We agree that choice of 'configure' options can change the platform, and that one cannot assume that modules built for one platform are compatible with an Emacs built for another. The disagreement is whether we should consider GMP to be "part of Emacs" (so GMP should not affect the module ABI) or "part of the platform" (so GMP can affect it). Both approaches are plausible; the former lets modules be more portable, and the latter gives modules better performance. Although I'm a fan of portability, here the portability advantage seems small and the performance advantage significant, so it's not clear that saying "GMP is part of Emacs" would be a win. Since an Emacs 27 release is imminent, perhaps the best thing to do would be to remove the extract_big_integer and make_big_integer methods from src/emacs-module.h.in. These methods are not good in master because they depend on gmp.h, and the proposed replacements are not good because they're slow and awkward. Surely we can do better than either, but we can't do that in a rush. Plus, quite possibly it will turn out that module authors don't much need a specialized API for bignums. After all, we've gotten along so far without a specialized API for bool-vectors, and to some extent bignums are just bool-vectors in disguise. I can propose a simple patch along these lines, if there's interest.