Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 14 Sep 2024 20:07:03 -0700
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <861q1leht4.fsf@linuxsc.com>
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> <vc35gk$1a8l8$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 15 Sep 2024 05:07:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="393c6de94aad5c3a9db23639212fcd5c";
	logging-data="1878719"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/DR4k7EHoPhCyxLBlOGXoKdniMA5t5uVs="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:H9Ky67PTEKOqcsPTg57WydPIxyY=
	sha1:P21+ylHMxeZD6/Dbmw0LzVP3V0I=
Bytes: 3030

BGB <cr88192@gmail.com> writes:

> On 9/12/2024 5:12 AM, Tim Rentsch wrote:
>
>> BGB <cr88192@gmail.com> writes:
>>
>> [...]
>>
>>> Would be nice, say, if there were semi-standard compiler macros for
>>> various things:
>>>    Endianess (macros exist, typically compiler specific);
>>>      And, apparently GCC and Clang can't agree on which strategy to use.
>>>    Whether or not the target/compiler allows misaligned memory access;
>>>      If set, one may use misaligned access.
>>>    Whether or not memory uses a single address space;
>>>      If set, all pointer comparisons are allowed.
>>>
>>> [elaborations on the above]
>>
>> I suppose it's natural for hardware-type folks to want features
>> like this to be part of standard C.  In a sense what is being
>> asked is to make C a high-level assembly language.  But that's
>> not what C is.  Nor should it be.
>
> There are a few ways things can go:
>   Define rules, have one of N permutations for how those rules can go;
>     How it often worked in practice.
>   Throw up hands and say it is unknowable.
>     What a lot of "portability" people assert.
>   Do whatever gives the fastest results in standardized benchmarks.
>     What many compiler maintainers want.

These options come from the perspective of someone writing a
compiler.  That is very different from the perspective of someone
writing a language definition.  More than 60 years ago we learned
the lesson that we shouldn't let machine architectures be defined
just by what the hardware does.  The same lesson applies to
defining a programming language just by what compilers do, or
even just what compilers can do.