5 ms·

> It used to be one thing checking which SIMD units an x86 had, but the nature of an open source processor lends itself to a near infinite listing of /proc/cpui

> It used to be one thing checking which SIMD units an x86 had, but the nature of an open source processor lends itself to a near infinite listing of /proc/cpuinfo flags. I mean, x86 sets a very high bar for the sheer number of feature flags. Most ISA extensions of interest to compilers are standardized with the RISC-V Foundation †. The mechanism is similar to other chips, and the situation so far seems to be about the same, except a couple orders of magnitude difference in the current number of flags. † Seems it's now RISC-V International

fuoqi 6y ago
So is there a CPUID-like instruction in the base RISC-V instruction set? After a cursory search I couldn't find anything like it. If there is indeed no such instruction, it will be a real shame. Why would you not include it into a such extensible ISA?
- microcolonel 6y ago
  Your system's device tree describes the CPU to the kernel. The riscv,isa string contains the list of extensions in the standard format (a string of single-character standard extensions, and Z-delimited extensions). To clarify I did not mean that this information was accessed through specialized CPU instructions directly, but that it is available through cpuinfo on Linux and such like usual. Here's an example device tree for the HiFive Unleashed board, which describes the embedded controller as rv64imac, and the application processor cores as rv64imafdc (same as the embedded controller, but with floats and doubles): https://github.com/riscv/riscv-device-tree-doc/blob/master/examples/sifive-hifive_unleashed-microsemi.dts https://github.com/riscv/riscv-device-tree-doc/blob/master/e... If your system is application-specific enough, you won't even bother with that. You'll know what extensions your SoC supports when you make your purchasing decision, and you'll know when you compile your software.
  - formerly_proven 6y ago
    How does the OS <discover/gain access to/build/enumerate> the device tree? Edit: Apparently the device tree is handled by the firmware (UEFI?), so that a RISC-V OS asks the firmware to provide the device tree and I suppose if it ever gets to desktops, it'd be firmware's job to figure out what CPU is plugged into the board. The current state seems to only cater to integrated systems, though?
    - microcolonel 6y ago
      The firmware or the bootloader leaves it in memory somewhere. Re: the added question on "integrated systems": your VM hypervisor will map a device tree for VM guests as well, this is how QEMU and other hypervisors expose virtio devices to guests as well.
      - formerly_proven 6y ago
        Yeah, but that sort of punts the question of "how does the [firmware] code figure out what CPU is being used", unless that's backed into the firmware at build time.
        monocasa 6y ago
        Yep, it's baked into the firmware somehow. Sometimes it'll actually be linked in, sometimes the firmware knows where in flash or whatever to grab it from before loading the kernel, sometimes the firmware knows how to interrogate hardware and generate a new one. Sometimes it's a combo of all three.
        cmrx64 6y ago
        yeah, it usually is, that's how those device trees work. it's generally bundled with the "bootloader" (chain loader component of the firmware). you can even bake them into your kernel if you want, i believe. RISC-V is a processor ISA, not a platform spec. you may be interested in the SBI: https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi.adoc https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi... the details of how all this stuff works at a human-collaboration level has changed a bit since 1993. there's a higher level of collaboration expected. vs intel and ms bossing people around. edit: you may also be interested in https://doc.coreboot.org/arch/riscv/index.html https://doc.coreboot.org/arch/riscv/index.html and https://lkml.org/lkml/2020/2/25/1209 https://lkml.org/lkml/2020/2/25/1209 and https://lists.gnu.org/archive/html/grub-devel/2019-02/msg00021.html https://lists.gnu.org/archive/html/grub-devel/2019-02/msg000... not exactly "desktop" yet, but hopefully you can see how that might look, given the existing linux infrastructure :)
- loeg 6y ago
  > So is there a CPUID-like instruction in the base RISC-V instruction set? Yes. > After a cursory search I couldn't find anything like it. This was the first google result for "riscv cpuid feature instruction" for me (RISC-V Instruction Set Manual v1.7): > The mcpuid register is an XLEN-bit read-only register containing information regarding the capabilities of the CPU implementation. This register must be readable in any implementation
  - microcolonel 6y ago
    Oh right, I tried looking for it and it's not in the current specification AFAIK. What there is, though, is the misa CSR, which accomplishes something similar described in 3.1.1 of the Privileged spec. The misa register is a bitfield of the supported standard extensions. Not sure but I think it's not readable in U-mode, or it's undefined.
  - fuoqi 6y ago
    Thank you! I was looking at the Volume 1 only. But IIUC it will not be accessible at user-level, so capability detection will be significantly less convenient for cross-platform library authors compared to x86.
    - Narishma 6y ago
      Why does it need to be accessible from user-space? Applications can just ask the OS what extensions are available before using them.
      - fuoqi 6y ago
        It does not need to be, but it makes things significantly easier for library authors. Asking OS is a more involved process than calling an instruction (for starters you should learn which OS your code is running on) and you may not have OS in the first place (e.g. for bare-metal programming).
        roca 6y ago

