On 09/17/2012 09:04 AM, Andreas Färber wrote:
> Without knowing the code, this does not strike me as the best of ideas:
> SPARC CPUs are rather uncommon these days, so being able to emulate it
> in sparc32-softmmu may be helpful for keeping it working.
>
> Could you elaborate on what exactly is broken and what would need to be
> done as alternative?
See, for instance, patch 2. INDEX_op_qemu_ld64 and INDEX_op_qemu_st64
were unimplemented, caught during tcg startup with --enable-tcg-debug,
and crashing later without.
Handling only sparcv9 host cpus means that lots of code paths are able
to be cleaned up:
(1) Multiply and divide insns are available
(Conditional support for these is not easy.)
(2) Endian-swapping load/store insns are available
(Vastly cleans up qemu_ld/st; by the end of my patch set the
fast path through the tlb is a single insn in the delay slot
of the branch over the call to the helper.)
(3) Conditional move insns are available
(For setcond this is tidier than playing subtract-with-borrow games).
But sparcv9 is now coming up on 20 years old. The amount of hardware
still live that isn't v9 capable is bound to be vanishingly small -- in
much the same way that i386 hosts without i486 bswap. I don't think we
need to use the QEMU TCG code generator as a test case that keeps sparcv7
code alive.
r~
