Apple Expected to Announce Arm-Based Mac Plans at WWDC, Transition Away From Intel to Begin in 2021

[Sydde]

Regarding being arm64 - would that mean binaries built for arm64 should work on an Apple silicon mac without recompiling? Or docker containers targeting arm64 would just work?

Apple has specific APIs for its various OSs, so the ARM binaries would have to be compiled against the correct OS architecture and structured in a way that the target system can interpret. The binary executable format they use for files is slightly different from common formats like ELF (which is what I think Linux uses).

Software built on ARM against other APIs could work if a compatibility layer can be included in the system (OEM or 3rd party) possibly in the form of a hosted or simulated OS environment. This kind of stuff will probably happen.

 

[Unregistered 4U]

They may be contractually obligated to be compatible with at least some of the arm instruction subsets.

This is what their license calls for. Their solutions has to be ARM64 compatible, but Apple can extend their implementation if they want to create custom instructions.

 

[cmaier]

This is what their license calls for. Their solutions has to be ARM64 compatible, but Apple can extend their implementation if they want to create custom instructions.

Have you seen their license? I’m not convinced they took the standard architectural license.

 

[Sydde]

I got the impression that they are more like some kind of contributing partner.

 

[Unregistered 4U]

Have you seen their license? I’m not convinced they took the standard architectural license.

I’ve seen it mentioned a few times. Here’s a random result from Google.

ARM adds an architectural licensee

ARM has signed a rare architecture licence which allows licensees to design their own cores which use the ARM instruction set. The identity of the

www.electronicsweekly.com

 

[cmaier]

I’ve seen it mentioned a few times. Here’s a random result from Google.

ARM adds an architectural licensee

ARM has signed a rare architecture licence which allows licensees to design their own cores which use the ARM instruction set. The identity of the

www.electronicsweekly.com

Ok. Doesn’t really do more than speculate on the terms. I would guess that given Apple’s market power, bank account, and pre-existing special relationship with Arm, they have more flexible terms than the average Arm licensee. Just a guess of course.

 

[SocialKonstruct]

Why do I feel strongly that the iPad Pro is going to converge with the MacBook Pro and then we will see a MBP with a detachable iPad screen? AKA the MacOS version of the Surface Book series.

 

[Sydde]

Ok. Doesn’t really do more than speculate on the terms. I would guess that given Apple’s market power, bank account, and pre-existing special relationship with Arm, they have more flexible terms than the average Arm licensee. Just a guess of course.

All ARM licensees have flexible licenses. I have read (perused) various manuals (I think I have 603 and 68020 manuals in a box somewhere) and they tend to be pretty precise. By contrast, the ARMv8 manual has a lot of entries like

If a Store instruction performs a writeback and the register that is stored is also the base register, then behavior is CONSTRAINED UNPREDICTABLE and one of the following behaviors must occur:

• The instruction is treated as UNDEFINED.

• The instruction is treated as a NOP.

• The instruction performs the store to the designated register using the specified addressing mode, but the value stored is UNKNOWN.

which tells me that the basic license gives the builder significant latitude in how they implement the architecture.

 

[cmaier]

All ARM licensees have flexible licenses. I have read (perused) various manuals (I think I have 603 and 68020 manuals in a box somewhere) and they tend to be pretty precise. By contrast, the ARMv8 manual has a lot of entries like

which tells me that the basic license gives the builder significant latitude in how they implement the architecture.

Sure, Arm definitely allows things like that.

But, for example, could Apple leave out mandatory instructions? Maybe, as long as they don't call it Arm? Could they add a whole new set of vector instructions that aren't the same as Arm's? Maybe?

 

[Sydde]

If it was something like the Store-Release/Load-Acquire group, I could see how they might get away with leaving those out, maybe. I mean, a compiler is not going to put that stuff into user-level code and it almost never gets used. They do have to maintain a compatible user-level implementation (I would guess) but on the system side, they can do prettymuch whatever they want.

 

[brownpaw]

This is almost certainly a false assumption. Since most software on the mac somehow depends on Apple‘s toolchain - which is available of course on ARM as well including Metal - in most cases its probably rather easy to build ARM versions.

I was speaking of legacy software that's not going to get any dev time for an updated ARM version.

 

[Nütztjanix]

I was speaking of legacy software that's not going to get any dev time for an updated ARM version.

It’s quite possible that this legacy software doesn’t work on Catalina either if there’s no dev time. 64 bit only problem. So this wouldn’t make a difference.

 

[Sydde]

Ars is reporting leaked benchmarks for a devkit Mac Mini running what is probably some A12 (2-year-old) variant (4-core, not 4x4 big/little) that is slightly underclocked.

These tests appear to have been run in Geekbench 5.2.0 for macOS x86 (64-bit)—meaning they were run in Rosetta ... the Apple silicon-equipped developer kits average 811 for single-threaded Geekbench and 2781 for multi-threaded. That's about 20 percent slower than the entry-level i3-1000ng4 powered Macbook Air's single-core results and 38 percent faster than its multi-threaded results....​

Not as good as some of the Pro-level Intel Macs, but this is emulation (non-optimized translation). The true Mac-first-generation Axx chip will probably be quite a bit better than this, especially with XCode direct compilation.

 

