Steve Reinhardt wrote:
>
>
> On Tue, Sep 23, 2008 at 9:37 PM, Ali Saidi <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> On Sep 23, 2008, at 9:28 PM, Steve Reinhardt wrote:
> > I believe it's impossible fault on a microop in the middle of a
> > macroop and then resume where you left off in the middle of the
> > macroop flow. If you fault you will roll back to the state at the
> > beginning of the macroop and then on resuming from the fault you
> > either have to reexecute the macroop from the start or skip it
> > entirely.
> >
> > So it seems like the two cases where you're in the middle of a
> > macroop flow and you end the macroop are either (1) the final,
> > specially marked microop of the normal flow hits retire or (2) a
> > microop causes a fault and the whole macroop is discarded and the
> > fault handler is invoked. Interrupts don't count because you'd
> > never take an interrupt in the middle of a macroop.
> I think x86s string copy instruction is a case where you have to be
> able to take an fault (tlb) in the middle of the micro-op and then
> resume. Otherwise it would be possible to prevent the machine from
> making forward progress with a string copy that spanned more pages
> than the tlb holds.
>
>
> Yea, I was thinking of REP instructions as I wrote that... I believe
> the reality is that a REP instruction is actually executed almost as
> if it were N distinct instructions; basically you just re-execute the
> same PC decrementing CX/ECX/RCX each time but only advance the PC when
> the count hits 0. You can take a page fault on any "instance" and
> restart from that instance, or take an interrupt between instances.
> Since all of the state is kept in the GPRs it's totally restartable
> with no special handling.
>
> Steve
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
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
