Intel Plans to Overhaul Chip Architecture

Carl Bialik from the WSJ writes "Intel is planning to announce an entirely new chip architecture later this month at the company's developer forum, the Wall Street Journal reports. The company isn't discussing details yet, but it's expected that Paul Otellini will discuss a 'technology foundation designed from scratch to improve energy efficiency and make it easier to add more than two processors.'"

Comments

Not a user-perceptable change.

[sbaker]

On NPR this morning, they mentioned that Intel had said that a typical PC user wouldn't notice any change as a result of this new architecture. So one presumes this means no major instruction set revisions or anything.

AMD's dual core offering better than Intel's

[Anonymous Coward]

According to various preliminary benchmarks from The Tech Report, Tom's Hardware and AnandTech, AMD's desktop dual-core chips are significantly better than Intel's dual-core desktop offerings in terms of performance and power consumption. This is partly due to the fact that the AMD solution has a better inter-core communication architecture and lower memory latency.

Meanwhile, Intel's desktop dual core chips seem to offer much more aggressive pricing at this time. AMD's lowest price dual core chip, the X2 4200 is almost twice as expensive as Intel's lowest cost dual core processor. However, an interview with three AMD execs on PCPerspective.com claims that "AMD would eventually have lower priced Athlon X2 processors via the waterfall effect in the future".

Semantics

[frankie]

The word "multiprocessor" should be "multicore". They're talking about 4 or 8 cores on a single CPU, which might be nice for blades but not so useful for a laptop or a gamer.

And of course, Macheads note the phrase "performance per watt".

It's called i860 :-)

[Jeremiah Cornelius]

The Itanium will be re-christened "Xeon failure edition".

Intel i860

The Intel i860 (also 80860, and code named N10) was a RISC microprocessor from Intel, first released in 1989. The i860 was (along with the i960) one of Intel's first attempts at an entirely new, high-end ISA since the failed Intel i432 from the 1980s. It was released with considerable fanfare, and obscured the release of the Intel i960 which many considered to be a better design. The i860 never achieved commercial success and the project was terminated in the late 1980s. No known applications of the chip survive and it is no longer manufactured.

Technical features

Intel i860 MicroprocessorThe i860 combined a number of features that were unique at the time, most notably its VLIW (Very Long Instruction Word) architecture and powerful support for high-speed floating point operations. The design mounted a 32-bit ALU along with a 64-bit FPU that was itself built in three parts, an adder, a multiplier, and a graphics processor. The system had separate pipelines for the ALU, adder and multiplier, and could hand off up to three instructions per clock.

One fairly unique feature of the i860 was that the pipelines into the functional units were program-accessible, requiring the compilers to carefully order instructions in the object code to keep the pipelines filled. This achieves some of the same goals as RISC microprocessor architectures, where complex microcode, a sort of on-the-fly compiler, was removed from the core of the CPU and placed in the compiler. This led to a simpler core, with more space available for other duties, but resulted in much larger code, with negative impact on cache hits, memory bandwidth, and overall system cost. As a result of its architecture, the i860 could run certain graphics and floating point algorithms with exceptionally high speed, but its performance in general-purpose applications suffered and it was difficult to program efficiently (see below).

All of the buses were 64-bits wide, or wider. The internal memory bus to the cache, for instance, was 128-bits wide. Both units had thirty-two 32-bit registers, but the FPU used its set as sixteen 64-bit registers. Instructions for the ALU were fetched two at a time to use the full external bus. Intel always referred to the design as the "i860 64-Bit Microprocessor".

The graphics unit was unique for the era. It was essentially a 64-bit integer unit using the FPU registers. It supported a number of commands for SIMD-like instructions in addition to basic 64-bit integer math. Experience with the i860 influenced the MMX functionality later added to Intel's Pentium processors.

Performance (problems)

Paper performance was impressive for a single-chip solution; however, real-world performance was anything but. One problem, perhaps unrecognized at the time, was that runtime code paths are difficult to predict, meaning that it becomes exceedingly difficult to properly order instructions at compile time. For instance, an instruction to add two numbers will take considerably longer if the data is not in the cache, yet there is no way for the programmer to know if it is or not. If you guess wrong the entire pipeline will stall, waiting for the data. The entire i860 design was based on the compiler efficiently handling this task, which proved almost impossible in practice. While theoretically capable of peaking at about 60MFLOPS for the XP versions, hand-coded assemblers managed to get only about up to 40MFLOPS, and most compilers had difficultly getting even 10.

