Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!think!rst
From: rst@think.COM (Robert Thau)
Newsgroups: comp.misc
Subject: Re: Assembly Language
Message-ID: <7359@think.UUCP>
Date: Sun, 9-Aug-87 11:51:26 EDT
Article-I.D.: think.7359
Posted: Sun Aug  9 11:51:26 1987
Date-Received: Sun, 9-Aug-87 22:45:41 EDT
References: <892@edge.UUCP>
Sender: news@think.UUCP
Reply-To: rst@sauron.UUCP (Robert Thau)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 71

In article <892@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes:
... an ode to assembly language, saying various things like:

>In terms of the amount of code you have to write, assembly tends to be in
>the middle ground.  More code than APL or C, less code than Pascal or COBOL.

Have you got data on this?  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.  In particular, what gives you
the impression that PASCAL programs are that dramatically larger than C?

>...  Its strong points are ... and ease of debugging (yes,
>EASE of debugging).

In my experience, at least, the number of bugs is rougly linear in the
number of bytes of source code, for which see above.  Assembler also
suffers for the lack of type checking at either compile time or (as in
the case of LISP and SMALLTALK) run time, and the lack of direct
support for record structures.

You may be referring to the existence of ddt-type tools which allow
you to debug the program at the level of its (assembly language)
source, give or take the symbol table.  Source level debuggers for
HLLs are common these days, so assembler is at best on par.

Again, data would be helpful.

>As a rule, assembly language programs are actually EASIER for another
>programmer to pick up and figure out than are C programs (given that the
>reader is fluent in the language).  This isn't because of anything inherent
>in the language, but simply because assembly programmers usually comment
>like fiends, while C programmers think their code is self-documenting.

You are overgeneralizing mightily.  Both C and assembler portions
PDP-11 UNIX v6 source code, for example, were commented very sparsely.
Conversely, there are HLL programmers that "comment like fiends".
This is a question of style, not language.

>Assembly language programming isn't "impossibly hard", and it *is* still
>widely used in the non-Unix world.  Regardless of what college professors
>and Unix fans would have you believe.  There are a lot of applications out
>there where portability is of no interest, but performance is critical.  For
>those applications, assembly is clearly the language of choice.

A few boilerplate flames:

It is, by now, a truism that, in most applications, 10% of the code
takes 90% of the time.  Even with a lousy compiler, handcoding the
other 90% of your code buys nothing. 

Order-of-magnitude improvements in runtime often arise from changes in
algorithms.  In particular, you can often gain quite a lot by
incrementally modifying the state of a complicated data structure, the
manipulation of which would be quite difficult in assembler.

Lastly, modern optimizing compile technology is quite good.  After
looking at some of its output, I'd trust DEC's optimizing C compiler
("vcc" on ULTRIX) to come within 30% of my own handcoded assembler, in
both speed and size, and I've done quite a bit of assembly language (a
LISP interpreter for Z80 while I was in high school, more recently
a fair amount of Connection Machine assembler (PARIS)).

Personal opinion: In the light of all of this, it is hardly clear that
assembler is the language of choice *for an entire new program*, even
where portability is of no concern.  On the other hand, if you've got
tight requirements, good algorithms, and a lousy compiler, there
should be no hesitation in handcoding an inner loop.

>Doug Pardee, Edge Computer Corp; ihnp4!mot!edge!doug, seismo!ism780c!edge!doug