[Qemu-devel] qemu/target-sh4 op.c

[Qemu-devel] qemu/target-sh4 op.c

[Thiemo Seufer]

CVSROOT:	/sources/qemu
Module name:	qemu
Changes by:	Thiemo Seufer <ths>	07/04/26 23:50:46

Modified files:
	target-sh4     : op.c 

Log message:
	Fix inc8 and dec8 operations, by Magnus Damm.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/op.c?cvsroot=qemu&r1=1.3&r2=1.4

[Qemu-devel] qemu/target-sh4 op.c

[Thiemo Seufer]

CVSROOT:	/sources/qemu
Module name:	qemu
Changes by:	Thiemo Seufer <ths>	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

[Qemu-devel] BUG: qemu-sh4 - shar does logical not arithmetic right shift

[Dave Denholm]

Thiemo Seufer <ths@networkno.de> writes:

(in May 2007)

> CVSROOT:	/sources/qemu
> Module name:	qemu
> Changes by:	Thiemo Seufer <ths>	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              <ddenholm@esmertec.com>       http://www.esmertec.com