Illegal opcode

It has been suggested that this article be split into articles titled Invalid opcode and Unintended opcode. (Discuss) (December 2021)

This article has multiple issues. Please help or discuss these issues on the talk page. (Learn how and when to remove these template messages) This article needs additional citations for verification. Please help by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources:  –  ·  ·  · scholar · JSTOR (December 2010) (Learn how and when to remove this template message) This article includes a list of general references, but it remains largely unverified because it lacks sufficient corresponding inline citations. Please help to improve this article by introducing more precise citations. (June 2020) (Learn how and when to remove this template message) (Learn how and when to remove this template message)

A human generated illegal instruction signal

An illegal opcode, also called an illegal operation code,^[1] unintended opcode^[2] or undocumented instruction, is an instruction to a CPU that is not mentioned in any official documentation released by the CPU's designer or manufacturer, which nevertheless has an effect. Illegal opcodes were common on older CPUs designed during the 1970s, such as the MOS Technology 6502, Intel 8086, and the Zilog Z80. On these older processors, many exist as a side effect of the wiring of transistors in the CPU, and usually combine functions of the CPU that were not intended to be combined. On old and modern processors, there are also instructions intentionally included in the processor by the manufacturer, but that are not documented in any official specification.

Overview[]

While most accidental illegal instructions have useless or even highly undesirable effects (such as crashing the computer), some can have useful functions in certain situations. Such instructions were sometimes exploited in computer games of the 1970s and 1980s to speed up certain time-critical sections. Another common use was in the ongoing battle between copy protection implementations and cracking. Here, they were a form of security through obscurity, and their secrecy usually did not last very long.

In some cases, an "illegal" instruction could be repurposed. On Digital Equipment Corporation PDP10 and DECSYSTEM-20 mainframe computers which were used during the 1960s through the 1990s, there was no system call instruction, (a means to request input-output and other services from the operating system) so instead, the operating systems TOPS-10 and TOPS-20 recognized one specific illegal instruction as a supervisor call.

A danger associated with the use of illegal instructions was that, given the fact that the manufacturer does not guarantee their existence and function, they might disappear or behave differently with any change of the CPU internals or any new revision of the CPU, rendering programs that use them incompatible with the newer revisions. For example, a number of older Apple II games did not work correctly on the newer Apple IIc, because the latter uses a newer CPU revision – 65C02 – that does away with illegal opcodes.

More recent CPUs, such as the 80186, 80286, 68000 and its descendants, do not have illegal opcodes that are widely known/used. Ideally the CPU will behave in a well-defined way when it finds an unknown opcode in the instruction stream, such as triggering a certain exception or fault condition. The operating system's exception or fault handler will then usually terminate the application that caused the fault, unless the program had previously established its own exception/fault handler, in which case that handler would receive control. Another, less common way of handling illegal instructions is by defining them to do nothing except taking up time and space (equivalent to the CPU's official NOP instruction); this method is used by the TMS9900 and 65C02 processors, among others. Alternatively, unknown instructions can be emulated in software (e.g. LOADALL), or even "new" pseudo-instructions can be implemented. Some BIOSes, memory managers, and operating systems take advantage of this, for example, to let V86 tasks communicate with the underlying system ("bop").

In spite of this manufacturer guarantee against such instructions, research using techniques such as fuzzing has uncovered a vast number of undocumented instructions in modern x86 processors.^[3] Some of these instructions are shared across processor manufacturers, indicating that Intel and AMD are both aware of the instruction and its purpose, despite it not appearing in any official specification. Other instructions are specific to manufacturers or specific product lines. The purpose of the majority of x86 undocumented instructions is unknown.

Today, the details of these instructions are mainly of interest for exact emulation of older systems.

See also[]

• Backdoor (computing)
• Don't care term
• Easter egg (media)
• Halt and Catch Fire (computing)
• Microcode
• Pentium F00F bug
• Undocumented feature

References[]

Further reading[]

• Vardy, Adam (1996-09-27) [1995-08-22]. "Extra Instructions Of The 65XX Series CPU". Archived from the original on 2021-08-28. Retrieved 2021-11-18. (NB. Illegal opcodes on the 6502.)
• Steil, Michael (2008-07-29). "How MOS 6502 Illegal Opcodes really work". pagetable.com - Some Assembly Required. Archived from the original on 2021-11-19. Retrieved 2021-11-18.
• Young, Sean (2005-09-18) [1997]. "Z80 Documentation: The Undocumented Z80 Documented". 0.91. Archived from the original on 2021-10-09. Retrieved 2021-11-18. [1][2] (NB. Illegal opcodes on the Z80.)