A Program Is Not The Machine While It Runs
Forget computer programs for a minute and look one level closer to the atoms. A powered circuit can be present and ready without performing the operation we care about. The structure exists. Computation happens when signals and stored state change through that structure.
Code is data with an unusual job. It is a symbolic plan that an interpreter, compiler, processor, or configuration mechanism uses to select, schedule, or construct behavior from available resources. Calling it a blueprint is imperfect but useful: the drawing of a car is not the car, and a function sitting in storage is not the event of executing it.
A programming language is therefore a symbolic tool for the brain. It lets us fix logic, mathematics, facts, rules, behaviors, simulations, and estimates in an executable form instead of carrying every step in memory. It is an external memory that can be tested. It gives us a canvas where knowledge can run and contradict us.
The canvas still needs a machine. A source file may describe millions of possible executions, but an actual execution occupies devices, memory, wires, time, energy, and communication paths. The description and its realization must meet somewhere.
The Small Act: Controlled Selection And Propagation
At the elementary digital level, one useful act is controlled selection:
d = a ? b : c;The control a does not become the result. It chooses whether b or c can influence d. In hardware this is a 2:1 multiplexer. Trees of such choices, supplied with constants and input signals, can realize any combinational Boolean function.
Selection is not the whole physical story. An output must settle. Charge and electromagnetic state change in transistors and interconnect. Loads must be driven. Noise margins, delay, fan-out, and energy matter. Computation is not a switch symbol on paper; it is the controlled propagation that the built circuit makes possible.
Everything in the world can carry information for an observer. Far fewer things can serve as reliable automatic switches. Automation begins when a physical system repeatedly recognizes a condition and changes a path or state without someone manually reconnecting it each time.
This does not require the switch itself to be an agent. Agency supplies or adopts goals. Control is the mechanism that helps pursue them. Keeping those ideas separate prevents a useful automatic mechanism from being mistaken for a mind.
There Is No Abstract Append In Physical Memory
Programming languages let us write list.push(x) as though a new place appears at the end of a list. Physical memory does something less magical. The runtime uses capacity that was reserved earlier, or it finds another finite region, transfers ownership, copies what must survive, updates references, and releases the old region when it is safe.
The abstraction is valuable. The resources beneath it do not stop having location. Allocation always means that some bounded storage and some path to it become responsible for new state.
A tree offers a wonderfully literal example. Carbon from the air becomes part of a leaf only where the tree can build that leaf. If no suitable spatial region exists, the leaf does not grow there. Matter, energy, transport, and structure meet in one place. A computer's parts are different, but they inherit the same refusal of physical reality to append into nowhere.
This is not an argument against abstraction. It is an argument for knowing which promise an abstraction makes about the resources beneath it.
Three Views Of A Computation
A system becomes much easier to reason about when its description answers three different questions.
Many diagrams accidentally mix all three. A box may mean a physical device, a software instance, a function that could be called, or one invocation currently in flight. An arrow may mean a permanent wire, a possible call, a message already sent, or permission to communicate. The diagram looks complete while the machine remains ambiguous.
The remedy is not more boxes. It is deciding which of the three questions the diagram answers.
Physical Structure Sets The Operating Envelope
A physical computation occupies a finite volume for a finite time. Within that envelope, devices need space, signals need time to propagate and settle, stored state needs a physical medium, and heat must leave. Packaging, power delivery, cooling, repair, and fabrication yield can limit a system before the Boolean expression does.
Two constraints recur at almost every scale:
- Switching and propagation time: how quickly a device and its interconnect can produce a usable next state under the required voltage, load, process, and temperature.
- Communication capacity across boundaries: how much information can cross a package edge, board connector, rack network, clock-domain boundary, memory interface, or other physical boundary within the required time and energy.
There is no single universal clock limit, and bandwidth is not determined by surface area alone. Technology, encoding, geometry, signal integrity, cooling, and topology all participate. The enduring point is that useful work inside a region must be fed, synchronized, observed, and sometimes repaired through finite interfaces.
A small chip can use dense metal interconnect that cannot simply continue through an arbitrarily large three-dimensional computer. Stacked devices accumulate thermal and mechanical problems. Buried components become difficult to test and replace. A data center has aisles, power conversion, cables, switches, cooling equipment, and people because a computer at that scale is also a building.
From those facts we can derive a useful architectural sketch: available switching and storage inside each region, plus the latency and throughput of the boundaries joining regions. That sketch is more honest than counting operations while treating movement as free.
Logical Structure Gives The Parts Meaning
Physical structure tells us what exists. Logical structure tells us which role each available resource is serving.
On a processor, machine instructions select behavior from an already built collection of registers, decoders, arithmetic units, caches, and interconnect. A compiled function is logical structure distributed over those physical resources and over time. On a specialized accelerator, the logical and physical shapes may match more closely because a datapath is built for a narrower role.
Hierarchy makes either case manageable. A subsystem exposes a boundary, accepts inputs, produces outputs, and hides internal decisions that its neighbors do not need to know. A larger component can then connect several such subsystems without reproducing their interiors.
Sensors and actuators complicate the medium but not the need for a boundary. A camera converts light into electrical state. A radio crosses between electromagnetic fields and samples. A network stack turns timed electrical or optical changes into frames and messages. Digital systems can encode these exchanges as bit streams; the physical world itself does not become nothing but bits.
Data And Control Share The Channel
Hardware designers often distinguish data from control. Data carries the values being transformed. Control says when a value is valid, where it should go, whether a buffer can accept it, which operation applies, or when a transaction begins and ends.
The distinction is a role, not a different substance. The same wire, packet field, or stored bit can be data at one boundary and control at another. Some protocols put control on separate signals. Others encode it beside payloads or infer it from timing.
Together, data and control make communication unfold over time. An interface is not only a list of types; it is a protocol describing which changes are meaningful, in what order, and under whose clock or handshake. Connecting two subsystems therefore means more than drawing an arrow. Their assumptions about validity, capacity, ordering, backpressure, reset, and failure have to meet.
This is one reason distributed systems do not deserve to be treated as an exotic branch of computation. Once a design crosses an independent clock, process, device, or administrative boundary, communication becomes part of the computation's structure.
Runtime State Is The Computation In Flight
Structure alone describes possibilities. Runtime state tells us which possibility is active now.
In a combinational network, current inputs and intermediate electrical states determine the settling output. Add latches, flip-flops, SRAM, or other storage and the network can retain consequences of earlier events. Feedback through storage creates sequential behavior: counters, protocols, state machines, pipelines, and processors.
A useful hardware graph therefore contains selection, logic, routes, and places where a past value is deliberately retained. Multiplexer networks can express Boolean choice. Storage separates one step from the next. Clocks or event handshakes decide when a retained value becomes the new visible state.
Pipelining is not merely a performance trick. It assigns state to intermediate positions so several inputs can occupy different stages of the same structure at once. Memory holds values that cannot or need not remain beside every operation. A constant wired into the circuit is structure; a constant held in configuration storage or memory is long-lived state. The placement is an architectural choice.
Large systems often contain locally synchronous regions joined asynchronously or through explicit clock-domain crossings. The broad GALS idea—globally asynchronous, locally synchronous—is useful because it admits that one universal clock is neither necessary nor always practical. The boundary protocol, not wishful timing, carries state safely between regions.
Structural Change Is The Fun Part
Now ask a different question: who can change the graph?
Ordinary software creates objects, processes, queues, files, and virtual connections. Physically, a CPU or GPU remains mostly the same circuit while instructions schedule and select its resources over time. The program changes logical ownership and state far more often than it changes the silicon topology.
An FPGA exposes another layer. Configuration bits select lookup-table contents, routing paths, I/O behavior, and other resources inside a fixed physical fabric. Loading a bitstream changes the logical circuit realized by that fabric. Devices that support partial reconfiguration can replace a bounded region while other regions continue to operate, subject to strict interface and timing rules.
People and robots can change physical structure more literally: plug in another board, replace a failed module, move a cable, assemble a new machine, or add a rack. Migration changes both structure and runtime state when a live service must carry its history into a new home.
These operations all deserve explicit language. “Create” must eventually mean which existing resources become owned by the new instance. “Connect” must name a path and protocol. “Move” must say how state survives. “Replace” must define the boundary that remains stable while the interior changes.
Temporal reuse and spatial construction are two ends of a design choice. A processor can reuse one arithmetic unit across many instructions. A parallel circuit can place several units side by side. Vectorization, threading, pipelining, and hardware generation decide where work unfolds in time and where it unfolds in space.
Identity And Ownership Make Hierarchy Real
A type, class, template, or hardware module describes a possible structure. An instance has identity. Even when the instance is virtual rather than a dedicated patch of silicon, the running system must retain enough state to say which instance owns which memory, waits on which messages, and may change which resources.
Hierarchy is not indentation. A parent boundary allocates a region or set of resources, gives a child a controlled interface, and retains a way to replace or release it. That is the connection to my work on homogeneous reconfigurable fabrics: if local cells can become routes, selectors, constants, state, or configuration ports, then grouping and ownership become operations in the fabric itself.
The claim is not that every software object should become hardware. The useful claim is that construction, identity, state, communication, and replacement have physical consequences even when a language hides them.
A Reading Method For Real Systems
When I meet an unfamiliar system, I now ask three passes of questions.
- Structure: What has been built? Where are the boundaries? Which paths and operations exist?
- State: What is present now? Where can it wait? Which history must survive the next event?
- Structural change: What can be created, reconnected, resized, upgraded, migrated, or destroyed, and who has authority to do it?
The same questions can illuminate a circuit, a software service, a data center, or even an organization, but the analogy must not erase their different physics and incentives. In each case the questions force vague architecture words back toward mechanisms that can be inspected.
That is the general architecture I was looking for: not one diagram that declares everything connected, but a disciplined account of what exists, what is happening inside it, and what can change its shape.