Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

box86.org

Post reply on HN
Print view View original

11–20 of 149 posts

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

#11

Post by dmitrygr »

renox wrote: post #8
dmitrygr wrote: post #4

Earlier quoted context omitted.

None of this is new. None of it. In fact, bitfield extract is such an obvious oversight that it is my favourite example of how idiotic the RISCV ISA is (#2 is lack of sane addressing modes). Some of the better RISCV designs, in fact, implement a custom instr to do this, eg: BEXTM in Hazard3: https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3....

Whoa, someone else who doesn't believe that the RISC-V ISA is 'perfect'! I'm curious: how the discussions on the bitfield extract have been going? Because it does really seem like an obvious oversight and something to add as a 'standard extension'. What's your take on 1) unaligned 32bit instructions with the C extension? 2) lack of 'trap on overflow' for arithmetic instructions? MIPS had it..

1. aarch64 does this right. RISCV tries to be too many things at once, and predictably ends up sucking at everything. Fast big cores should just stick to fixed size instrs for faster decode. You always know where instrs start, and every cacheline has an integer number of instrs. microcontroler cores can use compressed intrs, since it matters there, while trying to parallel-codec instrs does not matter there. Trying to have one arch cover it all is idiotic.

2. nobody uses it on mips either, so it is likely of no use.

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

#12

Post by snvzz »

int0x29 wrote: post #9

That screenshot shows 31 gb of ram which is distinctly more than the mentioned dev board at max specs. Are they using something else here?

Pioneer, an older board.

Note that, today, one of the recent options with several, faster cores implementing RVA22 and RVV 1.0 is the better idea.

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

#14

Post by bonzini »

camel-cdr wrote: post #7
justahuman74 wrote: post #3

I hope they're able to get this ISA-level feedback to people at RVI

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...

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...

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

#17

Post by bonzini »

dmitrygr wrote: post #11
renox wrote: post #8

Earlier quoted context omitted.

Whoa, someone else who doesn't believe that the RISC-V ISA is 'perfect'! I'm curious: how the discussions on the bitfield extract have been going? Because it does really seem like an obvious oversight and something to add as a 'standard extension'. What's your take on 1) unaligned 32bit instructions with the C extension? 2) lack of 'trap on overflow' for arithmetic instructions? MIPS had it..

1. aarch64 does this right. RISCV tries to be too many things at once, and predictably ends up sucking at everything. Fast big cores should just stick to fixed size instrs for faster decode. You always know where instrs start, and every cacheline has an integer number of instrs. microcontroler cores can use compressed intrs, since it matters there, while trying to parallel-codec instrs does not matter there. Trying t…

Fixed size instructions are not absolutely necessary, but keeping them naturally aligned is just better even if that means using C instructions a bit less often. It's especially messy that 32-bit instructions can span a page.

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

#18

Post by Manfred »

> At least in the context of x86 emulation, among all 3 architectures we support, RISC-V is the least expressive one.

RISC was explained to me as a reduced instruction set computer in computer science history classes, but I see a lot of articles and proposed new RISC-V profiles about "we just need a few more instructions to get feature parity".

I understand that RISC-V is just a convenient alternative to other platforms for most people, but does this also mean the RISC dream is dead?

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

#19

Post by flanked-evergl »

Manfred wrote: post #18

> At least in the context of x86 emulation, among all 3 architectures we support, RISC-V is the least expressive one. RISC was explained to me as a reduced instruction set computer in computer science history classes, but I see a lot of articles and proposed new RISC-V profiles about "we just need a few more instructions to get feature parity". I understand that RISC-V is just a convenient alternative to other platfo…

Is there a RISC dream? I think there is an efficiency "dream", there is a performance "dream", there is a cost "dream" — there are even low-complexity relative to cost, performance and efficiency "dreams" — but a RISC dream? Who cares more about RISC than cost, performance, efficiency and simplicity?
Post reply on HN