[MIPS] avoiding certain instruction in delay slots

[Sven Anderson]

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