You're missing the point. You said "The ISA [and ratified extensions] has a soup of wacky opcodes". You're being asked to name a single wacky opcode from the ISA and ratified extensions. The response mentioned only vendor-specific extensions having bad opcodes.
The reply is an obvious troll. Whenever someone yawns at your post, dismisses, and then decides to be the arbiter of what constitutes valid (classic fallacy), walk away. Proof? Others did reply and Op just pisses on them verbally. If you don’t know how to read the ratified extensions which OP admitted we’re harmful, just walk away from the topic.
As an interested observer, I would like to know more about what you're talking about - it's not trivial to find the T-Head RISC-V extensions or identify which ratified extensions are 'wacky opcodes' or related. I agree that the OP has a biased view in favour of RISC-V, but it's also natural to react strongly to attacks like "soup of wacky opcodes".
I can see that RISC-V has made some short-sighted decisions (like having no carry flag or equivalent), and has a good few ratified extensions. But how does it compare to other architectures? I think everyone would agree that x86/x64 is a soup of wacky opcodes; is modern ARM(+SVE) better than RISC-V in this regard?
Why is having no carry flag "short-sighted"? Rather, it is dropping the unneeded historical baggage.
A carry flag was useful on an 8 bit CPU where you were constantly dealing with 16 bit and 32 bit numbers. On a 64 bit CPU it is almost never used, and updating it on every add is an absolute waste of resources.
Having integer operations wrap by default is a significant source of security issues, so having no other kind of addition and making it even harder to spot when it happens is not what my choice would be (I'd have both flags and trapping as options, at least). I should choose more charitable language.
I'd suggest that the unneeded historical baggage is default-wrapping integer operations, rather than carry flags. Back then, CPUs needed the simplicity.
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.
AES, particularly AES-256, is considered quantum resistant/safe. AES-128 could have its keysize effectively reduced to 64 bits with Grover's Algorithm (AES-256 to 128 bits), but scaling quantum computers to do that brute force search is not as straightforward as building a bunch of FPGAs or ASICs.
