Hacker News Reader

Hacker News

Comment by pjmlp | Hacker News Reader

Parent Full thread

pjmlp

I also lived through it, but I would say that RISC won in the end, just not exactly as its proponents thought.

x86 are no longer real CISC, as they moved the internal architecture to RISC, starting with the Pentium 4.

And all the other processors that matter are also RISC.

The real loosers were the VLIW proponents.

View on HN

Sounds suspicious to claim victory while redefining terms. :)

I'm curious which processors that matter are all RISC. I mean, I realize there are a fair bit of chips out there. I wouldn't have thought many of them really fit the original RISC mold. Sure, they have less instructions than some of the old behemoths. But, that is a far cry from the aims of RISC.

There is also the rise in specialized processors. Combining that with the increased focus on consolidating everything into one chip, and much of the debate is just weird nowdays.

Aren't ARM and the majority of micro-controlers RISC?

I think that really depends on perspective. Calling micro-controllers RISC versus CISC sorta misses the point. They are of course reduced from general processors. Does that make them RISC, though?

Easy way to consider it, a GPU would probably not qualify as a RISC processor, but it also probably has fewer overall operations than a CISC processor. (Or, do they qualify nowdays?)

Now, ARM definitely is. It remains to be seen whether they can continue to be dominant once Intel enters the same arenas.

I've read arguments that CISC now has a speed advantage because its denser instruction encoding is more friendly on the cache. If true, then ARM's RISC instruction set would hold it back from ever competing with x86 on speed.

x86 doesn’t really have a dense instruction encoding. The old un-prefixed scalar instructions are dense, but they do much less work per instruction than SSE or AVX instructions, which have two or three byte prefixes (four with AVX-512). arm64 instructions are all four bytes, for comparison.

The upshot is that simple scalar code tends to be somewhat more compact on x86, and tuned vector code (likely to be found in perf-critical routines that are CPU-bound) tends to be somewhat more compact on arm.

More to the point, loop buffers and µop caches on the last couple generations of processors make encoding density mostly irrelevant to performance (though occasional pathological examples do still exist).

"More to the point, loop buffers and µop caches on the last couple generations of processors make encoding density mostly irrelevant to performance"

As in, the part where x86 processors get to fully enable the "operate as a RISC" processor mode.

From my experience certain applications, mainly server workloads, have a high instruction footprint. I-cache optimizations are necessary even on an x86 processor. So there might be some weight to this argument. I'd like to see the difference in behavior between the two architectures.

Since ARM11 (ARMv6), cores have been running on Thumb 2 (16-bit instructions) and only jumping into regular 32-bit instructions when necessary. Before that there was the Thumb instruction set which according to [0] was introduced in 1994.

This makes ARM (especially ARMv7 and newer) a mixed setup like x86.

[0] - https://en.wikipedia.org/wiki/ARM_architecture#Thumb

Thumb2 only became standard with ARMv6. There are a few ARMv6 cores which implemented Thumb2 (as opposed to Thumb1), but they aren't in many commonly used products. The ARM1176 for instance as used in the Raspberry Pi is Thumb1 only.

Granted.

I suppose my point is that ARM is going towards the same inbetween-ism that x86 has moved to.

Reply on news.ycombinator.com