Discussions‎ > ‎

MAD, MAD/I, GOM, CTSS, UMES, MAD Magazine, and Brian Kernighan

This item goes back to pre-MTS time, but I wanted to save this information somewhere and this seemed like as good a place as any.
There is information about 7090 MAD, as well as MAD/I and GOM under MTS on S/360 and S/370 mainframes available on Wikipedia at:


Mike found the following note about the 7090 retro-computing  effort:


It appears that there is a 709/7090/7094 simulator on which you can run IBSYS and CTSS. Among other things CTSS includes a copy of the MAD compiler.

4. MAD, CTSS, and Brian Kernighan

posted Nov 19, 2010, 7:11 PM by Jeff Ogden

The following is an interesting quote from An Interview with Brian Kernighan: Breeding Little Languages, by Allen Noren (2009) when he was asked "What hooked you on programming?":

I think that the most fun I had programming was a summer job at Project MAC at MIT in the summer of 1966, where I worked on a program that created a job tape for the brand new GE 645 in the earliest days of Multics. I was writing in MAD, which was much easier and more pleasant than the FORTRAN and COBOL that I had written earlier, and I was using CTSS, the first time-sharing system, which was infinitely easier and more pleasant than punch cards.

3. MAD, CTSS, and UMES: Some recollections from Andy Goodrich and Mike Alexander

posted Nov 19, 2010, 6:31 PM by Jeff Ogden   [ updated Dec 25, 2011, 9:40 PM ]

