Apple Adds ARM Support to MacOS Sierra Kernel | Hacker News Reader

Apple Adds ARM Support to MacOS Sierra Kernel

iclarified.com

151 pointsrcarmo81 comments

Open articleView on HN

These header files have listed various ARM chips for years. This is expected since iOS runs on xnu!

They even reference sparc, vax, and several more ancient architectures.

Take a look at the full file here: http://opensource.apple.com//source/xnu/xnu-3248.60.10/osfmk...

So this is not a sign of ARM support in macOS.

Yep. Similarly in the OS X 10.11 API Diff document from last year [1] you can see "Added #def CPUFAMILY_ARM_TYPHOON".

[1] https://developer.apple.com/library/prerelease/content/relea...

If I remember correctly, someone did an article a while back on getting xnu to run on ARM because of the AirPort.

AFAIK, AirPort is actually running NetBSD[1], with the first generation being VxWorks.

[1]: https://www.youtube.com/watch?v=MxvOgd2T2nA

Interesting. Any idea Why NetBSD and Not FreeBSD? Since they both support MIPS, and surely Apple is more familiar with the FreeBSD codebase given the similarities with OSX.

I am going to assume future model will likely be ARM based, and therefore moving towards iOS as well.

I don't know for sure but my guess would be netbsd's cross-compile toolchain is very good--that is, to compile MIPS binaries from an x86

> This bit code is then used by Apple to convert the application to the specific platform. Which means that Apple can easily make the transition to a different instruction set, for example, switching from x86 to ARM without all apps need to be resubmitted

My understanding of bitcode is that this is incorrect. The bitcode 'intermediate representation' isnt source code that can just be recompiled into a completely different instruction set. Rather, it's to take advantage of optimisations when there are minor changes in the same arch.

An Intel to ARM switch would still require developers to update and resubmit their apps in order to be compatible.

Edit: As pointed out below, Mac App Store/macOS doesn't even support bitcode, so this entire point is moot.

That is the official LLVM bitcode, which doesn't mean Apple is using their own internal architecture neutral fork.

My understanding is that still "Apple Bitcode" is not architecture neutral and is not able to be used by Apple to automatically convert Intel apps to ARM.

The other part that's missing is that Apple only has Bitcode for Mac apps distributed through the Mac App Store, which leaves out most that people actually use.

> The other part that's missing is that Apple only has Bitcode for Mac apps distributed through the Mac App Store

Does it even have that? As far as I know bitcode is a requirement for watchOS and tvOS, an option (enabled by default) on iOS, I've found no reference to it even existing on MAS/macOS.

Ahh haha you're absolutely right - Bitcode doesn't exist for Mac at all, rendering this entire conversation moot.

Depends how serious is Apple about closing down the desktop.

The strategy of shifting macs to ARM with a closed-up MAS is nonsensical and has no evidence for it. MAS is a graveyard, it would seriously antagonise all existing mac user base, and it's not supported by the article (iOS being XNU-based is a sufficient reason to have ARM references in there).

Now if Apple wanted to close up "the desktop" and shift it to ARM, what could/would make sense would be scaling iOS further up from its current position: revive the iBook brand (or create a new brand) as a Chromebook-type laptop on ARM with a new iOS form factor, possibly with a touch-enabled display or as a convertible. That would be a relatively natural extension of the iPad Pro concept, would have precedent in the aforementioned Chromebooks, and could provide an acceptable entry-level (sub-$1000) laptop replacement to the 11" Air, at least for students and the like. It could even have a cellular option.

This is the future of Macs, who thinks otherwise will be surprised,

https://www.youtube.com/watch?v=1zPYW6Ipgok

Then again, Apple has a history of doing things in ways that were nonsensical and antagonising to some people before (no apps on iPhone, no phone plug, reviewed apps only on iOS AppStore, etc. etc.).

I'm not sure why moving to MAS only software on desktop OS would be such a stretch of imagination on ARM MacBooks?

> I'm not sure why moving to MAS only software on desktop OS would be such a stretch of imagination on ARM MacBooks?

Because MAS is a failure and a graveyard and restricting freedom on the mac tends to be seen in a bad light. Why break that ecosystem when you can get the same result by building up the other one, in which a restricted ARM laptop fits naturally?

