Re: Frame-related delay slot insns

[law at redhat dot com]

In message <wvn7k942kqo.fsf@talisman.cambridge.redhat.com>, Richard Sandiford w
rites:
 >law@redhat.com writes:
 >> In message <wvnof2g2rjq.fsf@talisman.cambridge.redhat.com>, Richard Sandifo
 >rd w
 >> rites:
 >>  >Richard Sandiford <rsandifo@redhat.com> writes:
 >>  >> The (somewhat ugly) patch below was tested on mips-elf, mips64-elf,
 >>  >> mips-sgi-irix6.5, mips64vrel-elf & mipsel-linux-gnu.  OK to install?
 >>  >
 >>  >BTW... I was in two minds as to whether the frame effects of the delayed
 >>  >insn should be described before or after the effects of the delay slots.
 >>  >It doesn't matter either way for mips.  Are there any back-ends for
 >>  >which it would?
 >> It would certainly matter on the PA.  In fact, one of the nastyiest long
 >> standing debugging/backtracing issues occurs when you have a function
 >> where the initial stack pointer adjustment gets pushed down into the
 >> delay slot of a branch.
 >
 >OK, thanks.  Which way round should it be for PA?  Do the effects
 >described by a call's frame-related expression happen immediately
 >(before the delay slot insns are executed)?  Or are they delayed?
The best way to think about how this works on the PA is to look at
when side effects of each instruction occur.

On the PA insns with a delay slot can have multiple side effects.  For
example, they may increment a register, change the PC, transfer a 
link address into a register, etc.

For the insn with the delay slot, the semantics are that the only
delayed effect is the transfer of control.  ie, all other side effects
such as incrementing a register, clearing a register, setting up a
link register, etc happen immediately.

The side effects of the insn in the delay slot will occur after the
non-control side effects of the insn with the delay slot.  Then finally
the control transfer of the insn with the delay slot will occur.

Here's a simplified example:

	addib,= 1,r2,<target>
          sub r2,r1,r2

The "addib" instruction increments r2 by 1 and if the result is zero,
then we jump to <target>.  The "addib" instruction has a delay slot
which is filled by a simple subtraction instruction (r2 = r4 - r2).



  cycle 0  r2 = r2 + 1, compare result with zero
  cycle 1  r2 = r2 - r1  /* Note this is r2 result computed in cycle 0 */
  cycle 2  If comparison in cycle 0 was true, then branch to <target>,
           otherwise fall-thru

This (of course) can be more complicated as the PA allows branches
in the delay slots of branches.  Luckily the number of cases where
this is an interesting and profitable thing to do are so so tiny
that I can count on one hand the number of instances I've run into
over the last 10 years of hacking PA codes. 
wi


Jeff