Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About the Rosetta Translation Environment

developer.apple.com

Post reply on HN
Print view View original

61–70 of 249 posts

Re: About the Rosetta Translation Environment

#61

Post by TheCoreh »

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…

They might be using something like an NX bit on the generated x86_64 page, so that whenever the code attempts to jump into it, a page fault is generated, and the kernel is able to handle that, kicking in the JIT compilation and translating the code / address. This is essentially a "double JIT" so there will likely be a performance hit.

Since they control the silicon, Apple might also be leveraging a specialized instruction / feature on the CPUs (e.g. a "foreign" bit that's able to mark memory pages as being from another architecture, and some addressing scheme that links them to one or more native pages behind the scenes)

Maybe the A series chips even have "extra" registers / program counters / interrupts that aid in accelerating this emulation process.

Re: About the Rosetta Translation Environment

#62

Post by NovemberWhiskey »

monocasa wrote: post #26
nickcw wrote: post #15

I thought this was the most interesting paragraph. > What Can't Be Translated? > Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. I guess translation of JIT compiled stuff implies this isn't a once of translation. I guess translating plugins implies that too. It sounds like very clever stuff to me! > However, Rosetta doesn’t translate the following executables: >…

> These sound like they should be relatively straight forward to translate. I wonder why they didn't? Lack of time? Or perhaps because translating them means that they don't run fast enough to be useful and the fallback paths are likely to run quicker. Probably because ARM's NEON doesn't have 256bit registers, greatly complicating the implementation.

I would guess that's right - AVX only came onto the scene in 2011 so most code will be able to fall back on an SSE implementation if AVX is unavailable, and presumably an AVX emulation which is a bad fit versus the hardware is actually slower than the SSE emulation.

A quick search suggests a couple of people already running into this issue with the older generation Mac Pros that also don't support AVX but it doesn't seem that widespread.

Re: About the Rosetta Translation Environment

#63

Post by perardi »

dsabanin wrote: post #3

From the page: What Can't Be Translated? Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. However, Rosetta doesn’t translate the following executables: * Kernel extensions * Virtual Machine apps that virtualize x86_64 computer platforms Some people are not going to be happy about this. Edit: But I personally am okay with that.

Apple wants kexts gone. They announced the deprecation last year, and this is another chance to force the change. (And for good reasons, if my layman's understanding of the security is at all correct.)

[https://developer.apple.com/support/kernel-extensions/](http...

Re: About the Rosetta Translation Environment

#64

Post by monocasa »

mkl wrote: post #54
monocasa wrote: post #50

Earlier quoted context omitted.

> The x86_64 machine code instructions are translated into ARM instructions, so there's no emulation That's what emulation is.

I think emulation would be interpreting the instructions one by one and doing what they say in software (a bit like Python's byte code interpreter). Rosetta translates the binary to another (now native) binary, and then runs it like normal, and much of the time this will be an ahead-of-time once off translation.

Recompilation is a valid emulation strategy. You're just amortizing client instruction decode by doing it ahead of time.

Last time I checked, that's how RPCS3 worked for instance, since PS3's GameOS didn't generally allow JITs anyway.

Re: About the Rosetta Translation Environment

#65

Post by LeSaucy »

bjpirt wrote: post #37

Having big flashbacks to the switch from PPC to x86 here. Rosetta worked relatively smoothly during that transition so fingers crossed it will be ok here too. Though with Docker support on the mac already being a second class citizen to running on Linux I wonder if a lot of devs will stop using macs for dev

Highly unlikely Apple would cede the software engineering market for a competitor to step in. Almost everyone in my company would prefer to have a MacBook vs a Thinkpad/Dell/etc if given the choice.

Re: About the Rosetta Translation Environment

#67

Post by NovemberWhiskey »

alexandrvicente wrote: post #39
flir wrote: post #33

Earlier quoted context omitted.

Do Amazon have an ARM server product?

Yes, https://aws.amazon.com/ec2/graviton/

... and it's actually kinda kick-ass - the original A1 instances were fairly disappointing but the M6g is at an extremely aggressive price/performance point.

Re: About the Rosetta Translation Environment

#68

Post by monocasa »

jayyhu wrote: post #42
beervirus wrote: post #24

Earlier quoted context omitted.

Do those programs blindly try to execute AVX instructions without checking whether they’re supported? What happens if you're just running on an older intel processor?

Apple seems to suggest that all well behaving programs: >use the sysctlbyname function to check the hw.optional.avx512f attribute So my guess it they probably just replace the AVX instructions with no-ops and let it blow up if the correct checks/fallbacks aren't in place.

Or just SIGILL rather than noop.

Re: About the Rosetta Translation Environment

#69

Post by ghaff »

leeter wrote: post #20
nickcw wrote: post #15

I thought this was the most interesting paragraph. > What Can't Be Translated? > Rosetta can translate most Intel-based apps, including apps that contain just-in-time (JIT) compilers. I guess translation of JIT compiled stuff implies this isn't a once of translation. I guess translating plugins implies that too. It sounds like very clever stuff to me! > However, Rosetta doesn’t translate the following executables: >…

RE AVX and above: My guess is that they are licensing the Transmeta IP which doesn't include those licenses IIRC. So unless they wanted to get sued they'd have to be careful. I suspect some SSE instructions may also not be supported as I don't recall if Transmeta had a license up to SSE4.

The original Rosetta was based on technology from a company called Transitive which was acquired by IBM a couple years after Apple's PowerPC to Intel transition. [1] It's not immediately obvious what technology licenses are involved with this new incarnation of Rosetta.

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

Re: About the Rosetta Translation Environment

#70

Post by mrpippy »

monocasa wrote: post #21
tomduncalf wrote: post #6

Are the limitations on x86_64 virtualization likely to be for technical reasons, or patent reasons? I read a comment on here alluding to some patents on x86_64 virtualization expiring later this year: https://news.ycombinator.com/item?id=23612256 - could that mean that there is a chance this might happen and they are keeping it quiet for now, or are patents likely unrelated?

Those are two different concerns. Rosetta isn't emulating x86_64 kernel mode. Microsoft isn't emulating x86_64 at all. I imagine Apple has enough patents that Intel infringes on to be able to cross licence.

Microsoft is working on it.
Post reply on HN