Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 31 Aug 2024 23:35:33 +0000
Organization: Rocksolid Light
Message-ID: <4ea63c1c737ab1435b5c1167791adcd4@www.novabbs.org>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me> <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me> <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me> <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me> <vb00c2$150ia$1@dont-email.me> <vb02o7$15e6b$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="413395"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$SuECAO3JJFnyoq.8jGvQz.mOUBS.w1Q1X3IC0Op6xIoLDsh.eeX/y
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 5024
Lines: 75

On Sat, 31 Aug 2024 21:42:31 +0000, Thomas Koenig wrote:

> Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> schrieb:
>> On 31.08.24 21:08, Thomas Koenig wrote:
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>
>>>> Of course the fans of compilers that do what nobody means found a
>>>> counterargument long ago: They claim that compilers would need psychic
>>>> powers to know what you mean.
>>>
>>> Of course, different compiler writers have different opinions, but
>>> what you write is very close to a straw man argument.
>>>
>>> What compiler writers generlly agree upon is that specifications
>>> matter (either in the language standard or in documented behavior
>>> of the compiler).  Howewer, the concept of a  specification is
>>> something that you do not appear to understand, and maybe never
>>> will.
>>>
>>> An example: I work in the chemical industry.  If a pressure vessel
>>> is rated for 16 bar overpressure, we are not allowed to run it at
>>> 32 bar. If the supplier happens to have sold vessels which can
>>> actually withstand 32 bar, and then makes modifications which
>>> lower the actual pressure the vessel can withstand only 16 bar,
>>> the customer has no cause for complaint.
>>>
>>> As usual, the specification goes both ways:  The supplier
>>> guarantees the pressure rating, and the customer is obliged
>>> (by law, in this case) to never operate the vessel above its
>>> pressure rating.  Hence, safety valves rupture discs.
>>
>> You compare apples and peaches. Technical specifications for your
>> pressure vessel result from the physical abilities of the chosen
>> material, by keeping requirements as vessel border width, geometry etc.,
>> while compiler writers are free in their search for optimization tricks
>> that let them shine at SPEC benchmarks.
>
> A specification is a specification, but it seems you do not grasp
> the concept.  It seems a curious mental gap in some people who
> think that it means fundamentally different things in different fields.
>
> But if you insist in putting some extra constraints on compiler
> writers, apart from the official standards, feel free to write them
> down (but please in a concise manner) and try to get them accepted,
> preferably by the relevant standards committees.  But you should know
> that writing a specication that is unambiguous and clear is
> hard work, and needs a lot of discussion and reviews.

Convincing the random code exercisers to obey the "that is not
an instruction" part of the specification is vastly harder.
C
>
> Or fork either gcc or LLVM (or both) and implement whatever
> restrictions you want, and if you can convince the maintainers
> of these compilers that it is a good idea to fold in your changes,
> they may do so.
>
> If you can make your case to enough people (or companies),
> then you will find enough volunteers and/or funding to do so.
> Snide remarks about compiler writers on comp.arch aren't going
> to have any meaningful impact, I'm afraid; if anything, they will
> lower your chance of success.
>
> But of course that depends on your definition of success - do
> you want to achive anything, or do you want to aggravate people?
> If it is the latter, then your chance of success might be a
> bit higher.
>
>> I personally write most code as in the days I learned C, where compilers
>> where literally too dumb to remember what they did 2 source lines ago,
>> so you could not rely on the compiler doing the "right thing" -- same as
>> nowadays, but because of other reasons.
>
> So you learned programming by ignoring the specifications that
> were available.  Well, sometimes making progress means unlearning
> something.