> On July 19, 2012, 10:25 a.m., Steve Reinhardt wrote: > > src/arch/x86/interrupts.cc, line 635 > > <http://reviews.gem5.org/r/1303/diff/3/?file=28015#file28015line635> > > > > Is this really necessary? As you say in the other comment, this should > > all be done in python eventually anyway...
I am just making it equal to the behaviour it had previously. There are plenty places where the code checks if clock == 0, and I don't know: 1) When that would happen, 2) what the impact is. At this point I did not want to change any behaviour. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1303/#review3099 ----------------------------------------------------------- On July 19, 2012, 5:46 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1303/ > ----------------------------------------------------------- > > (Updated July 19, 2012, 5:46 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9127:f00508d2c790 > --------------------------- > Clock: Move the clock and related functions to ClockedObject > > This patch moves the clock of the CPU, bus, and numerous devices to > the new class ClockedObject, that sits in between the SimObject and > MemObject in the class hierarchy. Although there are currently a fair > amount of MemObjects that do not make use of the clock, they > potentially should do so, e.g. the caches should at some point have > the same clock as the CPU, potentially with a 1:n ratio. This patch > does not introduce any new clock objects or object hierarchies > (clusters, clock domains etc), but is still a step in the direction of > having a more structured approach clock domains. > > The most contentious part of this patch is the serialisation of clocks > that some of the modules (but not all) did previously. This > serialisation should not be needed as the clock is set through the > parameters even when restoring from the checkpoint. In other words, > the state is "stored" in the Python code that creates the modules. > > The nextCycle methods are also simplified and the clock phase > parameter of the CPU is removed (this could be part of a clock object > once they are introduced). > > > Diffs > ----- > > src/arch/x86/interrupts.hh 48eeef8a0997 > src/arch/x86/interrupts.cc 48eeef8a0997 > src/arch/x86/utility.cc 48eeef8a0997 > src/cpu/BaseCPU.py 48eeef8a0997 > src/cpu/base.hh 48eeef8a0997 > src/cpu/base.cc 48eeef8a0997 > src/cpu/testers/memtest/memtest.hh 48eeef8a0997 > src/cpu/testers/networktest/networktest.hh 48eeef8a0997 > src/dev/CopyEngine.py 48eeef8a0997 > src/dev/Ethernet.py 48eeef8a0997 > src/dev/arm/RealView.py 48eeef8a0997 > src/dev/arm/pl111.hh 48eeef8a0997 > src/dev/arm/pl111.cc 48eeef8a0997 > src/dev/arm/timer_cpulocal.cc 48eeef8a0997 > src/dev/i8254xGBe.hh 48eeef8a0997 > src/dev/i8254xGBe.cc 48eeef8a0997 > src/dev/ns_gige.hh 48eeef8a0997 > src/dev/ns_gige.cc 48eeef8a0997 > src/dev/sinic.hh 48eeef8a0997 > src/dev/sinic.cc 48eeef8a0997 > src/mem/Bus.py 48eeef8a0997 > src/mem/MemObject.py 48eeef8a0997 > src/mem/bus.hh 48eeef8a0997 > src/mem/bus.cc 48eeef8a0997 > src/mem/mem_object.hh 48eeef8a0997 > src/mem/mem_object.cc 48eeef8a0997 > src/sim/ClockedObject.py PRE-CREATION > src/sim/SConscript 48eeef8a0997 > src/sim/clocked_object.hh PRE-CREATION > > Diff: http://reviews.gem5.org/r/1303/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
