lamaster@ames.arpa (Hugh LaMaster) (03/03/88)
In article <4678@sdcsvax.UCSD.EDU> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >[ Hugh: what are the interesting things about the OS for the Cyber 205? ] >[ I have seen NOS and was not impressed; has CDC learned how to write an ] >[ OS after all these years? --DL ] > To answer your last question first- wait and see. The new ETA operating system, which should become available in the next few months, will be Unix based. It will be interesting to see what it looks like. VSOS is actually LTSS of 1975, written at Livermore for the STAR. It is a pretty good operating system for 1975, but CDC hasn't done much with it since then. It does have one nice feature that LTSS/CTSS had/have- when you run a program, you produce, as a temporary file which belongs to the user, a job image file called a drop file. If your program aborts, you can start up the drop file as a child process of the interactive debugger, and continue to run and/or debug your program. Interestingly for a system of this vintage, user processes can exec other executable files as child processes and parent/child can communicate. Just as on Unix, this makes it easy to debug- but the drop file is an additional plus. VSOS is also an interactive, virtual memory, operating system with a large virtual address space- the machine is bit addressable, with 48 bit addresses. Contrary to the opinion of many Cray advocates, virtual memory INCREASES the machine efficiency- Swapping in several small tasks doesn't require 1) copying of contiguous memory segments, as on the Cray, and, 2) you don't have to swap out all the pages of a large task just to fit a small one in. Like other CDC/Cray operating systems, files are local and temporary by default, which I find much more user friendly than Unix/VMS style. Why can't Unix define a process local temporary file area called $LOCAL or something, which is inherited to child processes so that a series of processes can communicate by giving each other files, but the files disappear at the end of the parent process (e.g. the login shell)? In any case, VSOS has no particular connection with NOS. The last noteworthy feature of VSOS which is both unusual and valuable is the ability to map files onto process virtual memory. (A common idea in the Multics/TSS era..) I sometimes wonder why this isn't part of Unix- it would have been easy to do at the same time shared memory was done. A final note about the hardware/software architecture: All the machines in the series had fast channels which sent I/O requests to outboard I/O processors which actually controlled the disks. The CPU said to the I/O processor - "give me n blocks starting at block m" and the I/O subsystem translated to cylinder/sector/track, took all the interrupts, did all the positioning, etc. etc., and sent back the data. The CPU was only interrupted at completion. VERY fast and VERY low overhead- we have some jobs which can stream effectively at 3MBytes/sec from eight disks simultaneously. The newer disks are faster. There are a lot of negatives about VSOS, such as the lack of tree structured directoris (each user has a single level permanent file system), lack of stream oriented terminal I/O (line oriented only), and a list of dumb annoying things that is extremely long and which should have been fixed long ago.