bug#14916: Fixnum procedures can be made to return non-fixnums

[Mark H Weaver]

Andy Wingo  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 #x2fff))

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

bug#14916: Fixnum procedures can be made to return non-fixnums

[Göran Weinholt]

Mark H Weaver m...@netris.org writes:

 Göran Weinholt go...@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 go...@weinholt.se
I knew it! He's stepping up his game! We must match
his game with... MUCH MORE GAME! -- The Monarch


pgpvchqclviTH.pgp
Description: PGP signature

bug#14916: Fixnum procedures can be made to return non-fixnums

[Mark H Weaver]

Göran Weinholt go...@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

bug#14916: Fixnum procedures can be made to return non-fixnums

[Göran Weinholt]

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 go...@weinholt.se
Detta skall jag visa dig medelst ett stort papper som jag har fyllt
med faktiska upplysningar! -- August Strindberg


pgpWKp7tBGsMz.pgp
Description: PGP signature