Re: [MIPS] avoiding certain instruction in delay slots

[Richard Sandiford <rdsandiford at googlemail dot com>]

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

I'm afraid there's no existing code to pull apart a branch and its delay slot.
It'd need to cope with examples like Maciej's where the value is being
loaded into a register that is also used in the branch condition.

TBH I think reordering noreorder code is such a can of worms that editing
the problematic asm files really would be best.  Or just disable the asm
overrides and use the C fallback, where one exists.

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

Well, it's getting on for 10 years since I handled an errata directly :-)
(except for the well-known R10000 speculation problems, which are public).
The ones I did back then weren't confidential as far as I know, since the
customer actively wanted us to add the -mfix- flags and were prepared for
a summary of the errata to be mentioned in the comments and documentation.

CodeSourcery were the ones who implemented the -mfix-24k option.
I don't know whether this errata was deliberately excluded or whether
it wasn't known at the time.

Thanks,
Richard