Quoting from Programming for Performance exercise:

early versions of the MIPS processor had an "exposed pipeline" (that is, the assembly language programmer needed to know the latencies of operations and had to insert NO-OPS or other operations between dependent instructions to guarantee correctness). Later versions of the MIPS processor abandoned this idea.

The above is what I was able to find by googling "CPU with exposed pipeline" (mentioning "CPU" in the search string is important). The MIPS architecture was introduced in 1981 (unfortunately, the wiki page doesn't mention the exposed pipeline, except in the acronym expansion without explanation).

It is my understanding that VLIW architectures which also have an exposed pipeline, came later. Is that true? Was MIPS really the first one?

  • 2
    This doesn’t answer your main question; but yes, VLIW architectures have an exposed pipeline. Statically pipelined CPUs take this to extremes (but aren’t necessarily VLIW). – Stephen Kitt Apr 5 '17 at 21:07
  • 1
    And the currently "newest" CPU with exposed pipeline which is not VLIW is probably the Mill architecture. RISC started more or less with MIPS, and DSP wasn't much earlier, so I doubt there are earlier exposed pipeline architectures than the MIPS-1. – dirkt Apr 6 '17 at 11:20
  • @dirkt That's right. A few years ago I went to a few of the Ivan Godard's presentations. – Leo B. Apr 6 '17 at 16:14
  • 1
    I have been unable to find a definitive statement, but reading about the architecture of the CDC 7600 (1968) has left me with the impression that its pipeline was exposed, although more for the reason that its designers simply never considered an alternative than for any specific architectural benefit – Jules Aug 3 '18 at 22:38
  • 1
    .... And I just found such a mechanism, described on page 2-16, a set of register reservation flags. So it looks like it wasn't exposed. – Jules Aug 3 '18 at 23:16

The MIPS architecture was introduced in 1981

Are you sure? To my information the first MIPS implementation was of 1985 with the R2000. Of course, the project did start before (in 1981), but so did others.

It is my understanding that VLIW architectures which also have an exposed pipeline, came later. Is that true?

As far as I can tell, yes.

Was MIPS really the first one?

Not really. For (modern) microprocessors Berkeley RISC I (the foundation of later SPARC) was 2-3 years ahead of MIPS, as their first working chips came in 1982. Berkeley RISC did not only coin the name RISC (and vanished somewhat behind after it became the standard term), but also featured a branch delay slot exposing the pipeline when branches where about. Here the compiler (or programmer) would place the last instruction to be done before a branch is taken after that branch.

But then there are minis, especially the IBM 801 (*1), which was defined in 1976. It had it's first working implementation in 1978, first commercial usage in 1980 and first single chip implementation (as ROMP) in 1981 (*2). Looking at their 1976 overview paper shows that they already incorporated almost every aspect what got 'invented' half a decade later as RISC. Including a separate set of branch instructions, called branch and execute (*3), where the next instruction in sequence after a branch will be executed anyway - today called a branch delay slot.

As of my understanding that makes the 801 implementation of 1980 the first.

*1 - It's debatable if that architecture really is a mini, as it is not only very /370ish, but also has been used as microcode engine for /370 implementations.

*2 - Fodder for what-if-freaks: What if IBM had used in 1981 their own 32 bit ROMP instead of Intel's 8088 for their PC (While also making the chip available to other manufacturers) :))

*3 - By having two sets of branch instructions they even avoided the need of inserting a NOP if there was no usable instruction - like with two successive branches. In reality it was more like a bit in the branch opcode telling if the next instruction is executed or a virtual NOP is inserted.

  • 3
    I recall the Berkeley RISC folks being keen on the idea that compiler technology had advanced to the point where it was okay to do things in the CPU architecture that might tend to trip up mere humans. Since most programming was being done in high-level languages, oddities like delay slots weren't going to discourage acceptance of an architecture. – fadden Aug 2 '18 at 17:43
  • 1
    The PDF file Tommy refers to mentions "early 1981" as the starting date of the project vs "1980" for Berkeley RISC. This makes it hard to figure out who was the first to come up with the idea of the delay slot. – Leo B. Aug 2 '18 at 18:43
  • 1
    @Raffzahn it's not only a good answer, it's the best answer here. It is correct. I apologise if you think I'm asking you to defend it. All I'm suggesting is an alternative prism for evaluating academic efforts, because they have a different objective. It's moot in any case, since your IBM answer usurps both other candidates. – Tommy Aug 2 '18 at 21:14
  • 1
    @Tommy No offense taken. And I do understand your argument here, in fact, personally I would even use IBM's 1978 setup of a discrete implementation purely for demonstartaion as the date, not one of the later ones, as this is on par with what we use to determinate some other first - the first day the Manchester Baby was operational, the first time the Mailüfterl operated and so on. These are clear milestones. As for our purpose I want to use a scale that can cover a wide range of machines, and to me that's whenever an implementation was operational. – Raffzahn Aug 2 '18 at 21:22
  • 2
    @fadden Of course the CPU folks would be keen on that idea. Meanwhile, the compiler folks were probably keen on the idea that CPU technology had advanced to the point where compilers didn't need to do so much work to make programs run fast... – user253751 Jan 10 at 13:59

"A Retrospective on MIPS: A Microprocessor Architecture", authored by those that designed MIPS from the beginning, states:

The absence of hardware interlocks (to delay an instruction if one of the operands wasn’t ready) was a tradeoff...


The team wanted to pick a name for the project that emphasized performance. About nine months earlier, the RISC project at UC Berkeley had started, so we needed a catchy acronym. “Million instructions per second” (MIPS) sounded right, given the project’s goals, but this metric was also known as the “meaningless indicator of processor speed.” So, we settled on “microprocessor without interlocked pipeline stages.”

So: (i) absence of interlocks is the reason for the exposed pipeline; (ii) was also the feature that gave the project its name; and (iii) in picking a name, they tried to avoid meaningless titles.

I'd therefore suggest that it's likely that the MIPS processor was the first processor with an exposed pipeline, on the grounds that it's the feature the project was named after — it was one of the things they considered to make their work unique.

  • 1
    Another interesting aspect of exposing the microarchitecture to the software is the mechanism of recovery from an internal interrupt like a page fault. The kernel may have to undo register modifications inherent in the addressing mode in order to re-execute the instruction if the hardware hasn't saved the initial register values and restored them before trapping. This saves logic but complicates interrupt handling. Figuring out what to undo may be guided by flags in the interrupt status or require decoding of the faulted instruction. I haven't come up with a meaningful question about this. – Leo B. Apr 6 '17 at 19:07

Interesting enough, that ARM, while not being the first, has kind of exposed pipeline. Specifically, ARMv3 32bit instructions that use contents of R15 aka PC, always have it incremented by 8 from the address of the instruction. In earliest ARM architecture revisions (like the one used in ARM7TDMI or earlier) that probably was an exposure of pipeline (in a way), but later certainly became just a feature emulated for compatibility.

  • From that point of view, PDP-11 exhibited a similar level of pipeline exposure. – Leo B. Aug 2 '18 at 18:26
  • @LeoB.: On the PDP-11, R7 holds the address of the next instruction. On the ARM, it holds an address 4 beyond that which unfortunately, precludes the use of PDP-11-style "immediate" addressing [since one would need an addressing mode that fetches the byte at [R15,#-4], while loading R15 with the value it already holds (writing R15 prevents the execution of the instructions at [old R15,#-4]). One could perhaps use [R15,#4]! addressing mode [post-increment, like the PDP-11] in 32-bit ARM mode, but that would require inserting an unused word between the load and the immediate value. – supercat Aug 6 '18 at 16:06
  • @supercat I see. My point is that these details expose not the pipeline but the microprogram. The famous PDP-11 backwards-self-replicating instruction 012727 would not have worked with a different microprogram. – Leo B. Aug 6 '18 at 19:23
  • ARM7TDMI (taken as an example) has 3-stage pipeline and PC+8 paradigm fits nicely with the pipeline: while the instruction that addresses through PC passes from fetch to execute stage, PC increments twice (as new instructions fetch through) and holds PC+8 value. In contrary, PDP-11 has neither prefetching nor pipelining and bothering with PC after the instruction fetched and has started execution shows exactly +2 increment. – lvd Aug 7 '18 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.