Live data from Hacker News

About the Rosetta Translation Environment

developer.apple.com

111–120 of 249 posts

Re: About the Rosetta Translation Environment

#112

Translating JITted code is a pretty cool trick.

You'll probably also enjoy Nvidia's Denver architecture[1] (used in the Tegra processors) which JITs ARM bytecode into their own internal instruction set inside of the processor.

[1] https://en.wikipedia.org/wiki/Project_Denver

Re: About the Rosetta Translation Environment

#113
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 the longer Rosetta exists and macOS thereby supports a wider variety of binary executables, the more people will rely on it to deliver them day-to-day functionality in increasingly complex configurations, and the more Apple will expose itself to those users' criticisms. If Apple's rationale for the transition is to gain further control over their product design and manufacture, the prospect of having to appea…

Your first two paragraphs track, but I think the second two are quite a leap.

Sure it’s possible, but I think it’s exceptionally unlikely that Apple will try to lock down the Mac the way the iPhone is.

The reason is they think of them as fundamentally different products with fundamentally different purposes, and for the most part the trend line has been moving to more opening of the iOS ecosystem rather than more lockdown of the Mac.

(For instance in the last few iOS releases they’ve added file system support, removing the default apps, and in this new release they’re allowing users to set alternative default apps, etc.)

Apple views the iPhone as a pure consumer device where the most important thing is that everything “just works.” It’s locked down in the same way a video game console is locked down, and for the same reasons: they gain a lot of “just works” benefits from keeping things very standardized. And most consumers LIKE that. Most consumers hate that their PC (or even Mac) often fails them in “mysterious” ways that require tech support or just living with a broken experience.

Apple talks about iOS as a “car” and Mac as a “truck.” They see Mac as their development platform, and literally called that out in their keynote.

There is certainly a desire on Apple’s part to make the Mac also an excellent consumer product, hence things like the existence of the App Store and app signing, but on the Mac there have always been “escape hatches” for those who know what they’re doing.

Now, the part that Apple does want to lock down and is able to lock down even more with this move is the Hardware. They’ve never made Hackintosh easy and have never done anything to indicate support for tinkering with their hardware, to the point that when the pro community began to bail they brought back a highly “configurable” Mac Pro (configurable with official parts but not really tinkerable).

But anyway, I don’t think Mac OS is going to get locked down substantially more than it already is. It’s a nice OS with some trade offs, if those trade offs have worked for you in the past they’re likely to keep being fine, and if not then you probably wouldn’t be a Mac user anyway.

Re: About the Rosetta Translation Environment

#114
post #84
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…

in all fairness the Lightening connector has been around a lot longer than usb-c

Re: About the Rosetta Translation Environment

#115
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…

While I have talked about the financial of an All in ARM Mac platform, that was from an angle of each individual component. But you could also look at it from a company R&D perspective.

Example. Apple ship ~10M MacBook Air a year. Current spending on MacBook Intel chip is roughly $200 per unit. As long as Apple could make it below $200, they make more profits or lower the price.

That is a per unit, per model angle. i.e Apple could easily have fitted an A12Z inside Macbook Air, and save them at least $150.

Or you could look at it from a company total perspective.

Apple currently spend $2B annual R&D ( a made up number )on its Chip design. How much more additional would we need if we need to design for Mac CPU as well. $500M / $1B? Great, and do it. ( If you follow Apple closely, Apple's Net Profits and R&D has been at a fixed percentage for a fairly Long time )

>And finally, I am also curious about the accounting and financial disclosures required in such decisions.

There is nothing that needs to disclose until these decision make material effect on its stock performance.

It is worth pointing out Apple receives $10B annually from Google for having it as default search engine on Safari alone. While it is expensive to design its own chip, comparatively speaking it is still peanuts for Apple.

At the rate things are going, Apple could have spend more money on Apple TV+ Originals than R&D spend on Mac CPU alone.

Re: About the Rosetta Translation Environment

#116
post #106

Earlier quoted context omitted.

That's the big piece I've been wondering about too. Three options as I see it (none of them great): 1) Pin all threads in an x86 process to a single core. You don't have memory model concerns on a single core. 2) Don't do anything? Just rely on apps to use the system provided mutex libraries, and they just break if they try to roll their own concurrency? Seems like exactly the applications you care about (games, pro…

> 3) Some stricter memory model in hardware? Seems like that'd go against most of the stated reason for switching to ARM in the first place. I would assume that a more strict memory model would be enabled only for processes that needs it (ie, Rosetta translated ones). So a cpu-flag is set/cleared when entering/exiting user mode for those processes. Does this require a separate/special cache coherency protocol? A comp…

