[rescue] IBM on ebay
dave at cca.org
dave at cca.org
Wed May 15 21:46:21 CDT 2002
james at foonly.com writes:
>RISC was coined by David Patterson in 1980 at UCB. At that point in time
>it did mean a reduced ISA, with the goal of both a low cycle count per
>instruction and a simple die that could be run at higher speeds. RISC-I
>(1982) and RISC-II (1984) were the archetypes. 32-bit, 138 registers,
>330-ns cycle time with one cycle per opcode.
I really need to dig up the articles on those... I didn't know RISC-I
dated that far back.
>In the mid 80's IBM "redefined" the term to indicate a reduced instruction
>cycle count, rather than a reduced ISA. This roughly coincided with the
>unveiling of ROMP. They pushed the term "Reduced Instruction Set Cycles"
>heavily. They continued this marketing trend through the development of
>the PPC and it is to this that I was referring. I consider the POWER
>string instructions highly non-RISCy as they added microcode bloat and
>broke the one cycle per opcode convention. I blame IBM heavily for the
>abuse of the RISC term.
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?
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.)
>Believe me, I am not laboring under any misconceptions as to what RISC
>was/is. "RISC" in the IBM sense caused die bloat over leaner
>architectures, mips was a marvel of simplicity by comparison.
MIPS seems to be the favourite amoung the idealists. Has the performance
too...
>> After the market settled down and it became clear what was a win, I
>> think "RISC" became: "fixed length instructions & load/store". (Which
>> qualifies as "reduced instrcutions" as you describe above.)
>Other common features: lots of registers, no suboptimal (unaligned)
>accesses, register set orthogonality. These are all of course present in
>some "CISC" archs as well. VLIW blurs the line even more.
Registers is a side effect of load/store, so I don't count that.
Banning unaligned accesses is a good point. Very much in the
"this complexity is not worth it" school of theought.
I consider VLIW to be an alternative approach to RISC, but definately
RISC. If you look at each sub-instruction in a VLIW word, it's definately
RISC. The instruction word is just the grouping. (Yeah, it's more important
than that, and the implications to the compiler writers are monsterous,
but still. It's just a bunch of RISC instructions.)
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.
------ David Fischer ------- dave at cca.org ------- http://www.cca.org ------
-------- "I prefer the ridiculous to the sublime." - James Chance ---------
More information about the rescue
mailing list