| HN Mirror

My original post was about the futility of debating RISC vs CISC, supporting OP. The idea that RISC has very few instructions that are near register-level single-cycle: load/store/add/subtract/branch, etc. But in reality there is a tendency for these instructions to be come more tied to the hardware, compiler, or application; hundreds of opcodes that perform multiple RISC operations per opcode is very un-RISC-y. Same with multi-cycle operations that are tied to specific hardware, thus not "pure". Same goes for applications. (The classic example is the Arm "RISC" instruction called "FJCVTZS", or "Floating Point JAVASCRIPT convert to signed rounding to Zero". There's an entire HN thread on this from years ago.)

The crux of my argument is the review and ratification of extended compiler switches that add lots of functionality that becomes less about core compute and more about APPLICATIONS and HARDWARE. And that's where things get CISC-y. Hence the futility of comparing RISC v. CISC: if the clean-slate RISC-V project runs into this, stop arguing the the legend/myth because it is a waste of energy.

My use of the term "wacky" was a poor choice. My problem with the first reply is because they insist that isn't the case, sneers at me, and says "tell me what you think is wrong and I tell you why you are wrong..." That's flamebait, because there are several other replies that the post brushes off with more flamebait.

HARDWARE:

RISC-V has extensibility in the ISA, and T-Head added instructions that require an ASIC. So now we have an ISA+ that very clearly is hardware dependent. Should RISC-V really have entertained Alibaba's hardware-specific SIMD instructions as part of the standard, even if they are enabled with compiler switches? That's a question that will have consequences. RISC-V's biggest market is by far China, so maybe it makes sense? But these opcodes are "wacky" (ugh) in the sense because they require THead hardware, and are very CISC-Y.

I'll stop picking on T-Head. Consider the extensions for non-temporal instructions based on memory hierarchies. This is incredibly hardware specific. But of course, there will always be memory hierarchies regardless of vonNeuman v. harvard designs. And they can be left out of course. But still they will only apply to specific implementations. Much like machines that don't have FPUs cannot make use of FP opcodes, machines without hierarchies cannot make use of non-temporal instructions. So do FPU instructions not belong in the ISA, of course not.

APPLICATIONS:

Does an ISA need vector crypto? Well, it is an extension, so it can be turned off, but AES could easily become post-quantum obsolete. So why bloat the ISA? Sqrt/Sin/Cos will never become obsolete, but AES might.

Even security and privilege levels. Hypervisor extensions, and execution + code isolation extensions force a particular way of doing things on an ISA.

MY DARNED POINT

To recap: I may have made the biggest strawman of all time, but it is based on what I keep hearing. It is easy to wave away all four of my examples if you think RISC-V-can-do-no-wrong. But that misses my point: ISAs are complicated, and when you have hundreds of instructions that do complex things in multiple cycles with lots of side effects that are required by certain hardware or certain applications ... you no longer have a reduced instruction set computer. Even when the best minds start from a clean slate to create RISC they end up with CISC.

Which is why I think the debate is bunk and wastes everyone's time. It was entirely the product of 1990's marketing against Intel and still plagues us today.