Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site cadovax.UUCP
Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!trwrb!trwrba!cadovax!keithd
From: keithd@cadovax.UUCP (Keith Doyle)
Newsgroups: net.works
Subject: Re: Not again!?  Assembler vs High-Level languages
Message-ID: <543@cadovax.UUCP>
Date: Thu, 18-Apr-85 15:58:15 EST
Article-I.D.: cadovax.543
Posted: Thu Apr 18 15:58:15 1985
Date-Received: Mon, 22-Apr-85 11:48:34 EST
References: <483@terak.UUCP> <2251@wateng.UUCP> <492@terak.UUCP>
Organization: Contel Cado, Torrance, CA
Lines: 40

[...................]
> > How can any language (I don't know BLISS) produce a smaller program
> > than does assembler (assuming a competent assembly programmer)?  I'm
> > more interested in HOW than in a discussion of how many
> > competent programmers there are.
> 
> Because producing really tight code is an essentially mechanical job,
> requiring complex bookkeeping and application of many special tricks.
> Programs are much better at this than human beings.  My recollection
> is that a human assembler programmer could, given a lot of work, get
> code comparable to that of the Bliss compilers for any given small
> piece of code.  But the amount of work involved is prohibitive for any
> substantial program.
> 
> Remember, we are not talking run-of-the-mill assembler programming here,
> we are talking serious crunch-the-last-bit maximum-use-of-every-register
> efforts.  Mundane compilers generally do not do as well as good human
> assembler programmers, since the human programmer applies the simpler
> sorts of optimizations routinely.  But real optimizing compilers put
> more work into every piece of code than a human programmer can afford
> for anything but the most crucial stuff.
> -- 
> 				Henry Spencer @ U of Toronto Zoology
> 				{allegra,ihnp4,linus,decvax}!utzoo!henry

However, size is only one criteria that may exist for a given program.
Performance can also be an issue.  Size and performance have no
direct correlation.  In some parts of a program, performance may be the
primary issue.  Size may be a secondary, but still important issue.  Thus
a machine language programmer can decide where to use which techniques.
This may be an argument for smart compilers that produce really small
code that allow for machine coded subroutines that can use table techniques
that cost space if it buys appropriate performance.  Tradeoffs such as
these have to be weighed, and different parts of the same program may
require different techniques in order to optimize it for several conditions
at once.

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd