IBM 7094 Emulator now runs Fortran compiler

130 views
Skip to first unread message

Rob Storey

unread,
Sep 9, 2004, 6:49:27 PM9/9/04
to
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.

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

http://members.optushome.com.au/intaemul/Emul7094.htm

Rob Storey

Leif Harcke

unread,
Sep 9, 2004, 7:52:53 PM9/9/04
to
On Fri, 10 Sep 2004 08:49:27 +1000, Rob Storey wrote:
> Some suggestions for further experimentation:-
[snip]

How about booting CTSS?

http://www.piercefuller.com/library/ctss.html?id=ctss

-Leif

Rob Storey

unread,
Sep 10, 2004, 3:09:22 AM9/10/04
to
On Thu, 09 Sep 2004 16:52:53 -0700, Leif Harcke <lha...@stanford.edu>
wrote:

Hi Leif,

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

Rob Storey


John Savard

unread,
Sep 10, 2004, 12:06:53 PM9/10/04
to
On Fri, 10 Sep 2004 08:49:27 +1000, Rob Storey
<inta...@optushome.com.au> wrote, in part:

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

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

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

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

John Savard
http://home.ecn.ab.ca/~jsavard/index.html

Anne & Lynn Wheeler

unread,
Sep 10, 2004, 12:24:06 PM9/10/04
to
jsa...@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
> 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?


dusty decks, software history, early fortran ... etc
http://www.mcjones.org/dustydecks/archives/category/software-history/


--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Rob Storey

unread,
Sep 10, 2004, 8:00:09 PM9/10/04
to
The tape viewer has been improved, the listing is now much
"straighter".

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

The emulator now also generates instruction execution stats when
shutdown.

http://members.optushome.com.au/intaemul/Emul7094.htm

Rob Storey

Rob Storey

unread,
Sep 11, 2004, 3:42:00 AM9/11/04
to

I've obviously buggered up something here, any more than one
executable statement and the compiler loops.

Might be a day or two until I can backtrack my updates and fix it...

>Rob Storey

John Savard

unread,
Sep 11, 2004, 3:32:52 PM9/11/04
to
On Fri, 10 Sep 2004 10:24:06 -0600, Anne & Lynn Wheeler
<ly...@garlic.com> wrote, in part:

>dusty decks, software history, early fortran ... etc
>http://www.mcjones.org/dustydecks/archives/category/software-history/

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

John Savard
http://home.ecn.ab.ca/~jsavard/index.html

Rob Storey

unread,
Sep 16, 2004, 2:36:38 AM9/16/04
to
On Sat, 11 Sep 2004 17:42:00 +1000, Rob Storey
<inta...@optushome.com.au> wrote:

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

Rob Storey

Al Kossow

unread,
Sep 16, 2004, 1:19:23 PM9/16/04
to
From article <0jk2k0lrbs8vi9ovm...@4ax.com>, by Rob Storey <inta...@optushome.com.au>:

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

will you be updating the src snapshot with the recent changes?

Rob Storey

unread,
Sep 17, 2004, 10:39:04 PM9/17/04
to
>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.

http://members.optushome.com.au/intaemul/Emul7094.htm

Rob Storey

Reply all
Reply to author
Forward
0 new messages