Machine code - Revision history

imported>Oklopfer: substitute per MOS:SECTIONANCHOR

2026-06-29T17:20:53Z

← Previous revision		Revision as of 17:20, 29 June 2026
Line 14:		Line 14:
	* [[jump instruction\|Jump]] or [[Addressing mode#Skip\|skip]] to an instruction that is not the next one		* [[jump instruction\|Jump]] or [[Addressing mode#Skip\|skip]] to an instruction that is not the next one

	An [[instruction set architecture]] (ISA) defines the interface to a CPU and varies by groupings or families of CPU design such as [[x86]] and [[ARM architecture family \|ARM]]. Generally, machine code compatible with one family is not with others, but there are exceptions. The [[VAX]] architecture includes optional support of the [[PDP-11]] ~~instruction set~~. The [[IA-64]] architecture includes optional support of the [[IA-32]] instruction set. And, the [[PowerPC 600#PowerPC 615\|PowerPC 615]] can natively process both [[PowerPC]] and x86 instructions.		An [[instruction set architecture]] (ISA) defines the interface to a CPU and varies by groupings or families of CPU design such as [[x86]] and [[ARM architecture family \|ARM]]. Generally, machine code compatible with one family is not with others, but there are exceptions. The [[VAX]] architecture includes optional support of the [[PDP-11 architecture\|PDP-11 instruction set]]. The [[IA-64]] architecture includes optional support of the [[IA-32]] instruction set. And, the [[PowerPC 600#PowerPC 615\|PowerPC 615]] can natively process both [[PowerPC]] and x86 instructions.

	==Assembly language==		==Assembly language==
Line 49:		Line 49:
	* Input/output		* Input/output

	==={{anchor \|Overlapping instructions}}Overlapping instruction===		===<span class="anchor" id="Overlapping instructions"></span>Overlapping instruction===
	On processor architectures with [[variable-length instruction set]]s<ref name="Jacob-Jakubowski-Venkatesan_2007"/> (such as [[Intel]]'s [[x86]] processor family) it is, within the limits of the control-flow [[self-synchronizing code\|resynchronizing]] phenomenon known as the [[Kruskal count]],<ref name="Lagarias-Rains-Vanderbei_2001"/><ref name="Jacob-Jakubowski-Venkatesan_2007"/><ref name="Andriesse-Bos_2014"/><ref name="Jakubowski_2016"/><ref name="Jämthagen_2016"/> sometimes possible through opcode-level programming to deliberately arrange the resulting code so that two code paths share a common fragment of opcode sequences.<ref group="nb" name="NB_Merging_or_branching"/> These are called ''overlapping instructions'', ''overlapping opcodes'', ''overlapping code'', ''overlapped code'', ''instruction scission'', or ''jump into the middle of an instruction''.<ref name="HN_2021"/><ref name="Kinder_2010"/><ref name="RE_2013"/>		On processor architectures with [[variable-length instruction set]]s<ref name="Jacob-Jakubowski-Venkatesan_2007"/> (such as [[Intel]]'s [[x86]] processor family) it is, within the limits of the control-flow [[self-synchronizing code\|resynchronizing]] phenomenon known as the [[Kruskal count]],<ref name="Lagarias-Rains-Vanderbei_2001"/><ref name="Jacob-Jakubowski-Venkatesan_2007"/><ref name="Andriesse-Bos_2014"/><ref name="Jakubowski_2016"/><ref name="Jämthagen_2016"/> sometimes possible through opcode-level programming to deliberately arrange the resulting code so that two code paths share a common fragment of opcode sequences.<ref group="nb" name="NB_Merging_or_branching"/> These are called ''overlapping instructions'', ''overlapping opcodes'', ''overlapping code'', ''overlapped code'', ''instruction scission'', or ''jump into the middle of an instruction''.<ref name="HN_2021"/><ref name="Kinder_2010"/><ref name="RE_2013"/>

Line 64:		Line 64:

	==Examples==		==Examples==
			===IBM 650===
			[[File:BronxScienceProgrammingClassroom1960.jpg\|thumb\|A 1960 [[Bronx High School of Science\|high school]] classroom with an [[IBM 650]] instruction code chart above the blackboard, upper right]]
			[[File:IBM 650 student program 1961.agr.jpg\|thumb\|Student program from 1961 written in IBM 650 machine language, based on a text book exercise]]
			The [[IBM 650]], introduced in 1954, was a decimal, word addressed computer with instructions and data stored on a magnetic drum. Each word included ten digits plus sign. Instructions divided the words into a two digit operation code, a four digit address of the data word to be processed and a four digit address of the next instruction to execute. The second address allowed instructions to be placed on the drum near where the drum would be positioned after the previous instruction completed, a practice called optimization.<ref name=andree>{{cite book \| last = Andree \| first = Richard V.
			\| title = Programming the IBM 650 Magnetic Drum Computer and Data-Processing Machine
			\| url = http://www.bitsavers.org/pdf/ibm/650/Andree_Programming_the_IBM_650_Magnetic_Drum_Computer_and_Data-Processing_Machine_1958.pdf
			\| year = 1958}}</ref>

			With the aid of a physical table of op codes, it was quite feasible to write programs in machine code. IBM provided a form with a grid showing each memory location, so a programmer could keep track of which locations were still available. There was a single-instruction-per-card format that could be loaded directly into the machine and executed.
			Later IBM introduced an [[Symbolic Optimal Assembly Program\|assembler]] (SOAP) that allowed symbolic address and also performed a rough optimization pass.

	===IBM 709x===		===IBM 709x===
	The [[IBM 700/7000 series#Later scientific architecture (704/709/7090/7094)\|IBM 704, 709, 704x and 709x]] store one instruction in each instruction word; IBM numbers the bit from the left as S, 1, ..., 35. Most instructions have one of two formats:		The [[IBM 700/7000 series#Later scientific architecture (704/709/7090/7094)\|IBM 704, 709, 704x and 709x]] store one instruction in each instruction word; IBM numbers the bit from the left as S, 1, ..., 35. Most instructions have one of two formats:
Line 91:		Line 102:
	The [[MIPS architecture]] provides a specific example for a machine code whose instructions are always 32 bits long.<ref name="Harris_2007"/>{{Rp\|299}} The general type of instruction is given by the ''op'' (operation) field, the highest 6 bits. J-type (jump) and I-type (immediate) instructions are fully specified by ''op''. R-type (register) instructions include an additional ''funct'' (function) field to determine the exact operation. The fields used in these types are:		The [[MIPS architecture]] provides a specific example for a machine code whose instructions are always 32 bits long.<ref name="Harris_2007"/>{{Rp\|299}} The general type of instruction is given by the ''op'' (operation) field, the highest 6 bits. J-type (jump) and I-type (immediate) instructions are fully specified by ''op''. R-type (register) instructions include an additional ''funct'' (function) field to determine the exact operation. The fields used in these types are:

	~~6 5 5 5 5~~ 6 bits		{\| class="wikitable"
	~~[ op~~ \| rs \| rt \| rd \|shamt\| funct~~] R~~-~~type~~		\|-
	~~[ op~~ \| rs \| rt \| ~~address/~~immediate~~] I~~-~~type~~		! Type \|\| colspan=6\| -31-                                 format (bits)                                 -0-
	~~[ op~~ \| ~~target~~ address ~~] J-type~~		\|- align=center
			\| '''R''' \|\| opcode (6) \|\| rs (5) \|\| rt (5) \|\| rd (5) \|\| shamt (5) \|\| funct (6)
			\|- align=center
			\| '''I''' \|\| opcode (6) \|\| rs (5) \|\| rt (5) \|\|colspan=3\| immediate (16)
			\|- align=center
			\| '''J''' \|\| opcode (6) \|\|colspan=5\| address (26)
			\|}

	''rs'', ''rt'', and ''rd'' indicate register operands; ''shamt'' gives a shift amount; and the ''address'' or ''immediate'' fields contain an operand directly.<ref name="Harris_2007"/>{{Rp\|299–301}}		''rs'', ''rt'', and ''rd'' indicate register operands; ''shamt'' gives a shift amount; and the ''address'' or ''immediate'' fields contain an operand directly.<ref name="Harris_2007"/>{{Rp\|299–301}}
Line 117:		Line 134:

	==Bytecode==		==Bytecode==
	Machine code is similar to yet fundamentally different from [[bytecode]]. Like machine code, bytecode is typically generated (i.e. by a compiler) from source code. But, unlike machine code, bytecode is not directly executable by a CPU. An exception is if a processor is designed to use bytecode as its machine code, such as the [[Java processor]]. If bytecode is processed by an software interpreter, then that interpreter is a [[virtual machine]] for which the bytecode is its machine code.		Machine code is similar to yet fundamentally different from [[bytecode]]. Like machine code, bytecode is typically generated (i.e. by a compiler) from source code. But, unlike machine code, bytecode is not directly executable by a CPU. An exception is if a processor is designed to use bytecode as its machine code, such as the [[Pascal MicroEngine]] or a [[Java processor]]. If bytecode is processed by a software interpreter, then that interpreter is a [[virtual machine]] for which the bytecode is its machine code.

	==Storage==		==Storage==
Line 156:		Line 173:
	}}		}}

	==References==		== References ==
	<references>		<references>
	<ref name="Andriesse-Bos_2014">{{cite conference \|title=Instruction-Level Steganography for Covert Trigger-Based Malware \|first1=Dennis \|last1=Andriesse \|first2=Herbert \|last2=Bos \|author-link2=:d:Q56565972 \|date=2014-07-10<!-- /11 --> \|editor-first=Sven \|editor-last=Dietrich \|conference=11th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA) \|publisher=[[Springer International Publishing]] \|series=[[Lecture Notes in Computer Science]] \|publication-place=Egham, UK; Switzerland \|location=Vrije Universiteit Amsterdam, Amsterdam, Netherlands \|doi=10.1007/978-3-319-08509-8_3 \|s2cid=4634611 \|id=LNCS 8550 \|issn=0302-9743 \|eissn=1611-3349 \|isbn=978-3-31908508-1 \|pages=41–50 [45] \|url=https://www.cs.vu.nl/~herbertb/papers/stega_dimva14.pdf \|access-date=2023-08-26 \|url-status=live \|archive-url=https://web.archive.org/web/20230826135254/https://www.cs.vu.nl/~herbertb/papers/stega_dimva14.pdf \|archive-date=2023-08-26}} (10 pages)</ref>		<ref name="Andriesse-Bos_2014">{{cite conference \|title=Instruction-Level Steganography for Covert Trigger-Based Malware \|first1=Dennis \|last1=Andriesse \|first2=Herbert \|last2=Bos \|author-link2=:d:Q56565972 \|date=2014-07-10<!-- /11 --> \|editor-first=Sven \|editor-last=Dietrich \|conference=11th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA) \|publisher=[[Springer International Publishing]] \|series=[[Lecture Notes in Computer Science]] \|publication-place=Egham, UK; Switzerland \|location=Vrije Universiteit Amsterdam, Amsterdam, Netherlands \|doi=10.1007/978-3-319-08509-8_3 \|s2cid=4634611 \|id=LNCS 8550 \|issn=0302-9743 \|eissn=1611-3349 \|isbn=978-3-31908508-1 \|pages=41–50 [45] \|url=https://www.cs.vu.nl/~herbertb/papers/stega_dimva14.pdf \|access-date=2023-08-26 \|url-status=live \|archive-url=https://web.archive.org/web/20230826135254/https://www.cs.vu.nl/~herbertb/papers/stega_dimva14.pdf \|archive-date=2023-08-26}} (10 pages)</ref>
	<ref name="Dourish_2004">{{cite book \|url=https://books.google.com/books?id=DCIy2zxrCqcC&pg=PA7 \|title=Where the Action is: The Foundations of Embodied Interaction \|last=Dourish \|first=Paul \|author-link=Paul Dourish \|publisher=[[MIT Press]] \|date=2004 \|access-date=2023-03-05 \|page=7 \|isbn=0-262-54178-5}}</ref>		<ref name="Dourish_2004">{{cite book \|url=https://books.google.com/books?id=DCIy2zxrCqcC&pg=PA7 \|title=Where the Action is: The Foundations of Embodied Interaction \|last=Dourish \|first=Paul \|author-link=Paul Dourish \|publisher=[[MIT Press]] \|date=2004 \|access-date=2023-03-05 \|page=7 \|isbn=0-262-54178-5}}</ref>
	<ref name="Gates">{{citation \|title=Personal communication \|first=William "Bill" Henry \|last=Gates \|author-link=~~William Henry~~ Gates ~~III~~ \|date=}} (NB. According to {{citeref\|Jacob\|Jakubowski\|Venkatesan\|2007\|Jacob et al\|style=plain}}.)</ref>		<ref name="Gates">{{citation \|title=Personal communication \|first=William "Bill" Henry \|last=Gates \|author-link=Bill Gates \|date=}} (NB. According to {{citeref\|Jacob\|Jakubowski\|Venkatesan\|2007\|Jacob et al\|style=plain}}.)</ref>
	<ref name="Harris_2007">{{cite book \|url=https://books.google.com/books?id=5X7JV5-n0FIC \|title=Digital Design and Computer Architecture \|last1=Harris \|first1=David \|last2=Harris \|first2=Sarah L. \|publisher=[[Morgan Kaufmann Publishers]] \|date=2007 \|access-date=2023-03-05 \|isbn=978-0-12-370497-9}}</ref>		<ref name="Harris_2007">{{cite book \|url=https://books.google.com/books?id=5X7JV5-n0FIC \|title=Digital Design and Computer Architecture \|last1=Harris \|first1=David \|last2=Harris \|first2=Sarah L. \|publisher=[[Morgan Kaufmann Publishers]] \|date=2007 \|access-date=2023-03-05 \|isbn=978-0-12-370497-9}}</ref>
	<ref name="HN_2021">{{cite web \|title=Unintended Instructions on x86 \|date=2021 \|work=Hacker News \|url=https://news.ycombinator.com/item?id=27113890 \|access-date=2021-12-24 \|url-status=live \|archive-url=https://web.archive.org/web/20211225000914/https://news.ycombinator.com/item?id=27113890 \|archive-date=2021-12-25}}</ref>		<ref name="HN_2021">{{cite web \|title=Unintended Instructions on x86 \|date=2021 \|work=Hacker News \|url=https://news.ycombinator.com/item?id=27113890 \|access-date=2021-12-24 \|url-status=live \|archive-url=https://web.archive.org/web/20211225000914/https://news.ycombinator.com/item?id=27113890 \|archive-date=2021-12-25}}</ref>

imported>Guy Harris: Undid 2 revisions from 1340210721 until 1340210807 - rvv

2026-02-24T21:16:55Z

Undid 2 revisions from 1340210721 until 1340210807 - rvv

← Previous revision		Revision as of 21:16, 24 February 2026
Line 7:		Line 7:
	{{Program execution}}		{{Program execution}}

	In [[computing]], '''machine code''' is [[data]] [[encoded]] and structured to control a [[computer]]'s [[central processing unit]] (CPU) via its programmable [[Interface (computing)\|interface]]. A [[computer program]] consists primarily of sequences of machine-code instructions.<ref name="Stallings_2015"/> Machine code is classified as [[native (computing)\|native]] with respect to its host CPU since it is the language that the CPU interprets directly.<ref name="Managed"/> A [[interpreter (~~software~~)\|software ~~interpreter~~]] ~~is a~~ [[~~virtual machine~~]] that ~~processes~~ virtual machine code.		In [[computing]], '''machine code''' is [[data]] [[encoded]] and structured to control a [[computer]]'s [[central processing unit]] (CPU) via its programmable [[Interface (computing)\|interface]]. A [[computer program]] consists primarily of sequences of machine-code instructions.<ref name="Stallings_2015"/> Machine code is classified as [[native (computing)\|native]] with respect to its host CPU since it is the language that the CPU interprets directly.<ref name="Managed"/> Some [[interpreter (computing)\|software interpreters]] translate the [[programming language]] that they interpret into a virtual machine code ([[bytecode]]) and process it with a [[P-code machine]].

	A machine-code instruction causes the CPU to perform a specific task such as:		A machine-code instruction causes the CPU to perform a specific task such as:
Line 129:		Line 129:
	[[Disassembly]] decodes machine code to assembly language which is possible since assembly instructions can often be mapped one-to-one to machine instructions.{{Sfn\|Tanenbaum\|1990\|p=[https://archive.org/details/structuredcomput00tane/page/398 398]}}		[[Disassembly]] decodes machine code to assembly language which is possible since assembly instructions can often be mapped one-to-one to machine instructions.{{Sfn\|Tanenbaum\|1990\|p=[https://archive.org/details/structuredcomput00tane/page/398 398]}}

	A [[decompiler]] converts machine code to a [[High-level programming language \|high-level language]], but the result can be relatively [[Obfuscation (software)\|obfuscated]]; hard to understand.		A [[decompiler]] converts machine code to a [[High-level programming language \|high-level language]], but the result can be relatively [[Obfuscation (software)\|obfuscated]] (hard to understand).

	A program can be associated with [[debug symbol]]s (either embedded in the [[executable#native executable\|native executable]] or in a separate file) that allow it to be mapped to external source code. A [[debugger]] reads the symbols to help a programmer interactively [[debugging \|debug]] the program. Examples include:		A program can be associated with [[debug symbol]]s (either embedded in the [[executable#native executable\|native executable]] or in a separate file) that allow it to be mapped to external source code. A [[debugger]] reads the symbols to help a programmer interactively [[debugging \|debug]] the program. Examples include:

imported>Explicit: Removing link(s) because G8: Redirect to deleted page Detection of Intrusions and Malware, and Vulnerability Assessment (XFDcloser)

2025-12-30T23:36:18Z

Removing link(s) because G8: Redirect to deleted page Detection of Intrusions and Malware, and Vulnerability Assessment (XFDcloser)

← Previous revision		Revision as of 23:36, 30 December 2025
Line 7:		Line 7:
	{{Program execution}}		{{Program execution}}

	In [[computing]], '''machine code''' is [[data]] [[encoded]] and structured to control a [[computer]]'s [[central processing unit]] (CPU) via its programmable [[Interface (computing)\|interface]]. A [[computer program]] consists primarily of sequences of machine-code instructions.<ref name="Stallings_2015"/> Machine code is classified as [[native (computing)\|native]] with respect to its host CPU since it is the language that CPU interprets directly.<ref name="Managed"/> A [[interpreter (software)\|software interpreter]] is a [[virtual machine]] that processes virtual machine code.		In [[computing]], '''machine code''' is [[data]] [[encoded]] and structured to control a [[computer]]'s [[central processing unit]] (CPU) via its programmable [[Interface (computing)\|interface]]. A [[computer program]] consists primarily of sequences of machine-code instructions.<ref name="Stallings_2015"/> Machine code is classified as [[native (computing)\|native]] with respect to its host CPU since it is the language that the CPU interprets directly.<ref name="Managed"/> A [[interpreter (software)\|software interpreter]] is a [[virtual machine]] that processes virtual machine code.

	A machine-code instruction causes the CPU to perform a specific task such as:		A machine-code instruction causes the CPU to perform a specific task such as:
Line 19:		Line 19:
	[[File:Machine language and assembly language.jpg\|thumb\|319x319px\|Translation of assembly into machine code]]		[[File:Machine language and assembly language.jpg\|thumb\|319x319px\|Translation of assembly into machine code]]

	[[Assembly language]] provides a relatively direct mapping from a [[human-readable]] [[source code]] to machine code. The assembly language source code represents numerical codes in machine code, as mnemonics and labels.<ref name="Dourish_2004"/> For example, <code>[[NOP (code)\|NOP]]</code> in assembly for an ~~X86 processor, represents the~~ [[x86]] architecture [[opcode]] 0x90 in machine code. While it is possible to write a program in machine code, doing so is tedious and error-prone. Therefore, programs are usually written in assembly or, more commonly, in a [[high-level programming language]].		[[Assembly language]] provides a relatively direct mapping from a [[human-readable]] [[source code]] to machine code. The assembly language source code represents numerical codes in machine code, as mnemonics and labels.<ref name="Dourish_2004"/> For example, <code>[[NOP (code)\|NOP]]</code> in assembly for an [[x86]] processor represents the x86 architecture [[opcode]] 0x90 in machine code. While it is possible to write a program in machine code, doing so is tedious and error-prone. Therefore, programs are usually written in assembly or, more commonly, in a [[high-level programming language]].

	==Instruction set==		==Instruction set==
Line 52:		Line 52:
	On processor architectures with [[variable-length instruction set]]s<ref name="Jacob-Jakubowski-Venkatesan_2007"/> (such as [[Intel]]'s [[x86]] processor family) it is, within the limits of the control-flow [[self-synchronizing code\|resynchronizing]] phenomenon known as the [[Kruskal count]],<ref name="Lagarias-Rains-Vanderbei_2001"/><ref name="Jacob-Jakubowski-Venkatesan_2007"/><ref name="Andriesse-Bos_2014"/><ref name="Jakubowski_2016"/><ref name="Jämthagen_2016"/> sometimes possible through opcode-level programming to deliberately arrange the resulting code so that two code paths share a common fragment of opcode sequences.<ref group="nb" name="NB_Merging_or_branching"/> These are called ''overlapping instructions'', ''overlapping opcodes'', ''overlapping code'', ''overlapped code'', ''instruction scission'', or ''jump into the middle of an instruction''.<ref name="HN_2021"/><ref name="Kinder_2010"/><ref name="RE_2013"/>		On processor architectures with [[variable-length instruction set]]s<ref name="Jacob-Jakubowski-Venkatesan_2007"/> (such as [[Intel]]'s [[x86]] processor family) it is, within the limits of the control-flow [[self-synchronizing code\|resynchronizing]] phenomenon known as the [[Kruskal count]],<ref name="Lagarias-Rains-Vanderbei_2001"/><ref name="Jacob-Jakubowski-Venkatesan_2007"/><ref name="Andriesse-Bos_2014"/><ref name="Jakubowski_2016"/><ref name="Jämthagen_2016"/> sometimes possible through opcode-level programming to deliberately arrange the resulting code so that two code paths share a common fragment of opcode sequences.<ref group="nb" name="NB_Merging_or_branching"/> These are called ''overlapping instructions'', ''overlapping opcodes'', ''overlapping code'', ''overlapped code'', ''instruction scission'', or ''jump into the middle of an instruction''.<ref name="HN_2021"/><ref name="Kinder_2010"/><ref name="RE_2013"/>

	In the 1970s and 1980s, overlapping instructions were sometimes used to preserve memory space. One example ~~were~~ in the implementation of error tables in [[Microsoft]]'s [[Altair BASIC]], where ''interleaved instructions'' mutually shared their instruction bytes.<ref name="Gates"/><ref name="Jacob-Jakubowski-Venkatesan_2007"/><ref name="HN_2021"/> The technique is rarely used today, but might still be necessary to resort to in areas where extreme optimization for size is necessary on byte-level such as in the implementation of [[boot loader]]s which have to fit into [[boot sector]]s.<ref group="nb" name="NB_DR-DOS_707"/>		In the 1970s and 1980s, overlapping instructions were sometimes used to preserve memory space. One example was in the implementation of error tables in [[Microsoft]]'s [[Altair BASIC]], where ''interleaved instructions'' mutually shared their instruction bytes.<ref name="Gates"/><ref name="Jacob-Jakubowski-Venkatesan_2007"/><ref name="HN_2021"/> The technique is rarely used today, but might still be necessary to resort to in areas where extreme optimization for size is necessary on the byte level such as in the implementation of [[boot loader]]s which have to fit into [[boot sector]]s.<ref group="nb" name="NB_DR-DOS_707"/>

	It is also sometimes used as a [[code obfuscation]] technique as a measure against [[disassembly]] and tampering.<ref name="Jacob-Jakubowski-Venkatesan_2007"/><ref name="Jakubowski_2016"/>		It is also sometimes used as a [[code obfuscation]] technique as a measure against [[disassembly]] and tampering.<ref name="Jacob-Jakubowski-Venkatesan_2007"/><ref name="Jakubowski_2016"/>
Line 89:		Line 89:

	===MIPS===		===MIPS===
	The [[MIPS architecture]] provides a specific example for a machine code whose instructions are always 32 bits long.<ref name="Harris_2007"/>{{Rp\|299}} The general type of instruction is given by the ''op'' (operation) field, the highest 6 bits. J-type (jump) and I-type (immediate) instructions are fully specified by ''op''. R-type (register) instructions include an additional ~~field~~ ''~~funcational~~'' to determine the exact operation. The fields used in these types are:		The [[MIPS architecture]] provides a specific example for a machine code whose instructions are always 32 bits long.<ref name="Harris_2007"/>{{Rp\|299}} The general type of instruction is given by the ''op'' (operation) field, the highest 6 bits. J-type (jump) and I-type (immediate) instructions are fully specified by ''op''. R-type (register) instructions include an additional ''funct'' (function) field to determine the exact operation. The fields used in these types are:

	6 5 5 5 5 6 bits		6 5 5 5 5 6 bits
Line 131:		Line 131:
	A [[decompiler]] converts machine code to a [[High-level programming language \|high-level language]], but the result can be relatively [[Obfuscation (software)\|obfuscated]]; hard to understand.		A [[decompiler]] converts machine code to a [[High-level programming language \|high-level language]], but the result can be relatively [[Obfuscation (software)\|obfuscated]]; hard to understand.

	A program can be associated with [[debug symbol]]s (either embedded in the [[executable#native executable\|native executable]] or in a separate file) that allow it to be mapped to external source code. A [[debugger]] reads the symbols to help a programmer interactively [[debugging \|debug]] the program. ~~Example~~ include:		A program can be associated with [[debug symbol]]s (either embedded in the [[executable#native executable\|native executable]] or in a separate file) that allow it to be mapped to external source code. A [[debugger]] reads the symbols to help a programmer interactively [[debugging \|debug]] the program. Examples include:

	* The [[SHARE Operating System]] (1959) for the [[IBM 709]], [[IBM 7090]], and [[IBM 7094]] computers allowed for an loadable code format named [[SQUOZE]]. SQUOZE was a compressed binary form of [[assembly language]] code and included a symbol table.		* The [[SHARE Operating System]] (1959) for the [[IBM 709]], [[IBM 7090]], and [[IBM 7094]] computers allowed for an loadable code format named [[SQUOZE]]. SQUOZE was a compressed binary form of [[assembly language]] code and included a symbol table.
Line 158:		Line 158:
	==References==		==References==
	<references>		<references>
	<ref name="Andriesse-Bos_2014">{{cite conference \|title=Instruction-Level Steganography for Covert Trigger-Based Malware \|first1=Dennis \|last1=Andriesse \|first2=Herbert \|last2=Bos \|author-link2=:d:Q56565972 \|date=2014-07-10<!-- /11 --> \|editor-first=Sven \|editor-last=Dietrich \|conference=11th [[International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment]] (DIMVA) \|publisher=[[Springer International Publishing]] \|series=[[Lecture Notes in Computer Science]] \|publication-place=Egham, UK; Switzerland \|location=Vrije Universiteit Amsterdam, Amsterdam, Netherlands \|doi=10.1007/978-3-319-08509-8_3 \|s2cid=4634611 \|id=LNCS 8550 \|issn=0302-9743 \|eissn=1611-3349 \|isbn=978-3-31908508-1 \|pages=41–50 [45] \|url=https://www.cs.vu.nl/~herbertb/papers/stega_dimva14.pdf \|access-date=2023-08-26 \|url-status=live \|archive-url=https://web.archive.org/web/20230826135254/https://www.cs.vu.nl/~herbertb/papers/stega_dimva14.pdf \|archive-date=2023-08-26}} (10 pages)</ref>		<ref name="Andriesse-Bos_2014">{{cite conference \|title=Instruction-Level Steganography for Covert Trigger-Based Malware \|first1=Dennis \|last1=Andriesse \|first2=Herbert \|last2=Bos \|author-link2=:d:Q56565972 \|date=2014-07-10<!-- /11 --> \|editor-first=Sven \|editor-last=Dietrich \|conference=11th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA) \|publisher=[[Springer International Publishing]] \|series=[[Lecture Notes in Computer Science]] \|publication-place=Egham, UK; Switzerland \|location=Vrije Universiteit Amsterdam, Amsterdam, Netherlands \|doi=10.1007/978-3-319-08509-8_3 \|s2cid=4634611 \|id=LNCS 8550 \|issn=0302-9743 \|eissn=1611-3349 \|isbn=978-3-31908508-1 \|pages=41–50 [45] \|url=https://www.cs.vu.nl/~herbertb/papers/stega_dimva14.pdf \|access-date=2023-08-26 \|url-status=live \|archive-url=https://web.archive.org/web/20230826135254/https://www.cs.vu.nl/~herbertb/papers/stega_dimva14.pdf \|archive-date=2023-08-26}} (10 pages)</ref>
	<ref name="Dourish_2004">{{cite book \|url=https://books.google.com/books?id=DCIy2zxrCqcC&pg=PA7 \|title=Where the Action is: The Foundations of Embodied Interaction \|last=Dourish \|first=Paul \|author-link=Paul Dourish \|publisher=[[MIT Press]] \|date=2004 \|access-date=2023-03-05 \|page=7 \|isbn=0-262-54178-5}}</ref>		<ref name="Dourish_2004">{{cite book \|url=https://books.google.com/books?id=DCIy2zxrCqcC&pg=PA7 \|title=Where the Action is: The Foundations of Embodied Interaction \|last=Dourish \|first=Paul \|author-link=Paul Dourish \|publisher=[[MIT Press]] \|date=2004 \|access-date=2023-03-05 \|page=7 \|isbn=0-262-54178-5}}</ref>
	<ref name="Gates">{{citation \|title=Personal communication \|first=William "Bill" Henry \|last=Gates \|author-link=William Henry Gates III \|date=}} (NB. According to {{citeref\|Jacob\|Jakubowski\|Venkatesan\|2007\|Jacob et al\|style=plain}}.)</ref>		<ref name="Gates">{{citation \|title=Personal communication \|first=William "Bill" Henry \|last=Gates \|author-link=William Henry Gates III \|date=}} (NB. According to {{citeref\|Jacob\|Jakubowski\|Venkatesan\|2007\|Jacob et al\|style=plain}}.)</ref>

imported>DreamRimmer bot II: Standardise list-defined references format (bot)

2025-11-18T13:29:08Z

Standardise list-defined references format (bot)

Show changes

imported>Bryanperk: fixing broken reference link for managed code

2025-06-29T10:38:28Z

fixing broken reference link for managed code

← Previous revision		Revision as of 10:38, 29 June 2025
Line 214:		Line 214:
	<ref name="Kinder_2010">{{cite book \|title=Static Analysis of x86 Executables \|trans-title=Statische Analyse von Programmen in x86 Maschinensprache \|type=Dissertation \|first=Johannes \|last=Kinder \|location=Munich, Germany \|date=2010-09-24 \|publisher=[[Technische Universität Darmstadt]] \|id=D17 \|url=http://infoscience.epfl.ch/record/167546/files/thesis.pdf \|access-date=2021-12-25 \|url-status=live \|archive-url=https://web.archive.org/web/20201112013336/https://os.zhdk.cloud.switch.ch/tind-tmp-epfl/d6128d9d-0768-42e2-9576-1529206df956?response-content-disposition=attachment%3B%20filename%2A%3DUTF-8%27%27thesis.pdf&response-content-type=application%2Fpdf&AWSAccessKeyId=ded3589a13b4450889b2f728d54861a6&Expires=1605231216&Signature=%2FqOKvUdS%2FETy6xHfdFh5q4UJ82k%3D \|archive-date=2020-11-12}} (199 pages)</ref>		<ref name="Kinder_2010">{{cite book \|title=Static Analysis of x86 Executables \|trans-title=Statische Analyse von Programmen in x86 Maschinensprache \|type=Dissertation \|first=Johannes \|last=Kinder \|location=Munich, Germany \|date=2010-09-24 \|publisher=[[Technische Universität Darmstadt]] \|id=D17 \|url=http://infoscience.epfl.ch/record/167546/files/thesis.pdf \|access-date=2021-12-25 \|url-status=live \|archive-url=https://web.archive.org/web/20201112013336/https://os.zhdk.cloud.switch.ch/tind-tmp-epfl/d6128d9d-0768-42e2-9576-1529206df956?response-content-disposition=attachment%3B%20filename%2A%3DUTF-8%27%27thesis.pdf&response-content-type=application%2Fpdf&AWSAccessKeyId=ded3589a13b4450889b2f728d54861a6&Expires=1605231216&Signature=%2FqOKvUdS%2FETy6xHfdFh5q4UJ82k%3D \|archive-date=2020-11-12}} (199 pages)</ref>
	<ref name="Lagarias-Rains-Vanderbei_2001">{{cite book \|title=The Mathematics of Preference, Choice and Order \|first1=Jeffrey "Jeff" Clark \|last1=Lagarias \|author-link1=Jeffrey Clark Lagarias \|first2=Eric Michael \|last2=Rains \|author-link2=Eric Michael Rains \|first3=Robert J. \|last3=Vanderbei \|chapter=The Kruskal Count \|author-link3=Robert J. Vanderbei \|date=2009 \|orig-date=2001-10-13 \|arxiv=math/0110143 \|series=Studies in Choice and Welfare \|editor-first1=Stephen \|editor-last1=Brams \|editor-first2=William V. \|editor-last2=Gehrlein \|editor-first3=Fred S. \|editor-last3=Roberts \|publisher=[[Springer-Verlag]] \|publication-place=Berlin / Heidelberg, Germany \|isbn=978-3-540-79127-0 \|pages=371–391\|doi=10.1007/978-3-540-79128-7_23 }} (22 pages)</ref>		<ref name="Lagarias-Rains-Vanderbei_2001">{{cite book \|title=The Mathematics of Preference, Choice and Order \|first1=Jeffrey "Jeff" Clark \|last1=Lagarias \|author-link1=Jeffrey Clark Lagarias \|first2=Eric Michael \|last2=Rains \|author-link2=Eric Michael Rains \|first3=Robert J. \|last3=Vanderbei \|chapter=The Kruskal Count \|author-link3=Robert J. Vanderbei \|date=2009 \|orig-date=2001-10-13 \|arxiv=math/0110143 \|series=Studies in Choice and Welfare \|editor-first1=Stephen \|editor-last1=Brams \|editor-first2=William V. \|editor-last2=Gehrlein \|editor-first3=Fred S. \|editor-last3=Roberts \|publisher=[[Springer-Verlag]] \|publication-place=Berlin / Heidelberg, Germany \|isbn=978-3-540-79127-0 \|pages=371–391\|doi=10.1007/978-3-540-79128-7_23 }} (22 pages)</ref>
	<ref name="Managed">{{cite web \|title=Managed, Unmanaged, Native: What Kind of Code Is This? \|url=~~http~~://www.developer.com/net/cplus/article.php/2197621/Managed-Unmanaged-Native-What-Kind-of-Code-Is-This.htm \|website=~~developer~~.com \|date=~~28 April 2003~~ \|~~access~~-date=~~2008~~-09-02}}</ref>		<ref name="Managed">{{cite web \|last1=Gregory \|first1=Kate \|title=Managed, Unmanaged, Native: What Kind of Code Is This? \|url=https://www.developer.com/net/cplus/article.php/2197621/Managed-Unmanaged-Native-What-Kind-of-Code-Is-This.htm \|website=Developer.com \|access-date=2008-09-02\|archive-url=https://web.archive.org/web/20090923210338/https://www.developer.com/net/cplus/article.php/2197621/Managed-Unmanaged-Native-What-Kind-of-Code-Is-This.htm \|archive-date=2009-09-23\|date=2003-04-28}}</ref>
	<ref name="Microsoft_PDB">{{cite web \|url=https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/querying-the-dot-pdb-file?view=vs-2022 \|title=Querying the .Pdb File \|website=Microsoft Learn\|date=12 January 2024}}</ref>		<ref name="Microsoft_PDB">{{cite web \|url=https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/querying-the-dot-pdb-file?view=vs-2022 \|title=Querying the .Pdb File \|website=Microsoft Learn\|date=12 January 2024}}</ref>
	<ref name="Microsoft_Symbols">{{cite web \|url=https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/symbols \|title=Symbols for Windows debugging \|website=Microsoft Learn\|date=20 December 2022}}</ref>		<ref name="Microsoft_Symbols">{{cite web \|url=https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/symbols \|title=Symbols for Windows debugging \|website=Microsoft Learn\|date=20 December 2022}}</ref>

imported>Pancho507: Clarified

2025-06-19T23:43:05Z

Clarified

← Previous revision		Revision as of 23:43, 19 June 2025
Line 16:		Line 16:
	In general, each architecture family (e.g., [[x86]], [[ARM architecture family\|ARM]]) has its own [[instruction set architecture]] (ISA), and hence its own specific machine code language. There are exceptions, such as the [[VAX]] architecture, which includes optional support of the [[PDP-11]] instruction set; the [[IA-64]] architecture, which includes optional support of the [[IA-32]] instruction set; and the [[PowerPC 600#PowerPC 615\|PowerPC 615]] microprocessor, which can natively process both [[PowerPC]] and x86 instruction sets.		In general, each architecture family (e.g., [[x86]], [[ARM architecture family\|ARM]]) has its own [[instruction set architecture]] (ISA), and hence its own specific machine code language. There are exceptions, such as the [[VAX]] architecture, which includes optional support of the [[PDP-11]] instruction set; the [[IA-64]] architecture, which includes optional support of the [[IA-32]] instruction set; and the [[PowerPC 600#PowerPC 615\|PowerPC 615]] microprocessor, which can natively process both [[PowerPC]] and x86 instruction sets.

	Machine code is a strictly numerical language, and it is the lowest-level interface to the CPU intended for a programmer. [[Assembly language]] provides a direct map between the numerical machine code and a human-readable mnemonic. In assembly, numerical [[opcode]]s and operands are replaced with mnemonics and labels. For example, the [[x86]] architecture has available the 0x90 opcode; it is represented as [[NOP (code)\|NOP]] in the assembly [[source code]]. While it is possible to write programs directly in machine code, managing individual bits and calculating numerical [[memory address\|addresses]] is tedious and error-prone. Therefore, programs are rarely written directly in machine code. However, an existing machine code program may be edited if the assembly source code is not available.		Machine code is a strictly numerical language, and it is the lowest-level interface to the CPU intended for a programmer. [[Assembly language]] provides a direct map between the numerical machine code and a human-readable mnemonic. In assembly, numerical machine code [[opcode]]s and operands are replaced with mnemonics and labels. For example, the [[x86]] architecture has available the 0x90 opcode; it is represented as [[NOP (code)\|NOP]] in the assembly [[source code]]. While it is possible to write programs directly in machine code, managing individual bits and calculating numerical [[memory address\|addresses]] is tedious and error-prone. Therefore, programs are rarely written directly in machine code. However, an existing machine code program may be edited if the assembly source code is not available.

	The majority of programs today are written in a [[high-level programming language\|high-level language]]. A high-level program may be translated into machine code by a [[compiler]].		The majority of programs today are written in a [[high-level programming language\|high-level language]]. A high-level program may be translated into machine code by a [[compiler]].
Line 160:		Line 160:
	* [[List of programming languages by type#Machine languages\|List of machine languages]]		* [[List of programming languages by type#Machine languages\|List of machine languages]]
	* [[Machine code monitor]]		* [[Machine code monitor]]
			* [[Object code]]
	* [[Overhead code]]		* [[Overhead code]]
	* [[P-code machine]]		* [[P-code machine]]

imported>Belbury: MOS:ORDER, enlarge image

2025-05-30T09:25:03Z

MOS:ORDER, enlarge image

Show changes

← Previous revision		Revision as of 10:38, 29 June 2025
Line 214:		Line 214:
	<ref name="Kinder_2010">{{cite book \|title=Static Analysis of x86 Executables \|trans-title=Statische Analyse von Programmen in x86 Maschinensprache \|type=Dissertation \|first=Johannes \|last=Kinder \|location=Munich, Germany \|date=2010-09-24 \|publisher=[[Technische Universität Darmstadt]] \|id=D17 \|url=http://infoscience.epfl.ch/record/167546/files/thesis.pdf \|access-date=2021-12-25 \|url-status=live \|archive-url=https://web.archive.org/web/20201112013336/https://os.zhdk.cloud.switch.ch/tind-tmp-epfl/d6128d9d-0768-42e2-9576-1529206df956?response-content-disposition=attachment%3B%20filename%2A%3DUTF-8%27%27thesis.pdf&response-content-type=application%2Fpdf&AWSAccessKeyId=ded3589a13b4450889b2f728d54861a6&Expires=1605231216&Signature=%2FqOKvUdS%2FETy6xHfdFh5q4UJ82k%3D \|archive-date=2020-11-12}} (199 pages)</ref>		<ref name="Kinder_2010">{{cite book \|title=Static Analysis of x86 Executables \|trans-title=Statische Analyse von Programmen in x86 Maschinensprache \|type=Dissertation \|first=Johannes \|last=Kinder \|location=Munich, Germany \|date=2010-09-24 \|publisher=[[Technische Universität Darmstadt]] \|id=D17 \|url=http://infoscience.epfl.ch/record/167546/files/thesis.pdf \|access-date=2021-12-25 \|url-status=live \|archive-url=https://web.archive.org/web/20201112013336/https://os.zhdk.cloud.switch.ch/tind-tmp-epfl/d6128d9d-0768-42e2-9576-1529206df956?response-content-disposition=attachment%3B%20filename%2A%3DUTF-8%27%27thesis.pdf&response-content-type=application%2Fpdf&AWSAccessKeyId=ded3589a13b4450889b2f728d54861a6&Expires=1605231216&Signature=%2FqOKvUdS%2FETy6xHfdFh5q4UJ82k%3D \|archive-date=2020-11-12}} (199 pages)</ref>
	<ref name="Lagarias-Rains-Vanderbei_2001">{{cite book \|title=The Mathematics of Preference, Choice and Order \|first1=Jeffrey "Jeff" Clark \|last1=Lagarias \|author-link1=Jeffrey Clark Lagarias \|first2=Eric Michael \|last2=Rains \|author-link2=Eric Michael Rains \|first3=Robert J. \|last3=Vanderbei \|chapter=The Kruskal Count \|author-link3=Robert J. Vanderbei \|date=2009 \|orig-date=2001-10-13 \|arxiv=math/0110143 \|series=Studies in Choice and Welfare \|editor-first1=Stephen \|editor-last1=Brams \|editor-first2=William V. \|editor-last2=Gehrlein \|editor-first3=Fred S. \|editor-last3=Roberts \|publisher=[[Springer-Verlag]] \|publication-place=Berlin / Heidelberg, Germany \|isbn=978-3-540-79127-0 \|pages=371–391\|doi=10.1007/978-3-540-79128-7_23 }} (22 pages)</ref>		<ref name="Lagarias-Rains-Vanderbei_2001">{{cite book \|title=The Mathematics of Preference, Choice and Order \|first1=Jeffrey "Jeff" Clark \|last1=Lagarias \|author-link1=Jeffrey Clark Lagarias \|first2=Eric Michael \|last2=Rains \|author-link2=Eric Michael Rains \|first3=Robert J. \|last3=Vanderbei \|chapter=The Kruskal Count \|author-link3=Robert J. Vanderbei \|date=2009 \|orig-date=2001-10-13 \|arxiv=math/0110143 \|series=Studies in Choice and Welfare \|editor-first1=Stephen \|editor-last1=Brams \|editor-first2=William V. \|editor-last2=Gehrlein \|editor-first3=Fred S. \|editor-last3=Roberts \|publisher=[[Springer-Verlag]] \|publication-place=Berlin / Heidelberg, Germany \|isbn=978-3-540-79127-0 \|pages=371–391\|doi=10.1007/978-3-540-79128-7_23 }} (22 pages)</ref>
	<ref name="Managed">{{cite web \|title=Managed, Unmanaged, Native: What Kind of Code Is This? \|url=~~http~~://www.developer.com/net/cplus/article.php/2197621/Managed-Unmanaged-Native-What-Kind-of-Code-Is-This.htm \|website=~~developer~~.com \|date=~~28 April 2003~~ \|~~access~~-date=~~2008~~-09-02}}</ref>		<ref name="Managed">{{cite web \|last1=Gregory \|first1=Kate \|title=Managed, Unmanaged, Native: What Kind of Code Is This? \|url=https://www.developer.com/net/cplus/article.php/2197621/Managed-Unmanaged-Native-What-Kind-of-Code-Is-This.htm \|website=Developer.com \|access-date=2008-09-02\|archive-url=https://web.archive.org/web/20090923210338/https://www.developer.com/net/cplus/article.php/2197621/Managed-Unmanaged-Native-What-Kind-of-Code-Is-This.htm \|archive-date=2009-09-23\|date=2003-04-28}}</ref>
	<ref name="Microsoft_PDB">{{cite web \|url=https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/querying-the-dot-pdb-file?view=vs-2022 \|title=Querying the .Pdb File \|website=Microsoft Learn\|date=12 January 2024}}</ref>		<ref name="Microsoft_PDB">{{cite web \|url=https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/querying-the-dot-pdb-file?view=vs-2022 \|title=Querying the .Pdb File \|website=Microsoft Learn\|date=12 January 2024}}</ref>
	<ref name="Microsoft_Symbols">{{cite web \|url=https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/symbols \|title=Symbols for Windows debugging \|website=Microsoft Learn\|date=20 December 2022}}</ref>		<ref name="Microsoft_Symbols">{{cite web \|url=https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/symbols \|title=Symbols for Windows debugging \|website=Microsoft Learn\|date=20 December 2022}}</ref>