Another reason I'm treating the getPort part of things as an RFC is that it is nice to have the flexibility of getPort, and I don't want to try to envision every possible way getPort could useful be used and make a dodad which will provide that specific functionality. For instance, I could make something that would know how to forward ports in C++, or allow port aliases, but would that be any easier to use than just writing a little function to do it on the spot? Not having to do that in most simple cases is nice, being able to do it is nice, but having a hodge podge of doing it manually and not is a little off putting...
Gabe On Tue, Sep 3, 2019 at 2:26 AM Gabe Black <[email protected]> wrote: > 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
