This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFA] sim/h8300/h8300.c: Fix the handling of bxor.


Hi,

Attached is a patch to fix the handling of bxor.

Without the patch, running h8300-hms-run on

	mov.w #0x80,r0l
	bld   #7,r0l
	bxor  #7,r0l
	bst   #0,r0l

results in r0l equal to 0x81, whereas the correct simulation should
give 0x80.  This is because bxor is mishandled.  Specifically, "C"
below is a macro that takes a value of either 0 or 1.  "ea & m" takes
0 or m depending on the bit position, so comparing these two does not
mean XOR.  Instead, we should force "ea & m" to take a value of 0 or 1
by saying "!!(ea & m)".

OK to apply?

Kazu Hirata

2003-01-08  Kazu Hirata  <kazu@cs.umass.edu>

	* compile.c (sim_resume): Fix the handling of bxor.

Index: compile.c
===================================================================
RCS file: /cvs/src/src/sim/h8300/compile.c,v
retrieving revision 1.18
diff -u -r1.18 compile.c
--- compile.c	26 Dec 2002 05:44:46 -0000	1.18
+++ compile.c	8 Jan 2003 17:30:45 -0000
@@ -1521,7 +1521,7 @@
 	  OBITOP (O_BIAND, 1, 0, c = !(ea & m) && C);
 	  OBITOP (O_BOR, 1, 0, c = (ea & m) || C);
 	  OBITOP (O_BIOR, 1, 0, c = !(ea & m) || C);
-	  OBITOP (O_BXOR, 1, 0, c = (ea & m) != C);
+	  OBITOP (O_BXOR, 1, 0, c = !!(ea & m) != C);
 	  OBITOP (O_BIXOR, 1, 0, c = !(ea & m) != C);
 
 #define MOP(bsize, signed)			\


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]