* [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).