U-mode feature detection

[sorear]

Let's suppose that in the future, Amazing Extension X becomes widespread but not ubiquitous. (Ubiquitous anything is highly unlikely since RISC-V intends to support a wide range of core sizes.) You want to use it in programs if it's available?

• Can you trap SIGILL and probe the instruction directly? No, because RISC-V does not globally allocate opcodes. Even opcodes from standard extensions may have non-standard meanings if the original extension is omitted.

• Can you directly query the CPU for support? No, because there's no defined protocol.

• Can you do anything? Yes! You can parse /proc/cpuinfo and limit your feature to Linux, then add additional versions for each new OS that provides something similar.

It would be undesirable if a large amount of otherwise OS-neutral library code were to start depending on /proc/cpuinfo just to check for extensions.

A new OS-neutral mechanism could be added as instructions, CSRs, or as well-known external functions in the (not currently specified) ABI.

@kasanovic has indicated that there is "ongoing debate" about this in https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/42IM6tstYOg/ePRyYIenDAAJ .

This is a compatibility threat because if a large number of implementations without feature detection are deployed, it will become necessary to somehow detect the feature detection mechanism. Intel did this (in the Pentium 1, well over 21 years ago) by changing the definition of a WARL field in the EFLAGS register; we don't have a flag register but could do something similar with fcsr (eew), change the definition of a currently valid but useless instruction like andi x0,x0,1211 (eew), or use a function and invent a standard __dunder macro to signal its presence (less desirable for non-C languages).

The external function approach pushes this up a layer since there is not currently a way for Linux to get this information either; it just assumes RVG.

[kasanovic]

1) Has to be done as a feature that virtualization layers can intercept and substitute. 2) Has to support a potentially large set of independently developed extensions, and some might have parameters as well as binary exists/not-exists. Not clear that a register value or instruction result could do this well.

[sorear]

Most Linux architectures use AT_HWCAP in the auxv for this. It's fast enough and while the portability aspect still bugs me, it's not a unique riscv problem. Inclined to stick with AT_HWCAP.