From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HCNkG-0006jN-Qa for qemu-devel@nongnu.org; Wed, 31 Jan 2007 17:16:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HCNkF-0006jB-At for qemu-devel@nongnu.org; Wed, 31 Jan 2007 17:16:00 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HCNkF-0006j8-4M for qemu-devel@nongnu.org; Wed, 31 Jan 2007 17:15:59 -0500 Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.52) id 1HCNkE-0003pw-MS for qemu-devel@nongnu.org; Wed, 31 Jan 2007 17:15:58 -0500 Message-ID: <45C1153A.2090600@gmx.com> Date: Wed, 31 Jan 2007 23:16:26 +0100 From: Martin Bochnig MIME-Version: 1.0 Subject: Re: [Qemu-devel] Patch: sparc arm/mips/sparc register patch References: <8469713.1170266418239.JavaMail.root@eastrmwml07.mgt.cox.net> In-Reply-To: <8469713.1170266418239.JavaMail.root@eastrmwml07.mgt.cox.net> Content-Type: text/plain; charset=UTF-8 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: qemu-devel@nongnu.org x7310aBen Taylor wrote: >This patch was created by Martin Bochnig (mb1x@gmx.com) >and is for qemu compiling on sparc to work on arm, mips, >and sparc binaries, dealing with the sparc register allocation >issues. > > > > > >------------------------------------------------------------------------ > >diff -ruN qemu-ORIG/target-arm/exec.h qemu/target-arm/exec.h >--- qemu-ORIG/target-arm/exec.h 2005-11-26 05:38:39.000000000 -0500 >+++ qemu/target-arm/exec.h 2007-01-20 02:36:04.000000000 -0500 > > Ben, thanks for submitting this. List: This patch was the quickest hack of getting mips, sparc and arm targets running on SPARC HOSTs (Aurora{1,2}, Suse7.3, OpenSolaris). Global register usage is problematic on SPARC hosts (see ABI). Using slow memory locations may be unperformant, but does produce a functioning binary, and is hence infinitely faster than, what you have in cvs. (Saving/restoring registers before/after each iteration might be better, and is to be followed.) For the odd AREG{n} order in exec.h see my initial explanation from summer, when we first submitted that diff (as part of the sparcv9-stubs etc. / unfortunately has nobody [of the 4 gatekeepers] bothered to merge it into the branch). Here was the old explanation: http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00125.html "" >/ Why do you reorder the registers in Sparc?/ Dumb trying-out is sometimes the only wayout: I *tried* all possible combinations of registers in a systematic testing-approach (I only did this on the sparc-target so far, need to do the same for mips and arm). The assignments in the patch are the best I could get (as many as possible fast host registers, rather than slow main memory locations). Any other order of assignments resulted in segfaults. That's why everything appears to be out of order in target-sparc/exec.h. And if I would bring target-sparc/exec.h in order again, by changing the AREG assignments in dyngen-exec.h, I would mess up all the other targets like i386-softmmu and x86_64-softmmu. One odd observation: If I try to make use of AREG1 in target-sparc/exec.h, it would _always_ result in a segfault in gen_code_buffer(), no matter at all, which physical sparc host-register I would have assigned to AREG1 in dyngen-exec.h. There is something that makes AREG1 itself unusable on sparc hosts for all other emulation targets, except i386-softmmu, x86_64-softmmu (and maybe ppc-softmmu). "" And for the i386-target: I did semi-successfully boot win9x guests on Aurora. (only with a similar hack). Everything works fine on OpenSolaris_SPARC-HOSTs, though (for v7/v8/v8plus). Also fast registers work there (g2,g3,g4,g5,g6).