From: Fredrik Noring <noring@nocrew.org>
To: Aleksandar Markovic <amarkovic@wavecomp.com>
Cc: "Aurelien Jarno" <aurelien@aurel32.net>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Jürgen Urban" <JuergenUrban@gmx.de>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/9] target/mips: Require TARGET_MIPS64 for R5900 multimedia instructions
Date: Wed, 16 Jan 2019 16:36:54 +0100 [thread overview]
Message-ID: <20190116153654.GA2918@sx9> (raw)
In-Reply-To: <BN6PR2201MB12516C7D2E235DA81812DDF0C6810@BN6PR2201MB1251.namprd22.prod.outlook.com>
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.
> 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
next prev parent reply other threads:[~2019-01-16 15:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-13 19:00 [Qemu-devel] [PATCH 0/9] target/mips: Limited support for R5900 multimedia instructions Fredrik Noring
2019-01-13 19:02 ` [Qemu-devel] [PATCH 1/9] target/mips: Require TARGET_MIPS64 " Fredrik Noring
2019-01-15 21:03 ` Aleksandar Markovic
2019-01-16 15:36 ` Fredrik Noring [this message]
2019-01-16 19:20 ` Aleksandar Markovic
2019-01-20 18:18 ` "Jürgen Urban"
2019-01-13 19:03 ` [Qemu-devel] [PATCH 2/9] target/mips: Introduce 32 R5900 128-bit multimedia registers Fredrik Noring
2019-01-15 21:20 ` Aleksandar Markovic
2019-01-17 17:03 ` Aleksandar Markovic
2019-01-13 19:03 ` [Qemu-devel] [PATCH 3/9] target/mips: Support the R5900 PCPYLD multimedia instruction Fredrik Noring
2019-01-15 21:24 ` Aleksandar Markovic
2019-01-13 19:04 ` [Qemu-devel] [PATCH 4/9] target/mips: Support the R5900 PCPYUD " Fredrik Noring
2019-01-15 21:28 ` Aleksandar Markovic
2019-01-13 19:05 ` [Qemu-devel] [PATCH 5/9] target/mips: Support the R5900 LQ " Fredrik Noring
2019-01-15 21:34 ` Aleksandar Markovic
2019-01-13 19:06 ` [Qemu-devel] [PATCH 6/9] target/mips: Support the R5900 SQ " Fredrik Noring
2019-01-15 21:37 ` Aleksandar Markovic
2019-01-13 19:07 ` [Qemu-devel] [PATCH 7/9] tests/tcg/mips: Test R5900 multimedia instructions PCPYUD and PCPYLD Fredrik Noring
2019-01-15 21:45 ` Aleksandar Markovic
2019-01-13 19:08 ` [Qemu-devel] [PATCH 8/9] tests/tcg/mips: Test R5900 multimedia instruction LQ Fredrik Noring
2019-01-15 21:56 ` Aleksandar Markovic
2019-01-13 19:09 ` [Qemu-devel] [PATCH 9/9] tests/tcg/mips: Test R5900 multimedia instruction SQ Fredrik Noring
2019-01-15 21:57 ` Aleksandar Markovic
2019-01-14 2:53 ` [Qemu-devel] [PATCH 0/9] target/mips: Limited support for R5900 multimedia instructions no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190116153654.GA2918@sx9 \
--to=noring@nocrew.org \
--cc=JuergenUrban@gmx.de \
--cc=amarkovic@wavecomp.com \
--cc=aurelien@aurel32.net \
--cc=f4bug@amsat.org \
--cc=macro@linux-mips.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).