5 ms·

My bet is it is apple and they are looking for ARM emulation of x86 on new Mac laptops slated for next year. Oops, they are probably referring to Microsoft/Qua

My bet is it is apple and they are looking for ARM emulation of x86 on new Mac laptops slated for next year. Oops, they are probably referring to Microsoft/Qualcomm's announced project here: https://www.extremetech.com/computing/249292-microsoft-declares-windows-10-arm-devices-will-run-x86-code-near-native-speed https://www.extremetech.com/computing/249292-microsoft-decla...

ams6110 9y ago
Why would they need to emulate x86 they can just compile for ARM.
- mattnewton 9y ago
  They have to convince everyone else to as well though. There will need to be a transition period powered by emulation for third parties, similar to Rosetta from the last time they switched architectures.
  - glhaynes 9y ago
    They’d have had a very hard time making the PowerPC -> Intel transition without Rosetta, but I’m not sure they’re in the same position now. How many apps on the average 12” MacBook are no longer maintained or have significant asm in them? I’d guess very few. Start with the MacBook and, over time, as Ax chips become faster and more software gets an ARM64 port, transition the whole line. (Not saying I’d bet on this scenario happening, but it doesn’t seem impossible like making the move to Intel without Rosetta would have been.)
    - MBCook 9y ago
      One of the important things about the Rosetta transition was that the x86 processors were DRASTICALLY faster than the G4s, especially in mobile. The difference wasn't as big on the G5 processors, but if you had an Apple laptop even after running through Rosetta the speed difference was noticeable. If they were to switch processors and it was only (say) 10% faster, the hit from the transition layer may make it a hard sell. Apple has been knocking it out of the park with the A-series processors though, maybe they could make a big enough difference that it would work out again.
      - silvestrov 9y ago
        There is another important difference: there was no GPU back then (and QuickDraw was not very suited to GPUs. OSX changed that). Applications where CPU time was mostly drawing on screen (e.g. text editors) worked a lot better than those where most CPU time was in app code. Today the GPU and graphics code is an even larger amount of the processing. So for a lot of apps it will not be a big problem if the emulation is a bit slow.
- deleted 9y ago
  [deleted]
- ender341341 9y ago
  Apple doesn't have the same control of the app ecosystem on macOS that they do on iOS so they'ed need to maintain some compatibility system like they've done for their previous architecture migrations
- daxelrod 9y ago
  So that users can run all of their existing binaries. Both Mac processor architecture changes so far have included emulation or binary translation layers for this purpose. 68k -> PPC: https://en.wikipedia.org/wiki/Mac_68k_emulator https://en.wikipedia.org/wiki/Mac_68k_emulator PPC -> x86: https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software)
  - ams6110 9y ago
    With NeXT they had "fat" binaries to handle different processors. No emulating.
    - rlanday 9y ago
      That does not solve the problem of existing binaries.
OriginalPenguin 9y ago
Yeah, it probably is Apple. I can't imagine Intel going to war against Microsoft, both sides have too much to lose if they start seriously fighting. It's not called the Wintel monopoly for nothing. But if Apple were to stop buying Intel chips, and start using their own chips in their Macs, Intel could become very litigious.
- wolfgke 9y ago
  > Yeah, it probably is Apple. Did any publicly evidence appear officially or accidentally on the internet that Apple is working on such a project (for Microsoft the situation is known)? I am just a kind of person who prefers strongly to look at the evidence instead of rumors, speculations and hopes.
  - tyingq 9y ago
    Apple is notoriously secretive, so you won't get the evidence you're looking for until such a device is very close to launch.
    - wolfgke 9y ago
      Often evidence leaks beforehand for new Apple products or plans.
    - Q6T46nT668w6i3m 9y ago
      Sure, but some of this can be learned from monitoring LLVM patches and discussion groups (or attending the usual conferences). It's difficult (or impossible) to keep secrets like this from their underlying communities.
      - TheCoreh 9y ago
        Apple has three (iOS, tvOS, watchOS) of their four platforms on ARM, so LLVM patches related to OSX on ARM could probably be plausibly disguised as patches related to these platforms.
  - 9y ago
