> From: Fredrik Noring <nor...@nocrew.org> > Sent: Wednesday, January 16, 2019 4:36 PM > To: Aleksandar Markovic > Cc: Aurelien Jarno; Philippe Mathieu-Daudé; Jürgen Urban; Maciej W. Rozycki; > > qemu-devel@nongnu.org > 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
