qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC qom-cpu 03/41] cpu: Turn cpu_get_tb_cpu_state() in


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC qom-cpu 03/41] cpu: Turn cpu_get_tb_cpu_state() into a CPUClass hook
Date: Wed, 04 Sep 2013 13:20:44 +0200
User-agent: 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
and cpu-exec.c.

Paolo

> 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.
> 
> Andreas
> 




reply via email to

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