Chapter 3: The instruction set (ISA), an invisible contract

In the previous chapter, we saw that the kinds of "brain" exploded. From here, we descend to the deepest place in today's upheaval. The lead is something that never meets anyone's eye in daily life, yet quietly governs the world's software and hardware — the instruction set (ISA). An unfamiliar term, I'm sure. But don't worry; we'll unravel it slowly, starting from a familiar "huh?"

3.1 Why won't "the same software run on a different machine"?

Haven't you had this experience? An app for phones won't run on a PC as is. An app made for iPhone won't install on an Android phone. Insert a game-console title straight into a PC and you can't play it. — Isn't that strange? They're all "machines that compute," so why does software have a "compatibility"?

At the very back of that answer sits the ISA. In fact, a chip (CPU) can only understand a limited set of "instructions" decided in advance. And that "set of instructions it can understand" differs by chip. So software written for one chip literally "can't get through — the language doesn't work" and won't run on a different chip where the instructions don't register. This is the true nature of compatibility.

3.2 A chip understands only "the instructions it's set with"

In Chapter 1, we said a chip is a swarm of switches. What tells those switches "add now," "remember this value," "read that address over there" is an instruction. A chip is born holding "a list of the instructions it can respond to," and can execute only the instructions on that list. Hand it an instruction not on the list, and it just goes blank.

This — "the list of instructions this chip can understand, and the rules that go with it" — is called the instruction set architecture (ISA for short). Because it's long, in this corner we'll call it the ISA.

3.3 The ISA is the "shared language," and the "contract," between hardware and software

This is the most important part. The ISA is a shared agreement exchanged between hardware (the people who make chips) and software (the people who write programs). Precisely because both promise to keep to the same ISA, they mesh properly even when built separately.

To put it another way, the "language of control" at an international airport. Air traffic control worldwide makes fixed phrasings a shared agreement, so that a pilot of any nation can be understood. Because speaker and listener keep the same agreement, intent gets through without misunderstanding, even on first meeting. The ISA is the same — a shared language that reliably meshes chip and software, two "first-time strangers." That's exactly why it deserves to be called not a mere technical spec but a "contract" that everyone follows.

3.4 A little more precisely ― what do we mean by "software"?

So far we've lumped everything together as "software," but let's be precise. Software has layers. Roughly, the OS (the base software) and the apps that run on top of it. But what directly "shakes hands" with the ISA is not that category. It's a program in the state where it has finally been translated into that chip's machine language (a run of instructions in 1s and 0s). App or OS, at the moment of execution it has always been converted into that ISA's instructions. What the ISA binds is this "machine-language level."

Then what's "the relationship between the OS and the ISA"? The OS is a program too, so of course it's built to match that ISA. So if the ISA changes, the OS also needs rebuilding (or re-translating). But the OS has one more important role. The OS is also a "cushion (an interpreter)." Once the OS and the groundwork for that ISA are in place, the person writing apps can get by without being directly aware of the ISA. The raw dealings with the ISA are taken on by the OS and translation tools.

So, the true nature of "the same app." What we usually think of as "the same app" is, at distribution time, translated separately into machine language for each ISA. Take a translated one to a chip of a different ISA and it won't get through — this is the more precise picture of the "compatibility" in 3.1.

3.5 "Surely assembly is shared?" ― No, it's different per ISA

Here, let's answer a question that the sharper you are, the more it snags you. "I get that machine language differs by ISA. But surely assembly language is shared?" — No. Assembly, too, differs by ISA. The reason is simple: machine language and assembly are "the front and back of the same thing." Assembly is just the 1-and-0 instructions with short, human-readable name-tags (ADD, MOV, etc.) attached one-to-one. If the back (machine language) differs, of course the front (assembly) differs too.

So where is it "shared"? At a higher layer — high-level languages like C and Python. Humans write in a high-level language, unaware of the ISA, and a compiler (a translator) translates it separately into assembly / machine language for the intended ISA.

   Where it's "shared," and from where it's "per ISA"
 ───────────────────────────────────────────────────────────────
   Humans write: high-level language (C, Python, etc.)  ← independent of the ISA (can be shared)
        |   the compiler translates it separately per ISA
        v
   Per-ISA only: assembly / machine language            ← different per ISA (for x86, for ARM, for RISC-V...)
        v
   The chip executes                                    ← can only eat the instructions of its own ISA
 ───────────────────────────────────────────────────────────────

To put it another way, a high-level language is "a cooking recipe written in Japanese." Assembly / machine language is a set of work instructions translated into each kitchen's private jargon. Even if the recipe (high-level language) is shared, each kitchen (ISA) has different jargon, so the translated instructions get through only in that kitchen. The compiler is the translator.

So, when the ISA differs, what specifically changes? Don't overthink it; these four points are enough.

• The names and kinds of instruction (the menu). Even for the same "read from memory," x86 says MOV, ARM says LDR, RISC-V says lw. Both the naming and the lineup differ.
• The number and names of registers (the workbench at hand). Small holding spots for values, temporarily. x86 has EAX etc.; RISC-V has x0, x1…. Both the count and the naming differ.
• The shape of instructions (the style of writing). A family where "there are many kinds and one instruction is high-function" (CISC = x86), versus one where "instructions are pared down and it wins on simple numbers" (RISC = ARM, RISC-V).
• The rules for translating into 1s and 0s (encoding). Even for the same ADD, the agreement on what bit-pattern represents it is unique to each ISA.

Each shop has a different menu, a different number of prep counters, different phrasings for orders, a different slip format. So the same "order slip (assembly)" won't pass at another shop — once that settles in, you've got enough.

※ By the way, "does RISC-V's ISA have instructions for analog or sensors?" — The answer is, "that's not the ISA's area of responsibility." What the ISA looks after is only this kind of digital computation. The analog circuits, power semiconductors, and sensors touched on in Chapter 1 are not things you "drive with instructions"; they're a world outside the ISA. In an actual chip, those are attached separately (integrated alongside) around the ISA-following digital CPU.

3.6 Why does this "contract" carry such weight?

The reason the ISA is not just a piece of technical jargon lies in the strength of its binding. The world's software is written to match a particular ISA (contract). The OS (base software) and apps — that vast accumulation is stacked on top of one ISA. And so it goes: an ISA that has once spread cannot be switched away from easily.

If a new chip declares "ours is a different ISA," then in principle all the software to run on it must be rebuilt. The vast software assets stacked up around the world can no longer be used as is. So even when a technically superior newcomer appears, it "but if my existing software won't run…" struggles to spread. This "pain of moving house" is exactly what gives immense power to whoever holds the ISA.

3.7 Invisible, yet governing the world

What's strange is that an ordinary person never lays eyes on this ISA in their whole life. No one checks the ISA's name when buying a phone. And yet the ISA keeps quietly deciding "which software runs on which machine." Which phone you can choose, which apps you can use — behind all that, the invisible contract is at work.

"Invisible, yet binding the world's movements." Such things tend to become places where great power and great money gather. And indeed, this "shared language," the ISA, was for a long time the possession of particular companies. In the next chapter, Chapter 4, we move to the story of those "owners of the language" — the two empires of x86 and ARM. Why is it such a turning point when "a language is opened up for free"? The groundwork is now laid.