I know nobody likes to read looong emails so I'll try to help in splitting this up this email into 2 parts: 1. Comments on Gabe's idea 2. My proposed solution
=== Comments on Gabe's Idea === >From what I gather from Gabe's writeup, I would say the quick/dirty of what Gabe wants to do is decouple the indexing aspect of register files from the storage of the register files and place those within separate objects (is that right Gabe?). My *guess* to what inspires Gabe to do this is Gabe's experience with the O3 CPU which does not use the ISA-specific, pre-defined register file (defines its own) but needs ISA-specific indexing functions to support more complex ISAs. That gets confusing. Also since the SimpleCPU does use the ISA-specific, pre-defined register file that presents a disconnect in how the CPU Models work across the board (there is one more thing that disconnects that I'll get to in a bit...). 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 do like the idea of generic reg-files that all CPUs use, which I'll get to in a bit...) 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 since there isnt a heavy enough distinction to argue for separate objects. For instance, an indexing object couldn't do it's job without first knowing how many integer, FP, and misc. registers the register file object has. On the flip side of that, the register file object would be useless without the indexing object giving access to the register file's registers. It also gets more complicated in the multithreading case, since now we have to deal with indexing of shared-system registers. So that's part of the reason why I believe it would be too much work just keeping the "books clean" for two objects, rather than treating the register file as a "black box" that you will assume will work correctly given the right inputs. === Korey's Solution === The solution I would argue for is to not further create objects for M5 to maintain but to: (1) Be more stringent about the usage of the objects we do have (e.g. only one path for an instruction to access the register file) (2) Consolidate ISA-specific objects that perform the similar functionality into a base-class object (e.g. the register file) (3) Derive ISA-specific capabilities from that base-class object. (i.e. indexing and system register functionality) The quick/dirty way to say that is let's just use the current objects that we have "better". The objects of interests are: ThreadContext, ExecContext, RegFile, DynInst. I would like to do these things to create a consistent, generic interface for instructions and CPUs to interact with registers: - 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. - Consolidate the similar portions of the ISA-specific register files into a base register file that every CPU model and ISA can use: The SimpleCPU model uses the ISA-defined register file, while the O3 defines it's own physical register file. Every ISA provides basic integer/floating point/misc. register file functionality yet defines them separately. Why not just create a register file that can be initialized to an arbitrary # of registers (so the O3 can use it as well the InOrder/SimpleCPU/ and register windowing archs.). Going on with something similar to Gabe's "large pool of registers" idea, the register file could also be initialized by things like the # number of threads and # of reg. windows so there can be one unified concept of register file for all CPUs/ISAs to use. Inside of that register file object, provide the basic functionality that all ISAs have readIntReg,readFloatReg, etc. - Derive a ISA-specific register files from the base register file object. This would take care of the ISA-specific indexing problem since in the case where a ISA does not want to reg. window it uses the base class functions whereas the more complicated case just derives it's implementation of indexing into an array or registers. This also solves the miscellaneous register file problem where although a CPU may have multiple threads, it only has 1 miscellaneous register file for system registers but in that register file some registers are duplicated and some are shared. The details and effects of changing those registers can be encapsulated in the ISA-derived version of the register file. - Enforce the consistent interface of instruction execution: instruction -> thread context -> cpu ->regfile. Each object should only interact with objects above or below it in the previous arrow example. So that's my basic idea. Just revamping the objects we already have to strengthen the Object-Oriented design principles that M5 already has in place. I think there is some overlap into what Gabe and I are thinking. -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
