[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqe

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works
Date: Sun, 25 Mar 2007 18:46:44 -0500
User-agent: Thunderbird (X11/20070307)

Axel Zeuner wrote:
On Saturday 24 March 2007 21:15, Anthony Liguori wrote:
Axel Zeuner wrote:
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
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);
+    *(uint64_t*)ptr = v;

Yes, I think the proper thing to do is to use a configure check for GCC version to determine whether or not to use the 32 bit or 64 version of stq_le_p.

There is already a function in cpu-all.h that does the 32 bit version.

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.

I moved to helper2.c because AFAICT helper.c is compiled with the same sort of restrictions as op.c which leads to the compile failure.


Anthony Liguori

Kind Regards


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]