Difference between revisions of "TENEX"
m (→See also: +TENEX sharable save file) |
(One KL10) |
||
Line 14: | Line 14: | ||
[[Image:TenexPager.jpg|200px|thumb|left|The TENEX paging box for the KA10]] | [[Image:TenexPager.jpg|200px|thumb|left|The TENEX paging box for the KA10]] | ||
− | It was written by a small team at [[BBN]] for a [[KA10]] modified to add the hardware for [[virtual memory|paging]] (much as the MIT AI Lab added hardware to their KA10 for the same purpose). (The lack of a DEC [[mainframe]] with paging at the time was the primary driver for the creation of TENEX.) It was later adapted to run on the paging hardware supplied by DEC with the [[KI10]] (although not as efficiently). | + | It was written by a small team at [[BBN]] for a [[KA10]] modified to add the hardware for [[virtual memory|paging]] (much as the MIT AI Lab added hardware to their KA10 for the same purpose). (The lack of a DEC [[mainframe]] with paging at the time was the primary driver for the creation of TENEX.) |
+ | |||
+ | It was later adapted to run on the paging hardware supplied by DEC with the [[KI10]] (although not as efficiently). There is also a report of one [[KL10]] running TENEX. | ||
+ | |||
+ | ==Overview== | ||
Each user can have a hierarchy of [[process]]es, starting with the 'EXEC', the [[command processor]] (the collection being referred to as a 'job'); a 'superior' process has complete control over an 'inferior'. Processes may share memory with each other, and also map [[file]]s into their [[address space]]; memory shared between processes can be either readable, writeable, or 'copy on write'. [[Interrupt]]s may arrive from either the controlling keyboard of the job, or from another process in the job; [[trap]]s can be caused by the process' operation (e.g. illegal memory references). | Each user can have a hierarchy of [[process]]es, starting with the 'EXEC', the [[command processor]] (the collection being referred to as a 'job'); a 'superior' process has complete control over an 'inferior'. Processes may share memory with each other, and also map [[file]]s into their [[address space]]; memory shared between processes can be either readable, writeable, or 'copy on write'. [[Interrupt]]s may arrive from either the controlling keyboard of the job, or from another process in the job; [[trap]]s can be caused by the process' operation (e.g. illegal memory references). |
Revision as of 15:07, 2 April 2022
TENEX | |
Type: | Multi-tasking, multi-user, virtual memory |
---|---|
Creator: | BBN |
Architecture: | PDP-10 |
Date Released: | June, 1970 |
TENEX was an early operating system for the PDP-10 line of computers; it was the ancestor of the later DEC-supplied operating system for the DECSYSTEM-20, TOPS-20.
It was written by a small team at BBN for a KA10 modified to add the hardware for paging (much as the MIT AI Lab added hardware to their KA10 for the same purpose). (The lack of a DEC mainframe with paging at the time was the primary driver for the creation of TENEX.)
It was later adapted to run on the paging hardware supplied by DEC with the KI10 (although not as efficiently). There is also a report of one KL10 running TENEX.
Contents
Overview
Each user can have a hierarchy of processes, starting with the 'EXEC', the command processor (the collection being referred to as a 'job'); a 'superior' process has complete control over an 'inferior'. Processes may share memory with each other, and also map files into their address space; memory shared between processes can be either readable, writeable, or 'copy on write'. Interrupts may arrive from either the controlling keyboard of the job, or from another process in the job; traps can be caused by the process' operation (e.g. illegal memory references).
It provided the by-then-usual hierarchical file system, with protection (list, read, write, append, execute) to prevent one user from damaging another's files. File names included version numbers, which were automatically incremented when a file is written.
The system included three different debuggers, all versions of DDT. The first operated on the OS itself, when the OS was not running; it could be used to debug any part of the OS. The second wass a close variant; it also operated on the OS, but with the OS running. The third was used to debug user processes.
Connection to Berkeley Project Genie SDS 940 Timesharing System
Fred Wright wrote to the info-tops20 mailing list in 2005:
[TENEX] wasn't really a new design in its own right, being merely a rewrite of the SDS 940 system for the PDP-10. The 940 system, as well as the hardware enhancements that turned the 930 into the 940, came from Project Genie at UC Berkeley.
The 940 OS (mostly written by Peter Deutsch) was based on paging, viewed memory primarily as a cache for drum, had jobs with multiple forks which could optionally share pages, used the topmost fork of the job for the "shell", and had command and filename completion. Sound familiar?
TENEX was really not much more than a port of the 940 OS to the PDP-10, except for changing some things that didn't scale well to larger address spaces and storage devices. I can recall seeing TENEX code that looked literally like a line-by-line translation of 940 code, right down to using only three registers (like the 940's A, B, and X), and with half the instructions being MOVEs and MOVEMs since you can't keep much in three registers. They did, however, use a stack and PUSHJ/POPJ instead of JSR/JRST. :-) The exception model for system calls was as ugly as their hardware, instead of adopting an ITS-like PCLSRing approach - another step backwards from the 940 system, which in essence had simplified PCLSR.
Butler Lampson writes in http://bwlampson.site/Systems.htm about the SDS 940 operating system:
This system was copied directly in the design of the Tenex system for the PDP-10, except for the memory management.
Many of the TEN-SYS memos (see external links below) refer to a 940 system, presumably the BBN SDS 940 running the Berkely timesharing system and used for 940 LISP.