Simplistic Assemblers?

I realize that this forum is "of, by, and for" compiler gurus, and so I
shouldn't expect expertise in assembler technology. In case some of the
participants are interested, I would like to take a moment to dispute the
claims made here about simplistic assemblers being better for the human
assembler language programmer than complex assemblers.


By analogy, a C compiler could be made easier for the programmer to use if
we removed features like automatic variables, structures, unions, multiple
subscripts on arrays, the preprocessor, and especially those pesky pointers
which nobody can ever seem to get right. While we're at it, we can get rid
of a bunch of other complexities by eliminating separate compilation. Hey,
you can still write a Turing machine in the remaining language, so we
haven't removed anything that was absolutely critical, right?


If this seems like a ridiculous notion, you're right. But that is a close
approximation to what has been gutted from the typical Unix (tm) assembler
program. Today's assemblers are generally less capable than those which
were designed for the first-generation computers of the 1950s.


There is a good reason that the OS/360 assembler required four passes
(which still wasn't always enough, the OS/VS assembler can take an
unlimited number of passes). The OS/360 assembler was designed for use by
human programmers, in a time when assembler language programmers weren't
considered to be a subhuman lifeform.


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.


Assembler language will always be difficult (an understatement) to "port".
But assembler language doesn't HAVE to be difficult to program in, and the
programs don't HAVE to be difficult to read and maintain. IF reasonable
programming tools are available to the programmer (and the programmer has
the training and experience to use those tools).
--
Doug Pardee -- Edge Computer Corp., Scottsdale, AZ -- uunet!ism780c!edge!doug,
{ames,hplabs,sun,amdahl,ihnp4,allegra}!oliveb!edge!doug, mot!edge!doug


[My understanding was that the four-pass assembler did so because it was
shoehorned into 44K, the 256K assembler usually managed in two. It is also
true that there are some spiffy assemblers, most notably the ones for the
IBM 370 series, that have enormously powerful macro languages that let you
do all sorts of astounding stuff. For example, I know of at least two IBM
computers for which IBM never wrote an assembler, rather defining macros
for the 370 assembler and slightly postprocessing the object deck.


On the other hand, there is nothing that says that the powerful macro language
necessarily has to be bound up with the assembler. 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,
which suggests to me that we have an overintegrated program. Unix systems
traditionally have a minimal assembler and a separate macro processor, which
seems usually to be sufficient. I can't help but notice that in all of the
swell IBM assemblers, they never did stuff like optimizing span-dependent
branches on machines like the 1130 and more recently the ROMP, which Unix
assemblers have always done. In fact the IBM ROMP assembler had a warning "you
could have used a short branch instead of a long one here," but it never
occurred to them to have it do anything about it.


It has always seemed to me that the main place that assembler loses is in data
structuring -- typed data and pointers buy you a lot, particularly in the
error checking department, and it'd take an awful lot of macro magic to give
an assembler that. -John]
--

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