A deliberately triggered illegal instruction signal

In computer science, an illegal opcode, also called an unimplemented operation,[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. Unlike modern processors, those older processors have a very limited transistor budget, and thus to save space their designers often omitted circuitry to detect invalid opcodes and generate a trap to an error handler. The operation of many of these opcodes happens as a side effect of the wiring of transistors in the CPU, and usually combines 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

edit

While most accidental illegal instructions have useless or even highly undesirable effects (such as crashing the device), 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.

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 used a newer CPU revision – 65C02 – that did away with illegal opcodes.

Later 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, i.e. BOP (from "BIOS Operation") utilized by the Windows NTVDM.[3]

In spite of Intel's guarantee against such instructions, research using techniques such as fuzzing uncovered a vast number of undocumented instructions in x86 processors as late as 2018.[4] 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

edit

References

edit
  1. ^ "1.2. Instruction Format". PDP-10 Reference Handbook: Programming with the PDP-10 Instruction Set (PDF). Vol. 1. Digital Equipment Corporation (DEC). 1969. p. 1-7. Retrieved 2022-05-13.
  2. ^ Åkesson, Linus (2013-03-31). "GCR decoding on the fly". Archived from the original on 2017-03-21. Retrieved 2017-03-21.
  3. ^ Schulman, Andrew; Brown, Ralf D.; Maxey, David; Michels, Raymond J.; Kyle, Jim (1994) [November 1993]. Undocumented DOS: A programmer's guide to reserved MS-DOS functions and data structures - expanded to include MS-DOS 6, Novell DOS and Windows 3.1 (2 ed.). Reading, Massachusetts: Addison Wesley. ISBN 0-201-63287-X. (xviii+856+vi pages, 3.5-inch floppy) Errata: [1][2]
  4. ^ Domas, Christopher (2017-08-31). "Breaking the x86 Instruction Set". YouTube. Archived from the original on 2021-12-19. Retrieved 2018-01-03.

Further reading

edit
edit

📚 Artikel Terkait di Wikipedia

Halt and Catch Fire (computing)

design flaw was discovered by programmers. Due to incomplete opcode decoding, two illegal opcodes, 0x9D and 0xDD, will cause the program counter on the

Don't-care term

Decision table Side effect Short-circuit evaluation Incomplete address decoding Incomplete opcode decoding Logic redundancy Undefined behaviour Undefined variable

Jazelle

ways: decoded and executed natively in hardware, handled in software (with optimised ARM/ThumbEE JVM code), or treated as an invalid/illegal opcode. The

Blackfin

as 16-bit opcodes while complex DSP and mathematically intensive functions are encoded as 32- and 64-bit opcodes. This variable length opcode encoding

High memory area

only), similar to the DR DOS HIDOS.SYS /BDOS=xxxx parameter Incomplete address decoding Intra-segment offset relocation Rebasing SHELLHIGH (CONFIG.SYS

A20 line

High memory area (HMA) LOADFIX (CONFIG.SYS directive) (PTS-DOS) Incomplete address decoding Boot loaders Paul, Matthias R. (2002-02-02). "Treiber dynamisch

V850

Non-BR. 1st map opcodes NOP is an alias of MOV R0,R0. 2nd map opcodes 1st map opcodes † NOP is an alias of MOV R0,R0. 2nd map opcodes In 1998, NEC started

BASIC interpreter

the front of the program for use by the 1-byte RST 8080 opcode instead of the 3-byte CALL opcode. In LLL BASIC, some variables occupied the same memory