Re: Delay slots

[Warner Losh <wlosh%bsdimp.com@localhost>]

> On Jun 20, 2016, at 11:09 PM, Michael <macallan%netbsd.org@localhost> wrote:
> 
> Hello,
> 
> On Mon, 20 Jun 2016 14:44:48 +0000
> <Paul_Koning%Dell.com@localhost> wrote:
> 
>> 
>>> On Jun 11, 2016, at 1:23 PM, coypu%SDF.ORG@localhost wrote:
>>> 
>>> Hi,
>>> 
>>> I've heard port-pmax has trouble with mfc0 instruction needing a delay
>>> slot after it, and the generic MIPS code being modified and tested
>>> against newer machines which do not need this.
>>> 
>>> Delay slots are a generic MIPS problem, 
>>> ...
>>> If someone could provide a useful list of problematic instructions and
>>> mention architectures suffering problems, this could be a good tool.
> 
> Not a generic MIPS problem - sparc has delay slots too, with most jumps
> having a bit to cancel the instruction in it. I'm not sure about other
> architectures but I guess the reason why they exist don't apply to just
> MIPS and SPARC.

For MIPS the list of instructions is simple. There’s the branch delay slot
which always executes while the jump is happening. This is well know
and everybody takes advantage of it to ‘hide’ the loading of args to functions
or do other useful work. On mips1, there’s also the load delay slot, which
means you can’t use the result of the load for 1 instruction.

That’s it.

However, in supervisor mode, there’s what are called ‘hazards.’ These are
implementation defined delays in getting the results propagated to and from
CP0 (the MMU coprocessor). These require much careful study of the spec
(if you are lucky to be using a new enough design) or the processor manual
if not (and several processor manuals if you are trying to be generic, though
that path is always less efficient to be more convenient).

>> I think "delay slot" is a specific term with a different meaning.
>> Mostly it refers to the bizarre handling of the instruction
>> immediately following a branch instruction (other than
>> branch-likely). In MIPS-1 it also shows up in loads, but that
>> disappeared a very long time ago.
> 
> MIPS-II I think. Or was it 'implementation specific’?

No, it was MIPS ISA I only. It was eliminated in later ISA (at least
from MIPS ISA III and later).

>> What you're talking about I know as a "hazard" -- a machine-specific
>> rule that says after some privileged instructions you need to do
>> extra stuff before looking for a result, or expecting the action to
>> take effect, or whatever.  That extra stuff might be NOP
>> instructions, SSNOP instructions, or even weirder things.
> 
> IIRC powerpc needs sync or some delay after writes to certain internal
> registers ( "writes to x take effect after n clock cycles" or so ).
> Same thing really.

All CPUs I’ve ever used had some kind of delayed effect for some of
the instructions. The fun one is that the virtual address translations don’t
take effect until the next jump instruction, so you have to do things like
'jump PC+<sizeofinstruction> ‘ or a variation inside code that frogs the
TLB / MMU.

But in general there’s only these two classes: delay slots, which are
systemic in the architecture and everybody just copes with them, or
hazards, which are confined to a tiny fraction of code and only a few
specialists have to cope (and they usually cope wrong, at least some
of the time leading to fun bugs).

Warner