Hubbry Logo
Machine codeMachine codeMain
Open search
Machine code
Community hub
Machine code
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Machine code
Machine code
Machine code
View on Wikipedia
from Wikipedia

Machine language monitor running on a W65C816S microprocessor, displaying code disassembly and dumps of processor register and memory
Program execution
General concepts
Types of code
Compilation strategies
Notable runtimes
Notable compilers & toolchains

In computing, machine code is data encoded and structured to control a computer's central processing unit (CPU) via its programmable interface. A computer program consists primarily of sequences of machine-code instructions.[1] Machine code is classified as native with respect to its host CPU since it is the language that CPU interprets directly.[2] A 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:

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. 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 615 can natively process both PowerPC and x86 instructions.

Assembly language

[edit]
Translation of assembly into machine code

Assembly language provides a relatively direct mapping from a human-readable source code to machine code. The source code represents numerical codes as mnemonics and labels.[3] For example, NOP represents the x86 architecture opcode 0x90. 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

[edit]

A machine instruction encodes an operation as a pattern of bits based on the specified format for the machine's instruction set.[nb 1][4]

Instruction sets differ in various ways. Instructions of a set might all be the same length or different instructions might have different lengths; they might be smaller than, the same size as, or larger than the word size of the architecture. The number of instructions may be relatively small or large. Instructions may or may not have to be aligned on particular memory boundaries, such as the architecture's word boundary.[4]

An instruction set needs to execute the circuits of a computer's digital logic level. At the digital level, the program needs to control the computer's registers, bus, memory, ALU, and other hardware components.[5] To control a computer's architectural features, machine instructions are created. Examples of features that are controlled using machine instructions:

The criteria for instruction formats include:

  • Instructions most commonly used should be shorter than instructions rarely used.[4]
  • The memory transfer rate of the underlying hardware determines the flexibility of the memory fetch instructions.
  • The number of bits in the address field requires special consideration.[9]

Determining the size of the address field is a choice between space and speed.[9] On some computers, the number of bits in the address field may be too small to access all of the physical memory. Also, virtual address space needs to be considered. Another constraint may be a limitation on the size of registers used to construct the address. Whereas a shorter address field allows the instructions to execute more quickly, other physical properties need to be considered when designing the instruction format.

Instructions can be separated into two types: general-purpose and special-purpose. Special-purpose instructions exploit architectural features that are unique to a computer. General-purpose instructions control architectural features common to all computers.[10]

General-purpose instructions control:

  • Data movement from one place to another
  • Monadic operations that have one operand to produce a result
  • Dyadic operations that have two operands to produce a result
  • Comparisons and conditional jumps
  • Procedure calls
  • Loop control
  • Input/output

Overlapping instruction

[edit]

