GNU bug report logs - #14916
Fixnum procedures can be made to return non-fixnums

Previous Next

To reply to this bug, email your comments to 14916 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Göran Weinholt <goran <at> weinholt.se>
To: bug-guile <at> gnu.org
Subject: Fixnum procedures can be made to return non-fixnums
Date: Sat, 20 Jul 2013 07:56:21 +0200

[Message part 1 (text/plain, inline)]

Hello schemers,

the fxdiv procedure from (rnrs) fails to check that its result is
representable as a fixnum:

scheme@(guile-user)> (import (rnrs))
scheme@(guile-user)> (fxdiv (least-fixnum) -1)
$1 = 2305843009213693952

It should raise an &implementation-restriction. Here are a few other
examples of the same problem:

scheme@(guile-user)> (fxdiv-and-mod (least-fixnum) -1)
$2 = 2305843009213693952
$3 = 0
scheme@(guile-user)> (fxdiv0 (least-fixnum) -1)
$4 = 2305843009213693952
scheme@(guile-user)> (fxdiv0-and-mod0 (least-fixnum) -1)
$5 = 2305843009213693952
$6 = 0
scheme@(guile-user)> (fxarithmetic-shift-left (greatest-fixnum) 1)
$7 = 4611686018427387902
scheme@(guile-user)> (fxarithmetic-shift (greatest-fixnum) 1)
$8 = 4611686018427387902

Tested with Guile 2.0.9.40-824b-dirty on an amd64 system.

Regards,

-- 
Göran Weinholt <goran <at> weinholt.se>
"Detta skall jag visa dig medelst ett stort papper som jag har fyllt
med faktiska upplysningar!" -- August Strindberg

[Message part 2 (application/pgp-signature, inline)]

Message #8 received at 14916 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Göran Weinholt <goran <at> weinholt.se>
Cc: 14916 <at> debbugs.gnu.org
Subject: Re: bug#14916: Fixnum procedures can be made to return non-fixnums
Date: Fri, 16 Aug 2013 23:32:32 -0400

Göran Weinholt <goran <at> weinholt.se> writes:

> the fxdiv procedure from (rnrs) fails to check that its result is
> representable as a fixnum:
>
> scheme@(guile-user)> (import (rnrs))
> scheme@(guile-user)> (fxdiv (least-fixnum) -1)
> $1 = 2305843009213693952
>
> It should raise an &implementation-restriction.

Hmm.  Currently, our fixnum and flonum operations are implemented in
terms of the generic operations, with added checks.  Whereas the most
important generic arithmetic operations compile to VM instructions, the
fixnum and flonum operations compile into procedure calls to scheme code
that performs the checks and then uses the generic ops.

Needless to say, this is terribly slow.  I'm reluctant to make that code
any slower by adding more checks.

However, in the coming months I intend to reimplement the fixnum and
flonum operations, using dedicated instructions in the new RTL VM which
will be the basis of Guile 2.2.

It would be possible to backport some of this to Guile 2.0 as well, but
I'm not sure it's worth the effort.

What do you think?

      Mark

Message #11 received at 14916 <at> debbugs.gnu.org (full text, mbox):

From: Göran Weinholt <goran <at> weinholt.se>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 14916 <at> debbugs.gnu.org
Subject: Re: bug#14916: Fixnum procedures can be made to return non-fixnums
Date: Sat, 17 Aug 2013 09:55:14 +0200

[Message part 1 (text/plain, inline)]

Mark H Weaver <mhw <at> netris.org> writes:

> Göran Weinholt <goran <at> weinholt.se> writes:
>
>> the fxdiv procedure from (rnrs) fails to check that its result is
>> representable as a fixnum:

> Hmm.  Currently, our fixnum and flonum operations are implemented in
> terms of the generic operations, with added checks.  Whereas the most
> important generic arithmetic operations compile to VM instructions, the
> fixnum and flonum operations compile into procedure calls to scheme code
> that performs the checks and then uses the generic ops.
>
> Needless to say, this is terribly slow.  I'm reluctant to make that code
> any slower by adding more checks.

