From 0bc4333150628d0cd27111fac0ecc3c79b906747 Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin (Intel)" Date: Sun, 12 Oct 2025 12:58:04 -0700 Subject: [PATCH] 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) --- doc/changes.src | 24 ++++++++++++++++++++++++ x86/insns.dat | 14 ++++++++++---- 2 files changed, 34 insertions(+), 4 deletions(-) diff --git a/doc/changes.src b/doc/changes.src index c3d80ceb..79f9eb96 100644 --- a/doc/changes.src +++ b/doc/changes.src @@ -11,6 +11,30 @@ evolving code simpler. It is the production version of NASM since 2025. +\S{cl-3.02} Version 3.02 + +\b Fix build problems on C23 compilers using a pre-C23 version of + \c{} which defines \c{bool} as a macro in violation of the + C23 specification. + +\b The immediate form of the \c{JMPE} instruction (opcode \c{0F B8}) + has been changed to an absolute address, as in + the Itanium Architecture Software Developer's Manual, version 2.3, + Volume 4, page 4:249. Hopefully this won't break whatever virtual + environments use \c{JMPE}, but it is the closest thing there is to + an official specification for this opcode. + +\> Being an \e{absolute} address, treat it equivalent to a \c{FAR} + jump and do not default to 64 bits in 64-bit mode. + +\> That \c{JMPE} has apparently been wrong all these years is probably + as good of a hint as any how much it has been actually used, but it + \e{does} have the possibility of breaking virtual environments. In + that case, please file a bug report to \W{https://bugs.nasm.us/} + with details about the virtual environment, and we will figure out + a suitable solution. + + \S{cl-3.01} Version 3.01 \b A new \c{obj2} version of the \c{obj} output format, intended for diff --git a/x86/insns.dat b/x86/insns.dat index 024b89c5..e127297f 100644 --- a/x86/insns.dat +++ b/x86/insns.dat @@ -307,10 +307,16 @@ $br $wdq LOOPZ near|short,cx# [i-: a# os e1 rel8] 8086,NOAPX $br $wdq LOOPNZ near|short,cx# [i-: a# os e0 rel8] 8086,NOAPX ; JMPE is obsolete, but seems to be used by a fair number of virtual environments? -$br JMPE near [i: os 0f b8 rel] IA64 -; 0f 00 /6 with a prefix has been repurposed in long mode -$wdq JMPE rm#|near [m: nw o# np 0f 00 /6] IA64,OSIZE -$wd JMPE rm#|near [m: o# 0f 00 /6] IA64,OSIZE,NOLONG +; However, REP-prefixed JMPE opcodes have been repurposed. +; +; Per version 2.3 of the Itanium Architecture Software Developer's Manual, +; which is the closest thing to an offical specification for JMPE, +; the JMPE instruction is absolute and takes an operand size prefix like +; a far JMP. As far JMPs are not promoted by default on 64 bits, follow that +; convention. +; +$wdq JMPE imm#|near [i: norep o# 0f b8 i##] IA64,OSIZE +$wdq JMPE rm#|near [m: norep o# 0f 00 /6] IA64,OSIZE ;# Call and return $br CALL near [i: os e8 rel] 8086,BND,NOAPX