Re: Linux Kernel Microcode Question

[Timothy Miller <miller@techsource.com>]

Tigran Aivazian wrote:
> On Mon, 22 Mar 2004, Timothy Miller wrote:
> 
>>I don't see anything wrong with what he said.  As I understand it,
>>Pentium 4 CPUs don't use microcode for much of anything.  If an
>>instruction which was done entirely in dedicated hardware was buggy, and
>>it's replaced by microcode, then it will most certainly be slower.
>>
>>You seem to have missed where David used terms like "theoretically
>>possible" and "an operation".
> 
> 
> No, that is not what he said and that (what you say) is certainly wrong,
> namely this bit:
> 
>   If an instruction which was done entirely in dedicated hardware was
>   buggy, and it's replaced by microcode, then it will most certainly be
>   slower.
> 
> All instructions are done by means of microcode of some sort, i.e. the
> instructions are "compiled" as they are executed into a more primitive
> instruction set (called "microcode" or "u-code"). If a buggy instruction
> (or rather the sequence of microcode which corresponds to it) is replaced
> by a fixed version (i.e. by some other sequence of microcode) then there
> is no reason to say that the result will "most certainly be slower". For
> some bugs the fix runs faster than the broken code, for others it may be
> slower --- there is no way to tell apriori that it will always be slower.
> 
> Do you understand now?

What you're describing is not microcode in the traditional sense. 
Traditionally, microcode is a program store in the processor, and 
machine instructions cause the CPU to start executing micro instructions 
from that program store.  The Pentium 4 doesn't operate that way.

On the other hand, it would make sense to have some of the instruction 
decode being done using lookup tables, but the complexity of the x86 
instruction set is such that it can't all be done that way.