> On Feb. 22, 2012, 9:17 a.m., Steve Reinhardt wrote: > > src/mem/tport.cc, line 51 > > <http://reviews.gem5.org/r/1056/diff/1/?file=23553#file23553line51> > > > > Does having a constructor parameter with the same name as a member even > > work? I'm surprised if it does... > > Andreas Hansson wrote: > It works absolutely fine. Within this scope name refers to the parameter.
Interesting... learn something new every day. I'm not surprised that the parameter declaration shadows the member, but I am surprised that the compiler doesn't give you a warning about that (as it does if you have a local var that shadows a param). I'm also slightly surprised that "label(label)" works, since you've got the same name with two different bindings right there (though clearly the context is different so the compiler can distinguish them). I always assumed that the idiom of naming either the param or the member something slightly different like "_label" was to avoid such problems, so it's mildly surprising to see that no such problems exist. I guess I'd still like to see the param called "_label" just for consistency with all our other constructors. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1056/#review2181 ----------------------------------------------------------- On Feb. 22, 2012, 11:31 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1056/ > ----------------------------------------------------------- > > (Updated Feb. 22, 2012, 11:31 a.m.) > > > Review request for Default. > > > Description > ------- > > MEM: Simplify cache ports preparing for master/slave split > > This patch splits the two cache ports into a master (memory-side) and > slave (cpu-side) subclass of port with slightly different > functionality. For example, it is only the CPU-side port that blocks > incoming requests, and only the memory-side port that schedules send > events outside of what the transmit list dictates. > > This patch simplifies the two classes by relying further on > SimpleTimingPort and also generalises the latter to better accommodate > the changes (introducing trySendTiming and scheduleSend). The > memory-side cache port overrides sendDeferredPacket to be able to not > only send responses from the transmit list, but also send requests > based on the MSHRs. > > A follow on patch further simplifies the SimpleTimingPort and the > cache ports. > > > Diffs > ----- > > src/mem/cache/base.hh 2629f0b99e8d > src/mem/cache/base.cc 2629f0b99e8d > src/mem/cache/cache.hh 2629f0b99e8d > src/mem/cache/cache_impl.hh 2629f0b99e8d > src/mem/tport.hh 2629f0b99e8d > src/mem/tport.cc 2629f0b99e8d > > Diff: http://reviews.gem5.org/r/1056/diff/diff > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
