CBE: Contract-Based Execution Architecture

An architecture for extracting maximum utility from existing physical capital through strict execution invariants.

Over the last couple of weeks—while taking a break from geopolitics—I’ve been working on a specification and implementation of an alternative computing paradigm in accordance with my SETE work. The path we walk is contingent—not inevitable—but from the path, this isn’t always visible, and if you walk it long enough you no longer possess the resources needed to plot a new trajectory.

To test if escaping this path dependence is actually possible, I have built a controlled counterfactual: a fully functional Linux kernel patch and an integrated -mcontract=scalar execution invariant for GCC and Binutils. I intend to compile a full Gentoo user space.

However, I want to be careful not to invite overly broad conclusions. It is a fascinating experiment to attempt a structural pivot within computer architecture precisely because it is a relatively tiny, strictly bounded subset of our broader civilisational predicament. Is it possible to pull off a fundamental change of trajectory within this specific domain? Perhaps. But civilisation itself is vastly more complex, and I suspect we are already well past the point of no return on the macro scale.

Still, the micro-experiment is worth running. Here is the architecture.
Update: I forgot add; initial testing with the kernel patch shows a minimum 20% reduction in context switch overhead.

1. The Core Thesis: Invariant over Inference

Modern computing architectures operate on an implicit capability model: a process potentially owns every hardware feature, and the kernel must dynamically discover its usage.

The central proposition of CBE is that an execution context should declare the physical state it is permitted to possess, and the OS/hardware interface should exploit that contract rather than dynamically infer state requirements.

The XSAVE Boundary

Historically, architectures have relied on dynamic state discovery to manage heterogeneous execution state (SIMD, AMX). Hardware mechanisms like XSAVE are sophisticated optimisations that make implicit heterogeneous state affordable.

However, XSAVE cannot eliminate the physical cost of maintaining the possibility of that state. Dynamic state discovery is fundamentally inferior to an architectural invariant when that invariant can be established ahead of execution. CBE provides an execution class where the absence of data-plane state is an architectural guarantee.

2. Formal Definition of the Contract

The foundational execution contract is CBE-SCALAR. It distinguishes strictly between what the contract guarantees and what the implementation may optimise.

CBE-SCALAR Architectural Guarantees:

1. No architectural Floating-Point (FP) state.

2. No SIMD/vector state.

3. No hardware-crypto execution state.

4. Floating-point values are represented and passed strictly through the scalar ABI.

5. Data-plane operations occur through asynchronous submission.

6. Contract violation is a defined execution fault.

Because of this architectural property, the OS may completely omit all prohibited state from its context management. (”The kernel does not save XMM state” is the implementation detail; “The execution context cannot contain XMM state” is the architectural invariant that enables it.)

Compiler Identity

The GCC backend enforces this via -mcontract=scalar. To provide maximum flexibility without polluting the environment, the compiler exposes two distinct identifiers:

• __cbe__: Informs the codebase that it is running under a Contract-Based Execution paradigm (useful for generic headers mapping math to the ACVM).

• __x86c__: Informs the codebase of the specific base ISA (useful for low-level scalar inline assembly like memory fences or locks).

Legacy monolithic assumptions (like __x86_64__) are explicitly undefined.

Orthogonality of Address Models

CBE separates the execution contract from the memory address model. Cache density optimisations (like 32-bit pointers on a 64-bit ALU) are valuable but orthogonal to the core CBE thesis.

                 CBE
                  │
        ┌─────────┴─────────┐
        │                   │
   execution contract    address model
        │                   │
      scalar                x32

A system can implement contract-scalar under standard LP64 or contract-scalar-x32, allowing the cache-density effects to be measured independently.

3. ACVM: The Accelerator Command ABI

By forbidding inline data-plane state in the CBE-SCALAR context, the architecture inherently separates the control plane from the data plane. SIMD is no longer treated as a property of the control-flow execution context.

To achieve this, CBE utilises the ACVM (Asynchronous Compute Virtual Machine).

The ACVM is not a strict virtual machine promising to interpret generic mathematical instructions forever; rather, it is an accelerator command ABI. The control plane submits semantic operations, and the kernel’s data plane is responsible for translating them into the appropriate accelerator execution (SSE, AVX, AMX, GPU, x87).

The Opcode Namespace

The binary protocol relies on a 16-bit opcode space that adopts an extension-class model analogous to RISC-V’s extensible ISA philosophy:

• Class V - Vector Operations

• Class M - Matrix / Tensor Operations

• Class K - Cryptographic Operations

• Class X - Extended Precision (x87)

Capability-Oriented Cryptography (Class K)

The ACVM provides a capability-oriented data-plane interface. CBE can expose cryptographic operations without ever transferring key material into the scalar execution domain.

scalar process
     │
     │ key handle (via ACVM SQE)
     ▼
kernel key infrastructure
     │
     ▼
ACVM crypto engine

A scalar process passes a key handle in its submission queue entry, allowing secure, asynchronous, hardware-accelerated encryption without possessing the secret material in user-space memory.