Burroughs 205
Programming Languages

 

At the time the Datatron was being designed and built in 1951-54, programming languages were in their earliest stages of development.  As the Datatron was deployed in commercial and government installations during 1954-60, higher level language development was well under way.  Both the makers and users of this computer were active participants in the language development arena.  Below are a few examples of programming languages used on the Datatron.

Machine Language

This was the language that every Datatron programmer knew and utilized.  Talk to an old-timer and they can probably still tell you three or four Burroughs 205 instruction codes right off the top of their heads.  Programs were sequences of eleven-digit numbers that looked like this:

00000646000
00000746001
00000126002
00000080000

Just so we didn't go nuts, we would usually write the programs on a coding form that broke up the eleven digits up into smaller parts and occasionally even add a cryptic note or two about what we were doing.

Location Sign Control Digits Command Address Notes
7000 0 0000 64 6000 Clear the A Register, add the contents of memory location 6000 (Subtotal)
7001 0 0000 74 6001 Add the contents of memory location 6001 to the A Register (Sales Tax)
7002 0 0000 12 6002 Store the contents of the A Register in location 6002 (Total Bill)
7003 0 0000 08 0000 Stop

 

The Star 0 Assembler

Initially begun by Electrodata, the Star 0 Assembler was the official Burroughs assembler for the 205.  I have no information about it beyond the publication title at this reference and a mention in Waychoff's article about Algol/Fortran compilers referenced below.  I suspect that it was quickly supplanted by the Shell Assembler.

The Shell Assembler

Serious business programming that I was familiar with was accomplished using the Shell Assembler for the Burroughs 205.  This was actually a customer-developed product originating at the Shell Development Company, Exploration and Production Research Division, in Houston.  It was produced by Joel C. Erdwinn, G. Clark Oliphint, C. M. Pearcy and David M. Dahm.  Erdwinn, Oliphint and Dahm went on to join Burroughs.  They were known as the arthropods (shell fish) and later played a significant role in the development of the Burroughs 5000.

    (Click on any picture to enlarge)
Two pale green manuals with 156 total pages supplied the documentation for the assembler.  Actual explanation, definitions and examples were covered in the first 21 pages of the first manual.  The remainder of the books included flow charts of the assembler and program listings for it.  This was a two-pass assembler, although they were called two "movements" in the documentation.

It was a remarkably sophisticated piece of software for its time, including macro instructions, symbolic addresses and, thank heavens, a format band generator for the Cardatron System.  A nifty feature was "program point" addressing that allowed you to use the symbolic addresses ".A", ".B", ... ".Z"  multiple times in the Location field and then reference them, for example, as "CAD +A" or " ST -B" meaning the next ".A" or the previous ".B"


The University of Portland's administrative systems were written in the Shell Assembler and, I believe, many of Pacific Power and Light's applications were also.

Datacode I

The Paoli branch of Burroughs (This was the locations of Burroughs other computer efforts, initially the E101) also produced a programming language for the Datatron under the direction of Saul Rosen, head of the Applied Mathematics Department.     (Editorial:  That last link I gave you leads to one of the many interesting and personal accounts of the early days in computing.  It is locked away behind the IEEE "buy this article for $29" policy.  Both the IEEE and the ACM have a truly shameful policy of restricting access to historical accounts in this fashion.  I hope that their members will lobby their organizations to reconsider the fees that are charged for access to historically significant but technically obsolete material!)  Rosen, of course, went on to head the Purdue University Computer Center and to write extensively on computer languages.


Datacode operated with all numeric input and simulated a three address machine with nine index registers.  A number of mathematical subroutines were available.  For a non-Cardatron system with Floating Point capability, this language would probably be very effective for engineers and mathematicians.  I personally never saw it in operation.  Here is a sample program to invert 10x10 matrices.

 

Algol 58

By the late 1950s, higher level languages were being developed at a fast pace.  After IBM brought IT (Internal Translator) to their model 650 drum machine, they took another step bringing a subset of Fortran called Fortransit to that machine.  In spite of a laborious compilation process: Fortransit source to IT source to SOAP source to machine code - IBM could claim they had Fortran on the 650.  Burroughs needed a competitive response.  Since the 205 was near the end of its life and all software resources were dedicated to the new 220, they hired young student, Donald Knuth, to write an ALGOL compiler for the 205 over the summer of 1960.  Knuth recalls driving out to Pasadena from Case Institute in an interview recorded at the Computer History Museum.  (Video version at this link.)  He drove a hundred miles a day and wrote code for the rest of the day in motel rooms.  A few highlights of that summer are recalled with more color by Richard Waychoff in this 1979 paper.  For the sum of $5,500 Burroughs now had an ALGOL 58 compiler for the Datatron.

