Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works

[Axel Zeuner]

On Saturday 24 March 2007 21:15, Anthony Liguori wrote:
> Axel Zeuner wrote:
> > Hi,
>
> Hi Axel,
>
> By adding some GCC4 fixes on top of your patch, I was able to get qemu
> for i386 (on i386) to compile and run.  So far, I've only tested a win2k
> guest.
Hi Anthony,

thank you for the test, I like to hear about your success. I have applied your 
patches, compiled and checked qemu-i386-softmmu on i386 without kqemu with 
FreeDos. It works also.

> The big problem (which pbrook helped me with) was GCC4 freaking out over
> some stq's.  Splitting up the 64bit ops into 32bit ops seemed to address
> most of the problems.
>
> The tricky thing I still can't figure out is how to get ASM_SOFTMMU
> working.  The problem is GLUE(st, SUFFIX) function.  First GCC cannot
> deal with the register pressure.  The problem I can't seem to fix though
> is that GCC sticks %1 in %esi because we're only using an "r"
> constraint, not a "q" constraint.  This results in the generation of
> %sib which is an invalid register.  However, refactoring the code to not
> require a "q" constraint doesn't seem to help either.
In the past I made some patches (not published yet) to speed up the helpers 
for 64 operations in target-i386/helper.c on x86_64 and i386 using gcc inline 
assembly.  x86_64 was really easy, but for i386 I had to use "m" and "=m" 
constraints and as less inputs and outputs as possible. 
> The attached patch is what I have so far.  Some help with people more
> familiar with gcc asm foo would be appreciated!

May I suggest some changes?  
I would like to try not to split the 64 bit accesses on hosts supporting it 
native, i.e. something like this:
===================================================================
--- cpu-all.h   (revision 16)
+++ cpu-all.h   (working copy)
@@ -339,7 +339,13 @@

 static inline void stq_le_p(void *ptr, uint64_t v)
 {
-    *(uint64_t *)ptr = v;
+#if (HOST_LONG_BITS < 64)
+    uint8_t *p = ptr;
+    stl_le_p(p, (uint32_t)v);
+    stl_le_p(p + 4, v >> 32);
+#else
+    *(uint64_t*)ptr = v;
+#endif
 }
Furthermore I think one should move helper_pshufw() from target-i386/helper2.c 
into target-i386/helper.c where all the other helper methods reside.   

Kind Regards
Axel

> Regards,
>
> Anthony Liguori
>