Liste des Groupes | Revenir à c arch |
MitchAlsup1 <mitchalsup@aol.com> wrote:On Mon, 12 Aug 2024 2:23:00 +0000, Brett wrote:
BGB <cr88192@gmail.com> wrote:
Another benefit of 64 registers is more inlining removing calls.
A call can cause a significant amount of garbage code all around that
call,
as it splits your function and burns registers that would otherwise get
used.
What I see around calls is MOV instructions grabbing arguments from the
preserved registers and putting return values in to the proper preserved
register. Inlining does get rid of these MOVs, but what else ??
For middling functions, I spent my time optimizing heavy code, the 10% that
matters.
The first half of a big function will have some state that has to be
reloaded after a call, or worse yet saved and reloaded.
Inlining is limited by register count, with twice the registers the
compiler will generate far larger leaf calls with less call depth. Which
removes more of those MOVs.
I can understand the reluctance to go to 6 bit register specifiers, it
burns up your opcode space and makes encoding everything more difficult.
I am on record as stating the proper number of bits in an instruction-
specifier is 34-bits. This is after designing Mc88K ISA, doing 3
generations
of SPARC chips, 7 years of x86-64, and Samsung GPU (and my own efforts)
Making the registers 6-bits would increase that count to 36-bits.
34-bits comes from having enough Entropy to encode what needs encoding
and making careful data-driven choices on "what to put in and what to
leave out" and finding a clever means to access vectorization and multi-
precision calculations. Without both of those 36-would likely be the
best option for the 32-register variants.
Les messages affichés proviennent d'usenet.