Re: Delay slots

[coypu%SDF.ORG@localhost]

On Mon, Jun 20, 2016 at 06:04:39PM +0000, Paul_Koning%Dell.com@localhost wrote:
> Nice.  It seems to be almost entirely MIPS Co. designs, though.  Not Sibyte, or Raza for example.
> 
Oh dear...

> I think the best answer for MIPS-I is "just say no".  Beyond that, yes, interlocks seem to be there to take care of things in the non-privileged part of the ISA.  The one oddity is the branch delay slot.  That long ago stopped being about hazards; it's now just a very ugly wart in the architecture that can't be removed because of code compatibility.
> 
:-))

Still seems useful for a CPU to have all that extra room to do branch
prediction
> As for "gas" and reordering, I have always viewed assembler reordering as a very large design error.  Assemblers should assemble; if I meant something different from what I wrote I would have written the other thing instead.  Reordering by programs belongs in compilers, not assemblers.  Note that GCC for years now has used gas in no-reorder mode for this exact reason -- gas does a horrible job, gcc knows far more about what should be done.
> 
I see your point now, it seems whoever wrote much of the MIPS code in
NetBSD felt the same - there's set noreorder almost everywhere.

> "wait long enough" sounds like a bug waiting to happen.  The machine documentation will (well, should) spell out the rules.  It may require NOPs, or SSNOPs, or other stuff like ERET.  But it will be something definite, and the answer is to implement what is required.  If different machines have different rules, the union of the mechanisms will be needed.  So if machine A says "4 SSNOPs" and machine B says "cross an ERET" then you'll need both.  Hopefully that union isn't too excessive, and the requirements aren't in conflict.  I haven't seen problems; we might have SSNOPs that only one of the machines need, but (apart from the loss of a couple of cycles) they cause no harm in other platforms.
> 
I'm probably wrong about what we're doing here. I imagine it throws a
coprocessor unusuable exception for us to catch, too (although we
should still wait a bunch before trying to use it, anyway).

> That's interesting.  In general, emulators are likely to tell you very little about hazards.  They might have hazard-like bugs, but actual hazards in the sense we've been talking about are probably only going to appear in real hardware.  And there they might not show up consistently.  It is surprisingly hard to get the whole machine pipeline to be in the same state consistently.  I've seen CPU bugs having to do with mishandled pipeline states that the factory had never seen, and that in our code would only show up under load once every couple of hours or so.

Wonder if that'll show up as one spot overheating in thermal imaging.