That's an interesting optimization... sounds like maybe you don't want to discard the macroop on a fault until you get into the fault handling microcode and determine that it's a real fault and not one of these special cases.
Steve On Tue, Sep 23, 2008 at 11:07 PM, Gabe Black <[EMAIL PROTECTED]> wrote: > That is what the REP (and REPE and REPNE) prefixes are for and how they > work, but that's not the whole story. There are microops which change > the fault handler location, and their intended use, as best I can > remember without actually looking it up, is so that you can cheat a > little in your microcode and then fix things up if you screwed up. For > instance, you might want to unroll a compare string instruction so that > you load a large quantity, say 8 bytes, at once. If you go past the end > of a segment in the process, you'll cause a fault which wouldn't have > happened in the original program. What you do in this case, again > assuming I'm not misinterpreting the patent, is that you set the fault > handling micropc to a special handler which fixes things up and finishes > out the instruction one piece at a time. The handler is still within the > context of the macroop and executes after taking a fault. > > Other than that I mostly agree that it would be ok to use the following > set of rules. > 1. On interrupts or faults, clear out the macroop. > a. If fromRom is set, don't fetch an instruction. > b. If not, work like it works now. > 2. If you're restarting after a mispredict... > a. If you're within a macroop but not at the start, reset the > macroop to the one for the last correct microop. > b. If you're at the start of a macroop or in a regular instruction, > clear the macroop and refetch. > > The tricky part is fitting in cases where you fault midway and resume > the same instruction. There may be other subtle corner cases I'm not > thinking of at the moment, but I'm probably 95% convinced that with the > one case I described aside we'd be ok. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
