Re: An unusual Performance approach using Synthetic registers

[Michael S. Zick <mszick@goquest.com>]

On Monday 30 December 2002 06:32 pm, James Mansion wrote:
> > application programming in assembler, I found 16 general purpose
> > registers not to be enough.
>
> I suspect, however, that this was because you wanted to avoid *coding*
> spill logic for registers that were reused infrequently. That's
> different for avoiding spills for *material* performance reasons, and
> a compiler isn't as lazy as you (or I).
>
> James
>
One, grumpy old man, says (once again):
That is an artifact of current compiler implementation.

To catorgorize register usage into two groups,
"reused infrequently" and "not reused infrequently"
is a decision.

For the human, it is a subjective one,
For a compiler, it is the result of numerical analysis.

For a human, experienced, assembly langauage programmer,
having knowledge of register usage that spans that represented
in a single (or limited number) of source file(s)...
The registers that fall into the "reused infrequently" group are one 
thing.

For a compiler, where its use of numerical analysis has been
artificially limited to less than the entire application (say limited
to a single source file)...
The registers that fall into the "reused infrequently" group are
a different thing.

The compiler's numerical analysis equivalent of human
"cognative span" has the potential for a span far greater than
any human.

My position:
If the compiler implimentation is done such that its "cognative
span" (numerical analysis) matchs or exceeds that of the human,
then you should see the number of registers that fall outside of its
"reused infrequently" group match or exceed that of the human's.

So the people who are looking at compiler output;
and reaching the conclusion that "16 registers are more than
enough" are probably right - for a compiler implemenation having
a crippled cognative span.

And the people who are drawing on their experience;
and reaching the conclusion that "16 registers don't even begin
to approach what is necessary" are also probably right - from
the viewpoint of considering a greater span of source than the
compiler does.

Q.E.D: Its an artifact of compiler implementation.

Mike