5 ms·
Box64 and RISC-V
- FullyFunctional 3y agoHe probably should make BOX64_DYNAREC_RV64NOEXT=1 the default or at least detect it dynamically. Zba and Zbb isn't part of the application profile and other (faster) SoC do not necessarily have them (like TH1520).
- ptitSeb 3y agoThe presence of Zba and Zbb extension is tested before using it.
- brucehoult 3y agoTH1520 (and SG2042, D1) have THead custom extension that contains a lot of the same things as Zba and Zbb, just slightly different and with encodings in the custom opcode spaces. e.g. "th.addsl rd, rs1, rs2, imm2" which has an immediate field for the shift instead of separate instructions (which is just documentation really), and shifts rs2 while Zba's sh1add, sh2add, sh3add shift rs1. Also th.ff0, th.ff1, th.rev, th.tstnbz (same as orc.b but with inverted result) They also have pre- and post-increment loads and stores with writeback of the incremented pointer, and [rs1 + rs2 << imm2] loads and stores, which can be useful for JITing x86 (or ARM) addressing modes. https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.0.0/xthead-2022-09-05-2.0.0.pdf https://github.com/T-head-Semi/thead-extension-spec/releases...
- xpuente 3y agoWe need RISCV hardware with Ztso extension to shine here. Enforcing Total store ordering (TSO) over a release consistency (RC) memory model is otherwise a pain. I don't know if Dynarec is tackling this problem (or just focusing emulation on single-threaded software).
- snvzz 3y agoThis is really cool. Even before the first batch of very high performance RISC-V CPUs hit the market, we're already ready to deal with applications/games that use the legacy x86.
- photonbeam 3y agoIs it feasible to emulate the SIMD via the vector extension?
- syrusakbary 3y agoExcited to see RISC-V supported in Box64. Great work ptitSeb!
- vardump 3y agoGreat work indeed. Although I do wish Box64 could support statically compiled binaries as well.
- boffinAudio 3y agoptitSeb is a dynarec god. I remember watching his progress during the Open Pandora days, getting stuff running on that machine that we never imagined possible..
- jmclnx 3y agoI home RISC-V gets used more and eventually gets cheaper as volumes go up. But, I hope they can avoid things like "Intel ME" and "TPM 1/2/...". If these are needed they should fully open the specs to people can inspect them. Also they should be disabled either by jumpers or whatever RISC uses for BIOS.
- kimixa 3y agoPretty much anything "evil" that can be done with the Intel Management Engine stuff can be done in SM mode, which was introduced in the 386SL and in every x86 since. And that's before we get into update-able microcode, or even asserting that the chip actually matches the RTL if you had access to that. If the supply chain is compromised and you can't trust them, they never needed any new hardware blocks to do bad things. I don't get why people are so obsessed with these new blocks - the level of required trust hasn't really increased.
- rfoo 3y agoTPM spec is fully open. Stop FUD.
- josephcsible 3y agoBy your logic, wouldn't EME be a good thing too, since its spec is also fully open?
- numpad0 3y agoOpen source emulators implementing ME or TPM or whatever is not a problem, so long the user retains full control of private keys. Or if it’ll be even less of a problem if ME CPU is going to be emulated too, because then the community will get to record the evil overlord doing its thing.
- ptx 3y ago> not a problem, so long the user retains full control of private keys The whole point of these technologies is to transfer control of the user's computer to various other actors. So in practice this condition (the user retaining control) is not going to be true, so they remain problematic.
- Joker_vD 3y agoSo, binary translation at instruction-level granularity? I imagine widening the scope to basic blocks would help with quality of the generated code, but I suppose 2/3 of native speed is quite good already.
- rwmj 3y agoThat's basically how the original qemu worked. It used GCC to generate target machine code "snippets" for each source instruction, and then simply stitched them together. (Nowadays the translation is a bit more complex and works at the basic block level.)
- dragontamer 3y agoWild tangent. I've got a gist of what a basic block is due to online discussions. I know it is roughly a list of instructions and that jumps are the boundaries. But I'm looking to understand it on a more fundamental level. I'm guessing the subject is SSA / single static assignment and compiler theory? Just wanna ask publicly if I'm on the right track, and if I'm following this discussion correctly.
- rwmj 3y agoIt's definitely a fundamental concept of compiler theory. Wikipedia has a reasonable description: https://en.wikipedia.org/wiki/Basic_block https://en.wikipedia.org/wiki/Basic_block
- pm215 3y agoIt's not specific to SSA, though SSA assumes it's working with basic blocks (as do a lot of compiler algorithms). And yeah, writeups of compiler theory (and compiler practice) are where to go for more detailed discussion. The core idea I think is that control flow complicates the kinds of analysis a lot of optimisation and other compiler passes need to do; so by first breaking the input into pieces which have very restricted possible flows of control ("only entered at the top, only exited at the bottom" is the classic definition) then: 1. You can get quite a long way with optimisations that only work within a basic block, and the restriction to within-a-BB simplifies things a lot because it can entirely ignore control flow 2. Analysis that only cares about control flow can work on a graph of BBs and ignore the individual-statement/instruction details, because the BB graph captures all the detail of what can branch where
- unixhero 3y ago"x86_64 programs can be now run on RISC-V with reasonable speed." This is absolutely huge
- brucehoult 3y agoBearing in mind emulated x86_64 programs run at a quarter of the speed of native RISC-V code, and today's best RISC-V SBCs run at a quarter of the speed of current Intel and AMD -- somewhere around late Pentium III to Pentium-M or early Core 2. This emulator is going to run at something like Pentium II speeds on current RISC-V boards. That's fine if you want to run late 90s (or earlier) x86 software at the same speed it ran on then. Except that will be i386 code, not x86_64. RISC-V boards are getting faster pretty quickly, but we're still going to need a better x86_64 emulator to get a Rosetta2-like experience on RISC-V even once the CPUs catch up.
- unixhero 3y agoThat is good enough performance for the last-mile scenario where one has to use emulation to get something working.
- ksco 3y agoNote these benchmarks only applies to pure emulation. For "real" programs, it will likely need some shared libraries. Box64 wraps some commonly used shared libraries, and function calls to these libraries will be forwarded to the corresponding native library for execution, which is almost native speed.