Re: [committed] Make MIPS VR5400 opcodes more like MDMX

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Sun, 7 Jul 2013, Richard Sandiford wrote:

> The VR5400 has MDMX-like vector instructions, but with different opcode
> assignments.  In both cases the final operand can be (a) a full vector
> register, (b) a broadcast of one vector element, or (c) a broadcast of an
> immediate value.  In the MDMX case these three alternatives were wrapped
> up in the single operand type "Q", but for the VR5400 they were spelled
> out as separate opcode entries.

 AFAIK NEC implemented the orignal MIPS V version of the MDMX 
specification, that used the COP2 major opcode space.  Their 
implementation appears partial though, there's no QH format support and 
some further instructions have been omitted, e.g. RNAU.OB or RNEU.OB.

> One reason for the difference might have been that, in the VR5400 form,
> SLL.OB and SRL.OB do not accept (a) and RZU.OB requires (c).
> However, the format of these instructions in the architecture manual
> is the same as for other OB instructions; the restrictions are given
> in the description instead.  This seems more like the limitations on
> the performance register field (to take one example) rather than
> something that should be handled directly in the opcode table.

 Hmm, TBH I fail to see where you might have read this in the VR54xx 
manual (or what else do you mean by "the architecture manual" in this 
context?; only the VR5432 went in production I'm told BTW), I see no 
mention of any such limitations, and moreover the algorithmic descriptions 
of the RZU.OB, SLL.OB and SRL.OB instructions clearly contradict this by 
indicating that all the usual QB fmtsel encodings are supported:

tt <- select(sel, vt)

(see the frames on pages 721, 726 and 728 of "VR5432 Microprocessor User's 
Manual").

 Do we have a bug here?  Or is that an unknown erratum of the chip being 
"worked around" the hard way?  And what is "the performance register 
field" you're referring to above?

  Maciej