Open Formats into Machine Code

Center Document for the Open Format PoC Track

Author
Affiliation

SSCCS Foundation

SSCCS Foundation

Published

August 6, 2026

Abstract

This document is the center of the open format poc track. The .ss open format is the notation of the pure SSCCS plane: a declarative description of computational geometry, containing no registers, clocks, or memory layout. Baking that structure into native machine code is the virtual materialization of the pure plane onto existing computing. The user writes a document; the engine turns it into circuitry.

Role of This Document

This document governs the open format poc track. It holds the pure .ss philosophy and its virtual materialization into machine code, and it is the reference that the poc parser, the compiler pipeline, and the format specification work against. The semantic definition of the format lives in the whitepaper appendix on the open format; this document carries the materialization thesis: structure is read once and baked, never interpreted at runtime.

Core Philosophy

SSCCS moves beyond runtime interpretation. Instead of parsing open-format documents at runtime, storing data in HashMaps, performing dynamic lookups, and paying heap allocation and locking costs, SSCCS reads structured open-format definitions and bakes them directly into native machine code at compile time.

Rust is not used merely as a programming language; it acts as a projection lens that transforms schema into optimized hardware-level execution.

The open format belongs to the pure plane: it describes topology only, with no memory layout and no instruction flow, because the same topology compiles to RTL, FPGA bitstream, CPU loop, or formal model without rewriting. Baking into machine code is the virtual materialization of that topology onto existing computing, so the philosophy becomes practically usable immediately.

Architectural Shift

Traditional Runtime Model

The von Neumann baseline interprets documents at runtime:

  • Data loaded into heap structures
  • HashMap lookups
  • Dynamic dispatch
  • Runtime validation
  • Memory contention and locking

SSCCS Compile-Time Model

The virtual materialization reverses the baseline:

  • Open format parsed at compile time
  • Segments converted into const
  • Projectors converted into fully inlined functions
  • LLVM performs constant folding
  • Runtime overhead: effectively zero

Prototype: Declarative Macro-Based Compiler

In production, build.rs or procedural macros (proc_macro) would parse external .ss files. For conceptual clarity, the current proof-of-concept simulates the entire materialization pipeline using declarative macros. The .ss blueprints are written as Rust macros; external .ss file parsing is the next target of the open format poc track.

// Compiler engine that parses open format (.ss) and converts it into code
macro_rules! ssccs_compile {
    (
        // Read 'segment' definition block from .ss file
        segments {
            $( $id:ident : $val:expr ; )*
        }
        // Read the 'projector' definition block from the .ss file
        projectors {
            $( $proj_id:ident = observe( $op:tt , $seg_a:ident, $seg_b:ident ) ; )*
        }
    ) => {
        // [Materialization result 1] Segments are baked as immutable constants
        // (const) without memory allocation. This is a complete zero-copy, as if
        // the data is imprinted at the hardware level.
        $(
            const $id: i32 = $val;
        )*

        // [Materialization result 2] Projectors are baked as inline functions
        // without runtime interpretation. Without HashMap lookups or type
        // checks, the CPU is left with only the operations to execute
        // immediately.
        $(
            #[inline(always)]
            pub fn $proj_id() -> i32 {
                // Create a composition structure by mapping operators inside
                // the macro
                ssccs_compile!(@op $op, $seg_a, $seg_b)
            }
        )*
    };

    // Internal operator mapping engine
    (@op +, $a:ident, $b:ident) => { $a + $b };
    (@op -, $a:ident, $b:ident) => { $a - $b };
}

// ========================================================================
// SSCCS Step 2: Developer-created open format data (same as if you imported
// a .ss file)
// ========================================================================
ssccs_compile! {
    segments {
        INT_A : 1;
        INT_B : 1;
        INT_C : 10;
    }
    projectors {
        adder_ab = observe(+, INT_A, INT_B); // 1 + 1 Observer
        sub_ca   = observe(-, INT_C, INT_A); // 10 -1 Observer
    }
}

// ========================================================================
// SSCCS Step 3: Runtime
// ========================================================================
fn main() {
    // There is no hash map traversal, pointer tracking, or locking at runtime.
    // When converted to assembly language, it is completely replaced
    // (constant folding) with `let projection1 = 2;`.

    let projection1 = adder_ab();
    println!("Adder observation projection results: {}", projection1); // Output: 2

    let projection2 = sub_ca();
    println!("Sub observation projection result: {}", projection2); // Output: 9
}

Why This Is Physically Faster

Extreme Constant Folding

Because INT_A and INT_B are compile-time constants, INT_A + INT_B becomes 2 at compile time. LLVM eliminates the addition entirely. At runtime, the CPU does not compute 1 + 1; it simply operates on the literal value 2. Runtime arithmetic cost: 0.

Zero Heap, Zero Copy

There is no heap allocation, no HashMap traversal, no pointer chasing, and no dynamic resolution. Data is embedded directly into the program’s instruction stream or registers. This approaches the efficiency of processor-in-memory architectures, hardware-level circuits, or microcoded logic.

Absolute Thread Safety

All segments are immutable const. There is no mutation, no locks, no race conditions, and infinite concurrent observation safety. Even 100 million threads invoking adder_ab() will not cause contention.

Conceptual Reframing

SSCCS is not a runtime framework, a dynamic interpreter, or a configuration loader. It is a schema-to-hardware projection system. The developer writes a structured document, and the compiler transforms it into static constants, inlined logic, and hardware-optimized execution paths. The open format becomes indistinguishable from handwritten assembly in performance characteristics.

Beyond 1 + 1

The arithmetic example is trivial. But imagine embedding network routing policies, access control graphs, distributed system consensus rules, security boundary definitions, or permission projection engines, all described declaratively in an open format, then compiled into zero-overhead machine code. This is not configuration; this is compilation of structure into silicon behavior.

Role of Rust

Rust is not merely the implementation language. It acts as the compiler lens that projects open-format schemas into optimal machine instructions. It provides memory safety, deterministic compilation, LLVM-level optimization, and guaranteed zero-cost abstractions. Rust becomes the physicalization engine of SSCCS.

Final Statement

The user writes a document. The engine turns it into circuitry. SSCCS is the transition from runtime interpretation to compile-time projection to hardware-equivalent execution. The schema is no longer read. It is baked.

© 2026 SSCCS Foundation — Open-source computing systems initiative building a computing model, software compiler infrastructure, and open hardware architecture.