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

[Anthony Liguori <anthony@codemonkey.ws>]

Axel Zeuner wrote:
> 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
>  }
>   

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.

Regards,

Anthony Liguori

> Kind Regards
> Axel
>
>   
>> Regards,
>>
>> Anthony Liguori
>>
>>     
>
>