Re: [Qemu-devel] TCG semantics

[Peter Maydell]

On 6 February 2017 at 10:14, Ed Robbins <address@hidden> 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.

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

thanks
-- PMM