11:06 p.m.
PATCH 21.5
Bignums are broken on 64-bit platforms, and have been since they were
first introduced. The problem is a spot in the code where I assumed
that EMACS_INT == int.
Do we know of any platforms where EMACS_INT == long long? I'll have to
think on how to address that.
src/ChangeLog addition:
2006-05-08 Jerry James <james(a)xemacs.org>
* number.c (Fcanonicalize_number): Use EMACS_INT instead of int,
which fixes bignum arithmetic on 64-bit platforms.
* number.h (bignum_fits_emacs_int_p): New macro.
* number.h (bignum_to_emacs_int): New macro.
xemacs-21.5 source patch:
Diff command: cvs -q diff -uN
Files affected: src/number.h src/number.c
Index: src/number.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/number.c,v
retrieving revision 1.16
diff -d -u -r1.16 number.c
--- src/number.c 2005/10/25 11:16:26 1.16
+++ src/number.c 2006/05/08 22:02:35
＠＠ -408,9 +408,9 ＠＠
number = make_bignum_bg (XRATIO_NUMERATOR (number));
#endif
#ifdef HAVE_BIGNUM
- if (BIGNUMP (number) && bignum_fits_int_p (XBIGNUM_DATA (number)))
+ if (BIGNUMP (number) && bignum_fits_emacs_int_p (XBIGNUM_DATA (number)))
{
- int n = bignum_to_int (XBIGNUM_DATA (number));
+ EMACS_INT n = bignum_to_emacs_int (XBIGNUM_DATA (number));
if (NUMBER_FITS_IN_AN_EMACS_INT (n))
number = make_int (n);
}
Index: src/number.h
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/number.h,v
retrieving revision 1.4
diff -d -u -r1.4 number.h
--- src/number.h 2004/05/21 20:56:32 1.4
+++ src/number.h 2006/05/08 22:02:35
＠＠ -100,6 +100,16 ＠＠
return Fcanonicalize_number (retval); \
} while (0)
+#if SIZEOF_EMACS_INT == SIZEOF_LONG
+# define bignum_fits_emacs_int_p(b) bignum_fits_long_p(b)
+# define bignum_to_emacs_int(b) bignum_to_long(b)
+#elif SIZEOF_EMACS_INT == SIZEOF_INT
+# define bignum_fits_emacs_int_p(b) bignum_fits_int_p(b)
+# define bignum_to_emacs_int(b) bignum_to_int(b)
+#else
+# error Bignums currently do not work with long long Emacs integers.
+#endif
+
extern Lisp_Object make_bignum (long);
extern Lisp_Object make_bignum_bg (bignum);
extern bignum scratch_bignum, scratch_bignum2;
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
4:04 p.m.
New subject: [AC 21.5] Bignum fix for 64-bit platforms
APPROVE COMMIT 21.5
I wrote:
Bignums are broken on 64-bit platforms, and have been since they
were
first introduced. The problem is a spot in the code where I assumed
that EMACS_INT == int.
I have committed this patch.
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
9:17 a.m.
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> Do we know of any platforms where EMACS_INT == long long?
Jerry> I'll have to think on how to address that.
I think this is unlikely until we start getting 128-bit platforms. It
seems rather likely that 32-bit ints will continue to be the rule,
then we get 64-bit longs. EMACS_INT will be at biggest a long.
But even then, we really want EMACS_INT == (void *), right? Moore's
law and all that, but are we really facing > 2^64 address spaces in
our lifetimes?
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
4:06 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
>>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> Do we know of any platforms where EMACS_INT == long long?
Jerry> I'll have to think on how to address that.
I think this is unlikely until we start getting 128-bit platforms. It
seems rather likely that 32-bit ints will continue to be the rule,
then we get 64-bit longs. EMACS_INT will be at biggest a long.
Sure. I just wondered why we had the "long long" logic in lisp.h.
Maybe somebody was just programming defensively, and that definition has
never been used on any real platform.
But even then, we really want EMACS_INT == (void *), right?
Moore's
law and all that, but are we really facing > 2^64 address spaces in
our lifetimes?
How long do you plan to live? :-) I can't imagine having enough storage
(both real and virtual) to fill up an entire 64-bit address space right
now. Maybe my imagination will kick in sometime before I die.
On the other hand, I still think that 640KB ought to be enough for
anybody. <*wink, wink*>
--
Jerry James, who misses his long-retired Commodore 64
5:37 p.m.
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> Maybe somebody was just programming defensively, and that
Jerry> definition has never been used on any real platform.
Of course it was Martin Buchholz! Anyway, that would be my bet. I'm
sure it was defensive, although I'm not 100% sure it was Martin.
Jerry> Jerry James, who misses his long-retired Commodore 64
Have you seen Jamie's blog with xdaliclock running on an original Mac?
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:53 p.m.
[ Sorry for the late reply. ]
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
I think this is unlikely until we start getting 128-bit platforms.
It
seems rather likely that 32-bit ints will continue to be the rule,
then we get 64-bit longs. EMACS_INT will be at biggest a long.
But even then, we really want EMACS_INT == (void *), right? Moore's
law and all that, but are we really facing > 2^64 address spaces in
our lifetimes?
Going off on a horrible tangent, I thought I'd mention this, just
for future reference:
The 64-bit (2005 .net) microsoft compiler has 32-bit ints,
32-bit longs, and 64-bit pointers. "Where's the 64-bit
datatype?", you ask? Well, that's a "long long".
What a wonderful world we live in.
--
Darryl ("If you can't fix the code, fix the compiler") Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
11:25 p.m.
Darryl Okahata <darrylo(a)soco.agilent.com> wrote:
Going off on a horrible tangent, I thought I'd mention this,
just
for future reference:
The 64-bit (2005 .net) microsoft compiler has 32-bit ints,
32-bit longs, and 64-bit pointers. "Where's the 64-bit
datatype?", you ask? Well, that's a "long long".
What a wonderful world we live in.
Argh, so I really do have to handle the long long case. I'll give it
some thought. Thanks for the heads-up, Darryl.
--
Jerry James, Assistant Professor Jerry.James(a)usu.edu
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
6847
days inactive
6855
days old
6 comments
4 participants
participants (4)
-
Darryl Okahata -
Jerry James -
Jerry James -
Stephen J. Turnbull