Re: Computer architects leaving Intel...

mitchalsup@aol.com (MitchAlsup1) writes:

On Sat, 7 Sep 2024 13:52:02 +0000, Tim Rentsch wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:
>

On Fri, 6 Sep 2024 13:37:13 +0000, Tim Rentsch wrote:

[...]

The idea is not to make more of the language defined but to give
less freedom to cases of undefined behavior.  (It might make
sense to define certain cases that are undefined behavior now but
that is a separate discussion.)  Let me take an example from
another of your postings:
>
  int a;
>
   ...
>
  if (a > a + 1) {
    ...
  }
>
>
Stipulating that 'a' has a well-defined int value, what behaviors
are allowable here?  [...]  If a == INT_MAX, it also should be
possible for the addition to abort the program.  [...]

>
It is also possible if a == INT_MAX that the exception will
transfer control to a signal handler to do some SW orchestrated
recovery.

>
Philosophically this reaction doesn't fit with the others.  Assuming
for the sake of discussion that raising an implementation-defined
signal is an important behavior to support, it should go into the
C standard in a different way than making it part of the "limited
undefined behavior" idea outlined above.

>
With it "being difficult" to determine when an integer overflow
has occurred in may architectures, it is unlikely that integer
overflow could ever be put into the C standard.

It could easily be added to the C standard just by making the
signal-raise option be conditional:  give each implementation
the choice of either (a) stipulating that overflow causes an
implementation-defined signal to be raised, or (b) letting the
operation be limited undefined behavior.  Limited undefined
behavior can be provided simply by naively compiling the code
in question, so that can be accommodated regardless of how
unsophisticated the processor is.