> I think Apple moving towards entirely ARM compatible Macs and Macbooks will drive the ARM SBC market forward for developers (it’s difficult to develop on architecture X for architecture Y).
I'd be very surprised if this was the case.
I'd be very surprised if this was the case.
Xcode/iOS's emulator is actually x86 - which is why it seems faster than Android's default emulator.
This is the same as the Android x86 "emulator".
(Mostly referring to the actual processor/OS itself; buttons that "vibrate" the phone are not really technically interesting to me.)
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.
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.
>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.
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...
> 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.
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.
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 isn't shy about communicating to developers that Apple Silicon uses ARM ISA. This is about conveying to consumers their unique platform advantage.
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.
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.
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.
See this post: https://www.realworldtech.com/forum/?threadid=187087&curpost...
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).
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).
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.
ARM very recently started allowing licensees to add custom instructions, but only for Cortex-M (embedded).
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).
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.
They've reserved a block for that in the encoding space. Quite exciting! And it makes a lot of sense in embedded world.
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...