From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40812 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pdt2S-0001PK-Cw for qemu-devel@nongnu.org; Fri, 14 Jan 2011 18:26:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pdt2R-00051A-44 for qemu-devel@nongnu.org; Fri, 14 Jan 2011 18:26:36 -0500 Received: from b.c.painless.aaisp.net.uk ([81.187.30.63]:47720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pdt2R-0004rM-04 for qemu-devel@nongnu.org; Fri, 14 Jan 2011 18:26:35 -0500 Received: from zubnet.me.uk ([81.187.243.246] helo=circe) by c.painless.aaisp.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1Pdt2G-0001IP-8l for qemu-devel@nongnu.org; Fri, 14 Jan 2011 23:26:24 +0000 Date: Fri, 14 Jan 2011 23:26:21 +0000 From: Stuart Brady Subject: Re: [Qemu-devel] tcg shift ops and magnitudes larger than register size Message-ID: <20110114232621.GA5779@zubnet.me.uk> References: <20110113085635.GA7296@edde.se.axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110113085635.GA7296@edde.se.axis.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Thu, Jan 13, 2011 at 09:56:35AM +0100, Edgar E. Iglesias wrote: > On Wed, Jan 12, 2011 at 08:13:45PM -0500, Mike Frysinger wrote: > > are there any rules with the tcg sar/shl/shr ops and their magnitudes > > ? such as "magnitudes cannot be larger than the register size" ? > > Yes, the result is undefined in those cases. The result is also undefined if the magnitude is *equal* to the width of the variable. > You need to handle it in the translator. CRIS has similar semantics > as your arch. See target-cris/translate.c:t_gen_lsl() for one way > of doing it. There might be better ways though. How widely used would a set of optional shift ops be, where the magnitude may be equal to (or exceed?) the width? Are there other helpers or op sequences that are commonly shared between targets that would be candidates for splitting out into common code? I know that a proliferation of ops is to be avoided -- the not, neg, andc, orc, eqv, nand and nor ops have been useful though, despite not being strictly essential, and the same could be said for the ext*s, ext*z and bswap ops. One of nice side-benefits of moving to TCG was that simple arithmetic ops and loads/stores worked the same way on all targets. Targets using different orderings for dest / source parameters was not really fun when switching constantly between SPARC, MIPS and x86 targets. :-/ Cheers, -- Stuart Brady