Apple would not get antitrust approval (iPhone maker controls all android chips????). So that’s why.

Were it a serious enough threat to their ARM license, they'd find a way to buy ARM and keep it independent.

Exactly, Apple is already straddling the line (and imho way past it) on anti-comp laws.

I'm not defending Apple, just thinking that can't we say this for many of the biggest tech firms? They are way past the line on anticompetitive business.

Yes, Apple is not alone in this. Google is another example, and they are very aware of this and are acting very carefully

What is their monopoly or which of their competitors are they colluding with?

Neither of those are required to violate anti-trust laws.

Such as? https://www.ftc.gov/enforcement/anticompetitive-practices

I think Apple is not committed to ARM at all. Bitcode, Rosetta 2, "Apple Silicon" - it all suggests they want to keep ISA flexibility.

Exactly. Apple’s strategy here is very clear:

Offer customers iOS apps and games on the next MacBook as a straight swap for Boot Camp and Parallels. Once they’ve moved everyone over to their own chips and brought back Rosetta and U/Bs they’re essentially free to replace whatever they like at the architecture level.

In their reveal I noticed that they only mentioned ARM binaries running in virtual environments. It makes sense if you don’t want to commit to supporting GNU tools natively on your devices (as it would mean sticking with an established ISA)

I would be quite surprised if LLVM ever lost the ability to compile C for the platform.

Exactly my point though.

Apple is large enough that if they want to break from ARM in the future they can do so by forking an LLVM backend. That's not a large job if it's a very small change, but once it's been done once they have plenty of resources to provide ongoing support (like they do for webkit).

The dividends of doing so are potentially massive. Given that they've been able to make really large gains with the A series chips to date on mobile (not least because they've been able to offload tasks to dedicated co-processors that general-purpose ARM cores don't ship with), the rewards for having chips that are a generation ahead of other like-for-like computers will outweigh the cost of maintaining the software.

Wow, but that cost - it's not a small thing to transition ISA, and don't forget that this transition is one of the simpler ones (more registers, fairly few devices). The risks of transitioning everything away from arm would be much greater.

I guess they have some ISA flexibility (which is remarkable). But not much; each transition was still a very special set of circumstances and a huge hurdle, I'm sure.

At the low-level driver interface, transitioning ISA is a big deal. But I would guess that, at higher levels, most of the work is just changing the target of your compiler?

As in, most of the work occurs in the low-level parts of the Operating system. After that the OS should abstract the differences away from User-space.

No way; not at all.

First of all: there's lots of software that's not the OS. The OS is the easy bit: everything else: grindy, grindy horrorstory. A lot of that code will be third-party. And if you think, "hey, we'll just recompile!", and you can actually get them to too - well, good luck, but performance will be abysmal in many cases. Lots and lots of libraries have hand-tuned code for specific architectures. Anything with vectorization - despite compilers being much better than they used to be - may see huge bog downs without hand tuning. That's not just speculation; you can look at software that's gets the vectorization treatment or was ported to arm from x86 poorly - perfomance falls off a cliff.

Then there's the JITs and interpreters, of which there are quite a few, and they're often hyper-tuned to the ISA's they run on. Also, they can't afford to run something like LLVM on every bit of output; that's way too slow. So even non-vectorized code suffers (you can look at some of the .net core ARM developments to get a feel for this, but the same goes for JS/Java etc). Webbrowsers are hyper-tuned. regexengines, packet filters, etc etc etc

Not to mention: just getting a compiler like LLVM to support a new ISA as optimally as x86 or ARM isn't a small feat.

Finally: at least at this point, until our AI overloads render that redundant - all this work takes expertise, but that expertise takes training, which isn't that easy on an ISA without hardware. That's why Apple's current transition is so easy: they already have the hardware; and the trained experts some with over a decade of experience on that ISA!. But if they really want to go their own route... well, that's tricky, because what are all those engineers going to play around on to learn how it works; what's fast, and what's bad?

