← Back to context

Comment by 6SixTy

19 hours ago

My take is that it could help tie up fragmentation. RISC-V has different profiles defining what instructions come with for different use cases like a general purpose OS, and enshrining them as an ISO standard would give the entire industry a rallying point.

Without these profiles, we are stuck with memorizing a word soup of RV64GCBV_Zicntr_Zihpm_etc all means

riscv was already gaining a profile mechanism outside of ISO, for example 'RVA23' is a known set of extensions

Hardly, see programming languages standards and compiler specific extensions.

  • languages are more fluid than processor architectures. I don't think they can be compared.

    • One would think, yet welcome to enterprise consulting, especially customers whose main business is not selling software.

      You will find fossilized languages all over the place.

      1 reply →

RISC-V never had a fragmentation problem, thanks to the profiles.

  • I wouldn't say it never had a problem, but the profiles are definitely a reasonable solution.

    However even with profiles there are optional extensions and a lot of undefined behaviour (sometimes deliberately, sometimes because the spec is just not especially well written).

    • The FUD keeps being brought up, but the solution here was in place before the potential issue could manifest.

      It started with G, later retroactively named RVA20 (with a minor extra extension that nobody ever skipped implementing), then RVA22 and now RVA23. All application processor implementations out there conform to a profile, and so do the relevant Linux distributions.

      Of course, in embedded systems where the vendor controls the full stack, the freedom of micromanaging which extensions to implement as well as the freedom to add custom extensions is actual value.

      The original architects of the ISA knew what they were doing.