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

Reply via email to