CDC Architecture [was: Re: products including PL/I compiler for Windows]

[Bob Lidral]

This is sort of OT for this group, so I've changed the subject and
cross-posted to comp.sys.cdc (whose members may be more familiar with
the subject).

Shmuel (Seymour J.) Metz wrote:

> In <***@comcast.net>, on 01/03/2008
> at 11:50 PM, Bob Lidral <***@comcast.net> said:
>
>
>>I worked with CDC machines until 1985. They were just coming out with
>>the 180-series to supersede the 170-series (descended from the 6600). I
>>don't remember a 160-series. I thought the progression went: 6600
>>series, 70 series, 170 series (with the 176 being based on the 7600
>>rather than the 6600 architecture as were the lower-numbered models in
>>the series), and the 180 series -- all based on the 6600 design.
>
>
> There were also Cyber 203 and Cyber 205, based on the STAR-100. You may
> have come on board after those were spun off to ETA.
>
I worked for CDC from 1978 - 1985 and had worked with CDC machines
before that since 1973. I had heard of the STAR-100 and subsequent
200-series machines but never worked on a project that used (or needed)
that architecture.

ETA was one of CDC's stupidest mistakes. One of the stupider things
they did was the way they announced the spinoff in the company
newsletter. Basically, it said the supercomputer group was at the
cutting edge of technology and needed the best and brightest of the
company (thereby categorizing those of us not being spunoff in some
other group). It also said CDC had too much bureaucracy and wasteful
internal procedures for anyone to make any significant contributions
toward progress so it was necessary to spin off the supercomputer group
into a new company not saddled with all that overhead (implying that
there was no hope for anyone not spun off to do anything useful or
significant and that the company had no plan or even intention to
improve internal procedures). As you might imagine, this was a major
morale-booster for the rest of us. I read a summary somewhere of CDC's
subsequent gross mismanagement of ETA (which they apparently never
really did spin off) but have no first-hand knowledge and, anyway,
that's a long story for another time and another newsgroup.

>>There were also the 1700 series and the 18 "series".
>
>
> Could the 18 series have been a new version of the 160, 160A or 160G? The
> 160 was very similar to the PP on a 6600.
>
That depends on how much Seymour Cray was involved with all of those
designs. My understanding was that Cray had designed the 1700 series
and that the 18 series was based on that design. See, for example,
http://en.wikipedia.org/wiki/CDC_Cyber#Cyber-18 .

I believe the 160 series was a straight 12-bit design. The PP was a
12-bit design but with an 18-bit accumulator (weird, but useful in the
self-modifying one-pass divide-by-5 algorithm).

I worked on a 1700 (used as an interface, sort of, to a 777 graphics
processor) and studied the 18-series "architecture" and its "Pascal"
compiler. The 1700 was a different design from the PP design.

> Note: I didn't mention, e.g., the 924, 1604, 3600 or 3800 because those
> were never marketed under the Cyber label.
>
I seem to remember the 1604, 3600, 3800, and 3300(?) were pretty much on
their way out by the time I joined the company. I saw a few of them at
various customer installations, but never worked with them. I believe
the 6600-series and subsequent related architectures still used unit
record equipment originally designed for some of those earlier models,
though.


Bob Lidral
lidral at alum dot mit dot edu

[Douglas A. Gwyn]

Bob Lidral wrote:
> I worked on a 1700 (used as an interface, sort of, to a 777 graphics
> processor) and studied the 18-series "architecture" and its "Pascal"
> compiler. The 1700 was a different design from the PP design.

It was probably a "Digigraphic" controller.

If you have *any* 1700 (or Cyber-18) system software in any medium,
even hardcopy, I could really use a copy of it for a 1700 emulation
I have been developing.

[Bob Lidral]

Douglas A. Gwyn wrote:
> Bob Lidral wrote:
>
>>I worked on a 1700 (used as an interface, sort of, to a 777 graphics
>>processor) and studied the 18-series "architecture" and its "Pascal"
>>compiler. The 1700 was a different design from the PP design.
>
>
> It was probably a "Digigraphic" controller.
>
> If you have *any* 1700 (or Cyber-18) system software in any medium,
> even hardcopy, I could really use a copy of it for a 1700 emulation
> I have been developing.

All of the code on which I worked was under contract to the Air Force
for a radar installations (PAVE PAWS, BMEWS, COBRA DANE, and COBRA
JUDY). Theoretically, it might be available somewhere, but not from me.

CDC owned the original source code. You may be able to find some from
one of its successors or assigns (used to be Syntegra and now BT Global
Services, apparently). You might also try the Air Force. Anything they
own that's not classified might be available to citizens for the asking,
but I wouldn't know how to go about getting it.

Good luck.


Bob Lidral
lidral at alum dot mit dot edu

[Douglas A. Gwyn]

Bob Lidral wrote:
> Douglas A. Gwyn wrote:
> > If you have *any* 1700 (or Cyber-18) system software in any medium,
> > even hardcopy, I could really use a copy of it for a 1700 emulation
> > I have been developing.
> All of the code on which I worked was under contract to the Air Force
> for a radar installations (PAVE PAWS, BMEWS, COBRA DANE, and COBRA
> JUDY). Theoretically, it might be available somewhere, but not from me.

Yes, last time I searched the net for it, apart from entries in
resumes, the Babbage Institute holdings, and my own mention in newsgroups
the only link to 1700 software I found was some document at Hanscom AFB.

> CDC owned the original source code. You may be able to find some from
> one of its successors or assigns (used to be Syntegra and now BT Global
> Services, apparently). You might also try the Air Force. Anything they
> own that's not classified might be available to citizens for the asking,
> but I wouldn't know how to go about getting it.

I've tried, but so far haven't been able to get in touch with anybody
who has a good idea about how to get hold of whatever sources might
exist "somewhere". There should be at least a fiche listing somewhere.
(I have one for SMM17, a diagnostic monitor, but not for any "user"
oriented system software.)

