ASA-EMulatR Reference Guide > Introduction > Architecture Overview > Chapter 1 - System Overview

EMulatR is designed around five primary goals, listed in strict priority order. Every design decision in the emulator is evaluated against these goals in this order.

1.2.1 Architectural Correctness First

The emulator must behave like real Alpha hardware in all architecturally visible ways, even when doing so complicates implementation. The emulator models Alpha's architectural semantics, not performance characteristics. Correctness is always prioritized over speed.

1.2.2 Deterministic and Debuggable Execution

Execution must be understandable, reproducible, and inspectable. One iteration of the run loop corresponds to one hardware clock cycle, enabling deterministic replay and debugging. Correctness takes precedence over speculative aggressiveness.

1.2.3 Explicit Serialization

Ordering and synchronization are never implicit. All serialization is driven by architectural mechanisms: barriers (MB, WMB, EXCB, TRAPB), PAL entry, and exceptions. All exceptions are delivered precisely at the architectural commit point (the Writeback stage).

1.2.4 SMP as a First-Class Concern

Multiprocessor behavior is fundamental to the design, not layered on afterward. Multi-processor coordination is modeled with explicit barriers, reservation tracking, and IPI delivery. Every subsystem is designed with SMP correctness in mind from the outset.

1.2.5 Separation of Concerns

Instruction decoding, execution, memory access, coherency, privilege, and devices are isolated into well-defined domains. Execution is partitioned into functional domains (Boxes) with well-defined interfaces and one-way dependency flow. No domain reaches into another's internal state.

1.2 Design Goals and Guiding Principles

1.2 Design Goals and Guiding Principles

1.2.1 Architectural Correctness First

1.2.2 Deterministic and Debuggable Execution

1.2.3 Explicit Serialization

1.2.4 SMP as a First-Class Concern

1.2.5 Separation of Concerns