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
