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

[Thiemo Seufer]

Dirk Behme wrote:
> Fabrice Bellard wrote:
> >You should add a runtime selection system : see the ARM and PowerPC 
> >targets (I would prefer a parameter to cpu_init(). It was not done that 
> >way on PowerPC for legacy reasons). Each machine should be able to 
> >select the processor it needs (and allow the user to change it if 
> >needed, but it is not the main point).

It might be interesting for MIPS to decouple Machine and CPU somewhat.
E.g. the Malta board supports a number of different 32- and 64-bit CPUs.

> >There is no good reason to make 
> >the selection at compile time because the translator can efficiently 
> >handle any CPU differences at runtime.

I'm a bit dubious about this argument, each instruction needs to be
checked agains a tuple of values. How much performance loss would be
acceptable?

> Find in the attachment a first proposal for runtime
> instruction set configuration for MIPS target. Please
> comment, correct etc.
> 
> Some notes:
> 
> - As first step, only three options for R4K, NEC (partly,
> see below) and FPU are used. The different MIPS ISA levels
> aren't used at the moment and are there for future use.
> Fabrice mentioned that he likes to split the different MIPS
> intstruction set configurations clearly.
>
> - As I understand it, MIPS III is an extension of MIPS II,
> MIPS IV is an extension of MIPS III etc. Therefore I used
> definitions for ISAx which include the smaller ones as well.

Unfortunately it is not that simple. We have the upward-compatible ISAs:

       --> III -> IV -> V -> 64 -> 64R2     (64-bit)
      /                       ^      ^
      |                      /      /
I -> II -----------------> 32 -> 32R2       (32-bit)

plus CPU-specific extensions. For pre-MIPS32 the CP0 instructions are
also CPU-specific, but they are needed for useful CPU emulation. The
GNU toolchain solves this by declaring some specific CPUs to ISA models
(R3000 for MIPS-I, R6000 for MIPS-II, and R4000 for MIPS-III), and
handles their instructions as if they were part of the ISA. Qemu should
IMHO use the same scheme.

The floating point instructions need also some finer granularity, most
ISAs extended the FP instruction set as well.

All of the above still doesn't handle the ASEs, like MIPS16, MIPS3D,
the DSP extensions, etc.

Binutils uses a ISA-ASE-CPU-HAS_FP tuple, since this is at least good
enough for code generation I figure it is also ok for emulation.

> @@ -275,5 +277,58 @@ enum {
>  int cpu_mips_exec(CPUMIPSState *s);
>  CPUMIPSState *cpu_mips_init(void);
>  uint32_t cpu_mips_get_clock (void);
> +void cpu_mips_set_model(CPUMIPSState *env, uint32_t id);
> +
> +enum mips_features {
> +    MIPS_FEATURE_ISA1 = 0x1, /* MIPS I   instruction set architecture */
> +    MIPS_FEATURE_ISA2 = 0x3, /* MIPS II  instruction set architecture */
> +    MIPS_FEATURE_ISA3 = 0x7, /* MIPS III instruction set architecture */
> +    MIPS_FEATURE_ISA4 = 0xF, /* MIPS IV  instruction set architecture */
> +    MIPS_FEATURE_R4K_EXT = 0x10, /* instruction set extension for MIPS R4K */

Those "extensions" seem to be unimplemented, maybe this was intended to
cover partial support for MIPS32R2, IOW, for a 4KE.

> +    MIPS_FEATURE_NEC_EXT = 0x20, /* instruction set extension for NEC CPUs */

This should name the specific CPU core (vr5400 or vr5500?). NEC built
a range of MIPS CPUs (e.g. vr41xx, or R12000) with different capabilities.

[snip]
> +void cpu_mips_set_model(CPUMIPSState *env, uint32_t id)
> +{
> +    env->CP0_PRid = id;
> +    env->features = 0;
> +    switch (id) {
> +    case MIPS_R4Kc:
> +        set_feature(env, MIPS_FEATURE_ISA3);
> +        set_feature(env, MIPS_FEATURE_R4K_EXT);
> +        set_feature(env, MIPS_FEATURE_FPU);
> +        break;

What's the meaning of "R4Kc" here?
- R4000: We don't have 64bit (ISA III) support.
- 4kc: This one has neither ISA III nor FPU.


Thiemo