3 ms·

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

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.