Re: [MIPS] avoiding certain instruction in delay slots

[Sven Anderson <sven at anderson dot de>]

Am 03.02.2014 um 17:56 schrieb Richard Sandiford <rdsandiford@googlemail.com>:

> Sven Anderson <sven@anderson.de> 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)?
> 
> Right.

Well, I have to break the contract anyway, so I'd be happy if my tools would support me with it. ;-) For example uClibc-0.9.32/libc/string/mips/memcpy.S contains problematic code. Instead of editing all the files by hand, it would be great to have a tool that automatically changes the instruction order, no matter if it is in a noreorder section. I understand the reluctance to support this in the assembler itself, but isn't an option to work around a buggy CPU a case for an exception, that breaks the rules with a "use-at-your-own-risk"-switch?

If I'd like to implement this at least for my personal gas edition, how can I implement the reordering? Is there similar code I could look at?

>>> 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.

I see, thanks for the advice.

> 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.

Well, these patches barely have enough originality to be covered by copyright, but anyway I would rewrite them on my own. The question is more, if this errata workaround is of general interest, since it doesn't seem to be public and I have no idea which other SoC might have the same bug. Is it usual that errata are confidential? If yes, how are they usually handled by gcc/gas?


BR

Sven