Unfortunately it looks like that mechanism I mentioned (for predicating reads/writes) makes some big assumptions which are not generally correct, they just happened to be correct in the situation that feature was initially used.
I think I'm going to try to replace that mechanism with one which puts sentry indices into the source/dest arrays which other mechanisms will know to skip. I think I remember mentioning that in an email before? That new mechanism will both handle zero registers, and replace this predication mechanism with something less complicated and less broken. Gabe On Thu, Aug 12, 2021 at 6:21 PM Gabe Black <gabe.bl...@gmail.com> wrote: > 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
