- >V8 emits a near-jump for all forward jumps. If the target ends up too far away, the near-jump target is adjusted to a jump pool entry that contains a long-jump to the actual target
This sounds weird to me... Why not assume that all jumps need to be long to start with (so that the code is valid), then relax them to short jumps during an N-pass optimization stage- so that you get the smallest possible code?
- Quote, because unlike on Reddit I couldn't figure out how to do multi para > quotes with code here.
------
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:
Now, this code uses the `zext.w` instruction from the Zba extension:li t3,1 slli t3, t3, 32 addi t3, t3, -1 and a0, a0, t3
-----zext.w a0, a0This is so strange. Does no one at Google know RISC-V? This has *never* needed more than...
And if they're going to use `Zba`, and zero-extend it and then add it to another register, then why use a separate `zext.w` instruction and `add` instead of ...slli a0, a0, 32 srli a0, a0, 32
... to zero extend and add in one instruction??add.uw decompressed, compressed, baseAfter 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.