4 ms·

What I see as more likely is that Apple is hedging it’s bets. On the iPhone / iPad side, they continue to develop better and better processors. One day they _ma

What I see as more likely is that Apple is hedging it’s bets. On the iPhone / iPad side, they continue to develop better and better processors. One day they _may_ be sufficiently better than Intel that Apple could pull a “Rosetta” a second time on the Mac, translating apps from x86 to ARM at the software level. But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing. So in the meantime, it makes sense to push the iPad toward being a stronger and stronger computing platform with things like the recently added trackpad, better multi tasking, etc. They’ve got a way to go, but given a few more years of iteration, who knows how many more of the “real computer” niches the iPad can fill. If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition, and Apple will probably shift it farther upmarket as the iPad cannibalizes every use case that doesn’t need x86. And if the processors do get that much better, then ARM comes to the Mac. Either way, Apple is in a good place to leverage the iPad as their vision of what the next generation of the personal computer looks like.

scarface74 7y ago
But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing. Apple has already done this. The 68K to PPC transition wasn't nearly as quick as the PPC to x86 transition. They released new 68K Macs after releasing PPC Macs. The apps were "fat binary". When I bought my first PPC Mac, all of my apps were on an external SCSI drive. I attached the drive to PPC Mac and it ran native software. If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition, Again it doesn't have to. I had a first generation PPC Mac 6100/60 that ran emulated code slightly slower than my accelerated 68030-40Mhz LCII. My 68K Mac was about half the speed of the high end 68040-40Mhz Macs. It couldn't emulate programs that used the 68040's FPU at all. There were third party hacks that you could run like SoftwareFPU (a 68K program nonetheless) that could emulate an FPU. The high end programs are always the first to be ported. The other apps are "good enough" and depending on how much time an emulated app spends running native operating system code, it won't be all emulated.
- tambourine_man 7y ago
  SoftwareFPU… Aaron… I can still their control panel and extension icons in my mind.
  - scarface74 7y ago
    There was an extension called “No Cigar”. It got rid of Windows animations when you closed a window. It took me forever to realize where the name came from. “Close but no cigar”.
roblabla 7y ago
> Apple could pull a “Rosetta” a second time on the Mac You mean a third time though! The mac went through three architecture transition, and each came with an emulator to keep compatibility for a while. The first one was when they went from Motorolla 68000 to PPC, and they built the Mac 68k Emulator[0] to keep software going. I also think they could pull it off again. Microsoft has shown us that it's possible to run a lot of x86 software on ARM64 with little noticeable impact[1]. It would, however, require immense engineering effort. [0]: https://en.wikipedia.org/wiki/Mac_68k_emulator https://en.wikipedia.org/wiki/Mac_68k_emulator [1]: https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-x86-emulation https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
- ken 7y ago
  If you don't limit the discussion to "Macintosh", Apple had a 4th architecture (and a 3rd 'transition'): 6502. There were third-party software emulators for 6502-on-68K, but Apple only provided a hardware one. https://en.wikipedia.org/wiki/Apple_IIe_Card https://en.wikipedia.org/wiki/Apple_IIe_Card
  - classichasclass 7y ago
    Officially, yes. Unofficially, there was Gus (65816, if you want to be pedantic, though Gus necessarily ran Apple II software as well). https://en.wikipedia.org/wiki/Apple_IIGS#Gus https://en.wikipedia.org/wiki/Apple_IIGS#Gus
wolfgke 7y ago
> One day they _may_ be sufficiently better than Intel that Apple could pull a “Rosetta” a second time on the Mac, translating apps from x86 to ARM at the software level. Emulating x86 on ARM is very hard because x86 has a strong memory model while ARM has a weak one. This either makes emulation very slow or will break lots of multithreaded applications. The other emulation direction (ARM on x86) works much better.
- jlokier 7y ago
  That's true for now. But due to RISC-V's openness, ARM has recently started allowing licensees to add extra features to the architecture. If emulation were taken seriously, Apple could add extra features to their ARM-ISA processors in support of x86 emulation, including x86 compatible implicit memory barriers.
  - doyouevensunbro 7y ago
    Don’t they still have to deal with the fact that Intel has been vocal about suing anyone doing x86 emulation?
    - jlokier 7y ago
      QEMU exists and so do others, and has for many years, so I think x86 software emulation might turn out to be fair game. In fact, out of Intel and ARM, ARM is the only one I know that tried to shut down software emulation... (ARM blocked parts of QEMU from being published for a while, citing "you must have read the manual to implement this therefore you are bound by the terms of the manual". They also had an open source design removed from OpenCores.) It would not be completely silly to modify QEMU with x86 guest and modified-ARM target (for implicit-barrier mode), and then just use QEMU for the emulation. As long as implicit-barrier mode was generic enough I think Intel would have an interesting time claiming it infringed some patent of theirs. Making it efficient would remain Apple's problem but they are good at that. (Or were until the CPU designers left to start Nuvia.) If Intel won that, implicit-barrier would have to be explicit-barrier which is just normal ARM, but there is no fundamental reason why that cannot be fast, if the processor is designed to expect a lot of barriers and optimised accordingly. Especially if a dense instruction encoding is created for it. (Everything I just said applies to RISC-V as well as ARM, should Apple decide to change course again.)

