mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tigran Aivazian <tigran@veritas.com>
To: Timothy Miller <miller@techsource.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 07:40:34 -0800 (PST)	[thread overview]
Message-ID: <Pine.GSO.4.58.0403220736480.8694@south.veritas.com> (raw)
In-Reply-To: <405F0B8D.8040408@techsource.com>

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?

Kind regards
Tigran

  reply	other threads:[~2004-03-22 15:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-18 16:40 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
2004-03-22 15:40         ` Tigran Aivazian [this message]
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
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=Pine.GSO.4.58.0403220736480.8694@south.veritas.com \
    --to=tigran@veritas.com \
    --cc=davids@webmaster.com \
    --cc=jpiszcz@hotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miller@techsource.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

Powered by JetHome