From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HVcSP-0000oU-Ry for qemu-devel@nongnu.org; Sun, 25 Mar 2007 19:49:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HVcSO-0000ny-E7 for qemu-devel@nongnu.org; Sun, 25 Mar 2007 19:49:05 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVcSO-0000nv-8Y for qemu-devel@nongnu.org; Sun, 25 Mar 2007 18:49:04 -0500 Received: from wx-out-0506.google.com ([66.249.82.224]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HVcQC-0003O5-Ka for qemu-devel@nongnu.org; Sun, 25 Mar 2007 19:46:48 -0400 Received: by wx-out-0506.google.com with SMTP id i30so2917008wxd for ; Sun, 25 Mar 2007 16:46:48 -0700 (PDT) Message-ID: <460709E4.3010907@codemonkey.ws> Date: Sun, 25 Mar 2007 18:46:44 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works References: <200703241850.03116.axel.zeuner@gmx.de> <460586D0.7030209@codemonkey.ws> <200703251215.11441.Axel.Zeuner@gmx.de> In-Reply-To: <200703251215.11441.Axel.Zeuner@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Axel Zeuner Cc: qemu-devel@nongnu.org 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 >> >> > >