|
yaYUL The AGC Cross-Assembler |
|
Please enable javascript in your
browser to see a site-search form here.
|
|
|||||||||||||||||||||
| Please enable javascript in your
browser to see a site-search form here.
|
||||||||||||||||||||||
| At this point, you may be
reasonably be wondering why a mere assembler would ever need to make 10
passes through the source code. Naively, one would expect a
simple assembler to take 2 passes: one to
resolve the values assigned to address labels, and one to generate the
code. However, there is a complication, in
that pseudo-ops like EQUALS
(see the assembly-language
manual) allow forward-references to other EQUALS
pseudo-ops. For example, consider the following code fragment: SYMBOL5
EQUALS SYMBOL4
SYMBOL4 EQUALS SYMBOL3 SYMBOL3 EQUALS SYMBOL2 SYMBOL2 EQUALS SYMBOL1 SYMBOL1 EQUALS 42 In this example, the value of SYMBOL1 isn't known until the end of pass 1, the value of SYMBOL2 isn't known until the end of pass 2, and so on. There is no practical limit to the number of passes needed—if symbol resolution is handled in a straightforward way—because it depends on how many constructs like those above appear within the assembly-language source code. Besides, this simple-minded use of multiple passes is eerily reminiscent of certain behaviors of the original YUL assembler, as evidenced by the following amusing quote from Hugh Blair-Smith (YUL's author): ... [the] observation about
assemblies being so long
that they were performed as overnight batch jobs, brings me to a
confession of one thing I wish I had done better, and I really think I
could have at the time. When it became clear, early in the project,
that the number of words in AGC memory was going to be greater than the
number of words in the assembling machine's (i.e., the Honeywell
800/1800's) memory, I gave up any attempt to retain the object program
in memory and just wrote each patch of object code on tape. Then there
was a "third "pass of the assembly process which sorted the object code
by what is perhaps the dumbest sort algorithm possible: running that
tape back and forth and writing the object code in its proper order on
another tape. As long as programs were just a few thousand
instructions, this went like the wind, but the full-size programs of
36000 or so instructions made Pass 3 pretty boring and frustrating to
watch. We did have a hard disk drive from 1965 or 1966, so I could and
should have written my object code onto that and read off the sorted
code in a flash. There wasn't anything like DOS to keep disk files out
of each other's hair, so this effort would have involved learning and
overcoming some risks of data getting stepped on. And there were always
other little enhancements that had to be done, so it wouldn't have been
easy—but I still wish I'd found a way to get it done. I guess one
thing that decreased the motivation was that each assembly had to be
printed, in about 3 or 4 hours on the noisy 600 line-per-minute
printer, so there wasn't anything the disk could do about assembly
being an overnight batch process. I had no notion, at the time, of
assembling modules separately and then linking the object modules, and
the long and difficult history of PC linkers suggests that it wouldn't
have been a good idea to try it even if I had thought of it.
This quote was taken from conference transcripts at MIT's Dibner Institute's now-discontinued History of Recent Science and Technology website. |
