2 ms·

> Apple's historically been pretty good at making this stuff. Their first 68k -> PPC emulator (Davidian's) was so good that for some things the PPC Mac was the

> Apple's historically been pretty good at making this stuff. Their first 68k -> PPC emulator (Davidian's) was so good that for some things the PPC Mac was the fastest 68k mac you could buy. Not arguing the facts here, but I'm curious—are these successes related? And if so, how has Apple done that? I would imagine that very few of the engineers who programmed Apple's 68k emulator are still working at Apple today. So, why is Apple still so good at this? Strong internal documentation? Conducive management practices? Or were they just lucky both times?

manv1 4y ago
I suspect that there's a design document somewhere that has secrets and tips. Plus MacOS and NeXTstep have been ported so many times that by now any arch-level things are well-isolated. A lot of the pain of MacOS on x86 were related to kernel extensions and driver API changes. And a lot of stuff fell out during the 64-bit transition. In general, MacOS/iOS/iPadOS owe everything to the excellent architecture laid down by the NeXT team back in the day. NeXTstep now has the dream that MS tried and failed to do back in the day: an OS that runs on every kind of device they make. Funny how that is.
joshstrange 4y ago
I mean they are one of very few companies who have done arch changes like this and they had already done it twice before Rosetta 2. The same engineers might not have been used for all 3 but I'm sure there was at least a tiny bit of overlap between 68k->PPC and PPC->Intel (and likewise overlap between PPC->Intel and Intel->ARM) that coupled with passed down knowledge within the company gives them a leg up. They know the pitfalls, they've see issues/advantages of using certain approaches. I think of it in same way that I've migrated from old->new versions of frameworks/languages in the past with breaking changes and each time I've done it I've gotten better at knowing what to expect, what to look for, places where it makes sense to "just get it working" or "upgrade the code to the new paradigm". The first time or two I did it was as a junior working under senior developers so I wasn't as involved but what did trickle down to me and/or my part in the refactor/upgrade taught me things. Later times when I was in charge (or on my own) I was able to draw on those past experiences. Obviously my work is nowhere near as complicated as arch changes but if you squint and turn your head to the side I think you can see the similarities. > Or were they just lucky to have success both times? I think 2 times might be explained with "luck" but being successful 3 times points to a strong trend IMHO, especially since Rosetta 2 seems to have done even better than Rosetta 1 for the last transition.
spacedcowboy 4y ago
FWIW, I know several current engineers at Apple who wrote ground-breaking stuff before the Mac even existed. Apple certainly doesn't have any problem with older engineers, and it turns out that transferring that expertise to new chips on demand isn't particularly hard for them.
- Wowfunhappy 4y ago
  > Apple certainly doesn't have any problem with older engineers Just to be clear, I never meant to suggest that they did—I just didn't realize employees remained with the company for that long, instead of switching.

manv1 4y ago

I suspect that there's a design document somewhere that has secrets and tips. Plus MacOS and NeXTstep have been ported so many times that by now any arch-level things are well-isolated. A lot of the pain of MacOS on x86 were related to kernel extensions and driver API changes. And a lot of stuff fell out during the 64-bit transition. In general, MacOS/iOS/iPadOS owe everything to the excellent architecture laid down by the NeXT team back in the day. NeXTstep now has the dream that MS tried and failed to do back in the day: an OS that runs on every kind of device they make. Funny how that is.

joshstrange 4y ago

I mean they are one of very few companies who have done arch changes like this and they had already done it twice before Rosetta 2. The same engineers might not have been used for all 3 but I'm sure there was at least a tiny bit of overlap between 68k->PPC and PPC->Intel (and likewise overlap between PPC->Intel and Intel->ARM) that coupled with passed down knowledge within the company gives them a leg up. They know the pitfalls, they've see issues/advantages of using certain approaches. I think of it in same way that I've migrated from old->new versions of frameworks/languages in the past with breaking changes and each time I've done it I've gotten better at knowing what to expect, what to look for, places where it makes sense to "just get it working" or "upgrade the code to the new paradigm". The first time or two I did it was as a junior working under senior developers so I wasn't as involved but what did trickle down to me and/or my part in the refactor/upgrade taught me things. Later times when I was in charge (or on my own) I was able to draw on those past experiences. Obviously my work is nowhere near as complicated as arch changes but if you squint and turn your head to the side I think you can see the similarities. > Or were they just lucky to have success both times? I think 2 times might be explained with "luck" but being successful 3 times points to a strong trend IMHO, especially since Rosetta 2 seems to have done even better than Rosetta 1 for the last transition.

spacedcowboy 4y ago

FWIW, I know several current engineers at Apple who wrote ground-breaking stuff before the Mac even existed. Apple certainly doesn't have any problem with older engineers, and it turns out that transferring that expertise to new chips on demand isn't particularly hard for them.

Wowfunhappy 4y ago
> Apple certainly doesn't have any problem with older engineers Just to be clear, I never meant to suggest that they did—I just didn't realize employees remained with the company for that long, instead of switching.