EricP <ThatWouldBeTelling@thevillage.com> writes:
>This is why the VAX with it PSW global flag enabling overflow detect
>had problems - real code would have to keep switching it on and off,
>which would cause a large overhead so they just left it on for
>Fortran or Ada and lived with occasional false overflow traps.
>Which is why Alpha has separate instructions for Add and AddTrapOverflow.

Already MIPS has addu (add on Alpha) and add (addv on Alpha). They
apparently thought that overflow trapping was required, but having no
flags was a design principle in these architectures (maybe thanks to
the VAX), so they put in trapping instructions. I wonder how much use
they saw. IIRC (but my memory is unreliable on this) recent MIPS
variants have eliminated the trapping variants, but added flags for
carry and overflow.

>The only mechanism I can think of that can handle that kind of
>flexibility smoothly would be based on multiple language data types,

On the language level types seem to be the way to go for languages
that use types to differentiate between integer and FP addition. This
makes it all the more puzzling that Swift went for differentiating
them by the operation symbols. I don't think that the C standard's
type-name approach (rather than the modifier approach of original C)
is the way to introduce this into the type system, though.

>and an ISA with separate instructions for each operation on each type.

Or alternatively, synthesizable. E.g., on AMD64 you can implement
trapping signed addition with an addition followed by a JO to a
trapping instruction.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Tuesday, October 19, 2021 at 9:48:06 AM UTC+3, Tim Rentsch wrote:
> Michael S <already...@yahoo.com> writes:
>
> > On Monday, October 18, 2021 at 5:24:02 PM UTC+3, Tim Rentsch wrote:
> >
> >> Michael S <already...@yahoo.com> writes:
> >>
> >>>> [..sarcastic comments regarding signed overflow..]
> >>>
> >>> Don't be silly.
> >>> The best solution does not involve magic.
> >>> Something like that will do:
> >>>
> >>> Signed overflow is implementation-defined, but in constrained way.
> >>> Possible options are
> >>> 1. two-complement wrap-around
> >>> 2. trap
> >>> 3. saturation
> >>> 4. one-complement wrap-around, if there exist a member of
> >>> committee that care about it
> >>>
> >>> Implementation has to specify the chosen option clearly in
> >>> documentation. It is allowed to select an option with special
> >>> flag. It is not allowed to make option dependent on optimization
> >>> settings. If the chosen option is trap and overflow happens in
> >>> intermediate result of complex expression, but not in the final
> >>> result than it's it's legal for trap to be intermittent and
> >>> dependent on ether optimization level or phase of the moon, but
> >>> not both.
> >>
> >> My sense is this idea is not much better than how things are
> >> now. I would like to see the decision be under control of
> >> the source code, perhaps by means of a #pragma:
> >>
> >> #pragma STDC SIGNED_OVERFLOW WRAP
> >> #pragma STDC SIGNED_OVERFLOW TRAP
> >> #pragma STDC SIGNED_OVERFLOW SATURATE
> >> #pragma STDC SIGNED_OVERFLOW UNDEFINED
> >> (..others?..)
> >>
> >> If it's important, implementations might be allowed not to
> >> implement some or all of these choices; but if they don't then
> >> they must at least check the #pragma line for legality and fail
> >> the compilation if they cannot accommodate the choice indicated
> >> (or if the #pragma STDC doesn't scan for some reason).
> >
> > I'd very much prefer if UNDEFINED is not in the list of Standard
> > compliant options. Compiler can offer it, but then it would have
> > no right to identify as "standard C". IMHO, UNDEFINED is only
> > good to win specifically crafted benchmarks.
> I think it's necessary to have the option, to allow compatibility
> with earlier versions of the C standard, and if the option is
> possible there should be a way of explicitly selecting it.

As far as correction goes, option WRAP is compatible with UNDEFINED.
Theoretically, TRAP and SATURATE are also compatible, in practice I wouldn't bet on that.

> I very
> much doubt I would ever select it myself, but at the same time I
> think it's wrong to exclude it just because I personally don't like
> it. And if there is someone who wants to make that choice, I would
> much rather it be among the set of officially recognized features
> than that it be some non-standard option or attribute or something
> along those lines.
> > I agree with the rest of your suggestions.
> Agreement? I'm speechless. :)

Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
> [..considering code examples..]
>
> if ((x < 1) || (x > 3)) __builtin_unreachable();
> y = z / x;
>
> [..or alternative..]
>
> if (x == 1) {
> y = 1;
> } else if (x == 2) {
> y = z / 2;
> } else {
> y = z / 3;
> }
>
> [..(end code examples)..]
>
>> I'd very much prefer
>> y = x > 1 && x < 4 ? z/x : z;
>
> +1

The range test above is pretty much a standard idiom, but I still think
it is wrong since it theoretically makes it impossible to evaluate both
conditions at the same time:

The '&&' is defined so that the left side must be true before the right
side can be evaluated, but I guess in this common case the compiler
could still hoist the 'x < 4' test up before the '&&' since it has no
possible side effects?

Terje

>
>> Depending on distribution of x, it can be either faster or slower
>> or the same as [the first example], but is fully-defined, does not
>> depend on gcc extensions and, IMHO, is easier to grasp.
>
> +1
>
> (Linguistic nit: no hyphen between "fully" and "defined". In
> most cases there is no hyphen between an adverb and a following
> adjective.)
>

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 19/10/2021 11:54, Terje Mathisen wrote:
> Tim Rentsch wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>>
>> [..considering code examples..]
>>
>>      if ((x < 1) || (x > 3)) __builtin_unreachable();
>>      y = z / x;
>>
>> [..or alternative..]
>>           if (x == 1) {
>>      y = 1;
>>      } else if (x == 2) {
>>      y = z / 2;
>>      } else {
>>      y = z / 3;
>>      }
>>
>> [..(end code examples)..]
>>
>>> I'd very much prefer
>>> y = x > 1 && x < 4 ? z/x : z;
>>
>> +1
>
> The range test above is pretty much a standard idiom, but I still think
> it is wrong since it theoretically makes it impossible to evaluate both
> conditions at the same time:
>
> The '&&' is defined so that the left side must be true before the right
> side can be evaluated, but I guess in this common case the compiler
> could still hoist the 'x < 4' test up before the '&&' since it has no
> possible side effects?
>

Yes, that would be fine (assuming a smart enough compiler and an ISA or
instruction scheduling that meant such code hoisting made sense). The
compiler is also free to hoist "z / x" above the conditional, if it
knows there are no side-effects (because it knows that x is non-zero, or
because it knows that on the particular architecture, z / 0 does not trap).

On Tuesday, October 19, 2021 at 11:22:12 AM UTC+3, David Brown wrote:
> On 19/10/2021 09:23, cla...@hotmail.com wrote:
> > David Brown <david...@hesbynett.no> writes:
> >
> >> On 18/10/2021 18:53, cla...@hotmail.com wrote:
> >>> cla...@hotmail.com writes:
> >
> > [..]
> >
> >>
> >> That's trolls, from the Discworld :-)
> >
> > Thanks! I've first encountered this adage (translated) an aen ago and it
> > stuck in my brain. However, it appears, you are also wrong [1] To make
> > this post NG topical - [1] points that Setun [2] was created by trolls,
> > not tame .no variety, but proper, fearless, soviet beasts.
> >
> Many things, good and bad, can be said of the old Soviets - but they
> were never afraid to try something different!

Back in 1958 nobody was afraid to try something different. Field of digital computing was so young!
By ~1975 Soviet computer development became pretty conservative; many people there,
esp. those at higher levels of industrial bureaucracy, didn't realize that the field was *still* young.

> >>
> >> /Real/ programmers count 0, 1, 0, 1, 0, 1, ...
> >
> > ;)
> >
> > [1] https://www.tes.com/teaching-resource/discworld-maths-starter-counting-in-troll-11027536
> > [2] https://en.wikipedia.org/wiki/Setun
> >

