Designing Cores for Someone Else's Instruction Set

"The instruction set is the contract. The core is how you keep it."

Two Things Called "Arm"

Arm the company sells two very different things. A core license is a finished processor design — a Cortex core — that a chip vendor drops onto its die and surrounds with its own memory controllers, GPU and peripherals. Most phone and laptop SoCs are built this way; the cores are Arm's, the integration is the vendor's. An architecture license is something else: the right to implement the Arm instruction set with a microarchitecture of your own design. The binaries are the same; everything underneath — how wide the core is, how it predicts branches, how deep its queues are, how it is clocked — is yours to decide.

Apple holds the second kind. Since the A6 in 2012 its CPU cores have been Apple designs that implement the Arm instruction set (AArch64 since the A7, the first 64-bit Arm core in a phone), and the M-series cores are the same lineage grown up. That is the precise answer to "is the M1 an Arm chip": it runs Arm's instruction set, and none of its cores were designed by Arm.

What an Instruction Set Is, and Why It Was the Right Thing to Borrow

An instruction set architecture (ISA) is the boundary between software and hardware: the list of instructions, registers, memory model and privilege levels that a compiler targets and a core must honour. It is an interface in exactly the sense of the previous track, and it is the one interface Apple chose not to own. The reason is the interface's usual gift: substitution on the other side. By adopting an ISA that already had compilers, operating systems, debuggers and a decade of optimized libraries, Apple got the whole software layer for free and could spend its engineering on the half that mattered to it — the core underneath.

What the license leaves to Apple is everything a spec sheet calls "microarchitecture": the number of instructions decoded and issued per cycle, the size of the reorder window, cache sizes and hierarchy, the branch predictor, the clock, and the mix of core types on a die. The next three lessons are about those choices. The point of this one is that they are choices — Apple was not handed a Cortex core and told to make the best of it.

The ISA Has Optional Parts, and Your Mac Will Tell You Which It Has

Arm's ISA grows by versions and optional extensions — advanced SIMD, half-precision floats, bfloat16, integer matrix multiply, the Scalable Matrix Extension (SME). Each is a feature flag a core either implements or does not, and macOS exposes the flags through sysctl hw.optional.arm.FEAT_*. The code block reads them. On an M3 Ultra you will find FEAT_BF16, FEAT_I8MM and FEAT_FP16 set — the extensions that matter for machine-learning arithmetic on the CPU — and FEAT_SME at 0, because SME arrived with the M4 generation. That last flag is worth remembering: it is the public, documented successor to a matrix unit Apple has shipped since the M1 without ever naming, which is lesson four's story.

One consequence of borrowing the ISA is worth stating because coding assistants get it backwards: Apple silicon does not run x86 code. Intel-era binaries run through Rosetta 2, a translator, and the translator works as well as it does because Apple built specific hardware support for it — also lesson four. The ISA is borrowed from Arm; the compatibility with Intel is engineered on top.

Code

isa_features.py — which optional parts of the Arm ISA does this core implement?·python

#!/usr/bin/env python3
"""Read the Arm feature flags macOS exposes. 1 = implemented, 0 = not.
The set is the architecture license made visible: Apple chose these."""
import subprocess

out = subprocess.run(["sysctl", "hw.optional.arm"], capture_output=True, text=True).stdout
flags = {}
for line in out.splitlines():
    key, _, val = line.partition(": ")
    flags[key.replace("hw.optional.arm.", "")] = val.strip()

WATCH = ["FEAT_FP16", "FEAT_BF16", "FEAT_I8MM", "FEAT_DotProd", "FEAT_SME", "FEAT_SME2", "FEAT_LSE", "FEAT_SHA512"]
print(f"{len(flags)} feature flags reported\n")
for k in WATCH:
    print(f"{k:14} {flags.get(k, 'not reported')}")

print("\nml-relevant:", ", ".join(k for k in ("FEAT_FP16", "FEAT_BF16", "FEAT_I8MM", "FEAT_SME") if flags.get(k) == "1"))

The same flags from the shell, and the architecture the kernel reports·bash

sysctl hw.optional.arm.FEAT_BF16 hw.optional.arm.FEAT_I8MM hw.optional.arm.FEAT_SME
# hw.optional.arm.FEAT_BF16: 1      <- office, M3 Ultra, 2026-09-15
# hw.optional.arm.FEAT_I8MM: 1
# hw.optional.arm.FEAT_SME: 0       <- SME arrived with M4; an M4/M5 Mac reports 1

uname -m          # arm64
arch              # arm64 natively; i386 inside a Rosetta shell (lesson four)

Exercise

Run isa_features.py on every Mac you can reach and add two columns to your card: FEAT_SME (0 or 1) and the count of reported flags. Then find one flag whose value differs between two of your machines and, from Arm's feature list, write one sentence on what a program could do on the machine that has it that it cannot do on the other.

Hint

FEAT_SME is the obvious split (M4 and later). If all your Macs are one generation, compare FEAT_SME2 against FEAT_SME, or look at the crypto flags — the point is that 'Arm' is a family of contracts, and your Mac signed a specific one.