Richard Sandiford wrote:
(Quoting out of order)
I feel we're talking at cross-purposes, so just to be clear:
Not really cross-purposes. I'm just rather new to patching something big like a
full-blown, multi-target compiler with 20 years of history to it. Mostly trying
to get an appropriate understanding of your two options so I can work the logic
out in my head and know how to go about attacking this.
This is a step up from writing a md file for processor scheduling :)
2) Implement both (a) and (b). In this case, any gcc code guarded
by TARGET_FIX_R10000 would need to check whether branch-likely
instructions are available. If they are, we can use either
workaround (a) or workaroudn (b). If they aren't, we must
use workaround (b).
I think it's better to target this path. While it's probably an extremely rare
case, because this problem only affects a specific set of processor revisions,
triggering a problem only noticed (so far) on SGI machines running Linux, I tend
to err on the side of caution and think it's probably a good idea to do it right
the first time.
Also, Murphy's Law.
You need to modify the asm templates whatever you do.
This is what has me a little perplexed. The asm templates are #define macros,
and it's kind of dawned on me that my attempts made so far to correct the errata
has me using preprocessor macros that are going to get translated into something
else when gcc itself is compiled, rather than gcc changing what it outputs based
on the flags we send it.
So I'm assuming that, poking around in the sync.md file some, the better
approach might be to pass an extra argument to these atomic macros as they're
evaluated in sync.md. This extra argument being the resultant branch likely
- If -mfix-r10000 isn't needed or -mbranch-likely isn't called,
"beq" gets passed in.
- If -mfix-r10000 is called, and ISA_HAS_BRANCHLIKELY is false,
pass in 28 nops plus "beq" (is there some kind of macro that can
expand a single nop 28 times?).
- If -mfix-r10000 is called and ISA_HAS_BRANCHLIKELY is true
and -mno-branch-likely was not called, then pass in the beqzl
I think that's all the relevant combinations. It's also probably a good idea
too to determine the value to pass as the extra argument before the atomic macro
Is this kind of check something that would need to be done in the md file
directly, referencing the various macros as needed, or would it need to be
defined as a function in mips.c and called inline in sync.md, returning a string
value to the function as it exists? Or is there a better way?
Yes, provided that you never override an explicit -mfix-r10000 or
I copied the same code for R4000 and R4400 for this:
/* Default to working around R10000 errata only if the processor
was selected explicitly. */
if ((target_flags_explicit & MASK_FIX_R10000) == 0
&& mips_matching_cpu_name_p (mips_arch_info->name, "r10000"))
target_flags |= MASK_FIX_R10000;
I assume that won't fire on r12000/r14000/r16000, right? I know R14K isn't
affected, but I haven't tried plugging my old R12K module back into the system
to see what it does. R16K is likely safe.
Actually, I meant: I was wondering about the fact that there seems
to be no online copy of the errata sheet that describes this problem.
I've only ever seen a description of the workaround. I've never seen
a verbatim copy of the errata itself.
I tried seeing whether archive.org had anything old off of the mips.com site,
but nothing close to the old directory structure seems to exist. If I new what
the PDF file name was, it might be possible to track something down on Google
pertaining to the last publicly released revision. Bit surprised, too, on why
NEC doesn't have anything on necel.com. They produced the actual silicon and
had a hand in designing it, if I'm not mistaken. I'd think they would at least
have a copy if no one else.
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic