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.
What aliasing information?
Aliasing of cpu state accesses between tcg_global_mem_new_* variables,
qemu_ld/st ops, and helper
On Mon, May 16, 2011 at 7:16 PM, Paul Brook p...@codesourcery.com wrote:
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.
What aliasing information?
Aliasing of cpu state
On Wed, May 11, 2011 at 12:28 AM, Paul Brook p...@codesourcery.com wrote:
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
On Wed, May 11, 2011 at 12:58 AM, Richard Henderson r...@twiddle.net wrote:
On 05/10/2011 01:54 PM, Blue Swirl wrote:
TCG the generator backend
-AREG0 is used for qemu_ld/st ops for TLB access. It should be
possible for the translators to pass instead a pointer to either
CPUState or directly
On Wed, May 11, 2011 at 1:57 AM, Paul Brook p...@codesourcery.com wrote:
While we're at it, let us change things a bit further to allow guest
byte-swap load/store insns to be implemented more efficiently. For
instance, currently a sparc load_asr (little-endian), as emulated on
an x86 host,
Blue Swirl writes:
On Wed, May 11, 2011 at 12:28 AM, Paul Brook p...@codesourcery.com wrote:
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.
On Wed, May 11, 2011 at 9:39 PM, Lluís xscr...@gmx.net wrote:
Blue Swirl writes:
On Wed, May 11, 2011 at 12:28 AM, Paul Brook p...@codesourcery.com wrote:
In practice generated code probably accesses CPUState often enough that a
dedicated register isn't a bad idea. My guess is that
Hi,
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
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
Am 10.05.2011 22:54, schrieb Blue Swirl:
Hi,
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
On 05/10/2011 01:54 PM, Blue Swirl wrote:
TCG the generator backend
-AREG0 is used for qemu_ld/st ops for TLB access. It should be
possible for the translators to pass instead a pointer to either
CPUState or directly to the TLB.
I believe that AREG0 should continue to be present in the
While we're at it, let us change things a bit further to allow guest
byte-swap load/store insns to be implemented more efficiently. For
instance, currently a sparc load_asr (little-endian), as emulated on
an x86 host, does the byte swap twice.
FWIW this also ends up interacting with the
12 matches
Mail list logo
