------
Compressed pointers reduce the need for memory by storing pointers as 32-bit unsigned offsets relative to a base register. Decompressing the pointers just consists of adding the offset and register together. As simple as this sounds, it comes with a small complication on our RISC-V 64-bit port. By construction, 32-bit values are always loaded into the 64-bit registers as signed values. This means that we need to zero-extend the 32-bit offset first. Until recently this was done by bit-anding the register with 0xFFFF_FFFF:
li t3,1
slli t3, t3, 32
addi t3, t3, -1
and a0, a0, t3
zext.w a0, a0
This is so strange. Does no one at Google know RISC-V? This has *never* needed more than...
slli a0, a0, 32
srli a0, a0, 32
add.uw decompressed, compressed, base
After all, `zext.w` is just an alias for `add.uw` with the `zero` register as the last argument...
They also could have always simply stored the 32 bit offset as signed and pointed the base register 2GB into the memory area instead of using x86/Arm-centric design.
V8 is a huge project and ports almost have to start from backends of existing architectures. Over time we (I recently worked on the RISC-V port) improve the situation.
Note that it's also crucial to stay somehow similar to the x86 and ARM backends as the V8 team frequently makes changes to these and keeping up with them would be a nightmare if the RISC-V backend was too different.
"Does no one at Google know RISC-V" This work wasn't done by Google. Also, you don't hire RISC-V experts, but V8 experts (or other similar VMs) for such a port. I, for example, had never worked with RISC-V before. As such, it can happen that some code of the RISC-V backend is written by engineers that aren't yet experts in RISC-V.
They probably wanted: "... that I should read?" So that this is at least marketed to be more than a fake-paper generation tool.