> On Feb. 11, 2013, 10:25 a.m., Ali Saidi wrote: > > src/python/m5/SimObject.py, line 604 > > <http://reviews.gem5.org/r/1667/diff/2/?file=33931#file33931line604> > > > > How does this work? I'm not saying it doesn't I just don't understand > > what the proxy is doing in this case? Looking for any object that is a > > UInt32? Do we want to have an specific EventQueueId object? > > Steve Reinhardt wrote: > Good catch, that should probably be Parent.eventq_index, not Parent.any. > We probably also need to explicitly set Root.eventq_index to 0 somewhere. As > far as how it works now, it's probably totally an accident... > > Nilay Vaish wrote: > I have changed the code as per the suggestion made. Can anyone explain > what Parent.any does? I used to think that some Python code probes the > parent of the object for the correct value that should be assigned to > variable that was assigned Parent.any in a params file.
Hi Nilay, Parent.any says traverse the object hierarchy and find me a parameter to that fits my type. In the case of Param.System(Parent.any) This is an easy way to get a pointer to a system object. In this case I suppose it went looking for an parent object that had a parameter that was a UInt32. It sorta worked because we don't have many parameters of type Uint32, but it could get the wrong value for sure. - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1667/#review4011 ----------------------------------------------------------- On Feb. 10, 2013, 1:44 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1667/ > ----------------------------------------------------------- > > (Updated Feb. 10, 2013, 1:44 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9497:484d33f78ef4 > --------------------------- > sim: simulate with multiple event queues > This patch extends the patch Steve posted on the reviewboard (846). The patch > updated with all the changes that have taken place over last 15 months. Code > has been added so as actually carry out a quantum-based parallel simulation. > > The patch was tested in two different configurations: > 1. ruby_network_test.py: in this simulation L1 cache controllers receive > requests from the cpu. The requests are replied to immediately without > any communication taking place with any other level. > 2. twosys-tsunami-simple-atomic: this configuration simulates a client-server > system which are connected by an ethernet link. > > We still lack the ability to communicate using message buffers or ports. But > other things like simulation start and end, synchronizing after every quantum > seem to be working. > > > Diffs > ----- > > src/cpu/base.cc ff4b1bde5f60 > src/dev/etherlink.cc ff4b1bde5f60 > src/python/m5/SimObject.py ff4b1bde5f60 > src/python/m5/event.py ff4b1bde5f60 > src/python/m5/main.py ff4b1bde5f60 > src/python/swig/core.i ff4b1bde5f60 > src/python/swig/event.i ff4b1bde5f60 > src/sim/SConscript ff4b1bde5f60 > src/sim/core.hh ff4b1bde5f60 > src/sim/debug.cc ff4b1bde5f60 > src/sim/eventq.hh ff4b1bde5f60 > src/sim/eventq.cc ff4b1bde5f60 > src/sim/eventq_impl.hh ff4b1bde5f60 > src/sim/global_event.hh PRE-CREATION > src/sim/global_event.cc PRE-CREATION > src/sim/serialize.cc ff4b1bde5f60 > src/sim/sim_events.hh ff4b1bde5f60 > src/sim/sim_events.cc ff4b1bde5f60 > src/sim/sim_exit.hh ff4b1bde5f60 > src/sim/sim_object.cc ff4b1bde5f60 > src/sim/simulate.hh ff4b1bde5f60 > src/sim/simulate.cc ff4b1bde5f60 > src/sim/stat_control.cc ff4b1bde5f60 > > Diff: http://reviews.gem5.org/r/1667/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