I have constructed my own object-code-compatible cross-linker in C
and was partway through creating a cross-assembler when I shelved the
project. It could be dusted off and reactivated if I got hold of
actual system software to act as an incentive.

[glen herrmannsfeldt]

Bob Lidral wrote:

(snip)

> I worked for CDC from 1978 - 1985 and had worked with CDC machines
> before that since 1973. I had heard of the STAR-100 and subsequent
> 200-series machines but never worked on a project that used (or needed)
> that architecture.

Someone in 1978 told me that the STAR-100 has decimal floating point.
I believed that for a long time, until I was told by a more reliable
source that it didn't.

I believe, though, that it does have a square root instruction,
which was pretty rare at the time.

-- glen

[Jitze]

On Mon, 07 Jan 2008 13:57:15 -0800, glen herrmannsfeldt
<***@ugcs.caltech.edu> wrote:

>Bob Lidral wrote:
>
>(snip)
>
>> I worked for CDC from 1978 - 1985 and had worked with CDC machines
>> before that since 1973. I had heard of the STAR-100 and subsequent
>> 200-series machines but never worked on a project that used (or needed)
>> that architecture.
>
>Someone in 1978 told me that the STAR-100 has decimal floating point.
>I believed that for a long time, until I was told by a more reliable
>source that it didn't.
>

I can't find an op code for anything like that - but it did have
decimal add, subtract, multiply and divide.

>I believe, though, that it does have a square root instruction,
>which was pretty rare at the time.
>

I just checked my copy of the "programmer's instant" for the STAR 100
and I see there were in fact 3 different op codes for square root
operations:

Op codes 53 and 73 are both defined as:
" Significant Square Root of (R) to (T) " and categorised as
being instruction type "register" - I'm not sure what difference
(if any) there was between these two.

Op code 93 is defined as:
" Significant Square Root of A -> C " and categorised as being
instruction type "vector"

Jitze

[robin]

"glen herrmannsfeldt" <***@ugcs.caltech.edu> wrote in message
news:***@comcast.com...
> Bob Lidral wrote:
>
> (snip)
>
> > I worked for CDC from 1978 - 1985 and had worked with CDC machines
> > before that since 1973. I had heard of the STAR-100 and subsequent
> > 200-series machines but never worked on a project that used (or needed)
> > that architecture.
>
> Someone in 1978 told me that the STAR-100 has decimal floating point.

> I believe, though, that it does have a square root instruction,
> which was pretty rare at the time.

One of the Elliott machines had square root hardware
instruction c. 1956 at the WRE.

[Everett M. Greene]

"robin" <***@bigpond.com> writes:
> "glen herrmannsfeldt" <***@ugcs.caltech.edu> wrote
> > Bob Lidral wrote:
> >
> > (snip)
> >
> > > I worked for CDC from 1978 - 1985 and had worked with CDC machines
> > > before that since 1973. I had heard of the STAR-100 and subsequent
> > > 200-series machines but never worked on a project that used (or needed)
> > > that architecture.
> >
> > Someone in 1978 told me that the STAR-100 has decimal floating point.
>
> > I believe, though, that it does have a square root instruction,
> > which was pretty rare at the time.
>
> One of the Elliott machines had square root hardware
> instruction c. 1956 at the WRE.

It's trivial to add square root to division operations.
The Univac 490 series machines for which I taught
hardware maintenace had exactly one extra logic gate
for square root.

[Scott Dorsey]

Douglas A. Gwyn <***@null.net> wrote:
>Bob Lidral wrote:
>> Douglas A. Gwyn wrote:
>> > If you have *any* 1700 (or Cyber-18) system software in any medium,
>> > even hardcopy, I could really use a copy of it for a 1700 emulation
>> > I have been developing.
>> All of the code on which I worked was under contract to the Air Force
>> for a radar installations (PAVE PAWS, BMEWS, COBRA DANE, and COBRA
>> JUDY). Theoretically, it might be available somewhere, but not from me.
>
>Yes, last time I searched the net for it, apart from entries in
>resumes, the Babbage Institute holdings, and my own mention in newsgroups
>the only link to 1700 software I found was some document at Hanscom AFB.

Send a FOIA request to Hanscom and see what happens. The chances that
anybody will have anything lying around still (and that it is not classified)
is slim, but you never know, and it doesn't take a lot of effort to make the
request.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Fred Bradford]

-Fred Bradford... I worked at CDC from 1968-1979.. My comments
interspersed below....

On Sun, 06 Jan 2008 18:33:21 -0800, Bob Lidral
<***@comcast.net> wrote:

>This is sort of OT for this group, so I've changed the subject and
>cross-posted to comp.sys.cdc (whose members may be more familiar with
>the subject).
>
>Shmuel (Seymour J.) Metz wrote:
>
>> In <***@comcast.net>, on 01/03/2008
>> at 11:50 PM, Bob Lidral <***@comcast.net> said:
>>
>>
>>>I worked with CDC machines until 1985. They were just coming out with
>>>the 180-series to supersede the 170-series (descended from the 6600). I
>>>don't remember a 160-series.


FB: the 160 and 160A were standalone computers. Later integrated into
the 6600 series as "PPU's"


> > > > I thought the progression went: 6600
>>>series, 70 series, 170 series (with the 176 being based on the 7600
>>>rather than the 6600 architecture as were the lower-numbered models in
>>>the series), and the 180 series -- all based on the 6600 design.

FB: the above is correct. The Cyber-70 was the 6000 series with "new
skins" and two totally worthless "character type" instructions that
were never implimented. Primarily, it was a "marketing" machine.

The first of the 6000 series was the 6600. It put CDC on the map.

Later, the 6400, simply the 6600 with no vector instruction stack.
considered a "starter machine" to reduce the cost of the basic
seriies.

