From: lowen@lorc.UUCP (Lamar Owen)
Newsgroups: alt.folklore.computers
Subject: HLL vx. Assembler--Summation
Date: 10 Sep 92 13:28:06 GMT
Organization: LORC Enterprises

Well, I've seen alot of bickering about assembler vs hll now.  I posted once
before.... Oh well, it's probably expired at most reasonable sites by now...
(My site is not reasonable--I actually don't expire afc at all.)

[Warning--Long post follows.  However, IMO, the signal to noise ratio is
satisfactory on this, so the reader is invited to read on, with a critical, but
objective eye]

Anyway, what I find incredible about this whole debate is the noticeable
polarization on each side (just to use two particular names that show up
frequently--Jim Frost and Charles Lasner (cjl)).  This polarization is due
entirely to a debate that, thus far, has rested entirely on nit-picking
details.  Now, nit-picking is fine, as long as it is done in a dispassionate
sense.  However, this debate has become nit-picking at its worst (my post
regarding the lack of stdlib.h included!).

So, I then see a post from Linus Torvalds, the person behind Linux (BTW: THANKS
Linus!!!).  In this post, Linus states that cjl will never admit to the merits
of hll.  Well, back at the beginning of the thread many eons ago, cjl 
specifically stated that hll was useful, but there were things that were best
done in assembler.

Now, the feeling I have is that cjl does not particularly like C because of
bad experiences porting so-called portable code.  So have I, but I wouldn't
want to write large portable applications in assembler.

However, cjl has a very valid set of points that no one has challenged.  
Seriously!  First, he states that there are things that simply cannot be
done efficiently in hll.  He goes on and provides a list.  Parts of this list
are quite accurate, such as the low-level stuff required to do systems work
(context switching, interrupt handling, timing loops, etc).  Although C is
quite capable of doing this level of work (I'm sure Linus could tell us about
Linux internals....), assembler is preferred because, at this level, assembler
is the most obvious language, meaning that it is far easier to handle this sort
of stuff (disk I/O transfers, critical interrupt handling, context switching) in
assembler than in C, or any other hll.  Why is this so?  Because an hll is too
high level to handle it well.  Note the 'well' qualification.

Second, he states, very correctly, that the vast majority of personal 
workstations out there are Intel x86 running a variant of MS-DOS.  This is a
FACT, not just cjl's opinion.

Note also that cjl is quite aware of the non-portable nature of assembler: he
is not challenging portability notions, he is rather saying that the intended
application of his code is already of a non-portable nature (MS-Kermit is one
example), so portability is a non-issue FOR HIM.  Portability is a prime issue
for me and many others, but not him.

For those that think cjl is a newbie of some sorts, read comp.sys.dec.micro
for awhile.

Similarly, Jim Frost, by virtue of being at centerline.com, has my respect
because I know who centerline is.  Do you?  Maybe Jim could ellaborate on just
what he does at centerline, who is a premier manufacturer of compilers and
compiler-support products, such as debuggers and IDE's (Integrated Development
Environments....).  For those in the know, they used to be Saber Software.

Jim is convinced that cjl doesn't know what a modern compiler can do.  Well,
being that Jim works for a compiler vendor, in particular a Unix C compiler
vendor, I believe Jim is quite qualified to say what a modern compiler can
and cannot do.

So, the debate is not "Assmbler is the absolute best and HLL always stinks for
all possible functions", but is more "I want an assembler because there are
things that only assembler can do on the architecture(s) I use, and HLL's
are unsuitable for some certain tasks that I do."  However, what has happened
is that cjl's opening remarks have caused, to use cjl's term, "HLL Zealots"
to pick up their cross and cry "Foul! You don't *need* an assembler!!!" (:-))
So, the debate has degenerated to arguing whether a human programmer can 
outperform a compiler writing tight code.  Well, reality check: the compiler
is itself a program written by a human, and it is this human that wrote the
compiler that the assembler programmer is programming against. Now, if you
take the combined assembler talent of thousands of people, and cleverly
combine the results into a compiler which knows all the optimization
tricks in the book (gcc is a good example compiler), then the lone assembler
programmer has very little chance of winning the war, although that lone
programmer may win a few battles in speed and/or low-level work.

So the two sides of the argument boil down to programmer freedom versus
management ease.  Yes, you heard me correctly: management ease is the driving
force behind hll.  I'm not talking management as in "the set of all managers",
I'm talking about management as in what SCCS and RCS were created for.  What
I'm talking about is having code that can be maintained versus code that is
quite artful, but unmanageable.  There are several happy mediums, one is
structured assembler (!?!?) and the other is C.  You can also inline assembler
in C if portablility is not a goal.

Cjl doesn't want the end of HLL's.  Rather, he wants to have the freedom to
program in any form he wishes.  Moreover, he wants everybody to have the
freedom to choose this freedom versus management ease.  Note that this
freedom to choose is for independent projects: it is ludicrous to think that
just because you want to use, say, FOCAL in your portions of a largish
COBOL project at work just to satisfy your freedom that you will be able to. No,
that would be unacceptable to your employer.  But, in you own work, if you
freelance, you should be free to choose whatever you wish.  Cjl is simply
helping the choice by providing information on what assembler does well. And,
I thank him for what started out as an informative discussion on the relative
merits of assembler versus HLL.  And I also thank those that took to time to
actually read what cjl was saying and post informative articles on what
modern compilers can indeed *do* (thanks for the gcc example, Matthew.).


--

Lamar Owen, Systems Consultant, GE Lighting Systems, Hendersonville, NC
***********************************************************************
 Opinions expressed herein are the author's and do not reflect policy
   or opinions of the General Electric Company or its subsidiaries.
***********************************************************************