🚀 go-pugleaf

In article <2085@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
<> You see, the problems tend to be with globally allocated data,
<> whose address isn't known until link time. So what's an optimiser
<> supposed to do?
<
<If you're using the variable frequently in a routine (say, in a loop) it should
<store the address of the variable, or the base address of the array, in a
<register. If not, then who cares how you get to it?

In that case, I'd much rather have the _variable_ in a register!
Trouble is, you have to spill it back to memory for function calls and
references through pointers. Maybe I should just declare it noalias
:-)>. (there's your beard, Peter!)

<> On the other hand, subroutine jumps could be to routines that you
<> don't have an address for yet (they may not even have been written yet
<> :-). So once again, the optimiser is missing some important data.
<
<Not at all. You apply this optimisation to the routines you know are local:
<that will be in the same load module. You're going to want to make long jumps
<outside that load module anyway, since it could be scatter-loaded anywhere.

This is roughly what Lattice/BLINK does now, a John Toebes already
pointed out.

<It's interesting to note that the Sun software for their RISC box does
<code modifications like these in the linker.

Not really. Putting stuff like this in the linker makes a lot of sense
- so long as you don't loose all the advantages in doing it. Somebody
at Sun almost certainly new that, and made sure that didn't happen on
the SPARC.

	<mike
--
When all our dreams lay deformed and dead		Mike Meyer
We'll be two radioactive dancers			mwm@berkeley.edu
Spinning in different directions			ucbvax!mwm
And my love for you will be reduced to powder		mwm@ucbjade.BITNET