Re: [Qemu-devel] TCG semantics

[Ed Robbins <er209@kent.ac.uk>]

On 6 February 2017 10:39:11 GMT+00:00, Peter Maydell <peter.maydell@linaro.org> wrote:
>On 6 February 2017 at 10:14, Ed Robbins <er209@kent.ac.uk> wrote:
>> It seems pretty good. I was surprised that call instructions can
>> have arguments/return specified, and wonder if those are normally
>> just empty, so that emulation of the target stack/registers just
>> carries the args/return in the background. Otherwise TCG must be
>> detecting the target's arguments/return for each call which would
>> need a clever dataflow analysis, or to follow calling convention
>> and just hope, right?
>
>"target" is a tricky word here, because it's unclear whether it
>means the guest or the host CPU architecture. Note that tcg/README
>always means "TCG target" (ie host) when it says "target", as
>per section 2.
>
>The "call" instruction is a call to a host function, so the
>only calling convention in play is the host OS's ABI. (This
>is what we use for calling C helper functions to implement
>more complex bits of the guest emulation.) We don't know or
>care about the guest's calling convention, because TCG only
>sees things at the level of guest instructions and registers.
>

Makes sense, thanks for clearing that up.

>> I also am not clear about the precise operation of the byte
>> swap instruction, but guess it follows the x86 bswap semantics.
>
>Er, there's more than one definition of how to do byteswaps?
>These instructions just swap the bytes in the however-many-bytes
>wide lump of data they're defined to operate on. (If the
>value type is wider than that lump of data then the insns
>are allowed to assume the high bytes are zeroes, ie undefined
>result if they're not.) Happy to take patches for clarifying
>the docs, though.
>

Maybe there's only one way it's done, but it's good to be clear on the precise operation.

Thanks,
Ed