The most cost effective machine was the 6500, a machine with two 6400
scalar CPU's.

Soon after with more compressed circuitry, a 6700 was tried, a 6500
but with a 6600cpu with a 6400cpu.

Then another machine, the 6200 came along. A slowed down 6400. (Simply
the clock slowed down, nothing else. Cost the same to build but sold
at more narrow profit margin. Not successfull.)

An internal joke was that it was "field upgradable to a 6400" for just
a few thousand dollars. The upgrade was a toggle switch hidden
inside to increase the clock speed to that of the 6400!!!


>>
>>
>> There were also Cyber 203 and Cyber 205, based on the STAR-100.

FB: The Star (later "STAR-100") came before the globalized "Cyber"
name change. thus STAR->STAR-100->Cyber-203->Cyber-205-->ETA-xxx

> > You may
>> have come on board after those were spun off to ETA.
>>
>I worked for CDC from 1978 - 1985 and had worked with CDC machines
>before that since 1973. I had heard of the STAR-100 and subsequent
>200-series machines but never worked on a project that used (or needed)
>that architecture.
>

FB: The internal conflicts between Seymour Cray (and his failed 8600)
and the military's enforced hardward designes used in the STAR series
brought about the mess discribed below.


Also forgotten in all the histories I've seen are the dirivatives of
the STAR hardware that were, I believe, called the STAR-50 and lower
numbers. These used some of the STAR logic but only in non-vector
mode. Prototypes were built and running in Toronto (suburb) in 1971+/-

There was also a CDC-3700 prototype that I did timings on. It was a
logicallly similar machine to the 3300 and 3500 machines, but with
circiutry looking like the 6600 pancake boards. While faster than the
3700, not fast enought to be put into production.

-Fred Bradford (Los Angeles)


>ETA was one of CDC's stupidest mistakes. One of the stupider things
>they did was the way they announced the spinoff in the company
>newsletter. Basically, it said the supercomputer group was at the
>cutting edge of technology and needed the best and brightest of the
>company (thereby categorizing those of us not being spunoff in some
>other group). It also said CDC had too much bureaucracy and wasteful
>internal procedures for anyone to make any significant contributions
>toward progress so it was necessary to spin off the supercomputer group
>into a new company not saddled with all that overhead (implying that
>there was no hope for anyone not spun off to do anything useful or
>significant and that the company had no plan or even intention to
>improve internal procedures). As you might imagine, this was a major
>morale-booster for the rest of us. I read a summary somewhere of CDC's
>subsequent gross mismanagement of ETA (which they apparently never
>really did spin off) but have no first-hand knowledge and, anyway,
>that's a long story for another time and another newsgroup.
>
>>>There were also the 1700 series and the 18 "series".
>>
>>
>> Could the 18 series have been a new version of the 160, 160A or 160G?


FB: no.... The 1700 was a ripoff attempt to copy the IBM1600. It
used 8-bytes and 6600 style pancake ciruits. The "18" was similar but
used integrated cirucuits. Neither related to the 160 computer
seriies.

The
>> 160 was very similar to the PP on a 6600.

FB: The 160 -> 160A were computers built into desks. Later redesigned
into virticle rack type computer called the 8090. It had 6-bit
characters.

A really messy dirivative of the 8090 was the 8092 that had 4-bit
characters, but two together created an early 8-byte capability. I
never saw one in operation.


>>
>That depends on how much Seymour Cray was involved with all of those
>designs. My understanding was that Cray had designed the 1700 series
>and that the 18 series was based on that design. See, for example,
>http://en.wikipedia.org/wiki/CDC_Cyber#Cyber-18 .
>
>I believe the 160 series was a straight 12-bit design. The PP was a
>12-bit design but with an 18-bit accumulator (weird, but useful in the
>self-modifying one-pass divide-by-5 algorithm).
>
>I worked on a 1700 (used as an interface, sort of, to a 777 graphics
>processor) and studied the 18-series "architecture" and its "Pascal"
>compiler. The 1700 was a different design from the PP design.
>
>> Note: I didn't mention, e.g., the 924, 1604, 3600 or 3800 because those
>> were never marketed under the Cyber label.
>>
>I seem to remember the 1604, 3600, 3800, and 3300(?) were pretty much on
>their way out by the time I joined the company. I saw a few of them at
>various customer installations, but never worked with them. I believe
>the 6600-series and subsequent related architectures still used unit
>record equipment originally designed for some of those earlier models,
>though.

FB: the 1604/3600/3800 were basically similar... 48??-bit words of
6-bir characters.
the 3300/3500/[3700] and cheapo machines 3200 and later the 3150
used 24bit words of 6 bits.

Peripheral equipment for ALL CDC machines with 6-bit characters, but
of the so called BCD mode rather than the 6600 "Display Mode" and
60-bit words. This required massive translation boxes for each
device attached to the 6000 machines that had to be included free in
the cost of the system. Totally a third of the computer room was will
with these "dumb" machines.

-Fred Bradford (Los Angeles)

>
>
>Bob Lidral
>lidral at alum dot mit dot edu

[Bob Lidral]

I removed the comp.lang.pl1 newsgroup.

Fred Bradford wrote:
> -Fred Bradford... I worked at CDC from 1968-1979.. My comments
> interspersed below....
>
> On Sun, 06 Jan 2008 18:33:21 -0800, Bob Lidral
> <***@comcast.net> wrote:
>
> ...
>>
>>Shmuel (Seymour J.) Metz wrote:
>>
>>
>>>In <***@comcast.net>, on 01/03/2008
>>> at 11:50 PM, Bob Lidral <***@comcast.net> said:
>>>
> ...
>>>>> I thought the progression went: 6600
>>>>
>>>>series, 70 series, 170 series (with the 176 being based on the 7600
>>>>rather than the 6600 architecture as were the lower-numbered models in
>>>>the series), and the 180 series -- all based on the 6600 design.
>
>
> FB: the above is correct. The Cyber-70 was the 6000 series with "new
> skins" and two totally worthless "character type" instructions that
> were never implimented. Primarily, it was a "marketing" machine.
>
> The first of the 6000 series was the 6600. It put CDC on the map.
>
> Later, the 6400, simply the 6600 with no vector instruction stack.
> considered a "starter machine" to reduce the cost of the basic
> seriies.
>
I once worked with on projects with both 174s and 175s. The 175 was
basically the 6600 architecture, while the 171, 172, 173, and 174 were
based on the 6400 architecture. We had a program that ran fine on a 174
but kept getting an address exception on a 175.

