[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] TCG: AREG0 removal planning
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] TCG: AREG0 removal planning |
Date: |
Tue, 10 May 2011 22:28:37 +0100 |
User-agent: |
KMail/1.13.5 (Linux/2.6.38-2-amd64; KDE/4.4.5; x86_64; ; ) |
> TCG uses a fixed global register (AREG0) to which points to currently
> used CPUState, also known as 'env'. Using a fixed register has the
> downsides that the register must be reserved by TCG for generated code
> and by the compiler for compiling a few critical files (op_helper.c
> etc.). The latter also means that any calls to C library may be unsafe
> from those files.
>
> Here are my sketches about transition to AREG0-less world.
> ...
> Translators/op helpers
> ...
> Comments? There are a few blank spots too.
I think a useful, and incremental goal is elimination of global cpu_env state
in C code (i.e eliminate HELPER_CFLAGS and dyngen-exec.h).
We already have much of the infrastructure for this - op_helper v.s. helper.c
and code_gen_prologue for transition in/out of "generated code" state.
In practice generated code probably accesses CPUState often enough that a
dedicated register isn't a bad idea. My guess is that eliminating it from C
code gets us almost all of the useful benefit. Removing it from the code
generator (i.e. TCG_AREG0) may be more pain that it's worth. For changes to
the TCG side we want to consider how we can provide useful aliasing
information, rather than a naive replacement of TCG_AREG0 with a variable.
Paul
Re: [Qemu-devel] TCG: AREG0 removal planning, Stefan Weil, 2011/05/10
Re: [Qemu-devel] TCG: AREG0 removal planning, Richard Henderson, 2011/05/10