v6.6 Engine (Legacy Archive)
v6.6 was the template-driven inference generation of C-Kernel-Engine: GGUF conversion, hand-merged graph templates, IR1/IR2 lowering, quantized GEMM/GEMV dispatch, and generated-C execution. It is archived under version/legacy/v6.6/. Active development is v8 inference (circuits, kernel maps, generated-C runtime) and v7 training.
Build pipeline and IR
End-to-end pipeline (was PIPELINE.md, docs/BUILD_PIPELINE.md)
The v6.6 flow converted a Hugging Face config plus GGUF metadata into weights.bump with a sidecar manifest, built IR1 (a forward op graph with typed tensors and kernel IDs) by merging the model's graph template with the manifest, lowered through IR2 (fusion detection, MEGA kernel grouping), planned one contiguous memory layout, and emitted a single generated C file plus an OpenMP thread-pool runtime. Each phase had a named script and a named artifact, which made the pipeline debuggable stage by stage.
Template to graph flow (was templates/PIPELINE.md, templates/README.md)
Templates defined the per-layer operation sequence — the logical graph — independently of any concrete weights. The three-stage pipeline (template → GraphIR → LoweredIR) resolved template ops against the parsed GGUF/sidecar metadata, so one template could serve several weight variants of the same architecture family.
IR1 architecture (was scripts/IR1_ARCHITECTURE.md)
IR1 was a direct template-to-kernel mapping produced by build_ir_v6_6.py: no general graph optimizer, just a deterministic walk from template ops to kernel IDs with typed tensor slots. The deliberate simplicity made generated behavior auditable — a principle v8 keeps, with circuits and kernel maps replacing templates and op builders.
Memory planning and formats
Single contiguous allocation (was MEMORY_PLANNING_SPEC.md)
All runtime buffers came from one dynamically generated arena: tensor lifetimes were computed from the IR, offsets assigned with cache alignment, and the generated C addressed everything as base-plus-offset. The spec covered section ordering, alignment rules, lifetime reuse, and canary placement. This is the direct ancestor of v8's memory planner.
BUMPWGT5 (was docs/BUMPWGT5_SPEC.md)
BUMPWGT5 kept the BUMPWGT4 payload layout intact and appended a self-describing metadata block at EOF, located via a fixed-size footer — so older readers could still consume the payload while newer tooling read full tensor metadata. v8's weights.bump plus sidecar manifest carries the same idea forward.
The .ck container draft (was src/ck_format.md)
A draft single-file container (v0) for weights, tokenizer data, alignment, and metadata. It was never the production format — weights.bump + sidecar won on simplicity — but its self-description goals survived in the BUMPWGT5 footer and the v8 manifest.
Logits buffer management (was docs/IR_LOGITS_BUFFER_PROPOSAL.md)
A proposal to move logits-buffer decisions out of runtime codegen logic and into the IR, so buffer shape and lifetime were planned artifacts rather than emitted conditionals. Superseded by v8's planner-owned buffers.
Kernels and op builders
Three-level kernel mapping (was scripts/KERNEL_MAPPING.md)
Level 1: template ops (architecture-level names). Level 2: kernel ops (operation families with contracts). Level 3: concrete kernel functions (quantization- and ISA-specific implementations). Selection walked the levels with explicit conditions — the conceptual seed of v8's provider-selection metadata, equivalence groups, and fail-closed resolution.
Kernel maps as single source of truth (was kernel_maps/README.md, legacy_kernel_maps/README.md)
Each kernel-map JSON described one concrete kernel variant: shapes, dtypes, quantization layout, and entry symbol. The archived kernel_maps/ and legacy_kernel_maps/ directories remain under version/legacy/v6.6/ as data; the v8 registry and hardened map format are the live descendants.
Auto-generated op builders (was scripts/OP_BUILDER_DESIGN.md, scripts/README_OP_BUILDERS.md)
Op builders — the glue that turned IR ops into concrete kernel calls — were generated from the kernel registry instead of hand-written, eliminating a whole class of drift between registry metadata and emitted calls. v8's map-owned call ABI is the hardened form of the same requirement.
Kernel development workflow (was docs/KERNEL_DEV_WORKFLOW.md)
Write the scalar kernel, register its map, regenerate specs, add a ctypes parity test against PyTorch, then optimize with profiling. The modern, fuller version of this loop is the model bring-up guide.
Testing, parity, and profiling
llama.cpp parity debugging (was testing/TESTING.md)
Layer-by-layer comparison harness against llama.cpp to catch model-compatibility issues: capture both runtimes' intermediates, walk layers in order, and stop at the first divergence. The five-minute corpus runs and exact-trajectory gates in current CI descend from this harness.
Parity CI system (was tools/PARITY_README.md)
The automated layer-comparison CI that ran those llama.cpp diffs per model and reported first-divergence artifacts — the direct ancestor of today's nightly numerical contracts and X-Ray boundary comparisons.
Manual E2E reference (was E2E_HELP.md)
A short operator reference for manual end-to-end checks on v6.6 Gemma/Qwen models with the pinned Hugging Face URLs of the time. Superseded by the v8 runbook.
Profiling notes (was src/profiling.md)
oneAPI/VTune environment setup and perf workflows used during v6.6 optimization. Current guidance lives in Profiling and v7 Profiling.
Historical v1–v5 lineage (was src/v6.6_pipeline.md)
A narrative of the early generations: v1 established kernel-level PyTorch parity for inference and backprop; later versions added IR, quantized dispatch, and the template machinery that v6.6 finalized. Kept for historical context only.
Where to go instead
- v8 runbook — current inference commands for every supported model family.
- Model bring-up guide — the current contributor path from math to standalone C.
- IR pipeline (v6.6, legacy) — the original v6.6 pipeline page, retained and marked legacy.
- Version history — how v6.6 relates to v7 and v8.