> That is the official LLVM bitcode, which doesn't mean Apple is using their own internal architecture neutral fork.

Where would it live? The bitcode uploaded to the AppStore is the one produced by the local toolchain, AFAIK there's no evidence that it's a fork with its own custom platform-independent bitcode.

The point of bitcode is that Apple can the compile separate packages for ARM32 and ARM64 devices, can easily drop ARM32, and can eventually migrate Watch software to ARM64 without involving developers (hence bitcode being required for WatchOS and tvOS, but optional for iOS). It also lets them perform higher-level static validation of software, or add new transformation/optimisation passes.

Incidentally, the whole thing is irrelevant because bitcode is an appstore feature, I've found no reference to it being used for MAS.

Apple toolchain is not the same you download from llvm.org.

Which completely misses the point, Apple's toolchain is machine-local, it can be inspected, so can the compiled bitcode package, and in the year since bitcode was released (and mandated for watchOS and tvOS) nobody has reported anything which would distinguish it from LLVM's bitcode.

And again the whole discussion is nonsensical considering bitcode is an appstore thing, MAS doesn't use it, it's not a thing on macOS at all.

So you know more than anyone else what is going on Apple walls?

I don't, so it makes sense to speculate.

Nothing prevents Apple to make the MAS a requirement for thr desktop as well.

> Nothing prevents Apple to make the MAS a requirement for thr desktop as well.

Except they haven't because the market and plenty of other realities prevent them from doing this.

Keep hoping.

>So you know more than anyone else what is going on Apple walls?

Strawman. He didn't claim that, just that the bitcode out of XCode is the same as that out of LLVM directly.

No need for access behind "Apple walls".

So you do have access to whatever might be XCode vNext?

Not sure what you keep talking about or deflecting.

Parents didn't mention some "future" or "behind the walls" Apple technology. They said the current bitcode as produced by the current version of XCode on people's laptops now, is the same as LLVM bitcode.

Not sure if that's the case myself (haven't checked) but if so, it has nothing to do with secret access to Apple's future technologies and is easily proven or disproven.

Parents appear to believe just because it isn't available in XCode installed on their Macs today, Apple will never change it tomorrow.

Given that in the past there were features coming to Xcode compilers that only several months later appeared on the open source ones, I don't see why one believes that Apple isn't already preparing something into this direction.

Whatever, I don't care about the downvotes, lets see who is right in a couple of months.

While the conversation is moot, I have tried to use bitcode to target multiple Apple targets. You are correct that bitcode is architecture specific. This makes sense if you start thinking about endianness and how instructions are generated. Inaddition to that, even the default platform address size, e.g. 64 or 32 bit, needs to be encoded.

In fact Apples requirement for submitting bitcode for tvOS and watchOS confounds me, b/c as far as I can tell it only gives them a minor set of instructions that they can actually change. Then on top of that it locks you into their toolchain, see this discussion on Rust around this: https://users.rust-lang.org/t/ios-rust-integration/6928/2

>Inaddition to that, even the default platform address size, e.g. 64 or 32 bit, needs to be encoded.

Isn't that moot, as all platforms used by Apple are 64-bit by now?

I was talking more generally about bitcode limitations. Maybe one day central CPUs will become 128 bits, it would be neat if you could just recompile the bitcode, but that won't work.

There's an architecture neutral close relative to LLVM bitcode: Google's PNaCl.

