Project: x86 to ARM binary translator

[Stefan Dösinger]

Am 08.04.2011 um 11:16 schrieb Yale Zhang:
> The 2nd approach, which is almost identical to FX!32 (runs x86 Windows programs on Alpha Windows), will be to do what Stefan proposed 2nd:  create a stand alone process VM to run x86 Windows apps on ARM Windows, using wrappers to translate x86 Windows functions to ARM Windows functions. I think those wrappers/jackets can be generated automatically by scanning header files.
I don't think you can autogenerate the wrappers. They require very deep understanding of the data passed around, e.g. if a parameter is a pointer to a structure you have to convert the members, which also may be pointers, ... You could even have things like double-linked lists where you have to know when to abort. Very often you don't even know the size of memory blobs pointed to by pointers without an in-depth look at other parameters, e.g. glTexImage2D.

Sometimes you might take some shortcuts in the conversion, especially with endianess or alignment. E.g. the D3D API already gives you 16 byte alignment for resources. Instead of swapping the byte order of the image data passed to glTexImage2D(or d3dsurface::lock) you could just change the pixelformat(fmt and type parameter or the d3d pixel format).

As I said, writing such an API wrapper is probably comparable to the effort needed to implement Wine.

> I still don't like this approach due to doing the API translation and instruction set translation in 2 separate programs. Ideally, I would take the Darwine approach of doing both API translation and binary translation both in Wine.
Separation of concerns?

You do of course need a bit of integration. An API wrapper needs a functionality in the CPU emulator to enter and leave the emulated environment, somewhat similar to switching between ring3 and ring0 on x86 CPUs.

> To me, the API translation is less interesting than doing x86 to ARM translation efficiently. I said earlier, QEMU's approach of translating target instructions => micro ops => host instructions is inefficient due to generating redundant operations.
I'm afraid you're looking at the wrong project then, you'd probably be better off looking at something less complex than the Windows API and focus on something that stresses the CPU side more. My impression is that running x86 code on <insert other platform here> is a more or less solved problem. It's probably not solved at maximum efficiency, but there are working solutions(bochs, qemu, probably some JIT compilers)