Re: Computer architects leaving Intel...

On 14/09/2024 23:19, Michael S wrote:

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.
 

Contrary to your imagination - compilers have /never/ followed your proposed semantics.  The oldest gcc version I found on godbolt.org is 3.4.6 from 2006, and given:
struct Bar {
   char x[8];
   int  y;
} bar;
int foo(int i) {
     bar.y = 1234;
     bar.x[i] = 42;
     return bar.y;
}
It generates:
foo:
         movslq  %edi,%rdi
         movl    $1234, %eax
         movl    $1234, bar+8(%rip)
         movb    $42, bar(%rdi)
         ret
That is, y is /not/ reloaded after bar.x[i] is set.
Your proposed semantics are extremely unexpected for most C developers, would involve pretty much a complete re-write of the C model if they were to be applied consistently to other aspects of C, would have a significant impact on code efficiency, and they are not something anyone has used or relied on before.

So, either bar.y is treated as if it was volatile, or hard-to-detect
bugs would appear because, with optimization, the assignment would
sometimes change the value of bar.y and sometimes not.

 No, semantics is that compiler has to reload bar.y if it keeps it in
register. Optimizer that does anything else is buggy.
 

Well, buggy according to your hypothetical semantics.  Not buggy according to the way C has always worked, and the way C compilers generate code.