Hello, I'm always wondering what's the result of gem5 full system simulation, is only the functional result or some number. And I want to change the memory in the cpu and get the cpi as a result how can I do that Can I do it just with the se mode
-----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代 表 [email protected] 发送时间: 2011年12月31日 1:00 收件人: [email protected] 主题: gem5-users Digest, Vol 65, Issue 71 Send gem5-users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of gem5-users digest..." Today's Topics: 1. Re: Initializing memData for a load instruction (Mahmood Naderan) ---------------------------------------------------------------------- Message: 1 Date: Fri, 30 Dec 2011 19:58:14 +0330 From: Mahmood Naderan <[email protected]> To: gem5 users mailing list <[email protected]> Subject: Re: [gem5-users] Initializing memData for a load instruction Message-ID: <cada2p2ufi9jnlj2utmmstl2x4qnqtzu1ubwe2bx1uk7cukb...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 > And then the LSQ will probably get a recvTiming and > eventually operate on the data. Yes there is LSQ<Impl>::DcachePort::recvTiming(PacketPtr pkt) which calls completeDataAccess(pkt) In that function I see writeback and store operations. Still I am not able to figure out how LSQ unit operates on the received data from dcache. Is it true that in LSQ, write and store operations should be done? As far as I know, in LSQ unit, load instructions are dequeued and provide the memory locations needed by execution unit. -- // Naderan *Mahmood; On 12/30/11, Korey Sewell <[email protected]> wrote: > 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 End of gem5-users Digest, Vol 65, Issue 71 ****************************************** _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
