Hi, I have not seen any reviews or comments on those changes. As we would like to push them as soon as possible, is it possible for some of you to have a look?
Thanks, Nathanael On 28/04/2016 14:51, "gem5-dev on behalf of Nathanael Premillieu" <[email protected] on behalf of [email protected]> wrote: >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 >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
