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]> 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]>: > > > 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]> 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]: > > > > > > > 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] > > > > 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 > -- ---------- 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
