On: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

[camel-cdr]

The scalar efficiency SIG has already been discussing bitfield insert and extract instructions.

We figured out yesterday [1], that the example in the article can already be done in four risc-v instructions, it's just a bit trickier to come up with it:

    # a0 = rax, a1 = rbx
    slli t0, a1, 64-8
    rori a0, a0, 16
    add a0, a0, t0
    rori a0, a0, 64-16

[1] https://www.reddit.com/r/RISCV/comments/1f1mnxf/box64_and_ri...

[bonzini → camel-cdr]

Nice trick, in fact with 4 instructions it's as efficient as extract/insert and it works for all ADD/SUB/OR/XOR/CMP instructions (not for AND), except if the source is a high-byte register. However it's not really a problem if code generation is not great in this case: compilers in practice will not generate accesses to these registers, and while old 16-bit assembly code has lots of such accesses it's designed to run on processors that ran at 4-20 MHz.

Flag computation and conditional jumps is where the big optimization opportunities lie. Box64 uses a multi-pass decoder that computes liveness information for flags and then computes flags one by one. QEMU instead tries to store the original operands and computes flags lazily. Both approaches have advantages and disadvantages...

[brucehoult → bonzini]

> except if the source is a high-byte register

That's just one more instruction, to right-align the AH, BH etc src operand prior to exactly the same instructions as above.

And, yes, this being 64 bit code compilers won't be generating such instructions. In fact they started avoiding them as soon as OoO hit in the Pentium Pro, P II, P III etc in the mid 90s because of "partial register update stalls".

[ptitSeb → bonzini]

Actually, Box64 can also store operands for later computation, depending on what comes next...

[ksco → camel-cdr]

Author here, we have adopted this approach as a fast path to box64: https://github.com/ptitSeb/box64/pull/1763, thank you very much!