Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 14 Sep 2024 07:25:00 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <vc3doc$1blrd$1@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me>
 <memo.20240830090549.19028u@jgd.cix.co.uk>
 <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com>
 <2024Sep8.173639@mips.complang.tuwien.ac.at>
 <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
 <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z>
 <2024Sep11.123824@mips.complang.tuwien.ac.at>
 <vbsoro$3ol1a$1@dont-email.me> <867cbhgozo.fsf@linuxsc.com>
 <20240912142948.00002757@yahoo.com> <865xqzg63u.fsf@linuxsc.com>
 <20240913144411.00005866@yahoo.com> <vc2ber$120mf$1@dont-email.me>
 <6cd02e4b37b109607fb10dd02db9c668@www.novabbs.org>
Injection-Date: Sat, 14 Sep 2024 09:25:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0604802c43a8c920c345dbdb1e4a2884";
	logging-data="1431405"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+vln9njSggByCqAQa+NDFs1AgqHzQpGSM="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:zudN1Vrzg4frx/HpothElqBTpQA=
Bytes: 4189

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?