RECONSTRUCTED APPENDIX H — ADVANCED FEATURES
reconstructed residue TOC, not a claimed recovered original. The strongest source constraints are: Collins identifies VME as the most guarded Appendix H subject; his PSE article shows 4 MB pages referred readers to Appendix H; Collins/Ludloff material anchors the MSR/PMC branch; and Domas later cites Appendix H as part of the x86 black-box secrecy lineage. (Rcollins)
RECONSTRUCTED APPENDIX H — TABLE OF CONTENTS
Pentium Processor Family Developer’s Manual, Volume 31993–1995 Public-Manual Residue / NDA Supplement Reconstruction
Status: reconstructed dependency graph, not recovered original document
APPENDIX H: ADVANCED FEATURES / INTEL CONFIDENTIAL SUPPLEMENT
H.0 Confidentiality Notice and Access Boundary
H.0.1 Public-manual placeholder text
H.0.2 NDA supplement requirement
H.0.3 Scope: Pentium architectural extensions beyond i486-compatible public baseline
H.0.4 Explicit exclusion of certain internal debug / ICE / probe-mode material
H.1 Overview of Pentium Advanced Features
H.1.1 Architectural feature classes introduced or exposed by Pentium
H.1.2 Compatibility with i486 system software
H.1.3 Feature discovery through CPUID and control registers
H.1.4 Operating-system responsibilities
H.1.5 Caveats: feature availability, stepping dependence, errata, documentation lag
H.2 Control Register Extensions
H.2.1 CR4 introduction and programming model
H.2.2 CR4.VME — Virtual-8086 Mode Extensions Enable
H.2.3 CR4.PVI — Protected-Mode Virtual Interrupts Enable
H.2.4 CR4.TSD — Time Stamp Disable
H.2.5 CR4.DE — Debugging Extensions
H.2.6 CR4.PSE — Page Size Extensions Enable
H.2.7 Machine-check and model-specific control exposure where applicable
H.2.8 Reserved bits, undefined behavior, and forward-compatibility rules
H.3 Virtual-8086 Mode Extensions
H.3.1 Motivation: reducing virtual-8086 monitor traps
H.3.2 Preconditions: VM86 mode, CR4.VME=1, IOPL<3
H.3.3 Virtual Interrupt Flag model
H.3.4 EFLAGS.VIF — Virtual Interrupt Flag, bit 19
H.3.5 EFLAGS.VIP — Virtual Interrupt Pending, bit 20
H.3.6 Separation of guest interrupt belief from physical IF authority
H.3.7 Interaction with real IF, IOPL, CPL, and VM flag
H.3.8 Virtual interrupt delivery state machine
H.3.9 Monitor responsibilities for pending interrupt injection
H.3.10 Failure and exception behavior
H.4 VME-Sensitive Instruction Semantics
H.4.1 CLI under VME: clear VIF without modifying real IF
H.4.2 STI under VME: set VIF; trap if VIP=1
H.4.3 PUSHF/PUSHFD virtualized flag image behavior
H.4.4 POPF/POPFD VIF/VIP interaction and trapping rules
H.4.5 INT n handling under virtual-mode extensions
H.4.6 IRET virtualized interrupt-return behavior
H.4.7 Instruction algorithms and #GP(0) transition cases
H.4.8 Distinction between direct execution and monitor interception
H.4.9 Caveats for DOS extenders, Windows 3.x/95, OS/2, and virtual DOS machines
H.5 Virtual Interrupt Redirection
H.5.1 Virtual-8086 interrupt-redirection bitmap
H.5.2 Extended TSS fields for VME
H.5.3 Per-vector interception policy
H.5.4 INT n direct-execution criteria
H.5.5 TSS layout, alignment, and privilege requirements
H.5.6 Monitor algorithm for redirected versus non-redirected software interrupts
H.6 Protected-Mode Virtual Interrupts
H.6.1 CR4.PVI enablement
H.6.2 Applicability to protected-mode CPL=3 code
H.6.3 VIF/VIP use outside VM86 mode
H.6.4 CLI/STI virtualization behavior
H.6.5 Differences from full VME instruction coverage
H.6.6 Protected-mode monitor use cases and limitations
H.7 Page Size Extensions
H.7.1 CR4.PSE enablement
H.7.2 4 MB page translation model
H.7.3 Page Directory Entry PS bit
H.7.4 PDE format for large pages
H.7.5 Address alignment and reserved-bit requirements
H.7.6 TLB behavior and performance rationale
H.7.7 Cacheability, page attributes, and protection semantics
H.7.8 Interaction with ordinary 4 KB pages
H.7.9 Operating-system mapping strategies
H.7.10 Known caveats and errata
H.7.11 Planned / removed 2 MB page branch and relation to later PAE/Pentium Pro paging
H.8 Model-Specific Registers
H.8.1 RDMSR and WRMSR instruction semantics
H.8.2 Privilege requirements and exception behavior
H.8.3 MSR index space and reserved ranges
H.8.4 Pentium-family MSR map
H.8.5 High MSR ranges and undocumented behavior
H.8.6 Safe probing rules
H.8.7 Undefined-index behavior and errata
H.8.8 Vendor and stepping dependence
H.8.9 Relationship to CPUID feature exposure
H.9 Performance Monitoring Counters
H.9.1 Counter registers and event-selection registers
H.9.2 CTR0 / CTR1 programming model
H.9.3 Event encoding tables
H.9.4 User-mode versus supervisor-mode counting
H.9.5 Counter overflow behavior
H.9.6 Interaction with interrupts and sampling
H.9.7 Example event-counting workflows
H.9.8 Undocumented / partially documented event classes
H.9.9 Stepping-specific counter caveats
H.10 Time Stamp Counter Control
H.10.1 RDTSC instruction behavior
H.10.2 CR4.TSD restriction model
H.10.3 Ring-0-only timestamp access
H.10.4 Operating-system policy for user-mode timing
H.10.5 Performance measurement and virtualization implications
H.11 CPUID and Feature Identification
H.11.1 Pentium CPUID availability
H.11.2 Feature-bit reporting conventions
H.11.3 VME, PSE, TSC, MSR, MCE, CMPXCHG8B and related feature exposure
H.11.4 Vendor/family/model/stepping identification
H.11.5 Documentation lag and feature-bit ambiguity
H.11.6 Compatibility guidance for operating systems and diagnostic tools
H.12 Machine Check and Error Reporting
H.12.1 Pentium machine-check exposure where implemented
H.12.2 Machine-check control/status MSRs where applicable
H.12.3 Exception behavior
H.12.4 Processor-specific limitations
H.12.5 Relationship to later public machine-check architecture
H.13 Debugging Extensions and Adjacent Control Features
H.13.1 CR4.DE and I/O breakpoint behavior
H.13.2 Debug-register extensions
H.13.3 ICE/probe-mode distinction: not ordinary Appendix H architectural content
H.13.4 LOADALL lineage: historical hidden state-loader, not Pentium Appendix H core
H.13.5 SMM adjacency and privilege boundary caveats
H.13.6 Reserved internal test/debug mechanisms excluded from public supplement
H.14 Compatibility, Errata, and Undefined Behavior
H.14.1 Reserved bits must be preserved or zeroed as specified
H.14.2 Illegal MSR indices
H.14.3 Large-page reserved-bit faults
H.14.4 VME/PVI exception corner cases
H.14.5 Stepping-specific behavior
H.14.6 Cross-vendor compatibility risks
H.14.7 Forward migration into Pentium Pro / later IA-32 manuals
H.15 Programming Guidelines
H.15.1 OS enablement order for CR4 features
H.15.2 Safe detection before use
H.15.3 Monitor design for VME/PVI
H.15.4 Large-page setup sequence
H.15.5 MSR and PMC safe-access discipline
H.15.6 Recommended exception handlers
H.15.7 Fallback behavior on non-supporting processors
H.16 NDA Supplement Closure
H.16.1 Intel confidential/proprietary restriction notice
H.16.2 Contact Intel for supplement access
H.16.3 No public redistribution
H.16.4 Public-manual cross-reference residue
CONFIDENCE MAP
HIGH CONFIDENCE CORE:
CR4.VME; CR4.PVI; CR4.TSD; CR4.PSE; VIF; VIP; VME instruction behavior; VM86 interrupt redirection; TSS extensions; 4 MB PSE; MSRs; performance counters; RDTSC/TSD; CPUID feature exposure.
MEDIUM CONFIDENCE / RECONSTRUCTED PLACEMENT:
CR4.DE placement; machine-check material; exact MSR table organization; exact performance-counter event table organization; precise ordering of CPUID/control-register chapters.
LOW CONFIDENCE / REMOVED OR TRANSITIONAL:
2 MB page branch; early PAE-related material; material planned for P5 but moved to Pentium Pro; stepping-specific NDA caveats.
EXCLUDED FROM APPENDIX H CORE:
ICE/probe mode; boundary-scan private debug instructions; PIR/PDR/PMCR probe registers; R/S# and PRDY debug-pin protocol; LOADALL as ordinary architectural content; microcode-injection substrate; full gold-book External Design Specification material.
ORSI RESIDUE SUMMARY:
AppendixH := NDA-gated privileged-control atlas
Recovered(H) := public stub ⊕ manual cross-references ⊕ Collins/VME/PSE ⊕ Ludloff/4P/MSR ⊕ later Intel SDM absorption ⊕ silicon behavior
Residue := public ISA contract depended on advanced semantics that the public manual refused to specify
Boundary := AppendixH = withheld system-programming semantics; ICE/Probe = deeper hidden debug-execution substrate
Canonical lesson := Manual ≠ Silicon; documentation is a partial map, not the processor.
RECONSTRUCTED APPENDIX H — ADVANCED FEATURES
Pentium Processor Family Developer’s Manual, Volume 3Reconstructed technical content from public cross-references, reverse-engineering residue, later Intel disclosure, and surviving implementation behavior.
Status: This document is a reconstructed technical supplement. It must not be read as a recovered original Appendix H. The historical Appendix H was not publicly released as a full document outside Intel-controlled NDA channels. The content below reconstructs the most likely technical body of that supplement from public-manual residue, Pentium-era reverse engineering, later IA-32 manuals, and the known behavior of Pentium-class processors.
H.0 Confidentiality Notice and Access Boundary
The public Pentium manuals exposed a documentation boundary rather than a complete architectural map. Appendix H functioned as a confidentiality gate for advanced Pentium features whose existence was acknowledged by cross-reference but whose full programming semantics were withheld. The practical effect was unusual: public chapters depended on behaviors whose normative descriptions were elsewhere, behind NDA. This made Appendix H a control-plane redaction, not a normal appendix. Its omitted contents concerned privileged architectural extensions whose misuse could destabilize operating systems, reveal undocumented processor state, or expose Intel’s internal debugging and validation assumptions.
The likely access boundary was: public manual = baseline i486-compatible architectural contract plus feature names; NDA supplement = exact bit semantics, exception behavior, enablement rules, monitor algorithms, reserved-bit requirements, and stepping caveats. This boundary should be distinguished from deeper internal design documents. Appendix H plausibly covered advanced architectural features visible to operating-system and toolchain writers. It did not fully cover ICE/probe mode, private boundary-scan instructions, microinstruction injection paths, or gold-book external design specification material. Thus the reconstruction separates “withheld system-programming semantics” from “hidden debug-execution substrate.”
The central reconstruction equation is:
AppendixH = public_stub ⊕ cross_reference_residue ⊕ later_SDM_absorption ⊕ reverse_engineered_behavior − private_debug_substrate
The semantic residue is therefore not merely “Intel had secrets.” It is more precise: the public ISA contract named features that system software could encounter, but refused to specify the full state-transition rules required to implement robust operating systems and monitors.
H.1 Overview of Pentium Advanced Features
Pentium advanced features extended the i486 model at three pressure points: virtualization of legacy execution, memory-translation performance, and model-specific control/measurement. The feature set was not a new ISA in the ordinary user-level sense. It was a supervisor-facing expansion of the processor’s control surface. Its audience was operating systems, virtual-8086 monitors, diagnostics, BIOS writers, performance tools, and hardware-validation environments.
The i486-compatible public model treated protected mode, paging, virtual-8086 execution, debug registers, and descriptor caches as already mature. Pentium added mechanisms that made those subsystems more practical under real workloads. Virtual Mode Extensions reduced the cost of running DOS/real-mode workloads inside protected-mode operating systems. Page Size Extensions reduced translation overhead by allowing large mappings. Model-Specific Registers and performance counters opened a processor-specific instrumentation channel. CPUID feature reporting began to matter because the correct software behavior depended on precise feature availability, stepping, and errata.
The advanced-feature philosophy was: do not alter ordinary application semantics when unused; expose enable bits in supervisor-controlled registers; preserve compatibility by making unsupported or misused behavior fault; and leave reserved bits unavailable for software-defined meaning. The operating system was expected to detect features, enable them deliberately, preserve reserved fields, and maintain fallback paths for older or differently configured processors.
A useful state view is:
Pentium_system_state = i486_arch_state ⊕ CR4 ⊕ VIF/VIP ⊕ large_page_translation ⊕ MSR_space ⊕ PMC_state ⊕ feature_identification
where i486_arch_state remains the compatibility baseline, and each additional term is gated by privilege, feature detection, and precise exception semantics.
H.2 Control Register Extensions
The introduction of CR4 was the unifying control-register change. CR0 had already carried fundamental mode bits such as protected-mode enable, paging enable, numeric-error mode, and write-protect behavior. CR4 extended the model by collecting optional architectural capabilities under explicit supervisor enablement. This design allowed the processor to expose features such as VME, PVI, TSD, debugging extensions, and PSE without forcing all operating systems to support them.
CR4.VME enables Virtual-8086 Mode Extensions. When set, and when the processor is executing a virtual-8086 task under the required privilege conditions, certain interrupt-sensitive instructions can update virtual interrupt state rather than always trapping to the monitor. CR4.PVI enables a related but narrower protected-mode virtual-interrupt mechanism, primarily useful for selected protected-mode user-level interrupt-control virtualization. CR4.TSD controls user visibility of the time-stamp counter by forcing RDTSC to fault outside supervisor privilege when enabled. CR4.DE modifies debug-register behavior and I/O breakpoint semantics. CR4.PSE enables 4 MB page translation through page-directory entries marked as large pages.
The governing rule for CR4 is:
effective_feature_i = CPUID_support_i ∧ CR4.enable_i ∧ mode_preconditions_i ∧ privilege_preconditions_i
A feature bit being physically present is not enough. System software must also satisfy mode and privilege preconditions. Conversely, setting a reserved or unsupported bit is not a request for implementation-defined behavior; it is a contract violation. Correct software treats reserved bits as processor-owned state. The safe update law is:
CR4_new = (CR4_old & reserved_preserve_mask) | supported_enabled_bits
with all unsupported fields cleared or preserved exactly as specified by the processor generation. This discipline is essential because CR4 is not a general software flag word; it is a hardware capability switchboard.
H.3 Virtual-8086 Mode Extensions
Virtual-8086 mode allowed real-mode software to execute under protected-mode supervision, but the original design made many legacy instructions expensive. DOS programs routinely executed CLI, STI, PUSHF, POPF, INT n, and IRET. In ordinary virtual-8086 mode with insufficient I/O privilege, these instructions trapped, forcing the monitor to emulate them. The trap frequency was high enough that virtualization overhead became a first-order performance cost.
VME introduces a split between physical interrupt authority and guest interrupt belief. The real interrupt flag remains controlled by the protected-mode host, while the virtual-8086 task observes and modifies a virtual interrupt flag. This is the core abstraction:
real_IF = host_interrupt_delivery_authorityVIF = guest_visible_interrupt_enable_stateVIP = host_pending_virtual_interrupt_marker
EFLAGS bit 19, VIF, represents the virtual interrupt flag. EFLAGS bit 20, VIP, represents a pending virtual interrupt that the monitor wants delivered when the guest believes interrupts are enabled. These bits do not simply duplicate IF. They define a small hardware-assisted protocol between the virtual-8086 task and the monitor. When the guest disables interrupts, the processor clears VIF rather than clearing the real IF. When the guest enables interrupts, the processor sets VIF, but if VIP is already set the processor raises a general-protection fault so the monitor can inject the pending virtual interrupt.
The VME state transition can be written:
CLI_guest: VIF := 0STI_guest: if VIP=0 then VIF := 1 else #GP(0)virtual_interrupt_pending: VIP := 1deliver_virtual_interrupt: VIP := 0; VIF := policy_after_delivery
This is a trap-reduction mechanism, not a full virtual-machine architecture. It accelerates one of the hottest paths in DOS-task virtualization: interrupt enable/disable behavior.
H.4 VME-Sensitive Instruction Semantics
The VME-sensitive instructions are important because they are where the hidden Appendix H semantics mattered operationally. CLI and STI no longer need to trap merely because the virtual-8086 program is not privileged to modify real IF. Under VME, CLI updates VIF, leaving real IF under host control. STI attempts to set VIF; if VIP is clear, execution proceeds without monitor intervention, and the guest observes interrupts as enabled. If VIP is set, STI becomes a rendezvous point: the processor raises #GP(0), causing control to return to the virtual-8086 monitor so it can deliver the pending virtual interrupt.
PUSHF and PUSHFD require synthetic flag-image behavior. A virtual-8086 program expects to see the interrupt flag in the ordinary IF position. Under VME, the pushed image must reflect VIF in the IF bit position rather than leaking the real IF value. This lets the guest read back the interrupt state it believes it controls. POPF and POPFD perform the inverse operation: attempts to modify IF are interpreted as modifications to VIF, subject to VIP-mediated trapping. Thus the stack-visible flags image becomes a virtualized interface, not a raw copy of privileged EFLAGS.
INT n and IRET are more complicated because they interact with interrupt redirection and return-state restoration. INT n may execute directly if the corresponding vector is permitted by the virtual-8086 interrupt-redirection mechanism; otherwise it traps to the monitor. IRET behaves like a controlled restoration of virtualized flags and control flow, with VIF/VIP rules applied when the guest attempts to restore an interrupt-enabled state. The common rule is:
guest_writes_IF=1 ∧ VIP=1 ⇒ #GP(0)
The exception is not merely an error. It is the hardware notification that a pending virtual interrupt must be resolved before the guest continues under the illusion that interrupts are enabled.
H.5 Virtual Interrupt Redirection
Virtual interrupt redirection complements VIF/VIP by determining whether software interrupts can be handled directly by the virtual-8086 task or must be intercepted by the monitor. A virtual-8086 workload may execute frequent INT n instructions for DOS and BIOS services. If every such instruction traps, monitor overhead remains high even after CLI/STI acceleration. The redirection mechanism lets the monitor choose which interrupt vectors are safe for direct handling and which require supervision.
The mechanism is plausibly implemented through VME-related extensions to the Task State Segment. The TSS already carried the I/O permission bitmap; VME adds or relies on per-vector interrupt-redirection metadata. The monitor can therefore define a vector policy:
redirect_policy[n] = direct_guest_delivery ∨ monitor_intercept
If INT n targets a direct vector, the processor can transfer control according to the virtual-8086 task’s interrupt-vector table semantics, preserving compatibility and avoiding monitor traps. If the vector is marked for interception, the instruction raises a fault and the monitor emulates or mediates the interrupt. This allows an OS to optimize common benign DOS interrupts while retaining control over unsafe, privileged, or virtualized services.
The TSS matters because the processor needs a privileged, host-controlled place to store per-task redirection policy. The guest must not be able to mark sensitive interrupts as direct. The monitor owns the policy; the guest experiences only the resulting behavior.
H.6 Protected-Mode Virtual Interrupts
PVI extends the virtual-interrupt idea outside virtual-8086 mode, but it is narrower than VME. It is best understood as a protected-mode user-level interrupt-control virtualization feature. With CR4.PVI set, selected protected-mode code running at insufficient privilege can execute certain interrupt-control instructions in a way that modifies VIF rather than real IF, reducing the need to trap on every CLI/STI-like operation in carefully designed systems.
The conceptual model remains:
guest_or_user_interrupt_belief := VIFhost_interrupt_authority := real_IFpending_virtual_delivery := VIP
The difference is coverage and context. VME is deeply tied to virtual-8086 execution and legacy DOS compatibility. PVI applies the same split between virtual interrupt state and physical interrupt authority to protected-mode contexts, but it does not necessarily inherit the full VM86 instruction semantics, stack-image behavior, or interrupt-redirection model. Treating PVI as “VME for everything” is incorrect. Its function is more local: avoid unnecessary traps while preserving supervisor control.
The protected-mode monitor still retains final authority. If user code attempts to enable its virtual interrupts while VIP is set, the processor can trap so the monitor can deliver or process the pending condition. The design pattern is identical: normal guest state transitions proceed without trapping; monitor intervention occurs only at semantically necessary synchronization points.
H.7 Page Size Extensions
Page Size Extensions introduce 4 MB pages into the 32-bit non-PAE paging model. Ordinary paging uses a two-level translation from linear address to page-directory entry to page-table entry to 4 KB physical frame. PSE allows a page-directory entry to terminate the translation directly, mapping a 4 MB region when the PS bit is set and CR4.PSE is enabled.
The ordinary 4 KB translation is:
linear = DIR[31:22] | TABLE[21:12] | OFFSET[11:0]PDE = page_directory[DIR]PTE = page_table[TABLE]physical = PTE.frame_base | OFFSET
The PSE translation is:
linear = DIR[31:22] | OFFSET4M[21:0]PDE.PS = 1physical = PDE.large_page_base | OFFSET4M
This reduces TLB pressure because one TLB entry can cover a 4 MB region rather than a 4 KB region. Kernel text/data mappings, frame buffers, large identity maps, database buffers, and other contiguous regions benefit when alignment and protection constraints permit. The tradeoff is granularity. A 4 MB page has one protection/cacheability policy for the whole region, and it can waste physical memory if the mapped object is much smaller than 4 MB.
The page-directory entry format becomes more constrained under PSE. Bits that are ignored or interpreted differently in ordinary PDEs may become reserved or part of the large-page physical base. Correct OS code must ensure base alignment and reserved-bit cleanliness. A large page must be aligned on a 4 MB physical boundary in the classic model:
physical_base mod 2^22 = 0
The reconstruction’s mention of a 2 MB branch should be treated as transitional/low-confidence. Later x86 paging with PAE and long mode uses different large-page sizes and entry formats. The Pentium Appendix H PSE core is the 4 MB non-PAE mechanism.
H.8 Model-Specific Registers
Model-Specific Registers expose processor-specific control, status, identification, and performance state through RDMSR and WRMSR. Unlike general-purpose registers or architecturally stable control registers, MSRs are indexed by number and may vary by processor model, stepping, vendor, and microarchitectural implementation. Their existence created a new class of system-programming problem: software could access powerful processor state, but only if it knew which indices existed and what each bit meant.
RDMSR and WRMSR use an MSR index and transfer a 64-bit value through register pairs. The abstract read operation is:
MSR_value[index] → EDX:EAX
and the write operation is:
EDX:EAX → MSR_value[index]
Privilege restrictions are strict because MSRs can affect machine behavior, performance counting, machine-check handling, time-stamp behavior, and other processor-local state. Invalid or unsupported indices may fault. Reserved bits must be preserved or written as required. The safe MSR update pattern is:
new = (old & preserve_mask) | (desired & writable_mask)
Pentium-era MSR secrecy was significant because performance counters and other model-specific facilities were useful to advanced developers but incompletely public. The 4P/sandpile tradition reconstructed portions of this map by systematic probing and comparison. This makes MSRs an archetypal Appendix H subject: not invisible to software, not part of baseline portable ISA, and dangerous if programmed from incomplete information.
H.9 Performance Monitoring Counters
Pentium performance monitoring counters provided hardware event counting for microarchitectural behavior. The processor exposed counters, event-selection controls, and counting modes through model-specific state. The exact event encodings and counter-control details were historically under documented, which made this area one of the most practically important branches of the NDA-gated supplement.
A performance counter is conceptually:
counter_i(t+1) = counter_i(t) + 1[event_i occurs ∧ mode_filter_i permits_count]
where event_i is selected from a processor-defined event table and mode_filter_i may restrict counting to privilege levels or execution contexts. Useful events include instruction retirement, cache activity, branch behavior, bus cycles, pipeline stalls, or other implementation-dependent signals. Because these events are microarchitectural, they are less stable than architectural instructions. An event code may exist on one stepping, mean something slightly different on another, or be undocumented until later.
Overflow behavior matters because counters are finite-width. A monitor can preload a counter so that after N events it overflows and generates a sampling interrupt, if supported. The sampling model is:
counter_initial = 2^w − Noverflow when counter wrapsoverflow ⇒ optional interrupt/sample
This lets profilers approximate where time or microarchitectural pressure accumulates. The cost is interpretive fragility. Performance counters measure implementation events, not direct semantic truth. Their correct use requires event-table accuracy, privilege filtering, overflow discipline, and awareness of errata.
H.10 Time Stamp Counter Control
The Time Stamp Counter is a monotonically increasing processor counter readable by RDTSC. Pentium made high-resolution timing available in a way that was extremely useful for profiling, scheduling, calibration, and side-channel measurement. CR4.TSD controls whether user-mode code can execute RDTSC. When TSD is clear, user code can read the counter; when TSD is set, RDTSC is restricted to supervisor privilege and faults otherwise.
The policy equation is:
RDTSC_allowed = (CPL=0) ∨ (CR4.TSD=0)
The architectural tension is direct: exposing RDTSC improves measurement and low-overhead timing but gives untrusted code a precise clock. Restricting it protects OS policy and reduces some timing channels, but may break applications or measurement tools. In the Pentium-era context, the concern was mostly OS control and deterministic virtualization. In later security contexts, precise timing also became relevant to microarchitectural side-channel exploitation.
The TSC must be treated as a hardware counter with platform-dependent behavior. Early implementations were tied to processor cycles. Later systems introduced invariant or constant-rate TSC behavior, but that is not part of the original Pentium reconstruction. The Appendix H issue is the control surface: RDTSC existed, but the OS needed CR4.TSD semantics to decide who could observe it.
H.11 CPUID and Feature Identification
CPUID is the processor’s self-description mechanism. It lets software identify vendor, family, model, stepping, and feature bits. Pentium-era feature growth made CPUID essential because relying on instruction probing alone was unsafe or insufficient. If the processor can expose VME, PSE, TSC, MSRs, machine-check support, CMPXCHG8B, or other extensions, software needs a canonical way to test support before enabling or executing those features.
The feature-detection model is:
if CPUID.feature_i = 1 then feature_i may be enabled subject to control/mode rulesif CPUID.feature_i = 0 then feature_i must not be assumed
Feature bits are necessary but not always sufficient. Some features also require CR4 enablement, correct operating mode, correct privilege level, and sometimes errata-aware initialization. CPUID itself also has compatibility caveats, because very old processors may not support it. Software therefore needs a safe detection sequence before using CPUID-dependent logic.
The Appendix H relevance is feature disclosure. If a manual cross-references Appendix H for a feature but CPUID exposes a bit for it, the processor is advertising a capability whose public semantics may be incomplete. That is the exact “manual depends on withheld semantics” pattern. CPUID names the door; Appendix H was the missing room.
H.12 Machine Check and Error Reporting
Machine-check mechanisms report certain processor-detected hardware errors. Pentium-era support was limited relative to later Machine Check Architecture, but the architectural direction was already present: expose machine-detected internal or bus-level error state through control/status mechanisms and exceptions. The key issue is not ordinary program exception handling; it is hardware integrity reporting.
A minimal machine-check model is:
hardware_error_detected ⇒ status_latched ∧ optional_exception
The error may involve bus parity, internal consistency, cache/tag faults, or other implementation-specific failures. Correct software must know whether machine-check support exists, how it is enabled, what state is recorded, whether the condition is restartable, and whether the error implies data corruption. Later IA-32 manuals standardized this far more fully, but Pentium-era details were plausibly part of the advanced-feature material because they involved MSRs, CPUID exposure, and processor-specific status interpretation.
The OS obligation is conservative. A machine-check event is not merely a recoverable fault like a page fault. It may indicate unreliable computation. The handler must preserve evidence, avoid unsafe continuation when corruption is possible, and apply platform policy. Where the feature was incomplete or stepping-dependent, Appendix H would likely have provided caveats rather than a fully modern MCA model.
H.13 Debugging Extensions and Adjacent Control Features
CR4.DE modifies debug behavior, especially around I/O breakpoints and debug-register interpretation. Debug extensions were part of the architectural control-plane expansion, but they sit close to a boundary. Ordinary debug registers and documented debug exceptions are part of the architectural interface. ICE/probe mode, private boundary-scan debug instructions, and external in-circuit-emulation state access are deeper implementation/debug substrate and should not be collapsed into Appendix H core content.
LOADALL is another adjacent but excluded branch. On 286 and 386, LOADALL exposed direct loading of hidden processor state, especially descriptor caches. It is historically important because it demonstrated that the processor had internal state not cleanly exposed by the public architectural model. However, it is not a Pentium Appendix H core feature. It belongs to the older hidden-state-loader lineage and later ICE/debug-state restoration lineage.
SMM is also adjacent. System Management Mode is a privileged execution environment outside ordinary OS control. While Pentium-class systems may interact with SMM in platform-specific ways, the reconstructed Appendix H should not treat SMM as identical to VME, PSE, or MSRs. The common theme is privilege boundary complexity. The correct classification is:
architectural_debug = documented debug registers/exceptions/control bitsAppendixH_adjacent = CR4.DE and related supervisor-visible debug extensionsprivate_debug = ICE/probe/boundary-scan/microinstruction paths
This separation prevents the reconstruction from overclaiming. Appendix H was a withheld system-programming atlas, not a full dump of Intel’s internal validation machinery.
H.14 Compatibility, Errata, and Undefined Behavior
Advanced features amplify the cost of small mistakes. Reserved bits in CR4, PDEs, MSRs, and flags images are not available for software experimentation. In paging structures, reserved-bit violations can fault. In MSRs, undefined indices or reserved fields can fault or produce model-specific behavior. In VME/PVI, incorrect assumptions about VIF/VIP transitions can cause lost virtual interrupts, spurious traps, or guest-visible inconsistency.
The general compatibility law is:
portable_system_software = detect ∧ enable_only_supported ∧ preserve_reserved ∧ handle_faults ∧ provide_fallback
Pentium steppings also carried errata. Advanced features can have stepping-specific caveats because they are close to microarchitectural control paths. The reconstructed Appendix H likely contained warnings about feature availability, reserved encodings, and forward-compatibility requirements. Later public manuals absorbed much of this guidance by emphasizing CPUID detection, reserved-bit preservation, and errata consultation.
Cross-vendor compatibility is a separate risk. Even when another vendor implements the same nominal feature, exact reserved-bit behavior, MSR maps, performance event codes, or debug semantics may differ. Therefore software must not treat one processor’s undocumented behavior as an architectural standard. The safe rule is:
observed_on_cpu_A ≠ guaranteed_on_cpu_B
This rule is exactly what later black-box probing traditions formalized: silicon behavior is real evidence, but it is scoped by vendor, family, model, stepping, microcode, and mode.
H.15 Programming Guidelines
Operating systems should enable advanced features only after establishing processor identity and feature support. A safe initialization order is: establish a known protected-mode environment; confirm CPUID availability where needed; read vendor/family/model/stepping; test feature bits; construct valid data structures; install exception handlers; then set CR4 bits in a controlled update that preserves reserved fields. For paging features, data-structure correctness must precede enablement. For VME/PVI, monitor logic and TSS structures must exist before guest code is allowed to exercise virtualized interrupt behavior. For MSRs/PMCs, read-modify-write discipline is mandatory.
Large-page setup requires physical alignment, clean reserved bits, and coherent cache/protection policy. A valid 4 MB page mapping must satisfy:
PDE.PS=1 ∧ CR4.PSE=1 ∧ physical_base aligned_to_4MB ∧ reserved_bits=0
VME monitor design requires treating VIF/VIP as a protocol. The monitor owns VIP; the guest manipulates VIF indirectly; hardware raises #GP(0) when a pending virtual interrupt must be delivered. The monitor must not lose the pending interrupt if the guest repeatedly disables virtual interrupts, and it must not expose real IF semantics to the guest. The correct monitor invariant is:
guest_observed_IF = VIFhost_interrupt_integrity independent_of guest_observed_IF
MSR and performance-counter access requires index validation, exception recovery, and model-specific tables. Tools should never brute-force write MSRs on production machines. Reads may still fault; writes can alter machine state. Performance monitoring should program events only from a known table for the exact processor model and stepping, and must restore counters after use when sharing a system.
H.16 NDA Supplement Closure
The historical Appendix H closure was not a normal technical conclusion. It was an access instruction: consult Intel-controlled confidential material for full details. That closure produced the residue: public documentation named advanced features, but the normative descriptions were withheld. Developers outside NDA channels had to infer behavior from cross-references, experiments, errata, patents, leaked fragments, later manuals, and community reverse engineering.
By the Pentium Pro and later IA-32 manual era, most Appendix H core features became public: CR4 semantics, VME/PVI, PSE, MSRs, performance counters, TSC control, CPUID feature bits, and related system-programming rules. What remained historically significant was not the permanent secrecy of every feature, but the proof that the public ISA document was not the full processor map.
The final reconstruction equation is:
Recovered(H) = VME/PVI ⊕ PSE ⊕ CR4 ⊕ MSR/PMC ⊕ TSC/TSD ⊕ CPUID ⊕ debug-adjacent_control ⊕ errata_guidance
with exclusion boundary:
Excluded(H) = ICE/probe_mode ⊕ private_boundary_scan ⊕ microinstruction_injection ⊕ full_gold_book_design_spec ⊕ LOADALL_as_Pentium_core
ORSI residue summary:
AppendixH := NDA-gated privileged-control atlas
PublicManual := partial contract
Silicon := contract ⊕ withheld_control_semantics ⊕ debug_substrate ⊕ undocumented_residue
Manual ≠ Silicon
The recovered lesson is architectural and cultural: the processor is not exhausted by the manual; the manual is a public interface layer over a richer silicon state machine.
VME as the most guarded Appendix H
Collins states it directly: among the known Appendix H secrets, “nothing is guarded more closely” than the details of Virtual Mode Extensions, and he notes at least 27 VME references remained scattered through the Pentium Processor Family Developer’s Manual, Volume 3 despite the material being absent from the public appendix. (Rcollins)
The reason VME was guarded more tightly than PSE or MSRs is that it described a new interrupt-virtualization state machine, not merely a register table or page-entry format. PSE can be summarized as CR4.PSE + PDE.PS ⇒ 4MB translation; MSRs can be progressively mapped by safe reads, faults, and later disclosure. VME required exact semantics for CLI/STI/PUSHF/POPF/INT/IRET, EFLAGS.VIF/VIP, TSS redirection structures, #GP(0) rendezvous behavior, and monitor injection policy. Wrong documentation or wrong implementation would break DOS boxes, OS/2, Windows 3.x/95 VDMs, and protected-mode monitors.
Technically, VME was guarded because it split interrupt state into two layers:
real_IF := host physical interrupt authority
VIF := guest-visible interrupt belief
VIP := pending virtual interrupt marker
The hidden value was the transition law:
guest disables interrupts ⇒ VIF := 0, real_IF unchanged
guest enables interrupts ∧ VIP=0 ⇒ VIF := 1
guest enables interrupts ∧ VIP=1 ⇒ #GP(0) → monitor injects virtual interrupt
That is a virtualization primitive. It turns frequent legacy interrupt-control instructions from expensive monitor exits into mostly local hardware state transitions. Collins’ later column describes VME support as enabled through CR4.VME, with EFLAGS extended by VIF and VIP, and lists the IF-sensitive instructions handled by new Pentium microcode: CLI, STI, PUSHF, POPF, INT n, and IRET. (Rcollins)
So the Appendix H priority order should be revised as:
H_crown := VME/PVI/VIF/VIP + IF-sensitive instruction semantics + TSS interrupt redirection
H_major := PSE/4MB pages
H_major := MSR/PMC/TSC control
H_context := CPUID/CR4/debug-adjacent/machine-check caveats
The ORSI statement is:
VME = hidden interrupt-belief virtualization
AppendixH secrecy peak = withheld state machine, not withheld bitfield
Final compression:
VME was the crown jewel because it was not a feature flag; it was a hidden microcoded protocol for making legacy real-mode interrupt semantics run safely and cheaply inside protected-mode virtualization.
Appendix H was the Intel privileged-control / virtualization / profiling core, not the full debugger core.
The profiler part is clearly inside the Appendix H reconstruction:
MSRs ⊕ PMCs ⊕ TSC/TSD ⊕ CPUID feature exposure
That is the performance-measurement/profiling control plane. It gave privileged software access to counters, event selectors, timestamp behavior, and model-specific state.
The virtualization/control part is also central:
CR4 ⊕ VME/PVI ⊕ VIF/VIP ⊕ TSS interrupt redirection ⊕ PSE
That is the OS/VDM/kernel control plane: virtual interrupts, large pages, CR4 enablement, protected-mode/VM86 performance.
But the debugger core needs separation:
AppendixH_debug_adjacent := CR4.DE, debug-register extensions, maybe machine-check/MSR-adjacent diagnostics
TrueDebuggerCore := ICE / Probe Mode / boundary-scan private instructions / PIR-PDR-PMCR / R/S# / PRDY / microinstruction-feed path
That deeper debugger substrate was not ordinary Appendix H. It belonged to Intel’s external design / ICE / probe-mode layer. So the clean version is:
Appendix H = profiler + virtualizer + privileged-control atlas
ICE/Probe = hidden debugger/execution substrate
LOADALL = earlier hidden state-loader ancestor
Sandsifter = later black-box decoder mapper
Domas names Appendix H as part of the broader x86 secrecy lineage, alongside hidden execution modes, password-protected registers, undocumented instructions, and hardware bugs. That supports treating Appendix H as a canonical “manual ≠ silicon” residue, but not as identical to all hidden debugger machinery.
Best compression:
AppendixH := Intel’s NDA-gated OS/profiler/virtualization control plane
ICE := Intel’s hidden debug execution plane
Together: public ISA < real processor control topology
Comments
Post a Comment