Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC vs. CISC: The Post-RISC Era (1999)

arstechnica.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: RISC vs. CISC: The Post-RISC Era (1999)

#41

Post by zozbot234 »

kllrnohj wrote: post #30
klelatti wrote: post #17

Earlier quoted context omitted.

> They are simpler to decode and execute, which is nice if you're making a small, cheap core aiming at low power consumption. Yes and there is an interesting corollary that it makes a big.LITTLE type arrangement more effective.

Except none of the shipping big.LITTLE implementations are "RISC" under the framework of the article, though. ARM is very definitely post-RISC and has very CISC-y features. Apple's versions go even farther and include x86 compatibility modes, very CISC-Y. And if course Intel's x86 is never accused of being RISC, either. And really the entire reason big.LITTLE even exists at all is because the cores got too large and…

These things have nothing to do with CISC vs. RISC. Apple's special x86 compatibility is about TSO model of concurrency, which though quite strong and straying far from more RISC-like approaches to concurrency (the Alpha memory model was even abandoned in more recent architectures as too weak) is not especially 'CISC' either.

Re: RISC vs. CISC: The Post-RISC Era (1999)

#42

Post by kllrnohj »

zozbot234 wrote: post #39
kllrnohj wrote: post #24

Earlier quoted context omitted.

Does it really though? Isn't RISC-V continually adding new complexity as it attempts to scale up from an ISA only useful for microcontrollers to one more competitive beyond that? The entire extension system seems pretty "CISC-y" does it not?

> Isn't RISC-V continually adding new complexity as it attempts to scale up On the contrary, some extensions are pretty clearly designed for simplicity. For example the original 'M' extension implemented both multiply and divide insns, but it was found that the latter were not always useful and required large area. So a multiply-only extension was created. The basic set of integer instructions is the one thing that's…

Reducing the register count is not a "RISC" move. It probably makes sense for the target die size of a given product, but it's definitely not something "RISC" related which was, at the time, about doing the exact opposite - increasing the register count relative to CISC CPUs.

Similarly divide wasn't removed. It's still there. Instead a second extension was added that introduced multiply-only variants. Total complexity was increased, not reduced.

Re: RISC vs. CISC: The Post-RISC Era (1999)

#43

Post by msla »

bogomipz wrote: post #31
msla wrote: post #15

Earlier quoted context omitted.

The Itanium was an interesting design and it wasn't even Intel's originally; Intel got in on HP's design, and HP was trying to leapfrog the superscalar designs by making parallelism the responsibility of software, akin to how the MIPS had made handling aggressive pipelining the responsibility of software: The Itanium design was to encode multiple instructions in very long instruction words, where all of the instructi…

>"The Itanium design was to encode multiple instructions in very long instruction words, where all of the instructions in a given word can be executed at once. I believe you are describing VLIW architecture here? Is that correct? >"This removes the need for the hardware to do reordering, and shoves the responsibility for finding parallelism onto the human or compiler, both of which can, presumably, take a more global…

> I believe you are describing VLIW architecture here? Is that correct?

Yes. The Itanium was a specific form of VLIW called EPIC, for Explicitly Parallel Instruction Computing:

https://en.wikipedia.org/wiki/Explicitly_parallel_instructio...

Wikipedia lists these modifications EPIC makes to the basic VLIW concept:

> Each group of multiple software instructions is called a bundle. Each of the bundles has a stop bit indicating if this set of operations is depended upon by the subsequent bundle. With this capability, future implementations can be built to issue multiple bundles in parallel. The dependency information is calculated by the compiler, so the hardware does not have to perform operand dependency checking.

> A software prefetch instruction is used as a type of data prefetch. This prefetch increases the chances for a cache hit for loads, and can indicate the degree of temporal locality needed in various levels of the cache.

> A speculative load instruction is used to speculatively load data before it is known whether it will be used (bypassing control dependencies), or whether it will be modified before it is used (bypassing data dependencies).

> A check load instruction aids speculative loads by checking whether a speculative load was dependent on a later store, and thus must be reloaded.

also:

> How exactly does a VLIW architecture remove the need for reordering? Is it just that any instructions in a word mean automatically mean there's no dependencies in that long instruction? Was that the original intention of VLIW?

That's exactly right: By putting the opcodes in the same word (and/or, in the case of EPIC, in a word subsequent to a previous word without the stop bit set) the entity generating the instruction stream is guaranteeing to the hardware that those opcodes can run in parallel with no problems.

> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point?

As others said, it was a mix, and, interestingly, the first few Itanium processor generations had a hardware x86 unit to provide compatibility, albeit one that executed x86 code at the speed of 100 MHz Pentium on a 667 MHz Itanium part, and Intel later commissioned software translation, which was actually faster:

https://www.informationweek.com/it-life/intel-sees-a-32-bit-...

Here's a very informative (but long) bunch of slides about Itanium in theory and practice:

https://users.nik.uni-obuda.hu/sima/letoltes/Processor_famil...

Re: RISC vs. CISC: The Post-RISC Era (1999)

#44

Post by msla »

nordsieck wrote: post #16
Animats wrote: post #11

The two extreme cases still existed in that era. One extreme was the DEC VAX. The instruction set is complex, convenient, high level, and slow. The other extreme was the original IBM 801, which led to the IBM POWER architecture. In its pure form, it was one instruction per clock, had lots of registers, and was quite simple. MIPS went down that road in a big way. Then CISC microprocessors became superscalar, and start…

