Re: [Qemu-devel] [PATCH 04/13] tcg-sparc: Assume v9 cpu always, i.e. force v8plus in 32-bit mode.

[Blue Swirl]

On Mon, Sep 17, 2012 at 5:05 PM, Richard Henderson <address@hidden> 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~