"PNaCl bitcode is based to a large extent on LLVM IR as of version 3.3" (https://developer.chrome.com/native-client/reference/pnacl-b...)

It's targeting x86, amd64, arm and mips and shipping for a good while. Seems a bit quiet lately though.

>Apple indicates that a new ARM HURRICANE chip family is now supported by the kernel. This is likely a custom ARM chip from Apple as the A7 was dubbed Cyclone, the A8 was Typhoon, and the A9 was Twister. It may even be the A10 Fusion processor found in the iPhone 7.

No need to speculate, the big two cores in A10 are Hurricane (the little two are Zephyr).

Apple is worth 4 times Intel's value ([1], [2]), and also, has 4x more sales. In my opinion, Apple buying TSMC (much smaller than Intel [3]), Panasonic (quite small in comparison, too [4]), and Sharp (tiny [5]), could mean almost complete vertical integration, including CPU, RAM, battery, and display. After that, not only Apple could avoid relying on Intel for desktop processors, but able to drive its margins higher than ever (replacing $300-1000 CPUs with $50-200 own CPUs, controlling even more cutting-edge litography planning, etc.).

[1] http://www.forbes.com/companies/apple/

[2] http://www.forbes.com/companies/intel/

[3] https://en.wikipedia.org/wiki/TSMC

[4] http://www.forbes.com/companies/panasonic/

This has been true for years. It remains unlikely because keeping suppliers independent offers more flexibility – and Apple's buying power already keeps costs low.

Apple could behave like Samsung. Buy the companies, merge them into a hardware fab unit, and then compete in the free market. Fab other companies chips, bid on parts.

Apple is able to outbid Samsung for Samsung made chips.

I can't imagine Apple doing this, for all of the obvious reasons. I absolutely could imagine a more wide-ranging strategic partnership with e.g. TSMC, though – sort of like their enterprise sales tie-ups with IBM and Deloitte.

Sharp was acquired by Foxconn. This was announced earlier this year and the transaction was completed in August. And BTW they will revive the Sharp brand for flatscreen TVs which will run on Alibaba's own YunOS (which translates to cloud OS)...

Thank you.

The fun bit for me (no real pun intended regarding Bitcode) is following the speculation that the delays in upgrading the Mac line might be tied to a switch to ARM at the low end. Would make a lot of sense for Apple to vertically integrate their macOS hardware line as neatly as iOS-based devices, but would kill the Mac as an agnostic development platform (i.e., no more Docker x64 binaries and so on).

Can't say I find that much of a problem these days (VMs are plentiful in the cloud), so the prospect of having thinner, lighter laptops seems a decent trade-off.

I just wish they'd actually fix their bugs, though.

Most of Apple's low end customers probably don't need to run Docker x64 binaries.

Most wouldn't even notice a change I guess, unless they need to install Windows, for example.

Precisely my point, although I didn't quite get to it :)

I think that at least ten poor little rabbits die when someone excuse himself for the pun.

They could have both ARM and x86 chips in their laptops and only spend the extra energy powering on the x86 chip when x86 compatibility is required. They already do this with GPUs in their laptops and they do a similar thing for their CPUs in iPhone 7.

They'd get a big battery life improvement for the typical case once people migrate away from x86-only software, and developers would have an incentive to port to ARM, while people who absolutely need x86 software won't get left behind.

An interesting idea. I know that most of the apps I use on my mac are Apple's, so if they ran on a low power arm cord while everything else was on an x86 core I imagine I'd have significant power savings.

Apple would have to get the GPU vendors to write drivers for their processors though, which would be a tremendous engineering effort. Intel would likely resist any such proposal for their Iris GPUs though, they're having enough of an existential crisis as it is without worrying about one of their largest customers moving away from their main product.

> They already do this with GPUs in their laptops and they do a similar thing for their CPUs in iPhone 7.

They do very different things on those. Both GPUs "speak" opengl/metal/whatever, and both core types of the iPhone 7 speak ARMv8. Handling concurrent ISA in the same machine is a very different problem (early PS3 did it to retain PS2 compatibility, they actually embedded PS2 hardware directly).

Their SDKs (like SpriteKit) have been blurring the lines between iOS and MacOS and I wouldn't be surprised if a new touch screen Mac allowed all iOS apps to run on the desktop. The question is, would that require switching to an ARM processor or adding it as a secondary chip?

From the comments: the iOS and OS X Kernel are shared, so this doesn't mean anything at all.

This is not exactly news as this is being for quite a while now and the code artifacts have been visible as well.

But given Apple's experience with their A-series CPUs it could make strategic sense although it might certainly hurt them on many ends, e.g. possible loss of Bootcamp functionality, inefficient virtualization for VMware or Parallels, loss of many old and loved / needed but unmaintained applications, maybe issues with Docker (?).

Not sure that the developer community (one of their key target audiences) would love to digest this at this point in time (possibly later). We have had this issue already when Apple made the switch from Motorola's 68k to Intel.

So I would give it a 50% likelihood for a switch in the next 12 months but not more at this time.

Apple moved from the 68K to PowerPC and, from there, to x86. Many companies did such moves before: HP from 68K to PA-RISC, Sun, from 68K to SPARC and IBM from the proprietary AS/400 to POWER. All these migrations were very successful.

Yesterday I saw this video about the G5 Mac, which gives a good baseline comparison https://www.youtube.com/watch?v=6SqYMU81l8Y

Now we supposedly have an ARM processor "good enough" to compete with x86 (while consuming several times less power)

The G5 was certainly fast (I'd guess things like video playing wasn't that good because of unoptimized software) but it consumed a lot of power

I owned an iMac G5, and I agree with the relative comparison. The G5 was fast, but the PPC arch was not that efficient, and moving to Intel at the time gave Apple more headroom while lowering their power consumption and thermal profile.

I don't think there's anything fundamentally wrong with the POWER architecture. Just look at IBM today selling POWER8 and POWER9 systems.

For example IBM Watson, which was featured of Jeopardy, was built on a POWER system.

If you look at performance per watt, I don't think the G5 is that far behind the NetBurst architecture Intel was pursuing at the time. Pentium 4 Mobile laptops were absolute beasts to handle the power and cooling needs of the chip. Pentium M laptops used a completely different CPU design which evolved from the Pentium 3 and later became the basis of the Core/Core 2 series of chips.

The main issue for Apple was that IBM couldn't make a processor that could work in a laptop (both for power and cooling reasons), and Motorola/Freescale were seriously behind schedule in shipping a dual core G4. Freescale eventually shipped their dual core in 2007. [1]

So the main reason for Apple's switch was an immediate availability of mobile CPUs (which greatly outperformed the single core G4). The first Apple Intel products actually used the Core Duo, which was actually a laptop part.

[1] https://en.wikipedia.org/wiki/PowerPC_e600

Its a shame that he couldn't get Linux installed on it (I'd guess some HW issue, maybe memory failure). Because I would find it quite surprising that the first gen Intel Mac Mini would really be faster on a level playing field. Just the amount of RAM and beefier GPU should tip the scales for G5.

