From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Aleksandar Markovic <amarkovic@wavecomp.com>
Cc: "Fredrik Noring" <noring@nocrew.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Aurelien Jarno" <aurelien@aurel32.net>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Jürgen Urban" <JuergenUrban@gmx.de>
Subject: Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU
Date: Mon, 29 Oct 2018 15:44:57 +0000 (GMT) [thread overview]
Message-ID: <alpine.LFD.2.21.1810291514390.1741@eddie.linux-mips.org> (raw)
In-Reply-To: <BN6PR2201MB1251F9D0D28E1177AF8E6B8DC6F30@BN6PR2201MB1251.namprd22.prod.outlook.com>
On Mon, 29 Oct 2018, Aleksandar Markovic wrote:
> > > Without TARGET_MIPS64, we can't say we emulate R5900 - we are emulating
> > > some other CPU that never existed.
> > >
> > > Convince me that I am wrong.
> >
> > R5900 O32 is usable.
>
> Absolutely not. This kind of emulation infidelity can't be in QEMU
> upstream. Even one step further, this should be forbidden, impossible to
> build.
What do you mean by "R5900 o32 is not usable unless TARGET_MIPS64"?
The user emulation mode does not emulate a CPU, it emulates an OS's user
ABI. None of the MIPS/Linux user ABIs exposes the privileged context and
the user instruction set is also defined by the ABI, as far as both
limitations (e.g. in o32 no MIPS III instructions are allowed, though
32-bit MIPS IV ones are) and extensions (e.g. many FPU instructions, LL/SC
and RDHWR implemented even if missing from hardware) are concerned.
So user emulation is never going to be an accurate CPU emulation anyway.
The R5900 specifically indeed has no way to enforce the o32 instruction
set, unlike all the other MIPS CPUs, but that has to be considered a
quirk, because the operation of the disallowed instructions is
unpredictable in o32 anyway and the first context switch when actually
executing real Linux rather than QEMU user emulation would clobber user
registers. And I don't think we need to define unpredictable operation in
hardware-specific way, it may well send SIGILL telling the user they did
something wrong (as opposed to silent context corruption observed with
real hw).
If you spoke about system emulation, then that would be a different
matter and I would tend to agree, noting however that even there QEMU does
not emulate all aspects of the architecture anyway, so it's always an
approximation defined such as to fit the people's needs.
What is this discussion about anyway? Do you require now for new CPU
subarchitecture acceptance that the whole instruction set has been
implemented with the first submission? I don't think that was the case in
the past and even artificial inexisting CPUs have been created (which
still are there AFAICT), but maybe I'm missing something, and of course
the rules may change.
Maciej
next prev parent reply other threads:[~2018-10-29 15:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-14 14:29 [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU Philippe Mathieu-Daudé
2018-10-14 16:41 ` Fredrik Noring
2018-10-14 21:56 ` Philippe Mathieu-Daudé
2018-10-14 23:03 ` Maciej W. Rozycki
2018-10-15 17:02 ` Fredrik Noring
2018-10-16 9:43 ` Aleksandar Markovic
2018-10-16 18:19 ` Fredrik Noring
2018-10-16 18:37 ` Richard Henderson
2018-10-16 18:52 ` Fredrik Noring
2018-10-16 19:02 ` Maciej W. Rozycki
2018-10-19 18:09 ` Aleksandar Markovic
2018-10-28 19:43 ` Aleksandar Markovic
2018-10-28 20:00 ` Maciej W. Rozycki
2018-10-29 11:52 ` Aleksandar Markovic
2018-10-29 14:51 ` Fredrik Noring
2018-10-29 15:03 ` Aleksandar Markovic
2018-10-29 15:44 ` Maciej W. Rozycki [this message]
2018-10-16 18:55 ` Maciej W. Rozycki
2018-10-15 15:36 ` Fredrik Noring
2018-10-24 18:01 ` Fredrik Noring
2018-10-26 11:17 ` Aleksandar Markovic
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=alpine.LFD.2.21.1810291514390.1741@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=JuergenUrban@gmx.de \
--cc=amarkovic@wavecomp.com \
--cc=aurelien@aurel32.net \
--cc=f4bug@amsat.org \
--cc=noring@nocrew.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.