It took awhile to figure out. It turns out the 175 had the
aforementioned instruction stack and used to pre-fetch two memory words
beyond the instruction stack; the other models didn't. The executable
exactly filled the available memory for the process and failed on the
175 because at least one of the words it tried to pre-fetch was beyond
the end of the available memory.

> The most cost effective machine was the 6500, a machine with two 6400
> scalar CPU's.
>
> Soon after with more compressed circuitry, a 6700 was tried, a 6500
> but with a 6600cpu with a 6400cpu.
>
I actually worked on a 6700 using remote access to a machine located in
some Naval laboratory somewhere (NSRDC maybe?). I heard there were only
a handful of them. Given that we were limited to remote batch or
telephone modem access, I never observed a speed difference among the
6400, 6600, and 6700 available to us.

Unfortunately, for us, the NOS "interactive" interface was full-duplex
without type-ahead (one of their less inspired design decisions). That
meant it ignored any character typed until it had echoed the previous
character. I can remember dozing off between keypresses while waiting
for the previous character to be echoed. Sigh.

> Then another machine, the 6200 came along. A slowed down 6400. (Simply
> the clock slowed down, nothing else. Cost the same to build but sold
> at more narrow profit margin. Not successfull.)
>
> An internal joke was that it was "field upgradable to a 6400" for just
> a few thousand dollars. The upgrade was a toggle switch hidden
> inside to increase the clock speed to that of the 6400!!!
>
I heard there was a similar relation between the 173 and 174. The
"upgrade" from a 173 to a 174 was rumored to consist of removing one
jumper -- but at least it cost a lot. :-)

> ...
>
> -Fred Bradford (Los Angeles)
>
Bob Lidral
lidral at alum dot mit dot edu

[Silver Bells]

On Thu, 10 Jan 2008 21:21:17 -0800, Bob Lidral
<***@comcast.net> wrote:

>I removed the comp.lang.pl1 newsgroup.
>
>Fred Bradford wrote:
>> -Fred Bradford... I worked at CDC from 1968-1979.. My comments
>> interspersed below....
>>
>> On Sun, 06 Jan 2008 18:33:21 -0800, Bob Lidral
>> <***@comcast.net> wrote:
>>
>> ...
>>>
>>>Shmuel (Seymour J.) Metz wrote:
>>>
>>>
>>>>In <***@comcast.net>, on 01/03/2008
>>>> at 11:50 PM, Bob Lidral <***@comcast.net> said:
>>>>
>> ...
>>>>>> I thought the progression went: 6600
>>>>>
>>>>>series, 70 series, 170 series (with the 176 being based on the 7600
>>>>>rather than the 6600 architecture as were the lower-numbered models in
>>>>>the series), and the 180 series -- all based on the 6600 design.
>>
>>
>> FB: the above is correct. The Cyber-70 was the 6000 series with "new
>> skins" and two totally worthless "character type" instructions that
>> were never implimented. Primarily, it was a "marketing" machine.
>>
>> The first of the 6000 series was the 6600. It put CDC on the map.
>>
>> Later, the 6400, simply the 6600 with no vector instruction stack.
>> considered a "starter machine" to reduce the cost of the basic
>> seriies.
>>



>I once worked with on projects with both 174s and 175s. The 175 was
>basically the 6600 architecture, while the 171, 172, 173, and 174 were
>based on the 6400 architecture. We had a program that ran fine on a 174
>but kept getting an address exception on a 175.
>
>It took awhile to figure out. It turns out the 175 had the
>aforementioned instruction stack and used to pre-fetch two memory words
>beyond the instruction stack; the other models didn't. The executable
>exactly filled the available memory for the process and failed on the
>175 because at least one of the words it tried to pre-fetch was beyond
>the end of the available memory.

FB: sounds like a problem I noticed (I think in the CDC-8600
preliminary manual, or at least a similar CDC or Cray machine with a
stack.) The resolution was to pad the loop with no-ops either to keep
the code entirely in the stack or to prevent timeconsuming search
outside the loop.)


>
>> The most cost effective machine was the 6500, a machine with two 6400
>> scalar CPU's.
>>
>> Soon after with more compressed circuitry, a 6700 was tried, a 6500
>> but with a 6600cpu with a 6400cpu.
>>
>I actually worked on a 6700 using remote access to a machine located in
>some Naval laboratory somewhere (NSRDC maybe?). I heard there were only
>a handful of them. Given that we were limited to remote batch or
>telephone modem access, I never observed a speed difference among the
>6400, 6600, and 6700 available to us.
>
>Unfortunately, for us, the NOS "interactive" interface was full-duplex
>without type-ahead (one of their less inspired design decisions). That
>meant it ignored any character typed until it had echoed the previous
>character. I can remember dozing off between keypresses while waiting
>for the previous character to be echoed. Sigh.
>
>> Then another machine, the 6200 came along. A slowed down 6400. (Simply
>> the clock slowed down, nothing else. Cost the same to build but sold
>> at more narrow profit margin. Not successfull.)
>>
>> An internal joke was that it was "field upgradable to a 6400" for just
>> a few thousand dollars. The upgrade was a toggle switch hidden
>> inside to increase the clock speed to that of the 6400!!!
>>
>I heard there was a similar relation between the 173 and 174. The
>"upgrade" from a 173 to a 174 was rumored to consist of removing one
>jumper -- but at least it cost a lot. :-)
>
>> ...
>>
>> -Fred Bradford (Los Angeles)
>>
>Bob Lidral
>lidral at alum dot mit dot edu

