[lkml]   [2004]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux Kernel Microcode Question

Tigran Aivazian wrote:
> On Thu, 18 Mar 2004, David Schwartz wrote:
>> It is at least theoeretically possible that a microcode update might cause
>>an operation that's normally done very quickly (in dedicated hardware) to be
>>done by a slower path (microcode operations) to fix a bug in the dedicated
> Did you dream that up or did you read it somewhere? If the latter, where?
> All operations are done by "dedicated hardware" and microcode DOES modify
> that hardware, or rather the way instructions are "digested". So, applying
> microcode doesn't make anything slower per se, it's just replacing one
> code sequence with another code sequence. If a new code happens to be
> slower than the old one then of course the result will be slower, but the
> reverse is also true. When you fix a bug in a particular software why
> should a bugfix be apriori slower than the original code? Think about it.
> So please do not spread misinformation that applying microcode makes
> something slower. If anything, it should make things faster, as long as
> the guys at Intel are writing the correct (micro)code.

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".

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:01    [W:0.070 / U:7.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site