Difference between revisions of "Berkeley Time-Sharing System"

From Computer History Wiki
Jump to: navigation, search
(Linkify SDS.)
(Changes to the 930 for BTSS)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The '''Berkeley Timesharing System''' was a [[time-sharing]] [[operating system]] for an enhanced [[Scientific Data Systems|SDS]] [[SDS 930|930]].  Primarily written by L. Peter Deutsch, Butler Lampson, and Chuck Thacker.
+
The '''Berkeley Time-Sharing System''' was a very influential [[time-sharing]] [[operating system]] for an enhanced [[Scientific Data Systems|SDS]] [[SDS 930|930]] (effectively the prototype of the later [[SDS 940]]; the changes (below) prevented a user [[process]] from doing anything which could interfere with another process, or with the operation of the overall system).
  
It had an influence on the early design of [[UNIX]]; Ken Thompson was very familiar with it, and some aspects of Unix (e.g. the split between ''fork()'' and ''exec()'') copy how the Berkeley system operated.  
+
It was produced by [[Project GENIE]] at Berkeley; it was primarily written by L. Peter Deutsch, [[Butler Lampson]], and Chuck Thacker. It later became a product for SDS; it was also updated by Ann Hardy at [[Tymshare]] and named TYMCOM (later [[TYMCOM-IX]]).
  
It was also one of the influences on [[TENEX]].
+
It had a substantial influence on the early design of [[UNIX]]; Ken Thompson had worked on it while he was at Berkeley, and was very familiar with it, and some aspects of UNIX (e.g. the split between ''fork()'' and ''exec()'') copy how the Berkeley system operated. It was also one of the influences on [[TENEX]].
  
Supposedly, it featured a limited version of PCLSRing. From Mark Emmer:
+
The [[kernel]] was named the 'Monitor', and the [[command processor]] the 'Executive'. [[Application]] software included an [[interpreter|interpretive]] [[programming language]] called 'CAL', inspired by, and very similar to, [[JOSS]].
 +
 
 +
The changes to the 930 were:
 +
 
 +
* Addition of two additional operating modes for the [[CPU]], "user" and "monitor" (or "executive") to the base "normal" mode (in which the machine operated ''almost'' exactly as a normal 930); the machine started in normal mode (the ''only'' way to enter normal mode), and a special [[instruction]] (the only visible 'non-normality' in normal mode) could switch to monitor mode.
 +
** Once in user mode, only a 'SYSPOP' (below), a [[trap]], or an [[interrupt]] could transition back to monitor mode.
 +
* [[Instruction]]s were divided into two classes, ordinary and "privileged" (such as [[halt]] and [[input/output|I/O]] instructions); "An attempt to execute a privileged instruction while in user mode will result in the execution of a [[no-op|NOP]] instruction and, subsequently, a trap".
 +
** Some reserved instructions were used by the system as 'system programmed operators' (SYSPOPs). (Half of the SYSPOPs were allocated to the user, and half to the system.)
 +
* The user's [[address space]] was divided into 8 [[segment]]s (each 2K [[word]]s long), each of which could be disabled, or independently [[relocation|relocated]] to any location in [[main memory]] (either for normal read/write access, or read-only).
 +
** In monitor mode, instructions with the sign bit (normally unused) set used instead user address mapping for that instruction.
 +
 
 +
In other words, much the same changes as were made to other machines in that era to allow
 +
time-sharing at the [[object code]] level.
 +
 
 +
Supposedly, it featured a limited version of [[PCLSRing]]. From Mark Emmer:
  
 
: ''From what I read of the PCLSRing feature, it would be the equivalent of SYSPOPs (System Programmed Operators) in the 940 system. That is, system calls appeared to be atomic while also being interruptible. During an interrupt, the PC would point to the original SYSPOP, perhaps with altered registers for things like counts and memory pointers, reflecting incremental progress with the system call. The user PC would never point to an address within the monitor. On interrupt return, the SYSPOP would be restarted in user space.''
 
