|Good practical language and OS agnostic text? email@example.com (2012-04-17)|
|Re: Good practical language and OS agnostic text? firstname.lastname@example.org (Alain Ketterlin) (2012-04-18)|
|Re: Good practical language and OS agnostic text? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-04-19)|
|Re: Good practical language and OS agnostic text? email@example.com (BartC) (2012-04-21)|
|Re: code quality, was Good practical language and OS agnostic text? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-04-22)|
|From:||Hans-Peter Diettrich <DrDiettrich1@aol.com>|
|Date:||Sun, 22 Apr 2012 12:41:55 +0200|
|References:||12-04-019 12-04-023 12-04-033 12-04-058|
|Posted-Date:||22 Apr 2012 10:23:34 EDT|
> "Hans-Peter Diettrich" <DrDiettrich1@aol.com> wrote in message
>> Life is too short for writing an full-blown heavily-optimizing
>> production compiler from scratch, including its whole RTL.
> Especially when there might only be difference of 2 or 3 times between
> performance of the best and worst code.
> My own compiler for x86-32 generates pretty awful code, and on a small
> handful of mostly numeric benchmarks, it averages out about 2.5 x as
> slow as gcc on it's highest optimisation setting. But, gcc often
> recognises these benchmarks as doing nothing useful, so removes whole
> sections of code!
I never trust benchmarks, in detail when supplied by compiler vendors :-]
When we had several workstations for evaluation, the AIX workstation
came with a benchmark program executing in about 3 seconds on that
machine. On other machines the time ranged from 8 minutes to more than
When I added a printf after the loop in the benchmark code, it also took
about 8 minutes! The benchmark turned out to test the compiler *default*
optimization settings, where the HP station was so incredibly slow
because it had turned off *any* optimization by default.
From that experience I also learned what optimization means in
practice. A dumb compiler, or with all optimizations disabled, may fetch
every expression operand from memory, and write back every intermediate
result (SSA?), which is nice when debugging some code. Thus *register
allocation* turned out to be a basic optimization of high value - I
wonder how somebody could ever design a CPU (with more than 8 bit
registers) with as few registers as available on most Intel processors.
Dead code elimination and moving loop-invariant computations out of
loops are the next optimizations to consider. And CSE...
Another compiler, for an M68000, turned out to be a very quick&dirty
port of an M6800 compiler. According to "an int is a pointer, a pointer
is an int" it kept all operands in the M68K *address* registers, so that
every logical or arithmetic operation had to be done in a subroutine,
which moved the operands from A0 and A1 into *data* registers, evaluated
and stored back the result into A0. The caller had to move the operands
into A0 and A1 before, of course. In my test programs every single C
statement resulted in about 3 pages of assembler code! 
But despite that horrible code generation, this compiler came with a
very powerful graphics and window software, with amazing runtime
behaviour. This observation again relativates the need for optimization,
at least in GUI applications.
 This compiler, and my rudimentary knowledge of C and compilers and
runtime libraries, made me write my first C decompiler in the late 80's.
Of course in Basic, which was the language I had used on all my
homecomputers before. Hereby I learned more and more about bad and good
practices in compiler writing, encountering any number of workarounds
for adopting old 8-bit compilers to 16/32 bit code and memory layouts.
Return to the
Search the comp.compilers archives again.