Hi Gabe, I like the idea of this change. Getting rid of that silly getPort boilerplate is really nice!
I've looked through the changes, but maybe because it's late in the day, I can't figure out how backwards compatible this change is. If I have my own MemObject that's not in the mainline, will I need to make changes or will everything "just work" (assuming I don't have non-conforming names)? If it's *not* backwards compatible, then I suggest keeping the old interface as well, if possible. Cheers, Jason On Tue, Sep 3, 2019 at 2:33 AM Gabe Black <gabebl...@google.com> wrote: > 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 <gabebl...@google.com> 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 > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
