Skip to content

Commit 0bc4333

Browse files
author
H. Peter Anvin (Intel)
committed
Change JMPE encoding from being relative to being absolute
Apparently NASM has been doing this in violation of the spec since JMPE was first added. Hopefully fixing it won't cause new problems... Signed-off-by: H. Peter Anvin (Intel) <[email protected]>
1 parent 44e89ba commit 0bc4333

File tree

2 files changed

+34
-4
lines changed

2 files changed

+34
-4
lines changed

doc/changes.src

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,30 @@ evolving code simpler.
1111
It is the production version of NASM since 2025.
1212

1313

14+
\S{cl-3.02} Version 3.02
15+
16+
\b Fix build problems on C23 compilers using a pre-C23 version of
17+
\c{<stdbool.h>} which defines \c{bool} as a macro in violation of the
18+
C23 specification.
19+
20+
\b The immediate form of the \c{JMPE} instruction (opcode \c{0F B8})
21+
has been changed to an absolute address, as in
22+
the Itanium Architecture Software Developer's Manual, version 2.3,
23+
Volume 4, page 4:249. Hopefully this won't break whatever virtual
24+
environments use \c{JMPE}, but it is the closest thing there is to
25+
an official specification for this opcode.
26+
27+
\> Being an \e{absolute} address, treat it equivalent to a \c{FAR}
28+
jump and do not default to 64 bits in 64-bit mode.
29+
30+
\> That \c{JMPE} has apparently been wrong all these years is probably
31+
as good of a hint as any how much it has been actually used, but it
32+
\e{does} have the possibility of breaking virtual environments. In
33+
that case, please file a bug report to \W{https://bugs.nasm.us/}
34+
with details about the virtual environment, and we will figure out
35+
a suitable solution.
36+
37+
1438
\S{cl-3.01} Version 3.01
1539

1640
\b A new \c{obj2} version of the \c{obj} output format, intended for

x86/insns.dat

Lines changed: 10 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -307,10 +307,16 @@ $br $wdq LOOPZ near|short,cx# [i-: a# os e1 rel8] 8086,NOAPX
307307
$br $wdq LOOPNZ near|short,cx# [i-: a# os e0 rel8] 8086,NOAPX
308308

309309
; JMPE is obsolete, but seems to be used by a fair number of virtual environments?
310-
$br JMPE near [i: os 0f b8 rel] IA64
311-
; 0f 00 /6 with a prefix has been repurposed in long mode
312-
$wdq JMPE rm#|near [m: nw o# np 0f 00 /6] IA64,OSIZE
313-
$wd JMPE rm#|near [m: o# 0f 00 /6] IA64,OSIZE,NOLONG
310+
; However, REP-prefixed JMPE opcodes have been repurposed.
311+
;
312+
; Per version 2.3 of the Itanium Architecture Software Developer's Manual,
313+
; which is the closest thing to an offical specification for JMPE,
314+
; the JMPE instruction is absolute and takes an operand size prefix like
315+
; a far JMP. As far JMPs are not promoted by default on 64 bits, follow that
316+
; convention.
317+
;
318+
$wdq JMPE imm#|near [i: norep o# 0f b8 i##] IA64,OSIZE
319+
$wdq JMPE rm#|near [m: norep o# 0f 00 /6] IA64,OSIZE
314320

315321
;# Call and return
316322
$br CALL near [i: os e8 rel] 8086,BND,NOAPX

0 commit comments

Comments
 (0)