Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!teknowledge-vaxc!sri-unix!garth!phipps
From: phipps@garth.UUCP (Clay Phipps)
Newsgroups: comp.arch
Subject: Cobol Data Corporation Cyber 180 (was Re: 64 bits)
Keywords: CDC,Cyber180
Message-ID: <2304@garth.UUCP>
Date: 29 Dec 88 06:51:45 GMT
References: <28200249@mcdurb> <451@babbage.acc.virginia.edu> <1951@scolex> <4150@watvlsi.waterloo.edu>
Reply-To: phipps@garth.UUCP (Clay Phipps)
Organization: INTERGRAPH (APD) -- Palo Alto, CA
Lines: 75

In article <4150@watvlsi.waterloo.edu>,
smcmahon@watvlsi.waterloo.edu (Scott H. McMahon) writes:
>In article <1951@scolex> seanf@sco.COM (Sean Fagan) writes:
>>[Elxsis are a] bit like a 64-bit VAX; everybody should buy one 8-)).  

What ?  You can fit 12 Elxsi CPUs into one computer and you want only one ? :-)
At ELXSI, one motto was "we came to bury VAX, not to praise it".  :-}

>>Cybers (my favorite machines 8-)) are ... 64-bit in 180-state.  
>
>[Cyber 180s are] my favourite architecture among the heavy duty 64bit frames.
>...the 180 is a good clean design that too many people are unaware of 
>(not necessarily their fault).  Part of this "ignorance" ...is CDC's fault.
>
>Does anyone out there have an opinion re: the 180 line??

The consensus in Europe appears to be that the CDC Cyber 180s are ...
I know !  I know !  A blazing high-performance FORTRAN machine, right ?

No, a great COBOL machine !  This is no secret inside CDC itself.
In Europe, far more C180s are bought to run COBOL than FORTRAN.

The C180 architecture has more of an IBM S/370 than a DEC VAX feel to it.
It is register-oriented for conventional computation, but
memory-oriented for BDP and vector computations.
It has 16 64-bit X-registers (data), and 16 48-bit A-registers (addresses).
Index values stay in X-registers.

Instruction fields are organized usually into nybbles of 4 bits, 
addressable in "parcels" of 16 bits.
Instructions are 16 | 32 | 48 bits long, although descriptor parts may make 
some BDP and maybe vector instructions even longer (I forget by how much).
There is only one "instruction format" per opcode,
and there are few cases in which the same operation can be performed
with more than one opcode.  

The "BDP" (i.e., business data processing, as in COBOL) or string 
instructions have the feel of the IBM S/370, although the C180 may have 
some operations that the S/370 doesn't but the VAX does.

The routine-call instructions and some branches are slow, relative to 
the rest of the instructions in the C180 higher-performance machines.

The address space is segmented more like the GE/Honeywell MULTICS machines,
with 4 bits of ring-id, 12 bits of segment-id, and 32 bits of byte-offset,
and there are mechanisms to enforce restrictions on calls between 
programs or routines residing in different rings.  

System-wide page sizes can be chosen to optimize performance.  
In one configuration with many MBs of real memory, 
changing only the page size from 4K to 8K produced a dramatic improvement 
in response time for a heavy software-development workload.

The C180, especially the smaller model 930 and kin, 
should be well-suited to a native UN*X, except for any assumptions 
that pointers are the same size as some size of integer.

Although this is not "comp.os", a few other comments on the OS:
The C180 native operating system: NOS/VE, is powerful, but it has no pipes 
or redirection features.  Perhaps its best feature is its humane command 
language, esp. its regular interface for command parameters, so that 
a user can query a command (with the "discp": "display_command_parameters" 
command) to discover its parameters and their allowable values.  
Each parameter usually bears both a long "self-explanatory" name and 
a very terse abbreviated name.  As a result, the absence of the moral 
equivalent of a "man" page doesn't leave a user helpless.
The worst feature might be its file system, apparently designed as a reach
from the C170's flat file system.  Some of the things that ought to be 
simple, such as the notion of directories, came out complicated.

-- 
[The foregoing may or may not represent the position, if any, of my employer]
 
Clay Phipps                       {ingr,pyramid,sri-unix!hplabs}!garth!phipps
Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403            415/494-8800