I haven't looked at Korey's code in that much detail yet, but in general the execution-phase operations have had this kind of structure:
1. CPU model calls StaticInst method with pointer to execution context (e.g., DynInst) 2. StaticInst method does what it needs to do, calling back into the execution context (and implicitly into the CPU model) in the process 3. Method returns fault code and not much else Unless there are compelling reasons why that doesn't work, I'd like to keep that high-level model. Having the CPU model call into the StaticInst to read out bits of state (like flags and access size) and then using that info to build a request is a different model. However it's also true (I think) that the ISA descriptions don't see Request or Packet structures at all either; they just talk to the CPU model in terms of read() and write() (and some other possibly unused functions like setEA()). I think that's also a nice level of separation between the ISA descriptions and the implementation details that I'd like to keep. I'll have to look at Korey's code more closely; the isolated patches haven't really given me a good picture of what's really going on. Steve On Fri, Apr 10, 2009 at 6:04 PM, Gabe Black <gbl...@eecs.umich.edu> wrote: > It could work like this: > > 1. Instruction calls read with flags. > 2. Build a request with the flags and the right size, translate it, and > stick it in the dynInst. > 3. Actually do the read with the translated request. > > Or if you want to break it up more: > > 1. Instruction calls read with flags. > 2. Build a request with the flags and the right size, and stick it in > the dynInst. > 3. Pull out the request, translate it, and stick it back in the dynInst. > 4. Actually do the read with the translated request. > > Korey Sewell wrote: > > Well, > > I dont think pretending to do the access would work for the TLB > > necessarily. > > > > I can see that the actual size of the access is irrelevant for the TLB > > translation (right?). Maybe we can work around that. > > > > But what about the type of access? That comes from the memory access > > flags and the only object that knows those flags is the actual > > instruction object. So that seems to be the big problem there. > > > > On Fri, Apr 10, 2009 at 5:23 PM, nathan binkert <n...@binkert.org > > <mailto:n...@binkert.org>> wrote: > > > > > That's a legitimate problem. Would it work to pretend to do the > > access > > > and save the request object for later? > > > > I think we should strive to do this. > > > > Nate > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org <mailto:m5-dev@m5sim.org> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > > > > -- > > ---------- > > Korey L Sewell > > Graduate Student - PhD Candidate > > Computer Science & Engineering > > University of Michigan > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
