Box86 - Linux Userspace x86 Emulator


@ible : that libxcb-xfixes is not wrapped in box86 (yet), so you need an i386 copy of it. Put it in the same folder as zoom binary and box86 will find it.

I looked at that lib and there are quite some symbols, so wrapped it may take time.
 
Hey, I have a quick question to help with a discussion my boyfriend and I are having. Could Box86 be adapted to run on POWER9 CPUs instead of ARM?

I'm not asking you to program support for that, just a general question of 'is it possible'.
 
Doesn't look impossible, though hard to do without any hardware to test it on. The OP of this thread links to the source: https://github.com/ptitSeb/box86/tree/master/src. For reference, the simple implementation of the opcodes is in emu and the dynarec that spits out raw ARM code is in the folder named dynarec, although to begin with it's probably worth turning that off for the power9 platform in main.c.
 
Assuming we went for a AArch64 CPU that still supported 32-bit user mode (the "mobile" type ones usually do) and had an OS that also supported this, then I expect it would be fine - perhaps there would be complications if something like the GPU userspace was 64-bit only though.
 
Silent-Hunter said:
Is it completely impossible to adapt Box86 to 64 bit? Because the next Pyra CPU likely will be.
Click to expand...
To repeat again: even if a box64 existed, it would not help run x86 games, because of the 1:1 translation concept. So, if you want to run ut99 for example, you still need box86, even on a aarch64 os. So you need 32bits subsystem somehow, with GPU driver and all... And yes, that can be problematic sometimes as @daveshah noted.

TL;DR box86 run x86 games, hypothetic box64 run x86_64 games. 2 differents programs for 2 different (even if similar) purpose.
 
Looks to me like the emulated side of things should be okay even on a 64-bit or long-endian CPU, since it looks like it all boils down to standard C to me. Sure, none of the x64 instructions are implemented yet as far as I know, so it wouldn't be able to run x64 code on any machine, but I don't see why box86 can't be ported and compiled on any architecture that supplies the POSIX libs and the C++ libs.

Getting the dynarec up and running might be a bit trickier, but most 64-bit architecures are still capable of working with 32-bit integers, so it may just be the same amount of work as porting it to any other new architecure, but that's a lot more work than getting the emulated side of things up to begin with.

Edit: Ah, right, the GPU interface. I hadn't considered that. I don't know enough about those to say, but it could well complicate matters beyond the feasible I guess.
 
The biggest difference when running on a native 64-bit platform (but not on a 64-bit CPU in a 32-bit compatibility mode) would be the 64-bit pointer size, where as the existing x86 code would be expecting 32-bit pointers.

As for the GPU userspace, hopefully our hypothetical future CPU board has open source GPU drivers that could be rebuilt to get 32-bit SOs :).
 
box86 have, rougly, 3 parts
1. elf loader
2. lib wrapper
3. x86 emulator

to have box64, what is needed is:
1. change elf loader, elf64 is not elf32. That's probably the easier part, but still a 50% rewrite
2. functions calls is sligtly different in 64bits then in 32bits. Especialy function that return double / float. Wrapper need rewrite, and function signatures (so thousand of them), need to be checked. also, callback probably need some work too.
3. x86_64 emulator. While it can be based on x86, there are many prefix at play, and 2 times the number of general register. Major changes of the interpretor. Full rewrite of the dynarec of course.

And again, even with box64 finished, you'll still need box86 for 32bits games.
 
daveshah said:
The biggest difference when running on a native 64-bit platform (but not on a 64-bit CPU in a 32-bit compatibility mode) would be the 64-bit pointer size, where as the existing x86 code would be expecting 32-bit pointers.
Click to expand...
True, but I expect pointers need slightly special handling anyway. I assume box86 probably doesn't support self-modifying code, but you still need to distinguish between a function call to a pointer and a data access of a pointer. I haven't actually looked at box86's memory handling yet but I'd expect the program code not to be in the simulated RAM, so in emulated mode at least a function call is a change of the instruction in the program data array while a memory access goes through to the simulated RAM. Actually it might be simpler if the program data were loaded into the simulated RAM and accessed from there when fetching instructions.

For box86 running on a 64-bit machine, you can't use the actual pointer according to the host OS as the pointer the code sees, since as you say that'd be a 64-bit number. You'd need to supply and respond to a 32-bit offset to the start of the simulated RAM instead, and I think that's all you actually need to do.
 
There is no simulated RAM in box86. The x86 code is at it's required address, and there is no address translation in anyway. That's the core of box86: the function call are directly wrapped x86 -> arm, the function arguments just used as-is (i.e. pointer are not translate).
Of course, the dynarec generate code at another place, but the program is not aware of that. Also, dynarec support Self Modify Code, but not on elf themself (for speed reason), only on code generated on-the-fly.
 
Last edited:
Work continue on box86.

Look what I just got running:
pinball02.png

(speed is even fine on my gigahertz model)
 
You must log in or register to reply here.

Similar threads

P
Box86 Error (loading libs) on rasp 4
Replies
13
Views
4K
pgroessw
P
Z
problems with box86 using direct path on raspberry pi
Replies
9
Views
6K
FBnil
FBnil
ptitSeb
Release Airline Tycoon Deluxe
Replies
13
Views
6K
Farox
Farox
ptitSeb
Release Eric's Ultimate Solitaire Demo
Replies
1
Views
3K
FBnil
FBnil
ptitSeb
Using Box86 on the Pyra
Replies
16
Views
3K
matzesu
matzesu
Back
Top