🚀 go-pugleaf

[A response pointing out that inter-statement optimization creates
opportunities for increased register use.]

>Your example works, but under special case assumptions: that you are working on
>a reg-reg architecture, whereas we were discussing reg-mem ones; that putting
>all three a,b,c in registers is worthwhile because they are going to be used
>heavvily in other parts of the program.

A value needn't be "heavily" used in order to benefit; if it is reused
once and kept in a register instead of in memory, then the program has been
sped up.  On a CISC or a RISC, this is true.  A well-designed CISC (like
the 486 or the 040) can get as much benefit from lots of registers as
can a RISC.  (This results from the fact that the cores of these well-
designed CISCs are essentially RISC pipelines....)

>The reg-reg assumption actually may point at one of their weaknesses, that
>since the cost of computing with parts of your operands in memory has a high
>fixed cost, you tend to want to store everything in regs, even if they are
>used little. In a reg-mem architecture little use variables in memory do not
>carry costs as high when you use them.

A memory-resident value on a reg-mem machine might not carry as high a cost
in *code size,* but the same number of memory references must be executed
on a reg-reg machine and a reg-mem machine.  The same number of processor
cycles will be used.  If the 30% code size penalty of a reg-reg machine is
of concern to you, then, as discussed a while back, the use of a reg-mem or
mem-mem machine is obviously warranted!
    	
>>    the knee of the curve was in the 24-28 range, for generally-allocatable

>Uh? This really astonishes me. I would have bet that even for a RISC, even
>doing inter statement optimization, the number was about 8-12 rather than 4
>(rationale: 4 scratches + 4 for register variables automatically chosen by
>the compiler+4 for RISC'iness at most).

The difference comes from the clever things that can be one for procedure
calls when enough registers are available.

>Disclaimer: I have only worked extensively on reg-mem machines so far. For
>such machines I beg to differ; my impression is that for intra statement
>optimization four scratch regs is enough, and for inter statement
>optimization ("register" variables) another four is enough. Hence my hunch
>that 8 (386), or 3+3 (plus 2 for system work) is a bit tight, but still
>tolerable, and 16 (68020) is even overabundant.

This is if you are willing to keep values in memory and pay the attendant
memory access penalty.

>Ahhhhhhhh. What you are saying is that you are using registers as a
>statically allocated cache, and that this is good not because they are
>frequently used, but because they would otherwise be frequently
>saved/restored... Well, well, well. If you want a reg-reg architecture, you
>pay the price, you take your chances. Me, my idea of RISC is a (mostly) zero
>address architecture with 8/12 bit instructions, and four (to avoid extra
>push/pop pairs in multiplexing a single one for the up to four independent
>computations) arith stacks.

This is a strange idea of RISC (my opinion).  But you are entitled to your
own definition.  However, don't be surprised if few other people share
your idea.  (Ther is, by now, a large body of literature that uses a
definition, although sometimes weakly defined, of RISC different from
yours.  Precedent is not on your side.)

>Note that It is assumed that RISC == reg-reg, and that load-store == reg-reg;
>neither these equations are necessarily true, as one could have RISC ==
>stack-stack or load-store == stack-stack... 

Again, few people, I think, will understand that you are so liberally
interpreting RISC unless you explicitly state.  Maybe your idea of RISC
comes partly from the claims that the Transputer is a RISC?