Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.arch
Subject: Re: using (ugh!  yetch!) assembler
Message-ID: <24134@bu-cs.BU.EDU>
Date: 28 Jul 88 19:54:11 GMT
References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <2926@utastro.UUCP>
Organization: Boston U. Comp. Sci.
Lines: 55
In-reply-to: nather@utastro.UUCP's message of 23 Jul 88 14:51:25 GMT


>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.  Until I can buy a compiler -- for any language --
>than can generate code that runs as fast as I can write by hand, I will
>use assembly language where speed is essential.  You will, indeed, have
>a hard time proving to me that I'm wrong in using the tool that best
>fits the requirements of the job.
>
>-- 
>Ed Nather

Sure Ed, I agree, sometimes a routine or three ought to be written in
assembler, everyone seems to be saying the same basic thing, what's
the problem here exactly?

One problem you have to acknowledge is that it's a hell of a lot
easier to turn out HLL programmers than assembler programmers of any
value (fortunately, given the above you don't need too many.) And the
world needs a lot of programmers, more than they need a few tightly
coded routines. To a great extent (except in the most extreme cases)
speed has become mostly an economic issue (one major exception being
the PC market where the customer hardware base is relatively fixed in
speed and, lo and behold, you find a lot of machine level code bummers
getting top dollar in that biz.)

The problem is not straightforward coding of typical things, like
loops or integer arithmetic or character manipulation, that's easy
enough. The problem is almost everything else, getting a student to
learn enough about writing floating point in assembler, I/O operations
and exception handling, data structure discipline (in assembler it
much more closely resembles an arbitrary, self-imposed discipline),
recursively callable code, re-entrant code etc.

In HLL's most of that is handled fairly naturally, floating pt and
integer are more or less the same with no long exegeses about
normalization etc.

Sure, numerical analysis can be a real problem in either case, but
that's a different issue entirely, nothing about writing an algorithm
in assembler particularly tells me that the loop I just wrote will
turn the numbers into cream cheese by the time it exits, nor HLLs.

What is unfortunate is the loss of assembler programming from a lot of
curricula as, at least, an exercise in what the hell a computer really
is. Too many kids I run into view a computer as a box which interprets
Pascal or C code (etc.) Their mental model is broken so they have a
lot of trouble turning out reasonable code (eg. they have little idea
why screaming down an incrementing pointer is a lot faster than doing
an array lookup on each turn of a loop, and should usually be coded as
such on the first pass in most straightforward routines, particularly
search routines, at best they rote memorize such hints.)

The problem is a crowded curricula, mostly.

	-Barry Shein, Boston University