Re: Delay slots

Michael <[email protected]> Tue, 21 Jun 2016 01:09:57 -0400
Newsgroups gmane.os.netbsd.ports.mips.devel,gmane.os.netbsd.ports.pmax
Organization The NetBSD Foundation
Message-ID <20160621010957.7cea6d70@blackbush>
Hello,

On Mon, 20 Jun 2016 14:44:48 +0000
<[email protected]> wrote:

> 
> > On Jun 11, 2016, at 1:23 PM, [email protected] 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.

> 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'?

> 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.

have fun
Michael