About the Rosetta Translation Environment • Hacker News Board

Re: About the Rosetta Translation Environment

#221

Post by gsnedders » Wed, Jun 24, 2020, 6:44 AM UTC

CoolGuySteve wrote: post #102

rz2k wrote: post #71

Does anyone have any insight into the business logistics involved in a transition like this? I presume Apple has done maintenance on transitioning desktop OS X to ARM as an option for a very long time. How many years ago would they have had to decide that was the direction they were going to make it reality? 2015? How many people would have been working on it? How many billions of dollars? How does the cost of develo…

Apple already supports ARM so they have the whole toolchain, most of their operating system, and many frameworks ported. Most of the heavy lifting was done in Project Purple (aka the first iPhone). Porting from PPC to x86 was arguably more difficult as a lot more of the framework code had endianness assumptions baked in.

> Porting from PPC to x86 was arguably more difficult as a lot more of the framework code had endianness assumptions baked in.

Did it? The code they inherited from NeXT didn't assume endianness, and until Rhapsody Developer Release 2 they shipped x86 builds. Some applications like iTunes ran on Windows, with a partial port of the Cocoa libraries underlying them (this, too, was a descendent of old NeXT support for Windows).

It's entirely plausible that Apple didn't have to do much; as they said at the time, they never stopped supporting x86 after Rhapsody Developer Release 2, and they had the OS running on x86 the entire time. I'd assume from the point of view of most developers working on OS X they simply had requirements to avoid endian assumptions, etc., and occasionally the team maintaining x86 support would send a nondescript patch to "fix the endianness assumption".

Re: About the Rosetta Translation Environment

#222

Post by qalmakka » Wed, Jun 24, 2020, 6:51 AM UTC

DCKing wrote: post #40

Rosetta's goal is to support legacy Mac apps. It's quite finely scoped, but I hope Apple will go above this and make it available as part of their virtualization framework. This way e.g. Parallels and Docker could use this to provide some way to tap in probably the fastest way to run x86 on ARM Macs. This would mean Rosetta would go beyond its stated scope, and certainly go beyond what the relatively short-lived Rose…

I think Rosetta is mostly about userspace, and a Hypervisor is definitely not something that sticks to that - modern VMs run on the bare metal thanks to CPU acceleration and dedicated instructions (i.e. VT-x and AMD-V). Getting an app to run on a foreign architecture it's different than emulating a whole machine in order to get an unmodified OS kernel to run. You can do it this very day with QEMU, yesterday I tried just for fun to boot Windows XP on my Raspberry Pi 4 (it boots but it's horrendously slow, if you're interested). Maybe with time and effort, an emulator can get a satisfactory level of speed (probably never enough to run Windows games on emulated Windows though, but who knows).

Re: About the Rosetta Translation Environment

#223

Post by Dunedan » Wed, Jun 24, 2020, 7:35 AM UTC

qubex wrote: post #84

Bigpet wrote: post #44

Earlier quoted context omitted.

I think I'm missing something. How is ARM closing things up? Does Apple have a bunch of processor extensions that make it incompatible with other ARM processors? Or do you think they'll take the chance to kill boot-camp or something?

The “ARM world” is almost inconceivably varied by x 86 standards. There’s not even an agreed-upon boot procedure (the Raspberrry Pi’s CPU famously gets booted by the GPU). Efforts to standardise this in the server space are only just getting off the ground with the Arm Server Base Boot Requirements version 1.2 being ratified last year. I doubt you’ll find Apple subscribing to anything that they won’t develop in-house…

> This is, after all, the company that developed the Lightening connector and sticks on its iPhones to it despite the whole industry shifting to USB-C.

There is a rumor that Apple developed USB-C and donated it to the USB-IF [1]. Apple was also one of the first users of USB-C when they introduced the 12" MacBook in 2015.

Since then they've continuously grown their adoption of USB-C, first in the MacBook Pro in 2016, then in the iMac and iMac Pro in 2017, the iPad Pro, MacBook Air and Mac Mini in 2018 and most recently in the Mac Pro in 2019. In fact nowadays the only Apple devices still not featuring USB-C are the iPhone and the (non-Pro) iPads.

There are probably good reasons why Apple hasn't replaced Lightning with USB-C for the iPhone and iPad yet. If they replace Lightning with USB-C now, the whole 3rd-party accessory ecosystem has to adapt to that. While that's probably fine, if the rumors are true that Apple plans to remove all physical ports from iPhones [2] next year, that would result in USB-C equipped iPhones/iPads only being sold for 2-3 years, before there is another interface again. So Apples thinking is probably that it's more customer friendly to stick to Lightning until they replace it with a wireless solution and I'd agree with such an assessment.

[1]: https://www.macrumors.com/2015/03/13/apple-invents-usb-c/

[2]: https://www.macrumors.com/2019/12/05/kuo-iphone-without-ligh...

Re: About the Rosetta Translation Environment

#224

