return to main page

1401 - FORTRAN - Illustrated

Goal: a web page that combines

- the "known" FORTRAN phase descriptions from 1401-IBM-Systems-Journal-FORTRAN.html
- with the disassembled and commented "phases" from Van Snyder, up through rev. v3m4.

Zeroth - Surprise!! - the floating point operations were "interpreted".
from http://en.wikipedia.org/wiki/Fortran

IBM 1401 FORTRAN

FORTRAN was provided for the IBM 1401 by an innovative 63-pass compiler that ran in only 8k of core. It kept the program in memory and loaded overlays that gradually transformed it, in place, into executable form, as described by Haines et al.[5] The executable form was not machine language; rather it was interpreted, anticipating UCSD Pascal P-code by two decades.

Gary Mokotoff [GM] and Van Snyder [VS] state

  • [GM] The compiler DID produce machine language. It converted FORTRAN to 1401 machine language.
    Of course floating point was interpretive. There was no floating point hardware. :>)
  • [VS] Only the floating-point calculations were interpreted "byte codes". The interpreter is phase 63.
    - There's a listing for it at the bottom of this page.
    The alternative was to emit calls to individual floating-point routines.
    The byte code is more compact (by about three characters per operation).
    For a = b * c it would be something like
    b arith
    dcw @*@
    dc b
    dc c
    dcw @=@
    dc a
    
    instead of
    
    b ffmult
    dcw b
    dcw c
    b fstore
    dcw a
    It's not much of a performance hit: Interpreting it is much less work than actually doing the arithmetic.
  • [VS] The compiler fits in 4k, but that doesn't leave any room for the program )-|
  • [VS] If you wish to run a version of 1401 FORTRAN on a PC in 1401 emulation mode click here 1401-FORTRAN-SIMH.
  • [VS] For running on a 1401 using mag tape emulator, the longest record on the compiler tape is less than 2300 characters, so it should be possible to run them through the 1401 magnetic tape emulator. The files are v3m0.simh.mt1 and v3m4.simh.mt1

First, a little fun ;-)) Early March 2011
from David Macklin
Ron, [Ron Mak, Prof. Comp. Science, San Jose State]
I would add an amusing point:

During development and testing, during which source programs were small, we were running on a 4k byte machine.

David Macklin


from Robert Garner
Amazing!

Do you recall any other interesting anecdotes about your minimal-footprint compiler? Funny bugs? Interesting problems you had to solve?

What was the design process like? Fortran had just come out.
Did you grumble about any language specification holes?

Why 63 passes, and not 64, or 127 ? ;-)
It was not planned to have precisely 63 passes. A new pass would be defined when the space constraints so dictated. In fact, the ability to do so is the principal benefit of the serial compiling process.

David

How did you respond to folks that say it was too slow?
Honestly, no one ever said that. It was a 'fait accompli'.

D

- Robert


Alan Kay added
I meant the compiling part heh heh! (although we had the luxury of an 8K machine in ATC so we could work with larger programs)

I seem to recall an Algol compiler described by Woodger (?) in one of the first Annual Reviews of Automatic Programming that ran on a tiny British machine that only had a few hundred words of memory (on a drum), and this took more than 100 passes to compile. The paper was extremely well written and gave a good picture of how the programmer went about dividing up the passes....

Cheers,

Alan

and
I remember the FORTRAN compiler well .... it was .... somewhere between "glacial" and "majestic" (history should bestow the latter pace to it!)

Cheers,

Alan
Hardly 'glacial'. The object program, already being in core, was instantly ready to run.

David

Gary Mokotoff mentions
When I left IBM in 1968, I took with me printouts of the source code of 1401 SPS-1, SPS-2, Autocoder and FORTRAN. ...

... I gave them to the Charles Babbage Institute at the University of Minnesota. You can see the description at http://discover.lib.umn.edu/cgi/f/findaid/findaid-idx?c=umfa;cc=umfa;rgn=main;view=text;didno=cbi00093


Local copy of CBI page at MokotoffGary2CBabbageInstitute.html

Back to business ;-))

The phases (overlays) below illustrates the efforts and complexities faced (in the goode olde dayze) when memory was not essentially free and infinite. This compiler worked in a computer of 8,000 characters of memory, not 1,000,000 bytes (characters) of memory. Overlaying meant that when one "phase" was completed, another "phase" was loaded into the same place in memory, with links to common data and variables precomputed. To do the above, sucessfully, required real attention to detail !!

The code in this page was sent by Van Snyder, April 18, 2004 - in a main (mokotoff-9.zip) and an update (mokotoff-9-v3m4.zip). I merged the files, replacing the updated files. Van Snyder and David Macklin have been working on this disassembly.

Table of Contents, Links to Phases (Overlays)
  • 00, - Snapshot.
  • 01, - System Monitor. Brings in the next phase from ...
  • 02, - Loader. Stores the entire source program ...
  • 03, - Scanner. Determines the type of each statement ...
  • 04, - Sort one phase. Determines if there is enough free storage to ...
  • 05, - Sort two phase. Statements of the same type are chained together.
  • 06, - Sort three phase. The source program is sorted internally by statement type.
  • 07, - Insert group-mark phase
  • 08, - Squeeze phase
  • 09, - Dimension phase one

  • 10, - Equivalence phase one
  • 11, - Equivalence phase two
  • 12, - Dimension phase two
  • 13, - Variable Phase One
  • 14, - Variable Phase Two
  • 15, - Variables Phase 3
  • 16, - Variables Phase 4
  • 17, - Variables Phase 5
  • 18, - Constants Phase One
  • 19, - Constants Phase Two

  • 20, - Subscripts Phase
  • 21, - Statement Numbers Phase
  • 22, - Statement Numbers Phase
  • 23, - TAMROF Phase One
  • 24, - TAMROF Phase Two
  • 25, - List Phase One
  • 26, - List Phase Two
  • 27, - List Phase Three
  • 28, - Stmt Numbers Two
  • 29, - Stmt Numbers Three
  • 30, - Stmt Numbers Four
  • 31, - Stmt Numbers Five
  • 32, - Input/Output One
  • 33, - Arith Phase One
  • 34, - Arith Phase Two
  • 35, - Arith Phase Three
  • 36, - Arith Phase Four
  • 37, - Arith Phase Five
  • 38, - Arith Phase Six
  • 39, - I/O Phase Two

  • 40, - Computed GOTO Phase
  • 41, - GOTO Phase
  • 42, - STOP/PAUSE Phase
  • 43, - Sense light Phase
  • 44, - IF Cond Phase
  • 45, - Continue Phase
  • 46, - DO Phase
  • 47, - Resort 1 Phase
  • 48, - Resort 2 Phase
  • 49, - Resort 3 Phase

  • 50, - Resort 4, phase 50A & 50B
  • 51, - Replace phase one
  • 52, - Load - phase 52A, B, C
  • 53, "Relocatable Package - Reloading Snapshot - Snapshot
  • 54, - Format loader 54A, 54B, 54C, 54D
  • 55, - Replace phase 2
  • 56, - Snapshot phase
  • 57, - Condensed deck phase one,
  • 58, - Condensed deck phase 2,
  • 59, ???

  • 60, - Condensed deck phase 3,
  • 61, - GEAUX phase one
  • 62, - GEAUX phase 2
  • 63, - Arithmetic package

The principal function of each phase of the compiler is indicated below. Secondary functions are subordinated; for example, error checking occurs in almost every phase, but is seldom mentioned.