I think it might be better to detect when you're going to stay in the macroop before you get to the handler. If you need the microop to decide to fetch and/or throw away the current macroop or not, and you need to fetch (potentially) to create the macroop to create the microop, you end up with a circular dependency. What might be a good idea is for the CPU to record that it intends to end the current macroop, and then in the fault object itself decide whether to overwrite that through maybe the thread context. The fault objects can process the register state of the machine in arbitrarily complex ways, so it would probably be fairly easy for it to decide whether to stay in the current macroop or not. This also has the handy side effect that for ISAs that don't care about this sort of thing, they don't have to do anything special and faults will behave like they do now which I think is what people will expect.
This also makes me wonder what real hardware would do in the case where a store string instruction overwrote itself. Would it recognize the new value of memory right away/at the end of the first iteration that wrote on itself, or would it go until the instruction, for instance, page faulted, at which point it would be restarted and refetch. If I had to guess I'd say the former since I think the idea is for it to be more like a repeatedly executed instruction rather than an instruction that repeatedly executes. I wonder how they get this to happen in a machine where they bundle iterations together like I mentioned before? I think this is a corner case we can safely ignore. Gabe Steve Reinhardt wrote: > 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] > <mailto:[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] <mailto:[email protected]> > http://m5sim.org/mailman/listinfo/m5-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
