bignum branch

classic Classic list List threaded Threaded
205 messages Options
1234 ... 11
Reply | Threaded
Open this post in threaded view
|

bignum branch

Tom Tromey-4
I've pushed the bignum branch to emacs git, as feature/bignum.

Please read through it and try it out, and reply to this message with
your comments.

thanks,
Tom

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Eli Zaretskii
> From: Tom Tromey <[hidden email]>
> Date: Thu, 12 Jul 2018 22:26:38 -0600
>
> I've pushed the bignum branch to emacs git, as feature/bignum.

Thanks for your work on this.  (I didn't yet have time to have a look,
but will do so soon.)

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Robert Pluim
In reply to this post by Tom Tromey-4
Tom Tromey <[hidden email]> writes:

> I've pushed the bignum branch to emacs git, as feature/bignum.
>
> Please read through it and try it out, and reply to this message with
> your comments.

Iʼve not tried it it yet, but I see that GMP will basically always be
available because mini-gmp.o is used when gmp is not found by
configure. Would it make sense to add GMP to emacs_config_features so
we can detect that case?

Regards

Robert

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Robert Pluim
Robert Pluim <[hidden email]> writes:

> Tom Tromey <[hidden email]> writes:
>
>> I've pushed the bignum branch to emacs git, as feature/bignum.
>>
>> Please read through it and try it out, and reply to this message with
>> your comments.
>
> Iʼve not tried it it yet, but I see that GMP will basically always be
> available because mini-gmp.o is used when gmp is not found by
> configure. Would it make sense to add GMP to emacs_config_features so
> we can detect that case?

And now that I have tried it:

        ELC      obsolete/pgg-pgp.elc

    In toplevel form:
    obsolete/pgg-pgp.el:30:1:Error: Error in CCL program

This is with gmp 6.1.2

If I force usage of mini-gmp.o I get the same error.

Regards

Robert

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Eli Zaretskii
> From: Robert Pluim <[hidden email]>
> Date: Fri, 13 Jul 2018 10:45:34 +0200
> Cc: [hidden email]
>
> Would it make sense to add GMP to emacs_config_features so we can
> detect that case?

Yes, I think so.

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Eli Zaretskii
In reply to this post by Robert Pluim
> From: Robert Pluim <[hidden email]>
> Date: Fri, 13 Jul 2018 11:51:43 +0200
> Cc: [hidden email]
>
>         ELC      obsolete/pgg-pgp.elc
>
>     In toplevel form:
>     obsolete/pgg-pgp.el:30:1:Error: Error in CCL program

The line number makes no sense.  Does the problem happen when loading
'cl'?  I mean, what CCL program is involved here?

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Eli Zaretskii
> Date: Fri, 13 Jul 2018 15:04:15 +0300
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email]
>
> > From: Robert Pluim <[hidden email]>
> > Date: Fri, 13 Jul 2018 11:51:43 +0200
> > Cc: [hidden email]
> >
> >         ELC      obsolete/pgg-pgp.elc
> >
> >     In toplevel form:
> >     obsolete/pgg-pgp.el:30:1:Error: Error in CCL program
>
> The line number makes no sense.  Does the problem happen when loading
> 'cl'?  I mean, what CCL program is involved here?

Sorry, I looked in the wrong branch.  Line 30 is actually about
loading pgg.  Does the same problem happen when pgg.el is loaded
and/or compiled?

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Robert Pluim
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> From: Robert Pluim <[hidden email]>
>> Date: Fri, 13 Jul 2018 11:51:43 +0200
>> Cc: [hidden email]
>>
>>         ELC      obsolete/pgg-pgp.elc
>>
>>     In toplevel form:
>>     obsolete/pgg-pgp.el:30:1:Error: Error in CCL program
>
> The line number makes no sense.  Does the problem happen when loading
> 'cl'?  I mean, what CCL program is involved here?

I donʼt know. I tried replacing the (require) on that line with the
contents of the require'd library, and the error went away. Iʼve
tracked it down to resolve_symbol_ccl_program returning nil, but the
only thing Tom changed in that function was replacing INTERGP with
FIXNUMP.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Robert Pluim
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> Date: Fri, 13 Jul 2018 15:04:15 +0300
>> From: Eli Zaretskii <[hidden email]>
>> Cc: [hidden email]
>>
>> > From: Robert Pluim <[hidden email]>
>> > Date: Fri, 13 Jul 2018 11:51:43 +0200
>> > Cc: [hidden email]
>> >
>> >         ELC      obsolete/pgg-pgp.elc
>> >
>> >     In toplevel form:
>> >     obsolete/pgg-pgp.el:30:1:Error: Error in CCL program
>>
>> The line number makes no sense.  Does the problem happen when loading
>> 'cl'?  I mean, what CCL program is involved here?
>
> Sorry, I looked in the wrong branch.  Line 30 is actually about
> loading pgg.  Does the same problem happen when pgg.el is loaded
> and/or compiled?

