src/mem/protocol/MOESI_CMP_token-L2cache.sm (Diff revision 1)

Hello Joel,

Is it necessary to access the DirEntry by "getDirEntry(addr)" funciton always? Doesn't localDirectory[addr] work anymore?
I am trying to quantify the number of changes I need to make in slicc files if I accept this patch in lieu of http://reviews.gem5.org/r/2786/.

Show all issues

1. Joel Hestness June 15, 2015, 4:54 p.m. (June 15, 2015, 4:54 p.m.)

   I'm not sure if localDirectory[addr] works or not - you could try it. It probably fails, since SLICC appears to dereference pointers to AbstractEntry or AbstractCacheEntry subtypes (see src/mem/slicc/ast/MethodCallExprAST.py). Note that all existing uses of this CacheMemory or DirectoryMemory "operator[]" in gem5 require static casts to pointers (e.g. see src/mem/protocol/MESI_Three_Level-L0cache.sm). Since all uses currently require the static cast, we should probably do away with the automatic dereferencing so you could use the "operator[]" as though it returns a pointer.
   
   That said, I'd strongly recommend that you use a function like getDirEntry(addr) to be consistent with all the existing protocols in gem5 and to slim down the "number of changes" required for merges like this. It's a simple, one-time change and can mostly be scripted, so it really doesn't make sense to count the number of required changes. Can I recommend using sed? Something like the following should be simple:
   
   sed 's/localDirectory\[\(.*\)\]/DirEntry dir_entry := getDirEntry(\1);\ndir_entry/' -i filename.sm

Bump. AMD is planning to push patches today, but I'm not sure what was decided on the SLICC getPointer patch (http://reviews.gem5.org/r/2786/). Note that this fix to PerfectCacheMemory should make the getPointer patch unnecessary.

Ship It!