See http://gem5.org/Simulation_Scripts_Explained#Relative_references for the official explanation.
Parent.any just looks for a type match and not a parameter name match. It's generally used where you're looking to find an "enclosing" object further up the hierarchy (like a System object) and not just inheriting a parameter setting. That said, we probably do abuse it some, in that there are likely places where we could use a "normal" Parent proxy and not Parent.any and it would be clearer. Steve On Wed, Feb 13, 2013 at 10:39 AM, Nilay Vaish <[email protected]> wrote: > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1667/ > > On February 11th, 2013, 10:25 a.m., *Ali Saidi* wrote: > > > src/python/m5/SimObject.py<http://reviews.gem5.org/r/1667/diff/2/?file=33931#file33931line604> > (Diff > revision 2) > > def cxx_param_decl(cls, code): > > 596 > > cxx_header = "sim/sim_object.hh" > > 597 > > eventq_index = Param.UInt32(Parent.any, "Event Queue Index") > > 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? > > On February 11th, 2013, 11:21 a.m., *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... > > 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. > > > - Nilay > > On February 10th, 2013, 1:44 p.m., Nilay Vaish wrote: > Review request for Default. > By Nilay Vaish. > > *Updated Feb. 10, 2013, 1:44 p.m.* > 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) > > View Diff <http://reviews.gem5.org/r/1667/diff/> > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
