Path: utzoo!attcan!uunet!husc6!mailrus!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: stack machines (Burroughs)
Message-ID: <28200157@urbsdc>
Date: 13 Jun 88 12:21:00 GMT
References: <370@dlscg1.UUCP>
Lines: 52
Nf-ID: #R:dlscg1.UUCP:370:urbsdc:28200157:000:2794
Nf-From: urbsdc.Urbana.Gould.COM!aglew    Jun 13 07:21:00 1988


..> Talk about the history (and future) of Burroughs/Unisys machines.

I showed some of this discussion to a guy I know who used to work for
Unisys, and here was his response ("he" was one of the earlier posters):

He is basically correct about the user interface for debugging and for
editing on the A series.  

He is wrong about the hardware.  The A-Series hardware pays a great
penalty for being stack oriented.  It is bigger 3m gates.  It has
bigger code files (because of all those extra pushes and pops.  It uses 
a lot of gates to decompile programs into an internal 3 address rr machine.

A-Series hardware spend much of its time making up for the stack, and
tags architecture.  If the same pounds of hardware and technology were
used to make a more riscy machine, it would run at least 3 times faster.

The disaster at unisys was that durring the late 70s.  It the computer
systems area was run by a manufacturing person and his chronies.  The
belief was that just reproduce the old design, concentrating on
packaging and cost, and technology will take care of speed. (the same
silly trap many risc people are falling into).  This was made worse by
the religious zelotry of the next level bellow him, who felt that the
instruction set was what made the systems successful.

This is indeed another case of an organization that didn't know why
its products were successful.  In my opinion, what made the product
successful was: 1. Development in and for a higher level language made
thoe original system very usable, and programmer oriented; 2. A small
development team helped make it simple; first comercial use of virtual
memory made it easy to program, and administer(job schedule); 3. First
true, clean, tightly coupled shared memory multiprocessing made
performance incremental for most DP type workloads; 4. A very clean
and rational I/O subsystem for its day (descriptors rather than
chained i/o commands) + fast head per track disk + fixed sector size
disks + device exchanges which allowed several channels and
controllers to access the same disks + striping files accross multiple
spindles and controllers. (all in the late 60s) This combined for a
high I/O performance I/O subsystem which was easy to use and administer.

In the early 70s they came out with DMS the first full featured database
management system.

In the late 70s the 6800 came out which was a disaster with its ill considered
shared global memory, with local memories.  This along with the religion
and management problems led to Burroughs sitting and waiting while one by one
their good features were "invented" by IBM.  Now they are behind.

Its not as if in the mean time they made the system better, but rather
they added layers of software and complexity that stoped the system
from being easy to use.