At Wed, 23 Mar 2022 20:56:27 +0100, Anders Magnusson <ragge%tethuvudet.se@localhost> wrote:
Subject: Re: pcc [was Re: valgrind]
Den 2022-03-23 kl. 19:37, skrev Greg A. Woods:
Heh. I would say PCC's generated code doesn't compare to either modern
GCC or LLVM/Clang's output.
I would say the main reason is PCC doesn't (as far as I know) employ
any "Undefined Behaviour" caveat to optimize code, for example.
I'll let the reader decide which might have the "higher" quality.
I would really want to know what you base these three statements on?
Well I've read a great deal of PDP-11 assembler as produced by PCC, and
I've fought with LLVM/Clang (and to a lesser extent with GCC) and their
undefined behaviour sanitizers (and valgrind) when trying to port old
code to these new compilers and to understand what they have done to it.
I also have way more experience than I ever really wanted in finding
bugs in a wide variety of compilers that are effectively from the same
era as PCC (e.g. especially Lattice C and early Microsoft C, which as I
recall started life as Lattice C).
Modern optimizers that take advantage of UB to do their thing can cause
very strange bugs (hidden bugs, when the UB sanitizer isn't used),
especially with legacy code, or indeed with modern code written by naive
programmers.
Note of course that I'm explicitly _not_ talking about the quality of
the _input_ code, but of the generated assembler code, and I'm assuming
that's what Paul was asking about.
One thing I don't have a good feel for though is how the code produced
by modern GCC and LLVM/Clang looks when they are told to "leave it
alone" after the first step, i.e. with "-O0", and especially as compared
to PCC with -O0. I _think_ they should be about the same, but I dunno.
Although older compilers like PCC are very naive and simplistic in how
they generate code, my feeling is that modern compilers are even more
naive in their first step of code generation as they have come to rely
even more on their own optimizers to clean things up. That's pure
speculation though -- I haven't worked directly with assembler code very
much at all since I left the likes of the 6502 and 8086 behind.