[rescue] IBM on ebay

[James Lockwood]

On Wed, 15 May 2002 dave at cca.org wrote:

> I really need to dig up the articles on those... I didn't know RISC-I
> dated that far back.

Patterson started RISC-I in 1980.

He's still lectures at UCB and is a marvel to listen to.  He was the first
member of the SPARC team at Sun and has some rather amazing war stories.

> Someone told me that they strapped a CISC bag on the side of POWER, like
> what they did to the original clean CDC-6600 design. Memory-memory
> string operations, something like that. Is that true? Are those the
> string ops you're talking about?

Right, instructions along the lines of CPIR/LDIR in Z80-land.

> I think the original obsession with one-cycle-execution was misplaced.
> If you're load/store, then your instructions tends to be simpler, because
> they don't have that much data to work on (you can't have the VAX's linked
> list instructions operating on registers....). So it's a side-effect of
> a good, clean, fast, design. But I don't think it should be a primary
> goal. (That all gets *really* dependent on the internal design of the
> processor. Anything that adds complexity to the internal data paths
> had better *really* be worth it.)

Depends on the cost of complexity.  Back in the 60's, microcode was a
major win due to the different costs of implementation of RAM and core.
Today, die space and latency are all-important.  Who knows what tomorrow
may bring?

> MIPS seems to be the favourite amoung the idealists. Has the performance
> too...

Original mips was a good example of proto-VLIW (Microprocessor without
Interlocked Pipeline Stages).

> Registers is a side effect of load/store, so I don't count that.

I can think of many load/store archs that were short on registers, but
most of that was due to high register implementation cost at the time.

> I like to look at processor design in terms of real-estate allocation.
> How much of your transistor dubget is working on the *user's* problem,
> and how much is going to overhead? That's why I'm so anti-Itanium.
> VLIW has the least control logic overhead possible, and yet they managed
> to turn that around and add all sorts of insanely baroque realtime
> accounting crap to it.

The effects of a pipeline spill on Itanium are scary.

-James