Apple Said to Work on Mac Chip That Would Lessen Intel Role (opens in new tab)

Yes. In fact, the Newton was the reason ARM was formed as a separate company. The chip design was originally done by Acorn (using VTI tools). When the ARM operation was spun out of Acorn under joint ownership (Acorn, Apple and VTI), they changed the A from Acorn to Advanced.

To be honest I don't know the answer to that. That said, Apple has always had corporate value of being maximally responsible for their own destiny. It's hallmark card wisdom to know the things you can change and accept the things you can't change, but in Apple's case their history has been filled with finding things we can't change and replacing them with something we can. So where one company might say "Well we have to work with what ever the microprocessor company will agree too" Apple wants to say "The microprocessor company will do what ever we require of them." And if they can't find such a company they look at becoming a microprocessor company.

A lot of that thinking was laid out fairly extensively in the lawsuit over manufacturing sapphire they got into. The manufacturer (GT Advanced) complained (reasonably I think) that Apple's contracts were so onerous as to make them employees of the company in everything but name. And that appears to be how Apple likes it, complete control of their destiny when ever possible.

Apple University is one of the things Jobs set up to try and keep Apple fresh:

https://www.nytimes.com/2014/08/11/technology/-inside-apples...

http://www.asymco.com/2011/05/08/codifying-asymmetry-how-app...

At least part of it is that the people aren't coming and going.

When new, key players arrive they're attracted and vetted by the existing community. And that community is well populated with folks that have long tenure.

There are plenty of folks at Apple in key technical positions with 10+ years at the company, and not a few with more than 20.

Apple isn't going down this road again because it's "in their culture", they're doing it because it puts them at an advantage and because they can. Changing the architecture means changes from the silicon level to the application level; it's not so much about engineering talent as it is controlling the entire stack. Still, 30 years later, Apple is the only company that could pull it off.

My guess would be that such specific historical strengths are local manifestations of a more general instinct that is nurtured within a company culture. This instinct would result in similar behaviour when presented with a similar situation — for better or worse.

I also suspect that a company like Apple would have a portion of employees that stick around for the very long term, who have been there since early days and can act as the company's institutional memory.

Specifically in this instance though, it's pretty clear that Apple is going down this road because they've already started going down this road. This is all just straightforward technology and skill reuse: the touch bar is pretty much an Apple Watch in a different package.

I don't believe PA Semi ever had a transferable license to Power. They had their own architecture which was very power efficient and they were a CPU design house with ARM experience (they did StrongARM at DEC). What it looks like from the outside looking in, is that Apple bought out a full architecture license (with derivative ownership) from ARM and bought PA Semi to be the core team to start building CPUs that they had 100% of the rights to.

> would have to wait for application developers to distribute ARM versions.

Or they can switch to their bitcode bundles for Mac apps like the iOS apps and transcode for Intel / ARM on delivery. Plus they have previous form in this area with the "run PPC apps on Intel" via Rhapsody (IIRC.) It'll be a stumbling block, nothing more.

Why so? A Mac is a very high ASP item - why not, for example allow iOS apps to run in macOS (using the ARM processor).

Ultimately, the 2016 MBPs are a great example of why Apple needs to divest from Intel. The poor timing for Kaby Lake mobile processors and lack of low-power RAM were both Apple's reasons stated when the topic of "the MBP isn't keeping up with the competition" arises.

And who's to say that macOS.next will be anything similar to the current macOS?

Is apple divesting its mac offering? Sounds like FUD.

Apple has done many, many things to eke out a couple more hours of battery life. And there has always been a market for those improvements. Same with making thinner cases. it doesn't seem like much, but it sells.

> Apple's de-investment in macOS

Citation needed.

"We love the Mac and are as committed to it, in both desktops and notebooks, as we ever have been."

http://www.independent.co.uk/life-style/gadgets-and-tech/fea...

