This is the mail archive of the binutils@sources.redhat.com 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]

Re: PATCH: mips-opc rearrange


"Eric Christopher" <echristo@redhat.com> writes:
> > Not (yet) an objection... but i'm intrigued!  8-)
> > 
> > 'pref' is at the beginning of the table because otherwise it'll be
> > decoded as 'lwc3'.
> > 
> > What instruction are you planning to add to the table that will
> > 'cover' prefx if prefx stays at it's current location in the table?
> 
> Anyhow, I, unfortunately, can't tell you right now.  I'm currently under
> NDA for this.  I just thought it would be easier in the long run if I
> pushed out these changes so that I can release faster when I get
> approval to move the chip to public sources from our customer.

Heh.  I figured as much, but i'm still a bit puzzled.  For this to be
an actual problem, you'd need:

* an entry earlier in the list that matches the same bit pattern that
prefx does,

* that entry and the prefx entry to both be (correctly) 'enabled'
(i.e., both prefx and the other entry are valid instructions on your
processor).

I don't understand how that could actually happen (but obviously you
have more information 8-).


I guess if you know that what you're proposing is correct and
necessary, that's good enough for me -- certainly the change causes no
harm.  8-)

The one remaining comment that i have is that, when you _can_ tell the
world, you should go back and update the prefx entry at the top of the
list to note the conflicting instruction.  (all of the rest of the
entries there, other than nop and ssnop, appear to have notes as to
why they're there.)


chris


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