On 19/10/2021 11:52, Michael S wrote:
> On Tuesday, October 19, 2021 at 9:48:06 AM UTC+3, Tim Rentsch wrote:
>> Michael S <already...@yahoo.com> writes:
>>
>>> On Monday, October 18, 2021 at 5:24:02 PM UTC+3, Tim Rentsch wrote:
>>>
>>>> Michael S <already...@yahoo.com> writes:
>>>>
>>>>>> [..sarcastic comments regarding signed overflow..]
>>>>>
>>>>> Don't be silly.
>>>>> The best solution does not involve magic.
>>>>> Something like that will do:
>>>>>
>>>>> Signed overflow is implementation-defined, but in constrained way.
>>>>> Possible options are
>>>>> 1. two-complement wrap-around
>>>>> 2. trap
>>>>> 3. saturation
>>>>> 4. one-complement wrap-around, if there exist a member of
>>>>> committee that care about it
>>>>>
>>>>> Implementation has to specify the chosen option clearly in
>>>>> documentation. It is allowed to select an option with special
>>>>> flag. It is not allowed to make option dependent on optimization
>>>>> settings. If the chosen option is trap and overflow happens in
>>>>> intermediate result of complex expression, but not in the final
>>>>> result than it's it's legal for trap to be intermittent and
>>>>> dependent on ether optimization level or phase of the moon, but
>>>>> not both.
>>>>
>>>> My sense is this idea is not much better than how things are
>>>> now. I would like to see the decision be under control of
>>>> the source code, perhaps by means of a #pragma:
>>>>
>>>> #pragma STDC SIGNED_OVERFLOW WRAP
>>>> #pragma STDC SIGNED_OVERFLOW TRAP
>>>> #pragma STDC SIGNED_OVERFLOW SATURATE
>>>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
>>>> (..others?..)
>>>>
>>>> If it's important, implementations might be allowed not to
>>>> implement some or all of these choices; but if they don't then
>>>> they must at least check the #pragma line for legality and fail
>>>> the compilation if they cannot accommodate the choice indicated
>>>> (or if the #pragma STDC doesn't scan for some reason).
>>>
>>> I'd very much prefer if UNDEFINED is not in the list of Standard
>>> compliant options. Compiler can offer it, but then it would have
>>> no right to identify as "standard C". IMHO, UNDEFINED is only
>>> good to win specifically crafted benchmarks.
>> I think it's necessary to have the option, to allow compatibility
>> with earlier versions of the C standard, and if the option is
>> possible there should be a way of explicitly selecting it.
>
> As far as correction goes, option WRAP is compatible with UNDEFINED.
> Theoretically, TRAP and SATURATE are also compatible, in practice I wouldn't bet on that.
>

You can bet as much as you like - when an operation is undefined, then
/any/ definition (including none) is compatible.

#pragma STDC SIGNED_OVERFLOW ANSWER_IS_ALWAYS_42

is perfectly compatible with the C standards. (And it is not /entirely/
daft - "magic" values like that can be useful in tracing problems. It's
more common to pick something like 0xDEADBEEF rather than 42, however.)

As far as C is concerned, there is absolutely /nothing/ special about
wrapping semantics for signed overflow behaviour.

On Tuesday, October 19, 2021 at 1:03:17 PM UTC+3, David Brown wrote:
> On 19/10/2021 11:52, Michael S wrote:
> > On Tuesday, October 19, 2021 at 9:48:06 AM UTC+3, Tim Rentsch wrote:
> >> Michael S <already...@yahoo.com> writes:
> >>
> >>> On Monday, October 18, 2021 at 5:24:02 PM UTC+3, Tim Rentsch wrote:
> >>>
> >>>> Michael S <already...@yahoo.com> writes:
> >>>>
> >>>>>> [..sarcastic comments regarding signed overflow..]
> >>>>>
> >>>>> Don't be silly.
> >>>>> The best solution does not involve magic.
> >>>>> Something like that will do:
> >>>>>
> >>>>> Signed overflow is implementation-defined, but in constrained way.
> >>>>> Possible options are
> >>>>> 1. two-complement wrap-around
> >>>>> 2. trap
> >>>>> 3. saturation
> >>>>> 4. one-complement wrap-around, if there exist a member of
> >>>>> committee that care about it
> >>>>>
> >>>>> Implementation has to specify the chosen option clearly in
> >>>>> documentation. It is allowed to select an option with special
> >>>>> flag. It is not allowed to make option dependent on optimization
> >>>>> settings. If the chosen option is trap and overflow happens in
> >>>>> intermediate result of complex expression, but not in the final
> >>>>> result than it's it's legal for trap to be intermittent and
> >>>>> dependent on ether optimization level or phase of the moon, but
> >>>>> not both.
> >>>>
> >>>> My sense is this idea is not much better than how things are
> >>>> now. I would like to see the decision be under control of
> >>>> the source code, perhaps by means of a #pragma:
> >>>>
> >>>> #pragma STDC SIGNED_OVERFLOW WRAP
> >>>> #pragma STDC SIGNED_OVERFLOW TRAP
> >>>> #pragma STDC SIGNED_OVERFLOW SATURATE
> >>>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
> >>>> (..others?..)
> >>>>
> >>>> If it's important, implementations might be allowed not to
> >>>> implement some or all of these choices; but if they don't then
> >>>> they must at least check the #pragma line for legality and fail
> >>>> the compilation if they cannot accommodate the choice indicated
> >>>> (or if the #pragma STDC doesn't scan for some reason).
> >>>
> >>> I'd very much prefer if UNDEFINED is not in the list of Standard
> >>> compliant options. Compiler can offer it, but then it would have
> >>> no right to identify as "standard C". IMHO, UNDEFINED is only
> >>> good to win specifically crafted benchmarks.
> >> I think it's necessary to have the option, to allow compatibility
> >> with earlier versions of the C standard, and if the option is
> >> possible there should be a way of explicitly selecting it.
> >
> > As far as correction goes, option WRAP is compatible with UNDEFINED.
> > Theoretically, TRAP and SATURATE are also compatible, in practice I wouldn't bet on that.
> >
> You can bet as much as you like - when an operation is undefined, then
> /any/ definition (including none) is compatible.

My comment was about incompatibility in the meaning "breaks existing code that worked fine for years or decades".
I think, that it was the meaning implied by Tim Rentsch in the post I was answering too.

>
> #pragma STDC SIGNED_OVERFLOW ANSWER_IS_ALWAYS_42
>
> is perfectly compatible with the C standards. (And it is not /entirely/
> daft - "magic" values like that can be useful in tracing problems. It's
> more common to pick something like 0xDEADBEEF rather than 42, however.)

I prefer DEADBADE

>
> As far as C is concerned, there is absolutely /nothing/ special about
> wrapping semantics for signed overflow behaviour.

As far as real world is concerned, wrapping is special in that it's 99.9% of what compilers emit in practice even when called without -fwrapv or similar option.

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>> [..considering code examples..]
>>
>> if ((x < 1) || (x > 3)) __builtin_unreachable();
>> y = z / x;
>>
>> [..or alternative..]
>> if (x == 1) {
>> y = 1;
>> } else if (x == 2) {
>> y = z / 2;
>> } else {
>> y = z / 3;
>> }
>>
>> [..(end code examples)..]
>>
>>> I'd very much prefer
>>> y = x > 1 && x < 4 ? z/x : z;
>>
>> +1
>
> The range test above is pretty much a standard idiom, but I still
> think it is wrong since it theoretically makes it impossible to
> evaluate both conditions at the same time:
>
> The '&&' is defined so that the left side must be true before the
> right side can be evaluated, but I guess in this common case the
> compiler could still hoist the 'x < 4' test up before the '&&' since
> it has no possible side effects?

Right. How '&&' works is defined in terms of what happens in the
abstract machine, where the right operand is evaluated only if
the left operand is non-zero. In an actual machine it is
perfectly okay to evaluate both sides at once, or even to turn
the code into something like

y = x - 2U < 2 ? z/x : z;

because the result is indistinguishable from the original code
running in the abstract machine (and like you said, because
the right hand operand has no side effects).

Michael S <already5chosen@yahoo.com> writes:

> On Tuesday, October 19, 2021 at 9:48:06 AM UTC+3, Tim Rentsch wrote:
>
>> Michael S <already...@yahoo.com> writes:
>>
>>> On Monday, October 18, 2021 at 5:24:02 PM UTC+3, Tim Rentsch wrote:
>>>
>>>> Michael S <already...@yahoo.com> writes:
>>>>
>>>>>> [..sarcastic comments regarding signed overflow..]
>>>>>
>>>>> Don't be silly.
>>>>> The best solution does not involve magic.
>>>>> Something like that will do:
>>>>>
>>>>> Signed overflow is implementation-defined, but in constrained way.
>>>>> Possible options are
>>>>> 1. two-complement wrap-around
>>>>> 2. trap
>>>>> 3. saturation
>>>>> 4. one-complement wrap-around, if there exist a member of
>>>>> committee that care about it
>>>>>
>>>>> Implementation has to specify the chosen option clearly in
>>>>> documentation. It is allowed to select an option with special
>>>>> flag. It is not allowed to make option dependent on optimization
>>>>> settings. If the chosen option is trap and overflow happens in
>>>>> intermediate result of complex expression, but not in the final
>>>>> result than it's it's legal for trap to be intermittent and
>>>>> dependent on ether optimization level or phase of the moon, but
>>>>> not both.
>>>>
>>>> My sense is this idea is not much better than how things are
>>>> now. I would like to see the decision be under control of
>>>> the source code, perhaps by means of a #pragma:
>>>>
>>>> #pragma STDC SIGNED_OVERFLOW WRAP
>>>> #pragma STDC SIGNED_OVERFLOW TRAP
>>>> #pragma STDC SIGNED_OVERFLOW SATURATE
>>>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
>>>> (..others?..)
>>>>
>>>> If it's important, implementations might be allowed not to
>>>> implement some or all of these choices; but if they don't then
>>>> they must at least check the #pragma line for legality and fail
>>>> the compilation if they cannot accommodate the choice indicated
>>>> (or if the #pragma STDC doesn't scan for some reason).
>>>
>>> I'd very much prefer if UNDEFINED is not in the list of Standard
>>> compliant options. Compiler can offer it, but then it would have
>>> no right to identify as "standard C". IMHO, UNDEFINED is only
>>> good to win specifically crafted benchmarks.
>>
>> I think it's necessary to have the option, to allow compatibility
>> with earlier versions of the C standard, and if the option is
>> possible there should be a way of explicitly selecting it.
>
> As far as correction goes, option WRAP is compatible with UNDEFINED.
> Theoretically, TRAP and SATURATE are also compatible, in practice I
> wouldn't bet on that.

I think what you mean by compatible here is not the same as what
I was trying to say. In my case "compatible" is not about
programs but about the semantic definitions of these operations
in the C standard. None of the four options I listed above are
compatible with any of the others, because the rules for what
operations do (or may do) are different in each case. As far as
programs go, all of these options are "compatible" if signed
arithmetic never overflows. I think it's important to be able
to compile a program under the old rules for how signed integer
works (which is the UNDEFINED option), even if the results of
such compilations may be different than earlier ones (which is
inherent in the nature of undefined behavior). For example,
suppose we are interested in a SPECint benchmark. Earlier
results of running SPECint implicitly use the UNDEFINED rules
(or at least I guess they do -- I don't know much about them).
If SPECint were run under the WRAP or SATURATE rules, we may
very well get different performance numbers, and if run under
the TRAP rules then there's a good chance we would get no
results at all (that is, that at least one operation overflows
and causes the benchmark to terminate before it is done).

I hope you can see what I mean here. I'm not really happy with
my writing in the last paragraph but I don't right now know how
to improve it.

On 19/10/2021 12:19, Michael S wrote:
> On Tuesday, October 19, 2021 at 1:03:17 PM UTC+3, David Brown wrote:
>> On 19/10/2021 11:52, Michael S wrote:
>>> On Tuesday, October 19, 2021 at 9:48:06 AM UTC+3, Tim Rentsch wrote:
>>>> Michael S <already...@yahoo.com> writes:
>>>>
>>>>> On Monday, October 18, 2021 at 5:24:02 PM UTC+3, Tim Rentsch wrote:
>>>>>
>>>>>> Michael S <already...@yahoo.com> writes:
>>>>>>
>>>>>>>> [..sarcastic comments regarding signed overflow..]
>>>>>>>
>>>>>>> Don't be silly.
>>>>>>> The best solution does not involve magic.
>>>>>>> Something like that will do:
>>>>>>>
>>>>>>> Signed overflow is implementation-defined, but in constrained way.
>>>>>>> Possible options are
>>>>>>> 1. two-complement wrap-around
>>>>>>> 2. trap
>>>>>>> 3. saturation
>>>>>>> 4. one-complement wrap-around, if there exist a member of
>>>>>>> committee that care about it
>>>>>>>
>>>>>>> Implementation has to specify the chosen option clearly in
>>>>>>> documentation. It is allowed to select an option with special
>>>>>>> flag. It is not allowed to make option dependent on optimization
>>>>>>> settings. If the chosen option is trap and overflow happens in
>>>>>>> intermediate result of complex expression, but not in the final
>>>>>>> result than it's it's legal for trap to be intermittent and
>>>>>>> dependent on ether optimization level or phase of the moon, but
>>>>>>> not both.
>>>>>>
>>>>>> My sense is this idea is not much better than how things are
>>>>>> now. I would like to see the decision be under control of
>>>>>> the source code, perhaps by means of a #pragma:
>>>>>>
>>>>>> #pragma STDC SIGNED_OVERFLOW WRAP
>>>>>> #pragma STDC SIGNED_OVERFLOW TRAP
>>>>>> #pragma STDC SIGNED_OVERFLOW SATURATE
>>>>>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
>>>>>> (..others?..)
>>>>>>
>>>>>> If it's important, implementations might be allowed not to
>>>>>> implement some or all of these choices; but if they don't then
>>>>>> they must at least check the #pragma line for legality and fail
>>>>>> the compilation if they cannot accommodate the choice indicated
>>>>>> (or if the #pragma STDC doesn't scan for some reason).
>>>>>
>>>>> I'd very much prefer if UNDEFINED is not in the list of Standard
>>>>> compliant options. Compiler can offer it, but then it would have
>>>>> no right to identify as "standard C". IMHO, UNDEFINED is only
>>>>> good to win specifically crafted benchmarks.
>>>> I think it's necessary to have the option, to allow compatibility
>>>> with earlier versions of the C standard, and if the option is
>>>> possible there should be a way of explicitly selecting it.
>>>
>>> As far as correction goes, option WRAP is compatible with UNDEFINED.
>>> Theoretically, TRAP and SATURATE are also compatible, in practice I wouldn't bet on that.
>>>
>> You can bet as much as you like - when an operation is undefined, then
>> /any/ definition (including none) is compatible.
>
>
> My comment was about incompatibility in the meaning "breaks existing code that worked fine for years or decades".

I think most code does not depend on signed integer overflow behaviour.
/Some/ does, not I like to believe it is a relatively small amount, and
I think people who are likely to make such mistakes are likely to have
made many other mistakes. However, it is clear that /some/ code relies
on wrapping overflow.

> I think, that it was the meaning implied by Tim Rentsch in the post I was answering too.

I never try to infer extra meanings from Tim's posts.

>
>>
>> #pragma STDC SIGNED_OVERFLOW ANSWER_IS_ALWAYS_42
>>
>> is perfectly compatible with the C standards. (And it is not /entirely/
>> daft - "magic" values like that can be useful in tracing problems. It's
>> more common to pick something like 0xDEADBEEF rather than 42, however.)
>
> I prefer DEADBADE
>
>>
>> As far as C is concerned, there is absolutely /nothing/ special about
>> wrapping semantics for signed overflow behaviour.
>
> As far as real world is concerned, wrapping is special in that it's 99.9% of what compilers emit in practice even when called without -fwrapv or similar option.
>

Wrapping is often what you get with a "don't care" result - the simplest
way to perform arithmetic without consideration for overflow is
typically wrapping by accident, even for optimised code.

But when you have more combinations in expressions, it's a different
matter. In particular, relational ordering and division often don't
work the same when optimised with a disregard for overflow, as they
would with strict modulo wrapping. As compilers get better at joining
code together (inlining, inter-procedural optimisations, header-only C++
libraries and C++ modules, link-time optimisation, etc.) then you are
going to see more and more problems from code that "used to work".

Standardising options for overflow behaviour would, I think, be a good
thing. But it would be even better if programmers stopped pretending C
worked the way they would like to work, and started using it the way it
/does/ work. (That applies to more than just signed integer overflow.)

On Tuesday, October 19, 2021 at 2:21:11 AM UTC-5, David Brown wrote:
> On 18/10/2021 19:00, Victor Yodaiken wrote:
> > On Monday, October 18, 2021 at 11:14:33 AM UTC-5, David Brown wrote:
> >
> >> Relying on wrapping is ugly and error-prone. It encourages people to
> >> write code that makes no logical sense, such as adding two positive
> >> numbers and checking for them being negative.
> >
> > 1. Signed arithmetic is a representation of arithmetic in the residue ring of the integers mod 2^{k}
> Not in standard C, and many other languages.
> > 2. Signed arithmetic is a patchy approximation of arithmetic over the integers with known failure cases and
> > unpredictable results and where the implication of x+1 > x and x <= INT_MAX is that INT_MAX < INT_MAX
> >
> Not in standard C, or any other language I know of. x + 1 is not
> defined for x = INT_MAX, so it can have no implications.
> > Of course 1 makes no logical sense. Bravo!
> >
> Try this exercise - find a random person, and ask them if "x + 1" is
> always bigger than "x". Assuming you can make it past the "is this a
> trick question?" stage, you'll get a "yes". C integer arithmetic
> matches this.

For the record, I agree that using int where you really mean unsigned int is
sloppy although there are 10s of millions of lines ( at least) of C code that
has that idiom in it and if I was managing such code I would be beyond
furious if the compiler changed the game on me.

But your argument here is super weak.
..
Find a random person and ask them if 1/2 is equal to 0.

Ask if they know what INT_MAX is. Then ask them if x+1 > x is a rule.
Your actual rule is "if x< INT_MAX then x+1 > x".

With modular arithmetic, when the user provides two positive numbers and
I need to see if they can be multiplied safely I write
if(x*y < x)wontwork();
This is a very cheap computation on 99% of 32/64 bit computers
What's your solution in UB Arithmetic? Maybe there is a good
solution I don't know.

>
> Find another random person and ask them if they know what a residue ring
> is. Ask them if they think ℤ/2ⁿ is a natural way to count and do
> arithmetic.

Do you think mod 2^k arithmetic is too weird for programmers?
That's a real question, not a rhetorical one.
When I taught intro computer science, it didn't seem too hard
for 18 year olds.

> Ask them if they know why this is similar, but not
> identical, to two's complement integers with wrapping. (Hint - think
> about division.)

Maybe you know something I don't, which is always possible, but as far as I know,
it is the same as 2s complement with wrapping - and wrapping is implicit
for 2s complement. Division works as it should.
( in mathematics they say Z/2^kZ is a ring, not a field, in computer architecture
its just repeated subtraction )
> Ask them if they think a logical and natural numbering system should
> follow basic rules of arithmetic as much as possible in the limited space..

"Basic rules of arithmetic" is context dependent. x/(2*x) == 0 is a basic rule
for integers (and modulus arithmetic) but not for real numbers or floating
point. In floating point we can have weird stuff like x+1 == x sometimes.

> Ask them if it makes more sense to say "these numbers are too big, you
> can't add them", or if it is more sensible to say "these numbers are big
> - you'll get a negative result if you add them".

Maybe people who don't know either modulus arithmetic or how 99%
of 32/64 bit processors do arithmetic should not program in C. There
are good, even excellent, programming languages that abstract all that low
level stuff away.

Here is a place where the architecture of processors, the mathematics,
and even the unoptimized semantics of C all AGREE, but you want to
opt for "if you multiply two numbers and the result would be too big, then
the value of the result depends on magic". I don't get it.
Trap on overflow is a perfectly sensible solution - which sometimes
we don't want because it is computationally expensive and for
other reasons, but "depends on the optimizer" is sloppy as hell.

BTW: your other example of simplifying x+ 3 -2 is a good
example of why the associative property of 2s complement
arithmetic is so convenient

(x +y )+z = x+(y+z)
The compiler does not have to check, because modulus arithmetic is
native for most 32/64 bit processors.

> Undefined signed integer overflow is the /only/ sensible and logical
> choice. There is /no/ correct answer for overflowing arithmetic in any
> simple, useful sense - so the sane way to handle it is to say "don't do
> it". It's hardly the most difficult rule to follow.

I really dislike "this is magic" as an explanation - usually
it means "this is poorly designed".

EricP <ThatWouldBeTelling@thevillage.com> writes:

> Tim Rentsch wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>>> [..sarcastic comments regarding signed overflow..]
>>>
>>> Don't be silly.
>>> The best solution does not involve magic.
>>> Something like that will do:
>>>
>>> Signed overflow is implementation-defined, but in constrained way.
>>> Possible options are
>>> 1. two-complement wrap-around
>>> 2. trap
>>> 3. saturation
>>> 4. one-complement wrap-around, if there exist a member of
>>> committee that care about it
>>>
>>> Implementation has to specify the chosen option clearly in
>>> documentation. It is allowed to select an option with special
>>> flag. It is not allowed to make option dependent on optimization
>>> settings. If the chosen option is trap and overflow happens in
>>> intermediate result of complex expression, but not in the final
>>> result than it's it's legal for trap to be intermittent and
>>> dependent on ether optimization level or phase of the moon, but
>>> not both.
>>
>> My sense is this idea is not much better than how things are
>> now. I would like to see the decision be under control of
>> the source code, perhaps by means of a #pragma:
>>
>> #pragma STDC SIGNED_OVERFLOW WRAP
>> #pragma STDC SIGNED_OVERFLOW TRAP
>> #pragma STDC SIGNED_OVERFLOW SATURATE
>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
>> (..others?..)
>>
>> If it's important, implementations might be allowed not to
>> implement some or all of these choices; but if they don't then
>> they must at least check the #pragma line for legality and fail
>> the compilation if they cannot accommodate the choice indicated
>> (or if the #pragma STDC doesn't scan for some reason).
>
> Gcc C already has the compiler switch -ftrapv to enable signed integer
> overflow checks (operators are implemented as subroutine calls).
>
> The problem with such pragmas in C is the same as compiler switches:
> they cause many false positives (overflow traps) because they are too
> much of a blunt object. As a consequence people just turn them off.
>
> A number of studies of real world code have shown that it is a
> mixture of signed and unsigned, checked and unchecked assumptions
> *often within a single expression*.
>
> E.g. these folks tap into clang's front end to inject checks into
> code.
>
> Understanding Integer Overflow in C/C++, 2015
> https://wdtz.org/files/tosem15.pdf
>
> Consider a hypothetical line from a codec:
>
> signal = signal + impulse[i + j];
>
> In this expression, i+j are signed integers and should be added using
> checked arithmetic, the array index then checked against array bounds,
> the array element address addition calculated using unsigned modulo
> arithmetic, and signal value added using saturating arithmetic.
>
> Note also that some unsigned wrap arounds are bugs, some not.
> It depends on the programmers intent.
>
> This is why the VAX with it PSW global flag enabling overflow detect
> had problems - real code would have to keep switching it on and off,
> which would cause a large overhead so they just left it on for Fortran
> or Ada and lived with occasional false overflow traps. Which is why
> Alpha has separate instructions for Add and AddTrapOverflow.
>
> The only mechanism I can think of that can handle that kind of
> flexibility smoothly would be based on multiple language data types,
> and an ISA with separate instructions for each operation on each type.

Just a few comments. I didn't see how to intersperse these
with what you said, so I'm putting everything here.

One, my comments were only about providing an alternative to
undefined behavior on signed integer arithmetic. They had
nothing to do with checking index bounds, incorrect use of
defined behavior on unsigned operands, bugs arising from
implementation-dependent behavior or integer promotions, etc.
All of these are outside the realm of what I was addressing.

Two, having something like the #pragma ability outlined above has
some advantages over things like -ftrapv. First, being defined
in the C standard, it's the same everywhere, with no need to hunt
around for compiler-dependent options. Second, because it is
expressed in C, it stays with the code, rather than having to
live outside the code in something like a makefile.

Three, unlike compiler options such as -ftrapv, the #pragma
mechanism is not all or nothing for a whole translation unit.
A single .c file can have multiple overflow #pragma's, changing
settings through the TU. Furthermore there is no reason they
can't be syntax sensitive, limiting the domains of application
to a braced block or a parenthesized expression. Combined with
calls to _Pragma operators, the details can be abstracted
inside macro definitions. Taking your example

signal = signal + impulse[i + j];

this might be written as

signal = SATURATE( signal + impulse[ TRAP(i + j)] );

where SATURATE and TRAP have been previously defined

#define TRAP(e) ( \
_Pragma ("STDC SIGNED_OVERFLOW TRAP") e \
)

#define SATURATE(e) ( \
_Pragma ("STDC SIGNED_OVERFLOW SATURATE") e \
)

Again, I'm not suggesting that using this approach for what
happens on signed overflows solves all the world's problems.
But I do think it is both more convenient and more flexible
than compiler options like -ftrapv, and needs only modest
changes to the C standard to enable it.

Ivan Godard wrote:
> On 10/18/2021 2:23 PM, EricP wrote:
>>
>> The only mechanism I can think of that can handle that kind of
>> flexibility smoothly would be based on multiple language data types,
>> and an ISA with separate instructions for each operation on each type.
>
> As for example:
> enumWithTraits(intNumEnums, overflowCode,
> excepting,
> modulo,
> saturating,
> widening
> );
> available in every kind of operation that can overflow?
>

I don't know what you mean.

I mean that only the programmer knows their intent and since
that intent changes and they need a way to express it.
A one-size-fits-all approach isn't flexible enough.

The compiler already handles overloading operators for different
integral and float data types and sizes. This expands on that mechanism.

David Brown wrote:
> On 18/10/2021 23:23, EricP wrote:
>> Gcc C already has the compiler switch -ftrapv to enable signed integer
>> overflow checks (operators are implemented as subroutine calls).
>>
>> The problem with such pragmas in C is the same as compiler switches:
>> they cause many false positives (overflow traps) because they are too
>> much of a blunt object. As a consequence people just turn them off.
>
> There are more problems than that. Consider "y = x + 3 - 2;". (Imagine
> it is the result of a set of macros, or inline functions and constant
> propagation, rather than a hand-written expression.) Can a compiler
> change that to "y = x + 1;" with overflow checking there? Does it need
> to do two operations, checking twice?
>
> Requiring strict overflow trapping would cripple the performance of a
> lot of code. That's fine for debugging (like gcc
> "-fsanitize=signed-integer-overflow"), but not for normal code.

I understand the issue, it comes down to the rules for optimization
in the presence of overflow detection, which also must be decided for
saturating arithmetic. Ideally the rules are the same.

The rule many languages use which allows the same optimizations as
are currently done is "if an operation is performed, then it is checked
for overflow". This does not require an operation be performed
and therefore does not interfere with normal optimizations.
This rule also works for saturate.

This is no different than memory ECC. ECC does not prevent an optimizer
from eliminating loads or stores. It just says that "if a load is performed,
then it is checked for single and double bit errors".

> I believe that these days that "-ftrapv" is considered broken beyond
> repair in gcc - it might work in some cases, but you'll get false
> positives and false negatives and little in the way of guarantees of how
> it interacts with optimisations and strength reductions. The sanitizer
> is the modern way to handle this.

I've never used it but I've seen references to it in the past that the
subroutines implemented broken algorithms and no one was fixing them.
I've also read that they eventually did get fixed.

But in any case, because they are implemented as subroutine calls and
not inline code, they are reported to cause a run time slowdown 50%.
Others have done inlined test *but implement the checks inefficiently*
and get slowdown of 195%.

This causes everyone to turn them off, which removes any impetus
to improve the performance, and the cycle continues.

Other research papers show that if overflow checks are inlined
and implemented efficiently there is 0-5% slowdown.

I noticed the other day that gnat Ada defaults to turning off
signed integer overflow detect when optimize is requested.
I suspect it uses the same -ftrapv mechanism.
It does keep bounds checks though.

>> A number of studies of real world code have shown that it is a
>> mixture of signed and unsigned, checked and unchecked assumptions
>> *often within a single expression*.
>>
>> E.g. these folks tap into clang's front end to inject checks into code.
>>
>> Understanding Integer Overflow in C/C++, 2015
>> https://wdtz.org/files/tosem15.pdf
>>
>> Consider a hypothetical line from a codec:
>>
>> signal = signal + impulse[i + j];
>>
>> In this expression, i+j are signed integers and should be added using
>> checked arithmetic, the array index then checked against array bounds,
>> the array element address addition calculated using unsigned modulo
>> arithmetic, and signal value added using saturating arithmetic.
>>
>> Note also that some unsigned wrap arounds are bugs, some not.
>> It depends on the programmers intent.
>>
>> This is why the VAX with it PSW global flag enabling overflow detect
>> had problems - real code would have to keep switching it on and off,
>> which would cause a large overhead so they just left it on for
>> Fortran or Ada and lived with occasional false overflow traps.
>> Which is why Alpha has separate instructions for Add and AddTrapOverflow.
>>
>> The only mechanism I can think of that can handle that kind of
>> flexibility smoothly would be based on multiple language data types,
>> and an ISA with separate instructions for each operation on each type.
>>
>
> For most ISA's, -ftrapv would generate some kind of "add with flags"
> instruction followed by a "trap if overflow flag set". Some might do
> the arithmetic with wider operands and then check the result. In
> general, it's a costly business - and operations involving flags are
> typically a pain for scheduling and pipelining on superscaler
> processors. It's fine for bug-chasing, but not for efficient end products.

Gcc currently calls subroutines (I checked on Godbolt)
which reportedly causes the 50% slowdown.

On x86 it could have used the INTO instruction (interrupt on overflow).
On x64 it could use inline JO Jump Overflow instructions with a forward
branch on overflow.
In either case there would likely be no detectable slowdown.

> And then you have the trouble with mixing signed and unsigned operands,
> as you mention. This is already quite counter-intuitive in C for many
> people, as the operation is done as unsigned arithmetic. It is worse if
> the programmer expected overflow trapping. (I like gcc's
> "-Wsign-conversion" warning, but false positives are not uncommon.)
>
> I think the only good answer here if you want tight control of your
> overflows, is to switch from C. Ada will give you all sorts of
> possibilities. Java will give you two's complement wrapping, fully
> defined (thus no errors even when the results are wrong), for those that
> want that. C++ lets you build classes to do exactly what you want,
> whatever that may be.

I know. If one wants features like these, plus array bounds checks,
better to have a language designed for this from the start.

Perhaps I just enjoy the gentle mist one gets from pissing into the wind.

> But standardised pragmas would be a good step forward in C, IMHO.

Or standardized extension types. :-)

On 10/19/2021 9:20 AM, EricP wrote:
> Ivan Godard wrote:
>> On 10/18/2021 2:23 PM, EricP wrote:
>>>
>>> The only mechanism I can think of that can handle that kind of
>>> flexibility smoothly would be based on multiple language data types,
>>> and an ISA with separate instructions for each operation on each type.
>>
>> As for example:
>>    enumWithTraits(intNumEnums, overflowCode,
>>                     excepting,
>>                     modulo,
>>                     saturating,
>>                     widening
>>                     );
>> available in every kind of operation that can overflow?
>>
>
> I don't know what you mean.
>
> I mean that only the programmer knows their intent and since
> that intent changes and they need a way to express it.
> A one-size-fits-all approach isn't flexible enough.
>
> The compiler already handles overloading operators for different
> integral and float data types and sizes. This expands on that mechanism.

I think the disconnect is the following. Ivan showed what capabilities
are/will be in the Mill hardware ISA. You talked about what the
programmer intends. The disconnect is that the current C language
doesn't provide a mechanism to "connect" the two, at least in many
cases. Several proposals have been made here (pragmas, compile options,
etc.), but none are apparently part of the standard.

I should note that at least a good part of these are specifiable in, for
example Ada. The very extensive type system in Ada is, IMO one of its
biggest strengths.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> This is why the VAX with it PSW global flag enabling overflow detect
>> had problems - real code would have to keep switching it on and off,
>> which would cause a large overhead so they just left it on for
>> Fortran or Ada and lived with occasional false overflow traps.
>> Which is why Alpha has separate instructions for Add and AddTrapOverflow.
>
> Already MIPS has addu (add on Alpha) and add (addv on Alpha). They
> apparently thought that overflow trapping was required, but having no
> flags was a design principle in these architectures (maybe thanks to
> the VAX), so they put in trapping instructions. I wonder how much use
> they saw. IIRC (but my memory is unreliable on this) recent MIPS
> variants have eliminated the trapping variants, but added flags for
> carry and overflow.

Yeah, I saw that. I suspect that is a result of the same binary code stats
that justified removing x86 INTO instruction on x64. They also dropped
the x86 BOUNDS instruction (but it was designed wrong anyway so no loss).

The 1970's and 80's had lots of Cobol and Fortran, some Pascal, and
scanning their binaries likely finds lots of overflow and bounds checks.

When Microsoft developed WinNT they switched from Pascal as their
corporate language to C. If they had switched to Modula-2 which has
all 4 data types for check & unchecked, signed & unsigned,
the usage stats would be different.

But as it was the 90's and 00's would be C and C++.
No INTO or BOUNDS in sight so eliminate the instructions.

>> The only mechanism I can think of that can handle that kind of
>> flexibility smoothly would be based on multiple language data types,
>
> On the language level types seem to be the way to go for languages
> that use types to differentiate between integer and FP addition.

Yes, just more of the same operator overloading.

> This
> makes it all the more puzzling that Swift went for differentiating
> them by the operation symbols. I don't think that the C standard's
> type-name approach (rather than the modifier approach of original C)
> is the way to introduce this into the type system, though.

Yeah, I saw that. My first thought was "Ooookaaayyy.... so no Swift".
What are they going to do for saturating operations on
Arm processor that support it? A whole new set of operators?
And why is overloading operators ok for integers and floats
but not ok for checked vs unchecked?
And checked integers should be checked when down converted
so why don't they have a special &= assignment operator?
And what about ++ and -- for checked integers?
And << and >>?

>> and an ISA with separate instructions for each operation on each type.
>
> Or alternatively, synthesizable. E.g., on AMD64 you can implement
> trapping signed addition with an addition followed by a JO to a
> trapping instruction.
>
> - anton

Yes, but in order to have traceability into which operation failed,
which is necessary to diagnose the problem, it must generate a
separate destination for each JO.
It's ok, it works, but INTO would have been cleaner.

And what happens on Arm A64 with no overflow flag?
It has to use the multi instruction idioms with their binary expansion
and speed overhead, which causes everyone to turn them off for production.

If there is a body of code that assumes checking is normal then there
is an incentive for Arm to add instructions to make it optimal,
just as they do for some processors with saturate.

On 10/19/2021 11:08 AM, Stephen Fuld wrote:
> On 10/19/2021 9:20 AM, EricP wrote:
>> Ivan Godard wrote:
>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>
>>>> The only mechanism I can think of that can handle that kind of
>>>> flexibility smoothly would be based on multiple language data types,
>>>> and an ISA with separate instructions for each operation on each type.
>>>
>>> As for example:
>>>    enumWithTraits(intNumEnums, overflowCode,
>>>                     excepting,
>>>                     modulo,
>>>                     saturating,
>>>                     widening
>>>                     );
>>> available in every kind of operation that can overflow?
>>>
>>
>> I don't know what you mean.
>>
>> I mean that only the programmer knows their intent and since
>> that intent changes and they need a way to express it.
>> A one-size-fits-all approach isn't flexible enough.
>>
>> The compiler already handles overloading operators for different
>> integral and float data types and sizes. This expands on that mechanism.
>
> I think the disconnect is the following.  Ivan showed what capabilities
> are/will be in the Mill hardware ISA.  You talked about what the
> programmer intends.  The disconnect is that the current C language
> doesn't provide a mechanism to "connect" the two, at least in many
> cases.  Several proposals have been made here (pragmas, compile options,
> etc.), but none are apparently part of the standard.
>
> I should note that at least a good part of these are specifiable in, for
> example Ada.  The very extensive type system in Ada is, IMO one of its
> biggest strengths.

Well put. Besides Ada, also consider C++ in which you can define classes
saturatingShort, saturatingInt, etc and overload the operators to
produce an intrinsic which in turn invokes a native instruction (Mill)
or sequence (whatever). Writing the library is annoying, but using it is
convenient and natural.

David Brown <david.brown@hesbynett.no> schrieb:

> You can bet as much as you like - when an operation is undefined, then
> /any/ definition (including none) is compatible.
>
>#pragma STDC SIGNED_OVERFLOW ANSWER_IS_ALWAYS_42
>
> is perfectly compatible with the C standards.

IIRC, gcc once defined

#pragma once

to launch a game of Tetris instead of compiling the code in question.

David Brown <david.brown@hesbynett.no> schrieb:

> There are more problems than that. Consider "y = x + 3 - 2;". (Imagine
> it is the result of a set of macros, or inline functions and constant
> propagation, rather than a hand-written expression.) Can a compiler
> change that to "y = x + 1;" with overflow checking there? Does it need
> to do two operations, checking twice?

In Fortran, it could according to the language definition, as
long as parenthethes are kept. The language even allows to change
(x - x) into zero for floats, never mind NaNs.

Few compilers dare to implement that.

It would be illegal for y = (x + 3) - 2.

On 10/19/2021 11:58 AM, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>
>> There are more problems than that. Consider "y = x + 3 - 2;". (Imagine
>> it is the result of a set of macros, or inline functions and constant
>> propagation, rather than a hand-written expression.) Can a compiler
>> change that to "y = x + 1;" with overflow checking there? Does it need
>> to do two operations, checking twice?
>
> In Fortran, it could according to the language definition, as
> long as parenthethes are kept. The language even allows to change
> (x - x) into zero for floats, never mind NaNs.
>
> Few compilers dare to implement that.
>
> It would be illegal for y = (x + 3) - 2.
>

That rule has always bothered me for a language with operator
precedence. OP forces parens to resolve precedence: Fortran (b+c)*a is
not the same as b+c*a, although it is in APL where there is no
precedence. Don't you find that precedence parens masquerading as
optimization-control parens sometimes engender bad code?

On 10/16/2021 1:04 PM, Ivan Godard wrote:
> On 10/16/2021 12:20 PM, Stephen Fuld wrote:
>> On 10/16/2021 11:44 AM, Ivan Godard wrote:
>>> On 10/16/2021 9:07 AM, Anton Ertl wrote:
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>> [bounds checking]
>>>>> There are languages where the necessary info is provided, Ada
>>>>> and Fortran among them.  However, that there is a rather large
>>>>> overhead in code size and, more importantly, execution time.
>>>>
>>>> Please support your claim with empirical results.
>>>>
>>>>> Compilers need to become better at moving
>>>>> checking code out of loops.
>>>>
>>>> Again, support needed.  My impression is that the Cousots solved this
>>>> problem pretty well in the 1970, and for the common case their
>>>> solution is good enough.  And it's not clear that much can be done for
>>>> the other cases.
>>>>
>>>>> Signed overruns - the very topic we are discussing here.  Integer
>>>>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>>>>> overflow, a 16-bit overflow and an 8-bit overflow.
>>>>
>>>> Consider:
>>>>
>>>> signed char a=127;
>>>> signed char b=127;
>>>> signed char c;
>>>> c=a+b;
>>>>
>>>> The addition is defined in C.  Maybe the narrowing of the result in
>>>> the assignment is undefined, C standards lawyers will know.
>>>>
>>>> But of course, the major question is who wants this?  Who uses -ftrapv
>>>> on MIPS and Alpha which have such instructions (for 32 bits and 64
>>>> bits, relevant for their I32LP64 C).
>>>>
>>>>> Use after free - much more difficult.  It might be possible to
>>>>> have a hardware list of "poisoned" address ranges from which it is
>>>>> not permitted to load.  Very expensive (comparable to
>>>>> cache) and would probably cache only the most recently freed
>>>>> memory blocks.  Not sure if this is worth it.
>>>>
>>>> If you have NaT bits associated with the memory, you could fill the
>>>> free()d memory with NaTs.
>>>
>>> I would love to have NaT bits (NaR in our terminology) associated
>>> with memory. It's certainly doable, but not economically feasible
>>> IMO, unless you are Samsung.
>>
>> I was thinking about (ab)using a modification of your mechanism that
>> allows reading zeros when you load from uninitialized memory, but I
>> suspect the overhead might be way to high.
>
> We looked at having uninit read as NaR. If real Samsung had NaR bits
> then you could write a speculative NaR and later discard it harmlessly;
> without Samsung we have to fault a NaR store, which limits the degree of
> performance gain available from speculation. With NaR uninits but no
> Samsung we can nanny the programmer, but the common zero init (as
> nannied) becomes explicit, lowering performance. Absent Samsung, we
> decided that the reliability gain from nannying wasn't as good as the
> performance gain from zero; YMMV. Might well have gone the other way had
> Samsung been aboard.

Obviously I am missing something, but I thought your "read zeros"
mechanism used the PLB, not anything in the RAM itself. So I was
suggesting some enhancement of the range protection in the PLB, but as I
said, I fear it would entail too much overhead.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 10/19/2021 11:58 AM, Thomas Koenig wrote:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>
>>> There are more problems than that. Consider "y = x + 3 - 2;". (Imagine
>>> it is the result of a set of macros, or inline functions and constant
>>> propagation, rather than a hand-written expression.) Can a compiler
>>> change that to "y = x + 1;" with overflow checking there? Does it need
>>> to do two operations, checking twice?
>>
>> In Fortran, it could according to the language definition, as
>> long as parenthethes are kept. The language even allows to change
>> (x - x) into zero for floats, never mind NaNs.
>>
>> Few compilers dare to implement that.
>>
>> It would be illegal for y = (x + 3) - 2.
>>
>
> That rule has always bothered me for a language with operator
> precedence. OP forces parens to resolve precedence: Fortran (b+c)*a is
> not the same as b+c*a, although it is in APL where there is no
> precedence. Don't you find that precedence parens masquerading as
> optimization-control parens sometimes engender bad code?

I cannot think of an problematic example right now. Do you
have an example?

On 10/16/2021 1:02 PM, Tim Rentsch wrote:
> John Levine <johnl@taugh.com> writes:
>
>> According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>>
>>>> As my thesis advisor Alan Perlis said when I was a student in the
>>>> 1970s, I don't know what language people will be using in the year
>>>> 2000, but it will be called Fortran.
>>>
>>> I wouldn't be surprised if Alan Perlis said this, but I think it
>>> was said originally by Tony Hoare. (Disclaimer: my memory is
>>> known to be faulty at times, and I have made no attempt to find
>>> sources to support my unreliable memory.)
>>
>> I don't think Alan claimed it was original. But he did like to say it.
>
> I have fond memories of Alan Perlis from when he was teaching at
> Caltech during the time I was a student there.

When I was an undergrad at CMU (1968-1972), Perlis was chairman of the
computer science department. There was no undergrad comp sci major (I
was a Chemistry major), but they did offer some undergraduate courses.
The introductory course (S600), was taught by Perlis himself, and taught
Algol (Perlis was on the committee that defined it).

The course had a terrible reputation. Apparently he gave one exam
where, out of 100 points, the average grade was something like 9, 16 got
you an A, and zero was passing.

The EE department was so disgusted that they created their own intro
course, in the EE department, that taught Fortran. My roommate was a EE
major, and I borrowed his books, and used the free mainframe computer
time provided to each student to learn Fortran.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 10/11/2021 10:13 AM, George Neuner wrote:
> On Sun, 10 Oct 2021 16:31:21 -0700, Stephen Fuld
> <sfuld@alumni.cmu.edu.invalid> wrote:
>
>> I don't think the question of whether 64 bits is adequate (it is), but
>> for how long into the future will it be adequate, and secondarily, when
>> it does become inadequate, how big a change, hardware and software, will
>> be required to deal with it?
>
> When the time comes that one computer can't run all your programs, buy
> another one.
>
> Address space won't be a problem until 64 bits is too small for a
> /single/ program. "Big data" notwithstanding, I don't expect to see
> programs of that size any time in this century.

You may be right. But historically, desired address space has grown by
about 1 bit every 2-3 years. Currently we are probably in the mid
forties bits, so if the trend continues then we will exceed 64 before
2099. But others have said the trend is slowing.

Of course, time will tell.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 19/10/2021 21:29, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>> On 10/19/2021 11:58 AM, Thomas Koenig wrote:
>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>
>>>> There are more problems than that. Consider "y = x + 3 - 2;". (Imagine
>>>> it is the result of a set of macros, or inline functions and constant
>>>> propagation, rather than a hand-written expression.) Can a compiler
>>>> change that to "y = x + 1;" with overflow checking there? Does it need
>>>> to do two operations, checking twice?
>>>
>>> In Fortran, it could according to the language definition, as
>>> long as parenthethes are kept. The language even allows to change
>>> (x - x) into zero for floats, never mind NaNs.
>>>
>>> Few compilers dare to implement that.
>>>
>>> It would be illegal for y = (x + 3) - 2.
>>>
>>
>> That rule has always bothered me for a language with operator
>> precedence. OP forces parens to resolve precedence: Fortran (b+c)*a is
>> not the same as b+c*a, although it is in APL where there is no
>> precedence. Don't you find that precedence parens masquerading as
>> optimization-control parens sometimes engender bad code?
>
> I cannot think of an problematic example right now. Do you
> have an example?
>

I can certainly see it as common practice to include more parenthesis
than strictly needed in C expressions. Sometimes this is done because
the precedence levels of some operators might not be familiar to many
people, or because they are slightly odd. It's a good idea, IMHO (and
in the opinion of many others), to write "x << (n + 1)" rather than just
"x << n + 1" despite it having the same meaning. And if you have macros
involved in the expression, these usually have generous quantities of
extra parenthesis. It would be a shame for this to result in poorer
efficiency object code - that would encourage people to write less
clear, less maintainable and unsafe source code.