small integers

[davis@ilog.ilog.fr (Harley Davis)]

   Date: Fri, 9 Oct 92 11:33:08 -0400
   From: Jeff Piazza <piazza@cambridge.apple.com>
 
   we would have, instead of two different 5's, two different
   +'s: one under which the <small-integer> class is closed, and one
   under which it isn't.  With the former operation, when the arguments
   are provably small integers, the compiler can generate a machine ADD
   instruction, and also conclude that the result will be a small
   integer.

This solution has been used in Le-Lisp for about 10 years.  It works
quite well within individual functions and for fixnums in general, but
does not address the crucial boxed float problem across function
boundaries.  However, it can solve it within a single function with
just a little compiler cleverness.  The result is that all fixnum and
simple FP programs run at the same efficiency as C but any real
programs are still considerably slower.

The real advantage of this approach is that it is easy to implement
and the user knows exactly what he's getting without having to
second-guess the compiler or read a lot of compiler output messages.
It also provides a very simple form of expression type declaration
without verbose syntax, which allows unboxing of floats within a
function.

This approach combined with return type declarations and sealing
should also allow intramodule optimizations, allow the increase in
implementational complexity is considerable.  For intermodule
optimizations, we would need more details on what the module system
provides.

I don't think the call to fix+ or whatever should be masked by a +
macro.  Furthermore, I don't see how to implement such a macro unless
the Dylan macro system allows access to a lot of compiler information.
I think + should check for overflow and fix+ should not, as Fahlman
suggested when he brought up this idea.  They are really two different
semantic operations, one working on numbers and the other on
representations.

-- Harley Davis