Add x64 backend

[StachuDotNet]

Add x86_64 native backend

Adds a complete x86_64 (Intel/AMD) backend to the Dark compiler alongside the existing ARM64 backend. The compiler auto-detects the host CPU and emits the correct native code — same Dark source, same test suite, two architectures.

Shared work

• ARM64 files moved to passes/arm64/ and new work lives in passes/x64/ for symmetry.
• PlatformTypes.fs — extracted OS/Arch DU for compile-order availability.
• ArchConfig.fs — per-architecture calling convention configs.
• Platform.fs — x86_64 syscall numbers, architecture detection.
• 5_RegisterAllocation.fs — now takes an Arch DU parameter instead of runtime CPU checks, so the register allocator can be driven by configuration rather than host detection.
• CompilerLibrary.fs — dual-architecture compilation pipeline.
• R11 scratch aliasing. x86_64 has fewer GP registers than ARM64 — LIR registers X8-X17 all map to R11 (scratch). Codegen uses SaveRegs/RestoreRegs patterns when multiple scratch values are needed simultaneously.

New x86_64 passes (passes/x64/)

• 6_CodeGen.fs — LIR to x86_64 instruction translation (3,065 lines)
• 7_Encoding.fs — instruction to machine code bytes (646 lines)
• 7_Resolve.fs — jump label resolution (132 lines)
• 8_Binary_Generation_ELF.fs — ELF executable output (110 lines)
• X86_64.fs — instruction type definitions (registers, conditions, ~47 instruction variants)

Tests

4 new test files (encoding, codegen, resolve, binary) with 556 lines of x86_64-specific unit tests.

Tooling

Diagnostic scripts (debug-stack.sh, debug-x86-crash.sh, disasm-func.sh, dump-lir-func.sh).

Test results

4,529 / 4,530 (99.98%)

1 known failure: memReclaimBurn — requires reference counting (heap memory reclamation). The RC helpers are implemented but disabled (enabling them currently causes 37 test regressions in crypto/other areas). See docs/x64-refcounting.md.

The hard part

The bulk of this work was handling x86_64's two-operand instruction format. ARM64 is three-operand (ADD X0, X1, X2 = "X0 = X1 + X2"), but x86_64 is two-operand (ADD RAX, RCX = "RAX += RCX"). When the LIR says dest = left OP right and dest == right, a naive MOV dest, left; OP dest, right clobbers right before reading it. Every binary operation needed careful handling:

• Commutative ops (Add, Mul, And, Or, Xor): swap operands
• Non-commutative ops (Sub, Div): use scratch/temp register
• Float non-commutative (FSub, FDiv): use XMM15 as temp

Benchmarks: ARM64 vs x86_64

Same run_benchmarks.sh cachegrind pipeline on both arches. ARM numbers are from paul @ 453aaafe (2026-03-05); x64 numbers are from major (Threadripper 3960X) @ 518d00e2 (2026-04-10), so some delta is commit drift, not pure codegen. edigits, fasta, mandelbrot failed to run on x64 and are excluded; reduced-size benchmarks are skipped.

Benchmark	ARM64 (paul)	x64 (major)	x64 / ARM
ackermann	11,450,298,027	12,881,626,223	1.13×
binary_trees	154,007,725	160,561,244	1.04×
collatz	81,441,905	113,644,282	1.40×
factorial	4,420,203	4,790,258	1.08×
fib	686,796,263	746,517,690	1.09×
leibniz	1,200,000,148	1,800,000,168	1.50×
merkletrees	733,993,597	704,505,266	0.96×
nqueen	724,301,430	936,840,115	1.29×
pisum	65,014,671	70,012,708	1.08×
primes	5,443,919	8,563,311	1.57×
sum_to_n	7,002,526	8,002,248	1.14×
tak	635,804,177	604,637,268	0.95×

Geometric mean x64/ARM ≈ 1.15× (x64 emits ~15% more instructions on average). tak and merkletrees are slightly better on x64; primes, leibniz, collatz, and nqueen are the clearest regressions and the best targets for x64 codegen tuning. Aggregate Dark-vs-Rust speedup in RESULTS.md moved from 3.99× (ARM) to 4.57× (x64).

Known gaps

• Encoding test coverage: 11 of 47 instruction types have byte-level unit tests. The remaining 36 are covered by E2E tests but lack encoding-specific regression tests.
• Reference counting: x86_64 emits no RC instructions. Programs work because the 512MB heap suffices for nearly all tests.
• No Mach-O output for x86_64 (Linux ELF only). macOS x86_64 is effectively EOL.