61–70 of 149 posts
> The x86 instruction set is very very big. According to rough statistics, the ARM64 backend implements more than 1,600 x86 instructions in total, while the RV64 backend implements about 1,000 instructions This is just insane and gets us full-circle to why we want RISC-V.
> The x86 instruction set is very very big. According to rough statistics, the ARM64 backend implements more than 1,600 x86 instructions in total, while the RV64 backend implements about 1,000 instructions This is just insane and gets us full-circle to why we want RISC-V.
>15 fps in-game Wow...that's substantially more than I would have guessed. Good times ahead for hardware
"which allows games like Stardew Valley to run, but it is not enough for other more serious Linux games" Hey! ;-)
> The x86 instruction set is very very big. According to rough statistics, the ARM64 backend implements more than 1,600 x86 instructions in total, while the RV64 backend implements about 1,000 instructions This is just insane and gets us full-circle to why we want RISC-V.
> The x86 instruction set is very very big. According to rough statistics, the ARM64 backend implements more than 1,600 x86 instructions in total, while the RV64 backend implements about 1,000 instructions This is just insane and gets us full-circle to why we want RISC-V.
Not really. RISC-V's benefits are not the "Reduced Instruction Set" part, it's the open ISA part. A small instruction set as actually has several disadvantages. It means you binary bigger because what was a single operation in x86 is now several in RISC-V, meaning more memory bandwidth and cache is taken up by instructions instead of data. Modern CPUs are actually really good at deciding operations into micro-ops. An…
Except this isn't actually true.
> Does getting rid of dramatically increase the performance ceiling? Probably not.
No but it dramatically DECREASES the amount of investment necessary to reach that ceiling.
Assume you have 2 teams, each get the same amount of money. Then ask them to make the highest performing spec compatible chip. What team is gone win 99% of the time?
> And the flexibility of being able to implement a complex operation in microcode, or silicon is essential for CPU designers.
You can add microcode to a RISC-V chip if you want, most people just don't want to.
> The real benefit of RISC-V is anybody can use it.
That is true, but its also just a much better instruction set then x86 -_-
> The x86 instruction set is very very big. According to rough statistics, the ARM64 backend implements more than 1,600 x86 instructions in total, while the RV64 backend implements about 1,000 instructions This is just insane and gets us full-circle to why we want RISC-V.
I think the 1600 number is a coarse metric for this sort of thing. Keep in mind that these instructions are limited in the number of formal parameters they can take: e.g. 16 nominally distinct instructions can be more readily understood/memorized as one instruction with an implicit 4-bit flag. Obviously there's a ton of legacy cruft in Intel ISAs, along with questionable decisions, and I'm not trying to take away fro…
Its clearly necessary to have comparability back to the 80s. Its clearly necessary to have 10 different generation of SIMD. Its clearly necessary to have multiple different floating point systems.
Earlier quoted context omitted.
Box64's documentation is just on installing the Wine x64 builds from winehq repos, because most arm repos aren't exactly hosting x64 software. It's even possible to run Steam with their x64 Proton running Windows games. At least on ARM, not sure about RISC-V. Wine's own documentation says it requires an emulator: https://wiki.winehq.org/Emulation > As Wine Is Not an Emulator, all those applications can't run on other…
> but that's what Box64/box86 already does with some Linux libraries: intercept the api calls and replace them with native libraries. Not sure if it does it for wine Yeah, that's what I meant. It's simple in principle, after all: turn an AMD64 call into an ARM/RISCV call and pass it to native code. Doing that for Wine would be pretty tricky (way more surface area to cover, possible differences between certain Win32 a…
> The x86 instruction set is very very big. According to rough statistics, the ARM64 backend implements more than 1,600 x86 instructions in total, while the RV64 backend implements about 1,000 instructions This is just insane and gets us full-circle to why we want RISC-V.
If an insane instruction set gives us higher performance and makes CPU and compiler design more complex, this might be an acceptable trade-off.
Its simply about the amount of investment. x86 had 50 years of gigantic amounts of sustained investment. Intel outsold all the RISC vendors combined by like 100 to 1 because they owned the PC business.
When Apple started seriously investing in ARM. They were able to match of beat x86 laptops.
The same will be true for RISC-V.
Earlier quoted context omitted.
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…