Breakfast Bytes Blogs

You probably already heard that going forward some Macs are going to be running on the Arm-based chips that Apple developed for iPhone and iPads. You probably don't have time to watch an entire day of presentations but here are some highlights of the announcement edited by Endgadget to nine minutes (and you can skip to 1:38 if you like, which is where Tim Cook starts the announcement):

Or if you prefer to read, see VentureBeat's Apple confirms Mac transition to ARM CPUs, Rosetta 2 Intel emulation.

You can find commentary on the implications of this all over the web, and I'm not going to weigh in since I don't have any special insight. But one area where I do have experience is on the question of when there is a switch of architecture, is how you get the old software to run on the new architecture. There are several names for the technology that is used to do this, from virtual platforms to dynamic translation to JIT, which stands for "just-in-time".

Architecture Transitions

As it happens, I was VP Marketing for two companies that developed and sold technology like this: VaST Systems Technology and Virtutech. We were not so much targeting people making an architectural switch in a product as attacking the problem of letting software developers create and debug software for one architecture on another. Usually, this was deeply embedded software than ran inside cars and basestations, often with complex timing issues as in automotive engine control or handling all the call volume on a base station.

If you know your Mac history, you will know that Apple has made this transition twice before. The first Macs were based on the Motorola 68000 architecture. Apple then got together with Motorola and IBM in a project called Somerset based in Austin to develop the PowerPC architecture, and they switched Macs to that. For that transition, they provided a 68000 emulator. Eventually, the responsibility for PowerPC switched entirely to IBM, who was not interested in producing low-power silicon for laptops. Apple switched again, to the Intel x86 architecture. When the iPhone came along, like other smartphones, it used the Arm architecture, and Mac continued to run on x86. At WWDC 2020, just recently, Apple announced that over the next year they would transition some Macs to their Arm chips.

I just noticed on Twitter that Steve Sinofsky, who used to be the manager of Microsoft Windows, says of this (read the whole thread):

Quite simply, what we're seeing is some of the most remarkable product engineering over time in history.

For the switch from PowerPC to Intel, Apple used a technology that they called Rosetta. The name comes from the Rosetta Stone which you can read about in my post The Rosetta Stone and the British Museum. The motivation for that name (as with the language learning company too) is that the Rosetta Stone contains the same text in three different languages, making it possible to decode the two that had been indecipherable until then.

Rosetta was based on technology from a company called Transitive Technology. The CEO of Transitive, Bob Wiederhold said in 2005 (for more details see the CNET article The Brains Behind Apple's Rosetta: Transitive):

We've had a long-term relationship with them [Apple]

I knew Bob since he had been in EDA (and lived on the same street as I did in Los Gatos). He became CEO of Transitive, at the time-based in Manchester UK. He flipped it to have a UK subsidiary of a US-based company. Eventually, IBM acquired them in 2008. IBM had a similar problem, which was how they could take software written to run on Intel, and make it run on their mainframes (360 architecture) and Power servers (Power architecture). By the way, Virtutech ended up being acquired by Intel, just to add to the complexity of the dance.

At WWDC, Apple announced three ways to get Intel software to run on the Arm-based chips. The first is simply to compile it. This requires all the source code to be clean enough, or for parts to be rewritten if necessary. That's not a very interesting solution so I won't explain it anymore, although Apple does have a way of having the compiled code contain both the Intel and the Arm version so that you can create a single binary that will run on either architecture.

The second is that Rosetta 2 can perform translation. When x86 code is run, the instructions (actually a block of instructions at a time for efficiency) are translated to equivalent Arm instructions. There are two ways to do this. One is to translate the whole program once when the software is installed. The other is called dynamic translation or JIT, which is to translate the instructions when they are just about to be executed (hence just-in-time compilation).

When you are doing virtual machines for embedded software development, it is best to do dynamic translation since the next time the program is run, it is likely to have been changed already by the programmer. It is also unlikely that any debug run of the software will run everything, so translating it all is overkill. But for shipping production code, static translation is better. The code will only change when there is a new release. In fact, for embedded development, it is better to do a mixture of interpreting code (just look at the instruction and do it) and do dynamic translation when it turns out the code is being run multiple times. Something we discovered at both VaST and Virtutech was that there are huge amounts of code that only run once when an operating system is booted and an application launched, and it makes no sense to optimize how to run it the second and subsequent times.

Java works like this on the web. At the website end, Java code is compiled into special bytecodes, not instructions for any particular architecture. Then these bytecodes are compiled when needed for the actual architecture that the browser is running on. In the same way, even when a program like a browser has been completely translated, there may still be code coming across the web that has to be dynamically translated. So both techniques will still be required in Rosetta 2.

If you want to run a different operating system, too, such as Linux, then you also need virtualization so that system calls in the guest operating system are handled by the hypervisor. You can read more about that in my post How Does Virtualization Work?

Learn More

See About the Rosetta Translation Environment on the Apple website.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.