Not only limited connection between Macs and SBCs, but the opposite has been true about iOS development.

Although interestingly, Android development on the other hand was actually hampered for a long time by the slow emulator

If your doing Android Development with the ARM emulator, then its crazy slow. However, if you use the x86 emulator - then you get native speed.

Xcode/iOS's emulator is actually x86 - which is why it seems faster than Android's default emulator.

Xcode doesn’t emulate anything, it runs the entire iOS userspace as native processes on top of the macOS kernel.

It "emulates" the hardware - e.g. you can inject shake / GPS / etc

This is the same as the Android x86 "emulator".

IIRC the Android uses hardware-assisted virtualization through Intel HAXM. iOS simulator is run entirely in userspace in a seperate launchd context.

(Mostly referring to the actual processor/OS itself; buttons that "vibrate" the phone are not really technically interesting to me.)

The annoying part about the default x86 emulator that installs from Android Studio is that it's incompatible with hyper-v. Requiring a reboot to disable.

There's a little bit about the history of ARM and Apple in the podcast Acquired did about Softbank and ARM.

https://www.acquired.fm/episodes/arm-softbank

I'm surprised that Apple didn't buy ARM yet.

My guess is that Apple buying ARM is a money-losing proposition. Actually licensing the ISA can't be terribly profitable for a company of Apple's size, and ARM being fabless means there's not much competitive advantage to owning (rather than licensing) the ISA. Simply owning ARM might invite antitrust concerns that Apple really doesn't want to be dealing with, and risks souring their business relationships. Actually trying to exploit the ownership, beyond collecting royalties, would guarantee both. As, perhaps, would any future efforts to put proprietary ARM extensions into their Cortex line.

So the reason Apple would buy Arm is to save itself money on the architecture license in the long run, right? But it could also save money on the architecture license if it switched to RISC-V. And you can be sure there's a tightly guarded spreadsheet somewhere inside Apple that models whether or not switching to RISC-V is a good idea.

Of course, Arm can figure all that out too, so somewhere inside Arm they've tried to replicate Apple's "should we switch to RISC-V" spreadsheet, and Arm sets the price of the architecture license so that the spreadsheet will always say "don't switch to RISC-V".

The other thing to consider: Arm's core design business is quite valuable; probably more valuable than their architecture business. But Apple does their own core design, and would not be interested in selling core IP to others, so they would get no value from that business. But if they were to buy Arm, they'd still have to pay for it.

Apple owned 43% of ARM in the early 1990s, when the company was investing heavily into Newton and associated mobile technologies during the Jobs interregnum.

Owning the instruction set and reference designs maybe isn’t terribly useful, when your primary competitors already have perpetual licenses to the technology and do their own core designs.

I think they’d struggle to do anything with it, given anti-trust concerns

Apple is one of the parties which founded ARM

Source? As far as I can see they only made a joint venture: https://www.latimes.com/archives/la-xpm-1990-11-28-fi-4993-s...

According to that article the joint venture they co-founded was actually ARM.

>The company was founded in November 1990 as Advanced RISC Machines Ltd and structured as a joint venture between Acorn Computers, Apple Computer (now Apple Inc.) and VLSI Technology.

>The new company intended to further the development of the Acorn RISC Machine processor, which was originally used in the Acorn Archimedes and had been selected by Apple for its Newton project.

https://en.wikipedia.org/wiki/Arm_Holdings#Founding

True, however the joint venture was founded to “further develop” the technology. That means the ARM architecture itself seems to have originated at Acorn, without Apple.

The point is, originally, Apple were co-owners of Arm (together with Acorn and VLSI).

Yes, that's correct.

The CPU architecture was developed long before the joint venture.

IIRC, it began as an expansion board for the BBC Micro.

This article implies that initial ARM development was undertaken between 1983 - 1985:

https://www.theregister.com/2012/05/03/unsung_heroes_of_tech...

This will make a huge headache for them and it's legal department since acquisition must be approved from government.

That requires that Softbank is willing to sell.

They are: https://www.bloomberg.com/news/articles/2020-07-22/softbank-...

> As part of the sale process, SoftBank approached Apple to gauge its interest in acquiring Arm, according to people familiar with the matter. While the two firms had preliminary discussions, Apple isn’t planning to pursue a bid, the people said.

I'm not quite sure where the assumption that Apple Sillicon instruction set will even be compatible with other ARM chips. Apple does add their own instructions.

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.