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 >
