Almost all commands available in both modes have the same opcode in both modes.
Remote Instructions :
- Binary encoded decimal data, such as AAM (ASCII setting after multiplication) to fix a binary encoded decimal number after executing a normal binary add / sub / mul / div in a register with two base 10 digits in each 4-bit half. They ran and were not used anyway. Storing numbers as binary integers instead of BCDs is widespread.
- push / pop from
CS / DS / ES / SS have been removed. push / pop FS and GS are still valid (these two segments may still have a non-zero base in long mode). mov Sreg, r32 and mov r32, Sreg are still available for castrated segment registers, so you can emulate push / pop using the integer variable scratch. CS still matters; remote transition to another code segment may switch to 32-bit mode, while the rest still need valid segment descriptors. - Other obscure segments such as ARPL : Adjust the segment field of the RPL segment segments. This is really just a bit-field clamp and setting flags for entire registers, so it can be emulated by several other instructions in rare places where the kernel might need it.
- Perhaps some other obscure or privileged instructions that compilers have never used in 32-bit code. (Not that compilers have ever emitted any of the above without inm or inm built in).
Removed (reprogrammed) encodings of some still available commands . In your case, 32bit can use inc r32 single-byte inc r32 (0x40 + register number). 64-bit mode has only inc r/m32 encoding, where the register to be increased is specified by the second byte. (In this case, the 0x4x bytes were reassigned as the REX byte prefix).
The Intel insn link (follow the wiki link, or) shows the following for inc :
Opcode Instruction Op/ 64-Bit Compat/ En Mode Leg mode FF /0 INC r/m32 M Valid Valid Increment r/m doubleword by 1. 40+ rd INC r32 O NE Valid Increment doubleword register by 1.
NE means not encoded. The Op / En column describes how operands are encoded.
Jan Hubicka AMD64 ISA Overview briefly describes the reuse of single-byte inc / dec codes for REX prefixes, as well as the default operand sizes and as immediate data are still 32-bit. movabs is available for loading 64-bit instantaneous constants or loading / storing from a 64-bit absolute address.
AMD AMD64 Manual , Section 2.5.11 Overridden Opcodes has a fairly short table. It lists only:
4x inc/dec r32 that turned into REX prefixes63 ARPL , which became MOVSXD (sign-extend dword to qword, when used with REX.W = 1 (which means the W bit in the prefix REX = 1)).
The early AMD64 and Intel EMT64 processors left in SAHF/LAHF mode in long mode, but later added this command again with the same SAHF/LAHF as 32 bits. This table also does not list instructions that have been completely deleted (BCD instructions and possibly others) that have been deleted to make room for possible future extensions.
They could simplify a lot, and made the x86-64 a much cleaner instruction set with more options for future extensions, but every difference from 32 bits means more decoder transistors . There are no machine instructions that have moved to another opcode on a 64-bit basis.
Several machine instructions often use the same mnemonics, mov most overloaded. There are loads, shops, mov with immediate constants, moving to / from segment registers, all in 8 bits and 32 bits. (16 bits - 32 bits with the operand size prefix, the same for 64-bit with the REX prefix). There is a special opcode for downloading RAX from a 64-bit absolute address. There is also a special opcode to load a 64-bit constant into the register. (The AT & T syntax calls this movabs, but it still just moves in Intel / NASM)