I agree with this sentiment. The fixnum operations are supposed to be
fast, so making them slower doesn't make sense. There is a delicious
irony in the fact that the generic operations have all these extra
checks that would have to be undone by adding more checks afterwards.

> However, in the coming months I intend to reimplement the fixnum and
> flonum operations, using dedicated instructions in the new RTL VM which
> will be the basis of Guile 2.2.
>
> It would be possible to backport some of this to Guile 2.0 as well, but
> I'm not sure it's worth the effort.
>
> What do you think?

It's better to look toward the future. If Guile 2.2 will be much faster
then you get more leverage when optimizing the fixnum/flonum operations
than compared with Guile 2.0.

Regards,

-- 
Göran Weinholt <goran <at> weinholt.se>
"I knew it! He's stepping up his game! We must match
his game with... MUCH MORE GAME!" -- The Monarch

[Message part 2 (application/pgp-signature, inline)]

Message #14 received at 14916 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: Göran Weinholt <goran <at> weinholt.se>, 14916 <at> debbugs.gnu.org
Subject: Re: bug#14916: Fixnum procedures can be made to return non-fixnums
Date: Tue, 21 Jun 2016 09:20:56 +0200

Hi Mark,

I know you like mathy things and so this might be a project you would
like.  I think the right thing to do here is to redefine fixnum? as

 (= x (logand x #x2fffffff))

on 32-bit targets and 8 more f's for 64-bit targets.  Make sure to get
that inline.  In that way we'll end up unboxing X and doing unboxed
arithmetic on it.  Likewise we can insert a similar check at the end.

Andy

On Sat 17 Aug 2013 09:55, Göran Weinholt <goran <at> weinholt.se> writes:

> Mark H Weaver <mhw <at> netris.org> writes:
>
>> Göran Weinholt <goran <at> weinholt.se> writes:
>>
>>> the fxdiv procedure from (rnrs) fails to check that its result is
>>> representable as a fixnum:
>
>> Hmm.  Currently, our fixnum and flonum operations are implemented in
>> terms of the generic operations, with added checks.  Whereas the most
>> important generic arithmetic operations compile to VM instructions, the
>> fixnum and flonum operations compile into procedure calls to scheme code
>> that performs the checks and then uses the generic ops.
>>
>> Needless to say, this is terribly slow.  I'm reluctant to make that code
>> any slower by adding more checks.
>
> I agree with this sentiment. The fixnum operations are supposed to be
> fast, so making them slower doesn't make sense. There is a delicious
> irony in the fact that the generic operations have all these extra
> checks that would have to be undone by adding more checks afterwards.
>
>> However, in the coming months I intend to reimplement the fixnum and
>> flonum operations, using dedicated instructions in the new RTL VM which
>> will be the basis of Guile 2.2.
>>
>> It would be possible to backport some of this to Guile 2.0 as well, but
>> I'm not sure it's worth the effort.
>>
>> What do you think?
>
> It's better to look toward the future. If Guile 2.2 will be much faster
> then you get more leverage when optimizing the fixnum/flonum operations
> than compared with Guile 2.0.
>
> Regards,

Message #17 received at 14916 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: Göran Weinholt <goran <at> weinholt.se>, 14916 <at> debbugs.gnu.org
Subject: Re: bug#14916: Fixnum procedures can be made to return non-fixnums
Date: Wed, 22 Jun 2016 11:32:14 -0400

Andy Wingo <wingo <at> pobox.com> writes:

> Hi Mark,
>
> I know you like mathy things and so this might be a project you would
> like.  I think the right thing to do here is to redefine fixnum? as
>
>  (= x (logand x #x2fffffff))

This doesn't work for negative fixnums, because you are effectively
masking out the sign of 'x' above.  Unfortunately, this problem cannot
be fixed by changing the mask.  For purposes of the bitwise operations,
negative integers are treated as though they have an infinite number of
ones in the high bits, e.g. -1 is all ones, and is thus an identity for
'logand'.  So, there's no single sign bit, but rather an infinite number
of them, and all of those bits can also be used as value bits as well,
so there's no way to avoid masking out the sign without also masking out
high-order value bits.

One possibility would be to subtract 'most-negative-fixnum' from x
before masking, but I don't know what the compiler would do with that.

     Mark

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.