This is the mail archive of the
mailing list for the binutils project.
Re: [MIPS] avoiding certain instruction in delay slots
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Sven Anderson <sven at anderson dot de>
- Cc: binutils at sourceware dot org
- Date: Mon, 03 Feb 2014 16:56:03 +0000
- Subject: Re: [MIPS] avoiding certain instruction in delay slots
- Authentication-results: sourceware.org; auth=none
- References: <52EF785C dot 7010509 at anderson dot de> <87fvo0dz1g dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <52EFBD4D dot 1040505 at anderson dot de>
Sven Anderson <firstname.lastname@example.org> writes:
> On 03.02.2014 15:57, Richard Sandiford wrote:
>> (In answer to your question, the assembler really does need to honour
>> ".set noreorder"; we can never insert fixup nops while that's in effect.)
> Is it not allowed "by contract" or is it technically not possible?
By contract. ".set noreorder" means we must assemble the code exactly
as written, with no extra instructions or swaps. (This is of course
what most assemblers do by default.)
> So the only thing I can do is to bail-out with an error, if there is a bad
> instruction found in a delay-slot in a noreorder section (in manually
> written assembly)?
>> If this particular errata applies specifically to delay slots though,
>> you'd need to handle it differently from -mfix-24k. You'd need to teach
>> both GCC and GAS about the restrictions. In the GCC case this would be
>> by setting the "can_delay" attribute to "no" for the problem cases,
>> while for GAS it would be making can_swap_branch_p return false.
> In the meantime I found some sources of the patched toolchain in the net
> which contained a patch for gcc-3.4.4. It does exactly what you propose
> here (although there was no can_swap_branch_p() at that time). However,
> if I understand it correctly, both things make sure that no bad code is
> constructed, but what for the case of manually written assembly that
> already filled the delay slots in a reorder section? Could I correct
> that? I just want to guarantee that 100% of the executables are free of
> the errata bad-code, and better fail with an error as a last resort.
Yeah, the error would need separate code, although obviously it'd be nice
for the error test and can_swap_branch_p to share a common subroutine
that checks for problem instructions. append_insn is probably the best
place to test for the error.
BTW, not sure whether you were thinking of sending in a patch, but if you do,
it'd need to be covered by an FSF copyright assignment. That means you'd
probably need to write the patch from scratch rather than base it on an
existing one from the internet.