The NexGen's x86 internal RISC architecture

Question

NexGen was best known for the unique implementation of the x86 architecture in its processors. NexGen's CPUs were designed very differently from other processors based on the x86 instruction set at the time: the processor would translate code designed to run on the traditionally CISC-based x86 architecture to run on the chip's internal RISC architecture. The architecture was used in later AMD chips such as the K6, and to an extent most x86 processors today implement a "hybrid" architecture similar to those used in NexGen's processors (https://en.wikipedia.org/wiki/NexGen).

How does this “internal RISC architecture” work and why is it so successful to be widely used today? Did the concept originate from NexGen or was it already being used in other non-x86 CISC processors? Further was this NexGen’s main design goal, or just one of many?

Edit to give extra context around the answers. The P5 Pentium was the first superscalar x86 processor; the Nx586 [1994], P6 Pentium Pro [1995] and AMD K5 [1996, based on a 29k RISC processor with an x86 decoding front end] were among the first designs which decode x86-instructions asynchronously into dynamic microcode-like micro-op sequences prior to actual execution on a superscalar microarchitecture; this opened up for dynamic scheduling of buffered partial instructions and enabled more parallelism to be extracted compared to the more rigid methods used in the simpler P5 Pentium; it also simplified speculative execution and allowed higher clock frequencies compared to designs such as the advanced Cyrix 6x86. [Wikipedia Superscalar Processor]. Thus although the K6 (1997) was a different design created by NexGen engineers, AMD had already implemented an x86 processor with RISC-like internals in the K5.

Answer 1

Like so often naming is also about giving a spin — to start with calling it RISC.

How does this “internal RISC architecture” work and why is it so successful to be widely used today?

By translating one instruction set on the fly into another, usually simpler, one and feeding that into the 'real' CPU. Most successfully if that CPU is superscalar as well.

Did the concept originate from NexGen or was it already being used in other non-x86 CISC processors?

In principle the whole translation idea isn't much different from classic micro programming. Here as well each user visible instruction gets replaced by one or more internal instructions executed by the 'real' machine.

This in turn links it with the very start of RISC as we know it, the IBM 801 project. Its goal (after some search for a target) was to improve /370 (*1) performance by translating the /370 CISC instructions on the fly into a less complex instruction stream of a RISC machine, which in turn was modelled to support the way the /370 operates (*2).

While the 801 originates already in the mid 1970s, and for sure it wasn't long until the full works to translate /370 on the fly to 801 code, the most solid (*3) answer to the question about prior machines would be:

The IBM 9370

Interestingly the 9370 was first available the very same year (1986) NexGen started their company to apply the same principles to a 386 design.

Further was this NexGen’s main design goal, or just one of many?

I guess design goals were rather competitive performance and price, but yes, the internal RISC structure was their take on these goals.

---

*1 – Within this context /370 is synonym for all of the line, /360, /370, /390, ...

*2 – Noteworthy here is that the /370 ISA was always only a user side definition. Internally these mainframes have used all kinds of CPU designs and instruction sets. This was done to enable wide range of CPUs, from 'economic' (read cheap but slow) to high performance.

*3 – There might be more before, as it's a blurry line between microcode and CISC to RISC translation, made up by many not well defined little differences, covered by buzzwords and marketing.

Of all designs around that idea, only Transmeta's CPUs clearly is a RISC CPU — for all others it's about internal mechanics that can be called many names.

Answer 2

Very rough answer, after looking at the Hardware architecture and some other pages linked from the Wikipedia page:

How does this “internal RISC architecture” work

An instruction is decoded and split up into several "micro-instructions", which are then scheduled an executed on "functional units", e.g. an address unit, two integer units, and a floating-point unit for the Nx586.

and why is it so successful to be widely used today?

I guess the best answer I can give for "why" is that it turned out to work well.

Did the concept originate from NexGen

