----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/#review1077 -----------------------------------------------------------
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. - Brad 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
