← board

Inline asm cannot express float or vector code (no xmm operands, no packed SSE, no VEX, no cpuid)

Correction to the original scope

The first version of this ticket claimed only AsmRegLookup was missing xmm names and everything downstream was ready. That is true for scalar SSE and false for everything else. A survey of asmtext.inc (104 mnemonics total):

group status
scalar SSE: movsd movss addsd subsd mulsd divsd addss subss mulss divss comisd ucomisd cvtsd2ss cvtss2sd xorps xorpd pxor encoded
movq xmm↔gp/mem bridge, cvtsi2sd, cvttsd2si encoded
packed SSE2: movapd movupd mulpd addpd subpd divpd cmppd andpd andnpd orpd sqrtpd movmskpd unpcklpd unpckhpd shufpd all missing
AVX / VEX encoding of any of the above (vmulpd vaddpd vcmppd vmovapd vbroadcastsd) all missing — no VEX prefix emitter at all
FMA (vfmadd231pd …) missing
CPU feature discovery: cpuid, xgetbv missing
rdtsc missing (minor, but the obvious companion)
xmm register OPERANDS in inline asm (AsmRegLookup in asmfront.inc) missing

So the work is: operand naming (small) + a packed-SSE2 encoder arm (moderate) + a VEX prefix emitter and the AVX mnemonic set (the real chunk) + cpuid/xgetbv (small, but they gate any runtime dispatch).

Symptoms

pascal26: error: asm: unknown instruction: xorpd ()      { operands failed to parse }
pascal26: error: asm: unknown instruction: cpuid ()      { not in the mnemonic table }

What already exists and should be reused

Suggested phasing

  1. xmm operands in asmfront.inc (size 16), so the ALREADY-ENCODED scalar SSE becomes reachable from Pascal inline asm. Unblocks a scalar-double escape kernel on its own — immediate, visible payoff.
  2. cpuid + xgetbv. Small, and they unblock runtime ISA dispatch even before any vector op exists (a program can then pick between a GP kernel and a scalar-SSE kernel).
  3. Packed SSE2 ($66 prefix over the existing scalar dispatch) — movapd/movupd/addpd/subpd/mulpd/divpd/cmppd/andpd/movmskpd/unpcklpd/shufpd. 2-wide double kernels become writable.
  4. VEX prefix emitter + AVX/AVX2 (v*pd, vbroadcastsd), then FMA. 4-wide. This is the largest piece and is where a real design decision lives (2-byte vs 3-byte VEX selection, and how much of the operand model needs a third source operand for the non-destructive v forms).

Phases 1–3 are worth landing on their own; phase 4 can wait.

Cross-target note

The same question exists for the other backends' vector units — aarch64 NEON (fmul.2d, fcmgt), arm32 VFP/NEON, and their register files (d0..d31, v0..v31, q0..q15) are equally unreachable from inline asm. Per Track O's rule, per-backend effort is x86-64 + aarch64 only; the others can stay portable-fallback indefinitely. Worth deciding whether NEON rides along with phase 3/4 or gets its own ticket.

Consumers waiting on this

Acceptance

[[feature-demo-mandelbrot-gui-threaded]] · [[feature-demo-mandelbrot-asm-autozoom]] · compiler/asmfront.inc (AsmRegLookup) · compiler/asmtext.inc (scalar SSE dispatch to extend) · compiler/asmenc.inc (has the xmm names already).

Log