Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I lived through both major Mac CPU transitions (68K-PPC and PPC->X86) and in both cases the assumption was that it was impossible for Apple to ship a usable emulator. In both cases Apple proved everyone wrong and in fact the emulator was a major contributing factor to a smooth transition. It simply takes a lot of time for all 3rd party software to be released for the new architecture.

Given how they handled it in the past my guess is that Apple will release a very usable X64 emulator for the ARM and really brag about it at WWDC.



sort by: page size:

Apple has made two transitions while retaining compatibility, in one case with emulation of the old architecture being around the speed of the previous (68k to PPC) and in the other with emulation being faster than the previous architecture (PPC to x86). There's no ARM that's fast enough to emulate an x86 in the same power envelope, so right now any transition would either require all performance sensitive apps to be ported or would result in machines that were slower for many tasks.

Bear in mind that both previous transitions were due to the processor line Apple was using being effectively EOLed (explicitly in the case of 68k, more implicitly in PPC - nobody was interested in making CPUs that had the appropriate performance/power ratio for consumer machines). Apple is doing great things with ARM, but they're not /that/ far ahead of the rest of the industry that they can pull off a seamless transition in the near future.


This is not happening any time soon and the article is junk. Previous transitions (68K->PPC->x86) occurred when the successor CPU's were so stupidly more powerful than what they replaced that emulation was a plausible tactic.

This is NOT the case with x86->ARM. Apple's ARM chips are impressive and are approaching Intel's chip in some areas if you benchmark in certain ways and ignore the areas where they fall short. I think people underestimate the gap. Maybe one day ARM while be fast enough to make switching worthwhile and emulate x86 acceptably, but it is not this day.

I would say it is more likely that Apple will end up releasing some sort of cross-CPU .NET/JavaVM-esque technology that compiles software locally if they really want to merge the product lines. But I am not even convinced that Apple wants to merge the two lines.


”Apple has proven it can do emulation very successfully - it's already done it twice (M68K->PPC->x86)”

In both cases, from a situation where the platform being emulated was seriously behind, performance-wise.

I don’t think they can maneuver themselves in that position for a x86 ? ARM migration (not even given that they can tweak their ARM variant)

Luckily, I don’t think they would need emulation. Many of their customers don’t run anything else than Apple’s software or popular open source apps that would be migrated within a few days on their Macs.

The others will have to wait until the likes of Adobe have ported their software.


It's not an obvious win like the last couple of architecture switches because of the end of Moore's law. Like the PowerPC chips they were initially using ran 68k code quicker in a non-JITing emulator than any 68k they could buy. They had to switch to a JIT with Rosetta, but that same perf distinction was still true for the high end for PowerPC/Intel during their switch.

Running x86 code faster in an emulator than on a real chip might not ever happen.

And in not too long the x86-64 patents will have expired all the way through SSE4... I think Apple making their own x86 chips is just as likely as switching to ARM.


