The usage of NOP
Tim Roberts
>
>I am a newbie of x86 asm. Can anybody tell me the usage of NOP, and why we
>need such a instruction since it apparently do nothing but xchg ax, ax ?
Sometimes, it is used as a very short delay. Sometimes, with some of the
newer processors, it can be used to affect the pairing of instructions and
can actually enhance performance.
It can also be useful during debugging to "disable" a section of code by
overwriting it with 90s.
It is convenient to have a no-op instruction available, even though it is
rarely used. In the x86 case, the designers discovered they could supply
one for free by using the opcode that would otherwise have exchanged ax
with ax.
It is interesting to ponder whether the processor actually DOES exchange ax
with ax when encountering this instruction...
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Robert Wessel
FWIW, NOP is a degenerate form of some other instruction on many
processors. "Xchg ax,ax" on x86, as you pointed out, "bc 0,x" (branch
on no condition) on S/360, "bis r31,r31,r31" ("or" contents of r31
with r31, store in r31 - note r31 is read-as-zero, ignore store) on
Alpha, and similar things on many of the RISC processors. There are
some (68K and VAX, come to mind) where it is a special op code.
These were probably all executed as the base instruction on early
members of each processor family, but are often suppressed on later
models (this is less true of the RISC machines where the execution is
designed to be cheap). As a practical matter, there are many
effective NOPs on most architectures, but sticking with the
conventional form is likely to be better for performance, since the
implementers are likely only going to optimize the "approved" idiom
for use in filling issue slots and what not.
Ed Beroset
>It is interesting to ponder whether the processor actually DOES exchange ax
>with ax when encountering this instruction...
I wonder if it might be determined empirically without dissecting the
die. For example, maybe one could monitor the power consumption of a
loop executing multiple NOP instructions followed by multiple XCHG
BX,AX instructions followed by multiple XCHG BX,BX instructions. When
viewed on a 'scope, it might give insight as to what's really
happening in there...
Ed
Lyle Goldman
On Mon, 23 Sep 2002 05:55:59 GMT, Tim Roberts <ti...@probo.com> wrote:
>
> On Sat, 21 Sep 2002 20:51:41 GMT, ou liuwrote:
>
> >I am a newbie of x86 asm. Can anybody tell me the usage of NOP, and why we
> >need such a instruction since it apparently do nothing but xchg ax, ax ?
>
What happened to this original posting? I don't see it on the
newsgroup.
- Lyle Goldman, USA
Terje Mathisen
> Tim Roberts <ti...@probo.com> wrote in message news:<4v6tou037t4fhflua...@4ax.com>...
>>with ax when encountering this instruction...
> These were probably all executed as the base instruction on early
> members of each processor family, but are often suppressed on later
> models (this is less true of the RISC machines where the execution is
> designed to be cheap). As a practical matter, there are many
> effective NOPs on most architectures, but sticking with the
> conventional form is likely to be better for performance, since the
> implementers are likely only going to optimize the "approved" idiom
> for use in filling issue slots and what not.
This is indeed important:
All current x86 cpus specialcase NOP, otherwise it would introduce false
dependencies on (E)AX, whihc could introduce pipeline bubbles.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Orlando Llanes
> All current x86 cpus specialcase NOP, otherwise it would introduce false
> dependencies on (E)AX, whihc could introduce pipeline bubbles.
Speaking of dependencies, I was reading a doc on the AMD K6 (?) in which
I was looking at partial register dependancies. "mov ah, al" seems to run
without penalty (I haven't tried it myself) on the K6+ since AMD loads ah
and al independantly. Intel still loads the entire register, hence the
penalty.
See ya!
Orlando
Robert Redelmeier
>
> These were probably all executed as the base instruction on early
> members of each processor family, but are often suppressed on later
> models (this is less true of the RISC machines where the execution is
> designed to be cheap). As a practical matter, there are many
> effective NOPs on most architectures, but sticking with the
> conventional form is likely to be better for performance, since the
> implementers are likely only going to optimize the "approved" idiom
> for use in filling issue slots and what not.
Fruthermore, `gas` [gcc assembler] will even code these multibyte
NOPs _automagically_ for .align pseudoinstructions. The multibyte
NOPs often are quicker to execute, or at least occupy fewer decode
and retirement resources.
-- Robert
Jerry Coffin
ber...@mindspring.com says...
I'd almost bet this could be determined even more easily, simply by
timing carefully selected code sequences.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Robert Wessel
Well, first Intel documents that the convention NOP gets special
handling, so...
Anyway, a quick test (one million iterations around a sequence of one
hundred repetitions of the instruction in question) shows that xchg
eax,eax (0x90) runs about 3.6 times faster than xchg eax,ebx (0x93) on
both a Pentium and P3, and about 2.7 times faster on a 486. No 386,
P4 or AMD boxes handy at the moment. But there's clearly something
different happening for NOP.
David Thompson
....
> FWIW, NOP is a degenerate form of some other instruction on many
> processors. "Xchg ax,ax" on x86, as you pointed out, "bc 0,x" (branch
> .... As a practical matter, there are many
> effective NOPs on most architectures, but sticking with the
The PDP-10, back in the day when complex instructions had to
be built out of (rather large numbers of) discrete transistors, had about
a dozen different no-ops: different kinds of jump or skip on no condition,
ALU identity operations, and IIRC halfword moves to nowhere.
Each carefully documented in the manual as "xxx is a no-op
which references memory" or "... does not reference memory",
since (synchronous) memory cycles were almost always
the dominant performance factor.
--
- David.Thompson 1 now at worldnet.att.net