When my wife worked at Apple Canada we got to borrow a G5 tower from the company demo pool for a bit. Noisiest and hottest computer I've ever worked with. In the summer I could have the AC on full blast and the room I was in with it would be hot. And in the winter it was an effective space heater. And a super noisy fan.

PowerPC always sounded good on paper. But it was definitely a dead end for Apple.

Some rump stump of the Amiga community seems obsessed with PowerPC still for some reason.

It is nice to imagine an alternative timeline in which Apple pivoted directly to ARM instead of to x86 when the switch happened. It was only a couple or three years after the Intel switch that the iPhone came out.

I had a dual-core G5 tower for a while - thing sounded like a jet when booting up.

That's why the laptops never got further than the G4 - the G5s were so hot and power hungry a laptop probably would have melted on the spot.

I wish Apple would bring the aluminium Mac Pro form factor back - it was a beast, but looked great and was as expandable as anything.

"It is striking that developers no longer send the final binaries when submitting an app, but a bit code. This bit code is then used by Apple to convert the application to the specific platform. Which means that Apple can easily make the transition to a different instruction set, for example, switching from x86 to ARM without all apps need to be resubmitted. It is probably also one of the reasons why legacy applications have recently been removed from the App Store."

I guess this is somehow related to the LLVM toolchain. Is now intermediate code submitted and Apple really generates the final one? Can anyone elaborate how this works and how realistic this it is that Apple would generate two/fat binaries?

It has been said that the LLVM bitcode is too low-level and architecture-specific to allow switching between x86 and arm for the final compilation pass that Apple performs in the app store. It's more likely this feature is here to enable hotfixing compiler bugs and micro-optimizations and perhaps taking advantage of new features in new chips within a given architecture.

additional: bitcofe is not used for macOS apps, making this irrelevant.

Having spoken to an LLVM developer about this, unfortunately it isn't quite true (as he understood it).

Essentially, developers submit the LLVM intermediate representation to the App Store. This means that chip-specific optimisations can be made by Apple (such as expanding the number of registers used, or swapping a few small operations for one slightly bigger instruction), however the LLVM IR is already architecture specific, so a change from x86 to ARM would require re-compilation from source.

You assuming Apple doesn't have their own architecture neutral fork.

LLVM used by Apple isn't 100% like the open source project.

Source?

Experience, Apple official compilers aren't 100% equal to what you can download from llvm.org.

For example the set of available optimisation passes, or for a long time not all Objective-C features were available on on the public clang one.

