qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/9] target/mips: Require TARGET_MIPS64 for R590


From: Fredrik Noring
Subject: Re: [Qemu-devel] [PATCH 1/9] target/mips: Require TARGET_MIPS64 for R5900 multimedia instructions
Date: Wed, 16 Jan 2019 16:36:54 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

Hi Aleksandar,

> Sorry, I have to disagree with this.

It was, without a doubt, entirely clear that the o32 ABI was going to stay
in after this MMI patch series. In other words, this series does not imply
the removal of o32. This is obvious, as discussed previously, since the o32
ABI is currently the main use case for R5900 QEMU and the reason the R5900
was implemented for QEMU to begin with.

> Processor model must stay the same, and
> Linux ABI should not affect, for example, the number and size of processor
> registers - just like it is the case in reality.

I thought Maciej's reply to you was quite clear on this topic?

> QEMU is an independent software tool - it is for example, a compiler-agnostic
> tool, and the only connection between a compiler and QEMU is the processor
> documentation - and this is the reason they work together so well. They 
> shouldn't
> be "tweaked" and "integrated" to work together - both QEMU and compiler should
> rely only on the processor specification, and should not know anything about 
> the
> other side.

The approach was to implement ABIs and instructions that are actually used,
and leave unused or optional instructions for later. The reverse, removing
ABIs in-use (o32) and focusing on unused instructions (MMIs) does not make
sense, so I will obviously not do that.

> My advice for you is to focus on n32 at the time being.
> 
> o32 can be implemented with the same 64-bit processor model, but in a much
> different way that you attempted some time ago. To avoid waste of our energy
> and time, I am suggesting that we finish n32, and think of o32 in future.

The o32 ABI is more important than n32 now, because o32 is in-use and
ready with Glibc, GCC, GAS and the Linux kernel. n32 is easy to enable
with a three-line patch, so we can actually use both now.

I recommend that we implement limited support for MMIs for n32 and
eventually system mode, and leave it as unsupported for o32 for the time
being. [ Perhaps MMIs for o32 could be implemented with 96-bit registers,
in contrast to the 64-bit registers for n32, but having LW and LQ without
LD seems strange to me. ]

Fredrik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]