It wasn't great.  We taught the language as "Advanced Computer Programming" at the University of Portland in the mid 1960s.  The compiler was S-L-O-W.  Waychoff's memory and mine diverge seriously at this point.  He claims a compile speed of 45 cards per minute.  My recollection is more like 45 seconds per card.  And to describe the diagnostics as "cryptic" was very generous.  When the compiler encountered an error, it simply stopped.  

The "08" Stop command presented a four digit code to the operator and this handy table was your guide to the problem.  A lot of careful desk-checking was the best defense.  Still, it was a remarkable implementation of a pretty decent higher level language.  Here are a couple of sample programs:
 

These examples come from the Programmer's Manual, Bulletin 3041 dated February, 1961, Minor Revision of December 1960 edition.  The two errors that I noted back in 1965 on the left example give credence to Waychoff's description of the writing of the manual.  I suppose that I should have been entitled to two dollars from Knuth for finding these but I was unaware of his standing offer until relatively recently.  

It is worth mentioning that the Burroughs 220 Algol compiler (sometimes known as BALGOL) has been preserved in source code form at bitsavers.  The program listing there is dated May 1, 1961 and includes the names of both J. Erdwinn, mentioned previously with the Shell Assembler and Knuth.  I assume there is a lot in common between the two compilers.  For anyone interested in understanding the two compilers Knuth has published a flowchart of Runcible, their ancestor program for the IBM 650.  

Keep in mind that the compiler fit into a bit over 3000 words, used no overlays and did all of its work in a single pass.  Addresses were cleverly resolved by its program loader.

Update:
Don Knuth donated an assembly language listing of the B205 compiler along with lengthy documentation of the program to the Computer Museum in Mountain View, CA.  The documentaion, with numerous flowcharts is titled: THE INTERNALS OF ALGOL 205.  It begins, "How does this compiler work?  Frankly, it's a miracle if it does."  Both of these listings are lengthy PDF files.  Follow this link to see the directory listing for Knuth's files.   

Fortocom

Meanwhile, the Burroughs sales force had another opportunity.  If the 205 could be coaxed to compile IBM 650 Fortransit programs - and compile them faster and execute them faster than a 650, Phillips Petroleum would buy a system.  Lloyd Turner and Richard Waychoff from the Dallas sales office received a one-day class in compiler writing from Bob Barton of Pasadena.  Waychoff narrates the rest of the tale here.  Like the Algol 58 compiler, the Fortocom compiler was released in 1960.  And, o yes, Phillips Petroleum installed a 205 in Sweeny, Texas in October of the same year.  We had a copy of the Fortocom compiler and a manual at the U of P but no one ever succeeded in making it run.


Dumbo

Babcock and Wilcox in Lynchburg Virginia bought a 205 in 1954 for their Atomic Energy Division. Bob Kubic worked there as a programmer and wrote a compiler for it called "Dumbo". The Dumbo language was used by "open shop" programmers - in part to familiarize them with the computer, but also for another way to get something done when the professional programmers were busy.

The Machine Language Interpreter

This was not really a programming language but an "operating system" for the Datatron.  All engineering students were required to take an "introduction to computer programming" at the University of Portland.  Since they were writing in machine language, mistakes were common, especially in the first few weeks of the semester.  Illegal command codes, overflow halts and similar problems plagued the runs of new programs.  I built a program that simulated the Datatron on itself but trapped all of the common errors.  It was slow-running, but if the program executed one hundred instructions successfully, it exited the simulator and ran its course at full speed.  Only a few percent made it to that point.  The overall boost in throughput in the data center was considerable.  A stack of student programs could be placed in the card reader and left to run unattended.  One key to the system was the "Automatic Rollback" switch at the engineer's control panel.  When activated, "Rollback" would initiate a paper tape read a few seconds after the machine halted for any reason.