RISC-5

[Little stoned kiwi]

I got drawn in by the clickbate and am glad I did. He says some interesting things.

[NorthWay]

Oh, the algorithm had already fed me this one and I liked it too - good people on both ends and interesting things said.

AFAIK the only ones saying anything contraire to what the industry is following as conventional wisdom is the Mill people (who are also doing a lot of other things), and possibly the Itanium was trying too.
I don't know what the original paper was, but AFAIK it said that "normal" code had a branch instruction for every 3-4 instructions. That either limits how much it is worth to decode per clock cycle, or you get exponential heroics needed for your out-of-order execution as you walk down both paths of a branch.
Mill seems to think they can architect themselves out of that, and in that context a big and irregularily sized instruction set is definitely a dead-end.
(BTW, did anyone ever try to redefine RISC as "Regular"?)

[Dio]

Nobody walks down both sides of a branch, ever. It's ruinous to perf/W.

[Little stoned kiwi]

Is it a case of how far you walk down the predicted path, with performance reliant on the accuracy of prediction?

[Dio]

As long as your branch prediction accuracy is more than 50% - and it's in the high 90s - walking both sides of a branch means doing more work that you then throw away and that cannot not cost power.

[venusian]

RISC-V might be the next big thing, but my money's on a CISC comeback, or rather, complex memory machinery behind a RISC influenced instruction set.

My logic goes like this:

RISC became popular because building complex cores was hard and RISC made it easy (or at least easier) to do smart stuff at high speed around pipelines, prediction, OoOE and so forth. Also processor designs were more space constrained i.e. a core took up a high proportion of a die so it was valuable to make the cores simpler and smaller.

The cost was in memory access. All the simple but increasingly high speed stuff puts a massive strain on the memory architecture, a problem only made exponentially worse by SMP. So now we have tiny cores next to massive, highly complex cache hierarchies.

There are two big problems looming: compute capacity and security. Capacity is being addressed through GPGPU-esque sytems and massively parallel arrays of cores with private memories both of which reduce memory pressure by having multiple busses and being a little bit NUMA.

Security will addressed (and this is my main assertion here) by complex memory access systems like capability addressed memories. This implies some really knarly addressing modes and multi-cycle instructions which are anathema to RISC. These are also slow and have high latency (sometimes). The mitigation is to return to more complex cores which do more per memory access, but that's okay because, relatively speaking, cores are now tiny on-die so there's plenty of room to grow and we have better tools to manage the design complexity.

Arm's CHERI project is an example. And those ole big-iron folk can sit in their rocking chairs and nod sagely.

[Dio]

I don't think I see it. At a time when dead silicon costs more than it ever has before, you need very good motivation to add accelerators which only activate in very specific scenarios.

[venusian]

I'm not, I think, suggesting an occasional accelerator, rather more complexity in the core that one can't avoid using all the time. It might sell be less efficient in terms of TOPS but it would rarely be dead area.

[Dio]

But then you need to answer the question of what problems it directly solves that exist in all compiled code. This is why RISC wins. By reducing the instruction set of the computer to the most frequently used things nearly everything is used nearly all the time.

Or, put it another way. Let's say you have 4 addressing modes in RISC and 20 in CISC - it's totally inherent that each CISC mode can on average only be used 5% of the time (well, multiplied by your IPC).

I mean, I'm still interested. But I'd need a clear line of sight from your 'complex stuff' to 'this is used everywhere in every program' to not call it dead silicon - or a use case like floating point / vectorised ops where the dead silicon eventually pays for itself in power/perf on specific key scenarios like video decode.

[gilesgoat]

But then you need to answer the question of what problems it directly solves that exist in all compiled code. This is why RISC wins. By reducing the instruction set of the computer to the most frequently used things nearly everything is used nearly all the time.

Or, put it another way. Let's say you have 4 addressing modes in RISC and 20 in CISC - it's totally inherent that each CISC mode can on average only be used 5% of the time (well, multiplied by your IPC).

