Citation?

Edit - I'm getting downvoted but if you're going to suggest that Apple are departing from the ARMv8 instruction set - which is a really important point if true and which I've not seen any evidence for - then you really need to supply a citiation.

I'm digging through history to find an article about Apple's LLVM patches to add a custom instruction only present on A series chip. Due to Sillion announcement it's kinda hard to find - but they did add at least one instruction to ARM instruction set.

From this, and from the very very strong marketing push to NOT use the name "ARM" from Apple, I have a suspicion that Apple Sillicon instruction set won't be a fully standard ARM holdings instruction set

"Apple Silicon" is simply a marketing term for, well, Apple's silicon. They're making this major change to their computers with the promise of better performance, functionality and battery life. Apple's made major investments to have the best chips in their class. Many of the functional improvements come from SoC siblings like GPU, neural cores, hardware codecs, etc. Why would Apple want to give ARM all the credit for that?

Apple isn't shy about communicating to developers that Apple Silicon uses ARM ISA. This is about conveying to consumers their unique platform advantage.

Thanks - I guess I would draw a big distinction between adding a new instruction as part of being first to a new version of ARMv8 - which then becomes part of the standard ISA, and adding a permanently Apple only instruction. Would be very disappointed if it's the latter.

Agreed that the Apple Silicon branding was very strong but assumed that it was just to distinguish themselves with consumers from those who will also use ARM on the desktop.

ARMv8.6 exists

Apple uses V8.4

Current ARM designs use v8.2

As you might suspect, that leaves Apple stuck doing the software support. It also gives them additional instructions that aren't proprietary to them, but are currently unique to them.

> and from the very very strong marketing push to NOT use the name "ARM" from Apple,

This is puzzling to me. I assume it's simple egotism. Apple marketing and also the user community at large tends to present their technologies as exclusive and product categories as invented by them, even when it's a stretch. This has a long history.

There are the AMX machine learning on-die accelerators. I assume there's some new instructions to talk to those.

You don't need special instructions to talk to peripheral devices. The ISA supports that from the get go. As a licensee, you can't add instructions to the ISA, only ARM can do that. That's what they do, they're the custodians of the ARM architecture.

They are probably just peripherals, like the GPU. I'd be very surprised if Apple strayed from the ARMv8 specification and added new instructions for those accelerators.

See this post: https://www.realworldtech.com/forum/?threadid=187087&curpost...

That whole thread is just speculation, same as what we are doing here.

See this post: https://www.realworldtech.com/forum/?threadid=187087&curpost...

As long as it's a compatible superset of ARM64, I don't see a big problem.

Just because you don't see the problem, it doesn't mean it's not there. However you want to put it, you can't add (or remove) instructions at your leisure if you want to keep your license. It does not happen. I can get into details if you want, but I think it's besides the point.

I can see a significant problem with adding proprietary instructions. Would be interested in more detail on ARM specifics if available. Thanks.

1) ARM sells "ecosystem". They can license their IP because licensees know that, once they buy into it, they benefit from a unified ecosystem. Developing and, more than anything else maintaining an ecosystem, is extremely expensive, messy, and error prone. ARM adds value by keeping that ecosystem in order.

2) ARM instructions have a fixed length of 4 bytes. This means that there's a limited number of instructions you can add. Intel, for instance, is different: they have a very complex encoding scheme that gives them, potentially, limitless encoding space.

3) If any licensee, specially a popular one like Apple, decides to take part of that encoding space for their own instructions... do you see the implications? Now, that space is unavailable to ARM. ARM, the owner and custodian of the ISA, are put in an impossible position: accept those instructions into the ISA (if Apple allows it, because now it's their IP) or lose unity in their ecosystem (fragmentation). In any case, they've lost extremely valuable encoding space and, more importantly, control over their own ISA.

And that's why not only ARM don't allow licensees to implement their own instructions, they will never allow it (generally speaking; they have reserved some encoding space in the M profile for custom instructions, but that's controlled customization in a profile that has fewer instructions to begin with).

Thanks. Makes a lot of sense.

Apple is making a really strong push to differentiate it's chips from ARM. A few of the mac sites are claiming it's "Apple Silicon" and not "ARM". I believe the heart of it is that Apple has "followed the ARM spec" but did not use ARMs actual silicon designs.

I don't really know what the backing of this is either. I'm sure they added a few of their own instructions. And I read that they single handedly pushed the ARM platform to 64bit (citation needed, definitely not sure if that's really true).

"Apple Silicon" is a literal truth. The silicon design, the microarchitecture, is theirs, not ARM's. The architecture, this includes the ISA but also many other things that have to be taken into consideration in CPU design (exception model, consistency, virtual memory, virtualization,...), is ARM's. They simply don't want to tie their brand to ARM's, which is fair enough, Apple's brand is much more valuable than ARM's.

Regarding the push for a 64-bit chip, I've heard the exact opposite. Aarch64 (64-bit ARM) was an ARM design without a customer, Apple were the first to buy into it. I've heard that many said it was a premature jump, and there was a lot of scepticism within ARM that they'd be able to sell it (this happened when ARM was selling mobile designs exclusively, with no intentions of getting into servers). Still, they went ahead with it, and was an unexpected success.

It’s easier to just tweak some system registers than to do that (and indeed this is how Apple implements their proprietary “in-silicon” features).

HN seems to dislike too much conciseness -- I guess a single-word comment, even if it's a good reply, comes across as impolite or low effort (for the lack of tone in text).

Thanks. (Please don't downvote me!)

Apple does not have a license to add instructions to the ARMv8 ISA. ARMv8 processors designed by Apple must be fully compliant with the ARMv8 instruction set architecture - such are the terms of the license.

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

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.

If they want to keep their architectural license they have to have their designs pass certain compatibility benchmarks.

I wouldn't put it past them to have paid silly money for a bespoke license.