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: MIPS PLT entry


Maciej W. Rozycki wrote:
> On Sun, 21 Jun 2009, Richard Sandiford wrote:
> 
> > >  The default sequence is out of question -- with MIPS I 
> processors a 
> > > failure to observe the load delay slot will make code 
> completely unusable 
> > > -- there is no interlock.  Correctness first, performance second.
> > 
> > It's not really "out of the question".  As you probably know, there
> > were two competing designs for the PLT stuff, and this was 
> very much a
> > question when the two designs were being discussed.  One of 
> the designs
> > used exactly the kind of cache-friendly 4-insn PLT that 
> Chao-Ying wants
> > at the (deliberate) cost of not supporting MIPS I.
> 
>  I haven't been following discussions in this area -- sorry 
> and something 
> to regret, I suppose.
> 
> > TBH, my position on this was (and still is): forget about 
> MIPS I.  This
> > is an ABI extension designed in 2007/8.  Anyone who wants 
> to play with
> > MIPS I as a hooby is free do so, and is free to use modern 
> tools to do
> > so.  But when it comes to an optional ABI extension like 
> this, it seems
> > quite reasonable to leave MIPS I aside and require the use 
> of MIPS II
> > or above.
> 
>  It is reasonable, but there is no point in deliberately 
> emitting code 
> which is -- by means of ELF file header flags -- known it 
> will not work.  
> It might make sense to bail out on -mplt with a MIPS I header though, 
> however...
> 
> > Now we didn't decide to that, which is fine, and I'm not 
> asking anyone
> > to reopen that debate.  I just don't think this as far 
> outside the sphere
> > of opinion as you seem to suggest.
> 
>  ... it's trivial to implement it flexibly, so that both MIPS 
> I support is 
> retained and newer platforms benefit from a faster sequence, 
> and I plan to 
> do so unless Chao-Ying beats me, ;) so I see no point in doing it 
> otherwise.

Hi Maciej,

  I think your implementation will work.  I was busy recently, so please do it.
Thanks a lot!

Regards,
Chao-ying


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