Re: [MIPS] avoiding certain instruction in delay slots

[Sven Anderson <sven at anderson dot de>]

Hi Richard,

thanks a lot for your answer! See inline.

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

Sven