How Different CPUs Execute The Same Software

[00:00:00]Welcome to this explainer. Okay, today we're going to tackle a concept that is absolutely everywhere in the tech world.

[00:00:07]I mean, you hear it in keynotes, you read it in articles, it's literally printed right there on the boxes of our gadgets. I'm talking about what is probably the most ubiquitous yet honestly fundamentally misunderstood term in all of computer science, architecture.

[00:00:23]So let's just dive right into this central mystery off the bat. Because in the tech world, architecture is just an incredibly overloaded term. Depending on the exact context we're using it in, it can mean completely different things.

[00:00:36]To cut through all that vagueness, we really need to strip away the marketing magic and look at how these machines actually process information down at the lowest level. To get to the bottom of this, let's build a processor from the ground up. We start by taking some basic transistors, right? We combine them into logic gates and then wire those into circuits. Now, if you keep stacking those special purpose circuits together, eventually you culminate in this critical super complex component, the arithmetic logic unit or the ALU. Now, the real key to the ALU is this thing called the op code. Think of this as the specific instruction. It's the command that tells the internal circuitry whether it needs to add, subtract, or you know, perform some other mathematical operation on the data inputs. Then boom, the result hits the output. Sounds simple enough, right? But how the ALU physically executes that instruction internally, well, that's where things get really complicated.

[00:01:30]Section one, the ambiguity problem. You see, the basic definition of an ALU tells us what it does, but it entirely leaves out exactly how to build the thing. There are literally countless ways to physically wire an ALU. A designer might build it to just calculate every operation all at once and then solely route the correct output. Or on the flip side, they might route inputs only to specific internal pathways. And it gets crazier. The bit patterns themselves vary wildly. To one designer, a 00 triggers addition. To another, no way, that means subtraction.

[00:02:01]They might even support completely different sets of operations altogether.

[00:02:05]Because of all this variation, a string of ones and zeros is absolutely not universal. If you take two different ALUs engineered by two completely different teams, and you feed them the exact same data and instruction bits, you might get completely different results. Their internal brains are fundamentally interpreting that data differently, which creates a literal physical incompatibility.

[00:02:25]To really make sense of this, let's think about software for a second. When a software developer is handed a single problem, they can solve it using multiple different algorithms, right? We call those specific solutions implementations. Well, the exact same principle is true in hardware design. A hardware engineer can build multiple physical implementations of the exact same component, meaning two processors can be completely different on the inside, yet still technically satisfy the broad textbook definition of a CPU.

[00:02:54]Which brings us to section two, the software-hardware contract.

[00:02:59]So, if hardware can be this radically different on the inside, how does any software run reliably? Well, to resolve this total chaos, we have to split that vague term architecture into two very precise concepts, the instruction set architecture and the microarchitecture.

[00:03:15]When the tech world talks about architecture broadly, they're almost always referring to the marriage of these two distinct things.

[00:03:22]Let's look really closely at the instruction set architecture first, or the ISA for short. This is the abstract specification. It's the strict rulebook telling software exactly what simpler operations are available to actually build a solution, what specific combinations of ones and zeros are required to trigger those operations, and exactly how those instructions must be formatted. In short, the ISA acts as the ultimate programmer-visible contract between the software and the processor.

[00:03:49]It basically tells the software, "Look, if you give me these exact bits, I promise to give you this exact behavior.

[00:03:55]The microarchitecture, on the other hand, is the actual physical circuitry that gets the job done. It is the specific implementation of that ISA contract. And honestly, this is the magic part. Two wildly different internal chip designs, meaning two entirely different microarchitectures, can be completely compatible with each other if they faithfully obey the exact same ISA rulebook. Because they follow the exact same externally visible rules, the software frankly doesn't care how the chip actually works on the inside.

[00:04:28]Let's move on to section three, real-world architectures. Let's apply this to the actual devices sitting on our desks right now. The most widely used instruction set architectures today are x86-64, ARM, and the open-source RISC-V.

[00:04:43]Take x86-64 for example. Companies like Intel and AMD build dozens of vastly different physical microarchitectures.

[00:04:52]Their internal circuitry is highly guarded, incredibly distinct intellectual property. But, because they both faithfully implement the x86-64 ISA rulebook, a program compiled for that ISA is going to run perfectly on both an Intel chip and an AMD chip. However, if you try to take that exact same x86-64 software and run it natively on an Apple M series processor, it's just going to fail. Why? Well, because Apple's processors implement the ARM set architecture. They are following an entirely different rulebook. The fundamental contract between the software and the hardware has completely changed, so those instructions are practically a foreign language to that Apple chip.

[00:05:32]Section four, the 1980s porting nightmare.

[00:05:37]Now, you might be wondering, why do companies strictly adhere to these specific ISAs instead of just inventing entirely new ones every single year?

[00:05:45]Well, to answer that, we just have to look back at the computer industry of the 1980s. Back then, there was virtually no widespread agreement on rules. Every new computer had a completely unique, totally bizarre hardware setup. I mean, we're talking about mind-boggling systems utilizing a 72-bit word length. Yeah, 72.

[00:06:02]Porting software during that era was an absolute nightmare. With no standardized ISA across the board, existing software was just never automatically compatible with new machines.

[00:06:13]Developers couldn't just recompile their code. They frequently had to rewrite their entire operating systems from scratch just to accommodate these insane, proprietary hardware quirks.

[00:06:23]Some of which, honestly, weren't even powers of two. Can you imagine? It is a staggering reality that leaves us with one final, pretty massive question to ponder. Would any of the modern software we rely on today actually work without the unseen contract of an ISA? So, the next time a massive tech company gets on a stage to announce a revolutionary new architecture, remember what's actually happening behind the scenes. You are almost always looking at a brand-new, innovative microarchitecture that is still faithfully obeying a strict, decades-old contract. It is that invisible rulebook that ultimately holds our entire digital world together.

[00:06:57]Thanks so much for joining me for this explainer, and keep questioning how your digital world really works.