> On July 13, 2015, 8:10 p.m., Nilay Vaish wrote: > > I am as such fine with the patch. I myself have faced similar problem with > > the naming of > > the header file. > > > > Can you expand on your eventual aim? I am trying to understand the need > > for spreading the > > ruby system pointer around. Please note that classic memory system has no > > notion of a memory > > system pointer. I think ruby should also try to avoid having a memory > > system pointer in each > > object.
The main problem with Ruby for having multiple instances is that there are static variables that end up being shared if there are multiple RubySystem objects. Currently, each time a Controller or DirectoryMemory object is instantiated it increments a static counter indicating how many copies of that object exist. The interconnection network uses this information extensively in order to iterate over members of the network and route packets. Effectively, each Controller has an ID in the range of 0 to the number of Controllers. One major problem is that the IDs are repeated for each RubySystem. So, with two RubySystems there are two controllers with ID 0, 1, etc. which leads to incorrect routing on the interconnection network (asserts in network/Topology.cc catch this, but if those are disabled then that is the result). What my future patches do is relocate these static variables to be members of the RubySystem object. Then, whenever an object needs to know this information, it accesses it through a pointer to the RubySystem that it is a part of. This disambiguates between controllers and eliminates the routing conflicts. In particular, the NetDest object frequently needs to know this information, but since it is not a SimObject, it must be passed a pointer to the RubySystem, which means that any object that needs to create a NetDest object needs access to a RubySystem object. The alternative would have been to make each of the static variables into a vector of their previous values and instead pass around a RubySystemID to each object. However, this has all of the disadvantages of passing pointers with the added pains of keeping information scattered and hard to understand, and not being as extensible. Other than those two options, I don't see any other way to implement what we need without significantly refactoring the interconnection network. Since the RubySystem object already exists, it makes more sense to use it. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2965/#review6758 ----------------------------------------------------------- On July 13, 2015, 7 p.m., David Hashe wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2965/ > ----------------------------------------------------------- > > (Updated July 13, 2015, 7 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10923:8bdfe8dd9c2b > --------------------------- > rename System.{hh,cc} to RubySystem.{hh,cc} > > The eventual aim of this change is to pass RubySystem pointers through to > objects generated from the SLICC protocol code. > > Because some of these objects need to dereference their RubySystem pointers, > they need access to the System.hh header file. > > In src/mem/ruby/SConscript, the MakeInclude function creates single-line > header files in the build directory that do nothing except include the > corresponding header file from the source tree. > > However, SLICC also generates a list of header files from its symbol table, > and writes it to mem/protocol/Types.hh in the build directory. This code > assumes that the header file name is the same as the class name. > > The end result of this is the many of the generated slicc files try to > include RubySystem.hh, when the file they really need is System.hh. The path > of least resistence is just to rename System.hh to RubySystem.hh. > > > Diffs > ----- > > src/mem/ruby/system/RubySystem.cc PRE-CREATION > src/mem/slicc/symbols/StateMachine.py > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/System.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/System.hh 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/Sequencer.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/SConscript 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/RubySystem.py 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/CacheMemory.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/BankedArray.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/BankedArray.hh > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/DirectoryMemory.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/Prefetcher.hh > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/RubySystem.hh PRE-CREATION > src/mem/ruby/system/RubyPort.hh 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/DMASequencer.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/DMASequencer.hh > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/system/CacheRecorder.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/WireBuffer.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/TimerTable.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/RubyMemoryControl.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/RubyMemoryControl.hh > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/structures/Prefetcher.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/slicc/symbols/Type.py 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/slicc_interface/AbstractController.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/network/simple/Throttle.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/network/simple/Throttle.hh > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/network/simple/SimpleNetwork.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/network/Network.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/network/MessageBuffer.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/filters/NonCountingBloomFilter.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/filters/MultiGrainBloomFilter.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/filters/LSB_CountingBloomFilter.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/filters/BulkBloomFilter.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/filters/BlockBloomFilter.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/common/DataBlock.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/mem/ruby/common/Address.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/cpu/testers/rubytest/RubyTester.cc > 5ee72f4b293152dd0c75ab402a49696d6903e604 > src/cpu/testers/rubytest/Check.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 > > Diff: http://reviews.gem5.org/r/2965/diff/ > > > Testing > ------- > > > Thanks, > > David Hashe > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
