Re: Folk Theorem: Assemblers are superior to Compilers

macrakis@osf.org (Stavros Macrakis)
Wed, 27 Oct 1993 18:43:50 GMT

          From comp.compilers

Related articles
Folk Theorem: Assemblers are superior to Compilers elliottm@csulb.edu (1993-10-24)
Re: Folk Theorem: Assemblers are superior to Compilers dmartin@andy.bgsu.edu (1993-10-26)
Re: Folk Theorem: Assemblers are superior to Compilers napi@cs.indiana.edu (Mohd Hanafiah Abdullah) (1993-10-26)
Folk Theorem: Assemblers are superior to Compilers ssimmons@convex.com (1993-10-27)
Re: Folk Theorem: Assemblers are superior to Compilers vick@wotangate.sc.ti.com (1993-10-27)
Re: Folk Theorem: Assemblers are superior to Compilers leichter@thorium.rutgers.edu (1993-10-27)
Re: Folk Theorem: Assemblers are superior to Compilers cliffc@rice.edu (1993-10-27)
Re: Folk Theorem: Assemblers are superior to Compilers macrakis@osf.org (1993-10-27)
Re: Folk Theorem: Assemblers are superior to Compilers amn@ubik.demon.co.uk (1993-10-27)
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)
[20 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: macrakis@osf.org (Stavros Macrakis)
Keywords: assembler, optimize, performance, comment
Organization: OSF Research Institute
References: 93-10-114
Date: Wed, 27 Oct 1993 18:43:50 GMT

It is surely true that any program can be implemented at least as well
directly in assembler than through a compiler. Proof: hand-emulate the
compiler. More practically, note that any technique a compiler can use, a
human can use. The assembly programmer can use more general knowledge
about the running behavior of an algorithm than can a compiler (e.g. that
the first time through the loop, condition X is likely to be true, while
on all subsequent times, it is unlikely to be true). The assembly
programmer has more freedom to design data structures tailored to the
algorithm and the architecture.


This is all true but irrelevant, however. Such optimization requires a
lot of work in general. Any modifications to the algorithm or the data
structures may require re-starting the assembly coding (if it is very
tight) from scratch. This means that _algorithmic_ improvement is
discouraged, and that is where the biggest gains happen. Also, assembly
coding is more error-prone than higher-level language programming, both
because it is more voluminous and because it is less redundant (no sanity
checks).


By the way, many of the techniques that Abdullah <napi@cs.indiana.edu>
mentions were used in hand assembly coding long before compilers used them
(in fact, if you look at the early Scheme papers, you will discover that
tail-recursion optimization was inspired by assembly-language practice).


The main reason code is big and slow is that there is little pressure to
make it small and fast. There is much more pressure to add new features,
to support more device types, and to do that as soon as possible. I am
convinced that much code could be far smaller and far faster for a
relatively modest investment in recoding. But that cost is presumably
less than the opportunity cost of not getting out the next product or the
next enhancement in many cases.


-s
[Now that you mention it, a few years back there was a spreadsheet called
Silk that boasted that it was totally written in assembler and super hand
optimized, apparently by a large group of programmers in Taiwan. It
vanished without a trace. -John]
--


Post a followup to this message

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