5 ms·

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 migr

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, typically one to set up a register and one to branch to common code. What that solution and Rosetta 2 have in common is that they’re super pragmatic - fast to start up, with fairly regular and predictable performance across most workloads, even if the theoretical peak speed is much lower than a cutting-edge JIT. Anyone know how they implemented PPC-to-x86 translation?

klelatti 4y ago
That’s really interesting. You might enjoy reading about the VM embedded into the Busicom calculator that used the Intel 4004 [1] They squeezed a virtual machine with 88 instructions into less than 1k of memory! [1] https://thechipletter.substack.com/p/bytecode-and-the-busicom https://thechipletter.substack.com/p/bytecode-and-the-busico...
- hoosieree 4y ago
  And here I was feeling impressed with myself for implementing the Nand2Tetris VM translator in ~2k of python... wow. Respect for the elders!
- iainmerrick 4y ago
  That is nifty! Sounds very similar to a Forth interpreter.
  - deleted 4y ago
    [deleted]
  - DonHopkins 4y ago
    There's also OpenFirmware's platform independent Forth bytecode "FCode": https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware >Open Firmware Forth Code may be compiled into FCode, a bytecode which is independent of instruction set architecture. A PCI card may include a program, compiled to FCode, which runs on any Open Firmware system. In this way, it can provide boot-time diagnostics, configuration code, and device drivers. FCode is also very compact, so that a disk driver may require only one or two kilobytes. Therefore, many of the same I/O cards can be used on Sun systems and Macintoshes that used Open Firmware. FCode implements ANS Forth and a subset of the Open Firmware library.
- wang_li 4y ago
  In the mists of history S. Wozniak wrote the SWEET-16 interpreter for the 6502. A VM with 29 instructions implemented in 300 bytes. https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16
Asmod4n 4y ago
I don't know how they did it, but they did it very very slowly. Anything "interactive" was unuseable.
- scarface74 4y ago
  Interactive 68K programs were usually fast. The 68K programs would still call native PPC QuickDraw code. It was processor intensive code that was slow. Especially with the first generation 68K emulator. Connectix SpeedDoubler was definitely faster.
  - duskwuff 4y ago
    Most of the Toolbox was still running emulated 68k code in early Power Mac systems. A few bits of performance-critical code (like QuickDraw, iirc) were translated, but most things weren't.
- lilyball 4y ago
  Assuming you're talking about PPC-to-x86, it was certainly usable, though noticeably slower. Heck, I used to play Tron 2.0 that way, the frame rate suffered but it was still quite playable.
