Path: utzoo!utgpu!attcan!uunet!husc6!cs.utexas.edu!utastro!nather
From: nather@utastro.UUCP (Ed Nather)
Newsgroups: comp.arch
Subject: Re: using (ugh!  yetch!) assembler
Message-ID: <2948@utastro.UUCP>
Date: 27 Jul 88 15:27:10 GMT
References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <37014@linus.UUCP>
Organization: U. Texas, Astronomy, Austin, TX
Lines: 44

In article <37014@linus.UUCP>, munck@linus.UUCP (Robert Munck) writes:
> In article <2926@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes:
> >I know of no programmer who thinks assembly language is better for all
> >kinds of programs, nor do I know a good one who feels it is *never*
> >better for *any* job.
> 
> Given real world system sizes, budgets, deadlines, and MAINTENANCE
> constraints as your "requirements,"  assembly language will "fit" only
> the smallest, most toy-like, never-to-be-used-for-real prototypes.
> If I've got two years and five people to write a system that takes
> 100,000 lines of Ada [...]
> 

Our models of what constitutes a program are clearly very different.  Given
two years and five people to write 100,000 lines of Ada, I'd find some other
profession.  I'm astounded that it can be done at all, and I would *never*
propose it be written in assembler.

This difference in models may explain a lot of our differences of opinion.
As an alternative chore, consider this: I'm writing a real-time data
acquisition program (in C) that runs on an IBM PC clone (because it is
cheap, not because it is fast) that must have an animated, non-blinking
graphical display of data as they arrive.  My first cut (in C) had a display
so slow I wouldn't ever use it myself, so I re-wrote the display driver in
assembler, achieving a speedup of over 50 times (*not* 50%) because I could
put everything into the ugly Intel register set and never reference memory
in the display loop anywhere -- a luxury the C compiler did not have.  

> Sure, sometimes the timing requirements are so tight that the HOL version
> doesn't make it.  In that case, instrument the heck out of the HOL, find
> out which ten statements it's spending 30% of the time executing, and
> re-write those in assembler.  Keep doing this until you meet the timing
> specs.  Almost certainly, you'll have re-written less than 5% of the code.

That's what I did -- except I didn't need to instrument anything, I could
see what was too slow just by watching the display.  So where do we
disagree?  If you believe I advocated assembly language for all jobs,
please re-read what I wrote.

-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin
{backbones}!{noao,ut-sally}!utastro!nather
nather@astro.as.utexas.edu