56 ms·

Thanks for explaining. I’m a bit more optimistic on several fronts. For example, Homebrew already has over 200 packages working on both Apple Silicon and Intel

Thanks for explaining. I’m a bit more optimistic on several fronts. For example, Homebrew already has over 200 packages working on both Apple Silicon and Intel. About Rosetta: I think the difference in instructions is overstated. Apple has tons of experience in that, and it shows. If the sheer difference in instructions were the only concern, Rosetta would work 100 % of the time. Examples for actual translation issues in practice: - software that uses JIT but doesn’t meet the Apple Silicon restrictions yet; - software that makes assumptions on virtual memory page sizes; - software that’s (partially) written in x86_64 assembly; - native software that needs a library which is only available on Rosetta, or vice versa. The majority of apps doesn’t fall under those cases though, and most seem to work fine already. Still, all those little special cases add up, and a couple important pieces of software still have a long way to go, such as GCC, OpenJDK, Chrome, and Firefox. So I think you may have a point there about the niche apps. I’m betting on those issues to be solved eventually but what do I know. The points you’ve made do make sense, and I can see how one ends up leaving the platform.

hrishios 6y ago
You're right, and I wasn't talking about getting the instruction coverage right - most software will have some idiosyncracies that will need to be discovered and worked around. Apple, as big as they are, will still need to discover some of these things in prod post release, I would be surprised if they didn't. I'm sure Spotify and Safari and the like will work on launch day, but I'm not too sure about Postico, Disk Inventory X and others. All of this would be fine if I trusted Apple to care about developers and niche users, but I just don't see it.
tbodt 6y ago
3/4 of the practical issues you mention are either not issues or won't be issues on shipped hardware. JIT, page size, and assembly code will all behave the same as they do on x86.
- Hackbraten 6y ago
  JIT is subject to W^X on Apple Silicon, which isn’t a thing on x86. Existing JIT code usually doesn’t respect W^X so it will keep crashing until the app is fixed. Unless fixed, how do you feel it’s ever going to run natively? Not sure what you’re trying to say about assembly. How would a native Apple Silicon app be able to use a library whose source code contains x86_64 inline assembly?

hrishios 6y ago

You're right, and I wasn't talking about getting the instruction coverage right - most software will have some idiosyncracies that will need to be discovered and worked around. Apple, as big as they are, will still need to discover some of these things in prod post release, I would be surprised if they didn't. I'm sure Spotify and Safari and the like will work on launch day, but I'm not too sure about Postico, Disk Inventory X and others. All of this would be fine if I trusted Apple to care about developers and niche users, but I just don't see it.

tbodt 6y ago

3/4 of the practical issues you mention are either not issues or won't be issues on shipped hardware. JIT, page size, and assembly code will all behave the same as they do on x86.

Hackbraten 6y ago
JIT is subject to W^X on Apple Silicon, which isn’t a thing on x86. Existing JIT code usually doesn’t respect W^X so it will keep crashing until the app is fixed. Unless fixed, how do you feel it’s ever going to run natively? Not sure what you’re trying to say about assembly. How would a native Apple Silicon app be able to use a library whose source code contains x86_64 inline assembly?