Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: two's complement idea Date: Thu, 28 Nov 2019 12:27:18 -0800 Organization: A noiseless patient Spider Lines: 67 Message-ID: <86y2vzagrd.fsf@linuxsc.com> References: <86lfspcekw.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="dce185ee50ea005ee4a34884a21fb89a"; logging-data="26629"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18yNHt4fu1TzDPHwhElj5HkhiBSnZlcR/w=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:xHVinLqpxIICi1iF05d+Rf7MRk8= sha1:9HbaZZA4kNCXIU7EoQe7jgZ7gNQ= Xref: csiph.com comp.lang.c++:70090 Paavo Helde writes: > On 9.11.2019 16:24, Tim Rentsch wrote: > >> Paavo Helde writes: >> >>> On 5.11.2019 17:58, Bonita Montero wrote: >>> >>>> With the same reasoning you could say that unsigneds might never >>>> wrap; but in fact they're specified to wrap. >>> >>> In retrospect, this (wrapping unsigneds) looks like a major design mistake. >>> >>> IMO, wrapping integers (signed or unsigned) are an example of >>> "optimization which nobody asked for", and they are there basically >>> only because the hardware happened to support such operations. >> >> Apparently you think how the hardware behaves (specifically, for >> unsigned or two's complement operands) is some sort of accident >> of history. It isn't. It was a deliberate choice, made by smart >> people. It isn't just a coincidence that the semantics of >> wrapping works nicely in a variety of applications. > > The hardware which I am familiar with properly sets the carry and > overflow flags for arithmetic operations. In case of multiplication it > also produces the result twice larger than the operands, in order to > not lose information. So at the hardware level the results are always > well-defined and complete, this is very fine. The calling program can > study the flags and decide what to do about this. > > The problem with C is that they decided the best way to deal with this > is just to ignore the overflow flag and the upper half of the > multiplication result. Not sure about PDP-11 itself, but they had to > think about other hardware too, and at some point they decided that > the best way to deal with the problem was just to ignore all the extra > information the current or future CPU-s might provide. > > An imaginary conversation: > > A: BTW, what should we do with the arithmetic overflow? There are > overflow flags and extended precision results in some hardware that we > could use. > > B: Because of speed and simplicity, we just ignore it. Each extra > opcode would slow us down! > > A: But in case of multiplication, we might lose half of the result! > > B. Just ignore it. > > A. But what we write down in the specs? We can't just say we carry out > an hardware operation and then ignore everything except the first > result register. > > B. Let's see... Isn't there a nice name for that behavior? Yep, it's > called wrapping! Write this down in the specs! > > A. But, but, with signed integers, there are different > representations, so that on some hardware it does not actually wrap! > > B. Ouch, my head is hurting. Just declare it undefined then! I believe your view of the history doesn't match what actually occurred. I don't propose attempting to resolve the matter; I just wanted to be clear that I think I see what you're saying even though I believe some of your premises don't match the historical facts.