Hey folks. I was thinking about better ways to handle the "zero register" in the CPUs.
A plan I had a little while ago was something sort of like /dev/null, where the zero register would be flattened to one thing if it was a source which would always hold zero, and another thing as a destination which would just collect junk. I was thinking about how to implement this, but it occurred to me that this scheme would have unnecessary overhead. Even though the source register would never be written to and would always have the same value, it would have to actually take up a spot in the register file, get plumbed through to instructions, etc, just to have a fixed value. The destination register would also take up at least one slot, and on systems which use renaming, may actually take up more slots if multiple instructions that wrote to it were in flight at a time. Fortunately, there is a mechanism that was added for x86 for condition code registers a good while ago which will help. The original idea was that when there is a single "register" from an architectural view which is actually made up of multiple real registers from an implementation point of view, specifically the condition code portion of the flags register in x86, you might read a register to build the original value of the composite register, but then end up writing over all the bits that came from that part. This mechanism lets you conditionalize whether you're actually going to read from (or write to) a register, and leave it out of src/dest register arrays and not actually call the accessors if not. So, my proposal is to use this mechanism to handle accesses to any zero registers at the ISA description level, and remove all special handling anywhere else. I expect this to be fairly painless and non-controversial, but wanted to send this email to let people know what was going on just in case, and also to provide context for the eventual reviews. I think I might put this into a JIRA issue as well. Gabe
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