emacs -Q
(require 'pgg)



Debugger entered--Lisp error: (error "Error in CCL program")
  register-ccl-program(pgg-parse-crc24 [1 30 14 114744 114775 0 161 131127 1 148217 15 82167 1 1848 131159 1 1595 5 256 114743 390 114775 19707 1467 16 7 183 1 4611686018427382276 4611686018427380740 22])
  byte-code("\301\302!\203\33\0\303\30\304\10!\210\305\306\307\310\306\10\"#\210)\311\312\313\"\210\301\207" [prog fboundp define-ccl-program [1 30 14 114744 114775 0 161 131127 1 148217 15 82167 1 1848 131159 1 1595 5 256 114743 390 114775 19707 1467 16 7 183 1 4611686018427382276 4611686018427380740 22] (lambda (def-tmp-var) (defconst pgg-parse-crc24 def-tmp-var nil)) put pgg-parse-crc24 ccl-program-idx register-ccl-program defalias pgg-parse-crc24-string #f(compiled-function (string) #<bytecode 0x5033e9>)] 6)
  require(pgg-parse)
  eval-buffer(#<buffer  *load*> nil "/home/rpluim/repos/emacs-bignum/lisp/obsolete/pgg.el" nil t)  ; Reading at buffer position 1024
  load-with-code-conversion("/home/rpluim/repos/emacs-bignum/lisp/obsolete/pgg.el" "/home/rpluim/repos/emacs-bignum/lisp/obsolete/pgg.el" nil t)
  require(pgg)
  eval((require 'pgg) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)


Which confirms what I found using gdb. That 4611686018427382276 in the
backtrace is bigger than 'most-positive-fixnum' on this machine, so
the error makes sense. I know nothing about how to fix CCL though.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Robert Pluim
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> From: Robert Pluim <[hidden email]>
>> Date: Fri, 13 Jul 2018 10:45:34 +0200
>> Cc: [hidden email]
>>
>> Would it make sense to add GMP to emacs_config_features so we can
>> detect that case?
>
> Yes, I think so.

OK. Tom, shall I push such a change to the feature/bignum branch?

Robert

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Eli Zaretskii
In reply to this post by Robert Pluim
> From: Robert Pluim <[hidden email]>
> Cc: [hidden email]
> Date: Fri, 13 Jul 2018 15:02:01 +0200
>
> emacs -Q
> (require 'pgg)
>
> ⇒
>
> Debugger entered--Lisp error: (error "Error in CCL program")
>   register-ccl-program(pgg-parse-crc24 [1 30 14 114744 114775 0 161 131127 1 148217 15 82167 1 1848 131159 1 1595 5 256 114743 390 114775 19707 1467 16 7 183 1 4611686018427382276 4611686018427380740 22])

Thanks.

I guess the operations in pgg-parse-crc24 give birth to these numbers,
so ccl.c should be fixed to avoid that, for backward compatibility
with existing CCL programs.  (I'm guessing that ccl.c relies on
integer wrap-around, and bignums violate that.)

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Andy Moreton-3
In reply to this post by Tom Tromey-4
On Thu 12 Jul 2018, Tom Tromey wrote:

> I've pushed the bignum branch to emacs git, as feature/bignum.
>
> Please read through it and try it out, and reply to this message with
> your comments.
>
> thanks,
> Tom

I've bootstrapped this with 64bit mingw64 (MSYS2) on Windows without
problems. There were a few compile warnings:

C:/emacs/git/emacs/bignum/src/floatfns.c: In function 'Fabs':
C:/emacs/git/emacs/bignum/src/floatfns.c:291:29: warning: overflow in implicit constant conversion [-Woverflow]
       mpz_init_set_si (val, - MOST_NEGATIVE_FIXNUM);
                             ^

In toplevel form:
../../../lisp/calc/calc-aent.el:28:1:Error: Arithmetic range error: "truncate", -1.0e+INF
make[2]: *** [Makefile:301: calc/calc-aent.elc] Error 1

In toplevel form:
../../../lisp/calc/calc-alg.el:28:1:Error: Arithmetic range error: "truncate", -1.0e+INF
make[2]: *** [Makefile:301: calc/calc-alg.elc] Error 1


All of the other warnings are the same as the master branch.

    AndyM


Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Eli Zaretskii
> From: Andy Moreton <[hidden email]>
> Date: Fri, 13 Jul 2018 15:28:27 +0100
>
> I've bootstrapped this with 64bit mingw64 (MSYS2) on Windows without
> problems.

Thanks.

> All of the other warnings are the same as the master branch.

If those warnings were never reported before, please report them (in a
separate thread, preferably a bug report).  Emacs should ideally
compile cleanly, without any warnings, as long as you use a recent
enough version of GCC.

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Andy Moreton-3
On Fri 13 Jul 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <[hidden email]>
>> Date: Fri, 13 Jul 2018 15:28:27 +0100
>>
>> I've bootstrapped this with 64bit mingw64 (MSYS2) on Windows without
>> problems.
>
> Thanks.
>
>> All of the other warnings are the same as the master branch.
>
> If those warnings were never reported before, please report them (in a
> separate thread, preferably a bug report).  Emacs should ideally
> compile cleanly, without any warnings, as long as you use a recent
> enough version of GCC.

The warnings on the master branch are from byte compiling lisp, not
from GCC.

    AndyM


Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Eli Zaretskii
> From: Andy Moreton <[hidden email]>
> Date: Fri, 13 Jul 2018 15:53:15 +0100
>
> The warnings on the master branch are from byte compiling lisp, not
> from GCC.

Ah, okay.

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Andy Moreton-3
In reply to this post by Andy Moreton-3
On Fri 13 Jul 2018, Andy Moreton wrote:

> On Thu 12 Jul 2018, Tom Tromey wrote:
>
>> I've pushed the bignum branch to emacs git, as feature/bignum.
>>
>> Please read through it and try it out, and reply to this message with
>> your comments.
>>
>> thanks,
>> Tom
>
> I've bootstrapped this with 64bit mingw64 (MSYS2) on Windows without
> problems. There were a few compile warnings:
>
> C:/emacs/git/emacs/bignum/src/floatfns.c: In function 'Fabs':
> C:/emacs/git/emacs/bignum/src/floatfns.c:291:29: warning: overflow in implicit constant conversion [-Woverflow]
>        mpz_init_set_si (val, - MOST_NEGATIVE_FIXNUM);

There is also odd behaviour on the bignum branch:
ELISP> most-negative-fixnum
-2305843009213693952 (#o200000000000000000000, #x2000000000000000)
ELISP> (abs most-negative-fixnum)
0 (#o0, #x0, ?\C-@)

On master, this behaves as expected:
ELISP> most-negative-fixnum
-2305843009213693952 (#o200000000000000000000, #x2000000000000000)
ELISP> (abs most-negative-fixnum)
-2305843009213693952 (#o200000000000000000000, #x2000000000000000)


Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Tom Tromey-4
In reply to this post by Robert Pluim
>>>>> "Robert" == Robert Pluim <[hidden email]> writes:

Robert> Eli Zaretskii <[hidden email]> writes:
>>> From: Robert Pluim <[hidden email]>
>>> Date: Fri, 13 Jul 2018 10:45:34 +0200
>>> Cc: [hidden email]
>>>
>>> Would it make sense to add GMP to emacs_config_features so we can
>>> detect that case?
>>
>> Yes, I think so.

Robert> OK. Tom, shall I push such a change to the feature/bignum branch?

Sure, thanks.

Tom

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Andy Moreton-3
In reply to this post by Andy Moreton-3
On Fri 13 Jul 2018, Andy Moreton wrote:

> On Fri 13 Jul 2018, Andy Moreton wrote:
>
>> On Thu 12 Jul 2018, Tom Tromey wrote:
>> I've bootstrapped this with 64bit mingw64 (MSYS2) on Windows without
>> problems.

It seems that there are problems after all.

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.

    AndyM



Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Eli Zaretskii
> From: Andy Moreton <[hidden email]>
> 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:

  @DEFN_LONG_LONG_LIMB@
  ...
  #ifdef __GMP_SHORT_LIMB
  typedef unsigned int mp_limb_t;
  typedef int mp_limb_signed_t;
  #else
  #ifdef _LONG_LONG_LIMB
  typedef unsigned long long int mp_limb_t;
  typedef long long int mp_limb_signed_t;
  #else
  typedef unsigned long int mp_limb_t;
  typedef long int mp_limb_signed_t;
  #endif
  #endif

This seems to indicate that if the configure script defines
_LONG_LONG_LIMB, then mp_limb_t will be a 64-bit signed integer type,
which is what you want.  And looking at configure.ac, I seem to
understand that MinGW64 should have caused _LONG_LONG_LIMB to be
defined.  (I cannot test all those because I don't have MinGW64
installed.)  Can you see why all this didn't work for you?

Reply | Threaded
Open this post in threaded view
|

Re: bignum branch

Andy Moreton-3
On Sat 14 Jul 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <[hidden email]>
>> 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:
[snipped]

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

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);
    mpz_clear(tmp);

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

    AndyM


1234 ... 11