Thanks for the ideas, Korey. I agree that using our existing objects better (defining what they really represent and then using them consistently according to those definitions) should be a central part of whatever we do.
2009/2/17 Korey Sewell <[email protected]> > While I do see Gabe's points about not placing the burden of register file > indexing, additional ISA semantics, and potential renaming on the CPU, I > disagree somewhat with the notion that we should split the register file > into 2 objects: ISA-specific indexing object and a CPU-defined generic > register file storage I think the key to Gabe's design is that all that's left of the register file once you've factored out the indexing object is this: TheISA::IntReg regs[TheISA::NumIntRegs]; TheISA::FloatReg regs[TheISA::NumFloatRegs]; so the benefit of defining those two lines in a central place is pretty minimal, and given that at least one CPU model (O3) doesn't use that storage at all, there's no point in requiring it to exist. For the most part, I think that if you have one object (indexer) whose sole > purpose is to provide info for another object (register file), then those > objects should be unified The key is that the indexer can provide indexes to multiple kinds of register files, flat dumb ones or fancy renaming ones, and so there's no point in hardwiring in the former. > It also gets more complicated in the multithreading case, since now we have > to deal with indexing of shared-system registers. Yes, this is an issue that needs to be considered, as I mentioned in my previous email. It's not clear that integrating in the register storage makes that any easier though. > - Consolidate the discrepancies in how ExecContext is used in CPU Models: > ExecContext is the object that an instruction (DynInst) interfaces with to > perform it's function on a CPU model.The SimpleCPU defines it's ExecContext > to be a pointer to the actual SimpleCPU object. The O3 defines it's > ExecContext to be a pointer to the ThreadContext. InOrder model follows > suit. **My solution would be to force all instructions to use a > ThreadContext pointer to interact with the CPU**. Allowing an instruction > direct access to the CPU forces the pre-processing of thread-specific > information to be done in the CPU or the instruction object when it really > should always be done in the ThreadContext object. Enforcing consistency > there simplifies the programming model and the "paths to correctness" so to > speak. I believe that in O3 the ExecContext is the DynInst. The key is that the ExecContext *by definition* is the interface that instructions use to access their execution context. It's got to encapsulate whatever state is required to correctly execute the instruction, which can be not much (for SimpleCPU) or a lot (for O3... note that the DynInst captures where in the speculative instruction flow the instruction exists, so it can get properly renamed registers, etc.). So what you're really saying is that you want to merge the ThreadContext and ExecContext. There are a lot of similarities, but there are differences too; it's helpful to look at BaseSimpleCPU in src/cpu/simple/base.hh, as that's an object that implements the ExecContext interface (most of it, anyway) on top of the ThreadContext interface (provided by SimpleThread). There are a number of calls that pass straight through, but there are several (such as the register accessor instructions) that do not. Note for example that an instruction cannot directly access "register 23"; there have to be hooks that allow that register to be renamed, and to prevent an instruction from accessing a register that didn't get renamed as one of its operands. However ThreadContext does allow direct register accesses, because it's really a functional interface to the thread's context (similar to how a sendFunctional() access to memory differs from a sendTiming()). Kevin helpfully provided documentation on the wiki for these concepts (which I just found today): http://m5sim.org/wiki/index.php/ExecContext http://m5sim.org/wiki/index.php/ThreadContext http://m5sim.org/wiki/index.php/SimpleThread http://m5sim.org/wiki/index.php/ThreadState > > - Consolidate the similar portions of the ISA-specific register files into > a base register file that every CPU model and ISA can use: I think this is the ISA indexer object that Gabe was talking about... I don't think there's enough similarity in the raw storage to make sharing that across CPU models worthwhile. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