[Bob Lidral]

Silver Bells wrote:
> On Thu, 10 Jan 2008 21:21:17 -0800, Bob Lidral
> <***@comcast.net> wrote:
>
> ...
>>I once worked with on projects with both 174s and 175s. The 175 was
>>basically the 6600 architecture, while the 171, 172, 173, and 174 were
>>based on the 6400 architecture. We had a program that ran fine on a 174
>>but kept getting an address exception on a 175.
>>
>>It took awhile to figure out. It turns out the 175 had the
>>aforementioned instruction stack and used to pre-fetch two memory words
>>beyond the instruction stack; the other models didn't. The executable
>>exactly filled the available memory for the process and failed on the
>>175 because at least one of the words it tried to pre-fetch was beyond
>>the end of the available memory.
>
>
> FB: sounds like a problem I noticed (I think in the CDC-8600
> preliminary manual, or at least a similar CDC or Cray machine with a
> stack.) The resolution was to pad the loop with no-ops either to keep
> the code entirely in the stack or to prevent timeconsuming search
> outside the loop.)
>
We didn't have the option of padding the loop -- directly, at least. I
don't remember how we resolved it. Except that, clearly, the last
(highest-address) instruction had to have been a backward branch. In
assembly language we could just have added a couple of no-ops to the
source. In a high-level language we'd have had to be careful that any
dummy code we added wouldn't have been optimized away.

As I remember, the way the 6600 architecture worked was that it only
kept the most recently-executed 7 contiguous words plus the next two
(pre-fetch). Since the words were 60 bits and instructions were 15, 30,
or 60 bits, the stack could potentially hold up to 28 15-bit
instructions. In practice it was usually a few fewer than that, but the
FTN optimizer was good at getting close to that for inner loops.

Backward branches to addresses still in the instruction stack executed
from the stack so loops entirely contained in the stack were very fast.
...

Bob Lidral
lidral at alum dot mit dot edu

[Shmuel (Seymour J.) Metz]

In <***@4ax.com>, on 01/10/2008
at 07:50 PM, Fred Bradford <***@earthlink.net> said:

>FB: the 160 and 160A were standalone computers. Later integrated into
>the 6600 series as "PPU's"

While the PP architecture certainly derived from the 160, the
implimentation was quite different;; there was one real CPU running at 10
MHz in order to look like 10 virtual CPU's at 1 MHz each.

>Later, the 6400, simply the 6600 with no vector instruction stack.

?

The 6600 was a scalar machine. It did, however, have an instruction
pipeline.

There were a couple of specialized machines consisting of a ring of PP's
with no CP; I don't know how well they did.

>FB: the 1604/3600/3800 were basically similar... 48??-bit words of 6-bir
>characters.

Yes; the 924 was 24 bit. The 3600 and 3800 had much larger instruction
sets and an improved architecture.

> the 3300/3500/[3700] and cheapo machines 3200 and later the 3150 used
>24bit words of 6 bits.

Yes.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to ***@library.lspace.org

[Silver Bells]

On Fri, 11 Jan 2008 07:43:03 -0500, Shmuel (Seymour J.) Metz
<***@library.lspace.org.invalid> wrote:

>In <***@4ax.com>, on 01/10/2008
> at 07:50 PM, Fred Bradford <***@earthlink.net> said:
>
>>FB: the 160 and 160A were standalone computers. Later integrated into
>>the 6600 series as "PPU's"
>
>While the PP architecture certainly derived from the 160, the
>implimentation was quite different;; there was one real CPU running at 10
>MHz in order to look like 10 virtual CPU's at 1 MHz each.
>
>>Later, the 6400, simply the 6600 with no vector instruction stack.
>
FB: ... I should not have used the word "vector" above. -f
>
>The 6600 was a scalar machine. It did, however, have an instruction
>pipeline.
>
>There were a couple of specialized machines consisting of a ring of PP's
>with no CP; I don't know how well they did.


FB: I believe it also had full central memory. It's purpose was to be
a sort of "server" on a network. I don't think it ever was put into
production.

>
>>FB: the 1604/3600/3800 were basically similar... 48??-bit words of 6-bir
>>characters.
>
>Yes; the 924 was 24 bit. The 3600 and 3800 had much larger instruction
>sets and an improved architecture.


FB: I never know where the "924" fit in or what it was used for.

CDC made some really terrible remote terminial/cardreader/printer
devices. One called the "200 User Terminal" a.k.a. "200 Loser
Terminal!

A 934 terminial somewhat better.

But the beast of all beasts was a printer with alternate character
drums missing. The entire "shuttle" would bump back and forth to print
odd then even columns. Know as the "shuttle printer." I only saw one.
Made an awful noise.



>
>> the 3300/3500/[3700] and cheapo machines 3200 and later the 3150 used
>>24bit words of 6 bits.
>
>Yes.

[Bob Lidral]

Silver Bells wrote:

> On Fri, 11 Jan 2008 07:43:03 -0500, Shmuel (Seymour J.) Metz
> <***@library.lspace.org.invalid> wrote:
>
>
>>In <***@4ax.com>, on 01/10/2008
>> at 07:50 PM, Fred Bradford <***@earthlink.net> said:
>>
>>
>>>FB: the 160 and 160A were standalone computers. Later integrated into
>>>the 6600 series as "PPU's"
>>
>>While the PP architecture certainly derived from the 160, the
>>implimentation was quite different;; there was one real CPU running at 10
>>MHz in order to look like 10 virtual CPU's at 1 MHz each.
>>
>>
>>>Later, the 6400, simply the 6600 with no vector instruction stack.
>>
> FB: ... I should not have used the word "vector" above. -f