MBCook 9y ago
Don't forget they just said High Sierra (ug) will be the last version to run 32-bit software "without compromises". In the next version they may run 64-bit clean and use emulation in some sort of Rosetta style environment for "legacy" 32-bit software.
- johncolanduoni 9y ago
  That seems like a pretty bizarre plan to me. The 32-bit emulator is going to be way bigger than the code that handles IA-32e mode. I think it's more likely that they'll reduce the amount of system libraries for which they ship 32-bit variants and/or require separate downloads of them. That's the real cost of keeping 32-bit support, and an emulator doesn't help on that front at all.
  - MBCook 9y ago
    It seems odd, but I wonder if it would be useful in some way. At that point you could buy chips that have no 32 bit mode at all. Or you could MAKE them. Or maybe you could make ARM chips and run a Rosetta like thing to run the 64-bit code, but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess. This is all pure speculation. I thought the way they phrased things with a little odd. It may simply be that they don't intend to update any libraries in 32 bit mode so stuff will just stop working as libraries change. It may be everything's going to start going through some layer that thinks 32-bit calls into 64-bit calls thus possibly reducing performance. I don't know… I just feel like that statement meant something interesting and I am coming up with fun guesses.
    - mikeash 9y ago
      My guess is that the "compromise" will be some fugly alert that pops up when you run a 32-bit app, saying that it's degrading system performance and you should update it and be ashamed of yourself. This is what iOS currently does, so there's precedent.
    - wolfgke 9y ago
      > but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess. I would not call x86-64 "cleaner" than x86-32. In many senses it is much more messy than x86-32.
JustSomeNobody 9y ago
This reads like they caught wind of something that really scares them. I'm in the, "it's probably Apple" camp, too. Not only is Apple doing very well with it's A series chip designs, but they have a ridiculous amount of money in the bank to fight any legal fights.
monocasa 9y ago
x86-> ARM is waaaay more complicated than 68K->PPC or PPC->x86 because of ARM's much weaker memory model than x86. It's borderline a non-starter.

ams6110 9y ago

Why would they need to emulate x86 they can just compile for ARM.

mattnewton 9y ago
They have to convince everyone else to as well though. There will need to be a transition period powered by emulation for third parties, similar to Rosetta from the last time they switched architectures.
- glhaynes 9y ago
  They’d have had a very hard time making the PowerPC -> Intel transition without Rosetta, but I’m not sure they’re in the same position now. How many apps on the average 12” MacBook are no longer maintained or have significant asm in them? I’d guess very few. Start with the MacBook and, over time, as Ax chips become faster and more software gets an ARM64 port, transition the whole line. (Not saying I’d bet on this scenario happening, but it doesn’t seem impossible like making the move to Intel without Rosetta would have been.)
  - MBCook 9y ago
    One of the important things about the Rosetta transition was that the x86 processors were DRASTICALLY faster than the G4s, especially in mobile. The difference wasn't as big on the G5 processors, but if you had an Apple laptop even after running through Rosetta the speed difference was noticeable. If they were to switch processors and it was only (say) 10% faster, the hit from the transition layer may make it a hard sell. Apple has been knocking it out of the park with the A-series processors though, maybe they could make a big enough difference that it would work out again.
    - silvestrov 9y ago
      There is another important difference: there was no GPU back then (and QuickDraw was not very suited to GPUs. OSX changed that). Applications where CPU time was mostly drawing on screen (e.g. text editors) worked a lot better than those where most CPU time was in app code. Today the GPU and graphics code is an even larger amount of the processing. So for a lot of apps it will not be a big problem if the emulation is a bit slow.
