3 ms·

There's far more than 2. Even just taking RV32I, you have M, A, F, D standard extensions which are all optional. A CPU could include any combination of these,

There's far more than 2. Even just taking RV32I, you have M, A, F, D standard extensions which are all optional. A CPU could include any combination of these, so you have 3! possible instruction sets off the start line. But let's assume we're working with G (which means all of IMAFD) Many PC grade processors will support some or all of extensions B (bitmanip), T (transactional memory), P (packed SIMD), V (Vectors), C (compressed instructions), RV64I, RV128I, Q (quad floats), and not to mention all the non-standard extensions. See: https://groups.google.com/a/groups.riscv.org/g/isa-dev/search?q=public%20review%20extension https://groups.google.com/a/groups.riscv.org/g/isa-dev/searc... for non-standard extensions. You also have vendor specific extensions such as those from Huawei: https://github.com/riscv/riscv-code-size-reduction/tree/main/existing_extensions/Huawei%20Custom%20Extension https://github.com/riscv/riscv-code-size-reduction/tree/main... As an application developer, finding the right set of features for your users will mean having to distribute many different binaries unless you stick to plain old RV32G, which has the capabilities of a ~20 year old x86 processor. If you assume all standard extensions, it only takes a processor to lack 1 of them for the program to not work. You can test for feature sets before running any of these instructions, but this is more commonly done at compile time via the preprocessor. This is what I mean about developers changing their perspective. It will be necessary to move all of those #ifdef __FEATURE__ to runtime, unless you recompile on each processor.

Vt71fcAqt7 4y ago
>As an application developer, finding the right set of features for your users will mean having to distribute many different binaries unless you stick to plain old RV32G, which has the capabilities of a ~20 year old x86 processor. Do you mean RV64G? Linux doesn't really support 32 bit anymore. Even then the VisionFive 2 supports rv64gc And the whole board sells for ~50 USD. The d1 supports RV64GCV (admittedly v. 0.7) and sells for even less. I don't think any Linux CPUs will skimp on C and most will have V and B in my opinion.
- sparkie 4y ago
  The set of RISC-V processors is going to be far more diverse than you are expecting. There's already dozens of open cores, both 32-bit and 64-bit, with varying support of standard extensions. Assume RVG64GBCV, do we skip P, T, Q? What about J (extensions for dynamic language runtimes)? Do we just ignore those capabilities and leave applications to not get the best out of the machine? If we stick to current status quo, of having #ifdef __FEATURE__ scattered through our code, we would want a source based distribution like Gentoo to make sure we get the most out of our machines, so we can check which features are present and set all the required compiler flags. Otherwise, we could have runtime checks for features, but this will require changing the way applications are commonly written, because we don't want to be checking for the presence of features everywhere in code. We only want to check once on application startup.
hajile 4y ago
It seems like you didn't even bother to read the linked spec. The result is a bad faith argument on your part where you are choosing to ignore the clearly stated facts. You also ignore the reality of x86 and ARM extension fragmentation. If you want people to use your chip in an interchangeable way (how ALL desktop processors want to work), then you'll implement RVA22S64 which automatically requires you to support a bunch of extensions. If you want proprietary or cutting-edge extensions in your chip, feel free, but software developers will be using the spec and your extras will just be ignored and drive up your cost for no real value. If you violate the specs you claim to support, you are liable for trademark infringement as use of the trademark requires adherence to any standards you claim to be supporting. At most you could claim "RISC-V compatible", but that will just become code for "doesn't work with normal software" and nobody will buy your chips and you'll have wasted a huge sum of R&D money. This is better than x86 or ARM which you conveniently ignore. x86 for example has some 55 extensions released in the last 20 years. Some like SGX or FMA4 only have support of a small subset of chips. Some have disappeared. Many aren't supported by older chips still commonly in use. ARMv8 has TEN different version PLUS more optional extensions PLUS the ability to add custom instructions. There's also FOUR versions of ARMv9 too (leaving aside the still very popular ARMv6 and v7). If fragmentation were such a huge problem, then certainly nobody would be using these ISAs. Of course, people use them everywhere which completely disproves your argument.

Vt71fcAqt7 4y ago

>As an application developer, finding the right set of features for your users will mean having to distribute many different binaries unless you stick to plain old RV32G, which has the capabilities of a ~20 year old x86 processor. Do you mean RV64G? Linux doesn't really support 32 bit anymore. Even then the VisionFive 2 supports rv64gc And the whole board sells for ~50 USD. The d1 supports RV64GCV (admittedly v. 0.7) and sells for even less. I don't think any Linux CPUs will skimp on C and most will have V and B in my opinion.

sparkie 4y ago
The set of RISC-V processors is going to be far more diverse than you are expecting. There's already dozens of open cores, both 32-bit and 64-bit, with varying support of standard extensions. Assume RVG64GBCV, do we skip P, T, Q? What about J (extensions for dynamic language runtimes)? Do we just ignore those capabilities and leave applications to not get the best out of the machine? If we stick to current status quo, of having #ifdef __FEATURE__ scattered through our code, we would want a source based distribution like Gentoo to make sure we get the most out of our machines, so we can check which features are present and set all the required compiler flags. Otherwise, we could have runtime checks for features, but this will require changing the way applications are commonly written, because we don't want to be checking for the presence of features everywhere in code. We only want to check once on application startup.

hajile 4y ago

It seems like you didn't even bother to read the linked spec. The result is a bad faith argument on your part where you are choosing to ignore the clearly stated facts. You also ignore the reality of x86 and ARM extension fragmentation. If you want people to use your chip in an interchangeable way (how ALL desktop processors want to work), then you'll implement RVA22S64 which automatically requires you to support a bunch of extensions. If you want proprietary or cutting-edge extensions in your chip, feel free, but software developers will be using the spec and your extras will just be ignored and drive up your cost for no real value. If you violate the specs you claim to support, you are liable for trademark infringement as use of the trademark requires adherence to any standards you claim to be supporting. At most you could claim "RISC-V compatible", but that will just become code for "doesn't work with normal software" and nobody will buy your chips and you'll have wasted a huge sum of R&D money. This is better than x86 or ARM which you conveniently ignore. x86 for example has some 55 extensions released in the last 20 years. Some like SGX or FMA4 only have support of a small subset of chips. Some have disappeared. Many aren't supported by older chips still commonly in use. ARMv8 has TEN different version PLUS more optional extensions PLUS the ability to add custom instructions. There's also FOUR versions of ARMv9 too (leaving aside the still very popular ARMv6 and v7). If fragmentation were such a huge problem, then certainly nobody would be using these ISAs. Of course, people use them everywhere which completely disproves your argument.