From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JE4Dg-0003f5-3M for qemu-devel@nongnu.org; Sun, 13 Jan 2008 09:53:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JE4De-0003eg-F8 for qemu-devel@nongnu.org; Sun, 13 Jan 2008 09:53:51 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JE4De-0003ec-C3 for qemu-devel@nongnu.org; Sun, 13 Jan 2008 09:53:50 -0500 Received: from mail.esmertec.com ([212.249.37.45] helo=postie.esmertec.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JE4Dd-0004SK-VE for qemu-devel@nongnu.org; Sun, 13 Jan 2008 09:53:50 -0500 Received: from mail.esmertec.com (unknown [10.10.10.10]) by postie.esmertec.com (Postfix) with ESMTP id BE58C866E for ; Sun, 13 Jan 2008 15:53:46 +0100 (CET) Received: from ddenholm by dalmore.esmertec.com with local (Exim 4.63) (envelope-from ) id 1JE4Da-0000rF-By for qemu-devel@nongnu.org; Sun, 13 Jan 2008 14:53:46 +0000 References: From: Dave Denholm Date: Sun, 13 Jan 2008 14:53:46 +0000 In-Reply-To: (Thiemo Seufer's message of "Sun, 13 May 2007 16:35:36 +0000") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] BUG: qemu-sh4 - shar does logical not arithmetic right shift Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Thiemo Seufer writes: (in May 2007) > CVSROOT: /sources/qemu > Module name: qemu > Changes by: Thiemo Seufer 07/05/13 16:35:36 > > Modified files: > target-sh4 : op.c > > Log message: > Remove unnecessary pointer magic in shift operations, by Magnus Damm. > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/op.c?cvsroot=qemu&r1=1.4&r2=1.5 > Hi, I'm just playing with qemu-sh4, and found that 'shar' seems to be doing a logical right shift, rather than an arithmetic right shift. I think that pointer magic was necessary after all. In the current version of target-sh4/op.c, op_shar_Rn() and op_shlr_Rn() are identical, which is surely wrong. void OPPROTO op_shar_Rn(void) { cond_t(env->gregs[PARAM1] & 1); env->gregs[PARAM1] >>= 1; RETURN(); } void OPPROTO op_shlr_Rn(void) { cond_t(env->gregs[PARAM1] & 1); env->gregs[PARAM1] >>= 1; RETURN(); } The behaviour is consistent with env->gregs[] being an array of unsigned ints, (I'm not familiar with qemu details...) and so to get an arithmetic shift, some kind of cast is necessary. dd -- Dave Denholm http://www.esmertec.com