Xref: utzoo comp.lang.c:14682 comp.lang.misc:2333
Path: utzoo!attcan!uunet!husc6!xait!g-rh
From: g-rh@XAIT.Xerox.COM (Richard Harter)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Assembly or ....
Message-ID: <37812@XAIT.Xerox.COM>
Date: 2 Dec 88 22:24:23 GMT
References: <1388@aucs.UUCP> <1107@esunix.UUCP> <16819@onfcanim.UUCP>
Reply-To: g-rh@XAIT.Xerox.COM (Richard Harter)
Organization: Xerox Corporation, Cambridge, Massachusetts
Lines: 27

In article <16819@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes:
>In article <1107@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
>>Trying to read a piece of assembly
>>language that you wrote last month might convince you that low level
>>code is indeed bad, ugly, and wrong.

>I've seen some elegant assembly code, and it's elegant for the same
>reasons that higher-level code is elegant: it does its job precisely
>and cleanly and well.

	One of the prettiest and most satisfying programs that I ever
wrote was in assembly language (PDP-11/34).  The program processed marine
seismic data.  It had to sample and demultiplex multiple traces, compute
and apply a Weiner shaping filter, do bottom tracking and derevereration,
60 hz filtering, common depth point stacking, and generate labelled chart
recorder output, and much more, all in real time.

	The great satisfaction of assembly language programming is that
one can do something very well using minimal resources of space and time.
However it is an expensive pleasure -- the cost of the labor required to
polish and refine is high.

-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.