Whoosh! The question is not whether it is possible to detect overflow, but rather how easy it is. Instructions for signed arithmetic set the condition code appropriately for signed operands, but not for unsigned operands, e.g., adding 00000001 to FFFFFFFF with A gives a zero condition code while AL gives an overflow condition code. If there were no AL instruction then detecting the overflow would be more awkward.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [[email protected]] on behalf of Robin Vowels [[email protected]] Sent: Thursday, April 21, 2022 9:08 AM To: [email protected] Subject: Re: Unexpected C code On 2022-04-21 22:43, Seymour J Metz wrote: > The problem is detecting overflow. Even Intel has overflow. > ________________________________________ > From: IBM Mainframe Assembler List [[email protected]] > on behalf of Robin Vowels [[email protected]] > Sent: Wednesday, April 20, 2022 10:38 PM > To: [email protected] > Subject: Re: Unexpected C code > > From: "Paul Gilmartin" > <[email protected]> > Sent: Wednesday, April 20, 2022 10:32 AM > >> C programmers don't give a damn about overflows. An unfortunate >> consequence, >> probably, of hardware architectures which, unlike 360, lack unsigned >> instructions, forcing compilers to generate signed instructions for >> unsigned operations. > > I think that you will find that in machines that store negative values > in two's complement form will produce a correct sum (or difference) > using "signed" instructions, since all 32 bits* participate in the > addition (or subtraction. > > On the S/360, the AL and SL instructions set the condition code > differently from A and S, but the 32-bit sum or difference is the same > as A and S. > __________________________ > > * [or whatever the word size is]