It has been around for a long time. The Cray-1 (1975) already used functional units and a pipelined schedule for instructions. Though this was for a completely different ISA, and the "translation to RISC microinstructions" idea wasn't present.

Further was this NexGen’s main design goal, or just one of many?

According to this page,

The race was on for the next generation CPU after the 486. Intel was very busy with the design of the Pentium. Other companies like Cyrix and AMD were also designing their next generation CPU's. They were however lagging behind. Compaq was the largest PC manufacturer at that time and it wanted a real alternative to Intel or maybe just a way to get the pressure on Intel. So they financially backed a new promising CPU design company : NexGen microsystems.

Nexgen Inc. was founded by Thampy Thomas in 1986. Its goal at that time was to design a 386 competitor, not an Intel clone but a new x86 compatible design. Apparently from the start the design would incorporate CISC and RISC elements.

[...]

Unfortunately the team faced many issues and delays. For instance, one of the first designs was so large that it ended up in 8 PGA's the size of a standard 386. By the time the design was ready, the 386 was history, the 486 was the CPU to have and the next generation chips were already on the drawing tables at Intel, AMD and Cyrix.

Finally after eight years of hard working on the CPU with the codename F86, Nexgen announced to the world the Nx586 in March 1994.

So again the answer seems to be "it just turned out this way".

Answer 3

Your question has several components, but I'll just comment on two of them

Did the concept originate from NexGen or was it already being used in other non-x86 CISC processors?

The basic concept is "ancient" and pre-dates x86 or the term RISC. Computers even in the 1950's and 1960's had microcode for implementing complex instructions in what we might now call firmware. The early machines were programmed directly in assembly, so they needed to expose a CISC-like ISA with lots of functionality to the assembly programmer. (Operating systems as we understand them today hadn't fully been invented yet, so you couldn't just dlopen a dynamic library with higher level functionality. Even the biggest systems of the time were more like working on bare embedded hardware. If you wanted functionality, it was either in the hardware, or you wrote it in assembly yourself as a part of the specific program you were working on.)

But the technology for actually implementing a processor was still crude with transistor budgets (or vacuum tube budgets in early machines!) being very low by modern standards, so you couldn't make a machine with millions of vacuum tubes to implement a separate circuit to implement every desirable instruction. Thus the execution units were very RISC-like. (Though the terms CISC and RISC hadn't been coined yet, and the application of them of wildly debatable.) Microcode was used to implement the more complex instructions in terms of what we'd now call the hardware's micro-ops.

why is it so successful to be widely used today?

It was sort of inevitable. The original x86 ISA was initially driven by what was practical to implement in the late 70's and early 80's. Over the course of decades the technology for implementing the guts of a processor changed. So in order to preserve backwards compatibility of the public ISA, there was always going to be some sort of conceptual mismatch between the ISA and the implementation over time. If you have a simple RISC-inspired core, you can expose a more complicated public interface with stuff like microcode. But if you want to make the actual execution units some sort of Mega-CISCy thing with massively more complicated conceptual instructions, you have no way to really expose the more complicated instructions in terms of simpler ones.

Like for a simplified example, if you have a multiply instruction, you can implement it internally in terms of a bunch of add operations.

But if you implement a multiply operation, you can't expose it in an ISA that only has Add instructions.

So the trend was always going to be that you could break down complex instructions into implementations based on simpler operations, but not the other way around. Of course, the public ISA has grown massively more complex over time as well -- it's not as if a 90's x86 chip only implemented the 8086 ISA. So there is an equal and opposite push to make the guts more complicated over time as the public ISA grows. (And to grow the public ISA as you can implement more complicated guts.) But in terms of existing instructions, there's always a limit to how complex you can make the implementation, so at least some of them will tend to wind up being implemented in terms of simpler steps. So if civilization gets bombed back to the stone age and computers are reinvented from scratch, the basic concept of cracking complex instructions into simpler to implement operations will eventually get reinvented.