This is the mail archive of the
mailing list for the binutils project.
Re: [committed] Make MIPS VR5400 opcodes more like MDMX
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 8 Jul 2013 19:14:43 +0100
- Subject: Re: [committed] Make MIPS VR5400 opcodes more like MDMX
- References: <87bo6e7k10 dot fsf at talisman dot default>
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
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?