
An Apple ISA is coming - samps
http://adriansampson.net/blog/appleisa.html
======
legulere
This has been stated before: LLVM Bitcode is architecture specific. It's
dependent on the architectures ABI and can contain inline assembly. There are
LLVM targets with corresponding ABIs that are nonspecific to architectures
like PNaCL but Apple is not using them

Things Apple can do with bitcode: Produce binaries optimized for different ARM
processors. Reoptimize with new versions of LLVM as soon as they are
available. Use a big database of LLVM IR to tweak optimizations. Keep some
optimizations secret and not even publish binaries doing them.

The biggest argument IMO that speaks against an Apple ISA is that they would
have to rewrite tons of hand tuned assembly code.

~~~
3JPLW
Another thing they can do: it allows them to introduce new non-ARM-standard
ops and immediately recompile the app store to take advantage of them.

Every now and then I see a new comparison of the Swift/ObjC dispatch assembly.
Now imagine — that could be a single opcode. Or the dispatch table could get
pinned to a particular cache. Or it could be other micro-optimizations that
they are in a unique position to exploit with full control of the language,
compiler and chip.

I have no idea how feasible these things might be or how much of a gain it
would create, but they can look through their corpus of LLVM-IR and identify
hot-spots where a new opcode would speed _everything_ up by some margin.

~~~
bjackman
Good point, but remember Apple license the ARM architecture from ARM (the
company), and they probably aren't allowed to deliberately ship partially-
compliant ARM hardware.

~~~
azinman2
Apple is much bigger than arm and could easily change the rules.

~~~
gherkin0
They may be smaller, but they have IP Apple needs now. Apple just can't do
whatever it wants to just because it's big.

~~~
azinman2
They could buy arm, or offer enough cash until they capitulate.

------
spiralpolitik
To understand Apple today you have to look to the past. Apple ended up being
stuck with Motorola's inablity to deliver faster PowerPC chips. Whole product
lines were delayed, or not possible. Effectively they gave control on when
they could ship new product to a third party.

10 years later they are now in the same position with Intel. If Intel delays
the next version of its product line by six months then Apple has to put
things on hold. This is bad for a company like Apple as it could cause them to
miss out on potentially lucrative periods (back to School, the Holiday season
etc).

Ultimately I suspect in the very near term we will see Apple move off Intel,
first for the laptops. LLVM IR would fit this strategy better than fat
binaries as Apple would not have to wait until developers recompile. They can
have the entire App Store available on day 1 of a product release.

~~~
tw04
And if a company with as much experience and expertise as Intel misses their
ship dates, what on earth makes Apple think they can do better?

I could see an argument for cutting cost by eliminating the margin that Intel
dictates... but even that assumes that you can find a third party to
manufacture the chips at a rate that is low enough to both cover the IP Intel
has in their chips, and the manufacturing cost itself.

~~~
Tloewald
Well, first of all Apple could do it and fail. They're done that before.
They're confident/arrogant/audacious enough to try things that they can't pull
off.

Also, they could take a two-pronged approach -- cherry-pick talent from Intel,
nVidia, etc. and offer them the opportunity to leapfrog baggage from the past.
How much of the difficulty of moving the x86 platform forward is a result of
the ludicrous amount of cruft? Grabbing a few of the smartest people and
narrowing your focus to an easier problem gets you a long way.

Apple has managed to outpace the entire industry (including Intel) with its
customized ARM cores (getting to 64-bit over a year ahead of everyone, and
take a look at benchmarks between Apple's Ax CPUs and rivals usually running
at far higher clocks with more RAM and sucking more power), and it got there
by cherry-picking talent, omitting stuff it didn't need, focusing on design,
and treating fabs as a commodity.

Looks like interesting times ahead.

~~~
spiralpolitik
Broadwell slipped by several months meaning that Apple couldn't do their
traditional pre Holiday refresh in 2014. I believe the Skylake chipsets that
would allow Apple to switch to using USB-C for the Pros aren't available until
next quarter meaning it's possible that Apple could miss another fall refresh.

Given that the holiday quarter is Apples best season you can probably make
bets that they are at least exploring their options.

------
gchadwick
It is a common theme in computer architecture for someone to say, 'look I have
an awesome new architecture all you need is a clever compiler to make it
work'. None of them really pan out (other than in specific applications, you
could argue GPGPU is as an example, though that appeared more by accident than
by design).