To imagine that the transition from ppc to x86 is remotely comparable to a present-day x86-to-ARM transition is utterly absurd. Basically everything has changed: Hardware architectures, software architectures, OS design, etc. The amount of software out there for x86 macs is massive and end users are going to expect all that stuff to work (even if they'll grumble and accept it when Apple tells them that only 50% of it will work). You're also having to maintain compatibility with a massive set of third party hardware used by creatives, developers and enthusiasts - are you gonna run those drivers in an emulator? In kernel mode?

This would be an undertaking beyond any past one, because in the past computers were much simpler and Apple controlled a bigger part of the picture. Now they're shipping elaborate GPUs and hardware stacks that mash together chips from various vendors and there's a ton of third party hardware and software all working on top of it. If they don't keep most of that working users won't stand for it. Something like "we need to get AMD or NVIDIA to provide us a top-tier video driver for the Axx instruction set and convince them not to demand a king's ransom for it" would not have been an obstacle in the PPC days but it's unavoidable now unless they want to ship their own GPU too (which they could do, but again, compatibility)


My expectation is that any ARM laptop/desktop made by Apple would include some form of x86 emulation, just like they used during their PPC-x86 and 68k-PPC transitions.

Not to be pedantic, but you could argue it goes all the way to 6502, so they have gone though all these transitions: 6502 -> m68k -> PowerPC -> x86. Added a x86 -> Arm64 transition would hardly be shocking.

EDIT: In case it wasn't clear; there are Apple II emulators for the Macintosh.


People have been speculating for the past year if Apple could switch their Macs to ARM, and keep compatibility with a emulation layer like they did during the PowerPC->Intel transition. I guess Microsoft beat them to the point... Will be interesting to see how well it performs in real life.

I have no doubt ARM will be in mid to high end laptops. I doubt though that the transition will be made emulating x86 apps for most users like it was with rosetta. 75% of Single core benchmarks is likely to become 40% even with a highly efficient emulating layer.

It makes sense to simply make vendors rebuild the app for the new platform then to use an emulating layer.

An emulator may be used for legacy apps, where performance doesn't matter, but apple has never worried too much about legacy in the past, so the mac community won't expect it. All the laptop needs to have is some other killer feature and the community will put enough pressure on the vendors to produce an OSX/arm build of their products.


Both times the new CPU architecture was faster than the older one, granted. But still the emulated software would be slower on the new models with the emulator compared to bare metal execution on the old models.

I assume Apple will make some more improvements to close the gap between x86 and ARM, and switch when it makes sense for them. I also assume that, with the Mac App Store, they will start forcing developers to ship software compiled to both architectures ahead of making the switch. This way, only software that is distributed outside their store would be slow, which is going to become more and more niche as Apple enabled stricter signing enforcement by default in macOS Sierra (by default, only apps from the Mac App Store are allowed to run).


Surprised to see no mention of emulation. Apple has pulled off emulation-based transitions twice before - from 680x0 to PowerPC and from PowerPC to x86 - and nobody else has tried. Why wouldn't we expect Apple to try again?

Given that Apple pulled it off twice with the Mac 68K emulator (for the Motorola 680x0 to PowerPC transition) and on OS X with Rosetta (for the PowerPC to x86 transition), it's certainly possible and ARM processors have come a long way.

Given how smooth Apple's transition from PPC to Intel was, and how much experience Apple has with ARM in their portable lines -- if/when the complete transition to ARM happens it'll probably be a brief blip on everyone's radar and likely increase competition both price and performance-wise in the desktop sector.

What's stopping Apple from adding hardware-level emulation to their SOC's, even if it's only partial functions, to ensure cross-compatibility doesn't take a serious toll on performance? x86 would be patent-encumbered but I'm sure there are a few creative ways to reduce that burden.


> I don't think that Apple will completely get away from x86 for a long time. Attempting to emulate the x86 on an Arm would be terribly slow.

It's not you're emulating an entire operating system: the operating system (and many libraries) are native, but the application code is emulated. It's faster than you think, and Apple has already done it twice: once in 1994, and once in 2005 (exercise for the reader: try extrapolating).

Apple's applications would be 100% native long before the ARM version shipped. Some intensive tasks—text rendering, audio/video/image encoding and decoding, HTML layout, JavaScript—these would also be native on third-party apps, since you just have to write the right glue into the emulator. This would be a lot easier than the 2005 switch from PowerPC to x86, which involved emulating a system with 4x as many GPRs and the opposite endian: ARM has 2x the GPRs as x86-64.

Sure, a bunch of apps will see reduced performance. Some will break. But remember: Apple has only been on x86 for ten years. We had the same problems during the PowerPC->x86 transition: you had to wait about two years to get a version of Photoshop that ran on x86 + OS X.

I'm willing to bet that Apple has been testing OS X on ARM for years now.


It sounds almost unbelievable, but it could happen. I mean, Apple, unlike every other computer company, has successfully transitioned processor architecture twice before (68k to PowerPC, PowerPC to Intel). They could pull the same tricks they pulled for PPC to have a smooth transition: x86 emulation on ARM, “Universal” (fat) binaries, and making it easy for developers to port their apps.

Apple will require CPU emulation to support legacy software releases (think Creative Suite, MS Office, ...); whether this can be done with reasonable performance on ARM is the first real question.

After that, why not make a switch? We (developers) can support ARM just as easily as x86-64, x86-32, and PPC. There are some specific areas that will require rework (games!), but investments are already being made there to support iOS.


Assuming the Apple-designed ARM chip is indeed significantly more performant than the x86-64 chip (there wouldn't be much point to this transition otherwise -- if it was solely about business concerns with Intel, they could use AMD's x86-64 chips instead), they could do an emulation mode of some kind. They could potentially even have some hardware optimizations for it.

Apps like photoshop would still get compiled targeting the new architecture to take advantage of the performance benefits, but other apps could run in emulation mode. Then, over say 3-4 years, most commercial and open-source apps would get updated or be replaced by alternatives.

On one hand, it's weird to use a different CPU than other computers. On the other hand I hate x86 and its complexity and its weird hacks, and it's about time someone ditched it. Although they literally just actually completed the transition to x86-64 a few months ago so it's a bit hilarious they're moving away so soon.


That's not really true. x86 emulation is a solved problem at this point, and Apple has shown willingness to use emulation to bridge an ISA transition in the past.

I think the real reason is some combination of (a) ARM isn't competitive (or only recently became competitive) at the high power/high performance point that Intel CPUs excel at; (b) the Mac line generates so much less revenue and operates at so much smaller of a scale than iOS devices that it isn't worth developing CPUs in-house for them, not to mention the fixed costs associated with undergoing a transition.


The switch to x86 from PPC turned out to be such a ridiculous win in terms of overall performance and compatibility that the community's initial reaction (omg! Nooooo!) was defused.

Apple also did a good job with Rosetta, which they kept around for quite some time. You'll note that Intel has folks that have done binary translation of ARM in an attempt to grab some mobile market share. The same could be done on the x86 => ARM side.

But it only works if the result is fast enough. We're probably still not that close today, but what odds would you take on 5 years? If most of the software folks are writing on macs is for other Apple ARM-based products, it doesn't sound so crazy to emulate x86 for people doing "server" work.

next

Legal | privacy