[Simh] What is CDC OS?

[Will Senn]

On 2/16/16 3:04 PM, Nelson H. F. Beebe wrote:
> Will Senn <will.senn at gmail.com> asks on the list on Tue, 16 Feb 2016
> 12:47:12 -0600 about CDC operating systems.
>
> I worked quite happily on a CDC 6400 from 1973 to 1977.  Initially, we
> had the SCOPE operating system, and later, KRONOS.  The latter was,
> from our viewpoint, a step back, because it had a flat file system
> that in our case had to serve our entire campus.  As a result, we had
> to adopt prefixes that encoded the department name and user name on
> all filenames.
>
> For its time, the CDC 6400 (and its bigger brothers, the 6600 and
> 7600) was quite fast.  It had interactive access, and a Unix-top-like
> process display that you could run without logging in.
>
> My previous machines were IBM and Amdahl mainframes that were only
> accessible with batch jobs submitted on punched cards: for a long
> time, users at that university were forbidden from storing files on
> disks.  We solved that in our research group by renting our own IBM
> 2311 disk drive, and buying eventually a dozen or so removable disks.
> According to Wikipedia,
>
> 	https://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_drives#IBM_2311
>
> those disks with six LP-record-sized platters held about 7MB.  I did
> hundreds of mounts of those disks myself.
>
> The interactive features of the CDC 6400 had a huge beneficial impact
> on my software productivity, compared to my previous batch
> environment, and I regret that I have yet to find a CDC [67]x00
> simulator with either SCOPE or Kronos.  I have one that boots up to
> ROM level, but cannot get further with it.
>
> The CDC machines had a small instruction set (64 different opcodes).
> All integer arithmetic was done with floating-point instructions,
> which offered both rounding and truncating modes.  The
> integer-to-float-to-integer conversion meant that integers were
> effectively limited to 48 bits of data stored in a 60-bit word.  There
> were 18-bit An and Bn (n = 0..7) registers, and associated 60-bit Xn
> registers.  A0 and X0 were scratch registers.  Loading an address into
> A1 through A5 loaded a word from that memory word address into X1
> through X5.  Putting an address in A6 or A7 stored the word in X6 or
> X7.  All instruction mnemonics have hard-coded register names, so
> there was no reasonable possibility of a macro language that could
> usefully give symbolic names to registers.
>
> The CDC floating-point arithmetic had both Indefinite and Infinity:
> they were the inspiration for NaN and Infinity in IEEE 754 arithmetic
> on almost all new post-1985 machine designs.
>
> One nice feature of Indefinite was that with a job-control statement
> immediately before your job, you could initialize all memory words to
> Indefinite, with the word's address in the lower 18 bits.  Then, if
> you accidentally used an uninitialized variable, you got a
> floating-point exception, and the traceback showed where it came from,
> and thus, which variable was unset.  We used that feature heavily, and
> only a few modern systems provide something similar.
>
> The address space was 2**18 = 262_144 words, and each process had a
> contiguous block.  All physical addresses were computed dynamically
> from the sum of a job base address and a relative-to-0 address, so the
> O/S could slide entire jobs around in memory to achieve optimal
> packing.  You could, and we did, adjust the process upper bound
> dynamically during execution to free core memory for others.
>
> The CDC [67]x00 family CPUs have no interrupts: instead, there are
> several peripheral processors (PP's) that interface to external
> devices such as disks and serial terminal lines.  The PP's are 12-bit
> computers, each with 4096 words of memory. They communicate with the
> main CPU by monitoring a couple of privileged memory locations that
> hold data for a device operation.  At our site, the PPs were never
> accessible to end users, so no one outside the computer center ever
> knew their instruction set.
>
> Niklaus Wirth and Urs Ammann have interesting, and sometimes negative,
> comments about the CDC 6600 on which they developed the first Pascal
> implementation.  Like Fortran and the IBM 709, and C and the DEC
> PDP-11, the Pascal language also contains several influences of the
> CDC 6600 architecture, although Wirth tried as much as possible to
> hide the hardware from the programmer.
>
> Here are some literature references about those machines, and early
> Pascal:
>
> papers:	James E. Thornton
> 	The CDC 6600 Project
> 	http://dx.doi.org/10.1109/MAHC.1980.10044
>
> 	Niklaus Wirth
> 	The Design of a PASCAL Compiler
> 	http://dx.doi.org/10.1002/spe.4380010403
>
> 	Urs Ammann
> 	On Code Generation in a PASCAL Compiler
> 	http://dx.doi.org/10.1002/spe.4380070311
>
> book:	James E. Thornton
> 	Design of a Computer: the Control Data 6600
> 	Scott, Foresman (1970)
> 	LCCN TK7889.C6 T5 1970
>
> Thornton was part of the 6600 architecture team.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
> - University of Utah                    FAX: +1 801 581 4148                  -
> - Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------
Thanks, Nelson. I'll take a look at the references and appreciate the 
additional background as well.

Will