Forum Replies Created
I figured that much, but was hoping for a little bit more details. 🙂 I prefer ‘ehb’ as it gives better pipeline protection against execution hazards.
Offtopic: is there M6250 based device i can buy to play with?
Thanks Chris. I’ve worked around the issue, but I am really curious about what the designers have to say. 🙂
Hey Chris. Thanks for the reply.
This is how i read table 2.9: If there’s mtc0 to SRSCtl(pss) the _next_ instruction should not be rd/wrpgpr. IOW the hazard continues into the future few clocks.
In my code example the hazard appears to happen _back_ in time. wrpgpr fails if the _following_ instruction is mtc0. I realized that this issue manifests itself more reliably if there’s a long loop before wrpgpr.
My (maybe naive) take on the problem is this: wrpgpr depends on SRSCtl(pss) just as mtc0 to the same location. For some reason and at certain conditions (cpu pipeline feature) wrpgpr executes after the following instruction. If the next instruction happen to be “mtc0 SRSCtl(pss)” we hit the race.
All execution hazards are supposed to affect the following instruction. In this case it appears that execution hazard may also affects the _preceding_ instruction.
Forgot to mention that TLB and both L1 caches (in write back with write allocate mode) are on. This may help explain the strangeness.