From: Andi Kleen <ak@muc.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Ulrich Drepper <drepper@redhat.com>, Andi Kleen <ak@muc.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Runtime memory barrier patching
Date: Tue, 22 Apr 2003 00:45:46 +0200 [thread overview]
Message-ID: <20030421224546.GA14845@averell> (raw)
In-Reply-To: <Pine.LNX.4.44.0304211502300.17938-100000@home.transmeta.com>
On Tue, Apr 22, 2003 at 12:05:51AM +0200, Linus Torvalds wrote:
> I would not be surprised if both AMD and Intel are playing some
> "benchmarking games" by trying to select nop's that work badly for the
> other side, and then showing how _their_ new CPU's are so much better by
> having the compilers emit the "preferred" no-ops.
>
> But maybe I'm just too cynical. And I do suspect the Hammer optimization
> guide was meant for the 64-bit mode only, because I'm pretty certain even
> AMD does badly on prefixes at least in older CPU generations.
Yes, you're right. The Athlon recommendation is pretty complicated
(they have different versions for different registers to avoid lengthening
dependency chains), but it uses different two byte nops.
They explicitely say that it works well on "other CPUs" too which
likely means Intel.
Basically it is:
NOP2_EAX TEXTEQU <DB 08Bh,0C0h> ;MOV EAX, EAX
NOP3_EAX TEXTEQU <DB 08Dh,004h,020h> ;LEA EAX, [EAX]
NOP4_EAX TEXTEQU <DB 08Dh,044h,020h,000h> ;LEA EAX, [EAX+00]
;LEA EAX, [EAX+00];NOP
NOP5_EAX TEXTEQU <DB 08Dh,044h,020h,000h,090h>
;LEA EAX, [EAX+00000000]
NOP6_EAX TEXTEQU <DB 08Dh,080h,0,0,0,0>
;LEA EAX, [EAX*1+00000000]
NOP7_EAX TEXTEQU <DB 08Dh,004h,005h,0,0,0,0>
;LEA EAX, [EAX*1+00000000] ;NOP
NOP8_EAX TEXTEQU <DB 08Dh,004h,005h,0,0,0,0,90h>
;JMP
NOP9 TEXTEQU <DB 0EBh,007h,90h,90h,90h,90h,90h,90h,90h>
(+ the same for all other GPRs). Someone must have too much time
when documenting this ;)
But I'm not gonna resubmit with that unless if you insist on it...
-Andi
next prev parent reply other threads:[~2003-04-21 22:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-21 19:27 [PATCH] Runtime memory barrier patching Andi Kleen
2003-04-21 19:59 ` Linus Torvalds
2003-04-21 20:53 ` Andi Kleen
2003-04-21 21:04 ` Linus Torvalds
2003-04-21 21:43 ` Ulrich Drepper
2003-04-21 22:05 ` Linus Torvalds
2003-04-21 22:45 ` Andi Kleen [this message]
2003-04-21 22:11 ` Andi Kleen
2003-04-21 22:23 ` Linus Torvalds
2003-04-21 22:59 ` Andi Kleen
2003-04-21 23:35 ` Jamie Lokier
2003-04-21 23:46 ` Andi Kleen
2003-04-21 23:56 ` [PATCH] Runtime memory barrier patching II Andi Kleen
2003-04-21 23:57 ` [PATCH] Runtime memory barrier patching Jamie Lokier
2003-04-22 0:06 ` Linus Torvalds
2003-04-22 0:13 ` Jamie Lokier
-- strict thread matches above, loose matches on Subject: below --
2003-04-21 23:41 Chuck Ebbert
2003-04-22 0:04 ` Jamie Lokier
[not found] <200304220111.h3M1BEp5004047@hera.kernel.org>
2003-04-22 8:43 ` Arjan van de Ven
2003-04-22 11:18 ` Andi Kleen
2003-04-22 16:11 ` Dave Jones
2003-04-22 10:12 Chuck Ebbert
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=20030421224546.GA14845@averell \
--to=ak@muc.de \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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