<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks to all those who responded to our email.<br>
<br>
Tilmann Scheller wrote:
<blockquote
cite="mid:aec43a860804051030g14d8514agb574f7fdcbbc9be6@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
However, there is still potential for improvement, one being an
efficient implementation of direct block chaining (in certain cases a
block can directly jump to its successor instead of falling back to the
dispatcher, this is currently implemented with calls instead of jmps,
which should be possible to implement with jmps now, after the recent
work on tail call optimizations). Direct block chaining is a very
useful optimization, on the nbench test case enabling direct block
chaining for regular qemu leads to a 100% speed increase. Another
promising improvement would be the capability to build "super"-blocks
from a set of connected basic blocks, resembling a "hot path". This
work is partially finished and, once complete, should yield a
significant performance improvement since a "super"-block offers a lot
more optimization potential compared to a single basic block.
Nevertheless, it is unlikely that llvm-qemu will ever be much faster
than regular qemu (by replacing its code generator completely, which it
currently does), which is due to the fact that regular qemu has a very
lightweight code generator (it basically only copies blocks of memory
and performs some patching to them and only does static register
allocation) which generates reasonably good code, with a very low
overhead for compilation time. In contrast the LLVM JIT generates
really high quality code (in fact the JIT and the static compiler share
the same code generator), but at a higher price in terms of compilation
time. Ideally the current code generator of qemu would coexist with the
LLVM JIT in llvm-qemu, allowing for different levels of code
quality/compilation time depending on the execution frequency of a
particular block.<br>
<br>
I guess in your situation, the chances are much higher that you will
see a significant performance increase since you apparently don't do
any dynamic binary translation yet, especially if you decide to use
your existing interpreter in combination with the LLVM JIT in a
hotspot-like manner.<br>
</div>
</div>
</blockquote>
We do dynamic binary translation. We are in a similar situation to qemu
except we are SystemC / TLM
compliant for hardware and bus models. Our current technology is
somewhat like qemu, we translate the binary into "semantic ops", which
are pre-compiled at build time, like qemu. Then we execute that code.
The difference is that we extensively use
partial evaluation to translate each binary instruction into one
specialized op. We do not intend to use LLVM at the basic block level.
Our initial idea is similar to what you call super-block, but also to
carry the LLVM compilation in a separate thread, so that we can use the
now available quad-core PC's without slowing down the on-going
execution. In fact similar to what we did a few years ago with the Java
VM,<br>
but on a separate computer because we did not have even dual-core at
the time.<br>
<blockquote
cite="mid:aec43a860804051030g14d8514agb574f7fdcbbc9be6@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>An important question is how you perform the translation from
your source architecture to LLVM IR, for llvm-qemu I could benefit from
the fact that qemu translates from source machine code to an
intermediate representation which has its instructions implemented in
C, thus I could use llvm-gcc to compile the instructions to equivalent
LLVM IR and did not have to worry about the actual translation from
machine code to qemu IR. Going directly from machine code to LLVM IR
certainly requires more effort.<br>
<br>
</div>
</div>
</blockquote>
This is the effort we are considering. But we already have C++ binary
decoders.<br>
<br>
<blockquote
cite="mid:aec43a860804051030g14d8514agb574f7fdcbbc9be6@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>Which architectures are you interested in particularly?<br>
<br>
</div>
</div>
<pre wrap="">ARM, MIPS, PowerPC and SH
</pre>
</blockquote>
<br>
Thanks again, <br>
Vania<br>
<br>
<div class="moz-signature">-- <br>
<meta content="text/html;" http-equiv="Content-Type">
<title></title>
<font face="Helvetica, Arial,
sans-serif">===============================================<br>
Vania JOLOBOFF<br>
LIAMA Sino French Laboratory
<br>
95 Zhongguancun East Road
<br>
Beijing 100080, China
<br>
Tel +86 10 8261 4528 <a class="moz-txt-link-freetext"
href="http://liama.ia.ac.cn/">http://liama.ia.ac.cn/</a><br>
<a class="moz-txt-link-abbreviated"
href="mailto:vania@liama.ia.ac.cn">vania@liama.ia.ac.cn</a>
or <a class="moz-txt-link-abbreviated"
href="mailto:vania.joloboff@inria.fr">vania.joloboff@inria.fr</a><br>
</font>
<br>
</div>
</body>
</html>