On processor architectures with variable-length instruction sets[11] (such as Intel's x86 processor family) it is, within the limits of the control-flow resynchronizing phenomenon known as the Kruskal count,[12][11][13][14][15] sometimes possible through opcode-level programming to deliberately arrange the resulting code so that two code paths share a common fragment of opcode sequences.[nb 2] These are called overlapping instructions, overlapping opcodes, overlapping code, overlapped code, instruction scission, or jump into the middle of an instruction.[16][17][18]

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.[19][11][16] 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 loaders which have to fit into boot sectors.[nb 3]

It is also sometimes used as a code obfuscation technique as a measure against disassembly and tampering.[11][14]

The principle is also used in shared code sequences of fat binaries which must run on multiple instruction-set-incompatible processor platforms.[nb 2]

This property is also used to find unintended instructions called gadgets in existing code repositories and is used in return-oriented programming as alternative to code injection for exploits such as return-to-libc attacks.[20][11]

Microcode

[edit]

In some computers, the machine code of the architecture is implemented by an even more fundamental underlying layer called microcode, providing a common machine language interface across a line or family of different models of computer with widely different underlying dataflows. This is done to facilitate porting of machine language programs between different models.[21] An example of this use is the IBM System/360 family of computers and their successors.[22]

Examples

[edit]

IBM 709x

[edit]

The 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:

Generic
S,1-11
12-13 Flag, ignored in some instructions
14-17 unused
18-20 Tag
21-35 Y
Index register control, other than TSX
S,1-2 Opcode
3-17 Decrement
18-20 Tag
21-35 Y

For all but the IBM 7094 and 7094 II, there are three index registers designated A, B and C; indexing with multiple 1 bits in the tag subtracts the logical or of the selected index registers and loading with multiple 1 bits in the tag loads all of the selected index registers. The 7094 and 7094 II have seven index registers, but when they are powered on they are in multiple tag mode, in which they use only the three of the index registers in a fashion compatible with earlier machines, and require a Leave Multiple Tag Mode (LMTM) instruction in order to access the other four index registers.

The effective address is normally Y-C(T), where C(T) is either 0 for a tag of 0, the logical or of the selected index registers in multiple tag mode or the selected index register if not in multiple tag mode. However, the effective address for index register control instructions is just Y.

A flag with both bits 1 selects indirect addressing; the indirect address word has both a tag and a Y field.

In addition to transfer (branch) instructions, these machines have skip instruction that conditionally skip one or two words, e.g., Compare Accumulator with Storage (CAS) does a three way compare and conditionally skips to NSI, NSI+1 or NSI+2, depending on the result.

MIPS

[edit]

The MIPS architecture provides a specific example for a machine code whose instructions are always 32 bits long.[23]: 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 funct to determine the exact operation. The fields used in these types are: 

   6      5     5     5     5      6 bits
[  op  |  rs |  rt |  rd |shamt| funct]  R-type
[  op  |  rs |  rt | address/immediate]  I-type
[  op  |        target address        ]  J-type

rs, rt, and rd indicate register operands; shamt gives a shift amount; and the address or immediate fields contain an operand directly.[23]: 299–301 

For example, adding the registers 1 and 2 and placing the result in register 6 is encoded:[23]: 554  

[  op  |  rs |  rt |  rd |shamt| funct]
    0     1     2     6     0     32     decimal
 000000 00001 00010 00110 00000 100000   binary

Load a value into register 8, taken from the memory cell 68 cells after the location listed in register 3:[23]: 552  

[  op  |  rs |  rt | address/immediate]
   35     3     8           68           decimal
 100011 00011 01000 00000 00001 000100   binary

Jumping to the address 1024:[23]: 552  

[  op  |        target address        ]
    2                 1024               decimal
 000010 00000 00000 00000 10000 000000   binary

Bytecode

[edit]

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.

Storage

[edit]

During execution, machine code is generally stored in RAM although running from ROM is supported by some devices. Regardless, the code may also be cached in more specialized memory to enhance performance. There may be different caches for instructions and data, depending on the architecture.[24]

From the point of view of a process, the machine code lives in code space, a designated part of its address space. In a multi-threading environment, different threads of one process share code space along with data space, which reduces the overhead of context switching considerably as compared to process switching.[25]

Readability

[edit]

Machine code is generally considered to be not human readable,[26] with Douglas Hofstadter comparing it to examining the atoms of a DNA molecule.[27] However, various tools and methods support understanding machine code.

Disassembly decodes machine code to assembly language which is possible since assembly instructions can often be mapped one-to-one to machine instructions.[28]

A decompiler converts machine code to a high-level language, but the result can be relatively obfuscated; hard to understand.

A program can be associated with debug symbols (either embedded in the 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 debug the program. Example include:

See also

[edit]
Look up machine code in Wiktionary, the free dictionary.

Notes

[edit]

References

[edit]

Sources

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Machine code

View on Grokipedia
from Grokipedia
Machine code, also known as machine language or native code, is the lowest-level programming language consisting of binary instructions (sequences of 0s and 1s) that a computer's central processing unit (CPU) can directly execute without further translation. It is inherently tied to a specific computer's instruction set architecture (ISA), such as x86-64 or ARM, which defines the format and operations of these instructions, including opcodes for actions like addition or data movement and operands specifying registers or memory locations. Each instruction is typically represented in a fixed or variable length binary format, often viewed in hexadecimal for readability by humans, but executed solely in binary by the hardware. In the software development process, machine code serves as the final output generated from higher-level abstractions. Source code written in high-level languages like C or Java is first compiled into assembly language—a symbolic, human-readable notation that mirrors machine instructions (e.g., add %rax, %rbx to add values in registers)—and then assembled into machine code by an assembler tool. This binary output is linked with libraries to form an executable file, which the operating system loads into memory for the CPU to fetch, decode, and execute sequentially. Due to its architecture-specific nature, machine code ensures optimal performance but lacks portability across different hardware platforms, necessitating recompilation for each target system. Historically, machine code emerged with the advent of stored-program computers in the mid-20th century, such as the in 1949, where programmers manually entered binary instructions via switches or paper tape, marking the shift from wired or plugboard-based programming to software-defined control. This direct hardware interaction laid the groundwork for modern , though its complexity prompted the development of assembly languages in the 1940s and high-level languages like in 1957 to abstract away binary details. Today, machine code underpins critical systems including operating system kernels, device drivers, and embedded , where efficiency and low-level hardware access are paramount.

Fundamentals

Definition

Machine code is the lowest-level representation of computer programs, consisting of sequences of binary digits (0s and 1s) that a computer's central processing unit (CPU) can directly execute without any further translation or interpretation. These binary instructions form the native language of the hardware, enabling the CPU to perform operations by fetching and processing them sequentially from memory. Unlike , which is written in human-readable forms such as high-level programming languages or assembly mnemonics, machine code is inherently hardware-specific and not intended for direct human comprehension or editing. It typically comprises operation codes (opcodes), which specify the action to be performed, and operands, which indicate the or locations involved in that action. Each instruction in machine code thus defines a precise operation—such as , loading from , or conditional branching—and may incorporate addressing modes to determine how operands are accessed, such as immediate values, register contents, or addresses. The concept of machine code originated in the era of early electronic computers during the 1940s, exemplified by the completed in 1949, where programs were entered as binary instructions punched on paper tape. This marked the realization of stored-program computing, establishing machine code as the foundational medium for instructing hardware to execute computational tasks.

Characteristics

Machine code consists of binary instructions encoded as sequences of bits, typically organized into fixed- or variable-length words such as 8-bit bytes or 32-bit words, which form the fundamental units processed by the CPU. This binary format ensures direct compatibility with hardware logic gates, where each instruction is a pattern of 0s and 1s representing opcodes and operands. Signed values within these instructions or data are commonly represented using notation, which allows efficient arithmetic operations by treating negative numbers as the bitwise inverse plus one. Floating-point representations, when used, adhere to the standard, specifying formats like binary32 (single precision) with a , biased exponent, and mantissa for precise hardware handling of real numbers. A core characteristic of machine code is its tight binding to a specific CPU architecture, such as x86 or , where the valid instruction set, register layout, and addressing modes are defined by the processor's (ISA). This specificity extends to details like byte ordering, or , with architectures employing either big-endian (most significant byte first, as in some PowerPC implementations) or little-endian (least significant byte first, as in x86) to interpret multi-byte values, impacting across systems. Such architecture dependence ensures optimized execution on target hardware but requires recompilation or emulation for compatibility with differing ISAs. Machine code exhibits high efficiency due to its minimal , incurring no interpretation overhead and enabling rapid direct execution by the CPU, often at clock speeds exceeding several gigahertz in modern processors. However, this comes at the cost of limitation to primitive operations, including basic arithmetic (e.g., , ), logical manipulations (e.g., AND, OR), and mechanisms (e.g., jumps, branches), without support for higher-level constructs like loops or conditionals unless emulated through sequences of these basics. During runtime, machine code loaded into memory remains immutable; the program itself does not alter its instructions, as —once common for optimization—now incurs severe performance penalties from cache invalidations and flushes in modern superscalar processors, rendering it rare and generally deprecated. Instruction lengths in machine code vary by , influencing code density—the ratio of executable bytes to functional complexity—with reduced instruction set computing (RISC) designs typically using 1- to 4-byte instructions to balance simplicity and compactness. For instance, base instructions are 32 bits (4 bytes), while compressed variants reduce to 16 bits (2 bytes) for denser code in memory-constrained environments, directly affecting fetch efficiency and overall program size without compromising execution speed.

Generation and Relation to Higher Levels

Assembly Language

Assembly language is a that uses mnemonic codes, such as ADD for or MOV for data movement, and symbolic addresses to represent machine instructions in a human-readable form, with each assembly statement typically corresponding one-to-one to a single machine instruction. These mnemonics serve as symbolic names for opcodes, while symbolic addresses allow programmers to reference memory locations without specifying exact binary values, which are resolved by the assembler during translation to machine code. The syntax of assembly language includes labels for marking memory addresses or jump targets, assembler directives for controlling the assembly process, and macros for defining reusable code blocks. Labels are alphanumeric identifiers placed at the beginning of lines to denote locations, enabling jumps or data references without hardcoding addresses. Directives, such as .data for defining data sections or for setting the origin address, provide instructions to the assembler rather than generating machine code directly. Macros expand to multiple instructions at assembly time, facilitating and reducing repetition, though their implementation varies by assembler. Compared to writing directly in binary machine code, offers advantages in readability and maintainability, making and optimization more accessible while preserving direct hardware control for fine-tuned operations like register manipulation. Programmers can insert small, efficient code segments easily and achieve execution speeds close to machine code without the error-prone task of manual binary entry. Assembly language development began in the late 1940s, with early forms appearing alongside stored-program computers; for instance, the computer in 1949 incorporated an assembler known as Initial Orders, using single-letter mnemonics to simplify instruction entry on paper tape. By the , assemblers had become standard as the first abstraction above machine code, predating high-level languages like . Modern assemblers, such as NASM for x86 architectures and which supports multiple architectures including x86, , and MIPS, continue this tradition with enhanced features for cross-platform development. Assembly code is inherently platform-dependent, as its instructions and addressing modes are tailored to a specific CPU , necessitating reassembly for different processors even if the source code structure remains similar. The assembler translates this architecture-specific source into the corresponding binary machine code on that hardware.

Compilation from Higher-Level Languages

Machine code is produced from higher-level programming languages through a multi-stage compilation process that transforms abstract into platform-specific binary instructions. This automated translation enables developers to write code in expressive languages like C++ or while leveraging the efficiency of machine-executable instructions. The process begins with the and culminates in generating object files containing machine code, which are then linked into runnable executables. The compilation process originated with the developed by in 1957, marking the first successful of automatic code translation from a high-level language to machine code for the computer. Subsequent advancements have standardized the into key phases: , where the source code is scanned to identify tokens such as keywords and identifiers; syntax analysis or , which builds a to verify grammatical structure; semantic analysis, ensuring type compatibility and scope rules; intermediate code generation, producing a platform-independent representation like three-address code; optimization, applying transformations for efficiency; and final code generation, where target-specific machine instructions (opcodes) are emitted. occurs during linking, adjusting addresses in the machine code to resolve references between object modules. Compilers such as GCC () and implement this pipeline to generate machine code. For instance, GCC's front-end parses C++ source into an intermediate representation (GIMPLE), applies middle-end optimizations, and uses a back-end to produce assembly code, which the assembler (gas) converts to object files containing relocatable machine code. The linker (ld) then resolves symbols, performs relocation to fix absolute addresses, and combines object files into an executable binary. Some compilers, including , can directly emit machine code in object files without an explicit assembly step for certain targets. Optimization techniques during compilation enhance the resulting machine code's performance and size. removes unreachable or unused instructions, reducing program footprint and execution time, as implemented in GCC's optimization passes. reorders operations to minimize pipeline stalls on modern processors, improving throughput without altering program semantics; for example, GCC uses this to exploit . In contrast to , just-in-time () compilation generates machine code at runtime for greater portability across architectures. engines like V8 in and Chrome employ to interpret and optimize hot code paths, translating to native machine instructions dynamically via stages including Ignition (interpreter) and (). This approach, while incurring initial overhead, allows runtime adaptations such as architecture-specific optimizations. Some compilers use as an before final machine code emission, bridging high-level abstractions and low-level instructions.

Instruction Set Architecture

Instruction Components

Machine code instructions are composed of distinct structural elements that enable the processor to execute operations on . The primary component is the , a that specifies the operation to be performed, such as or data movement. For instance, in a hypothetical 4-bit (ISA), the 0001 might denote an ADD operation. Following the are the , which provide the or addresses required for the operation. can include register identifiers, immediate values embedded directly in the instruction, or locations. Common types encompass register for fast access to processor registers, immediate for constant values, and indirect addressing where the points to a containing the actual . Instructions are organized into specific formats that determine their overall length and layout. Reduced Instruction Set Computing (RISC) architectures typically employ fixed-length formats, such as 32 bits per instruction, to simplify decoding and fetching. In contrast, Complex Instruction Set Computing (CISC) architectures use variable-length formats, where instructions can range up to 15 bytes in the x86 family, allowing for greater flexibility but increasing complexity in execution. Within these formats, instructions are divided into fields that encode the components. The opcode field commonly occupies 6 to 8 bits to distinguish operations, while register specifiers use about 5 bits each to select from a set of general-purpose registers. Additional function codes, often 6 bits in , may specify sub-operations or variants within the same , enhancing the instruction's versatility without expanding the overall format. Addressing modes further refine operand interpretation, expanding flexibility by specifying how operands are computed, such as absolute addressing for direct locations, relative addressing based on the , or indexed addressing that adds an offset to a base register. The PDP-11 architecture, introduced in 1970, provided eight addressing modes that significantly influenced subsequent ISA designs.

Overlapping Instructions

Overlapping instructions refer to a technique used in some early computer architectures to conserve by allowing the bytes of one instruction to serve as part of another instruction. This was particularly employed in the 1970s and 1980s when was expensive, enabling more compact without fixed alignment. One example is in the implementation of tables in the Burroughs B1700 and B1800 systems, where overlapping allowed efficient storage of diagnostic or correction data within . The approach relies on careful encoding so that the CPU's instruction decoder can correctly interpret the intended instructions despite the shared bytes, often requiring specific alignment or hardware support. However, this complicates debugging, disassembly, and hardware design, as the sequential fetch-decode-execute cycle must account for potential ambiguities. In contrast to variable-length instructions, which use prefix-free codes for unambiguous parsing without byte sharing, overlapping is rare in modern ISAs due to these complexities. A historical example includes certain implementations in mainframes like the variants, though primarily for specialized purposes rather than general code. Modern equivalents appear in code obfuscation or anti-tampering techniques, but for performance-critical systems, fixed- or compressed-length instructions (e.g., RISC-V's 16-bit compressed extensions achieving 20-30% code density improvements) are preferred to simplify pipelining.

Microcode

Microcode consists of low-level sequences of micro-operations, such as register loads, ALU operations, and accesses, that define the internal steps required to execute a single machine instruction visible to the . These micro-operations serve as firmware-like control signals stored in (ROM) or writable control store within the CPU, translating higher-level instructions into primitive hardware actions. In complex instruction set computing (CISC) architectures, plays a key role by decomposing intricate machine instructions into simpler, reduced instruction set computing (RISC)-like primitives that the underlying hardware can execute efficiently. This layer enables the implementation of complex operations without requiring extensive hard-wired logic for each instruction. In some systems, is writable, allowing post-fabrication modifications for bug fixes, performance enhancements, or emulation of legacy instructions across different processor models. Microcode was introduced commercially on a large scale in the family of mainframes, with some models using it starting in 1965, marking a significant advancement in flexible instruction across compatible hardware. Early designs distinguished between horizontal , which provides detailed, unencoded control signals for direct hardware manipulation to maximize parallelism, and vertical , which employs higher-level encoding to compact instructions at the cost of additional decoding overhead. In modern processors, such as those implementing the x86 architecture, maintains with evolving instruction sets and supports security updates delivered via or , including mitigations for vulnerabilities like Spectre released in 2018. By shifting instructional complexity from custom hardware circuitry to programmable control sequences, simplifies CPU design, reduces development time, and facilitates adaptability without full hardware redesigns.

Examples

Historical: IBM 709x

The 709x series, exemplified by the 7090 introduced in 1959, utilized a 36-bit word architecture optimized for scientific and engineering computations, with machine code instructions stored as binary patterns in core memory. This played a pivotal role in early , powering NASA's Mercury and Gemini programs for real-time trajectory computations, flight simulations, and at facilities like the . Instructions followed fixed formats within the 36-bit word, often comprising a 6-bit , a 12-bit decrement field for modifying addresses, a 3-bit tag for indexing, and a 15-bit base address, allowing for operations like with specification. For instance, the add instruction ( 0400 in ) adds the contents of to the accumulator register; for location 000, it is represented as 040000 in , demonstrating direct addressing; with indexing via tag 1 and indirect addressing flagged, it could become 041000 for modified effective address calculation. Key features of the 709x machine code included fixed-length 36-bit instructions, with support for indirect addressing and indexing. The 7094 variant introduced instruction overlap features like Store Lookahead and Transfer Lookahead to enhance execution efficiency. Programming typically involved the FORTRAN Assembly Program (FAP), which translated symbolic code into these binary instructions. The architecture's design influenced later developments by emphasizing flexible addressing and high-speed arithmetic, with 709x systems remaining in use through the 1970s for specialized simulations in and . A brief example of machine code for a simple loop adding successive values (e.g., incrementing an accumulator and branching on zero) in representation might appear as follows, assuming a tagged decrement control (note: simplified and verified against manuals):

+050000 // CLA 0 (clear and add from location 0) +760100 // TZE LOOP (transfer on zero to loop start, tag 1) +011001 // ADD DECR (add decrement for index update; pseudo-op example) LOOP: +040000 // ADD from [memory](/page/Memory) at 0 to AC

+050000 // CLA 0 (clear and add from location 0) +760100 // TZE LOOP (transfer on zero to loop start, tag 1) +011001 // ADD DECR (add decrement for index update; pseudo-op example) LOOP: +040000 // ADD from [memory](/page/Memory) at 0 to AC

This snippet illustrates potential for efficient using indexing and branching.

Modern: MIPS

The MIPS architecture, a 32-bit (RISC) design originating from research at in the early 1980s and commercialized by MIPS Computer Systems starting in 1984, employs fixed-length 32-bit instructions to enhance decoding simplicity and pipeline efficiency. This uniform instruction length eliminates the need for variable-length parsing, distinguishing MIPS from (CISC) designs and facilitating high-performance execution in pipelined processors. A representative MIPS instruction is the ADD operation, which adds the contents of two registers and stores the result in a third, such as ADD $t0, $t1, $t2. In , this encodes as 000000 01001 01010 01000 00000 100000, where the fields comprise a 6-bit (000000 for R-type instructions), 5-bit source register rs (t1as01001),5−bitsourceregisterrt(t1 as 01001), 5-bit source register rt (t2 as 01010), 5-bit destination register rd ($t0 as 01000), 5-bit shift amount (00000), and 6-bit function code (100000 for addition). MIPS exemplifies a load/store architecture, where arithmetic and logical operations occur exclusively on registers using a three-operand format (source1, source2, destination), while memory access is restricted to dedicated load (e.g., LW) and store (e.g., SW) instructions. This design promotes register-intensive code for speed and has found widespread adoption in embedded systems like routers and digital devices, as well as consumer electronics including the Sony PlayStation console, which utilized the MIPS R3000 processor. MIPS notably avoids overlapping instructions to support straightforward pipelining without complex hazard resolution. The architecture evolved with the MIPS64 extension in the 1990s, expanding registers and addresses to 64 bits for handling larger datasets while maintaining with 32-bit code. In 2018, under Wave Computing, MIPS launched the MIPS Open initiative, providing royalty-free access to the 32-bit and 64-bit ISA specifications under proprietary terms to encourage adoption, but the program was discontinued in 2019 amid company financial difficulties. As of 2024, MIPS has ceased development of its proprietary ISA and shifted focus to RISC-V-based architectures. For illustration, consider a basic arithmetic sequence in machine code that loads two values into registers, adds them, and stores the result:

# LW $t1, 0($s0) ; Load first value (assume address in $s0) 100011 10000 01001 0000000000000000 # LW $t2, 4($s0) ; Load second value 100011 10000 01010 0000000000000100 # ADD $t0, $t1, $t2 ; Add them 000000 01001 01010 01000 00000 100000 # SW $t0, 8($s0) ; Store result 101011 10000 01000 0000000000001000

# LW $t1, 0($s0) ; Load first value (assume address in $s0) 100011 10000 01001 0000000000000000 # LW $t2, 4($s0) ; Load second value 100011 10000 01010 0000000000000100 # ADD $t0, $t1, $t2 ; Add them 000000 01001 01010 01000 00000 100000 # SW $t0, 8($s0) ; Store result 101011 10000 01000 0000000000001000

This 128-bit demonstrates the fixed-format encoding across I-type (load/store) and R-type (arithmetic) instructions.

Bytecode

Bytecode represents an abstract set of instructions that serves as a platform-independent , executed by a (VM) rather than directly by hardware processors. This design allows compiled code to run on any system equipped with a compatible VM, abstracting away hardware-specific details. Notable implementations include , which powers the (JVM), the (CIL), utilized within Microsoft's .NET runtime environment, and (Wasm), a binary instruction format for a stack-based virtual machine executed in web browsers and other environments. The origins of bytecode trace back to the UCSD Pascal system, introduced in 1978, where it was implemented as p-code—a portable intermediate code interpreted by a software-based p-machine VM to achieve machine independence across diverse hardware like the and . This innovation enabled the "write once, run anywhere" paradigm, later popularized by , by compiling high-level source code into a single bytecode form that could be deployed without platform-specific recompilation, though it introduces runtime interpretation overhead compared to native execution. In terms of structure, bytecode typically employs compact instructions with a one-byte denoting the operation, followed by variable-length operands providing necessary data or references. Most systems, including the JVM, .NET CIL, and , adopt a stack-based operational model, where instructions like iload (load an integer onto the stack from a ) and iadd (pop two integers from the stack, add them, and push the result) manage computation via an operand stack, contrasting with the register-based approaches in some native architectures. Bytecode generation occurs through compilation from higher-level languages; for example, the Java compiler (javac) translates .java source files into .class files containing bytecode, which the JVM then processes at runtime either by direct interpretation or via just-in-time (JIT) compilation into native machine code for efficiency. Similarly, .NET compilers produce CIL assemblies that the Common Language Runtime (CLR) JIT-compiles as needed. WebAssembly modules are compiled from languages like C++ or Rust and executed via JIT or ahead-of-time compilation in supporting runtimes. This process supports portability but requires VM support, distinguishing bytecode from hardware-specific binaries. A fundamental distinction of bytecode lies in its non-dependence on specific CPU binaries and its emphasis on pre-execution verification for security and correctness; the JVM's bytecode verifier, for instance, statically analyzes code to enforce , prevent stack underflows or overflows, and block unauthorized access, ensuring safe execution even for untrusted code. This verification step, absent in native machine code loading, mitigates risks in distributed environments while maintaining the portability that defines 's role as an intermediate form between and hardware execution.

Object Code

Object code refers to the relocatable form of machine code generated during the compilation process, stored in object files such as .o files on systems or .obj files on Windows. These files contain machine instructions that are not yet fully addressable, including sections like .text for executable and .data for initialized variables, along with a that lists unresolved external references to functions or variables defined elsewhere. The relocatable nature allows the code to be positioned at any during linking, with relocation records specifying adjustments needed for addresses. Common formats for object files include the (ELF), developed in the late 1980s for System V Release 4 Unix and formalized in the 1995 Tool Interface Standard specification, and the (PE) format, introduced with in 1993 as an extension of the Common Object File Format (COFF). Both formats feature headers that identify the target architecture, such as x86 or , and include metadata for entry points, section tables, and information to facilitate subsequent processing. Object files are produced by compilers or assemblers from or assembly, capturing the machine code output in a . The linker then combines multiple object files and libraries, resolving unresolved symbols by matching definitions across modules and adjusting addresses via relocation entries to produce a final . This supports integration with libraries, such as static archives (.a files) that embed code directly into the executable or dynamic shared objects (.so files) that defer resolution to runtime. For production builds, symbols—line numbers, variable names, and other metadata in the object files—are often stripped to reduce and enhance , using tools like the GNU strip utility. The concept of object code evolved from early relocatable loaders in the 1950s, such as those developed for systems like the , where programs were assembled into relocatable modules that loaders could position in memory without full reassembly. This approach addressed the limitations of absolute addressing in early computers, enabling and reuse across jobs.

Implementation Aspects

Storage and Representation

Machine code is typically stored in executable file formats that encapsulate the binary instructions along with necessary metadata for loading and execution by the operating system. Common formats include the (ELF), used primarily on and other Unix-like systems; the Mach-O format, employed by macOS and iOS; and the Common Object File Format (COFF), an older standard that influenced formats like the (PE) on Windows. These formats include metadata such as —unique byte sequences at the file's beginning to identify the type, like 0x7F 'E' 'L' 'F' for ELF—and section tables that delineate regions for code, data, and symbols, enabling the loader to map them appropriately into memory. Self-describing executable formats, which embed sufficient information for independent loading without external tools, emerged in the 1970s with the a.out format in early Unix systems on the PDP-11. Modern formats like ELF and Mach-O build on this by supporting position-independent code (PIC), where instructions use relative addressing rather than absolute locations, facilitating address space layout randomization (ASLR) to enhance security against exploits. Object code, as a precursor compiled from source but not yet linked into a final executable, often resides in these formats before the linking stage produces the persistent binary. In memory, machine code is loaded into RAM as a sequence of contiguous bytes representing the processor-specific instructions, organized into distinct segments: the (or text) segment for executable instructions, the for initialized global variables, and the stack segment for runtime local variables and function calls. These segments are typically mapped to virtual address spaces by the operating system's loader, ensuring isolation and efficient access. For representation and , machine code is often displayed in dumps, where each byte corresponds to an or ; for instance, in x86 , the byte 0x8B encodes the MOV instruction from to a register. In resource-constrained embedded systems, machine code may undergo compression techniques, such as dictionary-based or methods, to reduce storage footprint while allowing on-the-fly decompression during loading. On disk, machine code persists as binary files within these executable formats, with integrity often verified through cryptographic hashing like SHA-256 during to detect tampering or corruption. This hashing ensures that the binary matches the expected digest provided by the distributor, maintaining trustworthiness in deployment.

Execution Process

The execution of machine code occurs through the fetch-decode-execute cycle, a fundamental process in the where instructions and data share a common space, enabling sequential program execution. This cycle, repeated continuously by the (CPU), processes binary instructions stored in to perform computations and control operations. In the fetch stage, the CPU retrieves the next instruction from using the (PC), a special register that holds the of the instruction to be executed. The PC's value is placed on the address bus to access the instruction , loading the into the (IR), after which the PC is incremented to point to the subsequent instruction. This step ensures linear progression through the program unless altered by jumps or other control flows. During the decode stage, the interprets the (operation code) and operands within the fetched instruction, generating control signals to configure the CPU's datapath components such as the (ALU), registers, and memory interfaces. The specifies the operation (e.g., add or load), while operands indicate source registers or immediate values, allowing the to route data accordingly for the impending execution. In complex instruction set architectures (CISC), may assist this decoding by translating instructions into simpler sequences, though the high-level cycle remains unchanged. The execute stage performs the specified operation, such as ALU computations on register data or accesses, and updates the PC if the instruction involves branching. Results are typically written back to registers or , completing the cycle unless an or exception intervenes. In the von Neumann model, interruptions via hardware (e.g., from I/O devices) or exceptions (e.g., ) suspend normal execution, saving the current PC and state before transferring control to a handler routine, which restores flow upon resolution. Modern CPUs enhance this cycle through pipelining, overlapping stages across multiple instructions to increase throughput, typically dividing execution into five stages: fetch, decode, execute (ALU operations), memory (data access), and writeback (result storage to registers). This approach, common in reduced instruction set computing (RISC) designs, allows one instruction to complete per cycle in ideal conditions, though hazards like data dependencies require stalling or forwarding. Further optimizations include superscalar execution, where the CPU issues and executes multiple instructions simultaneously using parallel , as introduced in the processor in 1993 with dual integer units capable of two operations per cycle. Branch prediction mitigates pipeline delays from conditional jumps by speculatively fetching instructions based on historical patterns (e.g., assuming backward branches are taken), flushing the only on mispredictions to maintain high in modern processors. These techniques, building on the core cycle, enable CPUs to achieve effective execution rates far exceeding one instruction per cycle despite the underlying von Neumann bottlenecks.

Human Aspects

Readability Challenges

Machine code, consisting of binary or representations of processor instructions, presents significant readability challenges due to its lack of inherent context and structure. Unlike higher-level languages that use descriptive keywords and abstractions, machine code appears as opaque sequences of bits or digits, such as 10110000 01100001 for an x86 instruction to move a value to a register, making it difficult to discern operations, flows, or program intent without additional tools or . This dense packing of instructions, where each byte or word encodes multiple elements like opcodes, operands, and addressing modes, obscures logical flow and control structures, requiring readers to mentally reconstruct the program's semantics from raw numerical . The imposed by machine code is particularly high, as humans must track low-level details such as register states, addresses, and changes across sequences of instructions, a that exceeds typical capacity without aids. Research on binary program comprehension highlights how this low-level granularity compounds uncertainty, forcing analysts to infer higher-level behaviors from granular hardware interactions, which increases mental effort and rates. For instance, understanding a simple loop in machine code involves simultaneously monitoring accumulator values and jump conditions, a task that demands sustained and often leads to or misinterpretation. Historically, these challenges were even more pronounced in early computing, where programmers entered machine code directly via wired panels or toggle switches, as seen with the in 1945, leading to highly error-prone processes that could take hours for short programs and frequent via manual verification. Such methods amplified risks, exemplified by the 1962 rocket failure, caused by a in the guidance equations—a missing overbar in the source code—leading to incorrect computations, veering the vehicle off course and necessitating its destruction shortly after launch. Studies indicate that , with its mnemonic representations, improves comprehension and productivity over direct binary manipulation, as it reduces the need for numerical memorization and allows focus on logic rather than bit-level encoding. Despite this, machine code's inherent limitations persist, including the absence of high-level abstractions like variables or functions, which prevents intuitive mapping to problem domains and maintains a fundamental barrier to human readability even with partial mitigations like disassembly.

Disassembly and Reverse Engineering

Disassembly is the process of translating binary machine code into human-readable instructions, relying on knowledge of the processor's (ISA) to decode opcodes and operands. This linear or recursive traversal identifies instruction boundaries and generates mnemonic representations, enabling initial analysis of executable files without execution. Tools such as from the GNU Binutils suite perform this by dumping object files and producing assembly output for specific sections, supporting architectures like x86 and . Reverse engineering extends disassembly by reconstructing program semantics and logic from binaries, often through and analysis. Control flow graphs (CFGs) model execution as nodes representing basic blocks of instructions connected by edges for jumps, calls, and returns, aiding in identifying functions and data flows. Frameworks like angr recover CFGs via static lifting to intermediate representations or emulated execution, handling indirect jumps and resolving dynamic behaviors. Prominent tools facilitate both static and dynamic approaches to reverse engineering. IDA Pro, a commercial , offers decompilation to , scripting in IDC or Python, and visualization of CFGs for in-depth binary analysis across platforms. Ghidra, an open-source suite released by the U.S. in 2019, provides disassembly, decompilation, and collaborative features for dissecting compiled code on diverse architectures. For dynamic analysis, the GNU Debugger (GDB) attaches to running processes, setting breakpoints and examining memory to observe runtime behavior and interactions. Reverse engineering faces significant challenges from protective techniques that hinder analysis. Obfuscation alters code structure through renaming, insertion of dead code, or control flow flattening to obscure intent, while code packing compresses and encrypts executables, requiring unpackers before disassembly. Anti-debugging methods, such as timing checks or debugger detection via API calls, disrupt tools like GDB during execution. Legally, the Digital Millennium Copyright Act (DMCA) of 1998 restricts circumvention of technological protections but exempts reverse engineering for interoperability purposes under section 1201(f), provided the actor lawfully possesses the program and adheres to copyright limits. These techniques are vital for practical applications, including where disassembly reveals infection mechanisms and payloads in stripped binaries. In legacy software porting, enables recreation of obsolete systems; for instance, projects like the Rigel Engine disassemble DOS-era games such as to reimplement them on modern hardware for emulation.

References

  1. https://www.techtarget.com/whatis/definition/machine-code-machine-language
  2. https://openstax.org/books/introduction-computer-science/pages/5-4-machine-level-program-representation
  3. https://cs.brown.edu/~adf/programming_languages.html
  4. https://math.hws.edu/javanotes/c1/s1.html
  5. https://diveintosystems.cs.swarthmore.edu/book/C5-Arch/instrexec.html
  6. https://www.csfieldguide.org.nz/en/chapters/programming-languages/machine-code/
  7. https://www.cs.princeton.edu/courses/archive/fall05/cos217/lectures/17ComputerArchitecture.pdf
  8. https://users.cs.fiu.edu/~downeyt/cop3402/machine
  9. https://people.computing.clemson.edu/~mark/edsac.html
  10. https://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html
  11. https://learn.microsoft.com/en-us/cpp/build/ieee-floating-point-representation?view=msvc-170
  12. https://www.embedded.com/the-hardware-and-software-implications-of-endianness/
  13. https://nsec.sjtu.edu.cn/data/MK.Computer.Organization.and.Design.4th.Edition.Oct.2011.pdf
  14. https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-and-self-modifying-code
  15. https://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
  16. https://sourceware.org/binutils/docs/as/RISC_002dV_002dFormats.html
  17. https://cs.ccsu.edu/~gusev/CSC120/Lecture10_AssemblyLanguage.pdf
  18. https://cs.colby.edu/courses/S14/cs232-labs/labs/lab08/assembly.php
  19. https://www.tutorialspoint.com/assembly_programming/assembly_basic_syntax.htm
  20. https://www.investopedia.com/terms/a/assembly-language.asp
  21. https://softwareengineering.stackexchange.com/questions/129123/were-the-first-assemblers-written-in-machine-code
  22. https://www.computer.org/publications/tech-news/insider-membership-news/timeline-of-programming-languages
  23. https://developer.ibm.com/articles/l-gas-nasm/
  24. https://cs.stackexchange.com/questions/98406/does-assembly-language-depend-on-an-assembler-or-the-family-of-processor
  25. https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html
  26. https://www.ibm.com/history/fortran
  27. https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
  28. https://nodejs.org/en/learn/getting-started/the-v8-javascript-engine
  29. https://home.adelphi.edu/~siegfried/cs371/371l10.pdf
  30. http://teaching.idallen.org/dat2343/10f/notes/410_MachineLevelInstructions.html
  31. https://cseweb.ucsd.edu/classes/sp08/cse141/slides/CSE141-MBT-L2.pdf
  32. https://www.cs.cornell.edu/courses/cs3410/2019sp/schedule/slides/09-isa-notes-bw.pdf
  33. https://bytes.usc.edu/files/ee109/slides/EE109Unit16_ProcessorOrg_Notes.pdf
  34. http://www.bitsavers.org/pdf/dec/pdp11/handbooks/EB-23657-18_PDP-11_Architecture_Handbook_1983.pdf
  35. https://tcm.computerhistory.org/ComputerTimeline/Chap38-39-47_pdp11_CS2.pdf
  36. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-107.pdf
  37. https://people.computing.clemson.edu/~mark/uprog.html
  38. https://websites.nku.edu/~foxr/CSC462/notes/microcode.pdf
  39. https://users.ece.cmu.edu/~koopman/misc/byte87a.pdf
  40. https://www.usenix.org/system/files/sec21fall-albartus.pdf
  41. https://csg.csail.mit.edu/6.823S14/lectures/L06.pdf
  42. https://www.ibm.com/docs/en/zos-basic-skills?topic=today-s360-turning-point-in-mainframe-history
  43. http://homepage.cs.uiowa.edu/~jones/arch/notes/13micro.html
  44. https://www.intel.com/content/www/us/en/developer/articles/news/more-information-transient-execution-findings.html
  45. https://www.astronomy.com/observing/apollo-computers-when-ibm-engineers-gave-rockets-a-brain/
  46. https://fedtechmagazine.com/article/2016/10/how-ibm-7094-gave-nasa-and-air-force-computing-superiority-1960s
  47. https://bitsavers.org/pdf/ibm/7090/22-6528-4_7090Manual.pdf
  48. https://bitsavers.org/pdf/ibm/7090/books/Saxon_Programming_the_IBM_7090_1963.pdf
  49. http://ftpmirror.your.org/pub/misc/bitsavers/pdf/ibm/7090/Sherman-ProgrammingThe7090.pdf
  50. https://archive.computerhistory.org/resources/text/Fortran/102663110.05.01.acc.pdf
  51. https://www.scribd.com/document/938260536/S23-4000-7094suppl-InstrOverlap-Oct62
  52. http://www.columbia.edu/cu/computinghistory/7090.html
  53. https://ntrs.nasa.gov/api/citations/19880069935/downloads/19880069935_Optimized.pdf
  54. https://justine.lol/sectorlisp/ibm709.pdf
  55. https://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/mips/index.html
  56. https://www.eecs.harvard.edu/~cs161/notes/mips-part-I.pdf
  57. https://www.d.umn.edu/~gshute/mips/instruction-coding.html
  58. http://www.cs.kzoo.edu/cs230/Resources/MIPS/MachineXL/InstructionFormats.html
  59. https://personal.ntu.edu.sg/smitha/FYP_Gerald/addInstruction.html
  60. https://blog.jyotiprakash.org/mips-instruction-set-architecture
  61. https://minnie.tuhs.org/CompArch/Labs/week1.html
  62. https://thechipletter.substack.com/p/mips
  63. https://www.eetimes.com/mips-goes-open-source/
  64. https://www.eetimes.com/mips-r6-architecture-now-available-for-open-use/
  65. https://webassembly.org/
  66. https://jacobsschool.ucsd.edu/news/release/303
  67. https://docs.oracle.com/javase/tutorial/getStarted/intro/changemylife.html
  68. https://learn.microsoft.com/en-us/dotnet/standard/managed-execution-process
  69. https://docs.oracle.com/cd/E19683-01/817-3677/chapter6-46512/index.html
  70. https://refspecs.linuxfoundation.org/elf/elf.pdf
  71. https://www.cs.cornell.edu/courses/cs4120/2011fa/lectures/lec36-fa11.pdf
  72. https://www-users.cse.umn.edu/~smccaman/courses/8980/spring2020/lectures/04-elf-v2-8up.pdf
  73. https://learn.microsoft.com/en-us/windows/win32/debug/pe-format
  74. https://docs.oracle.com/cd/E19957-01/806-0641/6j9vuqujo/index.html
  75. http://www.staroceans.org/e-book/LinkersAndLoaders.pdf
  76. https://wiki.osdev.org/ELF
  77. https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_A-Brief-History-of-TI-Object-File-Formats.html
  78. https://yossarian.net/res/pub/macho-internals/macho-internals.pdf
  79. https://maskray.me/blog/2024-01-14-exploring-object-file-formats
  80. https://cmake.org/cmake/help/latest/prop_tgt/POSITION_INDEPENDENT_CODE.html
  81. https://www.geeksforgeeks.org/c/memory-layout-of-c-program/
  82. https://www.hackerearth.com/practice/notes/memory-layout-of-c-program/
  83. https://www.cs.uaf.edu/2016/fall/cs301/lecture/09_28_machinecode.html
  84. https://dl.acm.org/doi/10.1145/277044.277185
  85. https://jfrog.com/blog/your-safe-repositories-just-got-safer-with-sha-256/
  86. https://mojoauth.com/compare-hashing-algorithms/sha-256-vs-sha3-224/
  87. http://web.mit.edu/sts.035/www/PDFs/edvac.pdf
  88. https://www.uvm.edu/~cbcafier/cs2210/content/02_basics_of_architecture/fetch_decode_execute.html
  89. http://homepage.cs.uiowa.edu/~jones/assem/notes/04hawk.shtml
  90. https://www.cs.cornell.edu/courses/cs3410/2025sp/notes/cpu_stages.html
  91. https://www.cs.gordon.edu/courses/cs311/lectures-2003/control.html
  92. https://www.cise.ufl.edu/~mssz/CompOrg/CDA-proc.html
  93. https://www.cs.umd.edu/~meesh/411/CA-online/chapter/pipelining-mips-implementation/index.html
  94. http://www.ee.ic.ac.uk/pcheung/teaching/EIE2-IAC/Lecture%208%20-%20Pipelined%20Processor%20%28notes%29.pdf
  95. https://pages.cs.wisc.edu/~markhill/restricted/MKreadings2000percaitlin/ieee_micro_1993_alpert.pdf
  96. https://blog.cloudflare.com/branch-predictor/
  97. https://www.cs.cornell.edu/courses/cs3410/2025sp/notes/pipelining.html
  98. https://www.cs.fsu.edu/~hawkes/cda3101lects/chap1/index.html
  99. https://arxiv.org/pdf/2404.17051
  100. https://rpeszek.github.io/posts/2022-08-30-code-cognitiveload.html
  101. https://almanac.upenn.edu/articles/75th-anniversary-of-the-electronic-numerical-integrator-and-computer-eniac/
  102. https://www.edn.com/mariner-1-destroyed-due-to-code-error-july-22-1962/
  103. https://homepage.cs.uri.edu/faculty/wolfe/book/programming/chapsix.html
  104. https://www2.cs.arizona.edu/~debray/Publications/disasm.pdf
  105. https://docs.angr.io/en/latest/analyses/cfg.html
  106. https://hex-rays.com/ida-pro
  107. https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/1775584/ghidra-the-software-reverse-engineering-tool-youve-been-waiting-for-is-here/
  108. https://sourceware.org/gdb/current/onlinedocs/gdb.html
  109. https://www.vmray.com/malware-obfuscation-techniques/
  110. https://www.copyright.gov/legislation/dmca.pdf
  111. https://intezer.com/blog/malware-reverse-engineering-beginners/
  112. https://lethalguitar.wordpress.com/2019/05/28/re-implementing-an-old-dos-game-in-c-17/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.