> On April 6, 2016, 9:47 p.m., Andreas Hansson wrote: > > Is this fixing a problem? Functional? Performance?
This is to make this class' ENTRY conform with the changes to the other ENTRY types in the rest of the Ruby system. The ENTRY types were made into pointers because of cases where assignments were happening and then it was trying to copy uninitialized DataBlks into other uninitialized DataBlks. There's an assertion in DataBlk that prevents this from happening. With the initialization I added for DataBlocks and WriteMasks, the initialization happens after the object is constructed anytime (hopefully everytime) a DataBlk gets constructed in Ruby. So, it might not be necessary for these ENTRY objects to be pointers anymore, but it seems daunting to go back and make those changes and then find out that they were actually necessary because of 'X'. Right now, it works that the entries are accessed as pointer types. - Brandon ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3429/#review8154 ----------------------------------------------------------- On April 4, 2016, 11:42 p.m., Brandon Potter wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3429/ > ----------------------------------------------------------- > > (Updated April 4, 2016, 11:42 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11431:88018e899f82 > --------------------------- > ruby: PerfectCache changes so that we can create with new > > > Diffs > ----- > > src/mem/ruby/structures/PerfectCacheMemory.hh > cfad34a15729e1d5e096245f5a80ded6e2c379ca > > Diff: http://reviews.gem5.org/r/3429/diff/ > > > Testing > ------- > > > Thanks, > > Brandon Potter > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
