Re: [Qemu-devel] [PATCH] target-mips: add CPU definition for MIPS-II

[Maciej W. Rozycki]

On Tue, 25 Nov 2014, Vasileios Kalintiris wrote:

> Add mips2-generic among CPU definitions for MIPS.
> 
> Signed-off-by: Vasileios Kalintiris <address@hidden>
> ---
>  target-mips/translate_init.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
> index 148b394..d4b1cd8 100644
> --- a/target-mips/translate_init.c
> +++ b/target-mips/translate_init.c
> @@ -108,6 +108,29 @@ struct mips_def_t {
>  static const mips_def_t mips_defs[] =
>  {
>      {
> +        /* A generic CPU providing MIPS-II features.
> +           FIXME: Eventually this should be replaced by a real CPU model. */

 Umm, this comment is wishful thinking I am afraid, getting a real MIPS II 
processor emulated, i.e. the R6000, will be quite a challenge.

 For one COP0 is completely different to anything else, in particular as 
far as the MMU and the cache are concerned.  Plus we don't know the 
opcodes for some instructions, e.g. the R6000-specific LD and SD 
operations, implemented analogously to LDC1 and SDC1; their opcodes might 
be just the same as MIPS III+ LD/SD (which should be safe for user 
software as in 32-bit user mode they'd trap on MIPS III+ processors such 
as the R4000, etc.), but I wouldn't bet on it.  Likewise all the cache 
maintenance instructions.

 To the best of my knowledge there wasn't any other plain MIPS II 
implementation that might be easier to emulate.  LSI's TinyRISC processors 
were close, but lacked the LL and SC instructions (TR4101 didn't have SYNC 
either).  OTOH they had the MIPS16 ASE implemented; the original version 
that is of course, i.e. no compact jumps, SAVE/RESTORE, etc.  They had no 
FPU either -- a COP1 interface was available and an FPU chip apparently 
planned, but never implemented.

 All the other 32-bit pieces of the era were AFAIK more of MIPS I than 
MIPS II implementations.  That in particular includes IDT and Toshiba 
gear.  Maybe I have missed something and someone can speak out who knows 
better what was available around mid 1990s though.

> +        .name = "mips2-generic",
> +        .CP0_PRid = 0x00018000,

 You need to set CP0.PRId such that CompanyID is 0, meaning a legacy 
processor, or otherwise software will become confused.  In the R6000 the 
actual value was, according to Linux sources, 0x00000300, the same as in 
the R3000A.  I am not actually sure how the two quite different processors 
could be told apart, perhaps poking at another CP0 register would do.

> +        .CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_R4000 << CP0C0_MT),
> +        .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (15 << CP0C1_MMU) |
> +                      (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
> +                      (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA) |
> +                      (0 << CP0C1_CA),
> +        .CP0_Config2 = MIPS_CONFIG2,
> +        .CP0_Config3 = MIPS_CONFIG3,

 Likewise, these aren't right, there were no CP0 Config registers on the 
R6000, the cache subsystem was completely different.  I realise some of 
these bits are fake for internal use, but the rest should best be cleared, 
they can only confuse the reader.

> +        .CP0_LLAddr_rw_bitmask = 0,
> +        .CP0_LLAddr_shift = 4,
> +        .SYNCI_Step = 32,
> +        .CCRes = 2,
> +        .CP0_Status_rw_bitmask = 0x30000011,
> +        .CP1_fcr0 = (1 << FCR0_W) | (1 << FCR0_D) | (1 << FCR0_S),

 This isn't right, for a MIPS II processor CP1.FIR will have these bits 
clear and the Implementation/Revision fields set to a non-zero value to 
let software probe for the presence of the FPU.

> +        .SEGBITS = 32,
> +        .PABITS = 32,
> +        .insn_flags = CPU_MIPS2,
> +        .mmu_type = MMU_TYPE_R4000,
> +    },

 Yeah, as I say the MMU type isn't really right.  Mind that these 
processors used RFE rather than ERET for exception return too, to reflect 
a different exception model (the same as with MIPS I) and consequently 
layout of the CP0.Status register; all of which to be taken into account 
for a MIPS II processor as well.

 What do you really need this processor template for and how do you 
propose to use it?  Is it worth including one upstream that diverges so 
much from what the actual processor was like?  Is it for the user 
emulation mode only?

  Maciej