Hello Aleksandar and Fredrik, > Gesendet: Mittwoch, 16. Januar 2019 um 20:20 Uhr > Von: "Aleksandar Markovic" <amarko...@wavecomp.com> > An: "Fredrik Noring" <nor...@nocrew.org> > Cc: "Aurelien Jarno" <aurel...@aurel32.net>, "Philippe Mathieu-Daudé" > <f4...@amsat.org>, "Jürgen Urban" <juergenur...@gmx.de>, "Maciej W. Rozycki" > <ma...@linux-mips.org>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org> > Betreff: Re: [PATCH 1/9] target/mips: Require TARGET_MIPS64 for R5900 > multimedia instructions > > > 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.
I tried to find the patch where you have a problem with, but I wasn't able. I don't see a problem in [PATCH 1/9]. So I don't know where the actual problem is coming from. Let me explain how what the actual system was able to do: PS2 Linux was using 64-Bit and 128-Bit instructions with ABI o32 since the first day it was released. The toolchains which I released later was also using the feature that the CPU has 128/64-Bit registers which can be used when ABI o32 was used. It is even possible to call Linux ABI n32 syscalls from ABI o32 ELF and vice versa. I used this feature to get around some problems. The Linux kernel which I released was able to execute MIPS III code (complete instruction set) on R5900 without any problems as long as the addresses were within 32-Bit range, e.g. in ABI n32. All missing instructions including IEEE794 compliance were handled by the Linux exception handlers. It was even able to differ between LL/SC and SQ/LQ, although the same instruction encoding is used. It was possible to execute unmodified MIPS III ELF files without any problem. In order to correctly emulate the real PS2 Linux which I released, QEMU has to support 64-Bit registers when using ABI o32 and it would need a way to configure whether all MIPS III instructions should be supported or not. I.e. QEMU should be able to support ABI o32 with a 64-Bit processor. When this is not working there is a problem with the emulation and the problem is not r5900 related, as ABI o32 code is written in a way that it doesn't matter whether the CPU is 128-Bit (like R5900), 64-Bit or 32-Bit. Best regards Jürgen Urban > > > 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 >
