Darren New <dne### [at] sanrrcom> wrote:
> >   Integral types which support unlimited precision can *not* be as efficient
> > as CPU-register-sized integers

> Sure they can. I've used many computers where the unbounded arithmetic 
> was just as fast as the bounded arithmetic when you stayed within bounds.

  The only way for that is that the CPU has explicit support. In other
words, the CPU itself makes the bound checks at no additional cost in
clock cycles instead of the compiler having to add additional opcodes
which perform the checks.

  AFAIK x86 processors do not have such a feature. The only thing an integer
overflow will do is to set a flag, which can then be checked with additional
opcodes, at the cost of additional clock cycles.

> > 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.

> Nope. Ada, for example, allows you to specify an upper size on variables 
> and then actually *enforces* it, rather than just failing in bizarre 
> ways like leaving you with the sum of two positives being negative. And 
> Ada isn't known for its inefficiencies.

  This would require even more CPU support than simply checking for a
register-sized integer overflow, as you would have to check if the value
goes out of arbitrarily-set boundaries (instead of just overflowing or
underflowing over). In other words, you would have to be able to tell
the CPU, at no clock cycle cost, "if this register ever gets a value
smaller than this or larger than this, throw an exception". I have hard
time believing any existing CPU has such a feature.

  With normal CPUs the compiler would have to put a comparison and a
conditional jump after each single operation done to the variable, at the
cost of additional clock cycles. (Such a conditional jump might even mess
up the CPU's branching prediction logic, making it even more inefficient.)

  Unless you give me an understandable and logical explanation of how these
kinds of checks could be implemented without making the code slower, I just
cannot believe it's possible.

> Errr, no. I've used plenty of CPUs that provide for traps on overflow, 
> so the normal case is fast and when the value overflows, it traps out 
> and switches to the slower bignums rather than giving the wrong answers.

  I must admit that I'm not 100% sure if the x86 architecture supports
integer register overflow exceptions, but I'm quite certain it doesn't.

  Sure, there are some other CPUs which do, but in practical terms that
doesn't help the average programmer too much.

-- 
                                                          - Warp

Post a reply to this message