139c1837db
With Makefiles that have automatically generated dependencies, you
generated includes are set as dependencies of the Makefile, so that they
are built before everything else and they are available when first
building the .c files.
Alternatively you can use a fine-grained dependency, e.g.
target/arm/translate.o: target/arm/decode-neon-shared.inc.c
With Meson you have only one choice and it is a third option, namely
"build at the beginning of the corresponding target"; the way you
express it is to list the includes in the sources of that target.
The problem is that Meson decides if something is a source vs. a
generated include by looking at the extension: '.c', '.cc', '.m', '.C'
are sources, while everything else is considered an include---including
'.inc.c'.
Use '.c.inc' to avoid this, as it is consistent with our other convention
of using '.rst.inc' for included reStructuredText files. The editorconfig
file is adjusted.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
131 lines
4.6 KiB
Plaintext
131 lines
4.6 KiB
Plaintext
TCG Interpreter (TCI) - Copyright (c) 2011 Stefan Weil.
|
|
|
|
This file is released under the BSD license.
|
|
|
|
1) Introduction
|
|
|
|
TCG (Tiny Code Generator) is a code generator which translates
|
|
code fragments ("basic blocks") from target code (any of the
|
|
targets supported by QEMU) to a code representation which
|
|
can be run on a host.
|
|
|
|
QEMU can create native code for some hosts (arm, i386, ia64, ppc, ppc64,
|
|
s390, sparc, x86_64). For others, unofficial host support was written.
|
|
|
|
By adding a code generator for a virtual machine and using an
|
|
interpreter for the generated bytecode, it is possible to
|
|
support (almost) any host.
|
|
|
|
This is what TCI (Tiny Code Interpreter) does.
|
|
|
|
2) Implementation
|
|
|
|
Like each TCG host frontend, TCI implements the code generator in
|
|
tcg-target.c.inc, tcg-target.h. Both files are in directory tcg/tci.
|
|
|
|
The additional file tcg/tci.c adds the interpreter.
|
|
|
|
The bytecode consists of opcodes (same numeric values as those used by
|
|
TCG), command length and arguments of variable size and number.
|
|
|
|
3) Usage
|
|
|
|
For hosts without native TCG, the interpreter TCI must be enabled by
|
|
|
|
configure --enable-tcg-interpreter
|
|
|
|
If configure is called without --enable-tcg-interpreter, it will
|
|
suggest using this option. Setting it automatically would need
|
|
additional code in configure which must be fixed when new native TCG
|
|
implementations are added.
|
|
|
|
System emulation should work on any 32 or 64 bit host.
|
|
User mode emulation might work. Maybe a new linker script (*.ld)
|
|
is needed. Byte order might be wrong (on big endian hosts)
|
|
and need fixes in configure.
|
|
|
|
For hosts with native TCG, the interpreter TCI can be enabled by
|
|
|
|
configure --enable-tcg-interpreter
|
|
|
|
The only difference from running QEMU with TCI to running without TCI
|
|
should be speed. Especially during development of TCI, it was very
|
|
useful to compare runs with and without TCI. Create /tmp/qemu.log by
|
|
|
|
qemu-system-i386 -d in_asm,op_opt,cpu -D /tmp/qemu.log -singlestep
|
|
|
|
once with interpreter and once without interpreter and compare the resulting
|
|
qemu.log files. This is also useful to see the effects of additional
|
|
registers or additional opcodes (it is easy to modify the virtual machine).
|
|
It can also be used to verify native TCGs.
|
|
|
|
Hosts with native TCG can also enable TCI by claiming to be unsupported:
|
|
|
|
configure --cpu=unknown --enable-tcg-interpreter
|
|
|
|
configure then no longer uses the native linker script (*.ld) for
|
|
user mode emulation.
|
|
|
|
|
|
4) Status
|
|
|
|
TCI needs special implementation for 32 and 64 bit host, 32 and 64 bit target,
|
|
host and target with same or different endianness.
|
|
|
|
| host (le) host (be)
|
|
| 32 64 32 64
|
|
------------+------------------------------------------------------------
|
|
target (le) | s0, u0 s1, u1 s?, u? s?, u?
|
|
32 bit |
|
|
|
|
|
target (le) | sc, uc s1, u1 s?, u? s?, u?
|
|
64 bit |
|
|
|
|
|
target (be) | sc, u0 sc, uc s?, u? s?, u?
|
|
32 bit |
|
|
|
|
|
target (be) | sc, uc sc, uc s?, u? s?, u?
|
|
64 bit |
|
|
|
|
|
|
|
System emulation
|
|
s? = untested
|
|
sc = compiles
|
|
s0 = bios works
|
|
s1 = grub works
|
|
s2 = Linux boots
|
|
|
|
Linux user mode emulation
|
|
u? = untested
|
|
uc = compiles
|
|
u0 = static hello works
|
|
u1 = linux-user-test works
|
|
|
|
5) Todo list
|
|
|
|
* TCI is not widely tested. It was written and tested on a x86_64 host
|
|
running i386 and x86_64 system emulation and Linux user mode.
|
|
A cross compiled QEMU for i386 host also works with the same basic tests.
|
|
A cross compiled QEMU for mipsel host works, too. It is terribly slow
|
|
because I run it in a mips malta emulation, so it is an interpreted
|
|
emulation in an emulation.
|
|
A cross compiled QEMU for arm host works (tested with pc bios).
|
|
A cross compiled QEMU for ppc host works at least partially:
|
|
i386-linux-user/qemu-i386 can run a simple hello-world program
|
|
(tested in a ppc emulation).
|
|
|
|
* Some TCG opcodes are either missing in the code generator and/or
|
|
in the interpreter. These opcodes raise a runtime exception, so it is
|
|
possible to see where code must be added.
|
|
|
|
* The pseudo code is not optimized and still ugly. For hosts with special
|
|
alignment requirements, it needs some fixes (maybe aligned bytecode
|
|
would also improve speed for hosts which support byte alignment).
|
|
|
|
* A better disassembler for the pseudo code would be nice (a very primitive
|
|
disassembler is included in tcg-target.c.inc).
|
|
|
|
* It might be useful to have a runtime option which selects the native TCG
|
|
or TCI, so QEMU would have to include two TCGs. Today, selecting TCI
|
|
is a configure option, so you need two compilations of QEMU.
|