All in all, it's no coincidence transitions like this take a long time, and that's for simple (aka well-prepared) transitions like the one's Apple's doing now. Saying they have ISA "flexibility", like they're somehow interchangeable is completely missing the point on how tricky on those details are, and how much they're going to matter on how achievable such a transition is. Apple doesn't have general ISA flexibility, it has a costly route from specifically x86 to specifically ARM, and nothing else.

Extremely aggressive optimizations are really special though, and they tend to require rewrites when new CPU extensions release (and workarounds to work on older hardware). If you rely on super low level ultra-aggressive micro optimizations your code is going to have a relatively short shelf life, different ISA or not.

The vast majority of the code written for any given computer or smartphone doesn't have this level of sophistication and optimization though. I'd wager that for most code just changing the build target will indeed mostly just work.

It won't be painless but modern code tends to be so high level and abstracted (especially on smartphones) than the underlying ISA matters a lot less than in the past.

That's not my experience. Plain old SIMD code ages fairly well - but if you port to a new arch, you will need to look at it again.

This isn't a question of precise instruction timing, it's a question of compilers being pretty bad at leveraging SIMD in general, even in 2020. Also, while I'm sure lots of projects have hand-tuned assembly, even higher level stuff like intrinsics help a lot, and need manual porting.

Absolutely this - even some aggressively optimised stuff like game engines don't have insurmountable amounts of micro optimisations in them.

Also - why would Apple massively up and change uArchs? Even if they did decide to turn Apple Silicon into not-ARM, I'd wager it would look a lot more like ARM than for example, x86 does.

Do it more and more and they'll have the tools to efficiently manage them.

Also likely the small tweaks they will want from time to time should be "easy" to follow internally, if you can orchestrate everything from top to bottom and back.

I doubt Apple is dumb enough not to have basically a perpetual license for ARM.

ARM was launched as a joint venture between Acorn, Apple, and VLSI. I believe that since day 0 Apple had perpetual access to the IP.

They sold all of the ARM shares in mid 90s to prevent themselves from going bankruptcy.

Not to mention starting a JV has nothing to do with perpetual IP access. You will still have to pay for it.

They can certainly have a contract with Arm that allows them to renew their arch license in perpetuity that nvidia won't be able to void.

I obviously don't know that for sure but the idea that Apple would stake their future on something they don't have a legal ironclad position seems unlikely.

I would also agree, the thing is - businesses breakup and come together all the time. If it makes sense and both parties can agree despite of past disagrements and lawsuits, they will partner.

Just because Apple and nVidia has bad relationship at the moment regarding their GPUs is probably orthogonal to what they'll do with this new branch of nVidia, that is ARM.

What need does Apple have with ARMs R&D going forward? They have their own chip designers, build tools, etc.?

True about frenemies the entire time that Apple was suing Samsung, it was using Samsung to manufacture many of its components.

But if your chip heavily builds on arm's IP you need a license for that at least as long as you can't replace the infringing parts of the design. Which sounds very much impossible if you also want to progress on other aspects of having the best chips.

Apple uses the ARM ISA. It doesn't use ARM IP - as in, the design of the chip. Apple designed their own damn chip!

Since they're not branding it as ARM in any way, shape, or form, and they have a perpetual architectural license to the ISA, I suspect they could do pretty much what they please - as long as they don't call it ARM. Which they don't.

During the design were they careful not to create any derivative works of arm IP and/or not to infringe on any of arm's patents?

Apple co-founded the company. I imagine that they have a right to that IP.

Even if not, then yes, I would imagine that a behemoth of IP design like Apple would probably have considered IP rights during that design...

They definitely call it ARM in developer tools and technical documents.

I doubt that will be true going forward. They first used the “Apple Silicon” branding for the Mac and yesterday they used the branding for the Watch and iPad (?)

>Just because Apple and nVidia has bad relationship at the moment regarding their GPUs is probably orthogonal to what they'll do with this new branch of nVidia, that is ARM.

Yea, they got fucked by Nvidia business practices multiple times. There's a saying about shame on you, shame on me, etc. Unless the entire Nvidia business unit also gets replaced in the same transaction, it doesn't matter how much of a faux separation of concerns they want to market.