> Then CISC microprocessors became superscalar, and started executing more than one instruction per clock. Now RISC machines were behind in speed. So they had to become superscalar. That killed the simplicity. There was no longer any real point to pure RISC instruction sets. I thought DEC Alpha was always ahead in speed. At least until it got bought and mostly abandoned by Compaq and then HP. Or is Alpha insufficient…

The Alpha was RISC, and, as seen in page 14 of this very long, very interesting set of slides, it eventually got passed in raw MHz by x86 chips (specifically, the 1 GHz AMD Athlon vs the 667 MHz Alpha 21164 around the year 2000) but you can see it was a close race

https://users.nik.uni-obuda.hu/sima/letoltes/Processor_famil...

This PDF shows the Alpha 21164 was superscalar:

https://acg.cis.upenn.edu/milom/cis501-Fall09/papers/Alpha21...

Re: RISC vs. CISC: The Post-RISC Era (1999)

#45

Post by msla »

bogomipz wrote: post #26
Animats wrote: post #11

The two extreme cases still existed in that era. One extreme was the DEC VAX. The instruction set is complex, convenient, high level, and slow. The other extreme was the original IBM 801, which led to the IBM POWER architecture. In its pure form, it was one instruction per clock, had lots of registers, and was quite simple. MIPS went down that road in a big way. Then CISC microprocessors became superscalar, and start…

>"The instruction set is complex, convenient, high level, and slow." Could you elaborate on how The DEC VAX ISA was complex yet also convenient? I feel like those two characteristic are at odds with each other. Or does complexity and convenience refer to different aspects i.e implementation vs use?

Convenient to assembly code authors and compiler writers. It had a lot of addressing modes and they were all almost completely orthogonal, which meant you could use them on any register, source or destination, and the hardware and microcode had to figure out how to not only execute the instruction, but back out all of the state if a fault occurred and the CPU had to handle it. In addition to its addressing modes, the VAX also had complicated opcodes, such as POLY, which evaluated a polynomial of arbitrary degree by taking an X value and a pointer to an array of coefficients.

Re: RISC vs. CISC: The Post-RISC Era (1999)

#46

Post by Mountain_Skies »

>RISC architecture is gonna to change everything. -- Acid Burn

That line from the movie Hacker's elicited many "that didn't age well" comments in the years after the movie came out but ultimately proved to be correct. It just needed a long enough timeframe to happen.

Re: RISC vs. CISC: The Post-RISC Era (1999)

#47

Post by klyrs »

Animats wrote: post #12
speed_spread wrote: post #10

Earlier quoted context omitted.

The IO and RAM for that many cores would be a bottleneck. If you manage to keep everything local to a core or a group of cores then you'll severely constrain the kind of programs you can run.

Right. However, we've had GPUs as compute engines for a while now. People have gotten better at getting massively parallel architectures to do something useful. Both machine learning and graphics fit that model. There have been many dead ends in that space, though. Thinking Machines and the Cell processor come to mind.

Indeed, a GPU is effectively a massive grid of RISC cores (and accessing global memory is a major bottleneck). I do think that "a GPU but RISCV" is an interesting proposal, but I doubt the major players would be willing to abandon their existing instruction sets

Re: RISC vs. CISC: The Post-RISC Era (1999)

#48

Post by Animats »

leeter wrote: post #33
bogomipz wrote: post #31

Earlier quoted context omitted.

>"The Itanium design was to encode multiple instructions in very long instruction words, where all of the instructions in a given word can be executed at once. I believe you are describing VLIW architecture here? Is that correct? >"This removes the need for the hardware to do reordering, and shoves the responsibility for finding parallelism onto the human or compiler, both of which can, presumably, take a more global…

> I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point? The answer is: yes Itanium failed because getting instruction parallelism is actually incredibly hard to do and compilers didn't catch up in time to make it matter. But it also failed because of AMD64 which…

> and compilers didn't catch up in time to make it matter.

Yes. I once saw am EE380 talk at Stanford by the HP team working on the Itanium compiler. They had to solve a complicated minimization problem for each block of instructions. It wasn't going well. Branch prediction decisions have to be made at compile time. Intel has built compilers where you feed tracing data back into the compiler to improve prediction, but that it never caught on.

> MIPS

MIPS compilers at one time had lots of flags for telling the compiler what specific MIPS model to target. All models had the same instruction set, but different numbers of functional units, which affected the optimal code order for each model. Software vendors were supposed to provide different executables for each model. That did not go over well.

Re: RISC vs. CISC: The Post-RISC Era (1999)

#49

Post by nordsieck »

msla wrote: post #44
nordsieck wrote: post #16

Earlier quoted context omitted.

> Then CISC microprocessors became superscalar, and started executing more than one instruction per clock. Now RISC machines were behind in speed. So they had to become superscalar. That killed the simplicity. There was no longer any real point to pure RISC instruction sets. I thought DEC Alpha was always ahead in speed. At least until it got bought and mostly abandoned by Compaq and then HP. Or is Alpha insufficient…

The Alpha was RISC, and, as seen in page 14 of this very long, very interesting set of slides, it eventually got passed in raw MHz by x86 chips (specifically, the 1 GHz AMD Athlon vs the 667 MHz Alpha 21164 around the year 2000) but you can see it was a close race https://users.nik.uni-obuda.hu/sima/letoltes/Processor_famil... This PDF shows the Alpha 21164 was superscalar: https://acg.cis.upenn.edu/milom/cis501-Fall…

While that's true, it still retained a performance advantage in floating point[1]. And that's after 2 years of neglect after being sold to Compaq.

---

1. https://www.realworldtech.com/battle64/

Post reply on HN