I don't think we'll see an Arm/x86 hybrid, that wouldn't make sense as they're completely different ISAs and they either need to cross translate between them, or dobble compile everything.

But a heterogenous CPU certainly does make sense. A super efficient, but not particular fast core for specific tasks that are more or less always running, and the beefy full core for regular work. If it eeks out another 2 hours of battery life, I can see Apple doing it when they're redoing a CPU from the ground up.

Actually, eking out another hour or two of battery life at great difficulty sounds exactly like the kind of thing Apple, but few others, would do, if you think about it.

On the other hand, they're commoditizing Intel further and differentiating from the competition.

HP and Dell have gotten smarter and are making better devices. Apple has powerful resources in the ARM space that their competition cannot match -- they are 100% dependent on Intel, who are having issues shipping product.

Either your prove that assertion of "reduced investment" or you retract your comment.

Apple haters...

I mostly agree with this, but I still haven't figured out what the end-game for this might be. I believe that they'd just emulate low-power-requirement x86 and x64 code rather than keeping a low-end x64 chip in the laptop.

If a significant number of MBP customers are running VMWare or Parallels, however, this might seriously hurt the timeline for moving to 100% ARM. In that case they'd either have higher-end Macs with the x64 chips (potentially complicating the product line) or work on adding x64 emulation acceleration to their Ax chip line.

Hope it's less crashy/buggy in the future than my current touchbar :/

That would probably be less power efficient than just running a single core alone at reduced clock.

