From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFThF-0007zK-3y for qemu-devel@nongnu.org; Wed, 15 Jul 2015 16:54:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFThD-00048B-R5 for qemu-devel@nongnu.org; Wed, 15 Jul 2015 16:54:29 -0400 Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]:50913) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFThD-00045S-Do for qemu-devel@nongnu.org; Wed, 15 Jul 2015 16:54:27 -0400 Date: Wed, 15 Jul 2015 22:54:23 +0200 From: Aurelien Jarno Message-ID: <20150715205423.GA23115@aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1398369715-16102-1-git-send-email-rth@twiddle.net> Subject: Re: [Qemu-devel] [PATCH v2 00/13] tcg/sparc v8plus code generation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Paolo Bonzini , qemu-devel@nongnu.org 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 aurelien@aurel32.net http://www.aurel32.net