Re: (m) Re: [f-cpu] More Instruction Set Trouble

[Michael Riepe <michael@stud.uni-hannover.de>]

On Wed, Aug 22, 2001 at 01:37:13PM -0400, Lee Randolph Salzman wrote:
[...]
>         I think this may end up being messy. Consider that two places
> where this instruction will be heavily used:
> 
> 1) loading data at an immediate offset from a stack/frame pointer
> 2) loading data at an immediate offset from a global storage pointer

loading/storing data at an immediate offset from any pointer

>         In both cases, these pointers are fixed registers, therefor the
> destination of said load instruction would also end up being fixed. So
> then you'd have to carefully lay out your ABI so that fixed registers
> are atleast a distance of 2 away from eachother. Moreover, since it is
> a fixed register if you wanted to load another address in parallel with
> it (you're not going to use the data quite immediately or else you fuck
> with the pipeline/scheduling/prefetch), you'd have to move the calculated
> address out of that fixed register to make room for another.

Yep, that's bad.  That's what I meant with "register pressure".

>         What I suggest is, as controversial as this may be or not, just
> to overwrite the source register (r1) with the calculated address. This
> can be quite handy in a number of situations such as iterating over an
> array (where you're constantly incrementing a pointer to load/store
> elements), and also gives the processor good hints about what you're
> doing with an array as a side-effect. This does mean you have to move
> the base register to a scratch register before you can use the
> instruction, but consider that you can also reuse previously calculated
> addresses to minimize this cost signifigantly: i.e. if we need
> to calculate SP + 16 for some snippet of code, and later need
> to calculate SP + 48, so long as the result of the SP + 16 calculation
> is still live, we can just calculate the result + 32 with the
> special form of the loadaddr instruction all the same.

That's bad as well.  Moving the base pointer before calculating the
address is even worse in terms of address calculation delay because
the move will need lots of extra cycles -- the sequence causes a
read-after-write dependency.  This is also true for the `move-away'
case, but there we can move the register later (maybe in parallel with
the memory access).

Instructions that overwrite their own operands are evil in general.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/