[Qemu-devel] Question - Is precise assembly code transpilation possible?

[Qemu-devel] Question - Is precise assembly code transpilation possible?

[Adeel Mujahid]

Hello,


[sorry in advance -- this is bit of an off-topic / academic question w.r.t qemu-devel]


Given the userspace virtualization capability of qemu, is it possible to ship the code that deals with source-to-source mapping of assembly code (say MIPS64 <-> AMD64) as a separate library, so we can potentially build assembly language converter utility?


For instance, consider a C/C++ project with couple of .asm/.S files containing Intel or ATT flavored assembly code for AMD64, and the aim is to port to AARCH64 -- is it even a deterministic problem to transpile precise and bug free AARCH64 assembly code, given the full usage context and all code paths at our disposal? In my understanding, qemu is doing something very similar; but I am not sure as there might be missing optimization opportunities, which render machine converted asm code less likely to match the one hand-roled by humans.


To this date, there are not many tools for assembly language, that convert between different dialects (ATT to Intel) or various architecture instruction sets. I have heard that LLVM has certain project, which aim to convert asmA -> via IR -> asmB but I haven't found it yet.


-- best

Adeel

Re: [Qemu-devel] Question - Is precise assembly code transpilation possible?

[Peter Maydell]

On 27 December 2016 at 21:45, Adeel Mujahid <adeelbm@outlook.com> wrote:
> For instance, consider a C/C++ project with couple of .asm/.S files
> containing Intel or ATT flavored assembly code for AMD64, and the
> aim is to port to AARCH64 -- is it even a deterministic problem
> to transpile precise and bug free AARCH64 assembly code, given the
> full usage context and all code paths at our disposal?

I don't think this approach is likely to produce useful results.
Generally the reason for some code being in assembly is because
it is a critical path for the program and has to execute as
fast as possible. If you try to automatedly translate that to
a different instruction set (with QEMU or otherwise) you will
produce output which is slower than it should be, because it
has to reproduce all the effects of the original code (like
setting flags correctly, getting the right floating point
results, etc).

If you want something that will work on any host architecture
(at the cost of being slightly slow) you should write a C
language version of the assembly code as a fallback path,
or even as the only code path. The C code can then correctly
express what the code actually requires (with no unwanted
side effects like having to set flags, etc) and the compiler
can produce good native code.
(This is useful anyway for testing whether the native assembly
version is broken.)

If the codepath is sufficiently hot that a native assembly
version is absolutely needed, then there is no substitute
for a real human doing the work, possibly starting from what
the C compiler produced. The oddities of different architecture
instruction sets (like how their SIMD works, whether they have
custom instructions for particular operations, etc) are not
something that's really possible for automatic code generation
to make full use of. (If it were possible, you could just
do that in the C compiler back end and write the code in C
in the first place.)

TLDR: doing C -> asm (with the C compiler) will get you
much better quality code than trying to do asm -> asm
with any kind of JIT/emulator like QEMU.

thanks
-- PMM