lostgame 4y ago
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 had released the Universal Binary CS3 that running Photoshop on my Intel Mac was a total nightmare. :( I learned to not be an early adopter from that whole debacle.
- saagarjha 4y ago
  Transitive.
- runjake 4y ago
  Link: https://en.wikipedia.org/wiki/QuickTransit https://en.wikipedia.org/wiki/QuickTransit
kijiki 4y ago
> Anyone know how they implemented PPC-to-x86 translation? 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.
- GeekyBear 4y ago
  > It was originally a startup, but had been bought by IBM by the time Apple was interested. Rosetta shipped in 2005. IBM bought Transitive in 2008. The last version of OS X that supported Rosetta shipped in 2009. I always wondered if the issue was that IBM tried to alter the terms of deal too much for Steve's taste.
  - spijdar 4y ago
    A lesser known bit of trivia about this is that IBM would go on to use Transitive's technology for the exact opposite of Rosetta -- x86 to PowerPC translation, in the form of "PowerVM Lx86", released that year (2008). It's very fascinating to me, since IBM appears to have extended the PowerPC spec with this application specifically in mind. Up until POWER10, the Power/PowerPC ISA specified an optional feature called "SAO", allowing individual pages of memory to be forced to use an x86-style strong memory model, comparable to the proprietary extension in Apple's CPUs, but much more granular (page level and enforced in L1/L2 cache as opposed to the entire core). As far as I can tell, Transitive's technology was the only application to ever use this feature, though it's mainlined in the Linux kernel, and documented in the mprotect(2) man page. IBM ditched the extension for POWER10, which makes sense, since Lx86 only ever worked on big endian releases of RHEL and SLES which are long out of support now. One mystery to me, though, is IBM added support for this page marker to the new radix-style MMU in POWER9. It's documented in the CPU manual, but Linux has no code to use it -- unless I've missed it, Linux only has code to set the appropriate bits in HPT mode, and no reference to the new method for marking radix pages SAO as the manual describes. I can't imagine there was any application on AIX which used this mode (it only decreases performance), and unless you backported a modern kernel to a RHEL 5 userland, you couldn't use Lx86 with the new radix mode. Much strangeness...

klelatti 4y ago

That’s really interesting. You might enjoy reading about the VM embedded into the Busicom calculator that used the Intel 4004 [1] They squeezed a virtual machine with 88 instructions into less than 1k of memory! [1] https://thechipletter.substack.com/p/bytecode-and-the-busicom https://thechipletter.substack.com/p/bytecode-and-the-busico...

hoosieree 4y ago
And here I was feeling impressed with myself for implementing the Nand2Tetris VM translator in ~2k of python... wow. Respect for the elders!
iainmerrick 4y ago
That is nifty! Sounds very similar to a Forth interpreter.
- deleted 4y ago
  [deleted]
- DonHopkins 4y ago
  There's also OpenFirmware's platform independent Forth bytecode "FCode": https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware >Open Firmware Forth Code may be compiled into FCode, a bytecode which is independent of instruction set architecture. A PCI card may include a program, compiled to FCode, which runs on any Open Firmware system. In this way, it can provide boot-time diagnostics, configuration code, and device drivers. FCode is also very compact, so that a disk driver may require only one or two kilobytes. Therefore, many of the same I/O cards can be used on Sun systems and Macintoshes that used Open Firmware. FCode implements ANS Forth and a subset of the Open Firmware library.
wang_li 4y ago
In the mists of history S. Wozniak wrote the SWEET-16 interpreter for the 6502. A VM with 29 instructions implemented in 300 bytes. https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16

Asmod4n 4y ago

I don't know how they did it, but they did it very very slowly. Anything "interactive" was unuseable.

scarface74 4y ago
Interactive 68K programs were usually fast. The 68K programs would still call native PPC QuickDraw code. It was processor intensive code that was slow. Especially with the first generation 68K emulator. Connectix SpeedDoubler was definitely faster.
- duskwuff 4y ago
  Most of the Toolbox was still running emulated 68k code in early Power Mac systems. A few bits of performance-critical code (like QuickDraw, iirc) were translated, but most things weren't.
lilyball 4y ago
Assuming you're talking about PPC-to-x86, it was certainly usable, though noticeably slower. Heck, I used to play Tron 2.0 that way, the frame rate suffered but it was still quite playable.

lostgame 4y ago

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 had released the Universal Binary CS3 that running Photoshop on my Intel Mac was a total nightmare. :( I learned to not be an early adopter from that whole debacle.

saagarjha 4y ago
Transitive.
runjake 4y ago
Link: https://en.wikipedia.org/wiki/QuickTransit https://en.wikipedia.org/wiki/QuickTransit

kijiki 4y ago

> Anyone know how they implemented PPC-to-x86 translation? 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.

GeekyBear 4y ago
> It was originally a startup, but had been bought by IBM by the time Apple was interested. Rosetta shipped in 2005. IBM bought Transitive in 2008. The last version of OS X that supported Rosetta shipped in 2009. I always wondered if the issue was that IBM tried to alter the terms of deal too much for Steve's taste.
- spijdar 4y ago
  A lesser known bit of trivia about this is that IBM would go on to use Transitive's technology for the exact opposite of Rosetta -- x86 to PowerPC translation, in the form of "PowerVM Lx86", released that year (2008). It's very fascinating to me, since IBM appears to have extended the PowerPC spec with this application specifically in mind. Up until POWER10, the Power/PowerPC ISA specified an optional feature called "SAO", allowing individual pages of memory to be forced to use an x86-style strong memory model, comparable to the proprietary extension in Apple's CPUs, but much more granular (page level and enforced in L1/L2 cache as opposed to the entire core). As far as I can tell, Transitive's technology was the only application to ever use this feature, though it's mainlined in the Linux kernel, and documented in the mprotect(2) man page. IBM ditched the extension for POWER10, which makes sense, since Lx86 only ever worked on big endian releases of RHEL and SLES which are long out of support now. One mystery to me, though, is IBM added support for this page marker to the new radix-style MMU in POWER9. It's documented in the CPU manual, but Linux has no code to use it -- unless I've missed it, Linux only has code to set the appropriate bits in HPT mode, and no reference to the new method for marking radix pages SAO as the manual describes. I can't imagine there was any application on AIX which used this mode (it only decreases performance), and unless you backported a modern kernel to a RHEL 5 userland, you couldn't use Lx86 with the new radix mode. Much strangeness...