Steve, Nate, Thanks for the feedback! I hope we can reach consensus on this soon.
To start with Nate's suggestion: It is not the members of System or MemObject that cause the problem, this is already in place. The issue is with the parameter header generation and SWIG wrapper generation. This would happen also without the PhysicalMemory, since System inherits from MemObject, and not a MemObject has a System pointer. Note that the latter could be fixed in c++ by forward declaring System in MemObject.hh. This, however, requires some serious modifications of the cxx_predecls, swig_predecls etc. A more general way of traversing the object hierarchy (I feel design patterns coming on :-) would definitely solve the problem and the setParent is really the not-so-general solution to this problem. Are there any other obvious good uses of this hierarchy that have been implemented in other (more inconvenient) ways? Steve's suggestion: Very much seems doable, with an additional class in the hierarchy. I also struggle with the naming, but I'll give it a quick bash and see how it goes. Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of nathan binkert Sent: 04 January 2012 21:53 To: gem5 Developer List Cc: Ali Saidi Subject: Re: [gem5-dev] Review Request: MEM: Add the system port as a central access point > The issue is essentially that the System inherits from MemObject, and placing > a system = Param.System(...) in MemObject creates a cycle. params/System.hh > ends up including MemObject.hh and vice versa. I have tried a number of > permutations of forward declarations etc using the cxx_predecls vs swig_decls > for the System/MemObject but not managed to solve it so far. It is starting > to look pretty nasty, but I will keep on going and see if I can solve the > circular dependency this creates in a decent way. The standard way of doing this is to break the cycle in C++. The reason you have a cycle (I believe) is that System has the physmem parameter and the memories parameter which are both PhysicalMemory objects which are in turn MemObjects. So, to do this the standard way, you'd put the system = Param.System stuff into MemObject and remove the physmem and memories parameters from System. Then in C++ during the constructor of PhysicalMemory, you'd call params()->system->registerPhysicalMemory (you'd have to write that function). The only hangup I see is that physmem is only one of potentially many PhysicalMemory Objects, so to make this work, you'd probably have to add a boolean parameter to PhysicalMemory that's like system_memory so that one object would get written back. It may just be better to allow cycles and enforce a more rigorous split between the constructors and init() (which I've wanted to do for a long time), but that's a much more complicated fix. Something else that would be possible and would make things easier for this sort of thing would be to add support for traversing the object tree in C++. It probably wouldn't be all that difficult. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
