Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!hao!noao!mcdsun!sunburn!gtx!edge!doug
From: doug@edge.UUCP (Doug Pardee)
Newsgroups: comp.misc
Subject: Re: Assembly Language
Message-ID: <904@edge.UUCP>
Date: Thu, 13-Aug-87 17:42:33 EDT
Article-I.D.: edge.904
Posted: Thu Aug 13 17:42:33 1987
Date-Received: Sun, 16-Aug-87 06:49:03 EDT
References: <892@edge.UUCP> <7359@think.UUCP>
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 76
Summary: Comparing assembler with HLLs

[Note to the reader:  I'm trying hard to avoid any "'Tis not! -- 'Tis so!"
arguments, and instead to concentrate on expanding my explanations -- DLP]

>A fairly complicated one-line HLL
>expression which involves, say, a few array references and a couple of
>multiplications (which often have odd alignment rules) can easily
>expand out to several *lines* of assembly language code, depending on
>the addressing modes of the machine.

True.  But this is cherry-picking for the example which best illustrates
your point.  Counter-example: this line of 80x86 assembler expands into 
several lines of just about any HLL:
  REP MOVSB

When you count HLL lines, don't forget all of those lines that don't even
generate any code at all.  How about the ever-popular C line, "}"?

That is petty stuff, though.  The real point is that some applications
are "naturals" for the HLL, in which case I say DO use the HLL.  But for
many others you have to go out of your way to accomplish the task, and
that usually means extra HLL code.

>Assembler also suffers ... the lack of direct support for record structures

Another netter mentioned this too.  This is not a fault of assembly
language, this is a deficiency in the assembler software package you're
using.  These record structures (often called DSECTS in assembly) are
available with IBM 360/370 assemblers, and with the Microsoft assembler for
the IBM PC.  No doubt with other assemblers too.

Unfortunately, in the Unix universe it is assumed that nobody programs in
assembler, so Unix assemblers tend to be unusable trash.  A vicious cycle.

>It is, by now, a truism that, in most applications, 10% of the code
>takes 90% of the time.
> ...
>Order-of-magnitude improvements in runtime often arise from changes in
>algorithms.

Granted.  No arguments from me.

But (and I bet you just *knew* there was going to be a "but"...)

Once you've selected the best algorithm you can find (if you look for it),
and once you've optimized the slow 10% of your code so that you no longer
have any "hot" spots (if you bother), the program still could go a number of
times faster if it was coded in assembler.  [How many times faster?  Depends
on how poorly the application fit the HLL in the first place.]

I'm trying to make two distinct points here:  1) one of the biggest reasons
that HLLs are used for applications that should have been done in assembly
is programmer laziness.  A lazy programmer probably won't look for the best
algorithm, and certainly won't bother to locate the hot spots and fix them.
A programmer who cares enough to use the right algorithm, and who cares
enough to find and fix the hot spots in his program, is usually a programmer
who cares enough to use the right language for the job, even if it happens
to be (horror of horrors) assembly language.

2) the "magic" that results from selecting the best algorithm, and of
finding and fixing hot spots, is *not* confined to HLLs.  It works just as
well for assembly language.

>("vcc" on ULTRIX) to come within 30% of my own handcoded assembler,

I've gotta repeat myself: if the application is a "natural" for C or some
other HLL, then USE that HLL.

It's really not fair to compare compiler output versus handcoded assembler
for those applications.  A proper comparison is to select an application
which *should* be written in assembler, and compare that assembly code
against the compiler output for the kludge you had to write in the HLL.

By the way, in many non-Unix applications you'd *kill* for "only" a 30%
improvement in code size and/or speed.
-- 
Doug Pardee, Edge Computer Corp; ihnp4!mot!edge!doug, seismo!ism780c!edge!doug