Assemblers

Doug Pardee writes:
| There is a modern aphorism that "It's much harder to program in assembler
| than in a high-level language". That's no surprise, considering that the
| typical programmer has neither training nor experience in assembler coding.
| We further hobble him by providing stone ax assembler tools, and then we
| have the gall to complain that the resulting program looks like it was
| butchered with a stone ax.


It may well be that Un*x assembler tools are pitiful. But the general
observation that "assembler is hard to program in" was learned on
systems (like OS/360) where the assembler-coding tradition was strong,
and the programmers had the requisite tools and skills. In many
cases, the system support for assembler was *much* better -- most HLLs
don't have a macro facility at all, and only fairly recently has the
concept of source-level debugging become popular. (On OS/360, the
*only* run time debugging facilities required that you know the
machine language and even the assembler coding *conventions*
intimately.)


The reason is that it generally takes more lines of assembler to do a
given job. And, not surprisingly, the number of lines of code is a
primary determinant of the amount of effort needed to write and
maintain an application. Assembler is also prone to errors of the
"oops, R7 doesn't have what I thought it had" type. (Remember C back
when "all the world's an int"?) It has always taken more time, money,
and skill to produce a working application in assembler than in an
appropriate HLL, even on systems that support assembler well.


As time has progressed, the fraction of applications which must be
written in assembler for efficiency reasons has gone down. The
quality of compiler-generated code has gone up. The availability of
languages (like C) that let you do the sort of sneaky back-door things
assembler used to be needed for has increased. Porting has become
more important. The price of hardware vs. labor has plummeted.


Assembler is still important, and its supporting tools should be as
rich as those for an HLL, but the area in which it can be economically
uses is gradually shrinking.


The moderator says:
| Indeed, I know people who
| use the 370 assembler as a macro processor, getting their results directly on
| the listing or in the object "deck," never generating an executable program,


The batch control file for an entire OS/360 system generation was the
preprocessor output of a bunch of macros!


Dale
--
Dale Worley Cullinet Software ARPA: culdev1!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw
--

Return to the comp.compilers page.
Search the comp.compilers archives again.