Addresses of parameters

[Tim Olson]

In article <84 at usl-pc.usl.edu> elg at killer.UUCP (Eric Lee Green) writes:
| Note that many machines with large register sets or register windows
| machines have optimizing compilers that keep ALL local automatic
| simple variables in registers, not only variables declared
| specifically as "register". This wrecks havoc with Unix.

How so?

| That's why
| the Pyramid 90x has the bogosity of a memory-mapped register window
| stack (so that you CAN take the address of a variable and have it mean
| something). That won't help the AMD29000 or the SPARC much, though. I
| suspect that what will happen then is that when the optimizer is
| deciding what register to allocate for what, it'll notice that you're
| taking the address of that particular variable -- thus forcing it into
| RAM,

That is precisely what happens.

| which is a performance hit if you use that variable often (e.g. a
| "char *" auto-incremented in a loop will be 6 times slower in RAM on
| the AMD than it would be in a register).

Not so.  Just because a variable has been aliased to memory does not
mean that a local copy cannot also be kept in the register file and used
from there.  The compiler just has to ensure that the memory copy is
updated correctly.  To use your example:

	inner loop where p			inner loop where p
	is in a register			is aliased to memory

;               sum += *p++;		;               sum += *p++;     
        load    0,17,gr121,lr6		        load    0,17,gr121,lr6    
        add     gr119,gr119,1			add     lr6,lr6,1        
        exbyte  gr121,gr121,0		        exbyte  gr121,gr121,0    
        add     gr120,gr121,gr120	        add     gr120,gr121,gr120
        cplt    gr121,gr119,10		        add     gr119,gr119,1    
        jmpt    gr121,L00012		        cplt    gr121,gr119,10   
        add     lr6,lr6,1		        jmpt    gr121,L00012      
					        store   0,0,lr6,lr2      

It is only one instruction longer when the variable is aliased to
memory.

	-- Tim Olson
	Advanced Micro Devices
	(tim at crackle.amd.com)