alt Hacker NewsIt's not. In practice you have two scenarios:
1. You have a microcontroller. You're compiling code yourself and the docs tells you what features are available and which compiler flags to use.
2. You are writing application code. In that case you simply target RVA23.
The edge case is the same edge case where you use CPUID on x86, I.e. you want to target say RVA23 and RVA28 in the same binary. In that case you do have to use the OS APIs to discover what is supported... which is slightly annoying, but in practice you're just calling a different function.
In theory `mconfigptr` will eventually make this a lot nicer but nobody has put in the effort to define how it works yet (last I heard they were looking at ASN.1 sick emoji).
Replies
Don't forget:
3. You are writing a kernel, with large amounts of inline assembly
4. You are writing a compiler, either offline or online
5. You are writing embeddable blobs that don't know what platform they will be running on.
6. You are designing a RISC-V core, and need to decide which extensions you should be supporting for your intended use-case.
> You are writing application code. In that case you simply target RVA23.
You're allowed to not handle a majority of extant Linux-capable machines, but it seems like an awkward position.
When I looked into mconfigptr some years ago I thought it looked like a swirling vortex of pain that might produce something useful some day. Good to see it's still being worked on. Sad to hear ASN.1 is still involved.
I added an "misa but more bits" register to my core, using the bit assignment from the RISC-V C API, so at least until then I know what extensions each instance of my core implements. https://wren.wtf/hazard3/doc/#reg-h3.misa
Linux folks seem to have already put a lot of the mconfigptr info into the DT blob anyways.