[socialdemocrat]

No, because verification tools are made to verify that you don’t take an extension for granted. Compilers as far as I know are made to generate code for different extensions. The CPU also contains registers to check what extensions are present.

ARM is what it is because license holders are required to implement the whole ISA. RISC-V is kind of the opposite. You are required to assume extensions are optional.

And OS is supposed to trap instructions not implemented and jump to a software emulation of them.

I don’t know all the details. But the point is they are planning for this from the start and building their tools around this. That was never the case for ARM or x86. Hence it is premature to assume it will end up the same.

[imtringued]

It's time to talk about a completely different domain that makes programming be heaven. In electrical engineering there is no such thing as a generic component. There are only implementations of them and you have to pick among the company provided implementations. Imagine if you had to specifically choose a 4Ghz grade if statement in your programming language or make sure your while loop supports 1.3V on the CPU. You need to have a good mental model of how the statement are implemented to choose the right one.

That's how bad electrical engineering is. Programming is bliss in comparison. You can do the dumbest things and it still works out. Your computer will never go up in flames even in the most bug ridden C code base. RISC-V will bring this to a lesser extent to software development. There will be no "general" RISC-V CPU. Instead you have to constantly worry about whether your CPU supports these instructions. Implementing fallbacks will just cause very inconsistent performance drops among CPU manufacturers. Think of things like the Intel compiler disabling SIMD on AMD cpus except this time it's because the manufacturer didn't bother to implement a "bloated extension" where only one instruction is actually used but when it is used it's in Fortnite or some other popular game so you do extremely poorly in benchmarks.

[eeZah7Ux]

> You can do the dumbest things and it still works out. Your computer will never go up in flames even in the most bug ridden C code base.

...and that, unfortunately, explains the quality of a lot of software and the low entry bar for the industry.

[sifar]

The issue is not whether SW can work around optional extensions. The point is that if you want a general purpose performant cpu (like ARM/x86) targeting a wide swath of applications, you will end up with these optional extensions as default. And then it is as bloated as others. We are not talking about micro-architecture optimization here to make it more performant, but isa architecure.

Ofcourse, you can change the computing module to minimal base isa and specific accelerations in ISA/HW. But then you will be restricted to niche applications and never replace the incumbents for general purpose workload.

>> Hence it is premature to assume it will end up the same.

And it is wishful thinking that it will happen otherwise. Whether ARM/x86 thought about extension from the ground up doesn't matter if you are targeting the same application space as them.

I have not seen anything done to even acknowledge this issue, let alone do something about it, for the simple reason that this lies far into the future and has no impact on the current scenario.

Given time and legacy software, it will morph into one.

[socialdemocrat]

> The point is that if you want a general purpose performant cpu (like ARM/x86) targeting a wide swath of applications, you will end up with these optional extensions as default.

Yes, but the number of instructions is still minuscule compared to ARM and x86. It am sitting with the reference sheet here in my hand. It is just two pages. Very quick to read over.

> And then it is as bloated as others.

Eh... nope. A huge number of those instructions exist due to cruft building up over years, not due to an actual need. A major source the huge number of instructions is tons of SIMD instructions which have superseded each other. RISC-V designers have specifically sought to avoid this preferring a Vector extension instead which adds a lot fewer instructions as it is more flexible.

People keep saying that is complex, but several companies have already made implementations of this. Esperanto Technologies is making SoCs with over 1000 RISC-V cores with vector extensions. So it cannot be that complex if they can fit that many cores.

And the compiler technology is better developed for vector instructions than for SIMD.

> And it is wishful thinking that it will happen otherwise.

It is not wishful thinking to assume a couple of lessons have been learned decades later in ISA design. You can just read up on the details about how the RISC-V ISA has been designed to understand how they are able to keep things simple while still retaining flexibility.

> Whether ARM/x86 thought about extension from the ground up doesn't matter if you are targeting the same application space as them.

The flaw in your assumption is that you seem to think all those instructions are actually used and need to be able to handle modern tasks. Tell me how much software today needs special instructions for Binary encoded decimal numbers? x86 is full of that kind of legacy bloating the ISA, with no value to modern software.

> I have not seen anything done to even acknowledge this issue, let alone do something about it, for the simple reason that this lies far into the future and has no impact on the current scenario.

I think you should just read what they have said about all these things. They have thought a lot more about this than you seem to have. They been doing ISA design for many decades and seen problem develop over time. RISC-V is a response to all those problems of the past. To not build yet another bloated ISA with redundant legacy instructions.