10

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.

6
  • 3
    I agree with @Stephen. So that seems to mean that this question is really just asking for an exhaustive list of all non-Intel/AMD x86 CPUs. Is that really on-topic for a Stack Exchange site? Feb 26 at 7:54
  • 4
    @SingleMalt kudos on trying to address the issues with your question! Feb 26 at 8:48
  • 1
    @StephenKitt I amended this to be about one initially unique x86 processor feature that also wanted to know more about. Will bear this in mind for future questions, those list based questions are tempting to write! Feb 26 at 8:48
  • 4
    Great job improving the question! There is no longer a need to close the question.
    – DrSheldon
    Feb 26 at 23:11
  • 1
    The only thing special with the NexGen was that it could bypass the x86 decoding stage and feed the units directly with its "RISC" instruction set. I've never seen it demonstrated but read that from different sources at the time. Mar 1 at 10:41
10

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.

8
  • 1
    re your point #2, it seems worth commenting that one of the major contributions of S/360 to the industry was to separate out in our minds the concepts of "architecture" (as seen by programmer) from "implementation". Feb 26 at 12:46
  • @another-dave Yes. If I had to pick a single most important invention of Amdahl, then it would be a hard tie between packing 8 bit in a byte and defining the user visible architecture complete independent of the underlaying implementation. Where even way later and intended 'cleaner' architectures tried to simplify and incooperate 'natural' side effects, he (they) didn't cave in at all.
    – Raffzahn
    Feb 26 at 18:29
  • 1
    I used a 9730 (or possibly a close successor) for awhile at Rational (developing an Ada compiler for a bare-metal 370). It was fascinating to watch it get installed in our raised-floor computer room: A guy came out and installed it and powered it up. Took an afternoon. Then another guy came out and installed the software. Took him nearly a week, full 8 hr days. I couldn't figure out how they were going to make money on these cheap "departmental" machines if installing each one took an IBM system engineer a week ... I still don't know the answer to that.
    – davidbak
    Feb 27 at 22:50
  • 2
    The information from the IBM 801 link is interesting (and perhaps not that well known) about how it demonstrated the value of the RISC concept and how the main researcher was awarded the Turing award in 1997. Feb 27 at 23:08
  • The Transmeta Crusoe and Efficeon CPUs take x86 binaries as data, and run software (called Code Morphing Software) which produces VLIW instructions which they then run. There is a tradeoff since you gain efficiency by having a RISC processor and the VLIW instructions, but there is a cost of having to run the CMS software together with the translated x86 program. Although they are RISC processors they can only run x86 programs as a system with the CMS software that does translation from native x86 to efficient VLIWs. Is this roughly correct? Mar 2 at 20:58
8

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".

4

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.

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.