Another serious problem was the lack of any solution to quickly handle context switching. The i860 had several pipelines (for the ALU and FPU parts) and an interrupt could spill them and need them all to be re-loaded. This took 62 cycles in the best case, and almost 2000 cycles in the worst. The latter is 1/20000th of a second, an eternity for a CPU. This largely eliminated the i860 as a general purpose CPU.

Versions, Applica

Re:It's called i860 :-)

[stripes]

Intel i860

OkiData had a short lived Unix workstation product line based around these. I used them for a while.

One fairly unique feature of the i860 was that the pipelines into the functional units were program-accessible, requiring the compilers to carefully order instructions in the object code to keep the pipelines filled.

Only the floating point pipeline was directly exposed. Your first two FMULADD got garbage as the result, the third got the result of the first FMULADD... I *think* it also had a mode with more conventional stalling if you tried to do a 2nd FMULADD before the first completed (or if you used the result register).

The i860 also had a mode where you it would execute two instructions per clock, but you had to pair one integer instruction with one floating point instruction in that mode (and the pairing was static, if you put two integer instructions in a row the CPU would fault with an illegal instruction fault).

Paper performance was impressive for a single-chip solution; however, real-world performance was anything but.

It outperformed it's contemparary SPARC and MIPS CPUs by a considrable margin in FP, and by a small margin in integer heavy code. It was competitave with the HP snake systems (HPPA). It predated the Alpha, and was badly outmatched when the Alpha finally came out.

One problem, perhaps unrecognized at the time, was that runtime code paths are difficult to predict, meaning that it becomes exceedingly difficult to properly order instructions at compile time. For instance, an instruction to add two numbers will take considerably longer if the data is not in the cache, yet there is no way for the programmer to know if it is or not. If you guess wrong the entire pipeline will stall, waiting for the data.

That was extremely common at the time. The best the contemporary CPUs had was the IBM ROMP (pre-IBM POWER!) that had register scoreboarding so it didn't take a stall until the result register was used. It wasn't until five to seven years later that out-of-order CPUs were commercially available (and I can't remember who did them first, maybe the TI SuperSPARC? Or was it the MIPS R8000?)

Another serious problem was the lack of any solution to quickly handle context switching. The i860 had several pipelines (for the ALU and FPU parts) and an interrupt could spill them and need them all to be re-loaded. This took 62 cycles in the best case, and almost 2000 cycles in the worst. The latter is 1/20000th of a second, an eternity for a CPU. This largely eliminated the i860 as a general purpose CPU.

It seemed of handling disk interrupts, mouse movement, and even the relatively tiny FIFO for SoundBlaster 16 audio out. Maybe this was more a problem in theory then in practice? Clearly the i860 never got far in the embedded space though, and this couldn't have possibly helped.

The i860 did see some use in the workstation world as a graphics accelerator. It was used, for instance, in the NeXTDimension, where it ran a cut-down version of the Mach kernel running a complete PostScript. In this role the i860 design worked considerably better, as the core program could be loaded into the cache and made entirely "predictable", allowing the compilers to get the ordering right. This sort of use slowly disappeared as well, as more general-purpose CPUs started to match the i860's performance, and Intel lost interest.

I think it was also used as part of the "geometry engine" on SGI's Reality Engine product. There were something like 4 per GE, and up to 4 GEs on a Reality Engine, which was pretty impressive in 1991ish, but other then having something like 196 bits of memory per pixel falls pretty far short of today's $100 graphics cards.

Re:Attempt to scare IBM

[AKAImBatman]

Itanium didn't kill Alpha/MIPS/Sun.

Yes it did. When the hype was at it peak, it was actually preventing companies (such as the one I was working at during that time) from looking into Sun solutions, and HP made its infamous decision to ditch the Alpha line of processors in favor of the upcoming Intanic line.

At that time, Sun machines held a reasonable partiy with Intel's offerings, and Alpha NT desktops simply flew. Pentium III (Coppermine) was still in the development phase, and SGI was barely hanging on thanks to their N64 and NT Workstation deals.