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
