Jim has worked solidy on this for the past 4 or 5 weeks, showing great
tenacity and willingness to delve into extraordinary detail to track
down the bugs that prevented the compiler running.
Thanks very much, Jim.
The demo script in the distribution compiles a simple "hello world"
program in Fortran. More complex programs have not been tested to any
great degree, but there does seem to be a problem with reading input
data from tape. Despite that, it's a great step forward in getting
this old software to run again.
Some suggestions for further experimentation:-
* More complex Fortran programs
* Trying to run the COBOL compiler
* Trying run the Assembler (and do a sysgen!)
* Working out how the output listing records are delimited
(select binary mode in the tape viewer to see the raw data)
The source files need some consolidation and cleaning up before
publication, but the executable is available at:-
How about booting CTSS?
Great, I didn't know these were available yet.
I hope someone gives it a shot.
But the 7094 customizations have to be added first...
>Thanks to a huge effort by James Fehlinger, the 7094 emulator can now
>load the Fortran compiler, compile a program, and execute the result.
>Jim has worked solidy on this for the past 4 or 5 weeks, showing great
>tenacity and willingness to delve into extraordinary detail to track
>down the bugs that prevented the compiler running.
>Thanks very much, Jim.
I will join you in giving thanks to him for this amazing accomplishment,
and to the others who worked on that emulator.
As a descendant of the historic IBM 704 Fortran compiler, the efficiency
of which established higher-level languages as a fully viable way of
programming, the compiler in question is of immense historical
Speaking of FORTRAN:
I was recalling an incident that happened about 25 years ago just the
other day in a conversation.
A friend was noting that FORTRAN had some obscure features. What was the
assigned GO TO for, given that the computed GO TO can do everything it
can do, and much more?
I answered that not only did it have a purpose, but I had just written a
program in which I had *used* the assigned GO TO - for its intended
It was a program to draw maps of the world.
(A BASIC program that does the same thing, but with more projections, is
available on my web site; I used it to generate .xbm files which I then
converted to the format used on my pages about world map projections.)
At the beginning, I ask which projection you want, and for other
information. Then I do a _computed_ GO TO to one of several stretches of
code that draw the border of the map, do any required precomputations,
and which also contain an ASSIGN statement.
Then, in the main loop, I read a point from a file, and draw a line to
that point in latitude and longitude as mathematically converted, by the
projection, into X and Y coordinates.
Since I'm going to the _same_ one of several alternatives over and over,
going to the code for the current projection was done by an assigned GO
load register 5 with branch_address
jump to 0(5)
Less overhead than a computed GO_TO, saving cycles.
(One still has to list the possible alternatives at the end of the
statement: I wondered why that was, assuming it was because on some
architectures, an assigned GO TO had to be implemented as a computed
GO_TO, perhaps because addresses were bigger than integers. But now I
realize it is also valuable because it lets the compiler optimize
dusty decks, software history, early fortran ... etc
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
It seems that IBSYS outputs large records consisting of a number of 96
character print lines, whereas the compiler outputs variable length
lines as single records.
BTW: Any tape rive can be displayed in the viewer by clicking its
The emulator now also generates instruction execution stats when
Might be a day or two until I can backtrack my updates and fix it...
>dusty decks, software history, early fortran ... etc
There was some interesting stuff there.
The Fortran II source is at the Smithsonian...
Fortran IV for the 7090 didn't include the advanced optimizations of the
original Fortran - but Fortran II for these computers did.
Also, the location of a paper about the optimizations in the original
>I've obviously buggered up something here, any more than one
>executable statement and the compiler loops.
Fixed now. The way things are currently, the scratch tape files need
to contain something (anything). I was not setting them large enough.
The COBOL compiler also runs, but doesn't seem to execute the result.
Tracing performance is improved with the ability to select the types
of trace entries to be recorded.
Also, just for fun, try checking the "plot" box on the main panel.
will you be updating the src snapshot with the recent changes?
Mais oui. In fact it's up there now.
Under the chaotic (ie. non-existent) change control system Jim and I
were using, some changes I'd come up with didn't make it into the code
that eventually worked. Some of these have now been incorporated, but
not all. There are some improvements and cleanups I still want to do,
but that will take some time, so I've put it up as is.