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 <go...@weinholt.se> writes: > 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,