[cmaier]

Ars is reporting leaked benchmarks for a devkit Mac Mini running what is probably some A12 (2-year-old) variant (4-core, not 4x4 big/little) that is slightly underclocked.

These tests appear to have been run in Geekbench 5.2.0 for macOS x86 (64-bit)—meaning they were run in Rosetta ... the Apple silicon-equipped developer kits average 811 for single-threaded Geekbench and 2781 for multi-threaded. That's about 20 percent slower than the entry-level i3-1000ng4 powered Macbook Air's single-core results and 38 percent faster than its multi-threaded results....​

Not as good as some of the Pro-level Intel Macs, but this is emulation (non-optimized translation). The true Mac-first-generation Axx chip will probably be quite a bit better than this, especially with XCode direct compilation.

There’s already a thread on this.

 

[Unregistered 4U]

Sure, Arm definitely allows things like that.

But, for example, could Apple leave out mandatory instructions? Maybe, as long as they don't call it Arm? Could they add a whole new set of vector instructions that aren't the same as Arm's? Maybe?

Here, it mentions that with the Architectural License, the cores still have to fully comply.

ARM architecture family - Wikipedia

en.wikipedia.org

But, then again, it’s assumed that the wiki writer has not actually seen Apple’s license and I haven’t found any definitive information whether or not Apple’s license does or does not adhere to one of the many types of licenses that ARM offers publicly.

I’ve also read an article (can’t find it now) that mentioned the license also allows for Architectural License holders to add custom instructions (as long as they’re otherwise compliant) which means they could concievably add a new set of vector instructions that aren’t ARM’s as long as ARM’s are there.

 

[Sydde]

The point is, the license applies to vendors. Apple is technically not a vendor, because they only distribute the Axx series within their own platform, for which they write their own system. They require that software be distributed in llvm-ir format, which means that the final compilation occurs either in their store or using code residing on each device, meaning that optimization can be tailored for each configuration. This means that the CPUs only have to be ARM-compliant at the intermediate-representation stage, after which the object code can be tweaked to function properly/ideally for the unit itself.

Not saying they are not fully ARM-compliant, but how can we know for certain?

 

[Unregistered 4U]

Not saying they are not fully ARM-compliant, but how can we know for certain?

Right now all the information available in the public indicates that ARM has a set of license agreements. The freedom Apple has with the architecture and what I have access to (like the Wiki page) says Apple has an Architectural license. That license starts with ARM instruction set compliance, and on pages defining the A-series chips, ARM32 and ARM64 is used (with no idea whether or not the writer actually tested for the compatibility, of course).

I guess one place to check would be cross platform app developers. If their ARM code is portable, then that would infer some form of adherence, but also not a complete picture. Even if someone HAS seen the agreement and posts anything, we’d have to assume they interpreted it correctly, something else that’s not a given.

As with a lot of things, there’s little way to know with 100% certainty, but for me personally, enough of the information leans in the “Architectural License” direction that I’m comfortable settling with that.

 

[jdb8167]

Right now all the information available in the public indicates that ARM has a set of license agreements. The freedom Apple has with the architecture and what I have access to (like the Wiki page) says Apple has an Architectural license. That license starts with ARM instruction set compliance, and on pages defining the A-series chips, ARM32 and ARM64 is used (with no idea whether or not the writer actually tested for the compatibility, of course).

I guess one place to check would be cross platform app developers. If their ARM code is portable, then that would infer some form of adherence, but also not a complete picture. Even if someone HAS seen the agreement and posts anything, we’d have to assume they interpreted it correctly, something else that’s not a given.

As with a lot of things, there’s little way to know with 100% certainty, but for me personally, enough of the information leans in the “Architectural License” direction that I’m comfortable settling with that.

I'm pretty sure that you can remove AArch32 and just retain 64-bit compatibility without violating the license. So that would allow Apple to reduce the complexity of the decoder while still honoring the license.

 

[Unregistered 4U]

I'm pretty sure that you can remove AArch32 and just retain 64-bit compatibility without violating the license. So that would allow Apple to reduce the complexity of the decoder while still honoring the license.

You can and they do. If you check wiki for the A-Series chips, the older ones are 32 and 64, newer ones are ONLY 64 compliant (on the right hand side of the respective processor’s main pages)
https://en.wikipedia.org/wiki/Apple_A10X Last A32 processor
https://en.wikipedia.org/wiki/Apple_A11 First A64 only

 

[jdb8167]

You can and they do. If you check wiki for the A-Series chips, the older ones are 32 and 64, newer ones are ONLY 64 compliant (on the right hand side of the respective processor’s main pages)
https://en.wikipedia.org/wiki/Apple_A10X Last A32 processor
https://en.wikipedia.org/wiki/Apple_A11 First A64 only

Thanks. I was looking for something definitive on this. (Not that Wiki is necessarily definitive but it gives me a starting point anyway.)

 

[Sydde]

I guess one place to check would be cross platform app developers. If their ARM code is portable, then that would infer some form of adherence ...

The problem is that a large fraction of dynamic library code is OS-reliant. Some gruntwork code might be directly portable without recompilation, but I suspect a lot of it has to be compiled directly against the target SDK. Unless it is written for darwin or GNUStep, it will likely not be directly portable.