There isn't any standard matrix multiplication instruction set so there's nothing to standardize over. Machine-learning driven instruction sets (of which MM instructions are motivated by, but not exclusively for) like this have been generally bespoke because the field moves relatively quickly compared to hardware. Every vendor generally follows some basic principles but the specifics are dependent on the workloads and models they expect e.g. quantization or how they expect to split models across accelerators. And ARM does not allow public proprietary instruction set extensions to ARM cores, one of their defining architecture features is that licensees literally are not allowed to do this.[1] The only reason Apple was allowed to do so in this case is likely 1) They negotiated it as part of their AAL (probably for a lot of money) and 2) They do not publicly document or commit to this feature in any way. It could get deleted or disabled in silicon tomorrow and Apple would be able to handle that easily, and in every other visible way they have a normal ARM64 complaint CPU core (there is the custom GIC and performance counters and some other stuff, but none of those violate the architectural license and are just IP stuff they chose to work on themselves.)
So actually the thing you're complaining about is prevented by ARM themselves; Apple cannot publicly commit to features that would fragment the architecture. They don't have to do everything identical either, though.
[1] They have publicly said they will allow some future Cortex cores to contain custom instructions, but it is quite clearly something they're very much still in control over, you won't get a blank check, especially considering almost all ARM licensees use pre-canned CPU cores and IP. You'll probably have to pay them for the extra design work. There are no known desktop/server-class CPUs that fit this profile on the current ARM roadmap, or any taped out processor, that I am aware of.
> The only reason Apple was allowed to do so in this case is likely 1) They negotiated it as part of their AAL (probably for a lot of money)
Apple fronted the cash that created ARM holdings in the first place, so yes, they invested quite a lot of money (well, relative to the other senior partners Acorn and VLSI and later investors), and ARM was hardly in a position to tell them "no".
> They would not use that naming if they intended to support the official ARM ISA in the long run.
Given Apple's marketing priorities, my guess is that the intent you speak of had zero weight in their naming decisions either way. They have no interest in raising the profile of ARM chips in general, and every interest in promoting their specific chips as amazing.
I was referring to branding. To clarify my point, I believe having branding separate from Arm’s does not substantially indicate a desire to move away from Arm.
I suspect, given Apple's pivotal role in founding ARM holdings, that they have as close to carte blanche with respect to the ARM IP as one could imagine.
Huh, I hadn't realised Apple had been one of the investors when ARM Holdings was spun out of Acorn Computers. It seems their interest was in the Newton using ARM chips.
So actually the thing you're complaining about is prevented by ARM themselves; Apple cannot publicly commit to features that would fragment the architecture. They don't have to do everything identical either, though.
[1] They have publicly said they will allow some future Cortex cores to contain custom instructions, but it is quite clearly something they're very much still in control over, you won't get a blank check, especially considering almost all ARM licensees use pre-canned CPU cores and IP. You'll probably have to pay them for the extra design work. There are no known desktop/server-class CPUs that fit this profile on the current ARM roadmap, or any taped out processor, that I am aware of.