Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

["Maciej W. Rozycki" <macro@linux-mips.org>]

Hi Fredrik,

> > target/mips/translate.c:4888:38: error: passing argument 3 of
> > ‘tcg_gen_add2_i32’ from incompatible pointer type
> > [-Werror=incompatible-pointer-types]
> >              tcg_gen_add2_i32(t2, t3, cpu_LO[acc], cpu_HI[acc], t2, t3);
> >                                       ^~~~~~
> 
> Would you know if any MIPS ISA have LO and HI registers that are not
> 32-bit? In QEMU they can obviously be either 32-bit or 64-bit, which
> causes the compilation error here.

 Actually with all 64-bit MIPS ISAs HI/LO are a pair of 64-bit registers, 
that is with MIPS III, MIPS IV, and then MIPS64 R1 to R5 ISAs (base R6 ISA 
removed the MD accumulator, although it has been retained along with the 3 
other ones in the DSP ASE).

 The R5900 CPU is an oddball here, having no 64-bit multiply or divide 
instructions, however documentation indicates these registers are still 
64-bit as far as the base instruction set is concerned, i.e. it says you 
can actually write the upper halves with any bit patterns explicitly with 
the MTHI and MTLO instructions.  And then they're really 128-bit as far as 
the full instruction set of the R5900 is concerned, for all the pipeline 1 
MD instructions operate on bits 95:64 and some MMI instructions operate on 
the full 128-bit width of the accumulator.

 Interestingly enough architecturally trying to use HI/LO values that are 
not properly sign-extended 32-bit numbers does not make the operation of 
32-bit multiply-accumulate instructions unpredictable, as they are 
specified to simply ignore the upper 32 bits of a 64-bit value contained 
there, and the the TX79 manual follows.

 This is unlike with the GPR inputs to all MD instructions, which 
architecturally have to be sign-extended.  Contrariwise, the TX79 manual 
says that GPR inputs to the unsigned variants of MD instructions have to 
be zero-extended, and I do hope this is just an editorial mistake and 
hardware does not follow (especially as the description of MULTU on page 
A-87 disagress in this regard with one on page B-25, and all the relevant 
pseudocode operation specifications consistently use NotWordValue as the 
input validation condition, although that has been nowhere actually 
formally defined).  Otherwise lots of software would break and you'd have 
to use a DSLL32/DSRL32 instruction pair every time before feeding the 
result of other 32-bit calculations to those instructions.

 BTW, notice that the pseudocode operation specification of the TX79 MD 
instructions does clearly indicate the sign-extension of output HI/LO 
contents, e.g. for MULTU we have:

    prod         <- (0 || GPR[rs]31..0) * (0 || GPR[rt]31..0)
    LO63..0      <- (prod 31)32 || prod31..0
    HI63..0      <- (prod 63)32 || prod63..32
    GPR[rd]63..0 <- (prod 31)32 || prod31..0

 HTH,

  Maciej