[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: small integers
- To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu
- Subject: Re: small integers
- From: Simon Spero <ses@SunSite.unc.edu>
- Date: Sat, 10 Oct 92 23:48:10 -0400
- Cc: email@example.com
- In-reply-to: Your message of "Sat, 10 Oct 92 22:38:31 EDT." <9210110238.AA26899@SunSite.unc.edu>
>I don't think this will work. The fact that a function will return only a
>fixnum, if it returns anything at all, must be known at compile time if you
>are to generate optimal code. Handlers are established dynamically, not
>lexically, so the compiler could not be sure what policy would be in effect
>when a function is called.
What I was thinking off was trying static analysis to determine which handler
would be in force for a given function; if it can be shown that for all
invocations the error re-raising version is in force, then one can deduce
that the only valid return type is fixnum; if this cannot be shown, then
we're back where we started. This analysis could be simplified by using some
macro (with-small-integers &rest body),sorry, #rest; force of habitr, which
would set the hander appropriately. The same goes for the bignum version.
The idea is that the compiler would treat these handlers as special cases
and generate the same code as before when the chosen policy is known at
The advantage of this method is that it doesn't introduce any strange new
semantics; bignums are generated by overflows triggering an exception/retry
like mechanism in nearly all implementations now (did it overflow? jump to
bignum code). It's more flexible that the either/or solutions, and is
conceptually pretty simple.
The big disadvantages are that if the analysis fails, then the result type
is no longer known exactly, and overflowing bignums may cost an extra
function call. Another hassle is that this introduces yet another potential
place to split. There's probably a show-stopper in there, but I can't quite
>I don't understand your other suggestion.
Well, I was trying to be obfuscuated, but I guess I over did it; what I was
really doing (I think - it's getting early this side of the pond) was suggesting
a name for the previously proposed machine-length 'integer'; by calling it
'long', programmers who are used to 'C' will automatically intuit its
non-numeric properties. The usual problems of boxing and unboxing still apply,
but static analysis can get rid of most redundant box/unbox pairs.
'long' would not be a replacement for the existing integer types; it would
be an additional integer like type for use by the mathematically impure.