rename System.{hh,cc} to RubySystem.{hh,cc}

Information
Submitter:	David Hashe
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Blocks:	3113
Reviewers
Groups:	Default
People:

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.

Testing Done

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.

David Hashe July 13, 2015, 2:56 p.m. (July 13, 2015, 2:56 p.m.)

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.

Are they comments on this? We'd like to ship this soon.

Nilay Vaish Sept. 3, 2015, 1:51 p.m. (Sept. 3, 2015, 1:51 p.m.)
```
Has hg mv been used to move those two files?
```
Tony Gutierrez Sept. 3, 2015, 2:17 p.m. (Sept. 3, 2015, 2:17 p.m.)
```
We can do hg mv or hg rm/hg add. What is preferred?
```

I had been putting off this review since it touched so many files. I didn't realize it was so simple ;).

Any last comments? I plan to ship this before the EoD today.

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Status: Closed (submitted)