Reading Specifications and Measuring¶
Finish by separating architectural behavior, call rules, assembler syntax and Linux services. Then decide what evidence would be needed before claiming an optimization.
Course examples on GitHub
Review the checked project · CMake build instructions. This lesson reviews existing examples; it does not add an automatic benchmark.
Before you start¶
Complete extended inline assembly, or return here after the core project if you are postponing advanced topics.
Outcome: find the right authority for a question, explain the course's boundaries and design a fair comparison. No new benchmark or persistent process is required in this lesson.
A reference map, not one universal manual¶
| Question | Authority | What to check |
|---|---|---|
| Instruction operands and behavior | Arm architecture documentation | ISA version, width, flags and required features |
| Arguments, return values, preservation | AAPCS64 | Actual signature and platform ABI |
| GNU directive or relocation spelling | GNU as AArch64 | Target and assembler version |
| ELF symbol or relocation result | readelf, objdump and linker documentation | Object before linking and executable after linking |
| Inline operand constraints | GCC extended asm | Compiler-visible inputs, outputs and effects |
| Debugger operation | GDB documentation | Selected binary, symbols and execution state |
| Kernel service number | Target Linux headers and syscall documentation | Architecture-specific entry convention |
A function call, Linux system call and assembler pseudo-instruction are different layers. A plausible instruction mnemonic does not prove a legal immediate or a valid memory address.
Final course review¶
Before considering speed, reproduce these explanations:
- Foundations: assemble/link/run independently; distinguish _start from a C-callable function; predict x/w alias effects; choose signed or unsigned conditions.
- Memory and calls: distinguish address from contents; state a valid array range; inspect a relocation; save a live value and LR across a nested call; restore SP.
- Integration: match a C/C++ declaration to assembly; observe a failure in GDB; run the report against empty, boundary and mixed-sign fixtures.
- Advanced: handle every vector tail; explain inline operands; distinguish a functional check from a measurement.
If one is unclear, return to that part rather than adding more instructions to an unexplained program.
Design a measurement before running it¶
Use the report or vector lesson as a candidate, but first match its C reference contract. Define input sizes, generation, aliasing, tail behavior and exact expected output. Build both with recorded compiler/options. Inspect whether the compiler vectorized the reference.
Separate preparation, allocation and output from the region under comparison. Prevent the compiler from removing the work by consuming verified results. Choose a finite repetition count and show the distribution over repeated trials, not a single favorable number.
Record board/OS/compiler, CPU temperature/throttling, relevant CPU policy and background activity. Distinguish warm/cold cache conditions. Do not change governors or disable services merely to make a tutorial look faster.
No timing loop is supplied here: the course verifies correctness without leaving CPU work running. Use the separate benchmark planning guide when you actually need a measurement.
What this course does not cover¶
This is a foundation in native Linux AArch64 user-space programming, not an exhaustive ISA specification. Atomics and the memory model, exception levels, MMU/page tables, kernel entry, SVE/SME, full floating-point behavior and production unwind metadata need separate study.
Do not use the ordinary load/store exercises as device-I/O guidance. Follow C++ Hardware Programming for kernel-supported peripherals, or OS Development for the distinct bare-metal learning path.
Choose a next project¶
Extend the array report with an explicit empty minimum/maximum policy, or expose a bounded byte-transform function to C++. First write fixtures, then state overflow and error policies, then implement. Only profile if the application has a measurable unmet requirement.
Check your understanding¶
Which source answers 'may x19 change after a call', and which answers 'does this immediate encode'? Why does fewer instructions not prove less time?
Compare your reasoning
The call-preservation question belongs to the ABI; the encoding question belongs to the architecture/assembler rules. Runtime also depends on dependencies, memory behavior, compiler output and the measured workload.