Re: [Qemu-discuss] Output many return values of some instruction

[Peter Maydell]

On 27 November 2014 at 02:47,  <address@hidden> wrote:
>    Many instructions can output only one return value by cpu_T[0] parameter,
> and input parameter is cpu_T[0], there is no other parameter to use for
> output more return value. How can I do it?
>
>    For example:
>
>       Common instruction: ADD, the output return value is eax, so in QEMU
> the output return value is cpu_T[0], then move it to eax.
>
>         tcg_gen_add_tl(cpu_T[0], cpu_T[0], cpu_T[1]);              //
> cpu_T[0] is return value
>
>         gen_op_mov_reg_v(MO_64, R_EAX, cpu_T[0]);             // mov return
> value to eax
>
>         gen_op_update2_cc();                                 // what means
>
>         set_cc_op(s1, CC_OP_ADDB + ot);                       // what means
>
>    After this sequence, it can finish “add” instruction for output to eax.
> But when my instruction “Getsec” want to output 3 return value to
> eax/ebx/ecx. And we have only one parameter cpu_T[0], how to finish it? And
> what means about the update_cc() and set_cc_op ?
>

The cpu_T[] are just ordinary TCG temporaries. For historical reasons
the x86 target creates them at startup and then uses them over and over,
but you can also just create and use your own temporaries if you need
more than just the two. (Don't forget to free them when you're done.)
Some functions in the x86 translator implicitly take arguments in
cpu_T[] rather than as actual function arguments; again, this is just
historical. (x86 is our oldest translator and not very actively
maintained; it has a lot of left-over style from very old versions
of QEMU.)

update_cc() and set_cc_op() are part of the optimisation for handling
the CPU flags: instead of computing all the flags set by an instruction,
we just save enough information about the instruction that we can
compute the flags later. (In this case we save the two inputs to the
ADD via gen_op_update2_cc() and the information about the operation
via set_cc_op()). The idea is that most of the time the flags set
by an instruction are never read by the guest before some following
instruction updates the flags again, so it's faster to only calculate
the flag information at the point where the guest code actually uses
it, even though it requires more book-keeping. If your instruction
affects the flags then you'll need to figure out how this works
so you can add support for your insn.

-- PMM