Yea, it seems like it could start translating, get to commit cause a fault that refetchs or replays that instruction...
Ali On Jan 16, 2009, at 11:08 PM, Korey Sewell wrote: > Isn't "before it commits" the same as "before/while it's executing"? > > On Sat, Jan 17, 2009 at 1:35 AM, Gabe Black <[email protected]> > wrote: > I don't think that'll work because the fix up needs to happen > before/while the instruction executes, not on the side before it > commits. > > Korey Sewell wrote: > > OK, I'm not sure why you cant just let the instruction go on as > > regular, have some object does does your special x86 stuff, then > when > > that finishes signals something to the CPU to acknowledge the fix > up. > > > > Basically, I'm not sure you cant just manipulate the signals that > are > > sent between stages and also maybe the condition for when a > > instruction commits so that this handles the x86 special case. > > > > However, I havent thought about it for very long so may be more > > complex than I know. > > > > On Fri, Jan 16, 2009 at 2:51 PM, <[email protected] > > <mailto:[email protected]>> wrote: > > > > Sure. Also the current process is not inaccurate, or at least > > mostly accurate if > > you want to be picky, for all the ISAs except x86. > > > > Currently, translation works like this as I'm sure you know: > > 1. Instruction generates request. > > 2. CPU asks TLB to translate request possibly generating a > fault. > > 3. If there's a fault, the request is dropped and the fault is > > handled. > > 4. If not, the translated request is sent to the memory system. > > 5. Get coffee while request is handled. > > 6. The request comes back and the instruction can be finished. > > > > The problem is that with current ISAs if there's a TLB miss that > > generates an > > architected fault which gets handled in the normal way in step > 3, > > and normal > > execution fixes things up. In x86, though, a TLB miss triggers a > > hardware > > mechanism which fixes things up, and the current instruction > > continues as if > > nothing happened. In the case of a TLB miss, x86 would > > realistically do > > something more like: > > 1. Instruction generates request. > > 2. CPU asks TLB to translate request possibly generating a > fault. > > 2.5 Get coffee while page table walk happens. > > 3. If there's a fault, the request is dropped and the fault is > > handled. > > 4. If not, the translated request is sent to the memory system. > > 5. Get coffee while request is handled. > > 6. The request comes back and the instruction can be finished. > > > > What I've been doing to fake this is that the TLB miss itself > > fixes up the TLB > > when it's invoked. This sort of works, except if the walk itself > > turns up a not > > present page or encounters some other problem. Then you've > already > > started > > handling one fault, so there's nothing to do with the new one. > > > > The two options I mentioned before were to either: > > 1. Invoke the new fault from the invoke method of the TLB miss. > > 2. Change the CPU models so that translation can put off > finishing. > > > > Gabe > > > > Quoting Korey Sewell <[email protected] <mailto:[email protected] > >>: > > > > > Gabe, > > > Can you step-by-step explain what's inaccurate about the > current TLB > > > process? > > > > > > On Wed, Jan 14, 2009 at 6:31 PM, <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > > Has anyone had a chance to give this some thought? Could > > Kevin/Korey > > > > comment on > > > > how hard they think it would be and/or how much overhead > there > > would be to > > > > make > > > > translation be deferrable in O3? > > > > > > > > Gabe > > > > > > > > Quoting [email protected] > <mailto:[email protected]>: > > > > > > > > > I've been putting off starting a discussion about this > since > > I know some > > > > > people > > > > > are otherwise occupied, but it would be useful for it to > at > > least be in > > > > the > > > > > back of someones mind. I haven't spent a huge amount of > time > > thinking > > > > about > > > > > this recently, but I see two possible ways to handle it. > > > > > > > > > > 1. Translation is reworked so that it can be delayed > like memory > > > > transations. > > > > > In > > > > > atomic mode it could be blocking and immediate, and in > > timing mode the > > > > CPU > > > > > would > > > > > get a call back. This isn't ideal because it would require > > changes to the > > > > CPU > > > > > models which would potentially cause performance overhead > > for the other > > > > ISAs, > > > > > potentially break ARM (more?), and would be painful to add > > to O3 in the > > > > long > > > > > term. It's the most realistic, though, in terms of > mimicking > > actual CPUs. > > > > > > > > > > 2. Make the TLB miss fault invoke whichever other faults > may > > come up > > > > inside > > > > > it's > > > > > own invoke method. This would be comparatively easy, but > > would be > > > > inaccurate > > > > > as > > > > > far as performance. It also goes behind the CPU's back as > > far as who is > > > > in > > > > > control of faults/exceptions, etc., and could cause > problems > > with generic > > > > > statistics for instance. I don't know if such statistics > exist. > > > > > > > > > > Gabe > > > > > > > > > > _______________________________________________ > > > > > m5-dev mailing list > > > > > [email protected] <mailto:[email protected]> > > > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > m5-dev mailing list > > > > [email protected] <mailto:[email protected]> > > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > > > > > > > > > > -- > > > ---------- > > > Korey L Sewell > > > Graduate Student - PhD Candidate > > > Computer Science & Engineering > > > University of Michigan > > > > > > > > > > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > > > > -- > > ---------- > > Korey L Sewell > > Graduate Student - PhD Candidate > > Computer Science & Engineering > > University of Michigan > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > > -- > ---------- > Korey L Sewell > Graduate Student - PhD Candidate > Computer Science & Engineering > University of Michigan > _______________________________________________ > 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
