* [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores
@ 2007-10-14 18:34 Robert Reif
2007-10-14 19:25 ` Blue Swirl
2007-10-14 20:14 ` Blue Swirl
0 siblings, 2 replies; 5+ messages in thread
From: Robert Reif @ 2007-10-14 18:34 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
Use stq_* for 64 bit stores.
This fixes one bug where T1 was used twice rather than T1 and T2.
Should the address be 64 bit alligned? i.e. T0 & ~7 rather than T0 & ~3?
Should these unaligned address cause traps?
[-- Attachment #2: stq.diff.txt --]
[-- Type: text/plain, Size: 1963 bytes --]
Index: target-sparc/op_helper.c
===================================================================
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.44
diff -p -u -r1.44 op_helper.c
--- target-sparc/op_helper.c 14 Oct 2007 17:07:21 -0000 1.44
+++ target-sparc/op_helper.c 14 Oct 2007 18:28:37 -0000
@@ -515,8 +515,7 @@ void helper_st_asi(int asi, int size)
stl_user(T0 & ~3, T1);
break;
case 8:
- stl_user(T0 & ~3, T1);
- stl_user((T0 + 4) & ~3, T2);
+ stq_user(T0 & ~3, ((uint64_t)T1 << 32) | T2);
break;
}
break;
@@ -533,8 +532,7 @@ void helper_st_asi(int asi, int size)
stl_kernel(T0 & ~3, T1);
break;
case 8:
- stl_kernel(T0 & ~3, T1);
- stl_kernel((T0 + 4) & ~3, T2);
+ stq_kernel(T0 & ~3, ((uint64_t)T1 << 32) | T2);
break;
}
break;
@@ -591,8 +589,7 @@ void helper_st_asi(int asi, int size)
stl_phys(T0 & ~3, T1);
break;
case 8:
- stl_phys(T0 & ~3, T1);
- stl_phys((T0 + 4) & ~3, T2);
+ stq_phys(T0 & ~3, ((uint64_t)T1 << 32) | T2);
break;
}
}
@@ -615,10 +612,8 @@ void helper_st_asi(int asi, int size)
| ((target_phys_addr_t)(asi & 0xf) << 32), T1);
break;
case 8:
- stl_phys((target_phys_addr_t)(T0 & ~3)
- | ((target_phys_addr_t)(asi & 0xf) << 32), T1);
- stl_phys((target_phys_addr_t)((T0 + 4) & ~3)
- | ((target_phys_addr_t)(asi & 0xf) << 32), T1);
+ stq_phys((target_phys_addr_t)(T0 & ~3)
+ | ((target_phys_addr_t)(asi & 0xf) << 32), ((uint64_t)T1 << 32) | T2);
break;
}
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores
2007-10-14 18:34 [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores Robert Reif
@ 2007-10-14 19:25 ` Blue Swirl
2007-10-14 19:32 ` Robert Reif
2007-10-14 20:14 ` Blue Swirl
1 sibling, 1 reply; 5+ messages in thread
From: Blue Swirl @ 2007-10-14 19:25 UTC (permalink / raw)
To: qemu-devel
On 10/14/07, Robert Reif <reif@earthlink.net> wrote:
> Use stq_* for 64 bit stores.
This could be less optimal for 32 bit hosts, but hopefully the
compiler knows its business.
> This fixes one bug where T1 was used twice rather than T1 and T2.
Great!
> Should the address be 64 bit alligned? i.e. T0 & ~7 rather than T0 & ~3?
>
> Should these unaligned address cause traps?
Yes, but the checks are already generated from translate.c
(gen_op_check_align_T0_7).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores
2007-10-14 19:25 ` Blue Swirl
@ 2007-10-14 19:32 ` Robert Reif
2007-10-14 19:52 ` Blue Swirl
0 siblings, 1 reply; 5+ messages in thread
From: Robert Reif @ 2007-10-14 19:32 UTC (permalink / raw)
To: qemu-devel
Blue Swirl wrote:
>On 10/14/07, Robert Reif <reif@earthlink.net> wrote:
>
>
>>Should the address be 64 bit alligned? i.e. T0 & ~7 rather than T0 & ~3?
>>
>>Should these unaligned address cause traps?
>>
>>
>
>Yes, but the checks are already generated from translate.c
>(gen_op_check_align_T0_7).
>
>
De we to align then again?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores
2007-10-14 19:32 ` Robert Reif
@ 2007-10-14 19:52 ` Blue Swirl
0 siblings, 0 replies; 5+ messages in thread
From: Blue Swirl @ 2007-10-14 19:52 UTC (permalink / raw)
To: qemu-devel
On 10/14/07, Robert Reif <reif@earthlink.net> wrote:
> Blue Swirl wrote:
>
> >On 10/14/07, Robert Reif <reif@earthlink.net> wrote:
> >
> >
> >>Should the address be 64 bit alligned? i.e. T0 & ~7 rather than T0 & ~3?
> >>
> >>Should these unaligned address cause traps?
> >>
> >>
> >
> >Yes, but the checks are already generated from translate.c
> >(gen_op_check_align_T0_7).
> >
> >
> De we to align then again?
The checks aren't fully enabled yet.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores
2007-10-14 18:34 [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores Robert Reif
2007-10-14 19:25 ` Blue Swirl
@ 2007-10-14 20:14 ` Blue Swirl
1 sibling, 0 replies; 5+ messages in thread
From: Blue Swirl @ 2007-10-14 20:14 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
On 10/14/07, Robert Reif <reif@earthlink.net> wrote:
> Use stq_* for 64 bit stores.
I changed also uses of 64 bit loads to ldq. But it looks like this
makes OpenBIOS trigger alignment traps, this is the same reason why
the alignment checks aren't fully enabled. So I can't commit this yet
except for the buggy store fix.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: use_ldq.diff --]
[-- Type: text/x-diff; name="use_ldq.diff", Size: 4633 bytes --]
Index: target-sparc/op_helper.c
===================================================================
--- target-sparc/op_helper.c.orig 2007-10-14 17:01:52.000000000 +0000
+++ target-sparc/op_helper.c 2007-10-14 19:48:20.000000000 +0000
@@ -170,6 +170,7 @@
void helper_ld_asi(int asi, int size, int sign)
{
uint32_t ret = 0;
+ uint64_t tmp;
#ifdef DEBUG_MXCC
uint32_t last_T0 = T0;
#endif
@@ -244,8 +245,9 @@
ret = ldl_code(T0 & ~3);
break;
case 8:
- ret = ldl_code(T0 & ~3);
- T0 = ldl_code((T0 + 4) & ~3);
+ tmp = ldq_code(T0 & ~7);
+ ret = tmp >> 32;
+ T0 = tmp & 0xffffffff;
break;
}
break;
@@ -262,8 +264,9 @@
ret = ldl_user(T0 & ~3);
break;
case 8:
- ret = ldl_user(T0 & ~3);
- T0 = ldl_user((T0 + 4) & ~3);
+ tmp = ldq_user(T0 & ~7);
+ ret = tmp >> 32;
+ T0 = tmp & 0xffffffff;
break;
}
break;
@@ -280,8 +283,9 @@
ret = ldl_kernel(T0 & ~3);
break;
case 8:
- ret = ldl_kernel(T0 & ~3);
- T0 = ldl_kernel((T0 + 4) & ~3);
+ tmp = ldq_kernel(T0 & ~7);
+ ret = tmp >> 32;
+ T0 = tmp & 0xffffffff;
break;
}
break;
@@ -303,8 +307,9 @@
ret = ldl_phys(T0 & ~3);
break;
case 8:
- ret = ldl_phys(T0 & ~3);
- T0 = ldl_phys((T0 + 4) & ~3);
+ tmp = ldq_phys(T0 & ~7);
+ ret = tmp >> 32;
+ T0 = tmp & 0xffffffff;
break;
}
break;
@@ -325,10 +330,10 @@
| ((target_phys_addr_t)(asi & 0xf) << 32));
break;
case 8:
- ret = ldl_phys((target_phys_addr_t)(T0 & ~3)
- | ((target_phys_addr_t)(asi & 0xf) << 32));
- T0 = ldl_phys((target_phys_addr_t)((T0 + 4) & ~3)
+ tmp = ldq_phys((target_phys_addr_t)(T0 & ~7)
| ((target_phys_addr_t)(asi & 0xf) << 32));
+ ret = tmp >> 32;
+ T0 = tmp & 0xffffffff;
break;
}
break;
@@ -515,8 +520,7 @@
stl_user(T0 & ~3, T1);
break;
case 8:
- stl_user(T0 & ~3, T1);
- stl_user((T0 + 4) & ~3, T2);
+ stq_user(T0 & ~7, ((uint64_t)T1 << 32) | T2);
break;
}
break;
@@ -533,8 +537,7 @@
stl_kernel(T0 & ~3, T1);
break;
case 8:
- stl_kernel(T0 & ~3, T1);
- stl_kernel((T0 + 4) & ~3, T2);
+ stq_kernel(T0 & ~7, ((uint64_t)T1 << 32) | T2);
break;
}
break;
@@ -591,8 +594,7 @@
stl_phys(T0 & ~3, T1);
break;
case 8:
- stl_phys(T0 & ~3, T1);
- stl_phys((T0 + 4) & ~3, T2);
+ stq_phys(T0 & ~7, ((uint64_t)T1 << 32) | T2);
break;
}
}
@@ -615,10 +617,8 @@
| ((target_phys_addr_t)(asi & 0xf) << 32), T1);
break;
case 8:
- stl_phys((target_phys_addr_t)(T0 & ~3)
- | ((target_phys_addr_t)(asi & 0xf) << 32), T1);
- stl_phys((target_phys_addr_t)((T0 + 4) & ~3)
- | ((target_phys_addr_t)(asi & 0xf) << 32), T1);
+ stq_phys((target_phys_addr_t)(T0 & ~7)
+ | ((target_phys_addr_t)(asi & 0xf) << 32), ((uint64_t)T1 << 32) | T2);
break;
}
}
Index: target-sparc/op_mem.h
===================================================================
--- target-sparc/op_mem.h.orig 2007-10-14 19:41:01.000000000 +0000
+++ target-sparc/op_mem.h 2007-10-14 19:55:02.000000000 +0000
@@ -36,8 +36,7 @@
void OPPROTO glue(op_std, MEMSUFFIX)(void)
{
- glue(stl, MEMSUFFIX)(ADDR(T0), T1);
- glue(stl, MEMSUFFIX)((ADDR(T0 + 4)), T2);
+ glue(stq, MEMSUFFIX)(ADDR(T0), (T1 << 32) | (T2 & 0xffffffff));
}
void OPPROTO glue(op_ldstub, MEMSUFFIX)(void)
@@ -55,8 +54,11 @@
void OPPROTO glue(op_ldd, MEMSUFFIX)(void)
{
- T1 = glue(ldl, MEMSUFFIX)(ADDR(T0));
- T0 = glue(ldl, MEMSUFFIX)((ADDR(T0 + 4)));
+ target_ulong tmp;
+
+ tmp = glue(ldq, MEMSUFFIX)(ADDR(T0));
+ T1 = tmp >> 32;
+ T0 = tmp & 0xffffffff;
}
/*** Floating-point store ***/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-10-14 20:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-14 18:34 [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores Robert Reif
2007-10-14 19:25 ` Blue Swirl
2007-10-14 19:32 ` Robert Reif
2007-10-14 19:52 ` Blue Swirl
2007-10-14 20:14 ` Blue Swirl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).