Newsgroups: | comp.compilers |
From: | raymondc@microsoft.com |
Keywords: | assembler, optimize |
Organization: | Compilers Central |
References: | 93-10-114 93-10-119 |
Date: | Thu, 28 Oct 1993 18:57:02 GMT |
leichter@thorium.rutgers.edu (leichter@thorium.rutgers.edu)
: | Data flow analysis for optimizing common-subexpressions....
:
: Again, most of these are trivial for a human being IF DONE DURING CODE
: DESIGN. For example, no decent assembler coder would ever write any dead
: code to begin with!
But as everyone knows, the code design rarely matches the final product.
After a few months of modification, I wouldn't surprised if snippits of
code started turning up dead.
: Similarly, copy/ constant propagation is, to a degree, a side-effect of
: the ease of having multiple names for things - important for clear
: exposition in high-level language. A good assembler programmer things
: about the DATA, not the names, and will usually do this automatically.
But compilers can perform constant propagation where an assembler
programmer would not see it. For example,
C Compiler output Human Asm
#define A 1 A equ 1
#define B 1 B equ 1
struct { char x[4]; } s;
x = A; r0 = 1 r0 = A
x = r0 x = r0
y = B; y = r0 r0 = B
y = r0
z = sizeof(s) * w; r0 = w r0 = w
r0 = r0 << 2 r0 = r0 * SIZE s
z = r0 z = r0
Sure it looks stupid here, but presumably the definitions of A, B and s
are hidden in header files. Similarly, other obvious assembler tricks
(optimizing a test against zero) may be hidden behind manifest constants
and hence elude the scrutiny of the human assembler programmer.
And if you *were* clever enough to see all of these tricks, you'll have
lots of fun if the definitions of A, B, and s change.
Of course, compilers have a much more difficult time with byzantine
architectures like the infamously non-orthogonal 8086 series. I'm
assuming a gloriously orthogonal RISC machine.
The problem with high-level languages is that you have to make sure your
problem is well-suited to the language. Writing a Scheme interpreter in C
is painful because C isn't well suited to tail recursion. (Call frames
traditionally contain both the arguments and the return address, which
makes CALLX'ing impossible if the destination has a different number of
arguments than the caller.)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.