This is the mail archive of the
mailing list for the binutils project.
Re: [MIPS] avoiding certain instruction in delay slots
- From: Sven Anderson <sven at anderson dot de>
- To: binutils at sourceware dot org, rdsandiford at googlemail dot com
- Date: Mon, 03 Feb 2014 17:01:17 +0100
- 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>
thanks a lot for your answer! See inline.
On 03.02.2014 15:57, Richard Sandiford wrote:
Sven Anderson <firstname.lastname@example.org> writes:
I'm working with an 24kc-based SoC for which - because of an errata -
certain instructions must not appear in branch delay slots (mainly lw
and sw). I could generally use gcc's -fno-delayed-branch to compile for
the target. But this has the two disadvantages that, 1. I additionally
have to manually patch assembler code, and 2. I disable more
optimization than necessary. Therefore I tried to patch gas to produce
according code by adapting the fix-24kc code in tc-mips.c, but it didn't
work as expected. It's probably because I have no clue how exactly the
process of assembling really works, that is when and if the delay slots
are filled by gas, for instance.
Therefore I want to kindly ask to give me some advice how to implement
this correctly. Would it even be possible to apply the constrain even to
noreorder assembly-code or at least give a warning about it? If this is
of general interest, I would be happy to submit a patch.
It depends on what sort of errata it is. Is the problem specific to
delay slots? Or is it a case of "instruction X must not be followed
by instruction Y in certain situations"?
It's specific to delay slots.
(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? 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
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.
The errata is called E250 for 24KE btw.
Thanks again and best regards,