Re: C arithmetic, was Software proofs, was Are there different

On Sunday, February 5, 2023 at 6:01:04 PM UTC-8, Keith Thompson wrote:


(snip)


> The upcoming 2023 standard mandates two's complement. And it
> requires INT_MIN to be exactly -INT_MAX-1; previously INT_MIN could
> be equal to -INT_MAX, and -INT_MAX-1 could be a trap representation.
> It still permits padding bits and trap representations.


Too bad for those CDC computers, and Unisys computers.
Last I know of sign-magnitude is the IBM 7090 and 7094.




> Note that twos's complement *representation* doesn't imply two's
> complement *behavior* on overflow. Signed integer overflow still
> has undefined behavior.


Overflow behavior mostly depends on the hardware.


Many computers, such as the IBM S/360 and successors, have a bit that
enables or disables the fixed point overflow exception. (For IBM, it
also applies to decimal overflow.)


For IA32, that is x86, there is the INTO instruction, which is put
after any instruction that could generate overflow, and causes the
interrupt if the overflow bit is set. Compilers would have to generate
that instruction.


It seems, though, that has gone away in x86-64 mode.


I don't know that there is any replacement, other than a conditional
branch based on the overflow flag.


Fortran programmers rely on fixed point overflow, as they have been
doing for 60 years, and don't have unsigned.


(There are two routines in TeX that Knuth suggests replacing with
assembly code. Those do multiply and divide, with 32 bit fixed point
values, 16 bits after the binary point. Pascal has no option for
avoiding the overflow trap, and it takes a lot of Pascal code to do
the multiply and divide!)

Return to the comp.compilers page.
Search the comp.compilers archives again.