fuoqi 6y ago

So is there a CPUID-like instruction in the base RISC-V instruction set? After a cursory search I couldn't find anything like it. If there is indeed no such instruction, it will be a real shame. Why would you not include it into a such extensible ISA?

microcolonel 6y ago
Your system's device tree describes the CPU to the kernel. The riscv,isa string contains the list of extensions in the standard format (a string of single-character standard extensions, and Z-delimited extensions). To clarify I did not mean that this information was accessed through specialized CPU instructions directly, but that it is available through cpuinfo on Linux and such like usual. Here's an example device tree for the HiFive Unleashed board, which describes the embedded controller as rv64imac, and the application processor cores as rv64imafdc (same as the embedded controller, but with floats and doubles): https://github.com/riscv/riscv-device-tree-doc/blob/master/examples/sifive-hifive_unleashed-microsemi.dts https://github.com/riscv/riscv-device-tree-doc/blob/master/e... If your system is application-specific enough, you won't even bother with that. You'll know what extensions your SoC supports when you make your purchasing decision, and you'll know when you compile your software.
- formerly_proven 6y ago
  How does the OS <discover/gain access to/build/enumerate> the device tree? Edit: Apparently the device tree is handled by the firmware (UEFI?), so that a RISC-V OS asks the firmware to provide the device tree and I suppose if it ever gets to desktops, it'd be firmware's job to figure out what CPU is plugged into the board. The current state seems to only cater to integrated systems, though?
  - microcolonel 6y ago
    The firmware or the bootloader leaves it in memory somewhere. Re: the added question on "integrated systems": your VM hypervisor will map a device tree for VM guests as well, this is how QEMU and other hypervisors expose virtio devices to guests as well.
    - formerly_proven 6y ago
      Yeah, but that sort of punts the question of "how does the [firmware] code figure out what CPU is being used", unless that's backed into the firmware at build time.
      - monocasa 6y ago
        Yep, it's baked into the firmware somehow. Sometimes it'll actually be linked in, sometimes the firmware knows where in flash or whatever to grab it from before loading the kernel, sometimes the firmware knows how to interrogate hardware and generate a new one. Sometimes it's a combo of all three.
      - cmrx64 6y ago
        yeah, it usually is, that's how those device trees work. it's generally bundled with the "bootloader" (chain loader component of the firmware). you can even bake them into your kernel if you want, i believe. RISC-V is a processor ISA, not a platform spec. you may be interested in the SBI: https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi.adoc https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi... the details of how all this stuff works at a human-collaboration level has changed a bit since 1993. there's a higher level of collaboration expected. vs intel and ms bossing people around. edit: you may also be interested in https://doc.coreboot.org/arch/riscv/index.html https://doc.coreboot.org/arch/riscv/index.html and https://lkml.org/lkml/2020/2/25/1209 https://lkml.org/lkml/2020/2/25/1209 and https://lists.gnu.org/archive/html/grub-devel/2019-02/msg00021.html https://lists.gnu.org/archive/html/grub-devel/2019-02/msg000... not exactly "desktop" yet, but hopefully you can see how that might look, given the existing linux infrastructure :)
loeg 6y ago
> So is there a CPUID-like instruction in the base RISC-V instruction set? Yes. > After a cursory search I couldn't find anything like it. This was the first google result for "riscv cpuid feature instruction" for me (RISC-V Instruction Set Manual v1.7): > The mcpuid register is an XLEN-bit read-only register containing information regarding the capabilities of the CPU implementation. This register must be readable in any implementation
- microcolonel 6y ago
  Oh right, I tried looking for it and it's not in the current specification AFAIK. What there is, though, is the misa CSR, which accomplishes something similar described in 3.1.1 of the Privileged spec. The misa register is a bitfield of the supported standard extensions. Not sure but I think it's not readable in U-mode, or it's undefined.
- fuoqi 6y ago
  Thank you! I was looking at the Volume 1 only. But IIUC it will not be accessible at user-level, so capability detection will be significantly less convenient for cross-platform library authors compared to x86.
  - Narishma 6y ago
    Why does it need to be accessible from user-space? Applications can just ask the OS what extensions are available before using them.
    - fuoqi 6y ago
      It does not need to be, but it makes things significantly easier for library authors. Asking OS is a more involved process than calling an instruction (for starters you should learn which OS your code is running on) and you may not have OS in the first place (e.g. for bare-metal programming).
      - roca 6y ago