riscv-profiles

For what it's worth, the RISC-V unprivileged spec says: > The behavior upon decoding a reserved instruction is UNSPECIFIED. > Some platforms may require that opcodes reserved for standard use raise an illegal-instruction exception. Other platforms may permit reserved opcode space be used for non-conforming extensions. The RVA23 says: (https://github.com/riscv/riscv-profiles/blob/main/src/rva23-...) > Implementations are strongly recommended to raise illegal-instruction exceptions when attempting to execute unimplemented opcodes or access unimplemented CSRs. and has an optional extension "Ssstrict": > Ssstrict No non-conforming extensions are present. Attempts to execute unimplemented opcodes or access unimplemented CSRs in the standard or reserved encoding spaces raises an illegal instruction exception that results in a contained trap to

> Does the 23 in RVA23 refer to 2023? Yes[1]. > Do you need annual recompilations of software..? The profiles is designed to provide guarantees of what's available. Just because RVA23 was released now, does not mean the RVA22 CPUs and the software that runs on those CPUs stop working. Also, at least for the foreseeable future, the profiles will be extensions of the previous ones[2]. Thus RVA22 should be a subset of RVA23, and any software targetting RVA22 should run fine on a CPU supporting RVA23. [1]: https://github.com/riscv/riscv-profiles/blob/main/src/profil... [2]: https://github.com/riscv/riscv-profiles/blob/main/src/rva-pr...

I don't see why "moronic" was needed there. Also Risc-V has profiles that group multiple extensions together for specific use cases. For example RVA23[0] which requires 64 bit and vector extension among many others. Operating systems like android can (and most likely will) specify that they only support certain profiles.[1] Lastly, ARM is also fragmented between Armv8 and Armv7 which android developers are still supporting. >RISC-V not only isn’t that on a technical level but is fighting some serious fragmentation. Do you have any evidence to support this? Seems like RVA23 will be the first majorly supported extension. All the "high performance CPUs" right now are just dev kits, so I don't see how there can be fragmentation in a market that does not yet even exist. [0] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-... [1] ht

Ssstrict is supposed to address the undefined behaviour problem, or at least it'll make undefined instructions actually trap. https://github.com/riscv/riscv-profiles/blob/main/rva23-prof...

>there are a lot of incompatible ISA implementations of RISC-V That is a form of FUD that unfortunately shows up very often. In reality, all known application processors (e.g. made to run a software stack based on Linux), follow the RVA profile[0] spec. So do all Linux binary distributions known to support RISC-V. As well as the BSDs. Specifically, they currently target RVA20, and thus also support RVA22. 0. https://github.com/riscv/riscv-profiles/releases

That's what the "RISC-V Application Profiles" are about: to standardise a set of extensions for application-class processors. The SiFive P870 supports "RVA23"[1] which provides more or less feature-parity with ARM. It also supports vector cryptography, which is optional in RVA23. (RVA23 is the successor to last year's RVA22, making Vector and a couple smaller extensions mandatory) RVA23 + vector crypto also lines up with what Google has announced is likely to be their baseline for RISC-V - based Android handsets in the future.[2] [1] <https://github.com/riscv/riscv-profiles/blob/main/rva23-prof...> [2] <https://youtu.be/xLwdUn3DQp8?t=990>

The bit manipulation [0] extension has been ratified for a while now and is part of the RVA22 application extension profile [1]. You can already buy SOCs that support it, e.g. vision five 2 and star64. Interestingly the risc-v vector extension [2] has it's own popcount instructions for vector registers/register masks. This is needed, because the scalable architecture doesn't guarantee that a vector mask can fit into a 64 bit register, so vector masks are stored in a single LMUL=1 register. This works really well, because with LMUL=8 and SEW=8 you get 100% utilization of the single LMUL=1 vector register. Another interesting thing is that the vector crypto extension will likely introduce a element wise popcount instruction [3]. [0] https://github.com/riscv/riscv-bitmanip [1] https://github.com/riscv/riscv-profiles [2] https://github.com/ri

There is very clear incentive structure to support the standardized extension profiles. [1] Vendors will likely add their own magic on top, but the base will be one of the latest profiles, which are backwards compatible. [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

Not since RISC-V Profiles[0]. 0. https://github.com/riscv/riscv-profiles/releases

The Profiles spec which includes RVA22 was finally ratified[0] last week. 0. https://github.com/riscv/riscv-profiles/releases/tag/v1.0

Yeah unfortunately there isn't really a great place that lists all the extensions with links and ratification status. But anyway there is a sort of standard set of extensions that "application processors" (I guess CPUs that want to run precompiled code) should support: https://github.com/riscv/riscv-profiles/blob/main/profiles.a... The 22 indicates the year.

Ah, you're right: https://github.com/riscv/riscv-profiles/blob/main/profiles.a... That's good to see. (Boy, it's really hard to find info about RISC-V profiles on Google. It just seems to ignore all the letters and numbers.)

As you say this, I realize I can't find anywhere that it does. I do not know why I thought it did. Possibly as U74-MC[0] supports that option. Interestingly, I also took a look at RVA22[1], and found it requires Zbb but not the whole B. Your /proc/cpuinfo isn't listing Z* extensions. Maybe lscpu output would be more detailed? 0. https://www.sifive.com/cores/u74-mc 1. https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

The foundation releases profiles. For example, the RVA22S64 means it's a 64-bit application processor with supervisor mode complying with the 2022 recommendations. It has a bunch of specific requirements about RAM layout, cache instructions, being little-endian, and so on all specified so code is portable. Likewise M (mul/div), A (atomics) F (32-bit float), D (64-bit float), C (16-bit instructions), and some misc bit manipulation and other instructions MUST be implemented. At the same time, it specifies optional extensions like V (vector), Zfh (16-bit floats), scalar crypto, H (hypervisor), and some optional supervisor stuff. If you want to claim to be a RISC-V chip, you MUST implement the specs exactly (else be infringing on their trademark). If you want to enter the desktop ecosystem that is being started, you'd better support the exten