If there isnt anything in mem, then you know that that particular pointer *isn't* explicitly used in the cache hierarchy.
But for this particular case, did you notice these lines in your search: src/cpu/o3/lsq_unit.hh:719: data_pkt->dataStatic(load_inst->memData); src/cpu/o3/lsq_unit.hh:737: fst_data_pkt->dataStatic(load_inst->memData); ... Seems like a packet is setting it's data to that memData pointer. I think if you look into the code, you'll find that there are a bunch of packet functions that operate on data in the /mem/ directory. The pointer to the data has to be set through something (in this case dataStatic). Somewhere in the LSQ there is probably a sendTiming call that uses that packet. The memory system will write that data (in the case of a load) and return it to the LSQ. And then the LSQ will probably get a recvTiming and eventually operate on the data. All of the basics (recvTiming/sendTiming) of the memory system are located on the gem5 website in the tutorial slides. Another good way to find code is place an assert(0) or breakpoint at a line of code, run it through GDB and then do a backtrace once that assert/breakpoint is hit. This wont catch situations where there is time between events but it's a good trick to know. On Fri, Dec 30, 2011 at 9:30 AM, Mahmood Naderan <[email protected]>wrote: > no such pattern in mem/ or mem/cache/ > > mahmood@mpc:gem5$ grep -rn "memData" src/* > src/arch/arm/isa/templates/mem.isa:81: uint64_t memData = 0; > src/arch/arm/isa/templates/mem.isa:91: &memData); > src/arch/arm/isa/templates/mem.isa:117: uint64_t memData = 0; > src/arch/arm/isa/templates/mem.isa:127: &memData); > src/arch/arm/isa/templates/mem.isa:151: uint64_t memData = Mem; > src/arch/arm/isa/insts/swap.isa:86: 'Dest = > cSwap((uint32_t)memData, ((CPSR)Cpsr).e);', > src/arch/arm/isa/insts/swap.isa:94: 'Dest_ub = > cSwap((uint8_t)memData, ((CPSR)Cpsr).e);', > src/cpu/base_dyn_inst_impl.hh:106: memData = NULL; > src/cpu/base_dyn_inst_impl.hh:165: if (memData) { > src/cpu/base_dyn_inst_impl.hh:166: delete [] memData; > src/cpu/inorder/inorder_dyn_inst.cc:60: thread(state), > fault(NoFault), memData(NULL), loadData(0), > src/cpu/inorder/inorder_dyn_inst.hh:188: uint8_t *memData; > src/cpu/ozone/lw_lsq.hh:566: assert(!inst->memData); > src/cpu/ozone/lw_lsq.hh:567: inst->memData = new uint8_t[64]; > src/cpu/ozone/lw_lsq.hh:569: memcpy(inst->memData, &data, > req->getSize()); > src/cpu/ozone/lw_lsq.hh:574: *(inst->memData)); > src/cpu/ozone/lw_lsq.hh:577: > data_pkt->dataStatic(inst->memData); > src/cpu/ozone/lw_lsq.hh:629: assert(!inst->memData); > src/cpu/ozone/lw_lsq.hh:630: inst->memData = new uint8_t[64]; > src/cpu/ozone/lw_lsq.hh:642: data_pkt->dataStatic(inst->memData); > src/cpu/ozone/lw_lsq_impl.hh:585: assert(!inst->memData); > src/cpu/ozone/lw_lsq_impl.hh:586: inst->memData = new uint8_t[64]; > src/cpu/ozone/lw_lsq_impl.hh:587: memcpy(inst->memData, > (uint8_t *)&(*sq_it).data, > src/cpu/ozone/lw_lsq_impl.hh:594: > data_pkt->dataStatic(inst->memData); > src/cpu/ozone/lw_lsq_impl.hh:605: req->getPaddr(), > *(inst->memData), > src/cpu/o3/lsq_unit_impl.hh:837: assert(!inst->memData); > src/cpu/o3/lsq_unit_impl.hh:838: inst->memData = new uint8_t[64]; > src/cpu/o3/lsq_unit_impl.hh:840: memcpy(inst->memData, > storeQueue[storeWBIdx].data, req->getSize()); > src/cpu/o3/lsq_unit_impl.hh:857: > data_pkt->dataStatic(inst->memData); > src/cpu/o3/lsq_unit_impl.hh:864: > data_pkt->dataStatic(inst->memData); > src/cpu/o3/lsq_unit_impl.hh:865: > snd_data_pkt->dataStatic(inst->memData + sreqLow->getSize()); > src/cpu/o3/lsq_unit_impl.hh:881: req->getPaddr(), > (int)*(inst->memData), > src/cpu/o3/lsq_unit.hh:570: load_inst->memData = new uint8_t[64]; > src/cpu/o3/lsq_unit.hh:571: data_pkt->dataStatic(load_inst->memData); > src/cpu/o3/lsq_unit.hh:633: assert(!load_inst->memData); > src/cpu/o3/lsq_unit.hh:634: load_inst->memData = new uint8_t[64]; > src/cpu/o3/lsq_unit.hh:642: > data_pkt->dataStatic(load_inst->memData); > src/cpu/o3/lsq_unit.hh:651: > fst_data_pkt->dataStatic(load_inst->memData); > src/cpu/o3/lsq_unit.hh:652: > snd_data_pkt->dataStatic(load_inst->memData + sreqLow->getSize()); > src/cpu/o3/lsq_unit.hh:712: assert(!load_inst->memData); > src/cpu/o3/lsq_unit.hh:713: load_inst->memData = new > uint8_t[64]; > src/cpu/o3/lsq_unit.hh:715: memcpy(load_inst->memData, > src/cpu/o3/lsq_unit.hh:724: > data_pkt->dataStatic(load_inst->memData); > src/cpu/o3/lsq_unit.hh:795: assert(!load_inst->memData); > src/cpu/o3/lsq_unit.hh:796: load_inst->memData = new uint8_t[64]; > src/cpu/o3/lsq_unit.hh:809: > data_pkt->dataStatic(load_inst->memData); > src/cpu/o3/lsq_unit.hh:827: > fst_data_pkt->dataStatic(load_inst->memData); > src/cpu/o3/lsq_unit.hh:828: > snd_data_pkt->dataStatic(load_inst->memData + sreqLow->getSize()); > src/cpu/checker/cpu_impl.hh:106: unverifiedMemData = inst->memData; > src/cpu/base_dyn_inst.hh:235: uint8_t *memData; > src/mem/ruby/profiler/MemCntrlProfiler.hh:77: uint64 m_memDataBusBusy; > src/mem/ruby/profiler/MemCntrlProfiler.cc:98: << > m_memDataBusBusy << endl; > src/mem/ruby/profiler/MemCntrlProfiler.cc:116: m_memDataBusBusy = 0; > src/mem/ruby/profiler/MemCntrlProfiler.cc:160: m_memDataBusBusy++; > > > On 12/30/11, Korey Sewell <[email protected]> wrote: > > Mahmood, > > do you use "grep"? It is a really powerful tool for finding a string in a > > set of files. In your case, I would try: > > grep -rn "memData" src/* > > > > That should list all the files that contain the memData string. > > > > Also, lots of people like to use a tool called CScope as wel. > > > > On Fri, Dec 30, 2011 at 8:37 AM, Mahmood Naderan > > <[email protected]>wrote: > > > >> ok but I can not find that in cache_impl.hh > >> > >> On 12/29/11, Nilay Vaish <[email protected]> wrote: > >> > On Thu, 29 Dec 2011, Mahmood Naderan wrote: > >> > > >> >> But I can not see that the read data is written to > load_inst->memData. > >> >> > >> >> On 12/29/11, Nilay Vaish <[email protected]> wrote: > >> >>> On Thu, 29 Dec 2011, Mahmood Naderan wrote: > >> >>> > >> >>>> Hi, > >> >>>> What is the purpose of this statment > >> >>>> > >> >>>> load_inst->memData = new uint8_t[64]; > >> >>>> > >> >>>> I see this in lsq_unit.hh and have no idea what does it do. > >> >>>> Any suggestion? > >> >>>> > >> >>> > >> >>> It seems that the data that would be read from the cache / memory > >> >>> would > >> >>> be > >> >>> stored in the space being allocated. > >> >>> > >> > > >> > You may note that the packet that is sent to the caches uses memData > as > >> > the pointer for storing the data. The actual write will occur in the > >> files > >> > related to the caches. > >> > > >> > -- > >> > Nilay > >> > _______________________________________________ > >> > gem5-users mailing list > >> > [email protected] > >> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > >> > > >> > >> > >> -- > >> -- > >> // Naderan *Mahmood; > >> _______________________________________________ > >> gem5-users mailing list > >> [email protected] > >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > >> > > > > > > > > -- > > - Korey > > > > > -- > -- > // Naderan *Mahmood; > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
