The hoops they had to go through to get PIC address calculations to work make it quite weird. Because `auipc` adds an offset from its `pc`, the corresponding `add` or `lw` relocation needs refer back to that instruction rather than the symbol it's actually looking for.

The poor ELF specification ends up quite tortured by this, IMO.

That affects ELF relocations but not the code.

Arm64 is even worse! There is almost exactly the same instruction, but it also zeroes the low bits of the target address, so as you relocate code you also have to change the offset in the 2nd instruction even if the distance between the reference and the target stays the same.

Probably on copying Arm too much :-) I hit "char is unsigned" (not really architectural, more of a toolchain issue) only this morning.

RISC-V was originally going to implement a hypervisor mode which would only have worked with Xen-like hypervisors. Luckily we were able to head that off early and the actual hypervisor extension we got can run KVM efficiently.

Not sure if you'll see this - going through old tabs - but I was curious, and just in case: what are the practical differences between Xen and KVM here?

It doesn't have a condition code register, which scores it plenty of weirdness points.

Not having condition codes actually cleans up the semantics a lot - no need to define the CC effects for each and every insn. It's also helpful to high-performance implementations, since the condition code register would otherwise enter as a dependency in every insn.

Sure, there are reasons for it being that way, but it makes it stick out from the mainstream. For example, if you're writing a codegen, before RISC-V you could assume that you had CMOVE and now you can't. The risk is then that the RISC-V backend will emit some clumsy sequence that emulates CMOVE, to make it fit in with the others.

The weirdest things about RISC-V are having very weak addressing modes in comparison with almost all other CPU architectures and also having extremely weak support for detecting integer overflow.

Going back to the original H&P texts and RISC philosophy, there is a claim that auto-increment addressing modes is too expensive due to the extra port in the RF + scheduling complexity. For an instruction set that should support embedded in order dual issue processors with math intensive loops, this is arguably a "weird" omission in the base line.

Lack of condition codes when the dominant paradigm (x86, ARM) is condition codes is weird. However, having 32 registers unlike x86_64's 16 makes up for some of it.

The base is too base and their bitfield extension is weird.

>The base is too base

I'm sure those that only need the base disagree. For the rest of us, there's G (IMAFD).