> On 2011-03-31 16:15:29, Brad Beckmann wrote: > > This is more of a question, then a suggestion. Is there a way to use > > allocateVoid() a wrapper around allocate() rather than have to duplicate > > code? What happens if you cast the return pointer to void? Does that > > suppresss the error? Maybe there is a way to set some attribute on the > > variable that the compiler can understand. I have no idea if that is > > actually possible and if any solution would be portable across compiler > > generations. I'm just curious if there was some way to avoid the code > > duplication. > > Lisa Hsu wrote: > Brad, I agree it's kind of ugly and I've never been a fan of code > duplication. (Which reminds me - why do we need two copies of lookup(), one > const and one not in CacheMemory?) I'll try the void * return suggestion, > though I wouldn't hold my breath. I'm open to other suggestions as well, if > anyone has any. I didn't get too creative here.
Ok, I think I must have been brain farting. This patch was the least of my worries, I was more concerned about the ruby-local one, so clearly I didn't even spend an iota of time thinking about this. I've wrapped allocate() appropriately with no duplication and it works. Will check in that version. Must be quitting time :). - Lisa ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/#review1077 ----------------------------------------------------------- On 2011-03-31 12:21:22, Lisa Hsu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/629/ > ----------------------------------------------------------- > > (Updated 2011-03-31 12:21:22) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > CacheMemory: add allocateVoid() that is == allocate() but no return value. > This function duplicates the functionality of allocate() exactly, except that > it does not return > a return value. In protocols where you just want to allocate a block > but do not want that block to be your implicitly passed cache_entry, use this > function. > Otherwise, SLICC will complain if you do not consume the pointer returned by > allocate(), > and if you do a dummy assignment Entry foo := cache.allocate(address), the C++ > compiler will complain of an unused variable. This is kind of a hack to get > around > those issues, but suggestions welcome. > > > Diffs > ----- > > src/mem/protocol/RubySlicc_Types.sm d8587c913ccf > src/mem/ruby/system/CacheMemory.hh d8587c913ccf > src/mem/ruby/system/CacheMemory.cc d8587c913ccf > > Diff: http://reviews.m5sim.org/r/629/diff > > > Testing > ------- > > > Thanks, > > Lisa > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
