I wrote math performance specifically, because that code size is larger and didn't have to be, arguably shouldn't be.

The problem is that, when people say "math", they usually refer to HPC, or sometimes machine learning, or in very rare occasions, symbollic math. They usually don't mean arbitrary-precision math. In fact, I'm not aware of a single serious computation field that must depend on arbitray-precision math. Usually in HPC or ML, if your model overflows, then your model just overflowed.

So for those scenarios, I haven't heard of code-size problem argument against RISC-V.

It may be a performance problem more specifically. More instructions / result = more instruction fetches and cache space used = lower peak performance than there would be otherwise.

Who knows? Maybe an extension addresses this and becomes dominant.

It's just more wordy per result than it could be, and it seems a poor choice given all the other pretty great ones made.

It is physically and logically impossible for any one practical ISA to optimally cover every one of the thousands of highly specialised application areas.

You, apparently, really really care about arbitrary-precision adds.

RISC-V is a general purpose ISA. It can do any computing task, just perhaps not optimally.

How non-optimal is it for arbitrary-precision adds? Or, more importantly, for the overall application that is a part of. No one who has raised this as a concern has shown any actual numbers. In fact they don't even show the actual loop doing the arbitrary-precision add, with loop control instructions, loads and stores. All they show is that a single "add-with-carry" instruction in some other ISAs translates to several instructions in RISC-V.

The problem, if any, in your application area can be solved by adding a single custom instruction to the ISA.

That doesn't sound like something fundamentally wrong with the ISA. Especially when that ISA is designed from the start to be extensible by users via adding custom instructions.

We will see. I think flags in general have enough advantages that the chip really should have them.

And it's not just an arbitrary Precision. There's a variety of constructs that will be longer.

And hey, it's not like I'm anti. We'll see where it all goes, and if it really does shake out like the proponents say, this will just be an academic matter.

I would rather some really good instructions be part of the base set just so they have broad coverage. The whole just add a rando instruction idea doesn't appeal to me at all.