\documentclass[11pt]{article}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage[margin=1in]{geometry}
\usepackage{microtype}
\usepackage{booktabs,tabularx,array}
\usepackage{amsmath}
\usepackage{xcolor}
\usepackage{enumitem}
\usepackage{xurl}
\usepackage{hyperref}
\hypersetup{colorlinks=true,linkcolor=blue!45!black,urlcolor=blue!45!black,citecolor=blue!45!black,pdftitle={Reverse Engineering the CUDA Software Stack},pdfauthor={M. Drake Stapleton},pdfsubject={CUDA++ GB10 toolchain evidence and limitations, version 2}}
\urlstyle{same}
\setlength{\emergencystretch}{2em}
\setlist{leftmargin=*,itemsep=2pt,topsep=5pt}
\newcommand{\cpin}{fbbf3af40db8f02195603dd69c94140758975d4f}
\newcommand{\hpin}{232332422bfdc31c8918085b50f13c1e18ab702e}
\newcommand{\opin}{3364a1dfd0ca50c1b82bf19ba34932d8bc10a7a9}
\newcommand{\rpin}{bf15e82a44fbfa04cbffdafce433d4cd5ed66df4}
\newcommand{\csrc}[2]{\href{https://github.com/aien-dev/CUDApp/blob/\cpin/#1}{#2}}
\newcommand{\hsrc}[2]{\href{https://github.com/aien-dev/CUDApp/blob/\hpin/#1}{#2}}
\newcommand{\osrc}[2]{\href{https://github.com/aien-dev/omega-mv/blob/\opin/#1}{#2}}
\newcommand{\rsrc}[2]{\href{https://github.com/aien-dev/aien-sovereign-core-mv/blob/\rpin/#1}{#2}}
\title{Reverse Engineering the CUDA Software Stack:\\ An Independently Implemented GPU Machine-Code Toolchain for the NVIDIA GB10}
\author{M. Drake Stapleton\\Independent Researcher, Aien, Springfield, MO, USA\\\texttt{drake@aienos.com}}
\date{Version 2, October 26, 2026}
\begin{document}
\maketitle
\begin{abstract}
I describe CUDA++, a research-stage GPU machine-code toolchain and runtime for the NVIDIA GB10 in a DGX Spark. It provides an execution path for demonstrated workloads without NVIDIA's proprietary CUDA user-space compiler, runtime, driver library or mathematics libraries. It is not a drop-in implementation of the CUDA language, APIs or library ecosystem. The path still uses NVIDIA's open Linux kernel modules and signed GPU firmware. I built the first-party implementation by directing AI coding agents, using public interface headers, vendor tools applied offline to my own probe kernels, Mesa's NAK/NVK sources, published technical references and hardware experiments. The implementation includes a driver client of about 900 lines, a kernel builder with 59 intermediate-representation instruction kinds, register allocation and direct launch-descriptor construction. Archived results include exhaustive GPU/CPU-sequence parity for nine declared FP32 operations, a 1,048,576-element vector-add run whose code and output hashes match its host-simulator record, and a live 35B model-serving process with no matched CUDA-library mappings. Numerical parity is distinct from correctly rounded mathematics: the contracts include error bounds and a restricted SIN/COS domain. Model-output evidence is limited to specified prompts and includes a known near-tie token difference. Throughput and launch timings are reported as workload-specific observations, not physical ceilings. This revision corrects the earlier scope, runtime-gating and evidence terminology; distinguishes historical results from the October 26 source snapshot; and identifies missing M16 raw logs that prevent full re-audit of that qualification. No new hardware measurements are introduced.
\end{abstract}
\noindent\textbf{Keywords:} GPU computing; reverse engineering; machine-code generation; device drivers; CUDA; Blackwell; reproducibility

\section{Scope and contribution}
The conventional NVIDIA CUDA software stack supplies compilers, a runtime, a user-space driver library and domain libraries. My goal was to implement the path needed by my workloads without depending on those proprietary user-space components. CUDA++ communicates with NVIDIA's open Linux kernel modules and generates GPU machine code directly. This is a bounded engineering result on one NVIDIA DGX Spark, using the GB10 target identified by the toolchain as \texttt{sm\_121}, rather than a claim that the whole CUDA ecosystem has been replaced.

The main contributions are an RM/UVM driver client, an encoder and kernel builder for a subset of the GB10 instruction set, command-list construction, and a collection of host tests and archived chip experiments. The implementation and historical measurements are public, but their evidence is not uniform: some results have raw logs and hashes, some are summaries, and some planned capabilities have no hardware qualification. I distinguish these cases throughout.

Version 1 was published on October 22, 2026 \cite{v1}. I preserve its historical results where the evidence supports them and correct broader interpretations. The historical CUDApp snapshot used here is \texttt{232332422bfd}; the later snapshot is \texttt{fbbf3af40db8}. Full hashes and immutable source links are in Section~\ref{sec:reproduce}. A result measured on an earlier implementation is not automatically a qualification of either snapshot.

\section{Sources and implementation method}
\subsection{Public interfaces and prior work}
NVIDIA's open kernel-module headers define the RM ioctl interfaces, object classes and UVM controls used by the client. CUDA++ includes 67 interface headers from release 580.173.02 with their NVIDIA MIT notices. These user-space interface definitions should be distinguished from the combined Linux kernel module, which NVIDIA licenses under MIT/GPLv2 \cite{thirdparty,nvidia-open}.

I used \texttt{nvcc} 13.0.88 and \texttt{cuobjdump -sass} offline on small CUDA C++ kernels written for probing. Changing one register, immediate, predicate or modifier at a time gave candidate encoding rules. The research use of vendor tools is separate from the resulting execution path, which does not require them. Some optional host cross-checks still use \texttt{nvdisasm} when installed; that test dependency has not been retired.

Mesa's NAK encoder and latency/QMD definitions, and NVK's compute-dispatch sequence, supplied hardware facts and implementation references. The repository attributes these uses and reports that no Mesa source code was copied \cite{thirdparty,method}. NVIDIA's PTX documentation and Binary Utilities instruction-set references also informed the work. It is too broad to call SASS wholly undocumented: NVIDIA publishes mnemonic-level references and disassembly tools. Recovering the binary fields and scheduling details needed here still required source inspection and experiments \cite{binaryutils}.

The tensor-arithmetic model also draws on published numerical research, explicitly credited in its source. The model header identifies the work of Fasi, Higham, Mikaitis and Pranesh \cite{fasi2021} as a basis for candidate accumulation models \cite{tensor}. Hardware observations test those candidates; agreement with a finite probe set is not a complete mathematical specification of the tensor unit.

\subsection{Authorship and provenance}
I set the architecture, directed AI coding agents (Claude, Codex, Grok and Gemini), and selected or rejected their first-party implementation work. The repository records this AI-assisted method and the identities in its commit metadata. NVIDIA's retained headers and other acknowledged third-party material are not my authorship.

\paragraph{Use of AI tools.} I directed this work and am responsible for its content. AI coding agents (the Claude, Codex, Grok and Gemini models named above) wrote most of the first-party code and ran the hardware measurements under my direction. AI writing assistants, including Anthropic Claude models used through the omp agent harness, drafted and revised the text of this paper under my direction. No AI tool is an author. Every number in this paper is tied to a public log, commit or pull request listed in the bibliography.

The extraction and later provenance audits report scoped checks of commit identities, notices, credential patterns and binary content. They do not prove the origin of every line, authenticate every historical account, or constitute a legal clean-room certification \cite{audit}. Accordingly, this revision uses ``independently implemented'' in the title and states the actual sources and boundaries rather than implying a separately certified clean-room process. I did not disassemble, decompile or patch proprietary NVIDIA programs; the documented oracle procedure inspected output generated from my own probes. The historical extraction audit reports removal of a vendor-generated disassembly listing from the published CUDApp cut; source repositories and extracted histories must not be conflated.

\section{The execution path}
\subsection{Driver client and memory}
\label{sec:driver}
The client in \texttt{nvrm/nvrm.c} is 908 lines in the reviewed October 26 snapshot. It uses \texttt{/dev/nvidiactl}, a GPU device file and \texttt{/dev/nvidia-uvm}. The implemented sequence is \cite{driver}:
\begin{enumerate}
\item Allocate the RM client, device and subdevice; query the class list and require the expected compute, GPFIFO and usermode classes.
\item Create a GPU virtual-address space and register it with UVM, which manages the page tables.
\item Allocate system-memory buffers and map each at corresponding CPU and GPU virtual addresses. For these allocations there is one underlying shared-memory buffer rather than separate host and device copies.
\item Create the channel group, context share and channel. A GPU-uncached 64~KiB allocation holds the GPFIFO ring and USERD page; the compute object is created beneath the channel.
\item Write an 8-byte ring entry, issue the required memory barriers, update GPPut and ring the usermode doorbell with a 32-bit store.
\item Poll a completion word under bounded wait rules. An uncertain completion leads the session to retain potentially live resources and refuse further work on that session.
\end{enumerate}
The established enqueue-and-ring fast path has no system call. Initialization, allocation, diagnostics and other runtime operations are outside that statement. Cacheability and CPU/GPU visibility are explicit platform requirements; the current path requires GPU-uncached storage for host-polled synchronization words. This is a contract for the tested driver/chip path, not a universal rule for all GPU memory systems.

The M16 qualification programs implement doorbell-withheld/doorbell-rung controls, process-map inspection and two-channel checks. However, the imported M16 summary references a raw-evidence directory and a superseded receipt absent from CUDApp. Its historical PASS fields remain data, not independently re-audited proof. The October 26 README explicitly labels current native qualification \texttt{NOT\_RUN} and requires a new authorized run with retained raw logs \cite{m16}. Other archived chip experiments are discussed separately below.

\subsection{Machine-code generation and submission}
The \texttt{BlackwellIROpcode} enumeration contains 59 instruction kinds. The implementation includes virtual registers, register allocation, instruction encoders and QMD construction. This is an implemented subset, not the complete hardware ISA. Golden-word tests and optional disassembler cross-checks cover particular encodings; they do not by themselves establish every operand combination or scheduling behavior on hardware \cite{encoder}.

The fixed unsigned-integer vector-add encoder contains 32 128-bit instructions: 512 bytes, or 128 32-bit words. The later \texttt{hello\_gpu} floating-point example uses the kernel builder and has its own archived code hash. Keeping these examples distinct avoids treating every vector-add record as the same program.

The BF16 tensor probe defines 2,048 cases with operand classes intended to distinguish candidate HMMA accumulation models. The source permits separate confirmation seeds and a dropped-accumulator negative control. This supports a repeatable model-fitting method, not exhaustive characterization of all BF16 matrices \cite{tensor}.

Command lists supply program addresses, arguments, QMDs, cache operations and launch commands. Source comments attribute dispatch ordering to Mesa NVK. Actual timings depend on barriers and workload configuration; Section~\ref{sec:performance} gives the measured scope rather than one universal launch cost.

\subsection{What the zero-CUDA checks establish}
The repository contains several distinct mechanisms \cite{gates}:
\begin{itemize}
\item \texttt{tools/zero-cuda-gate.sh} checks selected ELF dependencies and imported symbols, with a synthetic negative control.
\item The M16 qualification executable inspects its process mappings for \texttt{libcuda}/\texttt{libcudart} and fails that test when detected.
\item Several submit wrappers populate optional diagnostic fields for linkage, symbols and process mappings. They do not make those fields a mandatory pre-launch refusal: callers can omit the execution-info output, and the returned flags are not themselves launch-admission conditions.
\end{itemize}
Thus I do not claim a universal runtime gate that refuses any NVIDIA library in every calling process. A process-map snapshot establishes what was mapped at its observation time, subject to the stated matching rule; an ELF check establishes the inspected dependency surface. Neither removes the kernel modules or firmware, and neither is a universal proof against later dynamic loading.

\section{Evidence classes used in this paper}
\label{sec:classes}
Each quantitative statement below carries one of four labels. \textbf{MEASURED (chip)}: read from a raw log or receipt produced on the GB10 and archived at the linked commit. \textbf{MEASURED (host)}: read from a host or simulator log. \textbf{REPORTED}: stated in a pull-request description or summary file without an archived full transcript. \textbf{DERIVED}: computed from measured values by a stated formula; I rechecked each derived value from the logged parameters. This revision adds no new measurement; no binary was rebuilt to confirm a recorded binary digest.
\begin{table}[htbp]
\centering\small
\caption{Quantitative claims, their evidence class and their artifact.}
\label{tab:classes}
\begin{tabularx}{\linewidth}{@{}X l l@{}}
\toprule
Claim & Class & Artifact \\
\midrule
380 reduction cases, 148 load/store specifications, Gate 5 26 tests, all PASS & MEASURED (chip), summary & \cite{e1} \\
$2^{32}$ inputs per operation, nine operations, 0 mismatches, 0 unwritten & MEASURED (chip), raw logs & \cite{transclogs} \\
Declared maximum ULP per operation (Table~\ref{tab:ulp}) & contract, host-measured & \cite{transccontract} \\
1,048,576 elements, 0 wrong, matching code and output hashes & MEASURED (chip and simulator) & \cite{hello} \\
No mapped CUDA library in the serving process & MEASURED (process snapshot) & \cite{serve} \\
32/32 on three prompts, 31/32 on a fourth, 24/24 HTTP tokens & MEASURED (chip) & \cite{model} \\
115.14 and 115.36 TFLOPS & DERIVED from measured median times & \cite{perf} \\
195.1 and 207.7 GB/s & DERIVED from measured times, modified tree & \cite{perf} \\
25.09 to 31.97~$\mu$s and 2.68 to 9.68~$\mu$s per added launch & DERIVED from measured spans & \cite{launch} \\
94/94 submit gate, 54 swap checks & REPORTED (host) & \cite{hostprs} \\
\bottomrule
\end{tabularx}
\end{table}

\section{Archived results and their limits}
\subsection{Numerical closure}
The E1 closure summary records 380 reduction cases for SUM, MAX, MIN and MEAN, 148 load/store specifications, and a 26-test Gate 5 result. It also combines exhaustive GPU/CPU-sequence parity for nine FP32 operations \cite{e1}. The earlier four-operation run used Omega \texttt{4863803a47f2}; the later five used \texttt{fb36109d39bd}. The second commit sits on a feature branch and is not an ancestor of the Omega main branch; the closure instead records that binaries rebuilt on merged main (\texttt{40d1ea378617}) equal the chip binaries by digest. Closure records equality of relevant earlier kernel digests with the candidate, and separates the merged-main host rerun from the chip execution. The closure file's name is the SHA-256 of its canonical content without the digest field; that digest, and the digests of the two transcendental receipts and their raw logs, recompute exactly. Its digests are integrity checks, not authenticity.

The raw transcendental logs report $2^{32}=4{,}294{,}967{,}296$ input encodings per operation with zero mismatches and unwritten outputs \cite{transclogs}. The comparison target is the frozen \texttt{omega\_math\_*} CPU sequence, including exceptional-value rules. This is bitwise implementation parity, not a claim that all nine mathematical functions are correctly rounded over their usual real domains.

\begin{table}[htbp]
\centering\small
\caption{Declared numerical contracts accompanying the exhaustive parity claim. The error bounds are those reported by the CPU numerical contract, not a new accuracy measurement.}
\label{tab:ulp}
\begin{tabularx}{\linewidth}{@{}l c X@{}}
\toprule
Operation & Declared max ULP & Important boundary \\
\midrule
EXP2, LOG2 & 2 & Base-two operations; specified exceptional-value behavior. \\
SIGMOID, TANH & 3 & Defined saturation and signed-zero rules. \\
ERF, GELU & 3 & GELU uses the erf form; specified tail behavior. \\
SIN, COS & 2 & Admitted domain $|x|\leq2^{22}$; outside it returns canonical NaN. \\
RSQRT & 0 & Correct-rounding contract for positive inputs; specified zero, infinity and negative-input results. \\
\bottomrule
\end{tabularx}
\end{table}
The contract specifies operation order, rounding environment, canonical NaNs and subnormal treatment. Its mathematical-accuracy comparison uses a binary128 reference with a documented hard-to-round caveat; the nonzero declared bounds include a margin. An exhaustive encoding sweep includes intentional NaN outputs outside the admitted trigonometric domain. Natural-base EXP and LOG are not GB10 kernels in this closure and must not be inferred from EXP2 and LOG2 \cite{transccontract}.

\subsection{Vector-add correspondence}
The October 22 \texttt{hello\_gpu} chip log records 1,048,576 checked FP32 additions, zero wrong results and zero never-written values, with exit code zero. The simulator record reports the same result. Both name machine-code SHA-256 \texttt{6248b8ed3380\ldots} and output SHA-256 \texttt{72d0c1b29287\ldots}; the complete hashes are in the linked logs \cite{hello}. This is a concrete correspondence for one program, input construction and recorded run. It is not a standing qualification of all later commits or all input arrays.

\subsection{Model serving and output comparison}
The October 21 live-serving snapshot names a Qwen3.6-35B-A3B-FP8 model directory at revision \texttt{95a723d0}, the server executable hash and its command line. It lists the C library, mathematics library, \texttt{libgcc\_s} and loader, with zero mappings matching its CUDA-library pattern. It also records the NVIDIA 580.173.02 open kernel driver and open NVIDIA device files \cite{serve}. This supports the observed process-level user-space dependency claim, not numerical-output parity by itself.

Separate October 21 motor evidence compares token choices with the project's Rust CPU forward pass \cite{model}. Under the documented fixed 0.1-logit near-tie rule, three 32-token teacher-forced prompts match 32/32 token IDs; a fourth matches 31/32, with its one mismatch inside the permitted band. The fourth raw receipt explicitly records nonidentical goldens. A distinct HTTP gate records one 24-token greedy completion matching all 24 reference token IDs. These are bounded checks, not bit-identical logits or universal model equivalence.

The same evidence preserves an initial adaptive-band gate as withdrawn: deriving the band from the run's own error let a deliberately broken implementation pass. The fixed-rule rerun includes a failing negative control. It also documents a later prose-prompt failure outside the band. These exclusions matter when interpreting the selected passing examples. The process-map snapshot and output gates name different executable identities; the later live binary must not silently inherit an earlier binary's output qualification.

\subsection{Performance observations}
\label{sec:performance}
The October 13 tensor probe uses HMMA.16816.F32.BF16 and reports median times over five trials, with 4,096 floating-point operations counted per HMMA instruction ($2 \times 16 \times 8 \times 16$). Throughput is CTAs $\times$ warps per CTA $\times$ 4,096 iterations $\times$ accumulator chains $\times$ 4,096 operations, divided by the median time. Its clean-tree log records 115.36~TFLOPS for 384 CTAs of 4 warps with 16 chains (median 3,574.3~$\mu$s) and 115.14~TFLOPS for 384 CTAs of 8 warps with 16 chains (median 7,162.2~$\mu$s); both recompute from those parameters. These are achieved probe throughputs, not a demonstrated physical upper bound \cite{perf}.

The bandwidth log records 195.1~GB/s for a 96~MiB distinct working set and 207.7~GB/s for 384~MiB; repeated access to the same data gives different delivered rates. GB/s here is decimal bytes per nanosecond, while the source's working-set labels use binary-size arithmetic. The bandwidth run records \texttt{dirty=3}, a nonzero working-tree change count, while the tensor run four minutes earlier records \texttt{dirty=0}. The commit identifier alone cannot reconstruct the modified working tree. These observations should not be promoted to exact reproducible ceilings without the corresponding source changes and experimental conditions \cite{perf}.

The October 14 launch-cost archive has two receipts. Run 1 records four failed checks and verdict FAIL; its timing samples do not make it a passing qualification. Run 2 has 11 checks, zero failures and verdict PASS. For that run, the recorded incremental wait-for-idle launch estimates range from 25.09 to 31.97~$\mu$s; the no-barrier estimates range from 2.68 to 9.68~$\mu$s. The configuration uses $n=16{,}384$, $k=2{,}048$ and 20 repetitions. These estimator values depend on barrier policy and workload, and should not be generalized to every dependent launch \cite{launch}.

\subsection{Host tests and evidence strength}
The October 22 submit-path PR reports an earlier 94/94 gate; the swap-command PR reports 54 passing host checks after rebase. These are host results reported in PR descriptions, not new chip experiments or immutable full test transcripts \cite{hostprs}. Mutation tests show that specified deliberately broken variants are detected; passing them is useful evidence, not proof that all faults are excluded.

The E1 closure explicitly describes its digests as integrity checks, not authenticity. I therefore use \emph{hash-addressed receipts}, not ``signed chip receipts.'' A Git commit signature also does not turn a measurement into hardware attestation. Receipt authenticity requires a stated signer, trust model and verification procedure separate from content hashing.

\section{Coverage and open qualification}
\label{sec:limits}
Table~\ref{tab:coverage} summarizes the supported scope and known limits. Several were already partial or missing in the October 22 roadmap; they are not merely later regressions \cite{roadmap}.
\begin{table}[htbp]
\centering\small
\caption{Scope of the reviewed toolchain, not a CUDA compatibility guarantee.}
\label{tab:coverage}
\begin{tabularx}{\linewidth}{@{}p{0.25\linewidth} X@{}}
\toprule
Component & Evidence and boundary \\
\midrule
Code generation & Native GB10 subset, 59 IR kinds and QMD builder; no complete CUDA-language or ISA claim. \\
Driver client & RM/UVM implementation exists; imported M16 raw evidence is incomplete; current native qualification is NOT\_RUN. \\
Runtime & Memory, synchronous launch and command lists; general streams/events and process isolation remain qualification work. \\
Math libraries & Model-shaped matrix multiplication and attention; general any-shape coverage, scans and sorts remain incomplete. \\
FFT and RNG libraries & Roadmap marks cuFFT/cuRAND replacements missing. \\
Disassembly & Optional vendor cross-checks remain; independent disassembler work is not a completed CUDApp replacement. \\
Kernel and firmware & NVIDIA open kernel modules and signed firmware remain in the demonstrated path. \\
Portability & One demonstrated GB10/Linux/driver combination; no qualification of arbitrary GPUs, operating systems or driver releases. \\
\bottomrule
\end{tabularx}
\end{table}

The October 26 first-run guide calls CUDA++ research-stage and not a drop-in replacement for all CUDA. Its compatibility preflight is wrapper-only: \texttt{make doctor} checks target and driver, and \texttt{make hello-gpu} runs it first. Direct library callers and binaries do not have the same driver-version/PCI-ID admission guard. READY is a diagnostic result, not current-commit chip qualification \cite{currentguide}.

A replacement kernel driver remains work in progress; this paper does not claim that it has displaced NVIDIA's modules. Recovery after a fault, multi-process safety and broader library coverage need their own retained receipts. A timeout reported to the host does not establish that the GPU has stopped or that resources can safely be reused. Current first-party CUDApp is primarily C; planned migration work must not be described as already complete. No cross-vendor backend or standards-conformance result is established here.

\section{Reproducibility and licensing}
\label{sec:reproduce}
\subsection{Frozen source references}
The following full hashes define this revision's evidence-reading snapshots; they do not replace the different execution commits recorded inside individual experimental receipts:
\begin{itemize}
\item Historical CUDApp: \href{https://github.com/aien-dev/CUDApp/tree/\hpin}{\nolinkurl{232332422bfdc31c8918085b50f13c1e18ab702e}}.
\item Reviewed CUDApp: \href{https://github.com/aien-dev/CUDApp/tree/\cpin}{\nolinkurl{fbbf3af40db8f02195603dd69c94140758975d4f}}.
\item Reviewed Omega evidence: \href{https://github.com/aien-dev/omega-mv/tree/\opin}{\nolinkurl{3364a1dfd0ca50c1b82bf19ba34932d8bc10a7a9}}.
\item Reviewed Core model evidence: \href{https://github.com/aien-dev/aien-sovereign-core-mv/tree/\rpin}{\nolinkurl{bf15e82a44fbfa04cbffdafce433d4cd5ed66df4}}.
\end{itemize}
The bibliography links to files at those hashes, including raw logs where available. Readers should record the execution commit, source modifications, compiler and flags, artifact hashes, machine and driver identity, commands, exit codes and exclusions for each reproduced result. A build/test PASS, simulator PASS, physical-chip PASS and independently replicated PASS are different evidence categories. A skipped or unavailable gate is NOT RUN, never PASS.

\subsection{Reproduction workflow and missing evidence}
Begin with a detached checkout at the chosen snapshot and the corresponding first-run guide. Record \texttt{git rev-parse HEAD}, working-tree status, OS/architecture and compiler version. Host build/tests, the simulator and ELF dependency gate do not require a new hardware experiment. The full suite has host-architecture restrictions: an x86-64 build failure on AArch64 memory-ordering instructions must be reported, not bypassed and called a pass \cite{currentguide}.

Physical GB10 tests require compatible driver/kernel state and an authorized quiet window that does not interrupt a serving workload. Retain raw output, negative controls and source/binary hashes. Missing M16 raw logs prevent complete re-audit of the imported qualification; they do not demonstrate that the historical experiment did not occur. Likewise, a protocol can be runnable while its original result remains incompletely archived. The dirty bandwidth run needs its exact source modifications for exact reconstruction. No new hardware run or full historical reconstruction was performed for this revision.

\subsection{License snapshots}
Version 1 correctly described the historical CUDApp release as MIT. That historical grant remains available at \texttt{232332422bfd}. In the October 26 snapshot, first-party material is offered under Apache-2.0 WITH LLVM-exception, subject to any explicit file-specific notices; NVIDIA headers and other third-party material retain their own terms. Later contributions do not become MIT merely by being copied onto the historical branch. The transition and bounded provenance review are documented separately \cite{license,audit}.

\section{Conclusion}
CUDA++ demonstrates a readable path from selected programs to GB10 machine-code execution without the proprietary CUDA user-space components used by the conventional stack. The strongest evidence is attached to particular source versions, workloads and measurements. The implementation does not yet provide complete CUDA compatibility, general library coverage, universal runtime admission or qualification of every later revision. Publishing those limits alongside the working encoder, driver client and experimental records makes the engineering result more useful and more reproducible.

\section*{Revision statement}
Version 2 corrects the complete-replacement and mandatory-runtime-gate claims; narrows model-output equality; adds the FP32 numerical domains and error-contract distinction; replaces signature/ceiling language with the actual receipt and measurement scope; identifies missing M16 evidence and dirty-tree reconstruction limits; and separates historical MIT licensing from the later license. It changes the subtitle to avoid implying a certified clean-room process, and labels each quantitative claim by evidence class (Section~\ref{sec:classes}). Version 1 remains the historical publication. This revision introduces no new chip performance or correctness measurements.

\section*{Acknowledgements}
I acknowledge Mesa's NAK/NVK developers and NVIDIA's open kernel-module team for the public work on which this implementation relies. Their contributions, notices and the distinction between included material and technical references are documented in the repository.

\begin{thebibliography}{99}
\small
\bibitem{v1} M. D. Stapleton. \emph{Reverse Engineering the CUDA Software Stack: A Clean-Room GPU Machine-Code Toolchain for the NVIDIA GB10}. Version 1, October 22, 2026. \url{https://doi.org/10.5281/zenodo.23578453} (all versions: \url{https://doi.org/10.5281/zenodo.23578452}).
\bibitem{fasi2021} M. Fasi, N. J. Higham, M. Mikaitis and S. Pranesh. Numerical behavior of NVIDIA tensor cores. \emph{PeerJ Computer Science} 7:e330, 2021. \url{https://doi.org/10.7717/peerj-cs.330}.
\bibitem{thirdparty} CUDA++. \csrc{THIRD_PARTY.md}{Third-party material and notices}; \hsrc{THIRD_PARTY.md}{historical notices}.
\bibitem{nvidia-open} NVIDIA. \emph{Open GPU kernel modules}, release 580.173.02. \href{https://github.com/NVIDIA/open-gpu-kernel-modules/tree/580.173.02}{Versioned source}; \csrc{third_party/nvidia-open-580.173.02/COPYING}{retained license text}.
\bibitem{method} CUDA++. \csrc{docs/HOW_I_DID_IT.md}{Documented implementation method}. Historical method statements are subject to the evidence qualifications in this revision.
\bibitem{binaryutils} NVIDIA. \emph{CUDA Binary Utilities 13.0}, instruction-set references and disassembly tools. \url{https://docs.nvidia.com/cuda/archive/13.0.0/cuda-binary-utilities/index.html}.
\bibitem{tensor} CUDA++. \csrc{tests/bw_hmma_model.h}{BF16 accumulation model and prior-work attribution}; \csrc{tests/gpu_tc_probe_test.c}{2,048-case probe and negative control}.
\bibitem{audit} CUDA++. \csrc{docs/AUDIT.md}{Historical extraction audit}; \csrc{docs/LICENSE_PROVENANCE.md}{later bounded provenance audit}.
\bibitem{driver} CUDA++. \csrc{nvrm/nvrm.c}{RM/UVM client implementation}; \csrc{docs/DRIVER.md}{driver walkthrough}; \csrc{src/omega_gpu_session.c}{session and uncertain-state handling}.
\bibitem{m16} CUDA++. \csrc{evidence/m16-blackwell-native-path-requalification-receipt.json}{Imported M16 summary}; \csrc{README.md}{current README evidence limitation}; \csrc{m16/m16_requalify.c}{qualification executable}.
\bibitem{encoder} CUDA++. \csrc{src/omega_blackwell_codegen.h}{IR and register definitions}; \csrc{src/omega_blackwell_codegen.c}{encoder and fixtures}; \csrc{src/omega_blackwell_encoder.c}{fixed integer vector-add table}; \csrc{src/omega_blackwell_qmd.c}{QMD builder}.
\bibitem{gates} CUDA++. \hsrc{src/omega_blackwell_submit.c}{Historical submit diagnostics}; \csrc{src/omega_blackwell_submit.c}{current submit diagnostics}; \csrc{tools/zero-cuda-gate.sh}{ELF dependency gate}.
\bibitem{e1} CUDA++. \csrc{evidence/E1-CLOSURE/e7851c69d34ac777a9436af16d0bdd5d69264c8528c62d562b600f5d89153061.json}{E1 closure summary and constituent digests}. Omega: \osrc{docs/numeric/E1_GAP_TABLE.md}{closure scope and exclusions}.
\bibitem{transclogs} Omega. \osrc{evidence/E1-TRANSC-GB10/blobs/c65e00416a7d4454bf6353df51f1d74bdac155b7e0b32e7940592999b7b1c5ad.log}{Four-operation exhaustive raw log}; \osrc{evidence/E1-TRANSC-GB10/blobs/bb7531300676daedcb3c10c91a708daa0c7f16c669dc62bb8e2218f3dcddf636.log}{five-operation exhaustive raw log}.
\bibitem{transccontract} Omega. \osrc{docs/numeric/E1_TRANSCENDENTAL_CONTRACT.md}{Frozen CPU transcendental contract, domains, ULP metric and oracle limitations}. Its initial GPU-status text is superseded for the documented operations by the later closure receipts, not by this revision.
\bibitem{hello} CUDA++. \csrc{evidence/l424/hello-chip.log}{October 22 chip log}; \csrc{evidence/dx/d3-faults/hello-sim-spark.txt}{simulator logs}; \href{https://github.com/aien-dev/CUDApp/pull/2}{historical PR 2}.
\bibitem{serve} Omega. \osrc{evidence/WHAT-OMEGA-IS-20261021/live-serve-no-cuda.txt}{October 21 live-server process-map, binary and driver record}.
\bibitem{model} Aien Sovereign Core. \rsrc{evidence/motor-chip-20261021/README.md}{October 21 motor gates, withdrawals and exclusions}; \rsrc{evidence/motor-chip-20261021/gate1b-p4.json}{fourth-prompt raw result}; \rsrc{evidence/motor-chip-20261021/gate2-real.json}{24-token HTTP result}; \rsrc{evidence/q36-host-20261020/ORACLE.md}{CPU forward-reference description}.
\bibitem{perf} CUDA++. \csrc{evidence/OWN30B-T3-TC-PEAK-BW-5faa0f70-20261013T2236Z/peak.log}{Clean-tree tensor log}; \csrc{evidence/OWN30B-T3-TC-PEAK-BW-5faa0f70-20261013T2236Z/bw.log}{dirty-tree bandwidth log}; \href{https://github.com/aien-dev/omega-mv/blob/5faa0f70f22faf07d2589a14ef2d2e3b7416709a/tests/gpu_tc_peak_test.c}{probe source at the execution commit \texttt{5faa0f70}}; \csrc{tests/gpu_tc_peak_test.c}{later copy in CUDApp}.
\bibitem{launch} CUDA++. \csrc{evidence/OWN30B-LAUNCH-COST-20261014T0120Z/r1/receipt.json}{Launch-cost run 1 (FAIL)}; \csrc{evidence/OWN30B-LAUNCH-COST-20261014T0120Z/r2/receipt.json}{run 2 (PASS)}.
\bibitem{hostprs} CUDA++. \href{https://github.com/aien-dev/CUDApp/pull/4}{PR 4, reported earlier 94/94 submit gate}; \href{https://github.com/aien-dev/CUDApp/pull/3}{PR 3, reported 54/0 swap host checks}. PR descriptions are mutable summaries.
\bibitem{roadmap} CUDA++. \hsrc{ROADMAP.md}{Historical roadmap}; \csrc{ROADMAP.md}{October 26 roadmap}.
\bibitem{currentguide} CUDA++. \csrc{docs/START_HERE.md}{First-run and evidence guide}; \csrc{docs/runtime/API.md}{runtime API and admission boundary}; \csrc{docs/runtime/PORTABILITY.md}{platform portability contract}.
\bibitem{license} CUDA++. \csrc{docs/LICENSING_TRANSITION.md}{License transition and historical MIT access}; \hsrc{LICENSE}{historical MIT license}; \csrc{LICENSE}{reviewed current license}.
\end{thebibliography}
\end{document}