I'm a little confused by the question. From my recollection, the MESI directory protocol implements a full bit map vector. It is simply one implementation of a directory protocol. As you point out, there are other ways to implement a directory as well. For instance with the probe filter feature, the MOESI_hammer protocol implements a type of limited pointer directory. If a current protocol does not implement the directory scheme you're interested in, it should not be too hard to create your own. That is exactly the strength of SLICC/Ruby.
Brad > -----Original Message----- > From: [email protected] [mailto:gem5-dev- > [email protected]] On Behalf Of lyh > Sent: Monday, July 11, 2011 6:48 PM > To: gem5-dev > Subject: [gem5-dev] directory structures > > Hi All, > While implementing the cache coherence protocol for a cc-NUMA > system,the directory structure(e.g.directory entry) can be oganizated in > many ways, for example, full_map bit vector, limited pointers, or multilevel > directory the first level of which is a directory cache. > Theoretically, different directory structures have different impacts on system > performance. How does GEM5 implement directory structures? > e.g. > In file MESI_CMP_directory-dir.sm, the DirectoryEntry is a so-called > AbstractEntry, how can this implementation simulate the true situation? > // DirectoryEntry > structure(Entry, desc="...", interface="AbstractEntry") { > State DirectoryState, desc="Directory state"; > DataBlock DataBlk, desc="data for the block"; > NetDest Sharers, desc="Sharers for this block"; > NetDest Owner, desc="Owner of this block"; > } > > Sincerely > Lyh > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