Well, there was some concurrency in the 6600 architecture. The 6600 CPU
had several instruction units that could operate simultaneously; the
6400 architecture did not.

Some arithmetic and logical operations could be performed by different
instruction units. As I recall, it had a floating-point unit, an
integer unit, a logical unit, and, I believe, some others. For example,
arithmetic negation could be accomplished by the integer arithmetic unit
or by bitwise logical complement by the logical unit since it was a 1s
complement machine. For these types of operations, a smart optimizer
(and CDC's FTN optimizer was pretty good) could use whichever
instruction unit was not being used for something else at the time. In
an ideal situation, all instruction units could operate simultaneously
on different instructions.

The FTN optimizer used to build a dependency graph of operations and
operands and then generated instructions that could be executed
simultaneously. Since each operation could take different lengths of
time, it was necessary to make sure no operation was started until its
operands were available -- that is, that any instructions used to
compute the input operands of an instruction had finished before
starting the instruction.

I believe the FTN optimizer first located a critical path through the
intermediate language, assigned operations on that path to the
fastest-possible CPU unit, and then assigned any operations not on the
critical path to other available CPU units, if possible. It made an
impressive improvement in the speed of carefully-written FORTRAN programs.

Not really a vector architecture, but it did provide some localized
concurrency.

> ...
> FB: I never know where the "924" fit in or what it was used for.
>
> CDC made some really terrible remote terminial/cardreader/printer
> devices. One called the "200 User Terminal" a.k.a. "200 Loser
> Terminal!
>
> A 934 terminial somewhat better.
>
> But the beast of all beasts was a printer with alternate character
> drums missing. The entire "shuttle" would bump back and forth to print
> odd then even columns. Know as the "shuttle printer." I only saw one.
> Made an awful noise.
>
>
My favorite futile CDC product was called, I think, the Mass Storage
System (MSS). Whatever it was called, it was a huge magnetic tape
jukebox -- sort of. The following description is based on a nearly
30-year old memory of only a couple of minutes observation, so it may be
more than a little off.

It was huge -- probably about 8 or 10 feet tall by 8 feet or more wide.
It was implemented as a large honeycomb (well, rows and columns rather
than a hexagonal matrix) of wide tape reels that were roughly the same
size and shape as wax cylinders (another state-of-the-art medium :-)).

These tape reels were kept in what was probably a hermetically-sealed
cabinet with a glass front so you could watch it work (the best part
:-)). It had a picker of some sort. I seem to remember horizontal and
vertical rods that moved back-and-forth and up-and-down to position the
picker at one of the cylinders (though my memory is a little vague). It
would then extract tapes from the frame and move them to the read/write
unit or remove them from the read/write unit and return them to the
frame. I think it even had a queue of pre-fetched tapes that it would
fill while the read/write unit was busy with another tape.

It was huge, sucked a lot of power, and was extremely expensive. It
could be used to store a huge amount of data for its time. But it
wasn't worth it if you had significantly lower data storage requirements
and, although reputedly much faster than the 7- and 9-track tapes CDC
was fond of using, it was still limited in speed compared to disks.

It was extremely impressive to watch, if you had an application that
needed to read or write data on several different tape reels so the
picker arm would have to pull and replace tapes from the frame a lot.
But I don't know whether CDC ever sold any; the one I saw was a demo
prototype -- at Arden Hills, I believe.


Bob Lidral
lidral at alum dot mit dot edu

[Silver Bells]

On Fri, 11 Jan 2008 23:41:10 -0800, Bob Lidral
<***@comcast.net> wrote:

>Silver Bells wrote:
>
>> On Fri, 11 Jan 2008 07:43:03 -0500, Shmuel (Seymour J.) Metz
>> <***@library.lspace.org.invalid> wrote:
>>
>>
>>>In <***@4ax.com>, on 01/10/2008
>>> at 07:50 PM, Fred Bradford <***@earthlink.net> said:
>>>
>>>
>>>>FB: the 160 and 160A were standalone computers. Later integrated into
>>>>the 6600 series as "PPU's"
>>>
>>>While the PP architecture certainly derived from the 160, the
>>>implimentation was quite different;; there was one real CPU running at 10
>>>MHz in order to look like 10 virtual CPU's at 1 MHz each.
>>>
>>>
>>>>Later, the 6400, simply the 6600 with no vector instruction stack.
>>>
>> FB: ... I should not have used the word "vector" above. -f
>
>Well, there was some concurrency in the 6600 architecture. The 6600 CPU
>had several instruction units that could operate simultaneously; the
>6400 architecture did not.
>
>Some arithmetic and logical operations could be performed by different
>instruction units. As I recall, it had a floating-point unit, an
>integer unit, a logical unit, and, I believe, some others. For example,
>arithmetic negation could be accomplished by the integer arithmetic unit
>or by bitwise logical complement by the logical unit since it was a 1s
>complement machine. For these types of operations, a smart optimizer
>(and CDC's FTN optimizer was pretty good) could use whichever
>instruction unit was not being used for something else at the time. In
>an ideal situation, all instruction units could operate simultaneously
>on different instructions.
>
>The FTN optimizer used to build a dependency graph of operations and
>operands and then generated instructions that could be executed
>simultaneously. Since each operation could take different lengths of
>time, it was necessary to make sure no operation was started until its
>operands were available -- that is, that any instructions used to
>compute the input operands of an instruction had finished before
>starting the instruction.
>
>I believe the FTN optimizer first located a critical path through the
>intermediate language, assigned operations on that path to the
>fastest-possible CPU unit, and then assigned any operations not on the
>critical path to other available CPU units, if possible. It made an
>impressive improvement in the speed of carefully-written FORTRAN programs.
>
>Not really a vector architecture, but it did provide some localized
>concurrency.
>
>> ...
>> FB: I never know where the "924" fit in or what it was used for.
>>
>> CDC made some really terrible remote terminial/cardreader/printer
>> devices. One called the "200 User Terminal" a.k.a. "200 Loser
>> Terminal!
>>
>> A 934 terminial somewhat better.
>>
>> But the beast of all beasts was a printer with alternate character
>> drums missing. The entire "shuttle" would bump back and forth to print
>> odd then even columns. Know as the "shuttle printer." I only saw one.
>> Made an awful noise.
>>
>>
>My favorite futile CDC product was called, I think, the Mass Storage
>System (MSS). Whatever it was called, it was a huge magnetic tape
>jukebox -- sort of. The following description is based on a nearly
>30-year old memory of only a couple of minutes observation, so it may be
>more than a little off.
>
>It was huge -- probably about 8 or 10 feet tall by 8 feet or more wide.
> It was implemented as a large honeycomb (well, rows and columns rather
>than a hexagonal matrix) of wide tape reels that were roughly the same
>size and shape as wax cylinders (another state-of-the-art medium :-)).
>
>These tape reels were kept in what was probably a hermetically-sealed
>cabinet with a glass front so you could watch it work (the best part
>:-)). It had a picker of some sort. I seem to remember horizontal and
>vertical rods that moved back-and-forth and up-and-down to position the
>picker at one of the cylinders (though my memory is a little vague). It
>would then extract tapes from the frame and move them to the read/write
>unit or remove them from the read/write unit and return them to the
>frame. I think it even had a queue of pre-fetched tapes that it would
>fill while the read/write unit was busy with another tape.
>
>It was huge, sucked a lot of power, and was extremely expensive. It
>could be used to store a huge amount of data for its time. But it
>wasn't worth it if you had significantly lower data storage requirements
>and, although reputedly much faster than the 7- and 9-track tapes CDC
>was fond of using, it was still limited in speed compared to disks.
>
>It was extremely impressive to watch, if you had an application that
>needed to read or write data on several different tape reels so the
>picker arm would have to pull and replace tapes from the frame a lot.
>But I don't know whether CDC ever sold any; the one I saw was a demo
>prototype -- at Arden Hills, I believe.


