[danjoc]

>Is it IBM compatible though?

Man, I hated hearing that question. It was so utterly retarded, but trying to explain to the person who asked why it was a retarded thing to say always came off as damage control.

>Yep, not IBM compatible. Not interested.

Maybe Apple can get away with their own chips now. It sounds like they just want to take more R&D away from Mac though. "Just stick an A10 in it."

[__d]

iOS applications are now compiled to an intermediate representation which is then translated to the target CPU instruction at install time.

macOS applications could similarly be built to run on multiple instruction sets with basically no effort from the developers.

Perhaps initially it might be restricted to first-party apps, or maybe AppStore apps, but having fat binaries is something macOS developers are used to doing ...

The difficult bit would be the runtime migration from x86 to ARM and back. For processes that can restarted, it's easy. For running, stateful applications it would be more difficult.

But I think things like Mail.app already use a backend daemon to manage their datastore: you could suspend the UI process and restart the backend daemon on the low-power CPU fairly simply ...

[chrisballinger]

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

[5ilv3r]

The need for IBM PC compatibility has been dead longer than software sold in boxes. Longer than compaq has been gone. Longer than USB has been a thing. Longer than current CS students have been alive, even!