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

[Aleksandar Markovic]

> From: Fredrik Noring <address@hidden>
> Sent: Wednesday, January 16, 2019 4:36 PM
> To: Aleksandar Markovic
> Cc: Aurelien Jarno; Philippe Mathieu-Daudé; Jürgen Urban; Maciej W. Rozycki; 
> > address@hidden
> Subject: Re: [PATCH 1/9] target/mips: Require TARGET_MIPS64 for R5900 
> multimedia instructions
> 
> 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.
> 

Fredrik,

Modeling a 64-bit processor as a 32-bit one should not be a part of QEMU
upstream.

Thanks for your efforts so far,
Aleksandar

> > 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