CAL TSS was a timesharing system that ran on a CDC 6400 with Extended Core Storage (ECS) and Central Exchange Jump (most of the system ran on the CPU) written at the University of California, Berkeley between 1968 and 1971. After funding ran out, development ceased and the system ran until about May 1972, when the hardware was sold.
Butler Lampson and Howard Sturgis wrote a nice SOSP paper [1] about the exotic design (capabilities; multiple protection domains within a process) and how it worked out technically. About a year ago Dave Redell and I (who both worked on the system) decided to explore how the project came to be. After research at Berkeley’s Bancroft Library, interviewing the surviving project members, and studying the project archives [2], we wrote a paper [3] discussing the origin of the project, the people involved, development of the software, and the brief experience using the system before it was shut down. Comments on the paper are welcome.
The current state of the system is that a very poor job of archiving the source code, boot tapes, etc. was done at the time. Through heroic efforts Terry Heidelberg has managed to boot several versions of our system. However so many things are missing that it seems unlikely this will ever become an interesting emulation environment.
The archives (which have just been accepted by the Computer History Museum) include several hundred documents, a fairly complete set of listings, and machine-readable source code for the kernel layer (recovered by Terry); all this is online.
Butler W. Lampson and Howard E. Sturgis. Reflections on an operating system design. Communications of the ACM, 19(5):251-265, January 1976. https://dl.acm.org/doi/10.1145/360051.360074 (open access)
It was sad that our project would not continue. Personally, I received my bachelors in December 1971, so it felt natural to move on. Many of our group stayed in touch (see Photos, esp. 1974 and 1980).
Alan’s 1993 HOPL II paper [1] cited Butler Lampson’s 1969 paper on CAL TSS [2], which contains an excellent description of the kernel layer (we called it the ECS system), and how its extension mechanisms would be used to build the rest of the system.
[1] Alan C. Kay. 1996. The early history of Smalltalk. History of programming languages—II. Association for Computing Machinery, New York, NY, USA, 511–598. https://doi.org/10.1145/234286.1057828 (open access)
[2] Butler W. Lampson. On reliable and extendible operating systems. In Proceedings 2nd NATO Conference on Techniques in Software Engineering , Rome, September 1969. Reprinted in The Fourth Generation , State of the Art Report Number 1, pages 421-444. Infotech, 1971. Online at bwlampson.site / 71-reliable-os-Infotech-bwl Also appeared as:
Butler Lampson. “An Overview of the CAL Time-Sharing System.” October 10, 1969. Reprint of [Lam69], with a progress report (similar to 691011-progress-jng) appended.691010-overview-bwl
Thanks for these references. I tried looking this up, and got to a webpage on CAL, but like you were saying, the way it was presented didn’t look well-organized. This looks better.
I read The Early History of Smalltalk (TEHS) many years ago when I renewed my interest in the Smalltalk system. I can see that Alan’s reference to CAL didn’t stick with me until he talked about the weakness of user-access-list systems (a reference I’ve now forgotten)–which most of us use–in contrast to capabilities. This is an idea I hadn’t heard of, despite getting a CS degree (which shows the weak state that CS has been in for a while). I got more interested in this when he referred me to Mark S. Miller’s work, since he used the same idea in the mold of programming languages, with object capabilities.
An idea Alan has stressed as I’ve watched him is that we need more recognized, standardized relationships between state in our low-level systems. I see he made that point in TEHS, re. the stack frame. Lately, he’s been stressing McCarthy’s idea of fluents, so there’s less “Check if available, or access granted, then assign,” and more, “When X is here.”
Actually, when I said, “The current state of the system is that a very poor job of archiving the source code, boot tapes, etc. was done at the time” I meant to refer to the state of the system when we ceased work in 1971: at that time we did a very poor job of archiving the tapes and listings. I have been working on the archival web site ( https://mcjones.org/CalTSS/ ) since about 1998. In the last few months (while working on the history paper) I’ve put a lot of work into the web site; suggestions for improving it are welcome.
When I first approached your site a while back, I think my first thought was to look at the documents in top-down order, beginning with project plans and proposals. I may have gotten as far as the first couple design memos. Then I skipped around a bit to see if I could get my footing in the subject matter. One of the documents I picked out was Lampson’s article, “An Overview of the CAL Time-Sharing System,” and then took a break from this subject, because I felt like I was viewing things “out of order” (I needed more background).
When I approached it this time, I instead thought to look at the project history, the first link I came to, under Abstract. When I clicked the link, I was taken to the end of your outline, but I didn’t understand why I was there (I see some listings under References, and then the section on Citations). Did you mean to take people to Section 6 - Chronological order?
My suggestion for that would be when you’re referring to project history, that the place you land has a heading that comports with that subject matter.
I admit I’m coming at this being pretty naive about operating systems. All I had in that was an undergrad course when I was in college many years ago. We talked about memory management (and we wrote a small system that used shared memory, with semaphores and forked parallel processes), process scheduling (and we built a simulation of a process scheduler), and as I remember, a bit about file systems; not as much about operating systems as I expected (getting into kernel stuff).
I think what I felt like I lacked coming into your site was a sense of “where to start” for understanding what the goals were, how the project developed, what you started with, and then following your process to completion. I wanted to contrast what you guys built vs. the operating systems we’ve been using.
Looking over what you have, now, it seems the right place for me to start would be Section 6, but what would you suggest?
BTW, I’m looking over The Control Structure of an Operating System, and I was intrigued right away seeing it describes how you built things on top of virtual machines for various system functions (though, I see the article says there was “bleed through” where upper layers had access to machine functions). Interesting!
The link in this sentence of the Abstract “For a history of the project, see [MR2023].” leads to this entry in the References section:
[MR2023]
Paul McJones and Dave Redell. History of the CAL Timesharing System. Submitted to: IEEE Annals of the History of Computing. PDF
I believe this paper will address “understanding what the goals were, how the project developed, what you started with, and then following your process to completion”.
BTW, I’m looking over The Control Structure of an Operating System, and I was intrigued right away seeing it describes how you built things on top of virtual machines for various system functions (though, I see the article says there was “bleed through” where upper layers had access to machine functions). Interesting!
The same is true in modern operating systems: an application program running in a process on Windows, MacOS, or Linux is executing real instructions on a real processor. But some instructions are not available to it (e.g., instructions to modify memory mapping or I/O). Each layer typically adds some features, but hides some lower-level features.
By the way, note the sentence “In doing this we have freely done violence to the realities of CAL.” in the Motherhood section of the “Control Structure” paper. Think of the paper as giving a general idea or motivation for the system, but not the details.
Ah, yes, “Obvious (but unimplemented) generalizations have been included. Mistakes made in the implementation are not repeated here. Concessions to
the hardware are obscured.”
I read about Project Genie using a PDP-5 as a display controller. (Which seems suspiciously similar to Bell Lab’s Graphic I, but that’s another story.) My mind was somewhat boggled when I mentioned this to Mark Emmer who is an SDS 940 expert, and he replied back that he found the source code for the PDP-5.