14 Jul
2015
14 Jul
'15
1:55 p.m.
From: Paul Koning
> I have a hard time coming up with other machines
with the same level
> of impact/influence, in terms of CPU internal architecture. Maybe
> Atlas, or the 801?
CDC 6600, of course.
I guess I don't know the 6600 that well (I have the book, and have skimmed it
in the past). What are the novel features in the 6600 that were widely
adopted by other machines? (I listed the Atlas because of paging, and the 801
because of RISC.)
Noel
14 Jul
14 Jul
2:26 p.m.
On 07/14/2015 10:55 AM, Noel Chiappa wrote:
I guess I don't know the 6600 that well (I have
the book, and have skimmed it
in the past). What are the novel features in the 6600 that were widely
adopted by other machines? (I listed the Atlas because of paging, and the 801
because of RISC.)
There are more than a few folks who call the CDC 6000 one of the first
RISC machines. In particular, the 6600 with its instruction scheduling
and reservation control, multiple functional units, instruction cache,
etc. was quite noteworthy. You could easily recognize the earmarks of
a very different machine of the time. The issues that arose when
programming later RISC CPUs made me feel that I was back in familiar
territory.
3-address architecture, 60 bit ones complement words, with separate sets
of registers for addresses and indexing.
A typical beginning programmer's problem was to write a CPU loop to move
non-overlapping fields of words in the shortest amount of time (ECS not
available). The best solution usually involved two words per iteration,
with one instruction issue per cycle; bottom of the loop load (to
overlap the branch) and top-of-the-loop store.
Another challenge was to write a routine that could load and store the
values of all registers from and to memory. Not as simple as it sounds.
For me, one distinguishing feature is that there is no condition code
register. You could branch on a register value being signed or zero, or
compare and branch on the values of two index registers. Thus, the
result of an operation was covered by the regular register reservation
rules.
The I/O processors (PPUs) had access to all of CPU memory and
essentially were their own world, using a 12-bit instruction set derived
from the 160A. One could also say that the PPUs were
only one machine
with memory and registers being time-multiplexed to simulate 10
machines.
--Chuck
2:42 p.m.
Back at a more general level. To my way of thinking what Bob Supnik did
in software can be extended by producing a hardware replica vehicle for
his code to give the illusion that the original system has been
recreated. A sort of machine Turing test if you will.
Rod Smallwood
/
/
/On 14/07/2015 19:26, Chuck Guzis wrote://
/
On 07/14/2015 10:55 AM, Noel Chiappa wrote:
I guess I don't know the 6600 that well (I
have the book, and have
skimmed it
in the past). What are the novel features in the 6600 that were widely
adopted by other machines? (I listed the Atlas because of paging, and
the 801
because of RISC.)
There are more than a few folks who call the CDC 6000 one of the first
RISC machines. In particular, the 6600 with its instruction
scheduling and reservation control, multiple functional units,
instruction cache, etc. was quite noteworthy. You could easily
recognize the earmarks of a very different machine of the time. The
issues that arose when programming later RISC CPUs made me feel that I
was back in familiar territory.
3-address architecture, 60 bit ones complement words, with separate
sets of registers for addresses and indexing.
A typical beginning programmer's problem was to write a CPU loop to
move non-overlapping fields of words in the shortest amount of time
(ECS not available). The best solution usually involved two words per
iteration, with one instruction issue per cycle; bottom of the loop
load (to overlap the branch) and top-of-the-loop store.
Another challenge was to write a routine that could load and store the
values of all registers from and to memory. Not as simple as it sounds.
For me, one distinguishing feature is that there is no condition code
register. You could branch on a register value being signed or zero,
or compare and branch on the values of two index registers. Thus, the
result of an operation was covered by the regular register reservation
rules.
The I/O processors (PPUs) had access to all of CPU memory and
essentially were their own world, using a 12-bit instruction set
derived from the 160A. One could also say that the PPUs were only one
machine with memory and registers being time-multiplexed to simulate
10 machines.
--Chuck
3:25 p.m.
On Jul 14, 2015, at 2:42 PM, Rod Smallwood
<rodsmallwood52 at btinternet.com> wrote:
Back at a more general level. To my way of thinking what Bob Supnik did in software can
be extended by producing a hardware replica vehicle for his code to give the illusion that
the original system has been recreated. A sort of machine Turing test if you will.
I don?t think so, because SIMH does not (and does not aim to) deliver all the obscure
details of the original hardware, only those that are relevant to ordinary software.
paul
5:35 p.m.
Hi
Oscar Vermeulen managed to get an 8/I replica going using a
Raspberry Pi and Bob's code.
You do have to hook into the code of course. I want to do an 8/e the
same way.
Regards Rod
On 14/07/2015 20:25, Paul Koning wrote:
On Jul 14,
2015, at 2:42 PM, Rod Smallwood <rodsmallwood52 at btinternet.com> wrote:
Back at a more general level. To my way of thinking what Bob Supnik did in software can
be extended by producing a hardware replica vehicle for his code to give the illusion that
the original system has been recreated. A sort of machine Turing test if you will.
I don?t think so, because SIMH does not (and does not aim to) deliver all the obscure
details of the original hardware, only those that are relevant to ordinary software.
paul
2:32 p.m.
On Jul 14, 2015, at 1:55 PM, Noel Chiappa <jnc at
mercury.lcs.mit.edu> wrote:
RISC. I/O processors. Multiple instructions in process at the same time. (Not
pipelining, that came a year or two later in the 7600). Interlocking machinery to handle
memory ordering (?stunt box?) and register access ordering (?scoreboard?). Very fast
memory cycling for its day. Extremely efficient context switching.
That?s a good start.
paul
From: Paul Koning
> I have a hard time coming up with other
machines with the same level
> of impact/influence, in terms of CPU internal architecture. Maybe
> Atlas, or the 801?
CDC 6600, of course.
I guess I don't know the 6600 that well (I have the book, and have skimmed it
in the past). What are the novel features in the 6600 that were widely
adopted by other machines? (I listed the Atlas because of paging, and the 801
because of RISC.)
4:35 p.m.
On Jul 14, 2015, at 3:55 PM, William Donzelli
<wdonzelli at gmail.com> wrote:
Sure, but channel controllers and PPUs are very different beasts. You can?t run your OS
on a channel controller, which is exactly what Cray did on the 6600. Nor can you
implement the entire operator user interface on a channel controller, as was done in the
DSD PPU program.
paul
...I/O processors.
I do not think you can claim that the 6600 I/O processors were all
that new. Many (most?) of the 1960s mainframes before the 6600 had
channel controllers. 
4:48 p.m.
Sure, but channel controllers and PPUs are very
different beasts. You can?t run your OS on a channel controller, which is exactly what
Cray did on the 6600. Nor can you implement the entire operator user interface on a
channel controller, as was done in the DSD PPU program.
Yes, I realize that a CDC PPU is a very versatile I/O processor,
compared to channel controllers from other vendors, but the PPU idea
pretty much stayed with CDC and nobody else. It fails the "novel
features in the 6600 that were widely adopted by other machines" test.
--
Will
4:37 p.m.
On 07/14/2015 12:55 PM, William Donzelli wrote:
Perhaps not, but they were unique in their implementation (one "logic
core" multiplexed among 10 memories and register sets) and the
application os same. Prior to about 6000 SCOPE 3.4, most of the OS
logic was present in the PPUs, not the CPU. IIRC, in SCOPE 3.3, the
only CP part of the OS was the storage move program. PPs communicated
among themselves and used numerous "overlays" to accomplish the
supervisory funciton. You could have the CP at a dead stop with the OS
happily ticking along. SCOPE 3.4 moved more of the functionality
I don't think that was ever done with earlier machines.
In contrast, almost none of SCOPE 2 for the 7600 was in the PPs, which
had access only to pre-assigned buffers in CM (or SCM if you will).
7000 SCOPE was implemented using an interesting system of overlapping
field lengths, such that the user program was the innermost.
I've never heard of an operating system, handling all job supervisory
functions and I/O in a S/360 channel.
--Chuck
...I/O
processors.
I do not think you can claim that the 6600 I/O processors were all
that new. Many (most?) of the 1960s mainframes before the 6600 had
channel controllers. 
5:05 p.m.
Going all the way back to at least the IBM 7090, and presumably the 709,
though I have not actually checked. The B5000 had IO processors as well.
On 7/14/2015 2:55 PM, William Donzelli wrote:
...I/O
processors.
I do not think you can claim that the 6600 I/O processors were all
that new. Many (most?) of the 1960s mainframes before the 6600 had
channel controllers.
--
Will
5:47 p.m.
On 07/14/2015 02:05 PM, Jay Jaeger wrote:
Going all the way back to at least the IBM 7090, and
presumably the 709,
though I have not actually checked. The B5000 had IO processors as well.
Again, you're missing the point. The system *starts* with a PPU and
loads the CPU up to run. OS was pretty much entirely within the PPUs.
PPUs have autonomous access to the entire memory space of the CPU and
use the "exchange jump" to switch it to a task.
What was the stumbling block was that this was incompatible with virtual
memory schemes and other similar arrangements that fragmented the memory
space of the CPU. Transient real-time tasks, whose existence could be
measured in a millisecond or two were also unsuited for this setup.
The point is if the PP setup had been limited to I/O, the CPU with no
privileged mode (at the time; eventually a "monitor mode" was
introduced) would have been useless for most purposes. In fact, if an
address violation or arithmetic fault occurred, the CPU would store the
reason and just half. To issue a request to the PP OS, a CPU program
would store a request in word 1 of its field length and then hang.
--Chuck
6:28 p.m.
On 07/14/2015 02:53 PM, William Donzelli wrote:
That's true--but at the time, CDC's design made a huge amount of sense.
The CPU was left to do what it did best--crunch numbers without the
burden of managing the I/O activity and responding to interrupts. In
that sense, the CPU was treated as more of a peripheral device. In
fact, you could order a CPU-less system. (6416?)
You can still see the general scheme implemented today on the Parallax
Probeller MPU, which, some, I'm sure will tell you, is a pretty nifty
design.
--Chuck
Again,
you're missing the point.
This was a fairly specific CDC Cyber thing - not a widely adopted idea
in the industry, as was originally asked for.
The channel controller/director idea, on the other hand, was very
widely adopted.
6:42 p.m.
That's true--but at the time, CDC's design
made a huge amount of sense. The
CPU was left to do what it did best--crunch numbers without the burden of
managing the I/O activity and responding to interrupts. In that sense, the
CPU was treated as more of a peripheral device. In fact, you could order a
CPU-less system. (6416?)
What was the point of that machine? For people doing OS development only?
--
Will
7:40 p.m.
On 07/14/2015 03:42 PM, William Donzelli wrote:
More aimed at expanding the I/O capabilities. You could, for example,
hook the 6416 up to a couple million words of ECS. Remember too, that
CDC thrived on QSEs.
--Chuck
That's
true--but at the time, CDC's design made a huge amount of sense. The
CPU was left to do what it did best--crunch numbers without the burden of
managing the I/O activity and responding to interrupts. In that sense, the
CPU was treated as more of a peripheral device. In fact, you could order a
CPU-less system. (6416?)
What was the point of that machine? For people doing OS development only?
9:10 p.m.
Almost sounds like the CPU was kind of an "attached processor" - similar
to the way vector processors have been implemented by IBM and others.
On 7/14/2015 5:28 PM, Chuck Guzis wrote:
On 07/14/2015 02:53 PM, William Donzelli wrote:
That's true--but at the time, CDC's design made a huge amount of sense.
The CPU was left to do what it did best--crunch numbers without the
burden of managing the I/O activity and responding to interrupts. In
that sense, the CPU was treated as more of a peripheral device. In
fact, you could order a CPU-less system. (6416?)
You can still see the general scheme implemented today on the Parallax
Probeller MPU, which, some, I'm sure will tell you, is a pretty nifty
design.
--Chuck
Again,
you're missing the point.
This was a fairly specific CDC Cyber thing - not a widely adopted idea
in the industry, as was originally asked for.
The channel controller/director idea, on the other hand, was very
widely adopted.
9:34 p.m.
On 07/14/2015 06:10 PM, Jay Jaeger wrote:
Almost sounds like the CPU was kind of an
"attached processor" - similar
to the way vector processors have been implemented by IBM and others.
I suppose you could view it that way. There were CPU-less 6000 boxes,
but no PPU-less ones.
--Chuck
11:36 p.m.
On 07/14/2015 07:11 PM, William Donzelli wrote:
The 6416 was a special beast--I don't know that CDC ever produced any
standard software for it. It had 16KW of CM and it's own ECS coupler, so
I suppose that it could share ECS with other machines--but IIRC the ECS
access was via its own special instructions.
I suspect that some 6416s just communicated with other systems using the
6682(?) satellite coupler. I suspect that they were largely superseded
by the "additional PPU" machines.
I never ran into a 6416 in the flesh, but was aware of more than one 20
PPU 6000 (there were never enough PPUs). CDC also offered "PPU-reduced"
models of the 6400, with up to 3 PPUs removed, which never made any
sense to me.
--Chuck
I suppose you
could view it that way. There were CPU-less 6000 boxes, but
no PPU-less ones.
Were the CPU-less 6000 boxes at least connected to "normal" 6000s with
CPUs using shared ECS, or could they really be completely independent
units using their own ECS?
15 Jul
15 Jul
10:16 a.m.
On Jul 14, 2015, at 11:36 PM, Chuck Guzis <cclist
at sydex.com> wrote:
On 07/14/2015 07:11 PM, William Donzelli wrote:
The 6416 was a special beast--I don't know that CDC ever produced any standard
software for it. It had 16KW of CM and it's own ECS coupler, so I suppose that it
could share ECS with other machines--but IIRC the ECS access was via its own special
instructions.
I just found it, in the old (rev B) version of the System Programmer?s Instant. It?s the
6411/6414 ?Augmented I/O Buffer and Controller?. And yes, it has its own ECS
instructions, which use what would normally be NOP opcodes. Interesting, given that
conventional PPUs got ECS access via the DDP, an I/O device. I suppose they wanted to
integrate it a bit better, or use less logic?
I suppose
you could view it that way. There were CPU-less 6000 boxes, but
no PPU-less ones.
Were the CPU-less 6000 boxes at least connected to "normal" 6000s with
CPUs using shared ECS, or could they really be completely independent
units using their own ECS?
I suspect that some 6416s just communicated with other systems using the 6682(?)
satellite coupler. I suspect that they were largely superseded by the "additional
PPU" machines.
I never ran into a 6416 in the flesh, but was aware of more than one 20 PPU 6000 (there
were never enough PPUs). CDC also offered "PPU-reduced" models of the 6400,
with up to 3 PPUs removed, which never made any sense to me.
Same here. The PLATO system was pretty demanding of PPUs, but still it managed with the
standard 10. Partly that may be because it didn?t really use the standard CDC ones at
all, relying on its own dedicated ones instead. One for terminal I/O, two for disk I/O,
one for OS-like functions ? four persistent ones, that still leaves another four ?pool?
PPs.
paul
12:59 p.m.
On 07/15/2015 07:16 AM, Paul Koning wrote:
I just found it, in the old (rev B) version of the
System
Programmer?s Instant. It?s the 6411/6414 ?Augmented I/O Buffer and
Controller?. And yes, it has its own ECS instructions, which use
what would normally be NOP opcodes. Interesting, given that
conventional PPUs got ECS access via the DDP, an I/O device. I
suppose they wanted to integrate it a bit better, or use less logic?
My impression is that the 6416 was a pretty early device/configuration
so it probably never saw much deployment and hence, little development.
It's an interesting beast, however.
Same here. The PLATO system was pretty demanding of
PPUs, but still
it managed with the standard 10. Partly that may be because it
didn?t really use the standard CDC ones at all, relying on its own
dedicated ones instead. One for terminal I/O, two for disk I/O, one
for OS-like functions ? four persistent ones, that still leaves
another four ?pool? PPs.
Add tape I/O and things started getting tight. You still needed PPs to
handle the unit-record stuff (1LP and 1RC, IIRC, for the printer and
card reader). Then there's Intercom and IGS... Things could get tight.
Channels were another scarce resource--and, in particular, the
request/drop implementation in software could be pretty slow. When the
Cyber 70 introduced the ILR, that helped quite a bit.
All in all, the PP scheme for I/O was less than optimal. I vividly
remember struggling with the "long tape" driver (1LT) and ECS. 1LT
attempted to get around the constraints of PP memory size by
transferring data to/from CM on the fly. This worked--after a
fashion--if the system wasn't too busy--but a single ECS transfer choked
the pyramid and the driver would get overrun/underrun issues, meaning
backspacing back to the IRG and starting all over again. A QSE
introduced the "priority bit" on PPU CM reads and writes (just set the
high order address bit), but that was disruptive to things like DSD that
were generating the display in real-time from CM information. And, of
course, that had to be sacrificed eventually on machines upgraded to 262K.
It was a nasty problem that we never really solved. I can readily
understand why Cray in the Cray-I completely dodged the issue of I/O and
just provided a big pipeline.
--Chuck
16 Jul
16 Jul
2:45 p.m.
----- Original Message -----
From: "Chuck Guzis" <cclist at sydex.com>
To: <General at classiccmp.org>;
"Discussion at classiccmp.org:On-Topic and Off-Topic
Posts" <cctalk at classiccmp.org>
Sent: Tuesday, July 14, 2015 5:47 PM
Subject: Re: Reproducing old machines with newer
technology
On 07/14/2015 02:05 PM, Jay Jaeger wrote:
...
Going all the way back to at least the IBM
7090, and presumably the 709,
though I have not actually checked. The B5000
had IO processors as well.
Again, you're missing the point. The system
*starts* with a PPU and loads the CPU up to run.
OS was pretty much entirely within the PPUs.
PPUs have autonomous access to the entire memory
space of the CPU and use the "exchange jump" to
switch it to a task.
--Chuck
----- Reply -----
Not the same thing of course but remotely
on-topic, and I never miss an opportunity to put
in a plug for Cromemco:
By comparison, Cromemco used semi-autonomous 4MHz
Z80A SBCs for their I/O processors, with 16KB of
local RAM and up to 32KB of ROM; communication
with peripheral cards is via a separate 50-pin
'C-Bus'.
What's interesting and sort-of-relevant is that
later versions of Cromix (their UNIX work-alike)
could use the IOP to run Z80 programs, especially
useful in a system having only a 680x0 main CPU.
FWIW, their hard disk controller also used a 4MHz
Z80A with 8KB ROM and 64KB RAM that could cache 4
entire tracks.
m
17 Jul
17 Jul
12:21 p.m.
On 07/16/2015 11:45 AM, Mike Stein wrote:
Not the same thing of course but remotely on-topic,
and I never miss an
opportunity to put in a plug for Cromemco:
By comparison, Cromemco used semi-autonomous 4MHz Z80A SBCs for their
I/O processors, with 16KB of local RAM and up to 32KB of ROM;
communication with peripheral cards is via a separate 50-pin 'C-Bus'.
That wasn't all that uncommon in the microprocessor world--once the
price dropped sufficiently, doing multiuser applications by giving each
user their own CPU was practical. Molecular was another outfit that did
practically the same thing.
Dual-CPU setups, where the "weaker" of the two CPUs was in control of
the "stronger" one were even more numerous--just consider the number of
"add in" processor cards for the PC archicture. 68K, NS32xxx...you name
a CPU, it's probably been on an ISA card.
And there's the veneered and generated Radio Shack 68K series (16, 16B,
6000) where it's the Z80 that starts things and controls the show
initially, even if you're running Xenix.
In pretty much all cases, the system is capable of running without the
"stronger" CPU.
--Chuck
12:27 p.m.
That wasn't all that uncommon in the
microprocessor world--once the
price dropped sufficiently, doing multiuser applications by giving each
user their own CPU was practical. Molecular was another outfit that did
practically the same thing.
Dual-CPU setups, where the "weaker" of the two CPUs was in control of
the "stronger" one were even more numerous--just consider the number of
"add in" processor cards for the PC archicture. 68K, NS32xxx...you name
a CPU, it's probably been on an ISA card.
The common UK example is the BBC micro. It was a complete useable
6502-based computer, but could have a 'second processor' added
via an interface known as the 'tube'[1] The 6502 in the BBC micro handled
I/O functions, while user programs ran on the second processor. The ones
I know of are
6502 (ran BBC software including BBC BASIC, but faster than the plain BBC)
Z80 (ran CP/M)
32016 (ran something called PANOS)
ARM
There were also a couple of (fairly rare) Acorn machines which consisted of
a BBC B+ mainboard in a case with a built-in monitor and disk drives and
a second processor board. The ABC (Acorn Business Computer) had a Z80, the
ACW (Acorn Cambridge Workstation) had a 32016
[1] So called (officially) because it provided a 'tube' to pass information
between
the 2 processors. But of course 'Tube' is a common name for the London
Underground
(subway) and 'Bus' is anotherr form of public transport. As a total aside, the
system
bus on the Tatung Einstein was called the 'Pipe', presumably a pun on
'tube', for all
that machine never took second processors.
-tony
19 Jul
19 Jul
12:06 a.m.
----- Original Message -----
From: "Chuck Guzis" <cclist at sydex.com>
To: <General at classiccmp.org>;
"Discussion at classiccmp.org:On-Topic and Off-Topic
Posts" <cctalk at classiccmp.org>
Sent: Friday, July 17, 2015 12:21 PM
Subject: Re: Reproducing old machines with newer
technology
On 07/16/2015 11:45 AM, Mike Stein wrote:
----- Reply -----
AFAIK Cromemco never went the 'CPU for every user'
route; multi-user systems were implemented using
the multi-user Cromix OS, with a 64K memory card
for each user in a Z80 system and dynamically
allocated memory in a 680x0 system, but always
with only one CPU in control.
The early versions of Cromix ran on a Z80; when
they brought out the dual-CPU Z80/680x0 processor
cards you could still run the Z80 version or the
68K version which would use the Z80 as required
for Z80 software.
When the single 680x0 processor cards came out
along with the memory management hardware required
to run UNIX they needed a way to still run Z80
(i.e. CP/M or CDOS) software, and that's where the
ability to use a Z80 on an I/O controller was
handy.
I always wondered which was more efficient,
multiplexing among essentially complete 'computers
per user' sharing a common I/O 'channel' or
swapping processes and memory banks...
m
Not the same thing of course but remotely
on-topic, and I never miss an
opportunity to put in a plug for Cromemco:
By comparison, Cromemco used semi-autonomous
4MHz Z80A SBCs for their
I/O processors, with 16KB of local RAM and up
to 32KB of ROM;
communication with peripheral cards is via a
separate 50-pin 'C-Bus'.
That wasn't all that uncommon in the
microprocessor world--once the price dropped
sufficiently, doing multiuser applications by
giving each user their own CPU was practical.
Molecular was another outfit that did
practically the same thing.
Dual-CPU setups, where the "weaker" of the two
CPUs was in control of the "stronger" one were
even more numerous--just consider the number of
"add in" processor cards for the PC archicture.
68K, NS32xxx...you name a CPU, it's probably
been on an ISA card.
And there's the veneered and generated Radio
Shack 68K series (16, 16B, 6000) where it's the
Z80 that starts things and controls the show
initially, even if you're running Xenix.
In pretty much all cases, the system is capable
of running without the "stronger" CPU.
--Chuck
12:19 a.m.
On 7/18/2015 10:06 PM, Mike Stein wrote:
I always wondered which was more efficient,
multiplexing among
essentially complete 'computers per user' sharing a common I/O 'channel'
or swapping processes and memory banks...
m
I can't think of any system for the average user that runs
efficient.
Ben.
PS: I have a strong dislike of virtual <anything>.
1:26 a.m.
On 07/18/2015 09:06 PM, Mike Stein wrote:
I always wondered which was more efficient,
multiplexing among
essentially complete 'computers per user' sharing a common I/O 'channel'
or swapping processes and memory banks...
Well, the multiplexing (via hardware) memory among a single processor
did have the advantage that it was possible to hang a single "processor"
without taking down the whole shebang--you could simply label the
processor as unavailable in the processor pool. Believe me, when
debugging PPU programs that was very handy--hang a PPU, try again,
without rebooting the system.
Later versions of the Cyber (e.g. 170/180) actually used separate
completely autonomous processors.
--Chuck
8:45 a.m.
On Jul 19, 2015, at 12:06 AM, Mike Stein <mhs.stein
at gmail.com> wrote:
...
I always wondered which was more efficient, multiplexing among essentially complete
'computers per user' sharing a common I/O 'channel' or swapping processes
and memory banks?
If you?re talking about switching a single resource (or fixed set of resources) among
consumers, the answer doesn?t directly tie to the technical approach used but rather to
the efficiency of switching among consumers.
For example, a multiprogramming OS has to do a context switch. That may require one or
two instructions, which may be very fast (CDC 6600 ? about 3.5 microseconds) or not so
fast (VAX). Or it may take a few hundred instructions (most machines).
But you may also find more limited sharing systems where the switching is so fast that it
isn?t a factor in the performance. The timesharing of the PPU logic in a CDC 6600 is an
example: the logic is that of a 10 MHz class machine, but the memory is 1 MHz, so 10x
sharing of the logic among 10 memory banks and 10 sets of state makes sense.
That approach still exists; nowadays it?s called ?hardware threads (as in the mutithreaded
MIPS processors from Sibyte/Broadcom and Raza/Broadcom and others) or ?hyperthreading?.
But, as with so many things, Cray did it first.
paul
2:26 a.m.
On Wed, Jul 15, 2015 at 7:05 AM, Jay Jaeger <cube1 at charter.net> wrote:
...though I have not actually checked. The B5000 had
IO processors as well.
Not quite, the B5000 and B5500 arguably had DMA channels (up to 4 of
them), but not independent IO processors (with their own machine code)
that were seen on the later follow-on B6500 family (B6700, B7700) with
the DCP (which had an associated definition language NDL).
B6500 peripherals (like Datacomm) were back-ported to the B5700 (a
re-badged B5500 with optional B6500 peripherals) seemingly as a
stop-gap due to delays in delivering the B6500.
3287
days inactive
3292
days old
29 comments
10 participants
participants (10)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cube1＠charter.net -
jnc＠mercury.lcs.mit.edu -
mhs.stein＠gmail.com -
nw＠retroComputingTasmania.com -
paulkoning＠comcast.net -
rodsmallwood52＠btinternet.com -
wdonzelli＠gmail.com