Re: Why I've Dropped In

On Tue, 17 Jun 2025 1:26:01 +0000, Stephen Fuld wrote:

On 6/16/2025 9:17 AM, Stefan Monnier wrote:

Therefore, I reduced the index register and base register fields to
three bits each, using only some of the 32 integer registers for those
purposes.

This is going to hurt register allocation.

>
I vaguely remember reading somewhere that it doesn't have to be too bad:
e.g. if you reduce register-specifiers to just 4bits for a 32-register
architecture and kind of "randomize" which of the 16 values refer to
which of the 32 registers for each instruction, it's fairly easy to
adjust a register allocator to handle this correctly (assuming you
choose your instructions beforehand, you simply mark, for each
instructions, the unusable registers as "interfering"), and the end
result is often almost as good as if you had 5bits to specify
the registers.

>
I can see that it isn't too hard on the logic for the register
allocator,

You are missing the BIG problem::
Register allocator allocated Rk for calculation j and later allocates
Rm for instruction p, then a few instructions later the code generator
notices that Rk and RM need to be paired or shared and they were not
originally. How does on fix this kind of problem without adding more
passes over the intermediate representation ??

           but I suspect it will lead to more register saving and
restoring.

And reg-reg MOVment.

            Consider a two instruction sequence where the output of the
first instruction is an input to the second.  The first instruction has
only a choice of 16 registers, not 32.  And the second instruction also
has 16 registers, but on average only half of them will be in the 16
included in the first instruction.  So instead of 32 registers to chose
from you only have 8.  So the odds increase that you must save one of
those 8 and perhaps restore it after the two instructions have
completed.
>
It sure seems ugly to me.

It has been under study by compiler people since at least 1963 without
much forward progress.

>