Reminded me how one famous Russian guy ran Atomic Heart on Elbrus 8S.
Elbrus has native translator, though, and pretty good one, afaik. Atomic Heart was kinda playable, 15-25 fps.
Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
21–30 of 149 posts
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#22Earlier 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..
The handling of misaligned loads/stores in RISC-V is also can be considered a disappointing point: https://github.com/riscv/riscv-isa-manual/issues/1611 It oozes with preferring convenience of hardware developers and "flexibility" over making practical guarantees needed by software developers. It looks like the MIPS patent on misaligned load/store instructions has played its negative role. The patent expired in 2019, but it seems we are stuck with the current status quo nevertheless.
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#23> 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?
But we define the RISC dream as a dream that efficiency, performance and low-cost could be achieved by cores with very small instruction sets?
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#24> 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…
The explanation that I've seen is that it's "(reduced instruction) set computer" - simple instructions, not necessarily few.
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#25Earlier quoted context omitted.
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?
But we define the RISC dream as a dream that efficiency, performance and low-cost could be achieved by cores with very small instruction sets?
If adding more instructions negatively impacts efficiency, performance, cost and complexity, nobody would do it.
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#26> 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…
As I've heard it explained, RISC in practise is less about "an absolutely minimalist instruction set" and more about "don't add any assembly programmer conveniences or other such cleverness, rely on compilers instead of frontend silicon when possible".
Although as I recall from reading the RISC-V spec, RISC-V was rather particular about not adding "combo" instructions when common instruction sequences can be fused by the frontend.
My (far from expert) impression of RISC-V's shortcomings versus x86/ARM is more that the specs were written starting with the very basic embedded-chip stuff, and then over time more application-cpu extensions were added. (The base RV32I spec doesn't even include integer multiplication.) Unfortunately they took a long time to get around to finishing the bikeshedding on bit-twiddling and simd/vector extensions, which resulted in the current functionality gaps we're talking about.
So I don't think those gaps are due to RISC fundamentalism; there's no such thing.
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#27Earlier quoted context omitted.
But we define the RISC dream as a dream that efficiency, performance and low-cost could be achieved by cores with very small instruction sets?
If adding more instructions negatively impacts efficiency, performance, cost and complexity, nobody would do it.
Probably true now, but in ye olde days, some instructions existed primarily to make assembly programming more convenient.
Assembly programming is a real pain in the RISCiest of RISC architectures, like SPARC. Here's an example from https://www.cs.clemson.edu/course/cpsc827/material/Code%20Ge...:
• All branches (including the one caused by CALL, below) take place after execution of the following instruction.
• The position immediately after a branch is the “delay slot” and the instruction found there is the “delay instruction”.
• If possible, place a useful instruction in the delay slot (one which can safely be done whether or not a conditional branch is taken).
• If not, place a NOP in the delay slot.
• Never place any other branch instruction in a delay slot.
• Do not use SET in a delay slot (only half of it is really there).
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#28Reminded me how one famous Russian guy ran Atomic Heart on Elbrus 8S. Elbrus has native translator, though, and pretty good one, afaik. Atomic Heart was kinda playable, 15-25 fps.
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#29Earlier quoted context omitted.
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?
But we define the RISC dream as a dream that efficiency, performance and low-cost could be achieved by cores with very small instruction sets?
Not small instruction sets, simplified instruction sets. RISC’s main trick is to reduce the number of addressing modes (eg, no memory indirect instructions) and reduce the number of memory operands per instruction to 0 or 1. Use the instruction encoding space for more registers instead.
The surviving CISCs, x86 and z390 are the least CISCy CISCs. The surviving RISCs, arm and power, are the least RISCy RISCs.
RISC V is a weird throwback in some aspects of its instruction set design.
Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
#30Article is a bit short on "the basics" - I assumed they used some kind of wine port to run it. But it seems they implemented the x86_64 ISA on a RISC-V chip in some way - anyone can shed more light on that part how that is done?
The basics are here: https://box86.org/ It is an emulator but: > Because box86 uses the native versions of some “system” libraries, like libc, libm, SDL, and OpenGL, it’s easy to integrate and use with most applications, and performance can be surprisingly high in some cases. Wine can also be compiled/run as native.
> Wine can also be compiled/run as native.
I'm not sure you can run Wine natively to run x86 Windows programs on RISC-V because Wine is not an emulator. There is an ARM port of Wine, but that can only run Windows ARM programs, not x86.
Instead box64 is running the x86_64 Wine https://github.com/ptitSeb/box64/blob/main/docs/X64WINE.md