> It is striking that developers no longer send the final binaries when submitting an app, but a bit code

This bit is very expected, along with Arm architecture. It makes sense for Apple to lock down entire ecosystem. It is also terrible if you use Mac to develop anything except iOS/Mac apps, which is what I do. No more windows and half working Linux is not what I need. How long before you can't even compile Obj C or Swift code without going trough app store route?

I don't know if they will do all the steps in a few days or years but I know they will. Also not sure if it will backfire because people need occasional Windows app to run, I suspect huge majority won't care at all.

Lenovo, I know you think I neglected you but I am starting to look your way once again.

Given there are extremely high barriers that are preventing an ARM Mac and very little reason to do it, lets hold off on declaring the Mac dead until they actually do something.

I didn't declare it dead, far from that, it can only grow for the Mac only user population. I said the direction it is going for years does get further from what I need, year over year.

Can you please elaborate what are 'high barriers'?

'Very little reason' - really?

This is the trend of mobile OSes catching up with mainframes.

I guess everyone knows about Android, and on Windows case at least for .NET, version 8.x introduced AOT compilation to native code on the store, which was then improved to .NET Natt in 10.

One day we will have mainframes on our pockets. :)

It's worth noting that there have been discussions about bitcode and ARM in the past, notably ATP 122 and Bitcode Demystified. Both are worth listening to and reading respectively if you're interested in how this stuff works on a low level:

http://atp.fm/episodes/122 http://lowlevelbits.org/bitcode-demystified/

It's not necessarily for a full ARM laptop.

The new MacBook Pro are expected to ship with the Magic Toolbar and TouchID. For the Magic Toolbar it would make sense to allow it to display basic notifications whilst the laptop itself is asleep e.g. remaining battery or current time. For the TouchID it is going to need the secure enclave.

Hence it makes sense to have a dedicated ARM chipset.

You don't need a whole OS for those, especially not a XNU kernel

Indeed, the secure enclave uses its own L4-based SEP OS. According to a Blackhat 2016 presentation ("Demystifying the Secure Enclave Processor"), it's a descendant of the Darbat project.

You would for definitely need to for the Magic Toolbar if it going to be usable whilst the main computer is asleep. It is also going to be touchscreen enabled and need to support CoreGraphics etc. It's very similar to a long, thin Apple Watch.

And for TouchID I imagine it would be easier to lift/shift working platforms from iOS rather than port to OSX.

Yes, you need something for the Magic Toolbar, but I don't believe it is as complex as an Apple Watch

OK so how difficult will it be to convert all the shell tools to ARM? (including Open source tools used under Linux, BSD, etc..)

Am I going to be able to just "make install" for any package I download?

Since it's going to be the Mac, I need the entire XCode development environment there, along with things like Postgres, Python, web servers, etc..

(I don't know what percentage of open source projects have already been converted to ARM architectures...)

I've been running ARM machines for years (since before the Raspberry Pi was cool).

These days I have no trouble running most common Linux desktop software on ARM. Even Docker works (with ARM binaries inside the containers, of course).

I'd say the only sticking points would be graphics/assembly/hardware-related stuff, and all of them surmountable.

I tried setting up a Linux server on a Linksys WRT router a dozen or so years ago, but back then I did notice the open-source ARM binaries weren't widespread. I can't remember exactly for what but I believe I gave up compiling some downloaded code after a while for what I wanted to do.

The user land is based on FreeBSD, which has run on arm for years.

iOS NoUI builds have separate kexts and the full Darwin CLI tools, including the Clang compiler itself.

Note that Darwin was also ported to ARM outside of Apple as a part of the Darwin-on-arm project(##darwin-on-arm in Freenode, source on GitHub).

The differences are arbitrary. Fact: we could be using our iPhones as portable OSX machines, desktop-version-style, right now. It'd also inter-operate pretty well with existing desktop archs too.. If only Apple would let it happen.

Whether or not they ever switch the option of doing so has got to give them a lot more leverage in price negotiations with Intel.

This is known for a while now, hinting that Apple might actually consider building a ARM based MacBook. There is even this hack to run OSX on the iPad Air! [0]

[0]: https://tidbits.com/article/14617

That is horribly fake. It is meant as an April fools joke.

Reply on news.ycombinator.com