[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:20:44 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8
Il 04/09/2013 13:02, Andreas Färber ha scritto:
> Am 04.09.2013 12:26, schrieb Paolo Bonzini:
>> 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.
cpu-exec.c is all but common to the various targets. You could make
cpu_exec() itself a CPU method. Then calls to cpu_get_tb_cpu_state()
from cpu_exec() can remain inlined instead of being virtual calls.
Not all files have to be compiled "per target", probably only cputlb.c
> 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.