scarface74 7y ago

But that’s still a tall ask at the high end, and splitting the Mac lineup into models that can’t all run the same software isn’t appealing. Apple has already done this. The 68K to PPC transition wasn't nearly as quick as the PPC to x86 transition. They released new 68K Macs after releasing PPC Macs. The apps were "fat binary". When I bought my first PPC Mac, all of my apps were on an external SCSI drive. I attached the drive to PPC Mac and it ran native software. If the processor advantage never reaches the point that it can emulate x86 at full speed, then the Mac line probably won’t transition, Again it doesn't have to. I had a first generation PPC Mac 6100/60 that ran emulated code slightly slower than my accelerated 68030-40Mhz LCII. My 68K Mac was about half the speed of the high end 68040-40Mhz Macs. It couldn't emulate programs that used the 68040's FPU at all. There were third party hacks that you could run like SoftwareFPU (a 68K program nonetheless) that could emulate an FPU. The high end programs are always the first to be ported. The other apps are "good enough" and depending on how much time an emulated app spends running native operating system code, it won't be all emulated.

tambourine_man 7y ago
SoftwareFPU… Aaron… I can still their control panel and extension icons in my mind.
- scarface74 7y ago
  There was an extension called “No Cigar”. It got rid of Windows animations when you closed a window. It took me forever to realize where the name came from. “Close but no cigar”.

roblabla 7y ago

> Apple could pull a “Rosetta” a second time on the Mac You mean a third time though! The mac went through three architecture transition, and each came with an emulator to keep compatibility for a while. The first one was when they went from Motorolla 68000 to PPC, and they built the Mac 68k Emulator[0] to keep software going. I also think they could pull it off again. Microsoft has shown us that it's possible to run a lot of x86 software on ARM64 with little noticeable impact[1]. It would, however, require immense engineering effort. [0]: https://en.wikipedia.org/wiki/Mac_68k_emulator https://en.wikipedia.org/wiki/Mac_68k_emulator [1]: https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-x86-emulation https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...

ken 7y ago
If you don't limit the discussion to "Macintosh", Apple had a 4th architecture (and a 3rd 'transition'): 6502. There were third-party software emulators for 6502-on-68K, but Apple only provided a hardware one. https://en.wikipedia.org/wiki/Apple_IIe_Card https://en.wikipedia.org/wiki/Apple_IIe_Card
- classichasclass 7y ago
  Officially, yes. Unofficially, there was Gus (65816, if you want to be pedantic, though Gus necessarily ran Apple II software as well). https://en.wikipedia.org/wiki/Apple_IIGS#Gus https://en.wikipedia.org/wiki/Apple_IIGS#Gus

wolfgke 7y ago

> One day they _may_ be sufficiently better than Intel that Apple could pull a “Rosetta” a second time on the Mac, translating apps from x86 to ARM at the software level. Emulating x86 on ARM is very hard because x86 has a strong memory model while ARM has a weak one. This either makes emulation very slow or will break lots of multithreaded applications. The other emulation direction (ARM on x86) works much better.

jlokier 7y ago
That's true for now. But due to RISC-V's openness, ARM has recently started allowing licensees to add extra features to the architecture. If emulation were taken seriously, Apple could add extra features to their ARM-ISA processors in support of x86 emulation, including x86 compatible implicit memory barriers.
- doyouevensunbro 7y ago
  Don’t they still have to deal with the fact that Intel has been vocal about suing anyone doing x86 emulation?
  - jlokier 7y ago
    QEMU exists and so do others, and has for many years, so I think x86 software emulation might turn out to be fair game. In fact, out of Intel and ARM, ARM is the only one I know that tried to shut down software emulation... (ARM blocked parts of QEMU from being published for a while, citing "you must have read the manual to implement this therefore you are bound by the terms of the manual". They also had an open source design removed from OpenCores.) It would not be completely silly to modify QEMU with x86 guest and modified-ARM target (for implicit-barrier mode), and then just use QEMU for the emulation. As long as implicit-barrier mode was generic enough I think Intel would have an interesting time claiming it infringed some patent of theirs. Making it efficient would remain Apple's problem but they are good at that. (Or were until the CPU designers left to start Nuvia.) If Intel won that, implicit-barrier would have to be explicit-barrier which is just normal ARM, but there is no fundamental reason why that cannot be fast, if the processor is designed to expect a lot of barriers and optimised accordingly. Especially if a dense instruction encoding is created for it. (Everything I just said applies to RISC-V as well as ARM, should Apple decide to change course again.)