How to find the definition of some member variables of class System()?

[cnjsdfcy]

Hi,

As the title said, I searched around the code repo but can't find the definition of many variables of class System().
For example, where is the system.cpu defined?

Thanks,
Jason

[BobbyRBruce]

cpu isn't a SimObject parameter of a System like mem_ranges or cache_line_size (you can find the declaration of those src/sim/System.py). cpu, which you've likely seen in gem5 scripts, is just a variable which we use to store a Simobject in the simulation design. You can call it anything you want. In this instance cpu is just the name of the variable which holds the CPU SimObject.

To explain things in a little more details: In gem5 everything starts from a Root object, which typically contains a System SimObject. The System SimObject contains parameters like mem_ranges but can also contain other SimObects. These are added to the system with in the config script with statements like system.cpu = X86TimingSimpleCPU(). These SimObjects added to the System SimObject obey the same rules as the System SimObject. They have their special SimObject parameters which dictate the behavior of the object, but they can also contain other SimObjects.

As each SimObject can contain N SimObject, a gem5 simulation can be seen as a tree of SimObjects.

system = System()
system.cache_line_size = 32
system.my_cpu = X86TimingSimpleCPU()
system.my_other_cpu = X86KVMCPU()
system.my_other_cpu.my_object = MySimObject()

In the above design we have a System SimObject (system) which contains two child objects: my_cpu and my_other_cpu of types X86TimingSimpleCPU and X86KVMCPU. my_other_cpu also has a child SimObject, my_object, an instance of MySimObject. The system SimObject Parameter cache_line_size is set to 32.

[cnjsdfcy]

Hi Bruce,

Thanks a lot for your quick reply.
I did some digging and found that, all these "variables" that are not defined as params in xxx.py nor member variable in xxx.hh, are added as attributes by these code segment in SimObject.py, to form a tree as you said.

Am I understanding correctly?

Thanks,
Jason

[BobbyRBruce]

I think you are heading in the right direction. I can't say for sure I know exactly what that code does but what you're saying seems correct.

The big thing you need to know about "SimObject.py" and understand why things in gem5 are a bit weird is that we override __setattr__. This means that when you say simobject.x = "bla", our overritten __setattr__ function is called. Instead of just setting the value of simobject's attribute x to "bla" like you'd expect, our function does some processing. In our overridden function the attribute and value to be assigned are processed and what happens to them differs depending what they are. Here you can see the difference in how a param and a SimObject are treated. If the x in our example is a parameter, cls._param.get(x) will return param and cls._set_param will be called. If not, the value ("bla" in our example) will be checked to see if it's a SimObject. If it is, it's added as a child via cls._add_cls_child. There's also code for handling ports, special keywords, and some other things.

If you actually want to just assign a value to a SimObject attribute in a "normal" way you can use the setattr function (setattr(simobject, x, "bla") i think) but i've only ever seen this in low-level code gem5, so i wouldn't do this in your work. There is one small exception to all this which is useful: you can do normal assignment (with =) if you start your attribute with a leading underscore. So simobject._x = "bla" works as you'd expect. In this case simobject will have an assignment _x of value "bla". So if you want a "traditional python" assignment, use underscores. If you don't you'll liekly get an error complaining x is not a known attribute of simobject or that the value isn't a SimObject or Port.

[cnjsdfcy]

The devil is in the detail... quite complicated, I will dig more later.

BTW, during this code-digging, I have two struggles when reading & debugging gem5 source code using vscode:

1. The python intelligence is not working well. Though I looked around and found your PR, but the jump-to-definition still can't go to the original python definitions, since most python modules are imported using "addToPath()", which is not recognized by pylance, and I can only use grep.
2. The mixed-c++-python debugger is not working well. For many projects, internal C++ codes is wrapped and started by python codes, in this situation I can lanuch python debugger of vscode and then attach the C++ gdb to this process, then the mixed-debugging can single-step in both python and C++ world. However, Gem5 works in this pattern: C++（main.cc）-> python (main.py) -> python (xxx_config.py) -> C++, which makes the mixed-debugging not working.

So, I am wondering that do you have any ideas or any plans to alleviate above two struggles? For example:

1. Do explicitly import?
2. Start gem5 from main.py ?

[BobbyRBruce]

To address your big points:

1. The python inteli-sense solution I came up with was only a partial solution. The big issue it solved (in most cases) was stopping Pylance complaining about imports not existing. However, I've yet to find an easy way to get everything 100%. It's not just addToPath, there's a lot of gem5 which is very non-standard so it's hard to use these kind of Python tools that run on the assumption of a typical import system. For starters, we compile our Python code into the gem5 binary and because we do it that way we don't properly import things in source. SimObjects, for example, aren't complete until they are compliled. Python-level references, when followed, reach a dead end because they are linked up via the compilation process. from m5.objects import X86CPU doesn't allow you to go and see the X86CPU code becausde that only exists in the binary after compilation.

2. The CPP/Python split has its problems but there is a concept there. If you squint at gem5 it uses CPP and Python for two different things. We think of gem5 as having a Python outer-shell in which users use to create or extend components, configure their parameters, define their interactions, and ultimately setup simulations and run experiments with a matural, easy to use scripting language. Beyond the Python we have a CPP core that is designed for efficiency and simulating what is defined in at the Python. It is a high-performance CPP engine thats behavior is defined by what the user-friendlyPython interface dictates. However, there are a lot of parts of gem5 where the coupling between CPP and Python is too tight and this breaks down. SimObjects, ideally, would exist purely in Python thus allowing users to add, modify, or remove them freely without any recompilation. However, at present, creating requires creation of both CPP and Python code.

There's little in the pipeline which will massively solve either of these problems but there's a lot of overlap on the solution to both. They both require refactoring of how the SimObjects and other Python code sits atop and interacts with the wider CPP code. I've had the goal of having gem5 move more towards being a Python module which is imported like any other with the script executed as ordinary python codes. I'm thinking pip install gem5 and import gem5 then gem5.run(my_simulation). However, tight now, even if we could do that, it'd go under unutilized. The only way for people to develop new SimObjects or do things like add a new ISA instructions is to extend or modify the CPP code then recompile the binary. We can't just distribute gem5 via pip because being able to recompile and replace the binary is a must.

[cnjsdfcy]

Well, hope Gem5 can become more friendly and easier to understand for newcomers.
And again, thanks a lot for your patient explanations.