Ok, thanks for clarifying. I was just a little confused since the params
went on to live in the C++ world, and the ports seemed to follow the
same way (see the bit of code in my original post) but then got stopped
dead in their tracks in comparison.
On a side note, I was glad to see that the connectPorts call on the C++
side was delightfully straightforward. I was a little afraid of what I
might find messing around with C++-created ports, but it turns out to be
much less of a hassle I thought.
-- Jeroen
On Nov 19, 2010, at 11:35 AM, Jeroen DR wrote:
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.
Yes, that is correct. The ports aren't in the Params struct and python calls
the c++ connectPorts() call which calls getPort on each object to get the
correct port and connects them together. As far as the Python underpinnings to
make that happen Steve or Nate would need to comment.
Ali
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
