On Mon, Sep 17, 2012 at 5:05 PM, Richard Henderson <r...@twiddle.net> wrote: > 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.
No Linux distros supports Sparc32 anymore. There's NetBSD and OpenBSD though. Would it make sense to break up tcg/sparc into tcg/sparc32 and tcg/sparc64? That way it would be possible to give Sparc32 a chance of getting fixed. But I wouldn't object removal either. > > > r~
