Re: Folk Theorem: Assemblers are superior to Compilers

raymondc@microsoft.com
Thu, 28 Oct 1993 18:57:02 GMT

          From comp.compilers

Related articles
[9 earlier articles]
Re: Folk Theorem: Assemblers are superior to Compilers synaptx!thymus!daveg@uunet.UU.NET (Dave Gillespie) (1993-10-27)
Re: Folk Theorem: Assemblers are superior to Compilers winikoff@munta.cs.mu.OZ.AU (1993-10-28)
Re: Folk Theorem: Assemblers are superior to Compilers prener@watson.ibm.com (1993-10-28)
Folk Theorem: Assemblers are superior to Compilers Mark_Prince@gec-epl.co.uk (1993-10-28)
Re: Folk Theorem: Assemblers are superior to Compilers mps@dent.uchicago.edu (1993-10-28)
Re: Folk Theorem: Assemblers are superior to Compilers toon@moene.indiv.nluug.nl (1993-10-28)
Re: Folk Theorem: Assemblers are superior to Compilers raymondc@microsoft.com (1993-10-28)
Re: Folk Theorem: Assemblers are superior to Compilers adk@sun13.SCRI.FSU.EDU (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers elliottm@csulb.edu (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers jvn@fermi.clas.virginia.edu (Julian V. Noble) (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers Freek.Wiedijk@phil.ruu.nl (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers synaptx!thymus!daveg@uunet.UU.NET (Dave Gillespie) (1993-10-29)
Re: Folk Theorem: Assemblers are superior to Compilers rfg@netcom.com (1993-10-30)
[12 later articles]
| List of all articles for this month |
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.)
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.