On Sun, Apr 6, 2008 at 1:11 PM, Ralph Corderoy <<a href="mailto:ralph@inputplus.co.uk">ralph@inputplus.co.uk</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
How about storing generated code on disc?  Or the intermediate IR?  I'd<br>
typically use the same things under qemu day after day and would be<br>
happy to slowly build up a cache on disc.  Perhaps starting qemu with a<br>
'spend time and add to cache' option when I'm getting it to learn and a<br>
'use only what's in the cache already' when I having got the time to<br>
wait.<br></blockquote></div>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.<br>
<br>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.<br>
<br>Greetings,<br><br>Tilmann Scheller<br>