Have you ever noticed that ARMv8-A architecture extensions are published faster than Arm-designed cores make use of them? I'm pretty sure thats because architecture licensees are a major driver of those extensions. If Apple needs a CPU that adds X and Y to the architecture and removes Z, I have no doubt that Arm will work with them to allow it, and that it will probably come in the form of an architecture extension that permits it. Arm gets as much from Apple out of the relationship as Apple gets from Arm, and Arm surely knows it. They don't benefit from bossing Apple around.

Arm very recently started allowing Core licensees to add custom instructions (on M33 and M55). But they've allowed architecture licensees to do that for a long time (see XScale).

Yeah, agreed that architectural licensees definitely influence future ARM specifications - e.g. Fujitsu was a major driver behind SVE.

IMO, there's an important difference between Apple adding new instructions that are not in the spec, and Apple convincing ARM to add new instructions to the spec and then implementing those instructions.

In the first case, those are Apple-only instructions. In the second, that's just Apple implementing new ARM instructions.

> But they've allowed architecture licensees to do that for a long time

I don't agree that developing specifications and extensions based on the needs and desires of licensees is the same as permitting licensees to add custom instructions not permitted by the specification.

> They don't benefit from bossing Apple around

ARM benefits greatly from limiting fragmentation of their platform by exerting control over licensees.

"ARM very recently started allowing licensees to add custom instructions, but only for Cortex-M (embedded)."

They've reserved a block for that in the encoding space. Quite exciting! And it makes a lot of sense in embedded world.

Apple couldn’t care less; they are supposed to support 4K pages in hardware but they do not on recent chips.

ARMv8-A supports page sizes of 4k, 16k, and 64k. The specification permits implementations to choose which of these page sizes to implement. See the register ID_AA64MMFR0_EL1.

I'm not an expert, but I believe 4K support is required? Apple doesn't do that; they just have 16K granules (which I forsee as being problematic with compatibility as they bring these over to macOS).

> I believe 4K support is required?

As I said, I don't think that's the case. ARMv8-A supports the 3 page sizes and has a register so that implementations can advertise which are supported.

> Armv8-A supports three different granule sizes: 4KB, 16KB, and 64KB.

> The granule sizes that a processor supports are IMPLEMENTATION DEFINED and are reported by ID_AA64MMFR0_EL1

https://developer.arm.com/architectures/learn-the-architectu...

You know I asked around recently and it seems to be that all three are now optional. Perhaps Apple has pushed for this, because I recall 4K and 64K support being a hard requirement.