And the PS3 before it. And the WiiU, and the Wii. And every AMD chip since about 2013 (AMD Platform Security Processor, their equivalent of Intel's ME).

Honestly, pretty much every complex electronic device (and quite a few not so!) out there has a bunch of ARMs inside of it doing system management. This is borderline a non-story IMO.

Hell, an ARM7TDMI was a pretty common core to use on SD cards a few years back. The damn things are everywhere.

Anyone interested in this should watch the CCC talk: https://www.youtube.com/watch?v=-AoHGJ1g9aM

Not really, the ARM in the SB is much more like a ILOM system; not much different from the various processors scattered around hardware these days, be it ARM or some other more niche architecture, or even special-purpose archs.

Both CPUs are connected with a PCI bus and as far as the main SOC is concerned its a bunch of peripherals on PCI

https://media.ccc.de/v/33c3-7946-console_hacking_2016

Thankfully Intel has already done alot of new work in this area - allowing PCI devices (GPU, Xeon Phi) etc, to share computing resources more evenly.

Definitely going to complicate things but it could easily end up worth it for a laptop if it can reduce power usage to almost that of a phone when not doing anything particularly demanding.

Yes, it runs on a "T1" SoC, but the software is a watchOS derivative.

I almost posted that link too, but according to this comment, that product was cancelled and never released because Intel refused: https://www.reddit.com/r/Amd/comments/539kvq/will_amd_cpusmo...

There's still a mention of an expansion card on their site:

https://www.asus.com/us/Motherboard-Accessory/ThunderboltEX-...

But it's only compatible with ASUS motherboards that already have Thunderbolt. So I'm not sure what the point of it is (just to upgrade from ThunderBolt 2.0 to 3.0 maybe?), and as far as I can tell... still requires intel.

So as far as I'm aware, no product has ever released with Thunderbolt that doesn't use an Intel CPU (and even then, only higher-end ones).

Licensing aside, it may be a technical issue - ThunderBolt is an extension of PCI-express, which just isn't part of the ARM design. I'm not sure how feasible it would be to add it.

There will be a Thunderbolt 2 which stays a few steps ahead by then.

People have been saying this since the inception of iOS; given the trajectory of Cocoa vs UIKit, I don't see much sign of this.

It depends on app and developer tool support. Raskell (Haskell IDE for iOS) and Pythonista (Python IDE for iOS) are fun enough to use. While I would really like IntelliJ and RubyMine on my iPad Pro, I really like macOS.

All this said, I like to see completion. There are some very interesting Window 10 hybrid devices, and the new tiltable desktop Surface look interesting. I hope that there is never a 'winner take all' for consumer devices.

afaik there is no ACPI with ARM so it's non trivial to setup an ARM system that has modular hardware as we take for granted in the Intel world. Maybe they went through the trouble and are keeping it under wraps. Or maybe not.

That was actually their product rather than a 'hedge' for a while.

Not just Intel but PA-RISC and Sparc as well, in addition to M68K.

More than that, NeXTSTEP 3.3 and later did really release to the public for Intel x86

Look at what ARM did with AArch64 though: it's backwards compatible via mode switching but is otherwise a fairly clean break at the ISA level.

AMD probably could have done something similar. They just didn't, likely out of risk aversion.

> They tried that, though. It was called Itanium

And the i860, and i960, and i432...

> It was called Itanium and it went nowhere.

It was popular in its intended niche (HPC) for a while, but the value proposition was not sufficient. It dropped some x86 baggage but it didn't add anything fundamentally superior on top of it -- the ILP could easily be attained by having more cores on x86. To be honest I actually really like what they did with Itanium, but it wasn't a good enough innovation to break off the family line of backwards compatibility.

Was the Itanium fiasco more HP or Intel's fault?

Either way, it's been 20+ years they could try again.

It's more then just decode. Segmentation, x87 emulation, and the interaction with other features are all pain points.

> Historically, almost all attempts to replace an enormously successful product line with something incompatible have failed.

Except AArch64, which has a legacy 32 bit mode for compatibility but is otherwise a totally separate ISA, unlike x86-64 and i386.

If AMD hadn't come up with x64, they would have succeeded it.

6502 - 68000

They could,. Unfortunately, it requires a huge investment and needs a lot of highly skilled staff, who are currently working on its mainstream product. Also, when you've done your new chip design, you still have no hardware devices and no software to run on them.

It's taken roughly 40 years to get x86 to its current position, and almost as long to get ARM to its current position. For how many years would you have to invest in a new architecture (ie lose money) before you could compete with them?

AMD has just done a new chip design (Zen) but it's x86-compatible because that's where the software is....

Yes, but this is not specifically what I'm talking about.

Think of something like MS Outlook - it's a big, complex app with lots of features. Now imagine that you only write the app once, but design two interfaces for it - one set for the Mac, and the other for the iPad. You compile through XCode, and upload to the App store. Apple notes that their are interfaces for both iPad and Mac, and posts it in both app stores.

Obviously the mechanics would not be exactly like this (I presume a manifest of some kind), but it should be pretty close.

For Apple, this would bring more developers onto their tooling (yes, even many of those that complain about XCode), and allow more developers to target multiple platforms with little extra effort.

In fact, one of the more interesting things is that Apple could even create new platforms that just require some interface additions and an updated manifest.

Have a bug in your code? One fix. One upload. One code review.

Bitcode allows you to optimize between chip versions with different opcodes, but not different architectures, word sizes, or endianness.

Source: the recent Accidental Tech Podcast that interviewed Chris Lattner.

Intel margins in that single chip are probably a few orders of magnitude of ARM royalties on all those embedded CPUs combined. Intel has little to fear from those chips.

On the other hand, Apple does seem to have the capability to design competitive desktop class CPUs, so who knows.

Rosetta was mostly painless because the raw performance of the Intel chips were multiples of the G4 chips in the macs (especially considering most systems doubled the available core count). Even so Creative Suite was slower as high performance plugins used altivec which was not emulated. This wasn't an issue for compatibility as the G3's never had it, so almost every app had non altivec code paths.

The overhead was mostly acceptable because the performance boost from the chip change hid a lot of it. Not to mention the CISC vs RISC thing worked in Apple's Favour. There are few PPC instructions that were required to be supported that couldn't be covered with a small number of x86 instructions.

There is not a publicly available ARM chip that has single thread performance anywhere near the i5 / i7 chips being used. Add to this the complexity of converting SSE to equivalent instructions and the overheads dealing with edge cases, I am not sure there is much chance of equivalent performance.

The one thing going for Apple with an intel -> arm switch is that almost all major apps a built using Xcode. When PPC -> x86 happened, the apps that lagged the most were the ones stuck on CodeWarrior and other 3rd party IDEs that apple never gave sufficient notice to port in advance of the general announcement (however I will concede that codewarrior was owned by Motorola so it may not have made the jump anyway).

I think if Apple does release ARM based macs, it will be with apps specifically recompiled, not using an emulation layer.

It wasn't that great for Adobe product users.

> engineers with the low-level experience probably are way harder to find than for ARM

Eh, the instruction set doesn't matter that much for modern CPU designers (within reason). Apple's in house expertise came (in part) from their acquisition of P.A. Semi and their PowerPC engineers; Apple it seems immediately redirected them to working on ARM designs. And the Transmeta guys proved that a third party can put out an interesting x86 chip if you can get access to the licenses.

No he means that running x86 legacy mac programs on an arm mac with an emulator as a compatibility shim would be slow. Linux is totally different, because you can clone an entire DISTRO, cross compile it, and have a native arm environment with no compatibility shims slowing things down.

What?

I thought that deal goes both ways, AMD also licensing important parts of AMD64/x86_64 to Intel, so both sides would have a strong interest in keeping it alive in some form.

Is x64 owned by Intel? How much of the x86 stuff would Apple need?

But those weren't both loaded into memory at the same time.

Thinking about this I've convinced myself that what will happen is the ARM core will periodically check for various statuses (i.e. connect to your imap/pop server and see if there is new mail) and turn on an indicator or perhaps wake the intel cores. Which is to say that the powernap/low power functionality will be restricted to either things apple delivers ootb or to a special API. Not as something that automatically migrates whatever workload is running on the powerful intel cores into a slow motion version of the same thing running on the ARM cores.

I believe this is the agreement you're referring to and it looks like it applies even to a change in ownership of 50% of the company:

https://www.sec.gov/Archives/edgar/data/2488/000119312509236...

Please. I buy AMD then Intel loses the 64 licensing rights which AMD owns.

That really sounds like a winning proposition for Apple, given that Intel's own 64-bit arches historically sucked.

That's true, but Intel has as much to lose as AMD if that cross-licensing deal is terminated. So I'd imagine that Intel would want to re-negotiate it with the new party, which is obviously a possibility.

You do realize that amd owns a lot of the x64 patents, not intel, right?

I wonder about the other x86 licenses that have been out there in the past. Via still offers x86 apparently. It looks like Cyrix ended up with Texas Instruments. Transmeta looks messy. IBM used to make x86 chips as well.

And I wonder if any of this relevant to making modern x64 compatible cpus?

You're correct. Here's AMD's statement:

>Advanced Micro Devices has clarified terms of the cross-license agreement with Intel Corp. on Thursday. As it appears, if either AMD or Intel change their control (i.e., gets acquired), the cross-license agreement between the two companies is automatically terminated for both parties.

Since AMD invented x64 this would leave Intel in quite a bind and the only solution would be to work with the new owner to reach an agreement.

bit.LITTLE isn't a mixing of architectures, it's a mixing of micro-architectures. And the fact that big.LITTLE designs are commonly used now, and even Apple adopting their own version of it in their latest SoC is a validation of its benefits.

I don't think that's true. Arm chips just don't clock as high as intels can, and no one* cares about clock speed any more. That ship has sailed. Multiprocess web browsers will drive the sales of massively multicore arms (with tons of ram!), and intel will be sunk.

Mine goes 8 hours with a mainline kernel. I usually charge it once a week. Apple could/would/should do better.

There's always that risk: they'll do some sort of jail like they do with iOS.

From what I understand bitcode is still somewhat architecture dependent and wouldn't work well for ARM<=>x86 translation.