But only one token scan pass.
The subsequent pass(es) went
over the internal representation of the program to fill in the missing
pieces.
Your description fits two of the later compilers, Pascal
and NEWP: they build an internal representation (tree) for a portion of the
program text, massage it, emit the code, and then go back to the scanner for
more. But the compilers I listed were true one-pass compilers: token-scanning
and code emission were intermixed activities.
To be sure, there were special
cases in which 'long' lookahead was required: the worst of these —
parsing an ALGOL FOR-clause used 7-symbol lookahead in the case of FOR I := 0
STEP 1 UNTIL 10 DO (for various values of 0, 1, and 10), testing that STEPI
returned BECOMESY, INTCON, STEPSY, INTCON, UNTILSY, INTCON and DOSY at each
lookahead step. If the lookahead succeeded, it accepted the tokens and emitted
the simple iteration code; otherwise, it reparsed the FOR clause (from the
previously scanned tokens, saved in the ELBAT array, generating (in the normal
way) appropriate code for the non-simple cases. (Gee, I'm surprised that I can
recall that much of the code I wrote 45 years ago.)
The DECSystem10 compiler
may have used the technique you describe, but DEC didn't provide the
architectural support that made our one-pass techniques feasible. After all,
the PDP-10 was a normal, flat-memory architecture, where the Burroughs large
systems were a token-based, truely segmented architecture. We couldn't use a
linker back-patch technique, because we didn't have a linker: we designed the
architecture to avoid the need for one. --- --Bill. NAL: question the
answers, especially mine. [ Reply to This | Parent | # ]
|