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" <macro@linux-mips.org> writes:
> On Mon, 15 Jun 2009, Fu, Chao-Ying wrote:
>
>> >  There is a data dependency between the L[WD] instruction and the JR 
>> > instruction and therefore for MIPS I processors you need an 
>> > intermediate 
>> > instruction to fill the load delay slot.  Of course if building for a 
>> > higher processor (and in particular for LD, where it is 
>> > guaranteed) you 
>> > may swap the instructions, but it cannot be unconditional.
>> 
>>   Yes.  But, this design may hurt the performance.  If a CPU fetches
>> 4 instructions per cycle, it will need to fetch again for the 5th instruction next cycle
>> and execute the 5th instruction in pipeline stages.  And this 5th instruction is just 
>> an unused instruction.
>
>  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.

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.

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.

Richard


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