Apple would need a very good reason to produce their own ISA. Sure they like
to do many things in house but they don't do everything themselves. The
resources required to produce and support a whole new ISA are a major
investment, they're only going to do it if in the long run is cheaper than
paying for an ARM architecture license. I just don't see a solid argument that
a custom ISA and shiny new compiler would give them much (if indeed anything).

Whilst they may be shipping LLVM IR for the watch apps rather than ARM code I
think this is just so they can target the compile for a specific processor.
Each one has its own performance quirks and especially in such a power
sensitive environment it would make sense to do specific targetting.

~~~
sklogic
> The resources required to produce and support a whole new ISA are a major
> investment

It's not that hard, really. With such powerful tools as LLVM, a new ISA can
even be designed and implemented with all the tooling by a very small team.

What is hard in all this ISA business is the backward compatibility concerns.
Once you're liberated from this, you're free to do whatever you like. They may
want to experiment with a family of ISAs, maybe entirely incompatible,
targeting different device classes (instead of a single ISA across the range).

Source: experience in the mobile GPUs design.

~~~
MCRed
Apple is basically free of backwards compatilbiitly concerns, since they use
LLVM and Xcode. They have previously required all new apps to be recompiled
for the current version.

It won't be too long before Apps that have not been updated in 2 years start
disappearing from the store-- that's all they'd have to do and the app makers
would comply.

~~~
threeseed
And Apple has a long and reasonably successful history when it comes to
forcing developers to adopt new approaches e.g. PowerPC, Intel, 64-bit, LLVM,
OSX.

------
geoff-codes
I don't think this holds water at all.

The crux of the article is:

> ...one last gap remains in the middle of this stack of system exclusivity:
> Apple licenses the instruction set architecture for its mobile devices from
> ARM.

But Apple already not only designs the own SoCs independently already, they
regularly add their own opcodes to the ARM instruction sets they license, as
they see fit.

The alternative to _not_ licensing from ARM, even if they "invented their own
ISA", would be to pay an exorbitant sum in royalties to ARM _and_ every other
patent-holder whose technology they might dare use in their chip. So paying
ARM for their technology in one go just makes the most economical/legal sense.

------
haberman
It's widely disputed that LLVM bitcode is actually ISA-agnostic. There is a HN
comment quoting Chris Lattner as saying that CPU independence isn't really the
point of bitcode apps (I'd find it now but I'm on mobile). The thought is that
it has a lot more to do with the ability to re-optimize.

