3 ms·

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

by 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
    If you're on bare metal, then you have access to supervisor mode. I like the approach of hiding cpuid registers from user-space. It means, for example, the operating system can easily control what hardware features user-space will use. That's useful for debugging, for process migration, for record and replay (I maintain rr), and to "discourage" user-space from using buggy or detrimental features. Simplifying the hardware features exposed to user-space makes evolution easier. Your OS kernel should be (needs to be) up to date, while you might have old user-space binaries that you want to keep running, so you can live with weaker compatibility guarantees for supervisor-mode-only features.
- jlokier 6y ago
  Ew. So generic RISC-V libraries, that do things like calculations, crypto or even memcpy(), need to have OS-specific code in them? They won't work on OSes the library author didn't know about, or hasn't supplied code for, or which didn't exist when the library was created. There are a lot of OSes. Most likely it will be a call to libc or equivalent, and therefore be tied to libc. For generic libraries it may be the only reason for a dependency on libc. There are even more libc variations than OSes. In Linux terms, it is almost distro-specific. This is effectively part of the RISC-V ABI, and it means there is no OS-independent ABI.
  - microcolonel 6y ago
    > There are a lot of OSes. Maybe, but right now there are only a couple OSes that run on RISC-V, where you would care to detect these things at runtime. As of now, I think FreeBSD has an AT_HWCAP, which exposes RISC-V standard extension information. (though yes, it will be some platform code, one #ifdef and a couple lines to call either getauxval or elf_aux_info). > ...or even memcpy() P.S. memcpy goes in libc, the same place that implements these functions, so I think probably choosing the right memcpy is not an issue.

by fuoqi 6y ago

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
  If you're on bare metal, then you have access to supervisor mode. I like the approach of hiding cpuid registers from user-space. It means, for example, the operating system can easily control what hardware features user-space will use. That's useful for debugging, for process migration, for record and replay (I maintain rr), and to "discourage" user-space from using buggy or detrimental features. Simplifying the hardware features exposed to user-space makes evolution easier. Your OS kernel should be (needs to be) up to date, while you might have old user-space binaries that you want to keep running, so you can live with weaker compatibility guarantees for supervisor-mode-only features.
jlokier 6y ago
Ew. So generic RISC-V libraries, that do things like calculations, crypto or even memcpy(), need to have OS-specific code in them? They won't work on OSes the library author didn't know about, or hasn't supplied code for, or which didn't exist when the library was created. There are a lot of OSes. Most likely it will be a call to libc or equivalent, and therefore be tied to libc. For generic libraries it may be the only reason for a dependency on libc. There are even more libc variations than OSes. In Linux terms, it is almost distro-specific. This is effectively part of the RISC-V ABI, and it means there is no OS-independent ABI.
- microcolonel 6y ago
  > There are a lot of OSes. Maybe, but right now there are only a couple OSes that run on RISC-V, where you would care to detect these things at runtime. As of now, I think FreeBSD has an AT_HWCAP, which exposes RISC-V standard extension information. (though yes, it will be some platform code, one #ifdef and a couple lines to call either getauxval or elf_aux_info). > ...or even memcpy() P.S. memcpy goes in libc, the same place that implements these functions, so I think probably choosing the right memcpy is not an issue.