APSR Status Register

Overview

In the ARM architecture, the APSR (Application Program Status Register) is the status register that records condition flags (such as N, Z, C, V, Q, GE, and IT/ICI state, depending on architecture variant) produced or consumed by arithmetic, logical, comparison, and other data-processing instructions. Together with the general-purpose registers, the program counter, and observable memory writes, the APSR is part of the architectural state that fully determines the visible effect of an executed instruction.

Role in CPU State Modeling

In the Examiner differential testing system (ASPLOS '22), the CPU state of a target T before executing an instruction I is modeled as a tuple:

CPU_I(T) = < PC_T, Reg_T, Mem_T, Sta_T >

where:

• PC_T is the program counter pointing to the next instruction to execute,
• Reg_T are the general-purpose registers used by the processor,
• Mem_T is the (targeted) memory space the tested instruction may write into,
• Sta_T is the status register, which is the APSR in the ARM architecture.

After execution, the final CPU state additionally includes a signal/exception component:

CPU_F(T) = [ PC_T, Reg_T, Mem_T, Sta_T, Sig_T ]

A test case is reported as an inconsistent instruction stream whenever the final CPU states of two execution targets (emulator vs. real device) differ, i.e., when CPU_F(E) != CPU_F(R). Because Sta_T is part of this tuple, any divergence in the APSR between an emulator and real silicon is automatically captured as an inconsistency.

Use in Differential Testing

Examiner is a differential testing tool that automatically locates inconsistent instructions between real ARM devices and CPU emulators. To make the APSR observable across both targets, the tool:

1. Pushes the APSR (along with the other registers) onto the stack using inline assembly, and writes it into a file for post-run comparison.
2. Uses the Capstone disassembly framework to identify target memory addresses of write instructions, then snapshots only the relevant memory cells (the full memory is not compared, as that would be time- and resource-prohibitive).
3. Compares the collected state from the emulator and the real device; if any component — including the APSR — differs in the final state, the instruction stream is flagged as inconsistent.

The set of test cases is generated by parsing the ARM Architecture Specification Language (ASL), extracting lexical and syntactic information via regular expressions, and using the Z3 SMT solver to resolve constraints over encoding symbols (including boundary and negated constraints) so that multiple execution paths of each instruction are explored. The tool covers the A32, A64, T32, and T16 instruction sets, generating 2,774,649 instruction streams that collectively cover 1,998 instruction encodings across 1,070 instructions.

Implementation Context

The APSR handling in Examiner is implemented through inline assembly code that performs the initial state setup and the dumping of execution results. The total toolchain comprises 5,074 lines of Python, 220 lines of C, and 200 lines of ARM assembly.

See Also

• Differential testing — the testing technique of comparing two or more implementations of the same interface (here, an ARM emulator and a real ARM device) for behavioral divergence. Examiner uses the APSR as one of the components it compares when applying differential testing to ARM instruction streams.