Re: Computer architects leaving Intel...

MitchAlsup1 <mitchalsup@aol.com> schrieb:

On Fri, 13 Sep 2024 21:39:39 +0000, Thomas Koenig 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.

>
FORTAN allowed::
subroutine1:
       COMMON /ALPHA/i,j,k,l,m,n
subroutine2:
       COMMON /ALPHA/x.y.z
expecting {i,j} which are INT*4 to overlap with x Read*8 ;...
{Completely neglecting the BE/LE problems,...}

Not only that, also different FP formats...

The only thing that was guaranteed is the storage unit.  An INTEGER
and a REAL occupies one storage unit, a DOUBLE PRECISION occoupies
two.  Through EQUIVALENCE or through different COMMON blocks in
different procedures, an INTEGER and a REAL can occupy the same
storage location.  And if a value was assigned to a variable of
one time (the entity became defined, in standardese) the variable
with the same storage location becomes undefined (at least as far
back as Fortran 77, I didn't check earlier).

This was very widely ignored, people used COMMON and EQUIVALENCE
for type punning all the time.

There also was the issue of alignment; by playing tricks with
EQUIVALENCE, you could put a double precision variable on an
unaligned memory location.  With the advent of the RISC CPUs which
didn't support this, this became the most-ignored provision in the
standard (but with a flag to restorte standard-conforming behavior).

Hmm... what were the alignment restrictions on double precision
on the /360?