Xref: utzoo alt.folklore.computers:12657 comp.arch:23176
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!paperboy!osf.org!dbrooks
From: dbrooks@osf.org (David Brooks)
Newsgroups: alt.folklore.computers,comp.arch
Subject: Re: XDS940 computer (or Xerox Sigma 9)
Message-ID: <22724@paperboy.OSF.ORG>
Date: 10 Jun 91 22:01:08 GMT
References: <1991Jun5.231450.25856@digi.lonestar.org> <13933@goofy.Apple.COM>
Sender: news@OSF.ORG
Organization: Open Software Foundation
Lines: 77

In article <13933@goofy.Apple.COM>, johana!tsw@apple.com (Tom Watson) writes:
|> (excellent reminiscence of the SDS/XDS Sigmas)

I was working on a hospital administration joint project for four hospitals
in England in the early 70's; we chose Sigmas largely on the basis of the
availability of a full Codasyl database and entirely credible plans for a
transaction processing system.  Two of us went to El Segundo and basically
sat on their desks until they produced the latter.  I ended up a XDS
(actually RXDS) employee, starting 22 days before Xerox pulled the plug.
This was a genuine surprise; the Xerox board made the decision at 4pm in
New york, and I woke up to read about it in the morning paper the next day.

|> The machine has 16 general registers, registers 1-7 were used as index
|> registers.  Instructions addressed bytes, halfwords (16 bits), words (32 
|> bits), and doublewords (64 bits).  Included stack instructions that used a 
|> stack descriptor (multiple stacks).

But memory was basically word-addressed.

|> The instruction set was fairly complete, it was meant to compete with the 
|> IBM 360 series, and even used EBCDIC (good, or bad depending upon how you 
|> looked at it).  The Sigma 9 even has an instruction called edit byte 
|> string which is almost a 'printf' in an instruction.

The block-mode terminal driver had exactly one comment in it:

* The following instruction checks parity.  How it does so is left as an
* exercise to the reader.
	EBS	0

|> Several languages were available, most commonly used was Fortran (looking 
|> at the listing of the compiler was an experience in itself :-)  In 
|> addition, there was an Algol-68 compiler, APL, At least 3 assemblers (most 
|> subsets of the largest one),

You left out the BCPL port I did :-).  Additionally, we did all of the
DBMS/TP application programming in COBOL.  Stop snickering, you at the back.

|> >  5) What operating system was used and how does it compare to
|> >     current systems such as Unix?
|> Two main operating systems existed (CP-R, and CP-5)

If only.

The line suffered from a plethora of operating systems.  At one time there
were five active: CP-R, BPM (batch processing monitor), BTM (basic
timesharing?) UTS (timesharing plus) and XOS (the prototype TP system).
Fortunately all the functionality was rolled into CP-V (not CP-5) as Tom
described.  For a while, I gather there was a move to standardize on CP-V
for Honeywell mainframes after H took over.

I know most of the later OS's supported shared pure procedures (only one
copy of certain utilities in memory), but I'm vague on whether it handled
shared libraries.

But operating system overlays (thirteen?) were a thing of joy, if you liked
kernel debugging.

Near the end, the Sigma machines were replaced by the compatible 5x0 line:
the 3-6 by 560 and the 7-9 by 590.

Selling the things outside the U.S. had its own special challenges.  Rather
than build a 50Hz version, Xerox made its customers buy a 120V/60Hz
generator and install it in the basement.

Also (I may have mentioned this before), the 560 was rated by the British
Government at 1.05 Atlas-power (a measure of processor performance based
entirely on an obsolete machine, analogous to VAX-MIPS).  Unfortunately,
1.0 Atlas was the dividing point between an expensive and time-consuming
procurement process, and a more straightforward equipment purchase.

So the engineers in England drove the clock down a little bit, to 0.98
Atlas, and we proudly announced the 560 Model II, *the* machine for
Government departments.  Field-upgradable, of course, preferably at night.
-- 
David Brooks				dbrooks@osf.org
Systems Engineering, OSF		uunet!osf.org!dbrooks