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: [patch] [MIPS] Implement Errata for 24K and 24KE


Catherine Moore <clm@codesourcery.com> writes:
> This patch implements the errata for the 24K and 24KE.  The errata
> calls for a NOP to be emitted after an ERET/DERET instruction followed
> by a branch.  If the ERET/DERET is in a noreorder section, then a
> warning will be issued instead.  This functionality requires the
> -mfix-24k option.
>
> In addition, there was an error in the delay slot handling in
> append_insn.  The code failed to exclude an ERET or DERET instuction
> from being moved into a delay slot.  That failure is also corrected
> with this patch.
>
> Does this look okay to install?

Other hazards of this kind are handled by insns_between.  Was there
a reason why you couldn't use it in this case?

I don't like the idea of warning about an ERET at the end of a
.set noreorder block.  In general, if you have:

   .set noreorder
   ...
   FOO
   ...
   .set reorder
   ...
   BAR

and there is a hazard between FOO and BAR, it is perfectly OK to insert
nops at any point between the ".set reorder" and BAR.  This is what we
do for other hazards, and I think we should be consistent.  Likewise
if you have:

   FOO
   ...
   .set noreorder
   ...
   BAR
   ...
   .set reorder

it is perfectly OK to insert nops between FOO and the ".set noreorder".
(FWIW, using insns_between should give you this for free.)

Also, ".set neorder" has traditionally meant "trust me!".  If we want
to warn about caess where we think the programmer is wrong, I think
we need a consistent story.

Richard


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