Re: My 66000 and High word facility

Brett wrote:

BGB <cr88192@gmail.com> wrote:

On 8/11/2024 9:33 AM, Anton Ertl wrote:

Brett <ggtgp@yahoo.com> writes:

The lack of CPU’s with 64 registers is what makes for a market, that 4%
that could benefit have no options to pick from.

>
They had:
>
SPARC: Ok, only 32 GPRs available at a time, but more in hardware
through the Window mechanism.
>
AMD29K: IIRC a 128-register stack and 64 additional registers
>
IA-64: 128 GPRs and 128 FPRs with register stack and rotating register
files to make good use of them.
>
The additional registers obviously did not give these architectures a
decisive advantage.
>
When ARM designed A64, when the RISC-V people designed RISC-V, and
when Intel designed APX, each of them had the opportinity to go for 64
GPRs, but they decided not to.  Apparently the benefits do not
outweigh the disadvantages.
>

>
In my experience:
   For most normal code, the advantage of 64 GPRs is minimal;
   But, there is some code, where it does have an advantage.
     Mostly involving big loops with lots of variables.
>
>
Sometimes, it is preferable to be able to map functions entirely to
registers, and 64 does increase the probability of being able to do so
(though, neither achieves 100% of functions; and functions which map
entirely to GPRs with 32 will not see an advantage with 64).
>
Well, and to some extent the compiler needs to be selective about which
functions it allows to use all of the registers, since in some cases a
situation can come up where the saving/restoring more registers in the
prolog/epilog can cost more than the associated register spills.

  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.
 I can understand the reluctance to go to 6 bit register specifiers, it
burns up your opcode space and makes encoding everything more difficult.
But today that is an unserviced market which will get customers to give you
a look. Put out some vapor ware and see what customers say.

The solution (?) have always looked obvious to me: Some form of huffmann encoding of register specifiers, so that the most common ones (bottom 16 or 32) require just a small amount of space (as today), and then either a prefix or a suffix to provide extra bits when you want to use those higher register numbers. Mitch's CARRY sets up a single extra register for a set of operations, a WIDE prefix could contain two extra register bits for four registers over the next 2 or 3 instructions.
As long as this doesn't make the decoder a speed limiter, it would be zero cost for regular code and still quite cheap except for increasing code size by 33-50% for the inner loops of algorithms that need 64 or even 128 regs.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"