deleted 9y ago
[deleted]
ender341341 9y ago
Apple doesn't have the same control of the app ecosystem on macOS that they do on iOS so they'ed need to maintain some compatibility system like they've done for their previous architecture migrations
daxelrod 9y ago
So that users can run all of their existing binaries. Both Mac processor architecture changes so far have included emulation or binary translation layers for this purpose. 68k -> PPC: https://en.wikipedia.org/wiki/Mac_68k_emulator https://en.wikipedia.org/wiki/Mac_68k_emulator PPC -> x86: https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software)
- ams6110 9y ago
  With NeXT they had "fat" binaries to handle different processors. No emulating.
  - rlanday 9y ago
    That does not solve the problem of existing binaries.

OriginalPenguin 9y ago

Yeah, it probably is Apple. I can't imagine Intel going to war against Microsoft, both sides have too much to lose if they start seriously fighting. It's not called the Wintel monopoly for nothing. But if Apple were to stop buying Intel chips, and start using their own chips in their Macs, Intel could become very litigious.

wolfgke 9y ago
> Yeah, it probably is Apple. Did any publicly evidence appear officially or accidentally on the internet that Apple is working on such a project (for Microsoft the situation is known)? I am just a kind of person who prefers strongly to look at the evidence instead of rumors, speculations and hopes.
- tyingq 9y ago
  Apple is notoriously secretive, so you won't get the evidence you're looking for until such a device is very close to launch.
  - wolfgke 9y ago
    Often evidence leaks beforehand for new Apple products or plans.
  - Q6T46nT668w6i3m 9y ago
    Sure, but some of this can be learned from monitoring LLVM patches and discussion groups (or attending the usual conferences). It's difficult (or impossible) to keep secrets like this from their underlying communities.
    - TheCoreh 9y ago
      Apple has three (iOS, tvOS, watchOS) of their four platforms on ARM, so LLVM patches related to OSX on ARM could probably be plausibly disguised as patches related to these platforms.
- 9y ago

MBCook 9y ago

Don't forget they just said High Sierra (ug) will be the last version to run 32-bit software "without compromises". In the next version they may run 64-bit clean and use emulation in some sort of Rosetta style environment for "legacy" 32-bit software.

johncolanduoni 9y ago
That seems like a pretty bizarre plan to me. The 32-bit emulator is going to be way bigger than the code that handles IA-32e mode. I think it's more likely that they'll reduce the amount of system libraries for which they ship 32-bit variants and/or require separate downloads of them. That's the real cost of keeping 32-bit support, and an emulator doesn't help on that front at all.
- MBCook 9y ago
  It seems odd, but I wonder if it would be useful in some way. At that point you could buy chips that have no 32 bit mode at all. Or you could MAKE them. Or maybe you could make ARM chips and run a Rosetta like thing to run the 64-bit code, but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess. This is all pure speculation. I thought the way they phrased things with a little odd. It may simply be that they don't intend to update any libraries in 32 bit mode so stuff will just stop working as libraries change. It may be everything's going to start going through some layer that thinks 32-bit calls into 64-bit calls thus possibly reducing performance. I don't know… I just feel like that statement meant something interesting and I am coming up with fun guesses.
  - mikeash 9y ago
    My guess is that the "compromise" will be some fugly alert that pops up when you run a 32-bit app, saying that it's degrading system performance and you should update it and be ashamed of yourself. This is what iOS currently does, so there's precedent.
  - wolfgke 9y ago
    > but since 64-bit x86 is so much cleaner it's not much of a problem compared to the whole 32-bit mess. I would not call x86-64 "cleaner" than x86-32. In many senses it is much more messy than x86-32.

JustSomeNobody 9y ago

This reads like they caught wind of something that really scares them. I'm in the, "it's probably Apple" camp, too. Not only is Apple doing very well with it's A series chip designs, but they have a ridiculous amount of money in the bank to fight any legal fights.

monocasa 9y ago

x86-> ARM is waaaay more complicated than 68K->PPC or PPC->x86 because of ARM's much weaker memory model than x86. It's borderline a non-starter.