From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Chris Wedgwood <cw@f00f.org>
Cc: "Nakajima, Jun" <jun.nakajima@intel.com>,
richard.brunner@amd.com, linux-kernel@vger.kernel.org
Subject: Re: Intel vs AMD64
Date: Thu, 26 Feb 2004 09:35:16 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.53.0402260913300.32691@chaos> (raw)
In-Reply-To: <20040226133959.GA19254@dingdong.cryptoapps.com>
On Thu, 26 Feb 2004, Chris Wedgwood wrote:
> On Wed, Feb 25, 2004 at 09:32:08PM -0800, Nakajima, Jun wrote:
>
> > Yes, "implementation specific" is one of the differences between
> > IA-32e and AMD64, i.e. that behavior is architecturally defined on
> > AMD64, but on IA-32e (as I posted):
>
> > Near branch with 66H prefix:
> > As documented in PRM the behavior is implementation specific and
> > should avoid using 66H prefix on near branches.
>
>
> Not that it really matters that much --- but I'm curious to know why
> Intel made this decision?
>
> It seems really dumb to make such differences when Intel is already
> sorely lagging behind their competitor here, I would think given the
> circumstances Intel would try to be as compatible as possible on all
> fronts.
>
> I'd almost be nervous about getting an IA-32e CPU right now given that
> the AMD64 chips work just fine, have had lots of testing and there is
> plenty of code out there which is *known* to work reliably.
>
Errmm. The 0x66 prefix is used to change the implied register size
when using a register. It has nothing to do with a branch. It
can be used to cause the CPU to load the full-width of the
instruction pointer and the segment descriptor when transitioning
from 16-bit to 32-bit execution mode. This is an unconditional
jump immediate, instruction, not a branch. If it's used with a branch
instruction, near or far, the CPU should execute an "illegal operand
fault" (actually invalid opcode fault is the correct grammar since
neither AMD nor Intel make law).
Whether or not the CPU traps this invalid instruction is moot. No
compiler would emit junk like this and anybody horsing around with
an assembler deserves whatever they get, although you shouldn't
be able to smoke the CPU on a multi-user multitasking system because
it can be used as a DOS attack.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
next prev parent reply other threads:[~2004-02-26 14:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-26 5:32 Nakajima, Jun
2004-02-26 13:39 ` Chris Wedgwood
2004-02-26 14:35 ` Richard B. Johnson [this message]
2004-02-26 19:25 ` Timothy Miller
2004-02-26 19:46 ` Richard B. Johnson
2004-02-27 18:44 ` H. Peter Anvin
2004-02-26 19:18 ` Timothy Miller
2004-02-26 19:45 ` Scott Robert Ladd
2004-02-27 14:43 ` Timothy Miller
2004-03-03 17:34 ` Pavel Machek
[not found] <7F740D512C7C1046AB53446D37200173EA28A5@scsmsx402.sc.intel.com.suse.lists.linux.kernel>
[not found] ` <403E4681.20603@techsource.com.suse.lists.linux.kernel>
2004-02-26 20:17 ` Andi Kleen
2004-02-27 14:50 ` Timothy Miller
-- strict thread matches above, loose matches on Subject: below --
2004-02-26 4:28 richard.brunner
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.LNX.4.53.0402260913300.32691@chaos \
--to=root@chaos.analogic.com \
--cc=cw@f00f.org \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.brunner@amd.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
all inboxes | Powered by JetHome®