> I would assume that a more strict memory model would be enabled only for processes that needs it (ie, Rosetta translated ones). So a cpu-flag is set/cleared when entering/exiting user mode for those processes. Does this require a separate/special cache coherency protocol?

The benefits you'd get from going to a weaker memory model are by not having that extra coherency in the critical path in the first place. Adding extra muxes in front of it to make it optional would be worse than just having it on all the time.

> A complete L1d flush when entering/leaving these processes (across all CPUs)?

That wouldn't help because two threads could be running at the same time on different cores against their respective L1 and store buffers.

Re: About the Rosetta Translation Environment

#117
post #110

Earlier quoted context omitted.

They wouldn't need qemu anywhere either way; they have their own binary translator.

They've specifically called out that OS level virtualization isn't available in Rosetta 2. So if there is an x86 dependency QEMU becomes necessary.

There's qemu-user for user mode only emulation in addition to qemu-system.

Re: About the Rosetta Translation Environment

#118
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 static analysis, and use this to inform the rest of the compilation process.

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). Static analysis of the IR can find and label such instructions; and you can use this to replace them in the IR with more-abstract "enter JITed code" instrinsic ops.

Then, in the codegen phase of this compiler, you can have such intrinsics generate a shim of ARM instructions. Conveniently, since this intrinsic appears at the end of the JIT process, the memory at the address passed to the intrinsic will almost certainly contain finalized x86 code, ready to be re-compiled into ARM code. So the shim can just do a (hopefully memoized) call to the Rosetta JIT translator, passing the passed-in address, getting back the address of some ARM code, and jumping to that.

Re: About the Rosetta Translation Environment

#119
post #106

Earlier quoted context omitted.

> 3) Some stricter memory model in hardware? Seems like that'd go against most of the stated reason for switching to ARM in the first place. I would assume that a more strict memory model would be enabled only for processes that needs it (ie, Rosetta translated ones). So a cpu-flag is set/cleared when entering/exiting user mode for those processes. Does this require a separate/special cache coherency protocol? A comp…

> I would assume that a more strict memory model would be enabled only for processes that needs it (ie, Rosetta translated ones). So a cpu-flag is set/cleared when entering/exiting user mode for those processes. Does this require a separate/special cache coherency protocol? The benefits you'd get from going to a weaker memory model are by not having that extra coherency in the critical path in the first place. Adding…

> The benefits you'd get from going to a weaker memory model are by not having that extra coherency in the critical path in the first place. Adding extra muxes in front of it to make it optional would be worse than just having it on all the time.

Indeed true, good point.

> That wouldn't help because two threads could be running at the same time on different cores against their respective L1 and store buffers.

Of course, this was related to the cost of switching coherency protocol during context switch. But as you say the overhead of just making it switchable is prohibitive in itself.

Re: About the Rosetta Translation Environment

#120
post #93

Earlier quoted context omitted.

> Most applications do not contain JITs. Java apps and JavaScript apps (Electron) come to mind.

True, but those are trivial to port as there are already mature JDKs and JavaScript VMs for ARM64. Porting an electron app should be a matter of checking it out and building it with ARM support. Applications with internal JITs custom-built for X64 are going to be a lot tougher.

Electron doesn't support aarch64 builds compiled from aarch64 hosts yet (so you have to cross compile), and doesn't support cross compiling if you have any native code addons.

Some apps out there are between a rock and a hard place if it weren't for rosetta.

Post reply on HN