🚀 go-pugleaf

>In article <1RcY6x#64Zq3Y=news@anise.acc.com>
	lars@salt.acc.com (Lars J Poulsen) writes:
>.... # regs on different machines ...
>>The biggest pain with an architecture that exposes too
>>large a register file is saving and restoring on context switches. While
>>interrupt service routines can ignore this and store only what they
>>need, context switches require storing of the entire register set. Or do
>>people really feel that the processors today are fast enough that
>>scheduling pre-emption is too rare to influence the selection of
>>register file size ?

In article <107302@sun.eng.sun.com>
	khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) writes:
>Upshot: modern compilers can employ as many registers are you can
>	design in. If you got 'em, you gotta figure out a way to 
>	save 'em. Windows, "multiconnect", register pointers, special
>	purpose (including vector) and other solutions are workable.
>
>Naive rationale for infinite (as long as they are free) registers:
>
>constant propagation and common subexpressions, combined with loop
>unrolling (or more advanced techniques like percolation scheduling)
>result in a need for as many as you got ... and then some.
>
>OS is different from application programs, and it is not clear that
>one might not be better off with a special OS register allocation
>scheme.

What I am talking about is saving and restoring registers when the
operating system switches from one user process to another. This is not
something that the compiler can improve on. Maybe the architecture could
define a "highest register currently in use" pointer, and encourage
context switches just before it gets incremented ?
/ Lars Poulsen <lars@salt.acc.com>     (800) 222-7308  or (805) 963-9431 ext 358
  ACC Customer Service                Affiliation stated for identification only
                  My employer probably would not agree if he knew what I said !!