[patch][sh] mac.l insn endian issue

[patch][sh] mac.l insn endian issue

[Andrew STUBBS]

[-- Attachment #1: Type: text/plain, Size: 151 bytes --]

Hi all,

The mac.l simulator implementation is broken on big endian hosts, such 
as Sparc Solaris.

The attached patch should fix the problem.

Andrew

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1208 bytes --]

2008-01-31  Antony King  <antony.king@st.com>

	Fix INSbl28170:
	* interp.c (macl): Fix non-portable implementation.

--- sim/sh/interp.c@@/main/INSIGHT-6.6-ST-1.0-int/1	2007-08-17 15:11:45.000000000 +0100
+++ sim/sh/interp.c	2008-01-31 18:33:16.000000000 +0000
@@ -1433,14 +1433,9 @@
      int m, n;
 {
   long tempm, tempn;
-  long prod, macl, mach, sum;
-  long long ans,ansl,ansh,t;
-  unsigned long long high,low,combine;
-  union mac64
-  {
-    long m[2]; /* mach and macl*/
-    long long m64; /* 64 bit MAC */
-  }mac64;
+  long macl, mach;
+  long long ans;
+  long long mac64;
 
   tempm = RSLAT (regs[m]);
   regs[m] += 4;
@@ -1451,15 +1446,15 @@
   mach = MACH;
   macl = MACL;
 
-  mac64.m[0] = macl;
-  mac64.m[1] = mach;
+  mac64 = ((long long) macl & 0xffffffff) |
+          ((long long) mach & 0xffffffff) << 32;
 
   ans = (long long) tempm * (long long) tempn; /* Multiply 32bit * 32bit */
 
-  mac64.m64 += ans; /* Accumulate   64bit + 64 bit */
+  mac64 += ans; /* Accumulate 64bit + 64 bit */
 
-  macl = mac64.m[0];
-  mach = mac64.m[1];
+  macl = (long) (mac64 & 0xffffffff);
+  mach = (long) ((mac64 >> 32) & 0xffffffff);
 
   if (S)  /* Store only 48 bits of the result */
     {

Re: [patch][sh] mac.l insn endian issue

[Jim Blandy]

I don't think long long is guaranteed to be 64 bits long, but this is
certainly better than what's there now.  (I gather that STMicro has a
blanket assignment.)  So this looks okay to me.  Should Antony add
himself to the write-after-approval list?

Re: [patch][sh] mac.l insn endian issue

[Andrew STUBBS]

Jim Blandy wrote:
> I don't think long long is guaranteed to be 64 bits long, but this is
> certainly better than what's there now.  (I gather that STMicro has a
> blanket assignment.)  So this looks okay to me.  Should Antony add
> himself to the write-after-approval list?

It uses the same types the original implementation did, so I don't think 
it's any worse. I suspect that much of the simulator implementation 
would fall apart if the size of char, short, int and long long were not 
as expected.

ST does indeed have all the proper assignments. I do not know what is 
the proper thing to do with the write-after-approval list. Antony does 
not have write access, hence why I was posting it on his behalf. This 
stuff is usually handled by myself and Denis Pilat, both on the list.

If this is not a problem then I shall go ahead and check in the patch 
(minus the internal ST bug number).

Andrew

Re: [patch][sh] mac.l insn endian issue

[Daniel Jacobowitz]

On Mon, Feb 04, 2008 at 11:53:17AM +0000, Andrew STUBBS wrote:
> If this is not a problem then I shall go ahead and check in the patch  
> (minus the internal ST bug number).

It's not a problem - go ahead.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch][sh] mac.l insn endian issue

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> On Mon, Feb 04, 2008 at 11:53:17AM +0000, Andrew STUBBS wrote:
>> If this is not a problem then I shall go ahead and check in the patch  
>> (minus the internal ST bug number).
> 
> It's not a problem - go ahead.
> 
Thanks, committed.