TIP: Click on subject to list as thread! ANSI
echo: 80xxx
to: TIM HUTZLER
from: JERRY COFFIN
date: 1997-11-08 12:26:00
subject: jmp $+2

On (07 Nov 97) Tim Hutzler wrote to Serguei Shtyliov...
[ talking about `jmp $+2' ]
 TH> SS>It's been widely used to insert a delay between 2 I/O port
 TH> SS>accesses on the 80x86 PCs until 486/P5 have appeared.
 TH> NOPs would seem better, IMHO.
It takes a LOT of nops to do the job.  The point of using the jmp is
that it imposes a relatively long delay because in older CPUs it dumps
the current contents of the pre-fetched instruction queue, so the CPU
has to wait for an instruction to arrive from memory before it starts
executing another instruction.
Since the memory read had to take place from the motherboard, jus like
the I/O instruction access did, it was safe to assume that by the time
the memory read finished, so had the I/O.  However, with modern CPUs
using caching on the CPU itself, this is no longer the case.  Even when
the prefeteched instruction queue gets dumped, the CPU can usually
retrieve the next instruction from the cache on the chip instead of
waiting for the motherboard to catch up.  In this case, the CPU may
complete the jump well before the motherboard is ready for another
transaction.
You've expressed concern about somebody changing the assembler options
and messing up the offset hard-coded into the instruction.  If this is
really a concern (rarely the case, in my experience) you can make the
distance of the jump explicit or (preferrable, IMO) use a macro:
delay macro
    jmp short @F
@@:
delay endm
then when you want to code a delay, you just use "delay" instead of
putting the jump directly in your code.  This not only makes the code
harder to mess up, but could be interpreted as more readable as well,
though `jmp $+2' is a well known idiom, so I suspect the readability
isn't drastically affected either way.
    Later,
    Jerry.
--- PPoint 2.02
---------------
* Origin: Point Pointedly Pointless (1:128/166.5)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.