Re: Delay slots

On Mon, Jun 20, 2016 at 02:44:48PM +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.
> 
> 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.
> 
> 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.
> 
> This is all specific to individual machine implementations.  A generic list would have to be the union of all hazards, which is going to be quite a long list.  Some machines have very few; others (such as the Sibyte chips) have a rather substantial set.  In some cases, specific chip revs have even more hazards and particularly bizarre rules because you're actually looking at chip bugs and their workarounds.
> 
> So my answer would be: read the specific machine data sheet or programming manual for the hazards.  Hopefully they are described correctly and completely.  (Some vendors assign data sheet writing to the marketing department, so the English is pretty good but the technical content is not.)  You may need to find the "errata" for the product in question; access to that information may be hard to get at times.
> 
> 	paul
> 

Hi Paul!

I've been playing a bit since, and came across this helpful stockpile of
docs: http://wiki.prplfoundation.org/wiki/MIPS_documentation
Which seems pretty decent for any CPU designed in this century.

I was under the impression we've got a big issue with many instructions
being done without considering MIPS-I hazards. I'm no longer sure that
is the case, but the unifdef & grep -A trick was really handy to feeling
more confident about not having missed some cases in our ifdef-heavy
assembly code.

The impression I get thus far is that things executed on the same
pipeline (i.e. 'regular' instructions) are mostly sensible and
consistent across an ISA version (with MIPS-I being the worst offender,
and many machines since have interlocks for nearly everything, and gas
with reorder doing a fairly good job of doing the right thing if we
just let it try).

And that most of the per-machine variance is when doing things like
waiting for the FPU to be enabled (hopefully we can just wait enough)
and instructions like 'wait' being broken on some machines which
we've already got an opt-in quirk table for. (coincidentially came
across it mentioned on sbmips - BCM4706)

Perhaps I'll run into more issues once I play with some real hardware ;)
I've been using an emulator so far, but already found some issues worth
tackling, e.g. SOSEND_LOAN being broken on some MIPS machines, and I can
see this issue in emulation, too.
I've gotten some nice pointers for that issue, although I can temporarily
circumvent it by disabling it.

Thanks