I've done a bit of digging so far, and I think I've figured out a bit about the rename mode.
1. This is only used by ARM to handle the difference in how registers are renamed in aarch64 vs otherwise. 2. This is handled in O3 by detecting a squash in the CPU and then checking the aarch64 bit of the PCState. 3. If this changes, then O3 potentially shuffles things around to make register chunks contiguous, and starts renaming things differently. 4. The only way to switch in or out of aarch64 is through a fault. This leads me to a few conclusions. 1. Having the aarch64 bit in the PCState structure is probably not necessary and may actually be harmful because it makes that structure larger and slower to move around. This value does *not* change quickly or frequently, and only changes as part of an already heavy mode switch. It does not need to be predicted/predictable like a next PC, like something like thumb mode might. 2. The O3 CPU is checking renaming mode *way* more often than it really needs to. Almost every single squash is *not* a switch to/from 64 bit mode, but *every* switch involves that check, even in ISAs that don't even *have* rename modes. 3. The rename semantics switch can be handled right in the fault object when it implements the faulting context switch. It can detect that a switch is necessary and enact it without all the extra checks. 4. ARM can implement SVE, etc, using two different register files, one which is indexed by element for 32 bit mode, and one which is indexed by vector for 64 bit mode. The mode switch can copy values between the register files, and we can remove what I suspect is a lot of machinery from O3 by just letting it manage two different register files simply, instead of managing one with two different personalities. This also makes the register files much more homogenous and easier to generalize. A "real" CPU may not want to waste transistors, buses, etc, for two separate register files, but in the end it doesn't matter if the behavior is the same. This is all just in how O3 does its bookkeeping, and a redundant register file is nearly free for gem5. Please let me know if this is correct, and I'll start chopping away. Some way to test my changes would be very helpful, since otherwise I'll just be hoping for the best :-P. 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
