Re: [Qemu-devel] [PATCH v2 00/13] tcg/sparc v8plus code generation

[Aurelien Jarno]

On 2014-04-24 13:01, Richard Henderson wrote:
> 
> Our 32-bit build for sparc has been requiring a 64-bit capable chip
> for about 2 years now, by way of requiring move-conditional and LE
> memory instructions.  But we've mostly been generating 32-bit code
> otherwise.
> 
> This patch set changes things so that we make full use of the cpu.
> 
> The sparcv8plus code model requires that 64-bit data be kept only
> in the %g and %o registers.  These are saved by the kernel in full
> 64-bit slots somewhere.  Whereas the %i and %l registers are saved
> via the register window mechanism, and as part of the 32-bit ABI
> we've only allocated 32-bits of stack for storing these.  Since the
> register window can roll at any time, due to signals and interrupts,
> we must consider the high bits of %i and %l to be garbage.
> 
> This implies that we must treat 32-bit and 64-bit quantities differently.
> For the most part, TCG is good with that.  The one case where that falls
> down, however, is when we frob data between widths.  Thus the addition
> of the trunc_shr_i32 opcode.
> 
> This new opcode, or something like it, would have been required if
> we ever got around to supporting MIPS64 code generation, where 32-bit
> quantities must remain sign-extended in the 64-bit register at all times.
> 
> In the case of sparcv8plus, we can get what we need out of the opcode
> merely by setting its register constraints properly.

I am currently trying to review how we handle 32 to 64 and 64 to 32-bit
conversions in QEMU and I have a question about the (now not so) new 
trunc_shr_i32 opcode. Sorry for answering such an old email.

While I understand why we need the new trunc_shr_i32 opcode for MIPS64
(the 32-bit values must be kept sign-extended), I currently fail to
see why it is needed for SPARC. I understand only some registers can be
used to store a 64-bit value, but this is not the case for 32-bit
values. I therefore don't see why we would need any specific constraint
for the 64 -> 32 bit conversion (I understand for ext32u and ext32s).
Does it mean that SPARC needs to keep 32-bit values zero-extended? It
doesn't make sense either given the high bits of some of these registers
can become garbage at any moment.

Can you please give some more details about this so that I can add SPARC
target support to the "tcg: improve size changing ops" series? Thanks.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
address@hidden                 http://www.aurel32.net