On Mon, May 16, 2011 at 7:16 PM, Paul Brook 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 accesses b
> > 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
On 05/11/2011 08:25 PM, Blue Swirl wrote:
>
> 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
On Wed, May 11, 2011 at 9:39 PM, Lluís wrote:
> Blue Swirl writes:
>
>> On Wed, May 11, 2011 at 12:28 AM, Paul Brook 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
Blue Swirl writes:
> On Wed, May 11, 2011 at 12:28 AM, Paul Brook 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. Removing it from
On Wed, May 11, 2011 at 1:57 AM, Paul Brook 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, does the byte sw
On Wed, May 11, 2011 at 12:58 AM, Richard Henderson 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 to the T
On Wed, May 11, 2011 at 12:28 AM, Paul Brook 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 compiler for co
> 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 d
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 gen
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 cri
> 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 la
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
13 matches
Mail list logo
