This is the mail archive of the 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] avoiding certain instruction in delay slots

Hi Richard,

thanks a lot for your answer! See inline.

On 03.02.2014 15:57, Richard Sandiford wrote:
Sven Anderson <> 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 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.

The errata is called E250 for 24KE btw.

Thanks again and best regards,


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