[Top][All Lists]

[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

From: Andreas Färber
Subject: Re: [Qemu-ppc] [RFC qom-cpu 03/41] cpu: Turn cpu_get_tb_cpu_state() into a CPUClass hook
Date: Wed, 04 Sep 2013 13:02:29 +0200
User-agent: 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]