# Beyond Assembly: a Silicon Compiler The evolution from instruction-based emulation to direct hardware configuration Author Affiliation SSCCS Foundation [](mailto:contact@ssccs.org) [SSCCS Foundation](https://ssccs.org) Published June 26, 2026 Abstract Current SSCCS prototyping relies on a RISC‑V assembly layer to emulate observation‑driven computation on von Neumann hardware. This document examines the longer‑term trajectory: the assembly layer is a temporary necessity. As the paradigm matures, it points toward a new class of hardware‑description language, a Field Placement Description Language (FPDL), that compiles structural constraints directly into silicon topology. In the limit, the program itself becomes a self‑modifying stream, and the boundary between software and hardware dissolves. Other Formats [LLMs](https://docs.ssccs.org/direction/sc.llms.md) ## Where We Stand The SSCCS compilation pipeline today converts a high‑level `.ss` definition (the Scheme‑Segment source format) into RISC‑V assembly, which then produces Structurally Signed Code. This path is a concession to the available hardware: every constraint check and observation must be expressed as a sequence of general‑purpose instructions. The assembly layer is an emulation scaffold, not an architectural requirement. ## Why Assembly Is a Temporary Stage Traditional assembly languages encode a model of computation built on sequential instruction execution, mutable registers, and explicit data movement. SSCCS rejects that model at its foundation. Its primitives are not instructions but constraints, segments, schemes, and observations. Retaining an instruction‑based intermediate representation creates a translation gap that compilers must bridge with heuristics. As long as that gap exists, the full potential of structural observation remains unrealized. ## Field Placement Description Language When SSCCS targets native hardware, the intermediate layer will shift from instruction encoding to spatial configuration. A Field Placement Description Language (FPDL) describes which constraints occupy which regions of an observation fabric, how they interconnect, and how the fabric’s topology reflects the scheme’s adjacency rules. FPDL is not an assembler. It is a placement language that feeds a silicon compiler, which translates structural constraints directly into hardware netlists or FPGA bitstreams. The conceptual framework beneath FPDL treats Fact, Intent, and Hint as orthogonal axes in a three‑dimensional coordinate system, not merely as a classification scheme. Every placement in the observation fabric is a geometric configuration in this FIH space: a Fact occupies a coordinate along one axis, an Intent projects along another, and Hints modulate the constraint topology between them. FPDL descriptions are therefore spatial declarations of where each structural element sits in this volume and how signals propagate along the axes. This geometry is what distinguishes FPDL from traditional high‑level synthesis: HLS schedules operations in time; FPDL places constraints in space. ![](sc_files/figure-html/fig-evolution-output-1.svg) Figure 1: The compilation pipeline evolves from assembly emulation to direct silicon configuration The translation from FPDL to hardware is deterministic. A constraint such as an even‑check on a 64‑bit coordinate becomes a combinatorial logic gate, not a sequence of three instructions. The observation operator becomes a signal path, not a function call. The scheme’s immutable segments become physical memory banks with cryptographic identifiers wired into the fabric. ## The Silicon Compiler A silicon compiler for SSCCS accepts a scheme description and a set of field constraints, then produces a hardware configuration that instantiates the observation fabric. Its tasks include: - Partitioning segments across physical memory blocks. - Routing constraint signals so that all relevant checks complete within a single observation cycle. - Generating the minimal set of projection paths required by the field definitions. - Embedding cryptographic identifiers directly into the hardware so that every observation carries an auditable provenance. This compiler operates on a different principle from traditional high‑level synthesis tools. It does not schedule operations or allocate registers. It resolves spatial adjacency and connectivity. The resulting hardware contains no program counter, no instruction fetch unit, and no data cache in the conventional sense. It is a static fabric that responds to field updates with deterministic projections. The distinction runs deeper than the absence of a von Neumann control path. Processing‑in‑memory architectures reduce data movement distance by placing compute near storage. SSCCS eliminates data movement as a concept: data remains stationary at its scheme coordinate, and computation is the resolution of constraints across the topology. The resulting hardware is a constraint‑resolution fabric, not a sequential processor. The hardware targets for FPDL already exist in mature open‑source form. The silicon compiler toolchain (SiliconCompiler, Yosys, OpenROAD) and hardware description frameworks (Chisel, CIRCT, Amaranth HDL) provide the synthesis and place‑and‑route infrastructure needed to translate FPDL spatial declarations into physical netlists and bitstreams. ![](sc_files/figure-html/fig-silicon-compilation-output-1.svg) Figure 2: Low‑level compilation of observation and field connections into hardware topology. Scheme defines the structural substrate; Field owns constraints and observation specifications. ## Self‑Adaptive Systems The state that separates current thinking from the ultimate trajectory of structural observation is this: once the observation fabric exists, the field itself can be updated by observation results. A projection becomes a new constraint. The boundary between input stream and program dissolves. ![](sc_files/figure-html/fig-adaptive-output-1.svg) Figure 3: Self‑adaptive observation loop: the program evolves with every observation In this regime, a robotic system does not run a fixed control program. It continuously recomposes its own constraints based on what it observes. Each Observation produces a Projection, and the Projection may recompose the Field’s own constraint set, altering which observations fire next. This recursive loop (Field → Observation → Projection → new Field constraint) means the FPDL description evolves at runtime; the silicon compiler must either pre‑synthesize the reachable constraint topologies or support partial reconfiguration. The hardware remains structurally verifiable because every field update is a composition of known constraints on an immutable scheme. The system adapts, but the path of its adaptation remains auditable back to the primordial field definition. The structural observation model thus provides a framework where adaptation and verifiability coexist. Statistical learning systems sacrifice auditability for flexibility. Fixed logic sacrifices flexibility for auditability. SSCCS, by making constraint composition the primitive act of computation, aims to collapse that trade‑off. ## Summary The RISC‑V assembly layer is a scaffolding that will be dismantled when native observation fabrics become available. The replacement is a Field Placement Description Language that feeds a silicon compiler. That compiler produces hardware where computation is not a sequence of instructions but a spatial resolution of constraints. In the furthest horizon, the program is no longer a static artifact. It is a stream that rewrites the hardware’s own field with every observation, while the scheme guarantees that every such rewrite is structurally sound. ## Research Agenda The following architectural problems must be resolved before the silicon compiler can progress beyond a thought experiment. Each represents a prerequisite for any concrete FPDL design or hardware prototype. **Representation boundary** — Is FPDL a separate language from `.ss`, or an extension of `.ss` with physical placement annotations? A separate language preserves `.ss` purity but introduces a cross-language consistency burden. An extension avoids that but risks making the source format hardware-dependent. **Constraint and observation ownership** — Do constraints and observation specifications belong exclusively to the Field, with the Scheme providing only the structural substrate? Current draft diagrams reflect an emerging consensus toward Field ownership, but the exact boundary between Scheme-provided observation rules and Field-specified observation triggers is unsettled. **Mapping formalism** — The silicon compiler’s core transformation (scheme topology → spatial partition) has no established formalism. It resembles graph partitioning with wire-length minimization rather than traditional instruction scheduling, but whether this analogy holds under the constraint-composition model is unverified. **Hardware interface** — How does the compiled observation fabric interface with physical memory controllers, clock domains, and I/O? The claim of no program counter and no instruction fetch unit implies a radically different control path that has no reference implementation. **Self-adaptive reconfiguration** — When a field update rewrites constraints at runtime, does the fabric require partial reconfiguration (FPGA-style), or are all possible constraint topologies pre-synthesized and selected via multiplexing? **Cryptographic embedding** — Hardware-level provenance identifiers imply a root of trust embedded in the silicon. The relationship between scheme-level identity (SchemaId, SegmentId) and hardware-anchored identity has not been specified. These are not peripheral concerns. They determine whether the silicon compiler is an incremental improvement over existing HLS tools or a genuinely new compilation paradigm. Until at least the representation boundary and mapping formalism are experimentally explored, FPDL remains a direction rather than a design.