Early Programming Books

ben bfranchuk at jetnet.ab.ca
Mon Jun 21 03:39:42 CDT 2021


On 2021-06-21 12:06 a.m., Chuck Guzis via cctalk wrote:
> 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.

I have 'borrowed' copy of the Green dragon book.
The book promotes code generation for a multi register machine. PDP 11,
PDP 10, IBM 360. "(C) Bell Labs 1979 " I think is big hint here.

The machine model I am looking at is a single accumulator design like 
the 6800 or the IBM 1130. A AC,PC,Index and stack. No push or pop, 
subroutine call returns the old pc in the AC.


> 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.

Is Fortran the newer version of FORTRAN ( I II IV )?


> 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

There is very little to to bootstrap with today, that uses a small 
amount of memory.I need a cross compiler for my machine like K&R C
style compiler ,not the latest C+-#@? compiler.
I have no problem with a recursive decent compiler,I just have subtract
divide and mod reversed in places, something I want to avoid as well a
DISPLAY's like in Algol or Pascal.


> 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.

The machine works on FPGA delopment card, see the bliking lights on the
kitchen table. No hypothetical here.

1) Computer     Check
2) Front panel  Check
3) Bootstrap  loader Check
4) Software     No Check
Stage 4 is the problem.


> For whatever an old man's story is worth...
> 
> --Chuck
Thanks.
Ben.





More information about the cctalk mailing list