: ''From what I read of the PCLSRing feature, it would be the equivalent of SYSPOPs (System Programmed Operators) in the 940 system. That is, system calls appeared to be atomic while also being interruptible. During an interrupt, the PC would point to the original SYSPOP, perhaps with altered registers for things like counts and memory pointers, reflecting incremental progress with the system call. The user PC would never point to an address within the monitor. On interrupt return, the SYSPOP would be restarted in user space.''
  
 
{{semi-stub}}
 
{{semi-stub}}
 +
 +
==External links==
 +
 +
* [http://bitsavers.org/pdf/sds/9xx/940/ucbProjectGenie/ Project Genie] - documentation at [[Bitsavers]]
 +
** [http://bitsavers.org/pdf/sds/9xx/940/ucbProjectGenie/R-21_Time-Sharing_System_Reference_Oct68.pdf Reference Manual Time-Sharing System]
 +
** [http://bitsavers.org/pdf/sds/9xx/940/ucbProjectGenie/mcjones/R-23_CALrefMan.pdf CAL Reference Manual]
 +
* B. W. Lampson, M. W. Pirtle, W. W. Lichtenberger, ''[http://bwlampson.site/02-UserMachine/Acrobat.pdf A User Machine in a Time-Sharing System]''
 +
* [http://bitsavers.org/pdf/sds/9xx/940/ucbProjectGenie/mcjones/20.10.10.pdf Modifications to the SDS 930 Computer for the Implementation of Time-Sharing]
  
 
[[Category: Operating Systems]]
 
[[Category: Operating Systems]]

Latest revision as of 13:51, 11 June 2023

The Berkeley Time-Sharing System was a very influential time-sharing operating system for an enhanced SDS 930 (effectively the prototype of the later SDS 940; the changes (below) prevented a user process from doing anything which could interfere with another process, or with the operation of the overall system).

It was produced by Project GENIE at Berkeley; it was primarily written by L. Peter Deutsch, Butler Lampson, and Chuck Thacker. It later became a product for SDS; it was also updated by Ann Hardy at Tymshare and named TYMCOM (later TYMCOM-IX).

It had a substantial influence on the early design of UNIX; Ken Thompson had worked on it while he was at Berkeley, and was very familiar with it, and some aspects of UNIX (e.g. the split between fork() and exec()) copy how the Berkeley system operated. It was also one of the influences on TENEX.

The kernel was named the 'Monitor', and the command processor the 'Executive'. Application software included an interpretive programming language called 'CAL', inspired by, and very similar to, JOSS.

The changes to the 930 were:

  • Addition of two additional operating modes for the CPU, "user" and "monitor" (or "executive") to the base "normal" mode (in which the machine operated almost exactly as a normal 930); the machine started in normal mode (the only way to enter normal mode), and a special instruction (the only visible 'non-normality' in normal mode) could switch to monitor mode.
    • Once in user mode, only a 'SYSPOP' (below), a trap, or an interrupt could transition back to monitor mode.
  • Instructions were divided into two classes, ordinary and "privileged" (such as halt and I/O instructions); "An attempt to execute a privileged instruction while in user mode will result in the execution of a NOP instruction and, subsequently, a trap".
    • Some reserved instructions were used by the system as 'system programmed operators' (SYSPOPs). (Half of the SYSPOPs were allocated to the user, and half to the system.)
  • The user's address space was divided into 8 segments (each 2K words long), each of which could be disabled, or independently relocated to any location in main memory (either for normal read/write access, or read-only).
    • In monitor mode, instructions with the sign bit (normally unused) set used instead user address mapping for that instruction.

In other words, much the same changes as were made to other machines in that era to allow time-sharing at the object code level.

Supposedly, it featured a limited version of PCLSRing. From Mark Emmer:

From what I read of the PCLSRing feature, it would be the equivalent of SYSPOPs (System Programmed Operators) in the 940 system. That is, system calls appeared to be atomic while also being interruptible. During an interrupt, the PC would point to the original SYSPOP, perhaps with altered registers for things like counts and memory pointers, reflecting incremental progress with the system call. The user PC would never point to an address within the monitor. On interrupt return, the SYSPOP would be restarted in user space.

External links