This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [committed] Make MIPS VR5400 opcodes more like MDMX
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: <binutils at sourceware dot org>
- Date: Mon, 08 Jul 2013 21:05:38 +0100
- Subject: Re: [committed] Make MIPS VR5400 opcodes more like MDMX
- References: <87bo6e7k10 dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1307081823060 dot 20590 at tp dot orcam dot me dot uk>
"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> 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?
I was reading the same manual (version 5). The entries for SLL.OB and
SRL.OB say:
The sel field selects the values of vt[] used for each i, which must be
a scalar or an immediate.
The entry for RZU.OB says:
The sel field selects the values of vt[] used for each i. The shift
amount must be an immediate and the value must be 0, 8, or 16.
And yes, I did wonder about enforcing the 0, 8 or 16 restriction too,
but it seemed daft to be doing things like that for such an old processor.
> And what is "the performance register field" you're referring to above?
The "P" operand type, used for MFPC, MTPC, etc.
Richard