Hi,
As I expect to be needing to play around with Ports, I'm currently
trying to figure out how exactly setting and connecting Ports on the
Python side translates to the C++ side.
I know how regular parameters get hauled over to the C++ side; they use
the dynamically-generated XxxParams structs, which are then instantiated
and populated in Python. A call to create() is performed on the
XxxParams struct, resulting in the actual C++ object so that it can
configure itself using from that parameter struct.
I've figured out how Ports are assigned and their corresponding PortRefs
are connected using MetaSimObject's __setattr__ to check for ports and
all that jazz, and I've boiled things down to SimObject.getCCParams,
which is where the resulting XxxParams struct is actually instantiated
and its fields' values copied over from the corresponding ParamValue
instances.
Something similar seems to be happening for the ports (or at least their
references):
for port_name in port_names:
port = self._port_refs.get(port_name, None)
if port != None:
setattr(cc_params, port_name, port)
In other words, grab each registered port's reference by name, and
assign it to the C++ struct.
This is where I'm lost though. I know from looking at the generated
XxxParams structs in the build that only actual parameter fields are
included; the port fields appear to be left out. Then how does the
setattr(cc_params, port_name, port) make sense, or succeed at all? I've
added some hasattr calls before the setattr call to check whether
they're not secretly there somehow, and indeed they are not. After the
assignment they're there and can be retrieved at will though.
So one possibility I can think of is that the port attribute is assigned
only on the Python-side cc_params proxy object and not "forwarded" if
you will to the underlying C++ struct because it does not map to an
existing C++ field. I am not familiar enough with SWIG and any
Python/C++ proxy objects it has going on to know whether this is the
case though.
I also know that the Ports seem to be created on the C++ side; or at
least in e.g. Cache they are. I also know about the connectPorts call
that is exported to Python from C++ in pyobject.cc, and the
MemObject::getPort() method it uses. The Cache::getPort() implementation
basically seems to do a hardcoded check for Python's attribute names.
Ports are always connected after the corresponding C++ objects are
created (since Python's call to connectPorts in PortRef.ccConnect
requires them), so this seems to be where Python's wheels hit the C++
ground.
So, would it then be right to say that the whole Port and PortRef setup
on the Python side only serves to ultimately culminate in a call to
C++'s connectPorts() which will grab C++-created Ports by hardcoded
name? That would also render the bit of code above not only useless but
also highly confusing. Commenting it out certainly does not seem to
break anything.
Am I on the right track here or am I missing something?
Thanks,
-- Jeroen
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
