[LLVMdev] llvm-qemu. (Was: Newbie)

Tilmann Scheller tilmann.scheller at googlemail.com
Sun Apr 6 06:28:07 PDT 2008


On Sun, Apr 6, 2008 at 1:11 PM, Ralph Corderoy <ralph at inputplus.co.uk>
wrote:

> How about storing generated code on disc?  Or the intermediate IR?  I'd
> typically use the same things under qemu day after day and would be
> happy to slowly build up a cache on disc.  Perhaps starting qemu with a
> 'spend time and add to cache' option when I'm getting it to learn and a
> 'use only what's in the cache already' when I having got the time to
> wait.
>
A similar approach is used by FX!32 to translate Win32 x86 binaries to Alpha
binaries (to run them on Windows NT for Alpha). Basically FX!32 performs
incremental static recompilation. On the first run the binary runs with an
interpreter and profiling data is gathered (e.g. the targets of indirect
branches, as they usually can't be determined statically). FX!32 runs a
background process which uses the gathered data to statically recompile the
binary (doing optimizations which would be too expensive to be done at
runtime). The next time the user executes the binary, he is already
executing native Alpha code and in case he executes parts of the program
which he didn't reach the last time or which FX!32 couldn't determine
statically, FX!32 will fall back to the interpreter and collect profiling
data again. This way the binary is translated incrementally from x86 to
Alpha.

In principle a system like FX!32 could be implement with llvm-qemu. For
user-mode emulation it is certainly possible (these days, the demand for
such a system seems rather low though). However, for system emulation
(unlike user-mode emulation, system emulation also requires MMU emulation) I
would say static recompilation is not feasible since addresses change very
frequently, e.g. a program running on the system is very likely to be loaded
at different addresses on every invocation, so you would end up falling back
to the interpreter most of the time.

Greetings,

Tilmann Scheller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080406/f8559a54/attachment.html>


More information about the llvm-dev mailing list