Re: Folk Theorem: Assemblers are superior to Compilers

pardo@cs.washington.edu (David Keppel)
Wed, 3 Nov 1993 03:38:42 GMT

          From comp.compilers

Related articles
[22 earlier articles]
Re: Folk Theorem: Assemblers are superior to Compilers qualtrak@netcom.com (1993-10-30)
Re: Folk Theorem: Assemblers are superior to Compilers johnson@cs.uiuc.edu (1993-10-31)
Re: Folk Theorem: Assemblers are superior to Compilers henry@zoo.toronto.edu (1993-10-31)
Re: Folk Theorem: Assemblers are superior to Compilers drraymon@watdragon.uwaterloo.ca (1993-11-01)
Re: Folk Theorem: Assemblers are superior to Compilers dmr@alice.att.com (1993-11-02)
Re: Folk Theorem: Assemblers are superior to Compilers steven.parker@acadiau.ca (1993-11-02)
Re: Folk Theorem: Assemblers are superior to Compilers pardo@cs.washington.edu (1993-11-03)
Re: Folk Theorem: Assemblers are superior to Compilers kanze@us-es.sel.de (James Kanze) (1993-11-03)
Re: Folk Theorem: Assemblers are superior to Compilers vthrc@mailbox.uq.oz.au (Danny Thomas) (1993-11-05)
Re: Folk Theorem: Assemblers are superior to Compilers lenngray@netcom.com (1993-11-07)
Re: Folk Theorem: Assemblers are superior to Compilers rfg@netcom.com (1993-11-13)
Re: Folk Theorem: Assemblers are superior to Compilers synaptx!thymus!daveg@uunet.UU.NET (Dave Gillespie) (1993-11-15)
| List of all articles for this month |

Newsgroups: comp.compilers
From: pardo@cs.washington.edu (David Keppel)
Keywords: assembler, optimize, performance, comment
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: 93-10-114 93-10-149
Date: Wed, 3 Nov 1993 03:38:42 GMT

rfg@netcom.com (Ronald F. Guilmette) writes:
>[I hope code quality often suffers because responsible compiler
> vendors are doing their best to work on correctness first and place
> a lower priority on whiz-bang optimizations.]


I visited one of the implementors of a compiler and was surprised to find
it larger (more lines of source code) than GNU CC. I asked why and was
told that there were a variety of reasons, such as the overhead of
internal modularization; support for various code generation styles such
as shared libraries, support for varied processor implementations, and so
on. However, the biggest single reason for big code was from squeezing
another N% of performance from the generated code. The person argued that
nobody within the company had expressed a crying need for better code but
that market forces and a need to look good on e.g., SPEC benchmarks led
them to focus on detailed optimizations and thus to the larger code.


;-D on ( The Folk Historian ) Pardo
[In the PC tools biz, there seems to be a large market for compilers that
produce very fast but wrong code. Don't ask me why. -John]
--


Post a followup to this message

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