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