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
