> port_names = self._ports.keys()
> port_names.sort()
> for port_name in port_names:
> port = self._port_refs.get(port_name, None)
> if port != None:
> setattr(cc_params, port_name, port)
>
> I have no idea why we do this. It would be interesting to take this code
> out and see if anything breaks.
I don't recall writing the code, but hg says that I did! :)
Looking at the code (and the generated code), I believe that the end
result of the setattr is effectively a nop. Basically, what's
happening is that swig generates native C++ code for accessing all of
the functions and variables, but it does not generate an actual
extension type (a python class written in C/C++ instead of python).
Swig instead generates a regular python class and a bunch of wrapper
functions that call into the accessor functions (like this):
class SimObject(object):
def init(self): return _param_SimObject.SimObject_init(self)
The result is that there is a real python class and we're just adding
a python attribute to that python class that never makes it into C++.
If you were to add a C++ param called port_name to swig, then it
should "just work". Grep seems to say to me that nothing will break
if it gets removed, but I can't promise that. My best guess is that I
added that so that I could get some context when using pdb.
Make any sense?
Nate
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
