Hacker News new | ask | show | jobs
by cwyers 3936 days ago
> 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).

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?)

3 comments

Sort of ignorant and at least a little tangential here, but the notion of 'licensing' an instruction set seems a lot like licensing an API (cf the Java API copyright controversy) - are there parallels/precedents here or is it an unrelated issue?
The Federal Circuit's idiocy in the Oracle case aside, it's well established that copyrights don't cover methods of operation such as APIs or instruction sets. It's also well established that patents do, and that's what ARM licenses. Also they bundle mask works and copyrightable HDL code.
Cool, thanks for responding - what is it about an ISA that makes it patentable where an interface might not be?
Interfaces are also patentable.
It's a curious thing in business. People will do all sorts of things to keep from losing a big customer to a competitor. Some big companies keep multiple vendors and play them off each other. If I don't like you this week I place an order with the other guys.

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.

Intel CPUs have the highest performance per watt when running performance intensive code. The problem was that they could not scale down energy usage enough when performance requirements were very low, such as on mobile devices, and thats what they have been trying to fix for some years.
> 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. [...] I don't see how replacing ARM with a custom ISA helps Apple any.

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.

Apple doesn't use ARM's processor designs. They just license the ISA and design their own CPUs.
True, but the basic point still stands. ISA heavily constrains the final design on-die. ARM might not be able to deliver an ISA that fits Apple's needs.

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