Some may find this paper interesting on the FORTRAN I compiler:
https://www.cs.fsu.edu/~lacher/courses/COT4401/notes/cise_v2_i1/fortran.pdf
I will add that the diagnostic error messages for FORTRAN I were pretty
good for the time. Missing a comma in a computed GOTO? There was an
error message that directly addressed this error.
Back when I was still in the business of writing compilers, the "Dragon
Book" ("Compilers: Principles, Techniques and Tools", Aho, Sethi;
Ullman) was the standard reference. I don't know if it still is. The
earlier book by Saul Rosen is also pretty good.
FORTRAN (as opposed to Fortran) is somewhat odd lexically when compared
with other languages. There are no reserved words, there is no concept
of whitespace (except in Hollerith constants) and combinations of
EQUIVALENCE and COMMON have sent many a compiler designer to tipple.
But there are lots of ways to skin the proverbial cat. When I had to
produce an extended BASIC compiler for the 8085 using only a floppy-disk
MDS 800 system, I adopted a technique I learned from an old IBM COMTRAN
compiler guru. Lay out the semantics of your compiler; lexical
elements, their characteristics, etc. and then think of them as tokens
for a hypothetical machine that takes as input lexical elements and
produces some sort of code as output. Initially, my exposure to this
technique was in a COBOL dialect translator--you took more or less
standard COBOL as input and produced bastardized COBOL as output.
You design the instruction set of your hypothetical machine, then either
interpret it or use those instructions to produce macro calls. ASM80 on
ISIS II had a relatively weak macro facility, so we wrote the macro
processor in PL/M. Worked like a charm--in 4 months we had a working
compiler. I still have the design paper that I wrote for it.
For whatever an old man's story is worth...
--Chuck
