
Apple Adds ARM Support to MacOS Sierra Kernel - rcarmo
http://www.iclarified.com/57138/apple-adds-arm-support-to-macos-sierra-kernel
======
0x0
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...](http://opensource.apple.com//source/xnu/xnu-3248.60.10/osfmk/mach/machine.h)

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

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

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

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

~~~
ksec
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.

~~~
jquast
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

------
madeofpalk
> _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.

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

~~~
masklinn
> 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.

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

~~~
masklinn
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.

~~~
pjmlp
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.

~~~
madeofpalk
> 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.

~~~
pjmlp
Keep hoping.

------
mappu
_> 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).

------
faragon
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/](http://www.forbes.com/companies/apple/)

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

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

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

~~~
gilgoomesh
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.

~~~
basch
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.

~~~
culturestate
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.

------
rcarmo
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.

~~~
JimDabell
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.

~~~
masklinn
> 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).

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

------
oger
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.

~~~
rbanffy
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.

------
raverbashing
Yesterday I saw this video about the G5 Mac, which gives a good baseline
comparison
[https://www.youtube.com/watch?v=6SqYMU81l8Y](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

~~~
cmrdporcupine
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.

~~~
mattkevan
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.

------
heisenbit
"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?

~~~
danpalmer
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.

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

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

~~~
LaSombra
Source?

~~~
pjmlp
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.

------
Shank
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://atp.fm/episodes/122)
[http://lowlevelbits.org/bitcode-
demystified/](http://lowlevelbits.org/bitcode-demystified/)

------
threeseed
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.

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

~~~
threeseed
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.

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

------
mozumder
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...)

~~~
rcarmo
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.

~~~
mozumder
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.

------
my123
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).

------
fit2rule
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.

------
Symmetry
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.

------
dvcrn
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](https://tidbits.com/article/14617)

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

