Petko

Forum Replies Created

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • in reply to: wrpgpr fails at certain conditions #64033

    Petko
    Participant

    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,
    Petko

    in reply to: wrpgpr fails at certain conditions #64035

    Petko
    Participant

    Thanks Chris. I’ve worked around the issue, but I am really curious about what the designers have to say. 🙂

    cheers,
    Petko

    in reply to: wrpgpr fails at certain conditions #64037

    Petko
    Participant

    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.

    thanks,
    Petko

    in reply to: wrpgpr fails at certain conditions #64039

    Petko
    Participant

    Forgot to mention that TLB and both L1 caches (in write back with write allocate mode) are on. This may help explain the strangeness.

Viewing 4 posts - 1 through 4 (of 4 total)