On Saturday 24 March 2007 21:15, Anthony Liguori wrote:
Axel Zeuner wrote:
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
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.
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 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.
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;