FB: I too worked at Arden Hills from mid 1968 thru 1971 in the "6000
Demonstration Lab"

The CDC MSS was a ripoff of a simliar product by IBM. IBM made
reliable tape devices, All CDC's sucked.

Computer rooms by their nature are supposed to be spot less.

But...

I complained once that the janitors used those 30inch cicurlar buffers
with steel-wool pads to buff down the floors. I remembers bits of
broken steel wool flowing around the room where ever we walked.

Management was totally blind to this stupidity until I told them. Then
it stopped immediately.

I also remember the use of cirgarette ash (dabbed from ashtrays
brought into the computer lab, to polish the tape heads. No
commercially made product would remove the corrosion from the tape
heads.

Take some cloth, add some liguid "freon", dab some ashes, and scrub as
hard as possible to remove the deposits.

Nothing else worked.




>
>
>Bob Lidral
>lidral at alum dot mit dot edu

[Bob Lidral]

Silver Bells wrote:
> ...
> FB: I too worked at Arden Hills from mid 1968 thru 1971 in the "6000
> Demonstration Lab"
>
I never actually worked there. I took a tour as part of my New Hire
class, I took a few classes up there, and I tried to run a benchmark
there once. It was a holiday weekend I think (July 4th, maybe) and the
regular Benchmark Lab had shut down or maybe the Benchmark Lab was
already booked 24/7. So, at somebody's suggestion, I wandered up to
Arden Hills and wandered the halls until I found a machine room. The
only machine that looked plausible had the rear panels open and a bunch
of spaghetti hanging out the back. So I found another machine and
couldn't figure out how to start it. I found someone else wandering the
halls (it was probably about 11 PM) and he explained to me the second
machine was a 176 so it wouldn't have been useful anyway (I was still
new and not familiar with the physical appearance of the product line
and, of course, it didn't have a model number on it). We finally got
the first machine deadstarted and I was able to do some benchmarking,
but it was a surreal experience.

> The CDC MSS was a ripoff of a simliar product by IBM. IBM made
> reliable tape devices, All CDC's sucked.
>
CDC seemed to be able to sell 9-track tape drives, though. My big
problem with CDC's tape drives was the software. The software for them
really sucked. When I escaped from grad school (uh, that should read,
"left to enter the workforce") in 1978, I copied all of my projects
(completed, half-finished, and barely-begun) to 800 BPI 9-track tapes.
It seemed the most portable format at the time. For the IBM files, it
was simple: ANSI-standard multi-file labeled tapes in EBCDIC encoding
(they were, after all, intended to be used on an IBM architecture and
CDC's FORM claimed to be able to read all sorts of IBM tape formats --
and did a fair job). For the CDC machine, I tried to write
ANSI-standard multi-file labeled tapes using ASCII encoding.

The CDC tapes were a nightmare. I would try to write something like 17
files and then try to verify the tape. The verification step would only
show something like 12 files the first time and then maybe only 8 the
second time I tried it. I tried to write the tapes several times and
finally gave up on the verification, deciding to hope fervently that the
tapes had the intended data on them and that I would be able to read
them somehow at some future time.

By the time I finally could afford enough personally owned or rented
disk space, I had trouble finding a tape drive that could handle 800 BPI
tapes (should have used 1600 BPI -- sigh). When I finally did get them
converted to CD years later by a commercial data recovery establishment,
I learned that the CDC machine had correctly labeled the files on the
tape but, despite my explicit specifications (at least according to the
documentation), they had been written in CDC display code which wasn't
readable by the people who did the copy to CD. So I finally had them
copy the raw bits to CD and I had to write a conversion program to read
3 8-bit bytes at a time, assemble them into a 24-bit chunk, break it up
into 4 6-bit fields, and then convert those into 4 8-bit ASCII
characters (this last was the easy part). An amusing exercise, I
suppose (well, to me -- I suspect I've bored everyone else in this group
-- sorry 'bout that).


> Computer rooms by their nature are supposed to be spot less.
>
> But...
>
> I complained once that the janitors used those 30inch cicurlar buffers
> with steel-wool pads to buff down the floors. I remembers bits of
> broken steel wool flowing around the room where ever we walked.
>
> Management was totally blind to this stupidity until I told them. Then
> it stopped immediately.
>
> I also remember the use of cirgarette ash (dabbed from ashtrays
> brought into the computer lab, to polish the tape heads. No
> commercially made product would remove the corrosion from the tape
> heads.
>
> Take some cloth, add some liguid "freon", dab some ashes, and scrub as
> hard as possible to remove the deposits.
>
> Nothing else worked.
>
My favorite janitor story has to do with a Tandem machine. One of my
employers supplied software to a medical testing company that required
24/7 reliability -- hence their decision to use Tandem fault-tolerant
platforms (MIPS architecture running NonStop-UX). We were involved in a
joint venture with another software firm for this customer. Naturally,
whenever something went wrong we and the other joint-venture firm would
point fingers at each other (they were usually at fault, but we usually
had to prove it to them -- another long story and really OT).

Anyhow, the customer complained that the software stopped and restarted
(losing data and context) every night. Neither we nor our joint venture
partner could figure out the cause and the customer could never provide
any useful information because it always happened late at night when
nobody was there. Finally one night, one of the customer's programmers
was pulling an all-nighter in the machine room and discovered the cause.

Very late at night, he heard a vacuum cleaner in the hallway; it ran for
awhile and then stopped. Shortly thereafter, the door to the machine
room cracked open; a hand reached in and unplugged the Tandem in order
to plug in another cord. The vacuum cleaner started up again for a few
minutes and then shut off. The door to the machine room cracked open
again and a hand reached in to unplug the vacuum cleaner and plug the
Tandem back in. Then the Tandem started up (it was configured to reboot
after a power outage) again.


Bob Lidral
lidral at alum dot mit dot edu

[Shmuel (Seymour J.) Metz]

In <***@4ax.com>, on 01/11/2008
at 07:24 PM, Silver Bells <***@earthlink.net> said:

>FB: I never know where the "924" fit in or what it was used for.

As I recall it was for process control.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to ***@library.lspace.org

[LR]

Fred Bradford wrote:

> Then another machine, the 6200 came along. A slowed down 6400. (Simply
> the clock slowed down, nothing else. Cost the same to build but sold
> at more narrow profit margin. Not successfull.)
>
> An internal joke was that it was "field upgradable to a 6400" for just
> a few thousand dollars. The upgrade was a toggle switch hidden
> inside to increase the clock speed to that of the 6400!!!


My recollection is that for these kinds of machines, particularly for
machines like the 6600, slowing down the clock might result in much
cheaper maintenance.

I think that one of the 170 series machines had a similar clock speed
and upgrade path.

Perhaps that was part of the point for the 6200?

LR

[Bob Lidral]

LR wrote:
> Fred Bradford wrote:
...
> My recollection is that for these kinds of machines, particularly for
> machines like the 6600, slowing down the clock might result in much
> cheaper maintenance.
>
> I think that one of the 170 series machines had a similar clock speed
> and upgrade path.
>
> Perhaps that was part of the point for the 6200?
>
> LR

This is from my memory of 1982 - 1983 and at least some of it is
hearsay, so it may be a little off. I believe that was the 173 -> 174
upgrade.

There was an error in the marketing literature for the 170 series that
mis-stated the MIPS rate for the 173, claiming it was faster than it
actually was. For some reason, it apparently never got updated. Of
course salespeople and management believed the printed values and
couldn't be persuaded otherwise.

I met a former CDC employee once who had been a Shark analyst. He got
PO-ed at CDC because part of his reward for being a Shark was a free
trip to some resort area but he had to share a double room with someone
else. He felt that if he'd contributed that much to the CDC bottom
line, the least they could do was give him his own room -- so he quit.

Anyhow, before he left, he had discovered the problem during a benchmark
and tried to get CDC to reprint the material with the corrected 173 MIPS
rate. Either they didn't do it or the salesmen and managers never saw
the reprints.

One customer had ordered a pair of 173s in a competitive bid because the
published MIPS rate met their requirements more cost effectively than
any other company's offerings. They were shipped and installed at the
customer site for an evaluation period. During the evaluation, the
customer discovered that one of the 173s was fast enough for their
application but the other was too slow. Unfortunately, the 174, while
fast enough, was not as cost-effective as some of CDC's competitor's
solutions so the customer wanted to send the "slow 173" back for
replacement with a "fast 173" (which, of course, didn't exist).

The difference between the 173 and 174 was reputed to be a single jumper
on the 173 to slow it down. Somebody forgot to connect that jumper on
one of the machines so it was actually a 174. The salesman, known far
and wide for aggressive and "creative" solutions (and a no-prisoners
attitude towards co-workers) was rumored to have demanded that the CE
remove the jumper from the 173 to turn it into a 174 without telling
anyone. The CE refused unless his own manager would approve it; his
manager required approval from above and eventually the problem made its
way all the way to HQ.

I heard (I wasn't directly connected with that project) that CDC sent 3
or 4 VPs to the customer to discuss the issue. My feeling was that CDC
should have admitted they sent a 174 by mistake and just offer to
provide the customer with two 174s for the price of two 173s for that
one site. It was then explained to me that it wasn't just the lease
price on the hardware that differed. Apparently CDC charged different
lease rates for software depending on the platform. Thus, for example,
the same FTN compiler cost more to lease for a 174 than for a 173.

I don't know how it was resolved. I was transferred to another state
before then and somehow the resolution wasn't as interesting as the
problem so I never followed up.


Bob Lidral
lidral at alum dot mit dot edu