Re: Computer architects leaving Intel...

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.