[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Change module interface to no longer use GMP objects directl

From: Paul Eggert
Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly.
Date: Sun, 8 Dec 2019 16:35:13 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 12/5/19 6:43 AM, Eli Zaretskii wrote:

   typedef unsigned long long emacs_limb_t;
   typedef unsigned long emacs_limb_t;

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;

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]