On Mon, May 11, 2026 at 1:58 PM Richard Henderson <[email protected]> wrote: > > On 5/11/26 13:22, James Hilliard wrote: > > +static void octeon_reset_mtm0_mpl_state(void) > > +{ > > + TCGv_i64 zero = tcg_constant_i64(0); > > + > > + /* > > + * MTM0 defines MPL1 as zero; model the architecturally unpredictable > > + * MPL2/MPL4/MPL5 lanes as zero for deterministic emulation. > > + */ > > + octeon_store_mpl(1, zero); > > + octeon_store_mpl(2, zero); > > + octeon_store_mpl(4, zero); > > + octeon_store_mpl(5, zero); > > Where do you get that from? > > The octeon2 documentation, which only has MPL[0-2], MTM0 does *not* modify > either MPL1 or > MPL2. While I don't know what changed with octeon3, I really doubt this > statement is > true. It just doesn't make any sense.
CN50XX-HM-0.99E is OCTEON Plus documentation and covers the older three-lane multiplier state. Its MTM0 definition is MPL0 = rs; P0, P1, P2 = 0. It does not define the OCTEON III rt source or the high multiplier lanes MPL3..MPL5. The behavior modeled here is from CN71XX/OCTEON III. CN71XX defines MTM0 as loading MPL0 from rs, loading MPL3 from rt, setting MPL1 to zero, and zeroing P0..P5. It marks MPL2/MPL4/MPL5 architecturally unpredictable; I modeled those lanes as zero for deterministic emulation. The MPL1/MPL2/MPL4/MPL5 handling is therefore not from the CN50XX/OCTEON Plus MTM0 definition. It follows the newer OCTEON III multiplier-state definition. The legacy form remains encoding-compatible because cnMIPS II MTM0 rs maps to cnMIPS III MTM0 rs, $0, but the modeled state side effects follow the OCTEON III definition. > > > r~ > >
