On Tue, Feb 17, 2009 at 9:59 PM, Korey Sewell <[email protected]> wrote:
> A few quick points from reading Steve's email: > - O wow, I just realized I got mixed up in saying that the O3 > ExecContext is a thread context instead of a dyninst...my bad!...I > guess my point is that I would like to see some kind of consistency > there. But, there may be some functionality encapsulating in > ExecContext that I'm overlooking so time for a closer look at that. That's kind of the point of ExecContext, is that different models have dramatically different needs in terms of what kind of information needs to be encapsulated to allow an instruction to execute (register renaming of course being the prime example)... so the ExecContext interface lets us use a few very different objects serve the same purpose. The inconsistency would be if we didn't have a common ExecContext interface to these different objects. > - I started to come to the conclusion that the O3 *should* make use of > the ISA-defined storage object to again create one consistent type of > storage that is used by all CPU models. Of course, that's what we're > discussing now in the reg. file revamp ... > > - Why doesnt it work to view all register files as a flat space of > storage that is interpreted differently by ISAs? If that's what Gabe > is inching towards, I'd agree to that main concept although how that > indexer object will work concerns me in the long run. I'll keep tabs > on how the discussion into what we'll do evolves... > I think the issue is not that it wouldn't work, just that it's not clear what you gain by it. A basic "flat space of storage" really just means an array, and since different CPU models will need different array sizes, then if you put that array in a common place and you'd have to use a template for the size. Plus the commonality is only superficial since in one case you're using architectural register numbers as indices and in another case you're using physical register numbers. So it's a lot of effort to provide a common abstraction for something that's really just a plain native C++ data type. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
