Re: Computer architects leaving Intel...

On Sun, 15 Sep 2024 08:05:47 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Sat, 14 Sep 2024 20:14:23 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
 

Michael S <already5chosen@yahoo.com> schrieb: 

On Fri, 13 Sep 2024 21:39:39 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
  

Michael S <already5chosen@yahoo.com> schrieb:   

On Fri, 13 Sep 2024 04:12:21 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
    

Michael S <already5chosen@yahoo.com> writes:     

   

struct {
 char x[8]
 int  y;
} bar;
bar.y = 0; bar.x[8] = 42;
>
IMHO, here behavior should be fully defined by
implementation. And in practice it is.  Just not in
theory.       

 
Do you mean union rather than struct?  And do you mean
bar.x[7] rather than bar.x[8]?  Surely no one would expect
that storing into bar.x[8] should be well-defined behavior.
 
If the code were this
 
    union {
      char x[8];
      int  y;
    } bar;
    bar.y = 0;  bar.x[7] = 42;
 
and assuming sizeof(int) == 4, what is it that you think
should be defined by the C standard but is not?  And the
same question for a struct if that is what you meant.     

>
>
No, I mean struct and I mean 8.
And I mean that a typical implementation-defined behavior
would be bar.y==42 on LE machines and bar.y==42*2**24 on BE
machines. As it actually happens in reality with all
production compilers.

 
Ah, you want to re-introduce Fortran's storage association and
common blocks, but without the type safety.  Good idea, that.
That created *really* interesting bugs, and Real Programmers
(TM) have to have something that pays their salaries, right?
 
SCNR   

>
What I wrote is how all production C compilers work today. So it
will add no new bugs.   

 
Maybe I should be a little bit more precise in why I think this
is an extemely bad idea.
 
struct {
  char x[8]
  int  y;
} bar;
 
Assume
 
  bar.y = 1234;
  bar.x[i] = 42;  // The compiler does not know i
  // Do something with bar.y
 
The compiler should then treat the access to bar.x[i] as if bar.y
was clobbered by the assignment statement, and reload bar.y if
it was kept in a register?  That is the semantics you propose.
 

>
Yes, exactly. 

 
So, volatile for all structs,

No.
Access to field of struct's should be ordered only relatively to
accesses to other fields *of the same instance* of the struct. And,
of course, usual 'as if' applies, so optimizing compiler can figure out
that bar.x[7] and bar.y do not overlap and thus generate code knowing
that write to one does not clobber the other.
That's pretty far from semantics of volatile.

plus prescribed behavior on array overruns.

Only withing bound of struct. bar.x[12] remains UB

 
At the risk of repeating myself: This is an extremely bad idea.
 
I rest my case.

You seem to think that C should be as optimizable and as full of UBs as
Fortran. Many compiler authors agree with you.
I have different idea. IMHO, your party exploits the letter of C
standard in violation to its spirit.