Re: [Qemu-devel] Patch: sparc arm/mips/sparc register patch

[Martin Bochnig]

x7310aBen Taylor wrote:

>This patch was created by Martin Bochnig (address@hidden)
>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).