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

[Jürgen Urban]

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