Re: Tonights Tradeoff - Background Execution Buffers

On 2024-10-09 12:19 p.m., MitchAlsup1 wrote:

On Wed, 9 Oct 2024 10:44:08 +0000, Robert Finch wrote:
 

>
Been thinking some about the carry and overflow and what to do about
register spills and reloads during expression processing. My thought was
that on the machine with 256 registers, simply allocate a ridiculous
number of registers for expression processing, for example 25 or even
50. Then if the expression is too complex, have the compiler spit out an
error message to the programmer to simplify the expression. Remnants of
the ‘expression too complex’ error in BASIC.

 Both completely unacceptable, and in your case completely unnecessary.
in 967 subroutines I read out of My 66000 LLVM compile, I only have
3 cases of spill-fill, and that is with only 32 registers with uni-
versal constants.
 Of the RISC-V code I read alongside with 32+32 registers, I counted 8.
 With those statistics and 256 registers, If you can't get to essentially
0 spill=fill the problem is not with your architecture but with your
compiler.

Yes, that is sort of what I was thinking. The compiler does not generate very many spills and fills, using just 32 regs (10 temps+9 saved possibly). Most functions do not have any spills or fills. Using just a few more registers might virtually guarantee they never happen. Or have the number of registers used a compiler option, in case there is a case with not enough registers. I suppose the compiler could keep increasing the number of registers it uses until it has enough.
Not spilling and filling was to get around the issue of having to save extra carry-overflow bits for a register. So, maybe allowing the compiler to spill and fill is possible if CO bits are not needed for the app. So, one might have either compact and fast extended precision arithmetic or complex arithmetic expressions. Could make the compiler smart enough to detect the situation.