Re: [PATCH] Add `fixnum?' VM primitive

[Andy Wingo]

On Fri 25 Mar 2011 14:21, address@hidden (Ludovic Courtès) writes:

> I think that a fixnum API sucks.  In an ideal world, the implementation
> would be optimized such that you can be switch from fixnum to bignum
> with very little overhead:
>
>   1. The run-time support should be optimized to make arithmetic
>      operations fast in the fixnum case.
>
>   2. When the compiler can statically determine that code is dealing
>      with fixnums, it can generate code that uses untagged machine
>      integers (that’s what Bigloo does, for instance).
>
> I’ve always thought that R5RS implicitly acknowledges the fact that
> implementations can provide almost costless fixnum/bignum transition.

I rolled this one around for a while in my mind too, and came to the
conclusion that the R6RS fxops can be helpful -- but only to a system
that does native compilation.

Such a system, for +, for example, would do:

  output = input-a + input-b
  if overflow-bit-set?
    promote to bignums; try again

R6RS explicitly redefines this:

  output = input-a + input-b
  if overflow-bit-set?
    error

So there's no more overhead than for normal +.  However the fact that
the result will always be a fixnum allows you to do more flow analysis.
So even without unsafe compilation options, you can omit more fixnum?
checks when you use fxops, and the amount of code emitted is smaller.

But for Guile, right now, R6RS fxops have no advantage over the normal
numeric operations.

Andy
-- 
http://wingolog.org/