4 ms·

I don't fully understand riscv, but shouldn't this be something like `RV64GC`? Are they building for the base riscv with no isa extensions? This might be addre

I don't fully understand riscv, but shouldn't this be something like `RV64GC`? Are they building for the base riscv with no isa extensions? This might be addressed somewhere in the debian docs but I didn't see it.

CUViper 3y ago
RV64GC is mentioned here: https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_choice https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_cho...
- LatticeAnimal 3y ago
  Ah, thanks for that! I wonder how they plan to support future extensions like RV64GCV which seems to be gaining traction…
  - jrockway 3y ago
    Would it be much different than armhf vs. armel?
    - sanxiyn 3y ago
      Note that NEON is optional for armhf, mainly to support Tegra 2. This was a big deal at the time. See https://wiki.debian.org/ArmHardFloatPort https://wiki.debian.org/ArmHardFloatPort.
  - viraptor 3y ago
    Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).
    - cmeacham98 3y ago
      Debian distributes compiled binaries. Thus, they have to either turn processor features on in all their binaries, or off (or distribute two sets of binaries).
      - sanxiyn 3y ago
        Debian does distribute SSE-using binaries (with fallback) on i386 which detects presence of SSE at runtime using CPUID.
      - IntelMiner 3y ago
        You're thinking of optimizing the code for a specific processor. Run-time codepaths that detect CPU features have existed since MMX and SSE
      - pabs3 3y ago
        There are options for runtime instruction selection: https://wiki.debian.org/InstructionSelection https://wiki.debian.org/InstructionSelection
    - sanxiyn 3y ago
      > Check for feature presence That is the hard part. On Intel you can use CPUID, but it is ARM policy to not expose such instructions. You can read /proc/cpuinfo, but that is Linux-specific. Edit: there is a reason for ARM policy: CPUID is a well known virtualization hazard. In fact, KVM immediately traps if you execute CPUID on guest. ARM made a good decision here. Still, it means things can't work exactly like it worked on Intel.
      - erik_seaberg 3y ago
        https://news.ycombinator.com/item?id=18542040 https://news.ycombinator.com/item?id=18542040 talks about registers with a similar purpose.
        sanxiyn 3y ago
        Only in EL1, which means you can only use them in kernel.
      - viraptor 3y ago
        But specific instructions should be testable anyway, right? Try to execute with an exception handler and you'll know.
        pm215 3y ago
        On Arm this is generally a bad idea -- there are, or were, some corner cases where the kernel can know that an extension shouldn't be used, but it doesn't have a mechanism for "make the instructions UNDEF". The example I know about is ancient history now -- on the Cortex-A8 I think you could build a kernel without Neon support or perhaps the kernel might find there was a Neon-related erratum, but there was no way to disable Neon to force the UNDEFs. The recommended approach is to use HWCAPs, or else to use the kernel's "emulated ID register accesses" functionality.
      - pm215 3y ago
        The Arm Linux kernel allows you to use some of the "read ID register" instructions from userspace, because it traps them in the kernel and emulates them to present you with a slightly sanitized view of the available hardware: https://www.kernel.org/doc/html/v5.8/arm64/cpu-feature-registers.html https://www.kernel.org/doc/html/v5.8/arm64/cpu-feature-regis... You can also look at the hwcaps (available in the ELF aux vector) -- this is the older mechanism. It's true that there's no cross-OS mechanism to do this, but that's life -- often the OS wants to get in anyway to sanitize the answers (eg so it can tell you "feature X is not present" when it knows about a hardware erratum or the OS was built without feature-X support).
waaveshine 3y ago
I’ve noticed a lot of projects use riscv64 as shorthand for the rv64gc ISA, especially when it’s understood that there is an MMU, maybe an FPU, privilege levels, and any other extensions that a modern OS requires. Anyway, I did find this on the Debian website[1]. So it seems they mean rv64gc. [1] https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_choice https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_cho...
- photonbeam 3y ago
  Presumably Android will also chose a base minimum ISA spec for riscv software at some point. It would be tidy if they match the regular linux ecosystem
  - snvzz 3y ago
    Android (and most Linux distributions) is likely to settle for RVA22+V or RVA23 as minimum requirement. There's a lot in there which RV64GC (ratified in 2019, I understand unchanged since 2017) lacks. Some of the new extensions e.g. vector and bit manipulation do have a significant effect in performance.
  - panick21_ 3y ago
    It has not been decided. There was a talk about the details just 2 weeks ago on the RISC-V International Youtube channel. Very interesting and recommended.
ur-whale 3y ago
If there is a downfall of RISCV, it's going to be the myriad of sub-architectures and their weird naming schemes, with an added layer of marketing drones muddying up the waters even further. This is going to confuse the hell out of the potential customer base and it would be a crying shame, wasting a golden opportunity to get out of the oxygen-choking clutches of proprietary ISA vendors (who at this point are purely rent-seeking and add exactly zero actual economic value to the ecosystem).
- 15155 3y ago
  I don't think so, in practice since atomics (on single-core systems especially) and floats can easily be emulated. If larger, more-incompatible extensions become commonplace, possibly.
- bee_rider 3y ago
  I mean, in the very least the proprietary ISA vendors provide the service of selecting what extensions are added. If you think too many extensions will take down RISC-V, that seems to have value.
  - panick21_ 3y ago
    RISC-V will do the same thing. That's what profiles and even further platforms will provide. Most software (the large investment) will target these profiles. Not following the profiles will be possible but will cause issues.
