From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Fri, 14 Aug 1992 08:50:02 GMT

In article <1992Aug12.233613.4745@ecl.psu.edu> bjj@ecl.psu.edu (Bryan J. Jensen) writes:
>
>If you insist on using the 8086 as an example of assembly language
>programing, I will continue to use C as THE example of a high level language.
>
>I suspect that, to the majority of graduating seniors, assembly language
>means 80x86 assembly language, and a high level language IS C.

Microsoft MASM as an assembler sucks rotten eggs.  All assembly programmers
I know who cut their teeth in a variety of other places have one thing in
common: they loathe and despise virtually everything about Microsoft from
its business inception to its products to its policies, etc. and mostly
they hate MASM.  If they do use an 80x86, they use Borland products, including
C++ pro and TASM.  Microsoft C is incompatible with everything but its own
dark past, and MASM is incompatible with reality; it doesn't generate the code 
you want on the machine, thus forcing an unnatural organization of the code
merely to minimize the lossage.  It's no wonder that assembler is unpopular
because in the minds of many, it's exactly as you say.  I can't blame someone
for using a unix machine and naturally falling into C when the alternative is
to have to fight with MS-DOG and MASM.  This is not my idea of assembler
environment at all :-(.  I'll take MACRO-10, MACRO-11, LAP, or PAL anyday
over their demented notion of an assembler, which I understand is *written* in
C :-(.
>
>Features are added to assemblers to aid in program develeopement
>just as features are added to compilers.  Unfortunately, less work
>has been done in this area for assemblers then compilers due to the
>current unpopularity of assembly language.

Macros as added onto assembler are totally under the control of the
programmer.  In essence, the language can be redefined to fit the problem.
Compare that with fighting with an abstract, but fixed hll.  This is not
to say that there aren't some same facilities in some hll's, just that
they virtually never are used that way.  This is a shame since this in an
incredibly elegant mechanism that should be greatly explored regardless of
language, but is more flexible in assembler.  BTW, as a hack, it is possible
to write a HLL-like set of macroes.  Some people have done that to some extent
in the past.

Several implementations of SNOBOL have been created merely by redefining the
macroes for the target machine because the bulk is written in machine-
independent macro language.  Seems that this "portability" issue doesn't
really originate with C afterall :-).
>
>There are stylistic differences too.  C is best suited for starving
>graduate students hacking out code while looking forward to graduation.
>Assembly language is better suited to a more formal environment where
>the same company which writes the software is stuck with maintaining it.
>This is because, apparently, there is nothing that can be done to
>motivate the average C programmer to use comments.  In contrast, assembly
>language programmers have no shortage of space on the page for their
>comments, so they usually have plenty, sometimes drifting off to subjects
>unrelated to the adjacent code.
>
>Examples follow.

Yes, there is a lot of obfuscated nary-a-comment C code.  And I personally
write assembly code with much more comments than your example.  I am sure
that individuals will answer that they swing the balance the other way in
their experience, but on balance, I tend to agree with you about these
trends.  Buggy code with no comments is sometimes what you get when code is
created expediently by an inexperienced "hot shot" with an "attitude problem",
in this case the attitude of a student as you described.  Since a lot of the
arguments presented here are matters of expediency, I don't think I can find
any flaw in your reasoning about which direction invariably each type will
tend to gravitate in.

Perhaps people should get paid not by the line of code, but rather by the
count of comments in it.  Since assembly language offers more opportunity
for more types of comments at various lower levels, this would encourage
quality.  You will tend to see line-by-line comments on the right, and
also section descriptions for better-grade code.  Well-written macroes can
generate comments for you that actually can be somewhat useful.  (Again, the
macro construct as a good assembler will encourage you to do is such a wasted
resource :-(.)

cjl
Newsgroups: alt.folklore.computers