This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]