5 ms·
The blog post you link to criticizes MIPS because it has pipeline hazards and branch delay slots. MIPS had hazards in 1985. MIPS II eliminated hazards. No MIPS
by spoonhat 8y ago
The blog post you link to criticizes MIPS because it has pipeline hazards and branch delay slots. MIPS had hazards in 1985. MIPS II eliminated hazards. No MIPS processor released after 1989 has hazards. Branch delay slots are no big deal once you know they're there. There are a number of equally questionable design decisions in RISC-V, such as variable length instruction encoding and dest, src order of instruction operands. But RISC-V does have momentum.
- amluto 8y ago> Branch delay slots are no big deal once you know they're there. I disagree. I'm not really a MIPS user, but I've managed to encounter some branch delay slot issues, and, as an x86 system programmer, I can only imagine how unpleasant they must be. Here are some reasons: - The program counter does not adequately describe the execution state of the CPU. In other words, starting or resuming execution with a given set of register values and a given address will do the wrong thing if you're resuming in a branch delay slot. - Handling a fault due to an instruction in a branch delay slot seems highly problematic. Suppose you have a load in a delay slot and the load touches swapped-out memory. How is the operating system supposed to page in that memory and resume? - Linux, and probably other operating systems, will emulate FPU instructions if the CPU doesn't support them. Emulating FPU branch instructions is deeply problematic because of delay slots.
- monocasa 8y agoThe first two just mean that there's an extra trap state bit in a flags register for "I'm in a bench delay slot currently" and isn't really a big deal. The third one I imagine is a pain in the ass, but I've been lucky enough to always compile MIPS for the exact CPU I was running it on.
- amluto 8y agoIt’s more than just a bit. You need a bit saying “in a delay slot” and a whole word that stores the target of the branch.
- monocasa 8y agoNah, a delay slot bit is fine. Branches haven't really retired yet (that's the point of a delay slot), so when you reenter the instruction with that bit set the CPU just backs PC up and executes both of them again. You have to make sure you can map two pages at once in case the branch/delay pair straddles a TLB boundary, but you have to screw up pretty bad to not allow that.
- amluto 8y agoshudder If you try this on hardware that also supports software single stepping (which x86 does, but MIPS seems not to by default), then you have to be extra creative to guarantee forward progress. The same issue arises if you have data breakpoints. And if the branch loads from MMIO space, you have a problem.
- monocasa 8y agoI mean, it's MIPS so it's a load/store architecture anyway. Between the pair you're only going to have one memory reference at most, and it's going to be the delay slot.
- userbinator 8y agosuch as variable length instruction encoding and dest, src order of instruction operands One is basically necessary to get decent code density (and thus better cache utilisation and memory bandwidth minimisation, something that x86 was winning at for a long time --- and one of the worst parts of traditional RISC), the other is purely syntactic sugar (see the horrible GAS/AT&T syntax) and an order which I find most sensible (especially considering comparison and subtraction, as well as the direction of the assignment operator in the majority of programming languages that exist.)
- monocasa 8y agoVariable length instructions are to match Thumb2/SH4 ideas/density. Having written a simple RISC-V emulator, I totatlly agree with you that the operand encoding is non-intuitive, but it's nice for hardware implementations. There's a lot more non-intuitive opportunities for weird sharing in the decode stage that you'd never expect. Particularly that's why the branch offset has such bananas encoding.