I mean, I'm still interested. But I'd need a clear line of sight from your 'complex stuff' to 'this is used everywhere in every program' to not call it dead silicon - or a use case like floating point / vectorised ops where the dead silicon eventually pays for itself in power/perf on specific key scenarios like video decode.

<Parenthesis ( because I wrote this "somewhere else" this morning ) >

I told you once ( you did not listen ) , I am telling you again, "If you want to sell 300% more AMD CPUs what you REALLY need is a CPU with some transparent crystal top and RGB LEDs embedded ( that change some colours according to CPU activity ) "

Turst me, you'll sell more with that ( and it's going to cost you less to implement ) than RISC/CISC .. ..

</Parenthesis>

.. ok back to the normal thread ..

[edit] - semiserious, becuase I am/was debugging certain things .. I THINK that we could say that GPU shaders are "a good example" about "how you can do MANY things with very little instructions" ..

If you look at a dump of a shader code .. it almost looks like "3 instructions repeated 50 times" ..

Something like FMULADDDIVIFNOTZEROELSELOADANDSTORE ( array or FP registers ) ( array of PTRs registers ) ..

.. and that's almost it .. branches ? Hum .. maybe not, who needs branches ?

[Little stoned kiwi]

Perhaps it's worth emphasising the use cases in the video are specific and specialised. The criticism toward Intel/AMD/ARM seems to be what's under the hood and how protective the vendors are of it.

More general are Jim's opinions such as RISC-V dominating in 10 years. That's a tough call as Intel/AMD/ARM/nVidea won't want that. Google is pulling back on Android support at the moment. But on the other hand, RISC-V has been progressing.

Then there's the licensing. I expect most companies will be licencing their own "under the hood" secrets themselves. The advantage of RISC-V as a foundation must be attractive to companies and countries that don't want or can't have access to licensing from the main vendors.

[Dio]

AMD is largely agnostic to what ISA wins. You want to build a chip that gets IPC like Ryzen, the design is kind of fixed, and the ISA is just a small chunk over there in the corner.

The big lesson learned from the early RISCs like MIPS and SPARC was that trying to solve silicon-level architectural issues in the ISA (with things like branch delay slots) was a bad idea. I suspect one of the reasons ARM has gone as far as it has is because they didn't do that.

[venusian]

Why is it a bad idea? (That's a straight question, bit a challenge?) Clearly that's how the market orthodoxy went, but what drove that? It feels like moving instruction scheduling issues into static analysis problems would be a worthwhile win.

I worked on a VLIW DSP in the early 2000s that relied on the compiler to detect and resolve hazards, orderings and result forwarding delays and suchlike by producing only valid instruction packets. I wonder if compilers in general's inability to do that as robustly as hardware is the reason?

With C/C++ toolchains unable to progress much beyond targeting variations on VAX, CPUs also had to continue presenting themselves as really fast VAXen.

[venusian]

After cycling into work, my brain has pointed out that in contexts where one expects to run the same binaries on a range of machines, baked in optimisations would quickly become pesimisations.

You'd need to ship programs in some kind of IR/bytecode and optimise on load. Not a million miles from the current situation with x64 on Arm, I suppose.

[Dio]

Why is it a bad idea? (That's a straight question, bit a challenge?) Clearly that's how the market orthodoxy went, but what drove that? It feels like moving instruction scheduling issues into static analysis problems would be a worthwhile win.

I worked on a VLIW DSP in the early 2000s that relied on the compiler to detect and resolve hazards, orderings and result forwarding delays and suchlike by producing only valid instruction packets. I wonder if compilers in general's inability to do that as robustly as hardware is the reason?

It's great for the first iteration. But then you realise you need another two cycles in your pipeline and suddenly you have to either 1. change the ISA and invalidate all the old code or 2. build all the complicated logic that you thought you could leave out because you were clever enough to put it in your ISA.

VLIW largely failed for the same reason. It persisted longer in GPUs because they have a per-system compile phase, but even there we eventually dropped it (personally, I think because the ISA was completely f***ing unreadable to humans).