Hi, Gem5 currently rely on a unified space to map a register index to a class of register and a relative index. While such a mapping is quite straightforward when dealing with two classes of registers, it starts to make less sense when adding more registers classes. A patch has been created [1] to move from a unified space to a structural space. With this change, an architectural register index is know identified by a structure containing the class and the relative index of the register. This new structure is called RegId. The main advantages are:
* the code is a lot more clear when dealing with RegId because it is straightforward to know which type of register you are dealing with. * It eliminates the need to go from relative to unified then to relative, which is quite common throughout the code. * adding a new class of architectural register requires minimal effort and is decoupled from the definition of the other classes (mainly because there is no need to define a class to be on top of an other in term of indexing) The main disadvantage is the extra overhead: the RegIndex type is most of the time a uint16_t while the RegId adds a enum on top of that. The same kind of change [2] have been made for the Physical register indexing (in the O3 model). Here things are bit different as it is sometime handy to have a unified space, when the register class information is not needed, for example for the dependence graph and the scoreboard. That is why the PhysRegId structure contains a relative (regIdx) and a unified (flatIdx) index. Also, because physical registers objects are create once, PhysRegId are also created once and stored alongside the physical registers (in the regFile object). Most of other objects (freeList, dynInst, renameMap) then use a pointer (const PhysRegId* typedef to PhysRegIdPtr) to deal with them. This should enforces that no new PhysRegId is created after startup and the relative and unified index stay in sync. [1] arch, cpu: Architectural Register structural indexing: http://reviews.gem5.org/r/3457/ [2] cpu: Physical register structural + flat indexing: http://reviews.gem5.org/r/3458/ Looking forward to your reviews. Thanks, Nathanael IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
