Re: Do CO++ signed types have modulo semantics?

[Nicholas Nethercote <njn at cs dot utexas dot edu>]

On Tue, 28 Jun 2005, Joe Buck wrote:

> There is no such assumption.  Rather, we assume that overflow does not
> occur about what happens on overflow.  Then, for the case where overflow
> does not occur, we get fast code.  For many cases where overflow occurs
> with a 32-bit int, our optimized program behaves the same as if we had a
> wider int.  In fact, the program will work as if we had 33-bit ints.  Far
> from producing a useless result, the optimized program has consistent
> behavior over a broader range.  To see this, consider what the program
> does with a=MAX_INT, b=MAX_INT-1.  My optimized version, which always
> calls blah(b+1), which is what a 33-bit int machine would do.  It does
> not trap.

This point about 33-bit machines is interesting because it raises an
optimisation scenario that hasn't been mentioned so far.

Consider doing 32-bit integer arithmetic on 64-bit machines which only
support 64-bit arithmetic instructions.  On such machines you have to use
sign-extensions or zero-extensions after 64-bit operations to ensure
wrap-around semantics (unless you can prove that the operation will not
overflow the bottom 32 bits, or that the value will not be used in a way
that exposes the fact you're using 64-bit arithmetic).

But -- if I have understood correctly -- if the 32-bit values are signed
integers, a C compiler for such a machine could legitimately omit the
sign-extension.  Whereas for unsigned 32-bit values the C standard implies
that you must zero-extend afterwards.  I hadn't realised that.  This has
been an enlightening thread :)

Nick