From: Timothy Miller <miller@techsource.com>
To: Tigran Aivazian <tigran@veritas.com>
Cc: David Schwartz <davids@webmaster.com>,
Justin Piszcz <jpiszcz@hotmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: Linux Kernel Microcode Question
Date: Mon, 22 Mar 2004 10:51:41 -0500 [thread overview]
Message-ID: <405F0B8D.8040408@techsource.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0403191721110.3892-100000@einstein.homenet>
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
>>hardware
>
>
> 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".
next prev parent reply other threads:[~2004-03-22 15:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-18 16:40 Linux Kernel Microcode Question Justin Piszcz
2004-03-18 16:59 ` Dave Jones
2004-03-18 17:13 ` David Schwartz
2004-03-19 17:27 ` Tigran Aivazian
2004-03-19 23:16 ` David Schwartz
2004-03-22 11:55 ` Tigran Aivazian
2004-03-22 15:51 ` Timothy Miller [this message]
2004-03-22 15:40 ` Tigran Aivazian
2004-03-22 16:19 ` Timothy Miller
2004-03-22 19:14 ` David Schwartz
2004-03-22 20:58 ` John Bradford
2004-03-22 16:13 ` Richard B. Johnson
2004-03-22 16:51 ` Timothy Miller
2004-03-22 17:14 ` Richard B. Johnson
2004-03-18 16:59 ` Richard B. Johnson
2004-03-18 17:07 ` Robert Love
2004-03-19 0:16 ` Bill Davidsen
2004-03-19 12:56 ` Richard B. Johnson
2004-03-18 22:20 ` Tigran Aivazian
-- strict thread matches above, loose matches on Subject: below --
2004-03-18 17:19 Nakajima, Jun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=405F0B8D.8040408@techsource.com \
--to=miller@techsource.com \
--cc=davids@webmaster.com \
--cc=jpiszcz@hotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tigran@veritas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox