Intel's microcode update? What was that about?

[CoW]8(0)]

I'm having trouble finding out the specific details of Intel's microcode update awhile back. Did it affect certain revisions? Or did it affect all C2D processors?

And what exactly did the microcode fix? Microsoft only described it as 'uncommon crashes'.

 

[__Miguel_]

In (very) simple terms, as I don't really know the whole whatnots of the thing, microcodes work something like this:

Every CPU has bugs, no exceptions. Those bugs are like software bugs, they produce weird or wrong results when some conditions are met. There are really really bad bugs, which require a whole reconstruction of the core (those are pre-ES CPUs, used to test the architecture, and make changes, and don't reach the market); and then there are semi-important bugs, which happen in very few cases, and all but a handfull of people would be expected to find when using the CPU series.

One example of this last kind of bugs would be the infamous early x86 bugs (those that would result in odd results within Excel). There are two ways of addressing CPU bugs: new CPU revisions (called steppings), which basically "kill" the problem at the root, because a new CPU series is created with the bugs corrected; and CPU microcode updates.

These are destined to the existing CPUs on the market, and basically they tell the CPU itself something like "you know, when these conditions are met, ignore your result and hand out this other one". Of course, you can make this CPU microcode available either through the BIOS, and the BIOS uploads it at startup; or you can go the driver way, this time being the OS itself that changes the results the CPU outputs.

Theoretically, CPU microcode updates can have both a performance boost or performance hit. The vast majority of the times, however, they have a performance hit. The good thing is, that performance hit is not only negligible but also very uncommon (since it's a rare occurence, anyway).

Usually, you don't have to be worried about microcode updates - which, by the way, are WAY more frequent than you'd think, and EVERY CPU is affected, sooner or later. If a severe bug is found - not likely -, Intel will probably offer to change the CPUs (they have done that in the past once, mind you).

Hope this helps.

Cheers.

Miguel

 

[CoW]8(0)]

Thanks....I was more or less curios about microcode updates that were performance gains or perhaps increased stability in overclocking.

 

[__Miguel_]

Thanks....I was more or less curios about microcode updates that were performance gains or perhaps increased stability in overclocking.

AFAIK, OC is not a cause of probable microcode updates. General stability, on the other hand, may be a cause for a microcode update (those "uncommon crashes" you talked about).

Increased OC performance usually comes from new CPU steppings, where new materials or manufacturing techniques may be used, and may even result in lowered power consumption. That happens, for example, on G0 stepping CPUs. However, this isn't the norm, and sometimes there are downsides...

Performance gains are also not usually the main concern when creating a new microcode update. Although, that CAN happen, as a "side effect", mostly. Just don't count on it... lol

Cheers.

Miguel

 

[CoW]8(0)]

I was thinking a microcode update would allow the CPU to possibly handle exceptions better or have more reliable ways of executing specific instructions. And reliability might translate to possibly better stability for an OC.

 

[__Miguel_]

I guess that can also happen, but that kind of updates has limited room to appear; and even if it does appear, the performance and reliability gains wouln't be something earth-shattering.

CPUs are already extremely streamlined, and there are not that many ways to execute something inside it... hehe If/when some new ways to execute code are found - along with other improvements -, they are "compiled" on another CPU family. Just look at Penryn, for one: those are 45nm C2Ds with added features and optimizations...

And, even more radical different ways of doing things (like moving the memory controller to the CPU die) result in a completely different architechture - Like Nehalem-based CPUs, due starting sometime next year.

Cheers.

Miguel