Mon, 6 Feb 2023 13:26:00 -0800 (PST)

Related articles |
---|

Re: C arithmetic, was Software proofs, was Are there different Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-02-05) |

Re: C arithmetic, was Software proofs, was Are there different gah4@u.washington.edu (gah4) (2023-02-06) |

Re: C arithmetic, was Software proofs, was Are there different DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-02-07) |

Re: C arithmetic, was Software proofs, was Are there different gah4@u.washington.edu (gah4) (2023-02-08) |

Re: C arithmetic, was Software proofs, was Are there different anton@mips.complang.tuwien.ac.at (2023-02-08) |

Re: C arithmetic, was Software proofs, was Are there different DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-02-08) |

Re: C arithmetic, was Software proofs, was Are there different gah4@u.washington.edu (gah4) (2023-02-09) |

Re: C arithmetic, was Software proofs, was Are there different gah4@u.washington.edu (gah4) (2023-02-09) |

[5 later articles] |

From: | gah4 <gah4@u.washington.edu> |

Newsgroups: | comp.compilers |

Date: | Mon, 6 Feb 2023 13:26:00 -0800 (PST) |

Organization: | Compilers Central |

References: | 23-01-092 23-02-003 23-02-019 23-02-025 |

Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="13877"; mail-complaints-to="abuse@iecc.com" |

Keywords: | arithmetic, architecture |

Posted-Date: | 06 Feb 2023 21:27:00 EST |

In-Reply-To: | 23-02-025 |

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!)

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.