Post by phs318u » Wed, Jun 24, 2020, 8:57 AM UTC

snowwrestler wrote: post #214

Mister_Snuggles wrote: post #143

I've been using Macs at work for a long time, but sadly this will mark the end of that era. In particular, this limitation on Rosetta rules out an ARM-based Mac for work: > Virtual Machine apps that virtualize x86_64 computer platforms My job requires me to use a piece of proprietary Windows-only software for a large portion of my work. If I can't use this software I can't do my job. Currently I run it in VMware Fusi…

That line just means you can’t run an emulator on top of an emulator, which makes sense. Performance would suck. What will happen instead is that companies like VMware will release emulators that run natively on Apple chips. (Rather than trying to run on top of Rosetta.) However, Intel Windows performance might still suck in those. Remains to be seen.

> companies like VMware will release emulators that run natively on Apple chips

Exactly. This has happened before e.g. Microsoft's VirtualPC [0].

> However, Intel Windows performance might still suck in those

Bingo. I remember how agonisingly slow VirtualPC was for anything remotely useful (forget gaming).

[0] https://web.archive.org/web/20071031005603/http://www.micros...

Re: About the Rosetta Translation Environment

#225

Post by benmmurphy » Wed, Jun 24, 2020, 9:52 AM UTC

is the translation 100% static? for example if I do something like:

    function_pointer = blackbox_function_translator_does_not_understand();
    function_pointer()

then how do we end up calling the correct address in arm64 land? there are no type tags in assembly to distinguish between integers and addresses. in QEMU my understanding is translation is done dynamically so addresses would float around in memory as x86_64 addresses and then when you tried to `call` them it would look up a mapping table. In QEMU I suspect they also try and optimise this case similar to a JIT using inline caching so most of the time you wouldn't actually hit the mapping table.

But if you are not dynamically converting x86_64 addresses to arm64 addresses then you need to understand what all the addresses in the program are and understand all the manipulations that might be performed on those addresses. now, you shouldn't actually be doing weird manipulations of addresses to functions in memory but if you are running obfuscated code this often happens.

I think in QEMU this would work assuming (myfun+4)() does something intelligent:

    uint64_t add(uint64_t v) {
      return v + 4;
    }

    void myfun();

    int main() {
      void (*x)() = &myfun;
      x = (void*)add((uint64_t)x);
      x();
      printf("%lld\n", add(4));
    }

if you are holding function addresses as arm64 addresses in memory then you need to dispatch add() based on whether the argument is an integer or an address.

Re: About the Rosetta Translation Environment

#226

Post by tonyedgecombe » Wed, Jun 24, 2020, 10:03 AM UTC

viro wrote: post #111

So does this mean no windows VMs?

Yes, which is an interesting problem for Parallels and VMWare. I would imagine the key requirement for most of their Apple customers is to run Windows.

On the other hand it might be an opportunity to offer Windows in the cloud to Apple users.

Re: About the Rosetta Translation Environment

#227

Post by tom_mellior » Wed, Jun 24, 2020, 1:15 PM UTC

derefr wrote: post #118

mkl wrote: post #41

> Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. How on Earth does it do that? If executable code is being generated at runtime, it's going to be x86_64 binary machine code still (there are too many ways to generate valid machine code, and it won't know right away whether you're JITting, or cross compiling and actually want x86_64), so Rosetta would need to dete…

