Slashdot Mirror
Upgrade Your Pentium's Microcode
BugBBQ wrote to us regarding a a recent Byte column which talks about BIOS Update, a feature that Intel has built into their chips since the Pentium Pro. One of the interesting parts is that there's no checking to see if a code update is legit, according to the article.
The P6 processors have microcode that you can change at runtime. However, these changes DO NOT GET SAVED ACCROSS POWER CYCLES . This is used by Intel to fix some errata in the shipping microprocessor. The way it is implemented, since it is not written permanently, the system BIOS has to write microcode updates to the CPU at boot time, on every reboot. This enables Intel to make revisions take effect with simple BIOS updates that everyone is used to. This was very interesting for me, as I had no idea that BIOS updates held such weight with the P6 family of processors!
/dev/microcode support for P6 processors. What this allows you to do is update your microcode on boot. Why would you want to do this? Intel issues new microcode updates to the BIOS writers. If you get your hands on new microcode before there is a full flashable BIOS revision available, this will allow you to install the new microcode at bootup, removing one layer of your dependency on your BIOS writer.
If you look at the PPro Processor Specification Update (the accompanying PDF), you will see that some of the erratum are marked as: "Workaround: It is possible for BIOS code to contain a workaround for this erratum." This indicates an erratum that can be fixed by microcode updates.
The advantage to having this is significant, in my opinion. You don't have to buy a new processor stepping to get erratum fixed. Granted, there will be plenty of erratum that can't be fixed with a microcode change, but this is at least a step in the right direction.
As was pointed out by another poster, Linux 2.4 has
Anyway, I think this shit is really cool, but not something I plan on using unless there is a serious errata found in my processor that can be fixed this way. It sounds like quite a bit of hastle for marginal benefit in most cases. However, its great that Linux provides us this option.
Anyone have any ideas about hacking microcode? I donno if Intel releases specs on it. Could be very interesting.
Using your sig line to advertise for friends is lame.
Now I can talk to the midichlorians who live inside my CPU...
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
As you step up abstraction levels, you begin to get into all sorts of possibilities for less than optimal performance, mainly because your code relise much more heavily on single-line commands that fire off larger blocks of less abstract code. The possibility for optimization comes in when coders can look at these layers of abstraction and find more efficient possibilities, either by selecting different procedure calls or by stepping down to the next lowest layer of abstraction (i.e. putting assembler code into a C program to dump graphics more quickly to the screen buffer.) Basically, the higher up the abstraction level you get, the more different coding paths you can take to get the same end result. Finding a more efficient one requires a bit of work, yes, but there are enough other possible routes that the programmer didn't follow that you can probably find one way around it, even if all it is is re-writing the higher level code in a lower level chunk to skip over a few cycles.
With microcode, though, there are no additional layers of abstraction between the code and the processor. Microcode is as close as you can get to the chip before you break out your oscilloscope and multiplexer. The only way you can improve microcode is by actually finding a faster/better way of sending the command through the chip; though this is mathematically less challenging than trying to optimize at higher levels of abstraction, it also means that the engineers that wrote the microcode in the first place had a lot fewer possibilities to consider than they would have had they been writing C code. You can't "drop down" to the next layer of abstraction with microcode, either, so that entire family of optimization tricks can't even be applied to microcode.
Finally, upgrading one's microcode works only within a very limited scope. You may find that Upgrade A does good things for your machine, because you run a particular mathematical operation over and over, but for your friend's machine, it actually degrades performance, because of a pipeline trick in Upgrade A that was designed specifically to speed your particular mathematical operation. A TCP/IP upgrade, on the other hand, relies on the lower abstraction layers to handle the finer points of chip tuning, making it's performance improvements much more likely to be universally applicable. (Note, too, that by stepping down to lower abstraction layers to improve performance, one runs the risk of creating greater usage-specific issues, much like in the example above.)
To successfully upgrade something like the TCP/IP stack, you need some pretty heavy understanding of the protocol, language, and current implementation to succeed in upgrading it. To improve the microcode, you need nothing short of a truly pedantic understanding of the Pentium architecture itself. There's a big leap in skill and opportunity between these two. If there are even a handful of non-Intel developers out there who feel comfortable enough tackling this problem, I'd still be surprised if they managed to yield a universally-applicable microcode patch for the Pentium. It would certainly be no small feat.
But again, I do ask that if somebody manages to do it, pretty please, let me know...
Obliteracy: Words with explosions
1. Microcode viruses are highly improbable. The code is loaded by BIOS without checks, but the processor checks the code and won't use it unless it is valid. Further, the update is flushed out by every RESET.
2. There is no benefit to being able to patch microcode for performance, despite what this article states. There is only one decoder (out of three) on the P6 which will load the micro-ops from the patch area. So you get a third of your possible micro-op issue rate. About the only thing microops can do that you cant from macroops is 3 operand instructions (and a few more scratch registers, but those aren't handled by the shadow register table, so you'd have to be very careful).
3. update space is TINY, especially for the size of the microops themselves. There probably isn't enough space to implement a complicated algorithm even if someone wanted to. Most updates contain less than 10 microops per problem.
4. To do an update for a particular stepping would require the complete microcode listing for that stepping, because there is no jump table, just absolute offsets into the internal ROM. These are different by stepping, and of course family.
5. Reverse engineering microcode, aside from being a waste of time, isn't going to be particularly easy. Determining the decryption where the plaintext is just as incomprehensible is a complex task, and there is no observability except whether or not the patch got loaded.
6. This is not "secret", although hard to obtain now I suppose. The "P6 BIOS WRITERS GUIDE", which used to be available from an FTP site at Intel, had the complete mechanism for loading updates. Windows versions have some form of a microcode loader, to account for defunct bios vendors..
Quick show of hands here: who here has the skills, time and patience to analyze the performance of your computer and actually find a way to improve the microcode performance on their computer? Hell, that's one step removed from digging out your soldering iron and microsocpe to 'clean up' some of those slow pathways on your chip.*
Even with the complexity of Pentium chips, the odds of being able to successfully perform an "upgrade" of your Pentium's microcode is slim to none. Microcode is designed to be hella-fast, by people who do happen to know what they're doing and have access to every technical spec they could want on the chip.
Despite your potentially vast knowledge of microcode, the complexity of the Pentium chip is sure to present some major headaches, even if you have worked out the theory of what you need to do to improve the code.
Unless you have a very specific set of tasks you run on your computer (and then know exactly what changes you need to make to further improve on the existing microcode,) the odds of your writing a microcode upgrade that actually improves overall system performance is pretty low.
Having said that, do send me a copy if you manage to do it...
* BTW, this doesn't work. Learned that one the hard way... *grin*
Obliteracy: Words with explosions