Eventually, the InOrderCPU's "DynInst" object will be merged with the base_dyn_inst.hh.
If memory serves correct, in the original implementation I did not want to deal with the templated-definition and derivation of the base_dyn_inst.hh (at least upfront) and so DynInst specific to InOrderCPU was used. On Thu, Jul 22, 2010 at 9:35 AM, Steve Reinhardt <ste...@gmail.com> wrote: > I think you stated it pretty accurately, Gabe. It looks like the > base_dyn_inst.hh file is only used in o3, ozone, and checker, and of > those only o3 is really being used right now. > > Steve > > On Thu, Jul 22, 2010 at 12:56 AM, Gabe Black <gbl...@eecs.umich.edu> > wrote: > > The dynamic instruction object is really just the dynamic information > > associated with an instruction, as apposed to the static instruction > > object that gets reused. Strictly speaking there's no guarantee that an > > arbitrary dynamic instruction will always use timing mode, but all the > > CPU models we have that are complicated enough to need dynamic > > instructions use timing mode exclusively as far as I know. O3's dynamic > > instruction object for sure uses only timing mode, so yes, in that case, > > the data parameter is just so the function signatures are the same in > > the read case. initiateAcc is how memory instructions access memory in > > timing mode, so again, in this case and in most practical cases a > > dynamic instruction object's read function would be called from > > initiateAcc and not execute. If you're only worried about O3 (ie. it's > > in the o3 directory) you don't need to keep track of data. If it's the > > base dynamic instruction object it's a little less clear since > > -practically- speaking it will probably only be used with timing mode, > > but there isn't any reason I can think of that has to be true in all > > cases. I think the base dynamic instruction object may actually not be > > very far separated from O3 so it may already assume timing mode in other > > places. > > > > Please someone speak up if I'm wildly mischaracterizing how this is > > supposed to work. I've worked a lot with O3's innards, but I think all > > the design work was done before I was associated with M5. > > > > Gabe > > > > Min Kyu Jeong wrote: > >> so base_dyn_inst is always used timing memory - I assumed so but just > >> wanted to confirm this to make sure that read function, > >> > >> BaseDynInst<Impl>::read(Addr addr, T &data, unsigned flags) > >> > >> 'data' argument isn't really doing anything but being a placeholder > >> for func sig matching in xc interface. -- is this correct? > >> > >> BaseDynInst::read() will be called only in initiateAcc(), not in > >> execute() function. When the initiateAcc()/completeAcc() pair is used, > >> pkt->get() is used in completeAcc() to read the data. > >> > >> I am moving some code from read() to finishTranslation() and it looks > >> like 'data' variable doesn't need to be passed. > >> > >> Thanks, > >> > >> Min > >> > >> On Thu, Jul 15, 2010 at 10:01 AM, Steve Reinhardt <ste...@gmail.com > >> <mailto:ste...@gmail.com>> wrote: > >> > >> On Wed, Jul 14, 2010 at 8:35 AM, Min Kyu Jeong <mkje...@gmail.com > >> <mailto:mkje...@gmail.com>> wrote: > >> > b) memory is atomic (is it a possible combination? dyn_inst + > >> atomic?) - > >> > x86 doesn't seem to have code for this case - > >> Walker::recvAtomic() does > >> > nothing. > >> > >> I don't believe that O3+atomic mode works. Practically speaking it > >> doesn't make any sense. > >> > >> Steve > >> _______________________________________________ > >> m5-dev mailing list > >> m5-dev@m5sim.org <mailto: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 > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > -- - Korey
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
