79:T44b,**The Contrast with Motorola's Approach** Interestingly, Motorola took the opposite path with their 68000 series processors. With a larger 24-bit address bus (16 MB address space), Motorola architects decided that memory-mapping devices was simpler and consumed addresses that were plentiful. This architectural divergence between Intel and Motorola would shape the computing landscape for decades, with IBM PCs using Intel's port-mapped approach and Apple Macintosh using Motorola's memory-mapped architecture. **Technical Rationale for Separate Address Spaces** Beyond address space conservation, there were sound technical reasons for separating I/O from memory: 1. **Simpler Memory Management**: Memory protection schemes only needed to handle RAM, not I/O devices 2. **Cache Exclusion**: I/O operations needed to bypass CPU caches, which was automatic with separate address spaces 3. **Easier Privilege Separation**: Operating systems could easily restrict user-mode access to I/O ports 4. **Hardware Simplicity**: Separate chip-select logic for memory and I/O simplified motherboard design7a:T7a0,; ============================================= ; Port-Mapped I/O Instructions in x86 Assembly ; ============================================= ; --------------------------------------------- ; Form 1: Immediate Port Address (ports 0-255) ; --------------------------------------------- ; The port number is encoded directly in the instruction ; Read 8 bits from port 0x64 (keyboard status register) in al, 0x64 ; AL = byte read from port 0x64 ; Write 8 bits to port 0x20 (PIC EOI command) mov al, 0x20 ; EOI command value out 0x20, al ; Send to master PIC command port ; Read 16 bits from port 0x1F0 (IDE data register) in ax, 0x1F0 ; AX = word read from port 0x1F0 ; Read 32 bits (available on 386+) in eax, 0x1F0 ; EAX = dword from port ; --------------------------------------------- ; Form 2: Register Indirect (ports 0-65535) ; --------------------------------------------- ; The port number is passed in the DX register mov dx, 0x3F8 ; COM1 data port in al, dx ; Read byte from COM1 mov dx, 0x1F0 ; Primary IDE data port mov cx, 256 ; Number of words to read rep insw ; Read 256 words (512 bytes) to ES:DI ; Write block data to device mov dx, 0x1F0 ; Primary IDE data port mov cx, 256 ; Number of words to write rep outsw ; Write 256 words from DS:SI to port ; --------------------------------------------- ; Privileged Port Access Considerations ; --------------------------------------------- ; In protected mode, the I/O Permission Bitmap (IOPB) ; in the TSS controls which ports user-mode can access. ; Most ports require ring 0 (kernel) privilege. ; This code would only work in kernel mode: mov dx, 0x70 ; RTC index port mov al, 0x00 ; Register 0 (seconds) out dx, al ; Select register mov dx, 0x71 ; RTC data port in al, dx ; Read current seconds value7b:T425,flowchart TB subgraph CPU["CPU Core"] ALU["ALU/Execution Unit"] REG["Registers"] BIU["Bus Interface Unit"] end subgraph BUS["System Bus"] AB["Address Bus (A0-A15)"] DB["Data Bus (D0-D31)"] CB["Control Bus (M/IO#, RD#, WR#)"] end subgraph DECODE["Address Decode Logic"] MIO["M/IO# Signal Check"] MDEC["Memory Address Decoder"] IODEC["I/O Port Decoder"] end subgraph MEM["Memory Subsystem"] RAM["RAM Controller"] ROM["ROM/Flash"] end subgraph IO["I/O Subsystem"] TIMER["Timer (0x40-0x43)"] KBD["Keyboard (0x60-0x64)"] SERIAL["Serial (0x3F8-0x3FF)"] IDE["IDE Controller (0x1F0-0x1F7)"] end ALU --> BIU REG --> BIU BIU --> AB BIU --> DB BIU --> CB AB --> MIO CB --> MIO MIO -->|"M/IO#=1"| MDEC MIO -->|"M/IO#=0"| IODEC MDEC --> RAM MDEC --> ROM IODEC --> TIMER IODEC --> KBD IODEC --> SERIAL IODEC --> IDE7c:Tb54,/* * I/O Privilege Level Management in Operating Systems * * This code illustrates how kernels manage I/O port access through * IOPL settings and I/O Permission Bitmaps. */ #include #include /* EFLAGS bit positions */ #define EFLAGS_IOPL_SHIFT 12 #define EFLAGS_IOPL_MASK (3UL << EFLAGS_IOPL_SHIFT) /* * Set the I/O Privilege Level for the current task. * Only the kernel can modify IOPL. * * @param level: New IOPL value (0-3) * 0 = Only ring 0 (most restrictive) * 3 = All rings (least restrictive) */ void set_iopl(unsigned int level) { unsigned long eflags; /* Validate level is 0-3 */ level &= 3; /* Read current EFLAGS */ asm volatile("pushf; pop %0" : "=r"(eflags)); /* Clear old IOPL and set new value */ eflags &= ~EFLAGS_IOPL_MASK; eflags |= (level << EFLAGS_IOPL_SHIFT); /* Write modified EFLAGS */ asm volatile("push %0; popf" : : "r"(eflags)); } /* * Linux kernel approach: I/O Permission Bitmap in TSS * * Even with IOPL=0, the kernel can grant access to specific * ports by manipulating the I/O Permission Bitmap (IOPB). * * The IOPB is a bitmap where each bit corresponds to a port: * Bit = 0: Port access allowed * Bit = 1: Port access denied (triggers #GP) */ /* Structure representing the Task State Segment with IOPB */ struct tss_iopb { /* First 104 bytes: Standard TSS fields */ uint32_t reserved1[26]; /* Offset 102: I/O Map Base Address */ uint16_t io_bitmap_base; /* I/O Permission Bitmap: 8192 bytes for 65536 ports */ /* Each byte covers 8 ports; bit 0 = first port */ uint8_t io_bitmap[8192 + 1]; /* +1 for terminator byte */ }; /* * Grant port access to user-mode process (Linux ioperm syscall) * * @param from: Starting port number * @param num: Number of consecutive ports * @param turn_on: 1 to grant access, 0 to revoke */ long sys_ioperm(unsigned long from, unsigned long num, int turn_on) { struct thread_struct *t = ¤t->thread; unsigned int port; /* Only root can grant port access */ if (!capable(CAP_SYS_RAWIO)) return -EPERM; /* Validate port range */ if (from + num > 65536) return -EINVAL; /* Allocate IOPB if not already present */ if (!t->io_bitmap_ptr) { t->io_bitmap_ptr = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL); /* Initialize all bits to 1 (deny all) */ memset(t->io_bitmap_ptr, 0xff, IO_BITMAP_BYTES); } /* Set or clear bits for requested port range */ for (port = from; port < from + num; port++) { if (turn_on) /* Clear bit = allow access */ clear_bit(port, t->io_bitmap_ptr); else /* Set bit = deny access */ set_bit(port, t->io_bitmap_ptr); } return 0; }7d:Tcf1,/* * Legacy Keyboard Controller (8042) Port I/O Operations * * Port 0x60: Data Port (read keyboard scan codes, write commands to keyboard) * Port 0x64: Status Port (read) / Command Port (write) */ #include /* Port definitions */ #define KBD_DATA_PORT 0x60 #define KBD_STATUS_PORT 0x64 #define KBD_COMMAND_PORT 0x64 /* Status register bits */ #define KBD_STATUS_OBF 0x01 /* Output Buffer Full - data available */ #define KBD_STATUS_IBF 0x02 /* Input Buffer Full - controller busy */ #define KBD_STATUS_SYS 0x04 /* System Flag - POST complete */ #define KBD_STATUS_CMD 0x08 /* Command/Data - 1=command, 0=data */ #define KBD_STATUS_UNLOCKED 0x10 /* Keyboard unlocked */ #define KBD_STATUS_AUX 0x20 /* Auxiliary output buffer (mouse data) */ #define KBD_STATUS_TIMEOUT 0x40 /* Timeout error */ #define KBD_STATUS_PARITY 0x80 /* Parity error */ /* Low-level port I/O functions (x86 specific) */ static inline uint8_t inb(uint16_t port) { uint8_t value; asm volatile("inb %1, %0" : "=a"(value) : "Nd"(port)); return value; } static inline void outb(uint16_t port, uint8_t value) { asm volatile("outb %0, %1" : : "a"(value), "Nd"(port)); } /* I/O delay for slow devices (traditionally write to unused port 0x80) */ static inline void io_wait(void) { outb(0x80, 0); /* POST code port - used as delay */ } /* * Wait for the keyboard controller input buffer to be empty. * Required before sending commands or data to the controller. * * @returns: 0 on success, -1 on timeout */ int kbd_wait_input_buffer_empty(void) { int timeout = 100000; while (timeout--) { if (!(inb(KBD_STATUS_PORT) & KBD_STATUS_IBF)) return 0; io_wait(); } return -1; /* Timeout - controller not responding */ } /* * Wait for keyboard data to be available in output buffer. * * @returns: 0 on success (data available), -1 on timeout */ int kbd_wait_output_buffer_full(void) { int timeout = 100000; while (timeout--) { if (inb(KBD_STATUS_PORT) & KBD_STATUS_OBF) return 0; io_wait(); } return -1; /* Timeout - no data available */ } /* * Read a scan code from the keyboard. * Blocks until data is available or timeout. * * @returns: Scan code (0-255), or -1 on error */ int kbd_read_scancode(void) { /* Wait for output buffer to have data */ if (kbd_wait_output_buffer_full() < 0) return -1; /* Check for errors */ uint8_t status = inb(KBD_STATUS_PORT); if (status & (KBD_STATUS_TIMEOUT | KBD_STATUS_PARITY)) return -1; /* Read and return the scan code */ return inb(KBD_DATA_PORT); } /* * Send a command to the keyboard controller (not the keyboard itself). * * @param cmd: Command byte to send * @returns: 0 on success, -1 on timeout */ int kbd_controller_command(uint8_t cmd) { if (kbd_wait_input_buffer_empty() < 0) return -1; outb(KBD_COMMAND_PORT, cmd); return 0; } /* * Example: Disable the keyboard (during sensitive operations) */ int kbd_disable(void) { return kbd_controller_command(0xAD); /* Disable keyboard interface */ } /* * Example: Enable the keyboard */ int kbd_enable(void) { return kbd_controller_command(0xAE); /* Enable keyboard interface */ }7e:Tf84,/* * 8253/8254 Programmable Interval Timer (PIT) Control * * Port 0x40: Channel 0 data (system timer, IRQ 0) * Port 0x41: Channel 1 data (historically DRAM refresh) * Port 0x42: Channel 2 data (PC speaker) * Port 0x43: Mode/Command register (write only) */ #include /* PIT Port definitions */ #define PIT_CHANNEL0 0x40 #define PIT_CHANNEL1 0x41 #define PIT_CHANNEL2 0x42 #define PIT_COMMAND 0x43 /* PIT oscillator frequency: 1.193182 MHz */ #define PIT_FREQUENCY 1193182 /* Command register bit fields */ #define PIT_CMD_CHANNEL(x) ((x) << 6) /* Channel select (0-2, 3=read-back) */ #define PIT_CMD_ACCESS_LATCH 0x00 /* Latch count value */ #define PIT_CMD_ACCESS_LO 0x10 /* Access low byte only */ #define PIT_CMD_ACCESS_HI 0x20 /* Access high byte only */ #define PIT_CMD_ACCESS_LOHI 0x30 /* Access low then high byte */ #define PIT_CMD_MODE(x) ((x) << 1) /* Operating mode (0-5) */ #define PIT_CMD_BINARY 0x00 /* Binary counting */ #define PIT_CMD_BCD 0x01 /* BCD counting */ /* Operating modes */ #define PIT_MODE_INTERRUPT 0 /* Mode 0: Interrupt on terminal count */ #define PIT_MODE_ONESHOT 1 /* Mode 1: Hardware retriggerable one-shot */ #define PIT_MODE_RATEGEN 2 /* Mode 2: Rate generator (square wave, 50% duty) */ #define PIT_MODE_SQUAREWAVE 3 /* Mode 3: Square wave generator */ #define PIT_MODE_SWSTROBE 4 /* Mode 4: Software triggered strobe */ #define PIT_MODE_HWSTROBE 5 /* Mode 5: Hardware triggered strobe */ extern void outb(uint16_t port, uint8_t value); extern uint8_t inb(uint16_t port); /* * Configure a PIT channel with specified frequency. * * @param channel: PIT channel (0-2) * @param mode: Operating mode (see PIT_MODE_* constants) * @param frequency: Desired frequency in Hz */ void pit_configure(uint8_t channel, uint8_t mode, uint32_t frequency) { /* Calculate divisor from desired frequency */ uint16_t divisor = PIT_FREQUENCY / frequency; /* Minimum divisor is 2 (maximum frequency ~596.6 kHz) */ if (divisor < 2) divisor = 2; /* Build command byte: * - Select channel * - Access mode: low byte then high byte * - Operating mode * - Binary counting */ uint8_t command = PIT_CMD_CHANNEL(channel) | PIT_CMD_ACCESS_LOHI | PIT_CMD_MODE(mode) | PIT_CMD_BINARY; /* Write command byte */ outb(PIT_COMMAND, command); /* Write divisor low byte then high byte to channel data port */ uint16_t data_port = PIT_CHANNEL0 + channel; outb(data_port, divisor & 0xFF); /* Low byte */ outb(data_port, (divisor >> 8) & 0xFF); /* High byte */ } /* * Configure Channel 0 for 100 Hz system tick (10ms period). * This generates IRQ 0 at the specified rate for the system timer. */ void pit_init_system_timer(uint32_t hz) { /* Channel 0, Mode 2 (rate generator), specified frequency */ pit_configure(0, PIT_MODE_RATEGEN, hz); } /* * Configure Channel 2 for PC speaker tone generation. * Must also enable speaker via system control port. * * @param frequency: Tone frequency in Hz (e.g., 440 for A4 note) */ void pit_set_speaker_frequency(uint32_t frequency) { /* Channel 2, Mode 3 (square wave), specified frequency */ pit_configure(2, PIT_MODE_SQUAREWAVE, frequency); } /* * Read the current count value from a PIT channel. * * @param channel: PIT channel (0-2) * @returns: Current 16-bit count value */ uint16_t pit_read_count(uint8_t channel) { /* Send latch command for specified channel */ outb(PIT_COMMAND, PIT_CMD_CHANNEL(channel) | PIT_CMD_ACCESS_LATCH); /* Read low byte then high byte */ uint16_t data_port = PIT_CHANNEL0 + channel; uint16_t count = inb(data_port); /* Low byte */ count |= (inb(data_port) << 8); /* High byte */ return count; }71:{"json":{"id":"seed_6e058a60e6b3dc2b44ab5bb5ac564866","slug":"memory-mapped-io","category":"Operating Systems","topic":"Memory-Mapped I/O","title":"Memory-Mapped I/O","description":"Master the fundamental I/O addressing paradigms that enable CPU-device communication. Explore port-mapped and memory-mapped I/O architectures, understand address space design decisions, compare their performance and complexity tradeoffs, and examine the hardware support mechanisms that enable efficient I/O operations in modern computer systems.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_e06f367ab5abc393995cbdeebe23e7f9","title":"Port-Mapped I/O","order":0,"content":[{"id":"opening-io-addressing","title":"The Fundamental I/O Addressing Problem","content":[{"data":{"content":"At the heart of every computer system lies a fundamental architectural question: **How does the CPU communicate with peripheral devices?** This seemingly simple question has profound implications for processor design, operating system architecture, and overall system performance.\n\nWhen a CPU needs to send data to a disk controller, read a character from a keyboard, or control a network interface, it must have a mechanism to address these devices and transfer data. The addressing mechanism chosen impacts everything from instruction set design to memory management hardware to the complexity of device drivers.\n\nTwo primary paradigms have emerged in computer architecture history: **Port-Mapped I/O (PMIO)** and **Memory-Mapped I/O (MMIO)**. This page provides a comprehensive exploration of Port-Mapped I/O, establishing the foundation for understanding why modern systems often prefer memory-mapped approaches while PMIO remains relevant in specific contexts."},"type":"text"},{"data":{"icon":"Target","title":"Learning Objectives","content":"By the end of this page, you will understand: (1) The historical and architectural origins of Port-Mapped I/O, (2) How dedicated I/O address spaces separate device communication from memory access, (3) The specialized CPU instructions used for port-based I/O operations, (4) Hardware signal mechanisms that distinguish I/O from memory cycles, (5) The advantages and limitations of the PMIO approach, and (6) Real-world examples of PMIO in x86 and legacy architectures.","variant":"info"},"type":"callout"}]},{"id":"historical-context","title":"Historical Context and Origins","content":[{"data":{"content":"To truly understand Port-Mapped I/O, we must travel back to the early days of computing when architectural decisions were driven by hardware constraints that seem foreign by today's standards.\n\n**The Memory Address Space Pressure**\n\nIn the 1970s and early 1980s, microprocessors had severely limited address buses. The Intel 8080, for instance, featured a 16-bit address bus, providing access to only 64 KB of memory. The Intel 8086 expanded this to 20 bits (1 MB), but even this was considered generous. Every byte of this precious address space was valuable, and architects faced a critical decision: should device registers consume addresses from this limited pool?\n\nThe answer for Intel and many other manufacturers was a resounding **no**. A separate I/O address space would preserve the entire memory address range for RAM and ROM, while providing dedicated addresses for device communication. This philosophy became known as **Port-Mapped I/O** or **Isolated I/O**."},"type":"text"},{"data":{"icon":"Info","title":"Intel's Architectural Philosophy","content":"Intel's x86 architecture, starting with the 8086, implemented a completely separate 64 KB I/O address space. This decision, made in 1978, continues to influence PC architecture today, as modern x86-64 processors maintain backward compatibility with this I/O port mechanism.","variant":"note"},"type":"callout"},{"data":{"content":"$79"},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"io-address-space","title":"The I/O Address Space Architecture","content":[{"data":{"content":"Port-Mapped I/O creates a completely separate address space from memory—a parallel universe of addresses dedicated exclusively to I/O devices. Understanding this architectural separation is crucial for grasping how PMIO operates at the hardware level.\n\n**The Dual Address Space Model**\n\nConsider a system with a 32-bit processor. Under the dual address space model:\n\n- **Memory Address Space**: 4 GB of addressable memory (0x00000000 to 0xFFFFFFFF)\n- **I/O Address Space**: Typically 64 KB of addressable I/O ports (0x0000 to 0xFFFF on x86)\n\nThese two spaces are **completely independent**. An instruction that accesses memory address 0x1000 and an instruction that accesses I/O port 0x1000 reference entirely different locations despite the identical numeric address. The CPU distinguishes between them through different instruction opcodes and control signals."},"type":"text"},{"data":{"rows":[["0x000-0x00F","DMA Controller 1","8-bit DMA channels 0-3","IBM PC (1981)"],["0x020-0x021","PIC 1","Master interrupt controller","IBM PC"],["0x040-0x043","PIT (Timer)","System timer, speaker","IBM PC"],["0x060-0x064","Keyboard Controller","PS/2 keyboard and mouse","IBM PC/AT"],["0x070-0x077","RTC/CMOS","Real-time clock, BIOS settings","IBM PC/AT"],["0x0A0-0x0A1","PIC 2","Slave interrupt controller","IBM PC/AT"],["0x0C0-0x0DF","DMA Controller 2","16-bit DMA channels 5-7","IBM PC/AT"],["0x1F0-0x1F7","Primary IDE","First hard disk controller","IBM PC/AT"],["0x2F8-0x2FF","COM2","Second serial port","IBM PC"],["0x3F0-0x3F7","Floppy Controller","Floppy disk operations","IBM PC"],["0x3F8-0x3FF","COM1","First serial port","IBM PC"]],"caption":"x86 I/O Address Space Layout (Traditional PC)","headers":["Port Range","Device/Controller","Purpose","Legacy Origin"]},"type":"table"},{"data":{"content":"**Port Address Sizing**\n\nI/O port addresses on x86 are 16 bits wide, theoretically allowing 65,536 distinct ports. However, many legacy devices only decode the lower 10 bits (0x000-0x3FF), creating \"port aliases\" where ports like 0x400 would respond to accesses intended for 0x000. This legacy constraint significantly reduced the usable port space.\n\n**Port Width and Access Patterns**\n\nUnlike memory, which is typically byte-addressable with word-aligned access, I/O ports have explicit widths:\n\n- **8-bit ports**: Single byte read/write (IN AL, port / OUT port, AL)\n- **16-bit ports**: Word read/write (IN AX, port / OUT port, AX)\n- **32-bit ports**: Double-word read/write (IN EAX, port / OUT port, EAX)\n\nThe physical device determines the port width. Accessing a 16-bit port with an 8-bit instruction typically reads only the lower byte, while accessing an 8-bit port with a 16-bit instruction may produce undefined behavior. Device drivers must match access width to hardware specifications."},"type":"text"},{"data":{"icon":"AlertCircle","title":"Port Aliasing Hazard","content":"Legacy ISA devices often decoded only 10 address bits, meaning port 0x400 would respond to the same signals as port 0x000. Modern PCI devices properly decode the full 16-bit address, but mixing legacy and modern devices can create conflicts if not carefully managed through system resource allocation.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"cpu-instructions","title":"CPU Instructions for Port I/O","content":[{"data":{"content":"Port-Mapped I/O requires **dedicated CPU instructions** distinct from memory load/store operations. The processor's instruction set must explicitly support this separate address space. Let's examine the x86 implementation in detail, as it represents the most widely-deployed PMIO architecture.\n\n**The x86 IN and OUT Instructions**\n\nThe x86 architecture provides four primary instructions for port I/O:\n\n1. **IN** - Read data from an I/O port into a CPU register\n2. **OUT** - Write data from a CPU register to an I/O port\n3. **INS** - Read a string of data from a port (block transfer)\n4. **OUTS** - Write a string of data to a port (block transfer)\n\nEach instruction comes in two forms: immediate port addressing (for ports 0x00-0xFF) and register-indirect addressing (for ports 0x0000-0xFFFF)."},"type":"text"},{"data":{"fileName":"port_io_instructions.asm","languages":[{"code":"$7a","label":"x86 Assembly","value":"x86asm"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Instruction Timing and Bus Cycles**\n\nPort I/O instructions generate distinct bus cycles from memory operations. When the CPU executes an IN or OUT instruction:\n\n1. The port address is placed on the address bus (lower 16 bits)\n2. A special **I/O signal line** (M/IO# on Intel processors) is asserted to indicate I/O operation\n3. Data is transferred on the data bus\n4. The I/O cycle completes (typically with wait states for slow devices)\n\nHistorically, I/O instructions were slower than memory operations because:\n- Devices often required insertion of wait states\n- No caching or pipelining of I/O operations\n- Bus arbitration overhead for each I/O cycle"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Modern Perspective","content":"On modern x86 processors, IN/OUT instructions are significantly more expensive than memory operations—often 10-20 clock cycles versus 1-4 for cached memory. This performance gap is one reason modern device drivers prefer memory-mapped I/O when available, falling back to port I/O only for legacy device compatibility.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"hardware-signals","title":"Hardware Signal Architecture","content":[{"data":{"content":"The separation between memory and I/O address spaces is enforced at the hardware level through dedicated control signals. Understanding these signals is essential for comprehending how I/O operations physically traverse the system bus and reach their intended devices.\n\n**The M/IO# Control Signal**\n\nIntel processors use a control line called **M/IO#** (Memory/IO, active low for I/O). This single bit distinguishes between memory and I/O bus cycles:\n\n- **M/IO# = 1**: Memory cycle - address bus refers to RAM/ROM location\n- **M/IO# = 0**: I/O cycle - address bus refers to port address\n\nChipset logic and address decoders monitor this signal to route transactions to the appropriate subsystem. Memory controllers ignore cycles where M/IO# = 0, while I/O controllers ignore cycles where M/IO# = 1."},"type":"text"},{"data":{"height":"500px","mermaidSyntax":"$7b"},"type":"mermaid-excalidraw"},{"data":{"content":"**Complete Bus Cycle for Port I/O**\n\nLet's trace through a complete I/O read operation when executing `IN AL, 0x64`:\n\n**Phase 1: Address Phase**\n1. CPU places port address 0x0064 on address lines A0-A15\n2. CPU asserts M/IO# = 0 (indicating I/O cycle)\n3. CPU asserts RD# = 0 (read operation)\n4. Address and control signals stabilize (setup time)\n\n**Phase 2: Decode Phase**\n5. Chipset detects M/IO# = 0, routes to I/O decode logic\n6. I/O decoder matches 0x64 to keyboard controller range\n7. Keyboard controller's chip-select is activated\n\n**Phase 3: Data Phase**\n8. Keyboard controller places status byte on data bus D0-D7\n9. Data stabilizes (device response time, possibly with wait states)\n10. CPU samples data bus, captures byte in AL register\n\n**Phase 4: Completion**\n11. CPU deasserts RD# and M/IO#\n12. Keyboard controller releases data bus\n13. Bus cycle complete, CPU proceeds to next instruction"},"type":"text"},{"data":{"icon":"Info","title":"Wait State Insertion","content":"Unlike memory cycles that complete in predictable time, I/O cycles often require the device to signal readiness via a READY or WAIT signal. Slow devices can stretch bus cycles by inserting wait states, causing the CPU to pause until data is available. This mechanism ensures reliable communication with devices of varying speeds.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"os-implications","title":"Operating System Implications","content":[{"data":{"content":"Port-Mapped I/O has significant implications for operating system design, particularly in areas of privilege management, protection, and driver architecture. The separate I/O address space provides opportunities for security isolation but also introduces complexity.\n\n**I/O Privilege Level (IOPL)**\n\nThe x86 protected mode introduces an IOPL field in the EFLAGS register, occupying bits 12-13. This two-bit field (values 0-3) determines the minimum privilege level required to execute I/O instructions:\n\n- **IOPL = 0**: Only ring 0 (kernel) can execute IN/OUT\n- **IOPL = 3**: All privilege levels can execute IN/OUT\n\nTypically, operating systems set IOPL = 0, restricting port access to kernel mode code. Any attempt by user-mode code to execute IN or OUT triggers a General Protection Fault (#GP)."},"type":"text"},{"data":{"fileName":"iopl_management.c","languages":[{"code":"$7c","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**The I/O Permission Bitmap (IOPB)**\n\nFor cases where specific user-mode processes need controlled port access (such as old DOS games running in compatibility mode, or specialized industrial control software), x86 provides a finer-grained mechanism: the I/O Permission Bitmap.\n\nThe IOPB is stored in the Task State Segment (TSS) and provides per-port access control:\n\n- Each bit represents one I/O port\n- Bit = 0: Access permitted regardless of CPL\n- Bit = 1: Access triggers #GP if CPL > IOPL\n- Full bitmap size: 8192 bytes for 65,536 ports\n\nThe operating system can grant access to specific ports (like a parallel port for a printing application) while blocking all others. This enables running legacy applications that perform direct I/O without giving them blanket hardware access."},"type":"text"},{"data":{"items":["**IOPL Field**: Global I/O privilege level in EFLAGS, typically set to 0 by the kernel","**I/O Permission Bitmap**: Per-task, per-port access control enabling selective port grants","**Ring Isolation**: Instructions like LGTR, LIDT execute only in ring 0, protecting system state","**Context Switch Overhead**: IOPB switching during task switches adds measurable latency","**Virtualization Support**: VT-x provides I/O bitmap for VM exits on port access"],"title":{"icon":"CheckCircle","text":"Protection Mechanisms for Port I/O","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":5},{"id":"practical-examples","title":"Practical Port I/O Examples","content":[{"data":{"content":"Understanding port I/O programming requires examining real-world device interactions. Let's explore comprehensive examples of port-based device communication, covering common PC peripherals that still rely on PMIO.\n\n**Example 1: Reading the Keyboard Controller Status**\n\nThe legacy keyboard controller (Intel 8042 or compatible) uses port 0x64 for status/command and 0x60 for data."},"type":"text"},{"data":{"fileName":"keyboard_port_io.c","languages":[{"code":"$7d","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Example 2: Programmable Interval Timer (PIT) Configuration**\n\nThe 8253/8254 PIT is a classic example of a register-heavy device controlled entirely through ports. It uses ports 0x40-0x43 to program three independent timer channels."},"type":"text"},{"data":{"fileName":"pit_timer_port_io.c","languages":[{"code":"$7e","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":6},{"id":"advantages-limitations","title":"Advantages and Limitations of Port-Mapped I/O","content":[{"data":{"content":"Port-Mapped I/O represents a deliberate architectural trade-off. Understanding its strengths and weaknesses is crucial for appreciating why it was adopted, where it remains useful, and why modern systems increasingly favor memory-mapped alternatives.\n\n**Advantages of Port-Mapped I/O**"},"type":"text"},{"data":{"items":["**Complete Address Space Preservation**: The entire memory address range remains available for RAM and ROM. On early systems with 64 KB or 1 MB address spaces, this was critically important.","**Automatic Cache Bypass**: I/O ports are inherently non-cacheable. No need for cache coherency concerns or memory type configuration—I/O instructions always access physical devices.","**Simple Protection Model**: The IOPL/IOPB mechanism provides straightforward kernel-mode restriction of port access. No memory protection table modifications needed.","**Clear Semantic Distinction**: Distinct instructions (IN/OUT vs MOV) make I/O operations immediately recognizable in code, simplifying driver analysis and debugging.","**Guaranteed Non-Optimization**: Compilers cannot reorder or eliminate I/O instructions as they might with memory operations. Each IN/OUT has observable side effects.","**Hardware Simplicity**: Separate decode logic for I/O simplifies memory controller design—no need to carve out \"memory holes\" for device regions."],"title":{"icon":"CheckCircle","text":"Key Advantages","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"items":["**Limited Address Space**: Only 65,536 ports available on x86. Modern devices with large register sets or memory buffers cannot use PMIO efficiently.","**Instruction Set Dependency**: Requires dedicated CPU instructions. Processors without IN/OUT equivalents cannot support PMIO, reducing architectural portability.","**Performance Overhead**: I/O instructions are slow (10-20+ cycles on modern CPUs). Memory-mapped access via cached memory transactions is significantly faster.","**No Burst Transfers**: Each port access is a separate bus transaction. Large data transfers require repetitive IN/OUT sequences versus single DMA-like memory copies.","**Limited Data Width**: Port operations are typically limited to 8/16/32 bits. Modern memory interfaces support 64-bit or wider transactions.","**C Language Challenges**: Standard C has no port I/O primitives. Inline assembly or compiler extensions required, reducing code portability.","**Virtualization Complexity**: VMs must trap and emulate all port I/O, adding overhead. Memory-mapped I/O can leverage hardware pass-through more efficiently."],"title":{"icon":"XCircle","text":"Key Limitations","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"Lightbulb","title":"The Modern Verdict","content":"Port-Mapped I/O excels in scenarios involving legacy compatibility, low-speed control interfaces, and systems where explicit I/O semantics aid debugging. However, for high-performance devices (network cards, GPUs, NVMe drives), memory-mapped I/O is overwhelmingly preferred due to its superior bandwidth and integration with modern memory subsystems.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Port-Mapped I/O Fundamentals","content":[{"data":{"content":"This page has provided a comprehensive foundation in Port-Mapped I/O, establishing the baseline for understanding I/O addressing paradigms. Let's consolidate the essential concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Separate Address Spaces**: PMIO creates a dedicated I/O address space (64 KB on x86) completely distinct from memory addresses.","**Dedicated Instructions**: Special CPU instructions (IN, OUT on x86) access ports, distinguishing I/O operations from memory operations.","**Hardware Signal Differentiation**: The M/IO# control signal routes transactions to either memory or I/O subsystems.","**Protection via IOPL/IOPB**: Operating systems restrict port access through privilege levels and per-task permission bitmaps.","**Historical Motivation**: Address space conservation drove PMIO adoption on memory-constrained early microprocessors.","**Performance Trade-offs**: PMIO provides simplicity and clear semantics but sacrifices performance compared to memory-mapped approaches.","**Legacy Prevalence**: Despite limitations, PMIO remains essential for legacy PC peripherals (keyboard, timer, serial ports)."],"title":{"icon":"Target","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Looking Ahead**\n\nWith a solid understanding of Port-Mapped I/O, we're prepared to explore its counterpart: Memory-Mapped I/O. The next page examines how MMIO unifies device and memory access under a single addressing scheme, enabling the high-performance I/O that modern devices demand."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now possess a thorough understanding of Port-Mapped I/O—its architecture, instructions, hardware implementation, protection mechanisms, and trade-offs. This knowledge forms the essential foundation for comparing I/O paradigms and understanding why modern device drivers make specific addressing choices.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_6cba5aae5b5e0c0ab6173afa4a62e843","title":"Memory-Mapped I/O","order":1,"content":null,"isLocked":true},{"id":"seed_6aa7029a53f95ca41973b680e6bd71fa","title":"Address Space Usage","order":2,"content":null,"isLocked":true},{"id":"seed_ded80e8a1597727179744850d5cb7a1d","title":"Comparison","order":3,"content":null,"isLocked":true},{"id":"seed_2bf8fc8b4c9ab95fcedb56118e30e387","title":"Hardware Support","order":4,"content":null,"isLocked":true}]}}