[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [RFC qom-cpu 03/41] cpu: Turn cpu_get_tb_cpu_state() into
Re: [Qemu-ppc] [RFC qom-cpu 03/41] cpu: Turn cpu_get_tb_cpu_state() into a CPUClass hook
Wed, 04 Sep 2013 13:02:29 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
Am 04.09.2013 12:26, schrieb Paolo Bonzini:
> Il 04/09/2013 11:04, Andreas Färber ha scritto:
>> static inline TranslationBlock *tb_find_fast(CPUArchState *env)
>> + CPUState *cpu = ENV_GET_CPU(env);
>> + CPUClass *cc = CPU_GET_CLASS(cpu);
>> TranslationBlock *tb;
>> - target_ulong cs_base, pc;
>> + vaddr cs_base, pc;
>> int flags;
>> /* we record a subset of the CPU state. It will
>> always be the same before a given translated block
>> is executed. */
>> - cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags);
>> + cc->get_tb_cpu_state(cpu, &pc, &cs_base, &flags);
> I'm afraid you cannot turn inline functions into indirect calls like
> this in hot paths.
> One alternative would be to hoist the function call to the beginning of
> cpu_exec, and ensure that any place that modifies the result calls
> cpu_exit. It may be a problem for SPARC's npc stuff, for which I have
> no idea how it works.
Sorry, you lost me here...
> Another is to change cpu-exec.c into a file that is #included by
> target-*/helper.c or something like that. This way cpu-exec.c can still
> use the inline functions.
I don't see how that would help with compiling multiple CPU types into
one executable. A common CPU struct type is needed to compile the core
CPU code once, which in turn requires dispatching for target-specific
bits, such as this one or previously gdbstub and TBD monitor.
Combining only targets with target_ulong of the same size and identical
endianness is a restriction we can accept, I think - examples include
32-bit ARM+SH4A, ARM+MicroBlaze, ARM+Hexagon, ARM+Epiphany.
For performance reasons I have been careful not to have an, e.g.,
cpu_get_tb_cpu_state() wrapper that calls CPU_GET_CLASS() each time.
Many of the "cpu" variables added are being cleaned up later in the
series by argument propagation. And in placement of variables requiring
CPU() cast I have been careful to place them depending on where they
are/will be actually used rather than always placing them at the top.
But if behavior depends on the CPU type, then it cannot be a global
function - cpu.h as-is is a problem and needs to be broken up.
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg