[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
Re: [Qemu-devel] [PATCH 1/9] target/mips: Require TARGET_MIPS64 for R5900 multimedia instructions
Sun, 20 Jan 2019 19:18:12 +0100
Hello Aleksandar and Fredrik,
> Gesendet: Mittwoch, 16. Januar 2019 um 20:20 Uhr
> Von: "Aleksandar Markovic" <address@hidden>
> An: "Fredrik Noring" <address@hidden>
> Cc: "Aurelien Jarno" <address@hidden>, "Philippe Mathieu-Daudé"
> <address@hidden>, "Jürgen Urban" <address@hidden>, "Maciej W. Rozycki"
> <address@hidden>, "address@hidden" <address@hidden>
> Betreff: Re: [PATCH 1/9] target/mips: Require TARGET_MIPS64 for R5900
> multimedia instructions
> > 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.
> Modeling a 64-bit processor as a 32-bit one should not be a part of QEMU
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
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
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.
> > > 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
[Qemu-devel] [PATCH 2/9] target/mips: Introduce 32 R5900 128-bit multimedia registers, Fredrik Noring, 2019/01/13
[Qemu-devel] [PATCH 3/9] target/mips: Support the R5900 PCPYLD multimedia instruction, Fredrik Noring, 2019/01/13
[Qemu-devel] [PATCH 4/9] target/mips: Support the R5900 PCPYUD multimedia instruction, Fredrik Noring, 2019/01/13
[Qemu-devel] [PATCH 5/9] target/mips: Support the R5900 LQ multimedia instruction, Fredrik Noring, 2019/01/13
[Qemu-devel] [PATCH 6/9] target/mips: Support the R5900 SQ multimedia instruction, Fredrik Noring, 2019/01/13