ARM and the Mobile Pivot
Two cars roll off two assembly lines in 1985. The first is a Detroit V8 muscle car. It drinks fuel by the gallon, makes a beautiful noise, and goes very fast on a wide-open highway. The second is a tiny British city car with a half-size engine sized to a single rule — go as far as it can on the smallest possible cup of fuel. Nobody pays much attention to the city car at first. The highway is where the racing happens. Then the world stops racing on highways and starts racing in cities. Forty years later there is a city car in every pocket, every laptop, and every other server rack at Amazon. The muscle car still exists. It just stopped winning the races that mattered.
The city car was designed in 1983 by a team of about a dozen engineers at a British company called Acorn Computer in Cambridge. Acorn had won the contract to build the BBC Micro, the school computer that taught a generation of British children to type LIST at a flashing cursor. The BBC Micro used a CPU from another company. Acorn wanted a chip they owned. Two engineers on the team, Sophie Wilson and Steve Furber, had just read Patterson's Berkeley paper arguing for simpler instruction sets. They sat down to design their own. Wilson wrote out the instruction set on paper over a few months. Furber drew the chip layout. The team was small enough that the power budget was tight not because anyone insisted on it but because they could not afford the cooling that a hot chip would need. The first ARM1 came back from the fab in April 1985, drew about a tenth of a watt, and ran so cool that the engineers thought it was broken. They had built a chip that needed almost no battery.
A tenth of a watt did not matter on a desktop. Intel's Pentium in 1993 burned 16 watts and nobody cared because it was plugged into a wall. What mattered about a tenth of a watt was the thing that came eight years later. Apple was working on a tablet-sized device called the Newton — a notepad-shaped computer you could carry around and write on with a stylus. The Newton needed a CPU that would run for a few hours on a few AA batteries. Intel could not help. The Newton team flew to Cambridge in 1990, looked at ARM, and decided that this strange British chip was the only thing that would fit their power budget. Apple put up the money and spun ARM out of Acorn into a separate company called ARM Holdings whose business was selling chip designs to anyone who needed a low-power CPU. The Newton flopped. The chip survived.
The decade after the Newton was a slow conquest of every gadget Intel could not enter. Nokia phones used ARM. Palm Pilots used ARM. The first iPod in 2001 used a chip with two ARM cores. None of these were the moment that mattered. The moment that mattered was Steve Jobs holding up the iPhone in January 2007 with an ARM11 inside it. The iPhone's CPU drew about a watt at full tilt, which was the largest number that would let a 3.7-volt lithium battery in a pocket-sized slab run a screen and a radio and a CPU for a full day. Intel's smallest desktop chip at that moment drew thirty-five times that. Intel had been offered the iPhone contract two years earlier and turned it down because the margins looked too thin. Jobs went to Samsung, who fabbed an ARM design, and never looked back.
By 2010 every phone on earth ran an ARM chip. By 2015 Apple had built its own ARM designs in house — the A-series — and was beating the chips it was buying from Samsung. In 2020 Apple put one of those designs into a laptop and called it the M1. The MacBook Air with no fan ran cooler than an Intel MacBook Pro and lasted twice as long on a battery, because the chip inside had been bred for forty years to win exactly that race. The same year Amazon announced that an ARM-based chip called Graviton, which they had designed themselves, was now the default CPU for new AWS instances because it cost less to run per watt of data-center power. The chip Wilson and Furber sketched on paper in a small Cambridge office in 1983 was now the chip your phone, your laptop, and the server hosting this lesson all ran on.
Here is a Rust program that lays the story out as a table. Each row is a chip, the family it belongs to, the year it shipped, the watts it draws under load, and the device it shipped in. The Chip struct is a plain piece of data — a year, a name, a family string, a watt number, and a description.
struct Chip {
year: u16,
name: &'static str,
family: &'static str,
tdp_watts: u32,
shipped_in: &'static str,
}
const CHIPS: &[Chip] = &[
Chip {
year: 1985,
name: "ARM1",
family: "ARM",
tdp_watts: 1,
shipped_in: "Acorn Archimedes (UK desktop)",
},
Chip {
year: 1993,
name: "Intel Pentium",
family: "x86",
tdp_watts: 16,
shipped_in: "desktop PCs on AC power",
},
Chip {
year: 1993,
name: "ARM610",
family: "ARM",
tdp_watts: 1,
shipped_in: "Apple Newton (first PDA)",
},
Chip {
year: 2007,
name: "ARM11 (in iPhone)",
family: "ARM",
tdp_watts: 1,
shipped_in: "iPhone 1 (3.7V battery)",
},
Chip {
year: 2008,
name: "Intel Core 2 Duo",
family: "x86",
tdp_watts: 35,
shipped_in: "MacBook (wall + battery)",
},
Chip {
year: 2020,
name: "Apple M1",
family: "ARM",
tdp_watts: 20,
shipped_in: "MacBook Air (no fan)",
},
Chip {
year: 2018,
name: "AWS Graviton",
family: "ARM",
tdp_watts: 60,
shipped_in: "AWS data-center server racks",
},
];The main function walks the list, prints the table, then computes the average wattage on each side. Two lines of math, no surprises.
fn main() {
println!("ARM vs x86: watts per chip, by year");
println!(
"{:<5} {:<20} {:<6} {:>5} {}",
"year", "chip", "family", "watts", "shipped in",
);
println!("{}", "-".repeat(80));
for c in CHIPS {
println!(
"{:<5} {:<20} {:<6} {:>5} {}",
c.year, c.name, c.family, c.tdp_watts, c.shipped_in,
);
}
println!("{}", "-".repeat(80));
println!();
let arm_total: u32 = CHIPS
.iter()
.filter(|c| c.family == "ARM")
.map(|c| c.tdp_watts)
.sum();
let arm_count = CHIPS.iter().filter(|c| c.family == "ARM").count() as u32;
let x86_total: u32 = CHIPS
.iter()
.filter(|c| c.family == "x86")
.map(|c| c.tdp_watts)
.sum();
let x86_count = CHIPS.iter().filter(|c| c.family == "x86").count() as u32;
println!(
"ARM average TDP: {} watts across {} chips",
arm_total / arm_count,
arm_count,
);
println!(
"x86 average TDP: {} watts across {} chips",
x86_total / x86_count,
x86_count,
);
println!();
println!("a battery is a watt-hour budget. the chip that sips wins the pocket.");
}Build it and run it.
ARM vs x86: watts per chip, by year
year chip family watts shipped in
--------------------------------------------------------------------------------
1985 ARM1 ARM 1 Acorn Archimedes (UK desktop)
1993 Intel Pentium x86 16 desktop PCs on AC power
1993 ARM610 ARM 1 Apple Newton (first PDA)
2007 ARM11 (in iPhone) ARM 1 iPhone 1 (3.7V battery)
2008 Intel Core 2 Duo x86 35 MacBook (wall + battery)
2020 Apple M1 ARM 20 MacBook Air (no fan)
2018 AWS Graviton ARM 60 AWS data-center server racks
--------------------------------------------------------------------------------
ARM average TDP: 16 watts across 5 chips
x86 average TDP: 25 watts across 2 chips
a battery is a watt-hour budget. the chip that sips wins the pocket.Look at the watts column. Every ARM chip on the list draws between 1 and 60 watts. Every x86 chip draws between 16 and 35. The averages at the bottom tell the same story — the ARM family has been holding the same low-power line since 1985, while x86 was designed to climb upward through the wattage chart because climbing upward was the only way to win on the desktop. When the prize stopped being desktop performance and started being battery life, the chart stopped being a race the other side could win.
The unified-memory M1 design from the last lesson is the same idea pushed further. A chip that started its life designed for the smallest possible power draw kept inheriting the constraints of the place it was born — the phone in your pocket — even when it scaled up to a laptop and a data center. Intel spent forty years adding watts so it could add performance. ARM spent forty years adding performance without adding watts. The world picked the second one.
What the table on the page cannot show is what happens when the same Rust source has to compile into two completely different sets of bytes — one for the ARM chip in your laptop, one for the x86 chip in someone else's server — which is what the cross-compile lesson does next.