Hey Gabe, Sorry for the slow reply.
1. Re: port interface in the base class. I agree with you. No need for this interface to be forced on CPU models. In fact, I have a simple CPU model with a single port which returns the same pointer for both functions :). 2. Re: CPU switching. I actually have given a lot of thought to this, and I've developed a new interface which instead of switching the CPUs through this rigid interface allows any ports to be connected/unconnected at runtime. I believe if we use my new interface (which I need to somehow find the time to revive), then this would overcome this problem. 3. Re: proxy ports. I agree that it makes sense to only expose the functional interface to the memory system through the thread context. TBH, I'm not sure this even needs to be routed through the CPU. I can imagine other kinds of "contexts" (e..g., a GPU context) which may want to make functional accesses to memory. Cheers, Jason On Wed, Apr 17, 2019 at 7:38 PM Gabe Black <[email protected]> wrote: > Hi folks. I noticed that there are two methods on the CPU base class, > getDataPort and getInstPort, which return references to MasterPort objects > which presumably see memory from the perspective of the CPU. These > functions seem to serve three purposes as far as I can tell. > > 1. Give a component of the CPU a way to access the connection to memory > which belongs to the CPU. This could be done by the CPU subclass and > doesn't need to be done in the uber base class for all CPUs. > > 2. Provide a way to switch out CPUs. These two ports are disconnected one > the original CPU and reconnected on the new CPU when the switchover occurs. > This is useful, but it seems to rigidly assume that there are two ports > which serve these two purposes. This feels like it could be improved. > > 3. Give proxy ports a way to connect to memory for function requests. > > This last one is the one I'm interested in primarily, since it seems a > little mismatched and a little dangerous. First of all, the port being > requested is for the entire CPU, but proxy ports tend to set themselves up > from the perspective of a particular thread context. Granted a particular > thread context would access memory through a common port most likely, but > this involves more types of objects and more levels of abstraction than may > be desirable, and circumvents the ThreadContext somewhat. > > Also, these functions return a reference to the *entire* port, not just the > part that does functional accesses. They only *use* the part that does > functional accesses, but there's no restriction that requires them to do > that. They could, for instance, send a timing request which might cause > problems with the owners bookkeeping, and they have no way to hook into > callbacks when, for instance, a timing request completes. The only > useful/safe-ish thing they can do is a functional access. > > What seems like a reasonable solution to this problem is to add a > sendFunctional method to the ThreadContext which it can then route through > the CPUs port indirectly, in a way that the CPU has some influence over > since the ThreadContext is likely tightly coupled with and aware of how the > CPU works. That hides all the other goo inside the port, and makes it much > more clear what that interface is for. > > Thoughts? > > Gabe > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
