From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [Q] Implementation of spin_lock on i386: why "rep;nop" ?
Date: 17 Sep 2001 12:47:27 -0700 [thread overview]
Message-ID: <9o5k0f$25d$1@cesium.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.31.0109171725140.26090-100000@sisley.ri.silicomp.fr> <E15j2BM-0007WU-00@the-village.bc.nu>
Followup to: <E15j2BM-0007WU-00@the-village.bc.nu>
By author: Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
>
> > The "rep;nop" line looks dubious, since the IA-32 programmer's manual from
> > Intel (year 2001) mentions that the behaviour of REP is undefined when it
> > is not used with string opcodes. BTW, according to the same manual, REP is
> > supposed to modify ecx, but it looks like is is not the case here... which
> > is fortunate, since ecx is never saved. :-)
>
> rep nop is a pentium IV operation. Its retroactively after testing defined
> to be portable and ok.
>
Now, the example brought up was assembly, but in general I really
think we should have a processor-independent wait_loop(); inline.
Right now we have a rep_nop(); inline which only works on x86 (and
presumably x86-64).
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
next prev parent reply other threads:[~2001-09-17 19:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-17 16:16 [Q] Implementation of spin_lock on i386: why "rep;nop" ? Jean-Marc Saffroy
2001-09-17 16:22 ` Dave Jones
2001-09-17 17:19 ` Jean-Marc Saffroy
2001-09-17 16:42 ` Richard B. Johnson
2001-09-17 17:06 ` Jonathan Lundell
2001-09-17 17:27 ` Alan Cox
2001-09-17 19:47 ` H. Peter Anvin [this message]
2001-09-19 3:42 ` Jamie Lokier
2001-09-19 4:06 ` Brian Gerst
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='9o5k0f$25d$1@cesium.transmeta.com' \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.