3 ms·

Reminds me of this question on Super User: How does a CPU 'know' what commands and instructions actually mean? http://superuser.com/questions/307116/how-does-a-

Reminds me of this question on Super User: How does a CPU 'know' what commands and instructions actually mean? http://superuser.com/questions/307116/how-does-a-cpu-know-what-commands-and-instructions-actually-mean http://superuser.com/questions/307116/how-does-a-cpu-know-wh... Microcode in its most basic form is just a big look-up table (could be nested if word size is limited) containing the electrical signals for a particular instruction, and a new address to "jump" to (either a subsequent micro-operation, or jump back to the "fetch" micro-op). Electrically, however, there's no difference between a microcoded and hard-wired CPU - they both fetch and execute sequences of instructions. Of course, there's an obvious advantage to the microcoded approach: your instruction set gets uploaded to your hardware in a ROM! You can change the operation of instructions after the hardware is made, make custom sequences of instructions, or even fix microcode bugs (while uncommon, there have been cases in the past).

tjoff 14y ago
Uncommon? I'd venture to say that all desktop architectures have known bugs. Some are just documented, some are fixed by microcode, some require work arounds in software "or" compilers. Example: (core i7, may 2011) http://download.intel.com/design/processor/specupdt/320836.pdf http://download.intel.com/design/processor/specupdt/320836.p... BIOS updates often contain bugfixes for your CPU.
- dfc 14y ago
  I don't like waiting for BIOS vendors to package cpu firmware updates and I don't like to update the BIOS unless I have to. If you are running debian just install (amd64|intel)-microcode[1]. The package provides the most recent microcode updates from the CPU vendor and updates the microcode on boot. [1] http://lists.debian.org/debian-user/2012/11/msg00193.html http://lists.debian.org/debian-user/2012/11/msg00193.html
cynwoody 14y ago
> You can change the operation of instructions after the hardware is made, make custom sequences of instructions, or even fix microcode bugs (while uncommon, there have been cases in the past). I am reminded of the famous Intel Pentium FDIV bug (1994). Seems they had implemented a new and improved floating point division algorithm. It needed only half the cycles of the previous algorithm. The new algorithm used a 1066-cell lookup table to find partial quotients used in the calculation. Unfortunately, due to a screwup, five of the cells were left blank when the ROM was loaded. This led to obscure errors in the results, which went unnoticed until many thousands of chips were in customers' hands. At that point, Intel had a massively embarrassing recall on their hands. http://engineeringfailures.org/?p=466 http://engineeringfailures.org/?p=466 http://www.trnicely.net/pentbug/pentbug.html http://www.trnicely.net/pentbug/pentbug.html

tjoff 14y ago

Uncommon? I'd venture to say that all desktop architectures have known bugs. Some are just documented, some are fixed by microcode, some require work arounds in software "or" compilers. Example: (core i7, may 2011) http://download.intel.com/design/processor/specupdt/320836.pdf http://download.intel.com/design/processor/specupdt/320836.p... BIOS updates often contain bugfixes for your CPU.

dfc 14y ago
I don't like waiting for BIOS vendors to package cpu firmware updates and I don't like to update the BIOS unless I have to. If you are running debian just install (amd64|intel)-microcode[1]. The package provides the most recent microcode updates from the CPU vendor and updates the microcode on boot. [1] http://lists.debian.org/debian-user/2012/11/msg00193.html http://lists.debian.org/debian-user/2012/11/msg00193.html

cynwoody 14y ago

> You can change the operation of instructions after the hardware is made, make custom sequences of instructions, or even fix microcode bugs (while uncommon, there have been cases in the past). I am reminded of the famous Intel Pentium FDIV bug (1994). Seems they had implemented a new and improved floating point division algorithm. It needed only half the cycles of the previous algorithm. The new algorithm used a 1066-cell lookup table to find partial quotients used in the calculation. Unfortunately, due to a screwup, five of the cells were left blank when the ROM was loaded. This led to obscure errors in the results, which went unnoticed until many thousands of chips were in customers' hands. At that point, Intel had a massively embarrassing recall on their hands. http://engineeringfailures.org/?p=466 http://engineeringfailures.org/?p=466 http://www.trnicely.net/pentbug/pentbug.html http://www.trnicely.net/pentbug/pentbug.html