Asm X64 To Arm64

Two scenarios this skill covers

1. Inline asm in C/C++ — asm volatile (...) / __asm__ (...) blocks gated by #ifdef __x86_64__. Constraints, clobbers, and operand templates change; the surrounding C does not.
2. Standalone .asm files (MASM x64 → GAS arm64 .S) — entire files of OPTION PROLOGUE:NONE / MY_PROC name, n / mov rax, [rsi] style code, plus their macro headers. The dialect changes wholesale; translate the directive layer first, then the body.

The instruction-level mappings (registers, ABI, EFLAGS↔NZCV, atomics, SIMD, memory model) apply to both scenarios identically — only the syntactic container differs.

Critical pre-translation check

Before applying any rules below, identify:

1. Source x64 ABI variant — System V AMD64 (Linux/macOS) or Windows x64. They differ in argument register order, callee-saved set, and shadow space. See [[register-and-abi]].
2. Target toolchain — clang integrated assembler (recommended; same .S works on Linux/macOS/Windows-on-ARM64) or Microsoft armasm64.exe (which does not consume GAS syntax). See [[standalone-asm-dialect]].
3. Concurrency requirements — any plain mov to/from memory that survived under x64 TSO must be reviewed for required ordering on arm64. See [[memory-model-and-atomics]].

Spec dimensions

Detailed translation rules are organized by topic in references/specs/. Each .md is paired with a structured .yaml for tooling.

Worked example reference

• [[lzma-dec-port]] — 7-zip's Asm/x86/LzmaDecOpt.asm (1500-line MASM x64 hot loop) ported to Asm/arm64/LzmaDecOpt.S GAS arm64. Demonstrates the macro-shim idiom end-to-end, register-pressure annotations, PSHIFT-style data-width abstraction, calling-convention contract with the surrounding C, and Windows-on-ARM64 toolchain selection.

Preprocessor guards

Wrap architecture-specific blocks with standard guards. Split Apple vs. Linux arm64 only when the instruction actually differs (e.g. tpidrro_el0 vs tpidr_el0):

#if defined(__x86_64__) || defined(__i386__)
    /* x64 path */
#elif defined(__aarch64__) && defined(__APPLE__)
    /* Apple arm64 */
#elif defined(__aarch64__)
    /* Linux / other arm64 */
#else
    /* fallback */
#endif

Task

First identify which scenario applies.

Scenario A — inline asm: the target is asm volatile / __asm__ blocks inside C/C++.

1. Read the target code.
2. Identify every block that is x64-specific (x64 instructions, named register constraints, or __x86_64__/__i386__ guards).
3. For each block, determine the intent first (timing? CPU ID? atomic? SIMD?), then apply the correct mapping from the relevant spec — do not mechanically swap mnemonics.
4. Rewrite operand constraints and clobbers per [[inline-asm-constraints]].
5. Wrap both variants in appropriate preprocessor guards.
6. Add a one-line comment only when arm64 semantics differ non-obviously from x64 (e.g. added dmb, changed zero-input behavior, implicit vs explicit register).
7. Do not change non-asm logic. Do not introduce unnecessary abstractions.
8. Show the converted code and explain non-obvious translation decisions in 1–2 sentences.

Scenario B — standalone .asm file: the target is a full MASM x64 file (and typically a paired macro header).

1. Translate the macro header first per [[standalone-asm-dialect]]. It defines the vocabulary the body uses; without it the body translation is meaningless.
2. Replace dialect directives (.code → .text, PROC/ENDP → .global + label, equ → .equ, macro/endm → .macro/.endm).
3. Translate the procedure prologue/epilogue once and reuse: AAPCS64 typically needs stp x29, x30, [sp, #-16]! on entry and ldp + ret on exit. See [[register-and-abi]].
4. If the file is a long hot loop, consider the macro-shim idiom (see [[lzma-dec-port]]) before line-by-line translation.
5. Translate the body. For each x86 instruction: choose 2-op or 3-op form, decide whether the S-suffix flag-setting variant is needed ([[flags-and-conditions]]), rewrite memory addressing ([[memory-addressing]]), translate jcc to b.<cond> watching the inverted carry semantics.
6. Add #ifdef __APPLE__ switches around every .globl for Mach-O underscore prefix.
7. Verify the symbol still satisfies any link-time version contract with surrounding C (function name suffix _3 etc.) and any shared struct layout (offsetof() .equ constants must match what the C compiler produces).
8. Wire into the build system: pick clang -c --target=... (cross-platform GAS) or armasm64.exe (Windows-only ARMASM dialect — last resort).
9. Test: build, link, run a functional test (e.g. compress/decompress round-trip), then a benchmark to confirm the asm path is actually faster than the C fallback. If it isn't, the port likely has redundant flag-setting or missed a pre/post-indexed addressing opportunity.
10. Compute kernel (transform / filter / metric / DSP inner loop)? Re-tune the shape, don't transliterate — see [[neon-asm-performance]]. A numerically correct port that mirrored the x86 shape typically runs ~2× too slow. Before declaring done, check for the four anti-patterns: per-output addv horizontal reduction, mov+dup constant materialization on the MAC critical path, over-widening the accumulator (8-bit kernels that leave .8h too early), and full-matrix multiply where a partial butterfly belongs. If a prior/upstream arm64 kernel exists, confirm throughput is ≥ it.
11. Baseline already tuned and the target CPUs have DotProd/i8mm? Consider the extension tier — see [[neon-isa-extensions-dispatch]]. udot/sdot (SAD/SSD ~2×) and usmmla (FIR) need three pieces together: an isolated +dotprod/+i8mm translation unit, per-OS feature detection, and a capability-mask-honoring dispatch. An extension instruction on a CPU without the feature is SIGILL, so it is only safe behind runtime detection — never smuggle udot into a baseline armv8-a object.