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
