RISCV: add skeleton infrastructure for RISCV

[compnerd]

This adds the rv{32,64,128} skeleton in place so that we can start adding the
necessary architectural support.

[compnerd]

Why do you need to shift right just to shift back left if you are doing the and to pull of the relevant bits? Also you do this operation a lot... wondering if you could encapsulate it in an inline function?

Ah, good question! It seems silly but it is because I'm terrible at arithmetic, but the compiler is stupidly good at it. This means that I can just cross-reference the documentation saying that these bits correspond to this bit of the address. The compiler will collapse that down anyway.

Nit: More clear name than RISCVnnn? Isn't exactly clear what it represents.

I don't have a better name. This was something that I replicated from RISCV itself! They use that in the ABI documentation.

Nit: For the "non-obvious" alternate abbreviations, it would be worthwhile to have comments describing what they are. The return address/stack pointer, might be obvious -- but thread pointer, saved register, function argument might not be.

I think that you addressed this subsequently:

Nit: For the alternate-names, it would be useful to have a link to a reference where these are defined.

These names are from the RISCV specification. I can add a link to the specification, but not sure if its valuable (and we don't have similar links for the X86 or ARM specifications).

Should bit-size be 32 for RV32F, and 64 for RV32D?

That is part of the TODO mentioned in the build changes: this currently assumes RVnnnG. That implies f, d, and d = 64 bit as per the specification if I understand it correctly.

[dmlockhart]

Nit: More clear name than RISCVnnn? Isn't exactly clear what it represents.

[compnerd]

I took this name from one of the RISCV docs (ELF psABI?). The "nnn" is a placeholder for digits indicating the bitness.

[dmlockhart]

Nit: For the alternate-names, it would be useful to have a link to a reference where these are defined.

[compnerd]

This file is effectively determined by GDB as the canonical source of information. The same applies to all the definitions for the other architectures. I think that adding that to developer documentation might be a good idea, but would be out of scope for this change IMO.

[dmlockhart]

Nit: For the "non-obvious" alternate abbreviations, it would be worthwhile to have comments describing what they are. The return address/stack pointer, might be obvious -- but thread pointer, saved register, function argument might not be.

[compnerd]

TBH, I don't even know if there is an explanation for the names. These are determined by GDB's expectations.

[dmlockhart]

Should bit-size be 32 for RV32F, and 64 for RV32D?

"We use the term FLEN to describe the width of the floating-point registers in the RISC-V ISA, and FLEN=32 for the F single-precision floating-point extension."

"The D extension widens the 32 floating-point registers, f0–f31, to 64 bits (FLEN=64 in Fig-
ure 11.1). The f registers can now hold either 32-bit or 64-bit floating-point values as described
below in Section 12.2."

[compnerd]

This is one of the tradeoffs I made. If you look at the CMakeLIsts.txt change, there is a TODO there to determine the detail of the FPU more accurately. This currently assumes RVnnnG which implies f,d. AIUI, f = 32-bit, d = 64-bit, and q = 128-bit register width. GDB expects that a single width is used, which matches uintptr_t (due to the G expectation).

[dmlockhart]

Why do you need to shift right just to shift back left if you are doing the and to pull of the relevant bits?
Also you do this operation a lot... wondering if you could encapsulate it in an inline function?

[compnerd]

Good question! I am terrible with arithmetic but the compiler is good! It can flatten this out, but in its current form it matches the specification almost verbatim. I have less to think about this way.