Path: utzoo!utgpu!water!watmath!clyde!ima!johnl Newsgroups: comp.compilers Subject: Simplistic Assemblers? Message-ID: <789@ima.ISC.COM> Date: 15 Dec 87 18:03:55 GMT Sender: johnl@ima.ISC.COM Reply-To:Lines: 71 Approved: compilers@ima.UUCP 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] -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request