- snvzz 3y ago
  Not since RISC-V Profiles[0]. 0. https://github.com/riscv/riscv-profiles/releases https://github.com/riscv/riscv-profiles/releases

CUViper 3y ago

RV64GC is mentioned here: https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_choice https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_cho...

LatticeAnimal 3y ago
Ah, thanks for that! I wonder how they plan to support future extensions like RV64GCV which seems to be gaining traction…
- jrockway 3y ago
  Would it be much different than armhf vs. armel?
  - sanxiyn 3y ago
    Note that NEON is optional for armhf, mainly to support Tegra 2. This was a big deal at the time. See https://wiki.debian.org/ArmHardFloatPort https://wiki.debian.org/ArmHardFloatPort.
- viraptor 3y ago
  Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).
  - cmeacham98 3y ago
    Debian distributes compiled binaries. Thus, they have to either turn processor features on in all their binaries, or off (or distribute two sets of binaries).
    - sanxiyn 3y ago
      Debian does distribute SSE-using binaries (with fallback) on i386 which detects presence of SSE at runtime using CPUID.
    - IntelMiner 3y ago
      You're thinking of optimizing the code for a specific processor. Run-time codepaths that detect CPU features have existed since MMX and SSE
    - pabs3 3y ago
      There are options for runtime instruction selection: https://wiki.debian.org/InstructionSelection https://wiki.debian.org/InstructionSelection
  - sanxiyn 3y ago
    > Check for feature presence That is the hard part. On Intel you can use CPUID, but it is ARM policy to not expose such instructions. You can read /proc/cpuinfo, but that is Linux-specific. Edit: there is a reason for ARM policy: CPUID is a well known virtualization hazard. In fact, KVM immediately traps if you execute CPUID on guest. ARM made a good decision here. Still, it means things can't work exactly like it worked on Intel.
    - erik_seaberg 3y ago
      https://news.ycombinator.com/item?id=18542040 https://news.ycombinator.com/item?id=18542040 talks about registers with a similar purpose.
      - sanxiyn 3y ago
        Only in EL1, which means you can only use them in kernel.
    - viraptor 3y ago
      But specific instructions should be testable anyway, right? Try to execute with an exception handler and you'll know.
      - pm215 3y ago
        On Arm this is generally a bad idea -- there are, or were, some corner cases where the kernel can know that an extension shouldn't be used, but it doesn't have a mechanism for "make the instructions UNDEF". The example I know about is ancient history now -- on the Cortex-A8 I think you could build a kernel without Neon support or perhaps the kernel might find there was a Neon-related erratum, but there was no way to disable Neon to force the UNDEFs. The recommended approach is to use HWCAPs, or else to use the kernel's "emulated ID register accesses" functionality.
    - pm215 3y ago
      The Arm Linux kernel allows you to use some of the "read ID register" instructions from userspace, because it traps them in the kernel and emulates them to present you with a slightly sanitized view of the available hardware: https://www.kernel.org/doc/html/v5.8/arm64/cpu-feature-registers.html https://www.kernel.org/doc/html/v5.8/arm64/cpu-feature-regis... You can also look at the hwcaps (available in the ELF aux vector) -- this is the older mechanism. It's true that there's no cross-OS mechanism to do this, but that's life -- often the OS wants to get in anyway to sanitize the answers (eg so it can tell you "feature X is not present" when it knows about a hardware erratum or the OS was built without feature-X support).

waaveshine 3y ago

I’ve noticed a lot of projects use riscv64 as shorthand for the rv64gc ISA, especially when it’s understood that there is an MMU, maybe an FPU, privilege levels, and any other extensions that a modern OS requires. Anyway, I did find this on the Debian website[1]. So it seems they mean rv64gc. [1] https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_choice https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_cho...

photonbeam 3y ago
Presumably Android will also chose a base minimum ISA spec for riscv software at some point. It would be tidy if they match the regular linux ecosystem
- snvzz 3y ago
  Android (and most Linux distributions) is likely to settle for RVA22+V or RVA23 as minimum requirement. There's a lot in there which RV64GC (ratified in 2019, I understand unchanged since 2017) lacks. Some of the new extensions e.g. vector and bit manipulation do have a significant effect in performance.
- panick21_ 3y ago
  It has not been decided. There was a talk about the details just 2 weeks ago on the RISC-V International Youtube channel. Very interesting and recommended.

ur-whale 3y ago

If there is a downfall of RISCV, it's going to be the myriad of sub-architectures and their weird naming schemes, with an added layer of marketing drones muddying up the waters even further. This is going to confuse the hell out of the potential customer base and it would be a crying shame, wasting a golden opportunity to get out of the oxygen-choking clutches of proprietary ISA vendors (who at this point are purely rent-seeking and add exactly zero actual economic value to the ecosystem).

15155 3y ago
I don't think so, in practice since atomics (on single-core systems especially) and floats can easily be emulated. If larger, more-incompatible extensions become commonplace, possibly.
bee_rider 3y ago
I mean, in the very least the proprietary ISA vendors provide the service of selecting what extensions are added. If you think too many extensions will take down RISC-V, that seems to have value.
- panick21_ 3y ago
  RISC-V will do the same thing. That's what profiles and even further platforms will provide. Most software (the large investment) will target these profiles. Not following the profiles will be possible but will cause issues.
snvzz 3y ago
Not since RISC-V Profiles[0]. 0. https://github.com/riscv/riscv-profiles/releases https://github.com/riscv/riscv-profiles/releases