This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch] [MIPS] Implement Errata for 24K and 24KE
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Catherine Moore <clm at codesourcery dot com>
- Cc: binutils at sourceware dot org
- Date: Fri, 10 Apr 2009 09:06:24 +0100
- Subject: Re: [patch] [MIPS] Implement Errata for 24K and 24KE
- References: <49DD1319.7070108@codesourcery.com>
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