[Top][All Lists]

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

Re: bignum branch

From: Andy Moreton
Subject: Re: bignum branch
Date: Sat, 14 Jul 2018 21:04:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt)

On Sat 14 Jul 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Fri, 13 Jul 2018 20:35:18 +0100
>> The mpz_* API from libgmp uses "long" as the widest type for native
>> integers, which does not work on 64bit mingw64 on Windows, where "long" is
>> 32bit and "long long" (used for EMACS_INT) is 64bit.
> Isn't that a problem in how GMP was configured for MinGW64?  I see in
> the GMP sources that it does check for "long long", so why didn't that
> work during the build?
> In the file gmp-h.in (from which gmp.h is generated during the build),
> I see this:

The choice of word size for the limbs internal to GMP is irrelevant

The problem is that if EMACS_INT is "long long", then the calls to
mpz_*_si() API routines will truncate any values passed to GMP. This
means that emacs cannot use any the mpz_*_si() routines directly.

Alternatives include:
a) Build 64bit emacs on Windows using 32bit long for EMACS_INT. This
seems undesirable as all values larger than 32bits are then bignums.

b) Use 64bit long long for EMACS_INT, and do extra work to pass native
values into GMP in two halves, i.e. something like:
    EMACS_INT i;
    mpz_t val, tmp;
    mpz_init_set_si(val, (i >> 32));
    mpz_mul_2exp(val, val, 32);
    mpz_init_set_si(tmp, (i & 0xffffffff);
    void mpz_ior(val, val, tmp);

GMP does not yet support C99 types, so will result in awkward and
inefficient handling of 64bit vlaues on LLP64 systems.


reply via email to

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