dolphin memos
Al Kossow
some more, and I've recovered some information on Dolphin, which was
to be built of ECL macrocell arrays, with 1.5 KL performance. There was
also going to be a multiprocessor coupler with provisions for cache
coherency.
http://bitsavers.org/pdf/dec/pdp10/KXF10_Dolphin
I also found some memos on Jupiter performance (under KC10_Jupiter/memos)
** Posted from http://www.teranews.com **
Pat Farrell
> to be built of ECL macrocell arrays, with 1.5 KL performance. There was
> also going to be a multiprocessor coupler with provisions for cache
> coherency.
How close to release did the Dolphin get? The memos all have 78 dates,
while 1.5 KL in 78 was not all that interesting by 1980, it might have
helped. And it sure would have given strapped KL sites someone to talk to.
--
Pat Farrell
http://www.pfarrell.com/
Al Kossow
> How close to release did the Dolphin get?
Given the technological complexity, it couldn't have been more than
a paper design. The papers on it are dated to early '79. I think it was
abandoned later that year to work on something with a faster IBOX/EBOX
with the same circuit technology (Jupiter). I'll have to dig and see
when the earliest Jupiter memos are from. I know I've seen some from 1980.
Dropping Dolphin for Jupiter and who architected the new IBOX/EBOX is
something I'm curious about. I had heard the person who did it had a
360 background, and didn't understand the pipelining problems of 10's
(indirect addressing?) that didn't get caught until the prototype.
Pat Farrell
> didn't understand the pipelining problems of 10's
> (indirect addressing?) that didn't get caught until the prototype.
We were given a huge push on how great the Jupitor would be because of
pipelining, and then I heard from several reliable engineering sources
that it just didn't deliver, the pipelining didn't bring the benefits
that were promised.
As the good book says, the effective address is calculated before
anything else happens. Talk about a pipeline stall
glen herrmannsfeldt
> We were given a huge push on how great the Jupitor would be because of
> pipelining, and then I heard from several reliable engineering sources
> that it just didn't deliver, the pipelining didn't bring the benefits
> that were promised.
> As the good book says, the effective address is calculated before
> anything else happens. Talk about a pipeline stall
I suppose so, but what fraction of the time is it indirect?
What fraction double indirect?
Maybe even something like the 360/91 (described in all books
on pipelined processors), with reservation stations.
Instruction decode would do the effective address calculation
and submit the result to a reservation station. When the
appropriate processing unit is available, the operation is
started.
The 91 even has enough logic to detect self-modifying
code that modifies instructions already fetched and to
correct for that. (Self-modifying code wasn't so uncommon
in those days. Even the Fortran library did it.)
The complication of the 91 is imprecise interrupts. I don't
know how that would have affected a PDP-10.
-- glen
Al Kossow
> Dropping Dolphin for Jupiter and who architected the new IBOX/EBOX is
> something I'm curious about. I had heard the person who did it had a
> 360 background, and didn't understand the pipelining problems of 10's
> (indirect addressing?) that didn't get caught until the prototype.
I've renamed several of the KC10 memos on bitsavers since it turns out Mike
Uhler wrote up a memo describing programming workarounds for the pipelining
problems
uhler_Programming_for_a_Pipelined_Machine_19830427.pdf
uhler_Impressions_from_a_visit_to_Foonly_19830719.pdf is also interesting
in how Dave got the performance he did out of the F1.
Would be interesting to see a similar description of the SC30.
jmfbah
> Pat Farrell wrote:
>
>> We were given a huge push on how great the Jupitor would be because of
>> pipelining, and then I heard from several reliable engineering sources
>> that it just didn't deliver, the pipelining didn't bring the benefits
>> that were promised.
>
>> As the good book says, the effective address is calculated before
>> anything else happens. Talk about a pipeline stall
>
> I suppose so, but what fraction of the time is it indirect?
> What fraction double indirect?
Don't forget about indexing.
<snip>
/BAH
Pat Farrell
> glen herrmannsfeldt wrote:
>>> As the good book says, the effective address is calculated before
>>> anything else happens. Talk about a pipeline stall
>>
>> I suppose so, but what fraction of the time is it indirect?
>> What fraction double indirect?
>
> Don't forget about indexing.
Yes, I think indexing was far more of a problem than indirection. Tons
of code would do something like
MOVE T1,mumble
MOVE T1, fratz(t1)
which was a screaming stall for the second instruction
glen herrmannsfeldt
(snip)
> Yes, I think indexing was far more of a problem than indirection. Tons
> of code would do something like
> MOVE T1,mumble
> MOVE T1, fratz(t1)
> which was a screaming stall for the second instruction
Since S/360 doesn't have an indirect bit, all indirect
addressing is done that way. Well, if you mean the reuse
of T1, register renaming fixes that. Using the same register
is fairly common for S/360 code.
Well, the goal of the 360/91 was averaging one instruction
per cycle, with floating point being the slow part
(and with 13 clock cycles for memory access and no cache).
So the floating point processing was pipelined and out of
order execution was used, such that fast instructions could
finish ahead of slower instructions.
-- glen
jmfbah
I loved to do double-indexing.
/BAH