An Apple ISA is coming(adriansampson.net) |
An Apple ISA is coming(adriansampson.net) |
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...
Having exclusive rights on a strategic business brick is important when this brick is enough to give someone else a stronghold on the whole vertical market. Although having a good compilers is one of the many requirements in Apple's business model, it's neither the defining feature, nor what competitors miss in order to threaten Apple.
So yes, in this context, Apple non-exclusively owns LLVM.
Open source doesn't mean the process is collaborative. It just means the code is available for you to use, modify and fork. There are numerous open source projects (mostly those sponsored by companies) for which you would never be able to change the direction of.
Look at Node/IO for how things would need to work.
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.
Apple owns PA Semiconductors which employs some of the smartest and most experienced CPU designers in the business.
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.
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.
But I believe we're (hypothetically) talking about ARM, not x86, code.
They do indeed support LLVM IR target(s) that are, in fact, much more architecturally-nonspecific than PNaCl, namely the spir[64]-unknown-unknown target. See https://github.com/KhronosGroup/SPIR and /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/openclc (on a Mac, since 10.7).
I don't know if bitcode with this target triple is necessarily suitable for the Apple Watch, however.
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.
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.
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.
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
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?
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.
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]
On that note, I get the feeling Bootcamp for ARM Macs would be interesting since it would be an ARM version of Windows.
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.
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.
Hmm, I saw the "LLVM owned since ~2005". What exactly does the article mean by "owned"?
Perhaps, Apple owns it in the same way that all of us do, or perhaps the article just needs a little more work.
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."
http://appleinsider.com/articles/13/08/12/iphone-patent-wars...
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).
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.
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.
It's absolutely ISA specific and this target independence pipe dream keeps being repeated on HN. Just search the LLVM documentation for "target specific."
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.
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.
Apple doesn't have to worry about standards, backcompatibility or adoption. If they have noticed unneccesary inefficiencies, they can fix them.
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).
See here, https://scholar.google.com/scholar?hl=en&q=A+Technique+for+O...
(Not to mention earlier examples like AS/400, P-code etc)
I think the Mill was doing this too?
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.
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.
This article isn't about laptops, though. It's about ARM. Apple isn't dependent on anyone for ship dates in the ARM space -- they license the ISA, but they design their own chips based on the license. Yes, they're reliant on Samsung to fab the things, but Apple doesn't need their own ISA if they want to use their own fabs. I don't see how replacing ARM with a custom ISA helps Apple any.
(As for Intel -- it's not like Intel's other customers don't have the exact same sales periods that Apple does. So they're motivated. As others have said, if Intel slips deadlines like that, who's to say Apple has the ability to meet them where Intel couldn't?)
Intel's weak spot has always (or at least often) been mips per watt. Apple has a whole slew of products in the ultraportable niche and given their focus could easily have more.
If a custom ARM-like chip gives them the option to stop using Intel chips on everything but the MacBook Pro line, that would be worth a lot to them, even if they continued to use Intel chips on those devices. Just the threat gets them concessions.
Well, what if the time comes when ARM cannot deliver processor designs with necessary improvements to power consumption or processing speed? If they hit that wall, a new processor architecture might be the only way forward.
Given Apple's resources and position, that kind of contingency planning makes sense to me. You can't exactly spin up a architecture design team overnight.
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.
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.
Intel has other clients who may be just as noisy about their own ship dates. They make custom processors for AWS, as an example. An Apple-owned subsidiary/division would have Apple as its sole priority.
A decade of shipping millions of products that depend on very complicated supply chains on time and to great profit?
Switching to Intel guaranteed that they worst-case will always be on par with their competition. They'd lose that if they switch away to custom built silicon.
Now if ARM would start to make serious inroads in the Laptop/Desktop market that might change. But then again, thanks to P.A. Semi Apple has more than enough ARM knowledge already.
Intel is better than ever at the power-performance game, despite suffering badly from ARM. The performance gap is huge. Their current position is the result of a continuous sequence of design success and R&D reinvestment that started with Pentium M more than 10 years ago.
If anything, I expect Intel to finally start breaking into the phone market as they catch up on SoCs.
I think they are well prepared for every eventuality, but currently Intel’s and Apple’s interests are pretty well aligned.
Basically we are seeing a race towards a common goal from two directions here, though: Can Intel hit the low power goals (with sufficient performance) before Apple hits their performance goals (at low power) through some alternate route? Honestly, I don’t see Apple being able to touch Intel’s performance and with regards to power use Intel is getting better all the time. The space for ARM-like laptop chips is getting smaller by the day.
And Intel actually wants to hit that low power! It’s not like they are disinterested in that (like IBM being disinterested in making the CPUs Apple needs back in the day because they were making their money elsewhere and Apple was just a small, unimportant customer of them, not worth all the effort), they are working on that all the time.
That’s what I mean when I say their interests are aligned. I mean, I obviously think that Apple is always on the lookout for alternatives (and they have been through many such transitions by now, so I’m very confident that they would be able to pull it off), but I honestly think they would prefer their and Intel’s interests to remain aligned and Intel just making some kick-ass low-power CPUs, exactly what they need for their future retina resolution, light-weight, super-thin, all-day battery life, fanless MacBooks.
If they do this, it will be for it's ARM products, iPhone, iPad, iPod touch & AppleTV.
As for the dark days of Apple in the PC market and the deaths of Commodore and Atari, my recollection is that it had more to do with the stock market crash of 1987 tightening access to capital and the S&L crisis that followed it creating a recession where downsizing was what corporations not empty-nesters did.
- Apple has proven they can switch out hardware stacks, so that part seems straight forward enough. Especially given how mature XCode is.
- But: can they really get to a point where they complete with Intel directly? Would they try and use ARM or roll their own ADM64?
Apple/NeXt has much experience with technical challenge of porting entire platforms to different processors and with the business challenges of being tied to critical technologies you do not control.
Well this is exactly the point. They cannot do this the license will not permit them to alter the architecture it's all or nothing (indeed if the new ISA was too ARM like the lawyers would be sure to come knocking).
I'm sure the could reuse quite a lot of compiler technology but the entire point of the article is by doing clean slate ISA design you can do something radical and get gains. Whether this is true is unclear, but it would require some serious work on the compiler.
Producing their own conventional ISA would seem to be pointless as it wouldn't give them anything vs ARM (or indeed x86).
I think it's pretty much a no-brainer for them to at least try. They have so much cash available that spending a few billion dollars on a moonshot has little downside and crazy potential upside.
When they push Intel to advance on some front, those benefits are enjoyed by Apple competitors as well. If Apple brings it all in-house, they can try to stay a generation ahead of Intel. With the amount of money they have to throw at the problem, they could starve Intel of some key talent and hurting Intel will hurts Apple's competitors.
Edit:
We'll hurt everyone, maybe even ourselves.
Apple has absolutely control on anything and everything that would run on this thing, I don't think it is about paying licenses to Arm. When you have almost infinite money, in long term having a leaner/ faster / more efficient custom ISA is better and lucrative than depending ARM or Intel for innovation. They can make it run existing applications with a transformation layer (already done by Nvidia/Transmeta mentioned elsewhere in this thread) So, I don't see why not.
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.
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.
The Mill team defines their ISA and encoding manually, and then programmatically generates the compiler, assembler, linker, and entire toolchain.
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.
How is LLVM IR (which I am told is arch specific) different from GCC with RTL?
Remember the transition from VAX to Alpha? And they kept the binary and source compatibility in quite an inventive way (with both binary translation and by making MACRO32 just another high level language).
Margins is the only important thing for Apple, nothing else matters.
x86-64 isn't. I've measured this: the average instruction length is just about 4 bytes. REX prefixes add up quick.
Given that the holiday quarter is Apples best season you can probably make bets that they are at least exploring their options.
I'd prefer a 6809 with a wider address bus over a 68000. I wish Motorola had improved on the 6809 rather than having two competing architectures. The 6809 is a joy to code for.
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)
I've never seen anything quite like it since. About the closest I've seen is the way that Thumb code can be integrated with native ARM code, and that's explicitly just a different instruction encoding, rather than a separate ISA.
So apple was working with something north of 3x the raw performance, its no wonder that most people with older macs that weren't anywhere near the performance of the 840AV thought the powermac was incredible.
Wiki for QuickTransit seems to think that a number of prominent people from Transitive hopped to ARM and Apple (which might be telling, given the claims of the original post), but has no citations.
Apple already has a tweaked version of ARM (ARMv7s) [1]. There may come a day where tweaks no longer cut it. At the end of another excellent post, from the same author [2]:
> If compiler–architecture co-design is on the table, much more radical opportunities are available.
Apple has both compiler and architecture teams. And if it sees ties to a specific architecture hurting its product development goals again? It seems like exactly the kind of company that would drop the ARM ISA completely.
Or at least like the kind of company that wants to keep that option on the table.
[1] http://www.linleygroup.com/newsletters/newsletter_detail.php... [2] http://adriansampson.net/blog/macroscalar.html
Granted, Intel's supply chains probably aren't nearly as difficult as Apple's, but the supply chain is probably the least difficult part of shipping the next generation of a chip.
In my opinion it was mainly Steve Jobs who was brilliant telling people what they want. So I personally doubt whether this strategy still works with Tim Cook as CEO.
People are already using incredibly low power/perf laptops (new MacBook).
I'm not convinced anyone doing content consumption would notice if the chip swapped out for an ARM instead. After all, ARM's already power their content consumption devices (all of iOS)
I'd be sad if my upgrade path became some big, noisy, inelegant HP Xeon box.
I don't think that's as big of an issue with modern processors:
https://wiki.debian.org/Microcode:
> Processors from Intel and AMD may need updates to their microcode to operate correctly. These updates fix bugs/errata that can cause anything from incorrect processing, to code and data corruption, and system lockups.
x86-32 doesn't have nearly enough register names, causing totally unnecessary memory spills, which the hardware was never good enough to hide, and having to pass arguments on the stack. That's why x86-64 is faster than -32, even though 64bit wastes so much cache space.
And some instructions are just randomly slow because of handling the weird encoding, like 16-bit math is slower than either 8-bit or 32-bit math.
Then there's eflags, but that's a minor complaint.
Other than booting it, and EFI is addressing that, it's a fairly clean and nice architecture. Some of the registers have legacy names. Are there any really odd legacy behaviors?
Your assertion that their license will not permit them to alter the architecture is wrong. This is true of the vast majority of ARM licenses, but not Apple's.
They can take the ARM ISA and extend it in any way they want, and they can take ARM cores and adjust them, or design their own-- they have already done all of this (though to a small degree, not enough to be called a "new ISA".)
> They can take the ARM ISA and extend it in any way they want, and they can take ARM cores and adjust them, or design their own-- they have already done all of this (though to a small degree, not enough to be called a "new ISA".)
What is your source for this? As far as I know ARM do not permit modification of the designs they sell or alterations to the architecture. After all allowing such things could lead to the errosion of their business (e.g. by letting apple slowly slide to a non ARM architecture).
Wikipedia:
"Companies can also obtain an ARM architectural licence for designing their own CPU cores using the ARM instruction sets. These cores must comply fully with the ARM architecture."
Can you give a reference for that? As far as I know, Apple has an architectural license that allows them to ship anything that passes a test suite. Depending on the way the test suite is specified, that may not rule out shipping a superset of ARM, for example with a few extra instructions.
One that I _think_may_ be useful is one to load values from tagged pointers (caveat: I know little of CPU architecture)
I can't find one actually, so perhaps I am wrong. If it strictly based upon the test suite then maybe it's sufficiently thorough that interesting alterations are effectively impossible (e.g. it could test you get invalid instruction exceptions when you feed in unused bits of instruction encoding space, preventing you from adding any).
It has two extra integer division instructions and some extra floating point. Though the blog says that the extra floating point instructions are also present in ARMv7 (in XCode) but unused.
So perhaps they're allowed to add whatever they want? I suspect only the lawyers truely know...
What is pretty certain is they couldn't break compatability with the ARM architecture.
Given the lego-like structure of the ARM instruction set (the 32-bit variant), with zillions of extensions (Jazelle, DSP instructions, Neon, Thumb, Thumb-2, various revisions of vector floating point instructions) and explicit support for "coprocessors" (https://en.wikipedia.org/wiki/ARM_architecture#Coprocessors), I suspect (based on common sense and nothing else) that the license allows expanding the instruction set and dropping whole modules.
But as I said elsewhere: concrete proof for that is lacking.