From: adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: Sat, 26 Sep 1992 15:18:31 GMT
	<1992Sep24.235308.18105@odin.corp.sgi.com> <1661@idacrd.UUCP>
	<ADAMS.92Sep25172127@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
	<CLIFFC.92Sep25182902@helena.rice.edu>
Organization: TH-Darmstadt

In article <CLIFFC.92Sep25182902@helena.rice.edu> cliffc@rice.edu (Cliff Click) writes:

>   This is not nessecarily so.  Not all stores to cache are 1 cycle,
>	or even 2.
	
Should not they be one-cycle?

>   Bad: Writing to memory requires you to have a pointer to a spill location 
>   handy.  Sometimes due to local storage requirements and other temps 
>   generating a stack frame offset takes 2 or more instructions.  

Should not stack frame have already been established during compile
time for objects with known size?

>	Thus the store
>   to cache might take 2 instructions (cycles) to set up, and 2, possibly 3
>   more cycles to do the store.  

Perhaps I got something wrong, but looking at current stack engines,
there seem to exist address generators doing above with the cost of at
most one cycle, as it may be performed in parallel to other
operations, if a window of the stack is cached.

>	Addressing might require AN ADDITIONAL REGISTER
>   for building the spill offset causing you to spill earlier than you might
>   otherwise have.  And the same costs occur again on the reload.

It might, but it need not...see above.

>   Worse: Not all stores of spilled registers go to cache.  If you have some
>   poorly placed spill code, you might end up spilling the same register in a
>   loop and not reloading it (till after the loop).  

Get a better compiler ;->. Hardware is not able to fix everything.

>  With a cache miss and a
>   write-around cache the store will go to memory time and time again.
>   Or more likely, your cache line with the spilled registers gets flushed and
>   reloaded from the cache on every pass through the loop (perhaps because of 
>   an unlucky hit from some referenced global variables).

1) Use smaller cache lines.
2) This should never occur. 
	
	a) Backup of registers are temporary variables, placed on the 
	stack. Stack and globals should very seldom share same address range.
	(Stack underflow / Heap overflow) and cache lines . or
	
	b) Backup of registers is located at fixed addresses, and is known 
	as that by tag ram. As long as you do not assign a register a global
	variable ( which was possiple on DEC-10), globals and registers
	are kept on different cache lines ..

>   In short, fast code avoids memory whenever possible.  A fast int<->float 
>   register path lets the compiler "spill" to the other register set when the
>   current one gets full.  

How about increasing local registers to reasonable amount (16..32),
and offering a global, multiported register file between 
FPU and CPU (ALU). This was built with 20 ns access time from both 
ports in 1988, now they are just down to 12.5 to 9 ns [ECL or BiCMOS].

>   >Your apporach does not offer any performance gain.... 
>   I beg to differ.

Where to put the floating point values ??? Spill them to stack and 
freeze FPU? Please remember that most FPUs work in parallel with
CPU (in fact ALU), but need much more time to complete one instruction.

In fact, most often FPU register are indeed not available at all...

best, adams