What parts of CTSS (MIT's Compatiable Timesharing System for the IBM 7090) were written in MAD?

On Jul 6, 2010, at 10:57 AM, Andy Goodrich wrote: CTSS stuff referencing MAD:




CTSS listing and tapes on line:


I pulled the tape listings and looked through all the code, here is where MAD programs get used directly:

com1 - ARCHIV command -
com2 - FIB command - enter user's job in FIB job file.
com3 - MAD compiler
com4 - debugger (MADBUG) -  add comment to output list, add variable to output list
                           put BCD arguments in.
                           convert statement labels
                           boolean mode8
                           insert break points in user core
                           set first location in break block
                           get card image
                           .  .  .
com5 - MAIL command
disked - disk editor
fgadaem - daemon dump/load program
fsetup - compatibility package for pseudo i/o system including DDMAD package
        to simulate disk i/o
plibe - graphics package


And on Jul 6, 2010, at 11:55 AM, Andy Goodrich wrote:

Forgot some:

salall - dump / load programs
salsim - disk i/o simulation program
util - various utilities: algol listing printer, ALSTAT to summarize disk usage for use with FSTAT command
xlibe - various MAD utilities.


Was UMES written in MAD?

UMES is the University of Michigan Executive System, an operating system or really a batch monitor for the IBM 704, 709, and 7090 computers.

On Jul 30, 2010, at 6:41 PM, Andy Goodrich wrote:

As I remember most of UMES that I dealt with was written in 7090 assembler.


Mike Alexander agrees with Andy

On Jul 30, 2010, at 8:13 PM, Mike Alexander wrote:

Very little if any of it was written in MAD.  It was mostly or entirely written in assembly language.

2. MAD, MAD Magazine, and GOM: Don Boettner's and Bruce Arden's recollections

posted Nov 19, 2010, 6:06 PM by Jeff Ogden   [ updated Nov 19, 2010, 6:52 PM ]

On Jul 13, 2010, at 9:37 PM, Donald Boettner wrote:

1. GOM - I have a printed copy of the GOM Manual.  I also think I have it on a CD of saved stuff.  I will look.

2. I think $message was the only thing written in GOM.   When I wrote the command macro processor, I wrote a prototype in SNOBOL (actually SPITBOL) and then did the final version in PLUS.

3.  I just located in my archives a computer output listing dated 06 May 1960 under id R02DN (my course id for Bernie's course) which is a failed compilation and so has the Alfie picture.  (and I have a couple other Alfie ones)   This is a little large for my scanner.  I might try photographing it first and seeing if I can get sufficient detail and contrast that way.

4. Some words on the reason for Alfie and his subsequent disappearance in later years;   Bruce Arden would know better if I have some of the things mixed up:

MAD was written for an IBM 704 computer with 8192 words (36 bit) of main memory and 8192 words of high-speed drum storage.   It was written as a three-pass compiler.  Part I (Bob Graham) did the lexical scanning and generated the triples (DSCAN and CMPMTX for those who remember) and wrote the triples on an intermediate tape and any symbols encountered on the drum.  Part II (Bernie Galler) read in  the symbols from the drum, condensed the table and assigned addresses.  Part III (Bruce Arden) read in the triples from the intermediate tape and using the condensed symbol tape, generated the binary executable.

Most errors were caught in Part I, but there was not enough room for the compiler code and the full text of the error messages.  So Part I was actually in two core loads on the system tape:  the first did the compilation and if it  found an error, it put in a flag and an error number:
   ***************************** ERROR NR.      05172
after the offending source statement.  Then at the end of that phase, if it had detected errors, it read in the next core load which printed a page with Alfie at the top and the text of the error messages:
 (if no errors were detected in Part I, the second core load was skipped and control passed to the next core load which was Part II.)

When the 7090 was installed, it had 32768 words of main memory, and so this indirection was no longer necessary, and MAD was changed so the full text of the error messages was printed following the offending statement.  So there was no reason for the A.E.Neuman picture any more.

I will let you know later about the GOM Manual and the Alfie scan.


MAD Manuals

There are a number of MAD, MAD/I, and GOM manuals available on the Web, see the Reference section of the Wikipedia article on "MAD, MAD/I, and GOM".

Alfie: A portrait of Alfred E. Neuman as produced by the MAD Compiler in 1960

Don did scan his c. 1960 Alfie printout. Here is the result, which is included in the Wikipedia article on MAD:


Bruce Arden remembers a bit about Alfie too:

On Jul 12, 2010, at 11:24 AM, Bruce Arden wrote:


 . . .

I sent the request to MAD magazine for the use of their title, including the title font with the satyrs pursuing the buxom bacchantes. This was used for a while before it was changed due to someone's complaint about propriety. There was also a typo that raised hackles later. I received MAD's approving response and must have it somewhere unless it was a casualty of some move.


1. Origins of MAD: the Recollections of Bruce Arden and Bernie Galler

posted Nov 19, 2010, 2:17 PM by Jeff Ogden   [ updated Dec 25, 2011, 9:57 PM ]

Bruce Arden, Bob Graham, and Bernie Galler are the original authors of 7090 MAD.

Bruce Arden's recollections

From: Bruce Arden
Date: July 12, 2010 11:24:02 AM EDT
To: Jeff Ogden
Subject: Re: Wikipedia about the MAD language updated


When I get back to Ann Arbor I can probably add some more history. MAD was an important step in the evolution of compilers and it let Michigan become a leader in the academic use of computers. The Ford Foundation program to educate many university engineering professors from elsewhere was a great success. It depended on MAD. It had its origin on the IBM 650, a computer that was adopted by many, if not most, universities. Bob Graham and I wrote GAT for the 650 and it replaced the only competitor IT.  IT,  the perfect acronym, was written by  Perlis, Cheatham, and Smith who were then at Purdue and later at Carnegie-Mellon. FORTRAN was much too large and too much of a kludge to fit on a 2000 word 650. The GAT algorithm was the nucleus of MAD. There's more to the story. Later.


From: Bruce Arden
Date: August 26, 2010 12:57:07 PM EDT
To: Jeff Ogden
Subject: MAD history

In your pursuit of history you have no doubt found that MAD was an implementation of ALGOL 58. It was a demanding task. No European groups and only two other US organizations completed it: NELIAC (from the Naval Electronics Laboratory) and JOVIAL (Jules own version of the international algebraic language by the Rand Corporation). The Europeans were major supporters of this "standard." By the time Bob Graham, Bernie, and I finished it the Europeans (mostly the Germans) had decided that they wanted something simpler and called it ALGOL 60. The three completed programs would be scrapped and started over. Not surprisingly, the three organizations declined the honor.

Bob Graham and I became UM's first professional programmers, called Research Associates, when the IBM 650 arrived at the Statistical Research Laboratory. Bob left for MIT in late 1963. Apparently MAD was used to some extent in the programming of CTSS.


From: Bruce Arden
Date: August 28, 2010 11:12:30 AM EDT
To: Jeff Ogden
Subject: Re: MAD history


Sure, I see no reason for excluding memoirs. Obviously, such recollections by two different participants may not agree.

Regarding Jean Sammet [the comment "While MAD was motivated by ALGOL 58, it does not resemble ALGOL 58 in any significant way" appears on page 205 of Jean Sammet's 1969 book Programming Languages: History and Fundamentals], she may have conflated the two version[s] of IAL (58 and 60). Unlike the later version, the 58 version said nothing about what words (or language) should be used to identify conditional and transfer statements, which led for parsing reasons to words like WHENEVER. Also there were some additional features in MAD that went beyond the 58 specs. Since any symbol could be an array element, it was possible to do an indexed transfer to statements and subroutines. That was before program readability became important.

I don't know where MAD history begins. For me it was when Bob and I programmed GAT (Gaham/Arden Translator or Generalized Algebraic Translator for the world). It was, I think, the first instance of operator precedence parsing. GAT replaced IT and FORTRANSIT (Perlis et al.) in most of the university 650s -- including Perlis' at Carnegie Mellon.  We thought the really big contribution was fitting it in 2000 words of memory.


A portion of An Interview with Bernard A. Galler

From An Interview with Bernard A. Galler, Charles Babbage Institute, Center for the History of Information Processing, University of Minnesota, Minneapolis, 1991, OH 236, pages 18-22:

Maybe I should talk a little about the history of MAD, along this period [1960 to 1965], because MAD was one of
our major activities at the [UM] Computing Center.

It goes back to the 650, when I mentioned that we had the IT compiler from Al Perlis. IT, because of its constraints,
mainly the size of storage, and the fact that there were no index registers on the machine, had to have some severe
limitations on what could be expressed in the language. And Arden and Graham decided to take advantage of index
registers when we got them on the hardware and also to ... we began to understand compilers a little better, and they
decided to generalize the language a little bit, and so they wrote the compiler called GAT, the Generalized Algebraic
Translator, which Perlis then took; by that time he had gone to Carnegie-Mellon ... it may have been Carnegie at the
time. Perlis took GAT and added some things to it to call it GATE - GAT Extended - and he went on to add a few
things to it in that direction.

GAT was not used very long at Michigan. It was okay, but there was another development, because in 1958, there
was the ALGOL development in the European-American cooperation between ACM and the European group, and
they announced a standard language called ... well, first it was IAL, the International Algebraic Language, but they
changed the name to ALGOL, Algorithmic Language, ALGOL 58. They published a description of the language, and
said, "Please everybody, implement this, let's find out what's wrong with it. In two years we'll meet again and make
corrections to the language," in the hope of getting everybody to use this one wonderful language universally
instead of the several hundred which were already developing all over the world. Everybody was doing his own
thing; there was an issue of the ACM where the cover showed a Tower of Babel with all the different languages on it,
and so on. So the attempt was to try to get a universal language. John Carr was very active in this process, and he
came back to Michigan and said, "We've got to do an ALGOL 58. To help the process, let's find out what's wrong
with the language. We know how to write language compilers, we've already worked with IT, we've done GAT, and
so on. Let's see if we can help." So we decided - I was involved, and Arden and Graham, and John Carr a little bit,
but he never really was very involved. He left in 1959. We decided to do an ALGOL 58 compiler. It turned out that
there were some things wrong with the ALGOL 58 language specification. There were some things that were very
difficult to do, very foolish inclusions and so on, and when you actually write a compiler, you discover that you have
to make a number of decisions, and so by the time we designed the language that we thought would be worth doing,
and we could do a compiler for, we said we couldn't call it ALGOL any more; it really was different. What should we
call it? And so that's when we adopted the name MAD, for the Michigan Algorithm Decoder, and we had some
funny interaction with the Mad Magazine people, who finally gave us permission, in a very funny letter, which told
us that they would take us to court and everything else, but had a P.S. at the bottom - "Sure, go ahead."
Unfortunately, that letter was lost. But we decided to write a compiler, and at first it was Arden and Graham who did
all of this. I was helping, watching and so forth, but it was mainly their work because they had worked on GAT
together. And then at some point I said, "I want to take over part of this thing, too, and really join the group." And
they said fine. Arden was doing the back end of the compiler, Graham was doing the front end of the compiler. We
needed someone to do the middle part which would glue the pieces together and make everything flow and provide
all the tables and so on, and I said, "Fine. That's my part." So Graham did Part I, Galler did Part II, and Arden did Part

A few years later when Bob Graham left and went to the University of Massachusetts where he is now, I took over
Part I. So I had Parts I and II, and Arden had III, and we kept on that way. I was very glad that Graham had
developed some very powerful macros in Part I which made my job a lot simpler, and for which I want to absolutely
give Bob credit for doing a good job.

So we did the MAD compiler in 1959 and 1960, and I think it was 1960 when we went to that famous SHARE meeting
and announced that we had a compiler that was in many ways better and faster than FORTRAN. It was a better
language, and so on. There are people who still come up to me and tell me they rememb er my standing up at that
meeting and saying at one of the FORTRAN discussions, "This is all unnecessary, what you're doing here, because
you've got to come to our session where we talk about MAD and you'll see why." And people remember that,
because it was true. I remember one ...

E. GALLER: Did they think that you were being very ...

B. GALLER: Brash?

E. GALLER: ... brash, because you were so young?

B. GALLER: Of course, and well, who would challenge IBM? But okay. I remember one time, a little bit later, we had
a visit from a guy from IBM at Michigan. He came to Ann Arbor, and we went to lunch, and he was telling us that
they were so excited; they had discovered how to have the computer do some useful work during the 20-second
rewind of the tape in the middle of the FORTRAN translation process, and we sort of smiled. And he said, "Why are
you smiling?" And we said, "That's sort of funny, because the whole MAD translation takes one second." And
here he was trying to find something useful to do during the 20-second rewind in the middle of their whole
FORTRAN processor.

What happened in developing MAD that was important was that we were able to get the source listings for
FORTRAN on the 704, and Bob Graham studied those listings as to how they used the computer. The 704 computer,
at that time, had 4,000 words of core storage and, I think, 8,000 words of drum storage. And the way the IBM people
overcame the small core storage, the 4,000 words, was to store their tables on the drum. And they did a lot of table
look-up on the drum, recognizing one word for each revolution of the drum, and if that wasn't the word they wanted,
then they'd wait until it came around, and they'd look at the next word. Graham recognized this and said, "That's one
of the main reasons they're slow, because there is a lot of table look-up stuff in a compiler. You look up the symbols,
you look up the addresses, you look up the types of variables, and so on." So we said: "Fine. The way to organize a
compiler then is to use the drum, but to use it the way drums ought to be used. That is, you put stuff out there for
temporary storage, and you bring it back once and you use it again when you need it." And so we developed all of
our tables in core; when they overflowed we stored them out on the drum. That is, Part I did all of that. Part III, then,
would call in the relevant table when it needed it and use it. We did no look-up on the drum, and we were able to do
the entire translation in under a second. It was because of that that MIT, when they developed their time-sharing
system, which they called CTSS, the Compatible Time-Sharing System, and they needed a fast compiler for student
use, used MAD, and it was their in-core translator for many years. So we developed, then, MAD in 1959, 1960. It
really got finally working in 1961. In January ... well, February, I guess, 1961, we went to New York. Our 709 had
arrived, or was about to arrive. We went to New York, the three of us, in the middle of that big snowstorm, to debug
the new MAD version, the 709 version of MAD. And we were using the Socony Mobil 709 at night after they used it
in the daytime. So we would sleep most of the day and work at night. And we got the 709 version of MAD
debugged, so that when our machine arrived, we were able to use it. Our campus used MAD until the middle of 1965,
when the 7090 computer, which we had by that time, left. I think during the last four years of its life, we found no
additional bugs; it was a very good compiler. And the important thing about it, of course, was that we had a number
of language innovations, and notational innovations which were, some of them, picked up by the FORTRAN group
to put into FORTRAN IV and its successors later on. They never really advertised the fact that they got ideas and in
effect got some important notation from MAD, but they told me that privately.

So MAD was very important. We published a number of papers. One important thing we did was we had a language
definition facility. Now people refer to it as an extensible language facility. It was useful and important, and it worked
from 1961 on, but somehow we didn't appreciate how important it was, so we didn't really publish anything about it
until about 1969. And I was later lectured to by John Reynolds - I think he was at Argonne, an important language
guy - who told me that we were very derelict in not publishing it sooner because it was so important, and the world
should have known about it sooner. Well, in hindsight, yes. There is a lot of work in extensible languages now, and
unfortunately, not a lot of people credit the work we did, partly because we didn't publish it for so long, and while
people knew about it and built on it, there was no paper they could cite.

So we think the work on MAD was very important, and the work on the operating system stuff was important. That
was the foundation of Michigan's Computing Center activity.

Bruce Arden recalls a week of nights in NYC debugging MAD

From: Bruce Arden
Date: July 6, 2010 2:30:50 PM EDT
To: Mike Alexander
Cc: Jeff Ogden, Scott Gerstenberger
Subject: Re: another memory test

 . . .

Bernie, Bob Graham and I spent a week of nights using the 7090 in NYC at the TIME/LIFE building debugging in anticipation of the arrival of the 7090. We learned how programming ability decays when severe fatigue sets in.


1-4 of 4