141–150 of 367 posts
Does anyone know the names of the key people behind Rosetta 2? In my experience, exceptionally well executed tech like this tends to have 1-2 very talented people leading. I'd like to follow their blog or Twitter.
I am the creator / main author of Rosetta 2. I don't have a blog or a Twitter (beyond lurking).
Earlier quoted context omitted.
Rosetta 1 had a ticking time bomb. Apple was licensing it from a 3rd party. Rosetta 2 is all in house as far as we know. Different CEO as well. Jobs was more opinionated on “principles” - Cook is more than happy to sell what people will buy. I think Rosetta 2 will last.
> Jobs was more opinionated on “principles” - Cook is more than happy to sell what people will buy. Well, the current "principle" is "iOS is enough, we're going to run iOS apps on MacOS, and that's it". Rosetta isn't needed for that.
This is a great writeup. What a clever design! I remember Apple had a totally different but equally clever solution back in the days of the 68K-to-PowerPC migration. The 68K had 16-bit instruction words, usually with some 16-bit arguments. The emulator’s core loop would read the next instruction and branch directly into a big block of 64K x 8 bytes of PPC code. So each 68K instruction got 2 dedicated PPC instructions…
From what I understand; they purchased a piece of software that already existed to translate PPC to x86 in some form or another and iterated on it. I believe the software may have already even been called ‘Rosetta’. My memory is very hazy; though. While I experienced this transition firsthand and was an early Intel adopter, that’s about all I can remember about Rosetta or where it came from. I remember before Adobe h…
Vertical integration. My understanding was it's because the Apple silicon ARM has special support to make it fast. Apple has had enough experience to know that some hardware support can go a long way to making the binary emulation situation better.
Earlier quoted context omitted.
> If so, does it affect the application startup times? It does, but only the very first time you run the application. The result of the transpilation is cached so it doesn't have to be computed again until the app is updated.
Does that essentially mean each non-native app is doubled in disk use? Maybe not doubled but requires more space to be sure.
This is a great writeup. What a clever design! I remember Apple had a totally different but equally clever solution back in the days of the 68K-to-PowerPC migration. The 68K had 16-bit instruction words, usually with some 16-bit arguments. The emulator’s core loop would read the next instruction and branch directly into a big block of 64K x 8 bytes of PPC code. So each 68K instruction got 2 dedicated PPC instructions…
They licensed Transitive's retargettable binary translator, and renamed it Rosetta; very Apple.
It was originally a startup, but had been bought by IBM by the time Apple was interested.
> Rosetta 2 translates the entire text segment of the binary from x86 to ARM up-front. Do I understand correctly that the Rosetta is basically a transpiler from x86-64 machine code to ARM machine code which is run prior to the binary execution? If so, does it affect the application startup times?
Yes, it does. The delay of the first start of an app is quite noticeable. But the transpiled binary is apparently cached somewhere.
Does anyone know the names of the key people behind Rosetta 2? In my experience, exceptionally well executed tech like this tends to have 1-2 very talented people leading. I'd like to follow their blog or Twitter.
I am the creator / main author of Rosetta 2. I don't have a blog or a Twitter (beyond lurking).
May I ask – would it be possible to implement support for 32-bit VST and AU plugins?
This would be a major bonus, because it could e.g. enable producers like me to open up our music projects from earlier times, and still have the old plugins work.
Earlier quoted context omitted.
> feel like we don’t give them enough credit but maybe they’ve put themselves in that position by not bragging enough about what they do. And maybe also by keeping the technology closed and Apple-specific. Many people who could be interested in using it don't have access to it.
Exactly. As someone who would be very interested in this, but don't use Apple products, it's just not exciting because it's not accessible to me (I can't even test it as a user). If they wanted to write a whitepaper about it to share knowledge, that might be interesting, but given that it's Apple I'm not gonna hold my breath.
Earlier quoted context omitted.
>That's not going to happen unless Apple decides to switch from ARM to RISC-V, and... why would they? They've got 15 years experience and essentially full control on ARM. Two points here. • First off, Apple developers are not binded to Apple. The knkwledge gained can be used elsewhere. See Rivos and Nuvia for example. • Second, Apple reportedly has already ported many of it's secondary cores to RISC-V. It's not unrea…
Apple reportedly has already ported many of it's secondary cores to RISC-V Really? In current hardware or is this speculation?