Re: [Qemu-devel] cpu_regs in target-i386

[Xin Tong]

Thank you very much. This is very helpful.

Xin


On Sun, Nov 27, 2011 at 6:33 PM, Peter Maydell <address@hidden> wrote:
> On 27 November 2011 23:07, Xin Tong <address@hidden> wrote:
>> can you please show me where the (120) is used. we pushed a global
>> TCGV to the gen_opparam_ptr. lets say the backend is i386 and the
>> operation is an add.
>
> So, you can find it like this:
>
> (1) starting from tcg_global_mem_new_i64 we follow where that
> offset went, and we see that tcg_global_mem_new_internal stores
> it in the mem_offset field of a TCGTemp structure.
> (2) So we grep for uses of mem_offset, and we find that tcg.c
> uses it in the register allocator; basically there are a lot
> of places where we say "if this is a TEMP_VAL_MEM then either
> load or store the value". We do that load or store by calling
> tcg_out_ld() or tcg_out_st(), passing the mem_offset value
> (plus some other stuff like the base register and whatever
> temporary register the allocator wants to use for it).
> (3) grepping for tcg_out_ld() we find it's implemented in the
> backends. Specifically, tcg/i386/tcg-target.c has the x86
> version which writes out x86 code to do a load/store from
> [reg+offset].
>
> So we can deduce that TCG doesn't try to be particularly
> clever about these values -- we just load them when we need
> them and store them again when they are updated. (We don't
> try to support issuing add instructions with memory operands
> even if the host CPU architecture has them.)
>
> I didn't particularly know this in advance -- I'm just looking
> through the code and searching for uses of things and implementations
> of functions. QEMU's code generation is not particularly
> exotic:
>  * guest-specific front end decodes instructions and writes
>   intermediate representation
>  * optimisation pass that works on IR
>  * liveness analysis (ie work out when data values are no
>   longer needed, so we can reuse the registers they're in)
>  * turn IR into generated code by making calls to a handful
>   of host-specific backend functions
>
> (about the only slightly unexpected thing is that we do the
> register allocation as we go along generating the final
> code, rather than doing it as a separate pass.)
> So if you can get a grasp of the general structure then
> following through it to answer specific questions like this
> should be straightforward.
>
> -- PMM
>