What an Instruction Set Transition Costs an Entire Ecosystem at Once
Most of the costs in this series are paid quietly, a little at a time, by people who have stopped noticing. An architecture transition is the same cost arriving all at once and in public: every compiled artifact in an ecosystem is invalidated on the same day, and the industry gets to watch itself pay. It has just finished doing this and is being asked to begin again.
Paper 6 examined the accelerator, where a compiled artifact is worthless on the wrong hardware and the industry responded by deferring the final compile into the vendor's driver. This paper takes the processor itself, where the same commitment produces a failure that is harder to ignore because it happens to everyone simultaneously. When an ecosystem moves from one instruction set architecture to another, every artifact ever compiled for the old one stops being usable on the same day, and there are exactly three things that can happen to each of them: it is rebuilt, it is translated, or it is abandoned. All three are costs, all three are paid by somebody, and all three exist only because the instructions were decided in advance.
The industry has recently completed a large migration of this kind across desktops and servers, and is now being asked to consider another. The most revealing artifact of that experience is the translation layer: an entire category of sophisticated software whose purpose is to execute instructions compiled for a processor that is not present. It is the clearest statement of this series' thesis that anyone has built at scale, and it was built by people who had no choice, because the alternative was abandoning software nobody could rebuild. This paper also argues that the next architecture makes precompilation harder rather than easier, because a modular and extensible instruction set is not one target but a family of them, and a build matrix that must enumerate feature combinations grows faster than one that enumerates processors. The paper's own position is stated as narrowly as the others: x86-64 is what generates today, and the remaining architectures are roadmap rather than delivered.
The fixed commitment usually costs money the way a slow leak does. A support matrix is capped by budget. A container carries a userland nobody looks at. A program written to a conformance floor leaves capability unused on hardware somebody paid for. None of these produce an invoice, which is why they persist.
An architecture transition produces an invoice. On one side of it, an ecosystem's entire accumulated body of compiled software is fit for the machines people own. On the other side, none of it is. Not degraded, not slower: not executable. Every vendor in that ecosystem discovers on the same day that the artifacts they shipped encode a decision about a processor family their customers are leaving, and that the decision cannot be revised because the artifact is the only place it exists.
What makes this worth a paper rather than a complaint is that it is not rare and it is not over. The industry has recently moved substantial parts of the desktop and server world from one architecture family to another, at enormous aggregate cost, and the experience is fresh enough that most engineers reading this participated in it. It is now being asked to consider doing it again for a third architecture, and the arguments in favor are good ones. The question this paper asks is why the transition costs what it does, and the answer is not that processors differ.
Every compiled artifact facing a transition takes one of three routes, and it is worth pricing each of them honestly.
Someone still has the source, the toolchain, and the ability to test on the new hardware, so the artifact is compiled again. This is the good outcome.
Cost: paid per package, across an entire ecosystem, simultaneously. Multiplied by re-tuning and re-testing wherever performance mattered, which is wherever anyone cared.
The artifact cannot be rebuilt, so the platform runs it anyway, converting instructions for the absent processor into instructions for the present one.
Cost: a performance penalty on every execution forever, edge cases that surface for years, and a translation layer the platform must now maintain permanently: new compatibility debt created at the moment of the transition.
Nobody has the source, or nobody will fund the work, or the vendor no longer exists. The software does not make the crossing.
Cost: borne entirely by users, invisible in any vendor's accounting, and largest for exactly the long-tail and specialist software that had the fewest people able to rescue it.
Notice what determines which route an artifact takes. It is not how good the software is or how much anyone depends on it. It is whether a party with the source, the budget and the hardware still exists. Paper 3 described an enterprise bound to a compiled artifact whose requirements exist nowhere but inside the binary; a transition is the moment that entire category of software is asked to move, and much of it cannot.
Of the three outcomes, the middle one deserves attention out of proportion to its share, because of what it says about the premise.
A translation layer is software whose entire purpose is to execute instructions compiled for a machine that is not there. Building one well is genuinely difficult engineering (the ones shipped in recent transitions are impressive pieces of work by any standard), and the reason to build one is that the alternative is stranding software nobody can rebuild. It is the correct decision. It is also an industry, at considerable expense, constructing an apparatus whose function is to make a wrong prediction work.
Read against the rest of this series, that is not an embarrassment. It is the strongest available evidence that the prediction was the problem. Nobody would build a translation layer if the artifact had described what the work was for rather than how one particular processor should carry it out. The layer exists precisely because the artifact encodes the how, the how is now wrong, and the what was never written down anywhere that survives.
An open, royalty-free instruction set architecture is a good idea for reasons that have nothing to do with this series, and its momentum is not in question. It is worth noticing what it does to precompilation.
The architecture is modular by design. A base integer instruction set is extended by optional standard extensions, and implementers are free to combine them according to what they are building, which is the entire point: a microcontroller and a server part should not be forced to carry each other's requirements. The consequence for anyone shipping compiled artifacts is that the target is not one processor family but a space of feature combinations. Profiles exist to define common bundles and they help, and the space remains larger and more open-ended than a conventional architecture's, because openness is the design goal rather than a side effect.
A build matrix that must enumerate architectures grows linearly with architectures. A build matrix that must enumerate combinations of optional features grows considerably faster, and the usual response is to target a conservative baseline, which brings back Paper 5's problem exactly: an artifact built for the least capable configuration cannot use anything better, and the whole reason to select particular extensions was to get something better. The industry's freedom to compose the processor becomes, at the moment of compilation, a reason to ignore what was composed.
This is the point at which resolution stops being an alternative and starts being the obvious answer. A system that inspects the processor at execution reads which extensions are present the same way it reads anything else about the machine, and generates accordingly. The modularity that makes precompilation harder makes resolution more valuable, for the same reason and by the same mechanism.
The structural claim of this paper is short. If nothing was compiled for the old architecture, nothing is invalidated by leaving it. Work expressed as declared intent contains no processor's instructions, so a new architecture is a backend added once, centrally, by the party that owns the resolver, not an ecosystem-wide rebuild in which every vendor pays separately and the software with nobody left to pay for it dies.
The three outcomes in Section 02 do not become cheaper under this model. They stop applying. There is no artifact to rebuild, nothing to translate, and nothing to abandon, because the decision that those outcomes are all trying to rescue was never made.
x86-64 is what generates today. Intel-specific targets, ARM and RISC-V are on the roadmap and are not delivered, and this paper makes no claim about when they will be. That is a smaller claim than the argument above might suggest, and the gap between the two is the honest state of the work: the architecture makes a transition into a backend problem, and this platform has one backend.
Only x86-64 generates today. Intel-specific targets, ARM and RISC-V are roadmap items with no date attached. The argument in Section 05 describes what the architecture makes possible, not what has been delivered, and the two should not be read together.
No measurement on any non-x86 processor. Nothing in this series has been measured on ARM or RISC-V hardware, and the acceleration and energy figures cited elsewhere were obtained under stated conditions on other substrates.
Translation layers are not being criticized. Section 03 describes them as impressive work and as the correct response to an impossible position. The argument concerns why the position existed, not how it was handled.
The RISC-V description is architectural, not predictive. Section 04 describes modularity and profiles as design properties. It makes no forecast about adoption, market share or timelines, and profile standardization is active work whose current state should be checked directly.
A backend is real engineering. "A transition is a backend" is a claim about where the cost lands and how many times it is paid, not a claim that the cost is small. Generating for an instruction set requires knowing it thoroughly, and that work has not been done here for the architectures listed as roadmap.
The second movement closes here. Papers VI and VII took the two layers where the commitment is most literal (the accelerator's instruction set and the processor's) and found the same structure in both: a decision made in advance, an artifact that cannot say what it meant, and an industry building machinery to cope with the consequences.
The third movement changes the subject from the machine to the machines you do not own. Paper 8 takes the rented instance, where choosing a shape in advance is not only a compilation decision but a purchasing one, and where the gap between the prediction and the need is billed by the hour.
When an ecosystem changes instruction set architecture, nothing compiled for the old one survives the crossing on its own. What happens to each artifact is decided not by how good it is but by whether anyone with the source and the budget is still around, and the software with nobody left to pay for it simply stops. The translation layers built to soften that are excellent engineering aimed at a problem that only exists because the artifact recorded how rather than what. And the architecture the industry is moving toward next is modular by design, which makes the space of things to precompile for larger rather than smaller. x86-64 is what generates here today; the rest is roadmap, and this paper says so rather than implying otherwise.
The Common Substrate → Request Platform Access