Who's afraid of a big bad optimizing compiler?
Who's afraid of a big bad optimizing compiler?
Posted Jul 20, 2019 13:07 UTC (Sat) by anton (subscriber, #25547)In reply to: Who's afraid of a big bad optimizing compiler? by PaulMcKenney
Parent article: Who's afraid of a big bad optimizing compiler?
So from the viewpoint of someone in 1990, requiring wrap on signed integer overflow would have required substantial clairvoyance.Not at all. No significant new architecture with something other than twos-complement representation for signed integers was introduced after 1970. They sure saw during C standardization that the future was twos-complement , but they wanted to support the (then) present which included descendants of architectures from the 1960s.
That being said, even on these architectures implementing twos-complement would not be that expensive. They already support unsigned integers with wraparound (or C would not have standardized that). For +, -, and *, the same operations can be used for twos-complement arithmetics; inequality comparisons and possibly division would become a little more expensive, though.
Posted Jul 21, 2019 11:11 UTC (Sun)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link]
If I remember correctly, the usual way to do unsigned arithmetic on ones-complement-only systems was to force the sign bit clear after each addition and subtraction operation. And the ones-complement CDC 6600 systems used floating point to do integer multiplication and division, which required tricks normally used in multiple-precision arithmetic to get a 60-bit unsigned result out of floating-point operations with 48-bit mantissas. One reason that this worked was that there was a separate instruction for normalizing floating-point numbers, as well as another instruction that produced the lower 48 bits of the 96-bit product of two 48-bit mantissas.
Fun times! ;-)
Who's afraid of a big bad optimizing compiler?