Darren New <dne### [at] sanrrcom> wrote:
> There's the problem right there.  As one professor I knew put it, "There 
> are two kinds of languages. The ones that support unbounded arithmetic 
> types, and the ones that don't know they need to support unbounded 
> arithmetic types."

  Having automatic unbounded arithmetic types is fine as long as you don't
care about efficiency.

  Integral types which support unlimited precision can *not* be as efficient
as CPU-register-sized integers unless you explicitly tell to the compiler
that "this variable will always stay within these limits", in which case
you are already stuck with the same limitation as the C integral variables.
If you don't tell the compiler those limits and it has to make sure that
in case of overflow it switches to unlimited precision, then those integral
types simply cannot be as fast as the bounded ones. It's just physically
impossible. If nothing else, the compiler will have to add an overflow
check after each single operation done with those integers, thus adding
clock cycles and code size (filling code caches faster).

  I'm also sure that being forced to prepare for unlimited precision math
makes many compiler optimizations impossible (which would be possible with
register-sized integers).

  (Also, in the general case a compiler cannot deduce by examining a piece
of code that a variable will never have a value outside certain boundaries.
I'm certain this kind of check would be equivalent to the halting problem.)

-- 
                                                          - Warp

Post a reply to this message