Re: [Qemu-devel] [PATCH] MIPS instruction set configuration

[Dirk Behme]

Thiemo Seufer wrote:
...
> I recommend to go for a sufficiently flexible interface first, and then
> introduce it gradually in all appropriate places. A macro like:
>
> MIPS_OPC(ISA, ASE, CPU)
>
> which compares the arguments with the currently selected CPU emulation
> and throws an RI exception if the feature doesn't exist:
>
>     ...
>     case OPC_LD:
>         MIPS_OPC(MIPS-III, 0, 0);
>         ...
>         break;
>     ...
...
> My point is those MIPS_USES_*/MIPS_FEATURE_* should be abstracted
> better, that is, they should move in the implementation of the
> MIPS_OPC macro.

I really like your proposals of MIPS_OPC() and better
abstraction of MIPS_USES_*/MIPS_FEATURE_*!

Do you think you can post a patch which introduces the basic
parts of this functionality in the short term? Then we can
use it as a starter for more improvements.

> This is not meant as an objection, I'm just drawing from experience
> with binutils, where it took some iterations (and wasted effort) to
> get it sufficiently right.

You are right with your wasted effort argument above as well.

However, my patch does not only introduce
MIPS_USES_*/MIPS_FEATURE_*. It additionally introduces
cpu_mips_set_model() (yes, I know, this can be improved as
well, as Fabrice mentioned). So it shouldn't be to much
wasted effort to keep the cpu_mips_set_model() and convert
the three or four places of my MIPS_USES_*/MIPS_FEATURE_* to
your MIPS_OPC abstraction (in case my patch is accepted ;) ).

Btw, while talking about cpu_mips_set_model(): While
thinking about it I found that we should try to keep the
generic  parts of cpu and model selection logic in sync with
other architectures, I think at least with ARM (where
possible). There will be differences in details like in
instruction set splitting with your MIPS_OPC logic. But
would be nice if we make generic improvements to e.g.
cpu_mips_set_model() at MIPS, we make the same at ARM as well.

...
> Well, there is no CPU named "R4Kc". What qemu emulates today resembles
> mostly a 4kc, that is a MIPS32R1 CPU which has no FPU support.

Yes, I understand this. But two things:

First, in the current MIPS configuration FPU is enabled for
"R4Kc". I think we shouldn't disable anything what is there
at the moment, without giving an alternative for people
using this (e.g. introducing an additional machine). And
this only because there is no real world equivalent for this.

Second, while I agree that there is no real world equivalent
for this, I think this is one of the biggest advantages of a
simulator like qemu: Your are able to configure and test
machine and feature combinations which will never exist in
real world really quickly.

This second point is "the simulated machines should model
the real world 110% exactly" vs "I don't need 100%
simulation accuracy and wan't to be able to use
configurations which are not possible in real world".
Depends on how people will use qemu. I think while the first
argument may be valid for x86 where people want to run e.g.
Windows on Linux, for embedded processors like ARM or MIPS
the second may be valid and interesting as well.

Cheers

Dirk