Static Blackwell SASS audit
The sm_120 compiler already maps the external SHA-256d arithmetic to Blackwell-native shift, Boolean and add instructions.
Diagnostic work, exact algebra and local capabilities are not treated as end-to-end mining advantage.
What was tested?
The sm_120 compiler already maps the external SHA-256d arithmetic to Blackwell-native shift, Boolean and add instructions.
Why the test is meaningful
Static disassembly can verify instruction selection and memory behavior even when performance counters are unavailable.
native share=(SHF+LOP3+IADD3)/all SASShot-path global loads/stores=0spill count=0How it was tested
Disassemble the nine exact EXP-133 binaries with cuobjdump and count instruction families, registers, local memory and hot-path memory operations.
What happened
Each binary emitted 2,512 SASS instructions: 1,176 SHF, 629–630 LOP3 and 408 IADD3. Those families represented 88.097–88.137% of static code. The hot body had no global loads/stores, stack use or local memory; all 9/9 gates passed.
Exactness and statistical controls
The audit used already frozen binaries and did not substitute a new benchmark. Counts were repeated across all geometries.
What the result means
Blind intrinsic replacement and blind geometry tuning are closed: the compiler already emits the expected native integer forms.
Limitations
- Static counts do not reveal runtime issue stalls.
- Instruction mix is architecture-specific.
- Native mapping alone is not a mining advantage.
Evidence trail
Disassemble the sealed binaries with matching CUDA tools and reproduce family, register and spill counts.
Canonical variants
CANONICAL-EXP-135PREREGISTERED-CAMPAIGNSEALED-AUDITSource: internally audited canonical reports. Local filesystem structure, private headers and operational identifiers are excluded from publication.