Re: Compiler for Z80/6510

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <1103_943587334@DZOG-CHEN>,
	falis@ma.aonix.com (Ed Falis) wrote:


>My take on it, having been involved in Ada compilers for a long time, is
>that an optimizing compiler can do well compared to the average
>programmer, turned to assembly language.  But, a good assembly
>programmer for a given architecture can do better.  This isn't rocket
>science - human intelligence generally beats what we can simulate with
>machines.

It has been a long time since I have written assembler language
programs, but I recall how we used to take advantage of all sorts
of little tricks that an optimizer would not dare to assume.  We 
could turn data into instructions and instructions into data, take
advantage of knowledge concerning register contents at a specific 
point in the execution cycle and use that register in obscure ways.
By knowing all of the instructions in a CISC set, one can do 
software contortions one would not expect of a compiler. 

If this makes you wonder about maintainability, you wonder correctly. 

In the long run, the maintainability of the compiler-generated code
has significant advantages over the hand-tinkering we so loved to do
in those primeval days of assembler only.  There is a certain tendency
to elitism here, as well. "Only whimps and sissies use compilers."

Robert Dewar is fond of emphasizing "readability over writeability."  
It is not unusual for an assembler programmer to write a program 
that is highly efficient but totally unreadable, or contains 
instructions that seem to make no sense at all.  "Why are there six
successive NOP's in this code?"  "Why does this instruction add 
Hex FFFF to this register?" 

Yes, a good assembler programmer can write more efficient code.  It 
will even work until someone updates the instruction set or changes the
timing characteristics of the processor.  

Richard Riehle
http://www.adaworks.com