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

[Paul Eggert]

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.