Pipelining and Dec Jupiter thoughts....

[Chris Zach]

> Sort of.  But while a lot of things happen in parallel, out of order, speculatively, etc., the programming model exposed by the hardware still is the C sequential model.  A whole lot of logic is needed to create that appearance, and in fact you can see that all the way back in the CDC 6600 "scoreboard" and "stunt box".  Some processors occasionally relax the software-visible order, which tends to cause bugs, create marketing issues, or both -- Alpha comes to mind as an example.

Interesting to see this.

I've been reading a lot recently about the Jupiter/Dolphin project and 
the more I read the more I understand why it just could not be done. At 
the time (and to an extent even now) the only way to really improve a 
system's performance was to pipeline the processor, and the Pdp10 
instruction set just wasn't easy to do that with.

They had a great concept: An Instruction fetch/decode system (IBOX), an 
execution engine (EBOX), the obligitory vector processor or FPU (HBOX) 
and of course the memory system (MBOX). Break the process up into steps 
and have the parts all work in parallel to boost performance.

Unfortunately they started to find way too many cases where an indirect 
instruction would be fetched that would be based on the AC, which was 
being changed by another instruction in the EBOX. This would blow out 
all the prefetched work in the pipe, forcing the IBOX to do a costly 
reload.

Likewise branch prediction couldn't be done well because most branches 
and skips depended on the value in the AC which was once again usually 
being modified in the EBOX down the pipe. As soon as it was modified the 
pipe had to be flushed and reloaded. It looks like they tried to put 
that logic into the IBOX to catch these issues, but that resulted in a 
flat processor that wasn't going to benefit from any parallelism, an 
endless series of bugs, and an IBOX that was pretty much running with 
its own EBOX.

It got worse when they realized that the Extended memory segments in the 
2060 architecture totally wrecked the concept of an instruction 
decoder/execution box. There were just too many places where an indirect 
instruction to another section which was then based on the AC's would 
result in Ibox tossing the queue and invalidating the translation 
buffers. Increasing the translation buffer helped (I think that's one of 
the things they did on the final 2065 to make it faster) but they 
couldn't make that big and fast enough. I guess an indirect jump 
instruction based on comparing the AC to an indirect address pointing to 
an extended segment would be enough to make any decoder just cry.

It's sad to read, you can almost see then realizing it was doomed. The 
Foonly F1 was a screamer, but it was basically the KA10 instruction set 
and couldn't run extended memory segments like the 2060. And when they 
tried to do the same thing with the F4 it came out to be a little slower 
than a 2060. I used to think they put only one extended segment in the 
2020 to cripple the box, but maybe they started running into the same 
problem and ran out of microcode space to try and address it.

Couple this with the fact that much of the 20 series programs were built 
in assembler (and why not, it was an amazing thing to program) and you 
just had too many programs with cool bespoke code that would totally 
trash a pipeline. Fixing compilers to order instructions properly could 
have worked, but people just wrote in assembler it wasn't going to 
happen and they weren't about to re-code their app to please the new 
scheduler God.

The VAX instruction set was a lot less beautiful, but could be pipelined 
easier especially with the dedicated MMU so they took the people and 
pipelined the hell out of the 780 resulting in the nifty 8600/8650 and 
later the 8800's. Dec learned their lesson when they built Alpha, and 
even Intel realized that their instruction set needed to be pipelined 
for the Pentium Pro and above processors.

Ah well. I don't think it was evil marketing or VAX monsters that killed 
the KC10, it was simply the fact that the amazing instruction set 
couldn't be pipelined to make it more efficient for hardware and the 
memory management system wasn't as efficient as the pdp11/Vax MMU concept.