~~~
misterdata
I believe it's here:
[https://news.ycombinator.com/item?id=9728162](https://news.ycombinator.com/item?id=9728162)

------
raverbashing
Though the arguments are interesting, I'm not convinced

Sure, the semantic gap exists. But ARM and x86 have evolved and have overcome
a lot of difficulties.

People like to bash x86 but it has a big advantage: it's compact. ARM Thumb is
compact but not so much.

Also remember how big the last 'new ISA' (Itanium) success was?

Compiler and processor front-end beat "perfect ISA" today

~~~
simonh
The reason other ISAs have failed to get traction is compatibility. They
couldn't run any existing binaries, and everyone wanting to use it would have
to develop and adopt new tools. But Apple don't care about interoperability
and completely control the entire software tools and distribution stack from
top to bottom. They don't have to ask anyone else to do anything at all that
they aren't doing already. No previous ISA vendor has even been in that
position. Not even IBM with their mainframes. Furthermore the architecture of
LLVM decouples it from particular processor architectures in ways that
previous compiler architectures didn't, greatly easing the migration process
at a technical level.

But what's the benefit? Maybe a few percent speed/power efficiency boost?
We've already seen that Apple will go to extraordinary lengths for a few
percent improved performance, particularly when it comes to power efficiency.
A few percent here, a few more there and soon you're talking an hour+ extra
battery life.

I think this is highly plausible. There just doesn't seem to be any particular
reason why they wouldn't do it, and plenty of reasons why they would.

~~~
planteen
> Furthermore the architecture of LLVM decouples it from particular processor
> architectures in ways that previous compiler architectures didn't, greatly
> easing the migration process at a technical level.

How is LLVM IR (which I am told is arch specific) different from GCC with RTL?

------
zvrba
> a traditional von Neumann ISA like ARM incurs a semantic gap; the
> architecture wastes time and energy rediscovering facts that the compiler
> already knew.

So thought the designers of Itanium too; it turned out that the compiler
doesn't know _sufficiently_ much for an architecture like Itanium.

Were there any significant advances in compiler technology since then that
would make it worthwhile to experiment with a new ISA?

------
hexscrews
This seems a bit like click bait. It holds no substantial information. They
might as well have summed up the article with, One day, apple will make their
own processor. That's all it says.

~~~
blazespin
To be fair, It says a wee bit more, it says apple has an llvm IR layer and a
semantic gap exists with arm -> so it'll be both easier and necessary to
create their own ISA layer.

I'd really like to know the details behind the semantic gap, though. That was
annoyingly vague and really is the premise of the entire argument.

------
protomyth
I don't think they'll produce their own ISA. They have an architectural
license from ARM, so why bother.

But, Intel doesn't exactly produce chips that are helpful to Apple. Since
Apple switch, Intel has gotten rid of third-party chipsets. This removed a lot
of customization options and basically made life easier for Intel since they
produce a fixed set of chips and you have to take them. Also, Intel's market
differentiation of chip features probably doesn't help.

Apple wants to provide a custom experience, and Apple building their own PC-
class ARM chips will allow that.

[edit: also Intel's paying people to produce Macbook Air clones probably
didn't help]

~~~
dlp211
It will never happen. There isn't an ARM chip out there that could handle the
x86 emulation needed to move off of the platform. The only reason Apple was
able to move off of PowerPC is because they were able emulate the ISA on x86.

~~~
protomyth
I don't think that will be the limiting factor. I can see Apple saying the new
machines will run only newly compiled software.

On that note, I get the feeling Bootcamp for ARM Macs would be interesting
since it would be an ARM version of Windows.

~~~
mrpippy
The last time Microsoft made an ARM version of interactive/desktop Windows
(Windows RT for the Surface/Surface 2), it didn't support legacy Win32 apps
(native or x86 emulated). It was a huge flop; Win32 apps are still the
overriding reason why anyone runs Windows.

And now that Intel has gotten its act together with low-power SoCs, I don't
see desktop Windows coming back to ARM any time soon.

(yes, there is Windows 10 for ARM but only for IoT platforms, it doesn't
support graphical apps)

~~~
protomyth
The Windows RT Surface was a big flop for a lot of reasons. Telling developers
it had an iPad store model when the x86 version didn't was probably a bigger
problem.

------
ChuckMcM
I'm read this wondering if the author had any remembrance or understanding of
the original CHRP/PReP fiasco
([https://en.wikipedia.org/wiki/AIM_alliance](https://en.wikipedia.org/wiki/AIM_alliance)).
That was a painful time for Apple. Given the nature of how ARM operates, and
the fact that Apple has has a full ARM license (so could, at their leisure add
special sauce in the instruction set if needed) that they would do a new ISA,
they already did, x86-64 => ARM. The question for me is whether or not their
desktop/laptop series moves that way or not. I've said for years a 12" MacBook
Air running IOS would put a huge dent in the Chromebook market, and a 12" ARM
based Air running IOS? Well that would be a pretty obvious move to me.

------
rkangel
This article points to another bit of the technology stack that Apple doesn't
own - LLVM IR.

LLVM is open source and therefore doesn't require licensing unlike the ARM
Instruction Set, but it's another thing they don't perfectly control and
they're happy with that.

Developing a new ISA would be extremely expensive, and they'd have to have a
really good reason for doing it. The post doesn't suggest why it would be
beneficial, merely extrapolates a pattern.

~~~
leoedin
According to Wikipedia Apple hired Chris Lattner, one of the original authors
of LLVM, in 2005.
([https://en.wikipedia.org/wiki/LLVM](https://en.wikipedia.org/wiki/LLVM))

So they don't own it, but they do employ some of the most knowledgeable
developers of the project. They almost certainly have control over the
direction it takes, and could easily develop features behind closed doors.

------
tbrock
Apple has owned part of ARM holdings as part of a joint venture between them
and Acorn for decades now. That was one of the first pieces of the widget they
had. Joke is on everyone making phones and servers: you are paying Apple
already.

From Wikipedia:

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

~~~
hajile
Apple sold their remaining stake in ARM back in 2003.

[http://appleinsider.com/articles/13/08/12/iphone-patent-
wars...](http://appleinsider.com/articles/13/08/12/iphone-patent-wars-
apples-11-billion-arm-injection-ignites-a-mobile-patent-race)

------
joosters
I can't see this as a definitive sign that Apple are going to introduce a new
ISA. Instead, this gives them flexibility. They can switch ISAs (e.g. to a new
ARM revision, it doesn't have to be an Apple-specific one though) without
authors having to recompile their code for all platforms. It also allows Apple
to support multiple ISAs without code bloat - the app store can download the
correct binary to your phone, just like they now can send only the correct
size images.

I don't know how abstract the LLVM IR is - can you take IR and compile it to
two wildly different ISAs, (say) x86 and ARM, and get full optimisation on
both? Or is it more limited, e.g. allowing you to compile to ARM version x and
ARM version y (e.g. if version 'y' supports some new SIMD instructions).

~~~
HappyTypist
LLVM converts your input language into the intermediate representation (LLVM
IR) with a frontend. Then, a backend takes IR and spits out code for an ISA.

IR is ISA agnostic. Compiling the same code to x86 and ARM will have the same
IR, it's only the backend step that's different. Thus, of course you can take
IR "meant for ARM" and compile it to "x86" and get full optimisation. The IR
isn't meant for ARM anyway, IR is just IR.

~~~
gchadwick
> Compiling the same code to x86 and ARM will have the same IR

This is incorrect. Clang has specific code paths (producing different IR) for
x86 and ARM, specifically around calling conventions but I'm sure there are
more.

------
clord
I think the Mill team is a good acquisition target for Apple... Apple could
swiftly switch their whole stack over and gain remarkable benefits. I can't
think of another company that would even be able to switch to the mill line.

------
omarforgotpwd
Given the effort put into engineering support for bitcode in iOS 9, it's clear
that the processor's instruction set is definitely going to change at some
point. The only question is when. I wouldn't be surprised if these new
processors were unveiled about 8 and a half hours from now.

~~~
Jerry2
>I wouldn't be surprised if these new processors were unveiled about 8 and a
half hours from now.

I believe that we will see the new processor architecture in the next Apple
Watch, not the next iPhone. I think A9, that will be unveiled later today,
will be an improvement over A8 but it will not be a radical improvement and
will not contain a new ISA. It will have improved ARM cores.

Apple also doesn't require bitcode for iOS apps right now. They suggest you
add them but don't require them. They're required for watchOS apps.

Once Apple starts requiring bitcode for iOS, within a year or two you can
expect some radical Apple CPUs for iPhone/iPad.

------
hajile
Apple doesn't want their own ISA. MIPS was going for a song just a couple
years ago and Apple decided not to buy. That was the best shot they'll have at
their own ISA (they could go with RISCV, but they wouldn't own it).It is my
belief that they got what they wanted by forcing ARM to switch to the ARMv8
ISA.

New microarchitectures take 4 years or so to design. ARM announced the new ISA
in 2011 and didn't have a shippable product until 2015 which is very typical.
All the other implementers (eg. Qualcomm) have also not been able to ship
until now (Qualcomm's custom Kryo doesn't hit until later this year). Apple
shipped a better product in 2013 than A57 is today (ARM doesn't catch up until
A72 later this year). To my knowledge, a licensee had never shipped a new ISA
before the ISA designer up to this point. How did they get a chip designed,
validated, tapped out, produced, integrated, and shipped out in 2 years?

I believe that Apple looked into purchasing MIPS or designing a custom ISA,
but was put off by the costs and headaches associated with moving ISAs (having
already done this with the change from POWER to x86). Instead, they design an
ISA that is incredibly close to MIPS and start implementing a micro-
architecture. Once they reach the stage where they must make a decision about
which ISA, they tell ARM to use their ISA or they will move to MIPS. This
head-start also

ARM is already somewhat threatened by Android having first-class support for
MIPS. Having such a big player switch would be extremely threatening to them.
The result would be an immediate caving. ARM would need to publish the ISA,
but Apple would have a couple year head-start on implementing it (this head-
start also puts Apple in a good competitive position relative to Android phone
manufacturers). The rest is observable history.

This may not accurately represent what really caused this series of events,
but it does explain why Apple got a good chip out before ARM could release a
bad one (ARM couldn't even get a smaller, easier chip out the door). It also
explains why all the other chip companies hint at their surprise at Apple's
early launch.

------
hyperpallium
Getting rid of accumulated cruft would simplify decode logic. Customize it for
iOS. Siliconize common functions.

Apple doesn't have to worry about standards, backcompatibility or adoption. If
they have noticed unneccesary inefficiencies, they can fix them.

------
Tloewald
Very insightful little post. In theory Apple could start evolving their ISA
over time alongside everything else because LLVM gives them an abstraction
layer. (Everyone else could do this too of course.)

------
Quequau
I'm pretty certain that lots of folks here are looking at this from an
unproductive perspective.

Robert Colwell from DARPA presented a talk at HotChips 2013 which was focused
on post 'Moore's Law' technologies and he brings up specialized ISAs.

Looking at the potential of Apple releasing chips with new ISAs from this
perspective seems to me to make a lot more sense (to me at least).

[https://www.youtube.com/watch?v=JpgV6rCn5-g](https://www.youtube.com/watch?v=JpgV6rCn5-g)

------
nikdaheratik
Thought provoking, but I disagree with pretty much every conclusion. If there
is anything they _really_ need they can likely get ARM or Intel to put it in
there, so building an ISA from scratch isn't going to gain them much. It's the
same reason why they aren't going to become a cell-phone carrier even though
that's another part of the vertical stack that they could try to get into: the
cost/benefit makes it not worth it.

------
fulafel
This "get freedom from binary compatibility by shipping binaries as compiler
IR" concept is a venerable one and has been done many times with VLIW
machines:

See here,
[https://scholar.google.com/scholar?hl=en&q=A+Technique+for+O...](https://scholar.google.com/scholar?hl=en&q=A+Technique+for+Object+Code+Compatibility+in+VLIW)

(Not to mention earlier examples like AS/400, P-code etc)

I think the Mill was doing this too?

------
abalone
The key sentence is: "the [current] architecture wastes time and energy
rediscovering facts that the compiler already knew."

If Apple does something here it's going to be for the watch, not Macs. Pushing
the envelope of efficiency for the watch is where it becomes worth it to make
this kind of (otherwise insane) investment. It's also a relatively simpler
stack, so more feasible.

------
dsjoerg
In case you were wondering, like I was:
[http://google.com/search?q=what+is+an+isa](http://google.com/search?q=what+is+an+isa)

------
hitlin37
trying to understand a bit more about bitcode concept. Since a developer
submits a bitcode for apple watch, does that mean he can't optimize his own
app for performance?

FWIK, on android you can still optimize your app at assembly level and i think
that's what motivates developers at times. Remember the iphone camera high
speed shot app, that was hand coded to be fast on iphone.

~~~
monocasa
Bitcode can contain inline assembly still. Additionally, bitcode is
significantly more tied to the target architecture than the author is
assuming.

------
Aissen
We'll see an Apple GPU IP in iPhones/iPads before a new ISA.

------
frozenport
Why didnt Apple just ask authors to submit source code?

~~~
oofabz
Many developers see Apple as a competitor, and Apple has had a long history of
putting their platform's developers out of business. For example, iTunes
destroyed the market for music library software.

------
em3rgent0rdr
LLVM "owned" by Apple? Can't really "own" open-source.

~~~
sklogic
To some extent, it does own it. Ever tried to push even a mildly controversial
patch to LLVM or Clang upstream? If Apple guys are against it, it's a full
stop, no matter how many other parties are interested.

And their reasons to be against a particular patch are often as simple as that
it'll break compatibility with their _internal_ , _unpublished_ changes to
LLVM.

Learned it the hard way...

~~~
7Z7
Chris Lattner is the "Apple guys" now, so..

------
herp_derp
For Apple to develop an ISA they would have to develop a CPU. Something they
don't do inhouse.

Up until now the CPUs have been designed by ARM. Cores like Swift for example
were not developed at Apple, but rather at ARM.

The likelihood of ARM releasing a chip into the wild with a non-ARM ISA is not
all that great, since the ARM ISA is what ARM makes all of its living from.

Until the day where Apple is capable of creating a CPU by themselves there
will be no Apple ISA.

~~~
dagw
_For Apple to develop an ISA they would have to develop a CPU. Something they
don 't do inhouse._

Apple owns PA Semiconductors which employs some of the smartest and most
experienced CPU designers in the business.

