Hi folks. I was looking at creating a base Interrupts class which would be ISA agnostic, and noticed that the x86 version inherited from BasicPioDevice. If I wanted to maintain its functionality, I would need to either make the base Interrupts class also inherit from BasicPioDevice, or to reimplement that functionality directly in the x86 Interrupts object.
That didn't seem great. I thought about it a bit, and as a first step decided to try templatizing PioPort so that it would be easier to use without a PioDevice to go with it, complicating the inheritance hierarchy. https://gem5-review.googlesource.com/c/public/gem5/+/20568 That worked out well, but then I noticed that I'd have to write some goopy boilerplate code to make the port work which BasicPioDevice took care of. It occurred to me that it would be possible to make ports register themselves with a SimObject and then have the SimObject know to return them in a default getPort implementation. That way the object hosting them wouldn't have to do much more than just instantiate them with parameters it already needed to give them (more or less), and it would take care of itself. That seems to also have mostly worked, although it touches a lot of files and I've only had time to do some very minimal testing (x86 hello world and initial Linux boot). There are some places where getPort was doing something more than the most basic, and those were left alone. https://gem5-review.googlesource.com/c/public/gem5/+/20572/1 One nice side effect of this effort is that it identified places where ports were named using an inconsistent scheme (name() + "-foo" or just "foo" instead of name() + ".foo"), or were not named the same thing in python as they were in C++. Since this is a large change that only partially eliminates getPort, I thought I'd treat this as an RFC for now and see what people think. A couple things I'm thinking of to improve the implementation is to make the PortNameMap more of a separate class than a map and a collection of functions. That will make it easier to use in other places like in systemc objects which have a parallel but independent mechanism in C++. I'm also thinking of setting up a Port forwarding mechanism in python where you could say something like: class Foo(SimObject): port = ForwardPort(other_object's_port) And then when binding happened, it would go grab that other port from the other object and not try to get it from Foo. That won't help when ports are forwarded to internal C++ objects which actually own the ports, but it would help if, for instance, you wanted to create a SubSystem which wrapped some objects and wanted to poke some of the internal ports out for people to connect to. I'm also thinking about making some sort of container for vector ports which would also take care of registering with the SimObject so you don't have those clunky explicit addVectorPort calls lying around. Gabe _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
