[代码阅读]gem5 classic cache初步(2)

下面的分析主要集中classic cache有关的文件:

Cache.cc, cache.hh, cache_impl.hh,以及tag中的lru.cc,lru.hh等文件。

 

Lru.cc中的内容不复杂,我们先来分析,主要完成的功能是:

insertBlock, findVictim等相关容易掌握的函数,这里不再作深入探讨;

 

主要的问题在于cache.hh, cache.cc以及cache_impl.hh等部分,其中的cache_impl.hh部分是实现cache具体操作的主要部分,其中只有功能模块的定义,没有关于调用过程的信息,为了把握其中的相关信息,我们开启其中的debug功能,生成相关的trace:

 

     0: system.cpu0.icache: ReadReq (ifetch) 1cb60 miss

  1000: system.l2: ReadReq (ifetch) 1cb40 miss

 41000: system.l2: Handling response to 1cb40

 41000: system.l2: Block for addr 1cb40 being updated in Cache

 41000: system.l2: Block addr 1cb40 moving from state 0 to 7

 52000: system.cpu0.icache: Handling response to 1cb40

 52000: system.cpu0.icache: Block for addr 1cb40 being updated in Cache

 52000: system.cpu0.icache: Block addr 1cb40 moving from state 0 to 7

 54000: system.cpu0.icache: ReadReq (ifetch) 1cb64 hit

 55000: system.cpu0.icache: ReadReq (ifetch) 1cb64 hit

 

根据上述的部分trace内容,我们再回到cache_impl.hh中的源代码,知道处理流程与代码中模块的对应关系,但是上面的trace内容少了些,因此我们打算在源代码中再增加一些DPRINTF语句来便于更好的追踪,经过自己增加额外的DPRINTF语句后,我们分析得出cache模块操作的两个起点在于如下:

 

1.      面向cpu;cpu_side_port:

CpuSidePort::recvTiming(…){

myCache->timingAccess(pkt);

}                              

 

2.      面向mem:

MemSidePort::recvTiming(){

myCache->handleResponse(pkt);

}

上述的两个端口就决定了我们的分析切入点,那接下来要分析的事情就变得很简单了:从这两个起点入手,一步步地跟踪分析即可。另外还需要考虑的就是缓存同步问题,相应的分析入口就在MemSidePort::recvTiming(){}中的myCache->snooptiming(pkt)。

 


你可能感兴趣的:(cache,源代码,缓存,GEM5)