Think of binary translation as just another kind of compiler. It parses machine code, generates an IR, does things to the IR, and then codegens machine code in a different ISA. (Heck, Rosetta 2 is probably built on LLVM. Why wouldn't it be? Apple already put so much work into it. They could even lean on similar work like https://github.com/avast/retdec .) During the "do things to IR" phase of compilation, you can do…

> The unique pattern of machine-code that must occur in any implementation of JIT, is a jump to a memory address that was computed entirely at runtime, i.e. with a https://en.wikipedia.org/wiki/Use-define_chain for that address value that leads back to a call to mmap(2) or malloc(2).

This is probably mostly true. But actually reliably finding such cases, in the most hostile environment imaginable (namely, on x86-64 binary code), would require heroic program analysis that I as a compiler engineer would judge unrealistic.

I would find it much more plausible for the system to watch for something like "jump to a target in a memory page that at some point had the W flag set, has since had W removed and X set, and has not been jumped to since that", and then trigger a compilation of that page starting at the given jump address, and a rewrite of the jump instruction. As proposed in https://news.ycombinator.com/item?id=23614894 this could be done by watching for page faults, though presumably it would mean intercepting places where the application tries to set the X bit on a page and setting NX instead so that the page fault can be caught.

Re: About the Rosetta Translation Environment

#228

Post by Nexxxeh » Wed, Jun 24, 2020, 1:45 PM UTC

Mister_Snuggles wrote: post #152

empthought wrote: post #146

Earlier quoted context omitted.

It will be at least several years before you will not be able to purchase a new Intel-based Mac.

From another article, Apple claims that the transition will be complete in two years. I have 2.5 years left before I will be eligible to have my work computer replaced. Depending on the exact timing of Apple's product cycles and the procurement cycle, I'll either be getting one of the last Intel Macs or a Windows machine of some description. If an Intel Mac is still available at this time, that brings other concerns…

I think this may largely be a non-issue by the time it rolls around, as while software emulation of x86_64 might prove tricky, there's one thing that runs x86_64 really well. Actual x86_64 chips.

This is what they used way back in the day. Apple (and others) actually made x86 (non-64) add-on cards for PPC Macs that were effectively PCs on a card to slap in a Mac.

Would be relatively trivial to do the same now. PC on a PCIe card, maybe expose itself to the host as just a high speed network card.

Use a Ryzen embedded chip, SO-DIMMS, job's a good-un.

All the major software stuff would already work. Headless diskless iSCSI PC.

Bonus feature that it also acts as a hardware dongle if you want some magic sauce MacOS software to make the process easier.

Re: About the Rosetta Translation Environment

#229

Post by derefr » Wed, Jun 24, 2020, 1:47 PM UTC

saagarjha wrote: post #189

derefr wrote: post #118

Earlier quoted context omitted.

Think of binary translation as just another kind of compiler. It parses machine code, generates an IR, does things to the IR, and then codegens machine code in a different ISA. (Heck, Rosetta 2 is probably built on LLVM. Why wouldn't it be? Apple already put so much work into it. They could even lean on similar work like https://github.com/avast/retdec .) During the "do things to IR" phase of compilation, you can do…

> Rosetta 2 is probably built on LLVM. Why wouldn't it be? LLVM is kind of slow; JavaScriptCore abandoned it years ago for their FTL backend. > The unique pattern of machine-code that must occur in any implementation of JIT, is a jump to a memory address that was computed entirely at runtime, i.e. with a https://en.wikipedia.org/wiki/Use-define_chain for that address value that leads back to a call to mmap(2) or mall…

Re: your rebuttal code — that’s still a use-define chain. You don’t need the same literal pointer; you just need to know that the value of the pointer ultimately depended on a the output of mmap(2). Since the mmap(2) region address is passed into memcpy(2)—and memcpy(2) can fail, producing NULL—the output of memcpy(2) does then depend on the input. (Even if it didn’t, you could just lie to the compiler and tell it to pretend that memcpy(2) always depends on its input.)

Re: About the Rosetta Translation Environment

#230

Post by qubex » Wed, Jun 24, 2020, 1:55 PM UTC

Dunedan wrote: post #223

qubex wrote: post #84

Earlier quoted context omitted.

The “ARM world” is almost inconceivably varied by x 86 standards. There’s not even an agreed-upon boot procedure (the Raspberrry Pi’s CPU famously gets booted by the GPU). Efforts to standardise this in the server space are only just getting off the ground with the Arm Server Base Boot Requirements version 1.2 being ratified last year. I doubt you’ll find Apple subscribing to anything that they won’t develop in-house…

> This is, after all, the company that developed the Lightening connector and sticks on its iPhones to it despite the whole industry shifting to USB-C. There is a rumor that Apple developed USB-C and donated it to the USB-IF [1]. Apple was also one of the first users of USB-C when they introduced the 12" MacBook in 2015. Since then they've continuously grown their adoption of USB-C, first in the MacBook Pro in 2016,…

Regarding USB-C I agree with you entirely and think you entirely missed the point I was trying to make.

I am well aware Apple participated in the USB-C connector specification processes and only introduced the Lightening port when it became clear to it that USB-C would take longer to define than their urgency to ditch the old iPod 30-pin connector would allow, forcing them to ‘defect’. They’re probably rather sour about this deep down (since it forces them to have different “one size fits all” interfaces on different lines of products, which kind of undermines its own point).

At any rate, the thought I was trying to express is that I would be very surprised if Apple adopted any kind of ‘standard’ ARM architecture from upon which to begin its new era of ARM-based Macs. They’re not even calling them ARM-based, they’re using the term “Apple Silicon” (which is only a marketing gimmick but it’s pretty indicative).

So... they might, during the course of their preliminary analyses and feasibility studies identified a pre-existing ARM system architecture that they are comfortable with, but most likely they’ll go for something unashamedly homegrown such as whatever architecture they developed for the iPhone and iPad and consequentially whatever boot procedure they follow, which as far as I know is undocumented and subject to change (though it is the regular target of reverse-engineering, because of jail-breaking... and that game of cat-and-mouse has probably greatly enhanced code quality and reduced exposed surface area).

The end result is that “from the inside” from a very low level (the kinds of hardware levels) that matters when booting an OS and that it subsequently screens userland and the users from, these details matter, and I don’t expect them to be standard, I don’t expect them to be clear, and I expect that unsigned OS images won’t be bootable.

That said I read that Apple has had a session at the WWDC 2020 about booting other OSes from external drives on the ARM Developer Transition system, so who knows, I could be wrong.