> On May 20, 2012, 7:57 a.m., Ali Saidi wrote: > > hmm.. do we want to do it this way, or fix the issue? It seems like there > > may be value in allowing the configuration to change before it's > > instantiated (e.g create a perfectly workable system with only l1s and the > > later on decide you want to wedge in an l2). > > > > > > Andreas Hansson wrote: > From my point of view what I propose is definitely the cleaner option, > and no doubt the common case. I would suggest starting out with this patch to > fix the "brokenness". > > If someone would like to construct a system the way you suggest, i.e. > partially undoing previous connections, we can extend the port functionality > (mostly the vector ports) to match the assumptions. > > Ali Saidi wrote: > It's just an idea that I've had. If you could do this then you could > imagine building a configuration by using decorators on a basic system. > Something like > > @o3_cpu > @l2caches > @l1caches > createBasicSystem() > >
It's a nice idea...but also requires quite some work beyond the port connectivity. Shall we save the more extensive changes for later and just firm up the checks for now? - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1206/#review2737 ----------------------------------------------------------- On May 18, 2012, 9:11 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1206/ > ----------------------------------------------------------- > > (Updated May 18, 2012, 9:11 a.m.) > > > Review request for Default. > > > Description > ------- > > Config: Exit with fatal if a port is already connected > > This patch turns the existing warning into a fatal, as there should > never be any cases where a (non-vector) port is assigned to and then > later connected to something else. If this behaviour is allowed, as it > used to be, there are cases where the wrong number of C++ ports are > created when instantiating objects with VectorPorts (obviously that > could be fixed, but the better approach is to simply not allow it). > > > Diffs > ----- > > src/python/m5/params.py 7100059f7bfd > > Diff: http://reviews.gem5.org/r/1206/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
