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

41–50 of 249 posts

Re: About the Rosetta Translation Environment

#41

Post by mkl »

> 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 detect when the code's about to be run, or when it's marked as executable, and translate the machine code in that bit of memory just in time. The length of the ARM code might be longer, so it would have to be in a different block of memory, with the original x86_64 code replaced with a jump to the new code or something.

It's late at night here, so maybe I'm missing a simpler approach, but I'm a bit surprised they have it working reliably enough to make such a general statement (there being a great variety of JIT systems). From a quick search I can't tell if Microsoft's x86-on-ARM translation in Windows 10 ARM supports JITs in the program being run.

Re: About the Rosetta Translation Environment

#42

Post by jayyhu »

beervirus wrote: post #24
jayyhu wrote: post #17

>Rosetta translates all x86_64 instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. No AVX will probably mean that the vast majority of pro/graphics intensive apps won't work out of the box with Rosetta.

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.

Re: About the Rosetta Translation Environment

#43

Post by jeffbee »

saagarjha wrote: post #31
underdeserver wrote: post #14

Translating JITted code is a pretty cool trick.

At runtime it doesn't really matter where you code is coming from, as long as you do flushes at the right spots.

But doesn't this mean that they are translating and running the JIT and the JIT is creating new executable x86 code which then also needs to be translated? I'm a bit baffled as to how any of this can work properly, for example if my JIT is sampling instructions to determine when to optimize, does Rosetta need to reverse-translate the actual instruction pointer back to the original x86 code offset?

Re: About the Rosetta Translation Environment

#44

Post by Bigpet »

godzillabrennus wrote: post #38

The Apple transition to ARM for me is sad. There was so much positivity around the Intel transition. It opened up the Mac platform. Now it’s going back into a closed black box.

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?

Re: About the Rosetta Translation Environment

#45

Post by dividedbyzero »

EtienneK wrote: post #13
marcinzm wrote: post #10

Earlier quoted context omitted.

Which is less than ideal if you're using x86 servers since you no longer have the same dev containers as production containers.

Yeah. I predict a sudden increase of ARM servers as well.

And maybe even some decent ARM Linux laptops. One may dream...

Re: About the Rosetta Translation Environment

#46

Post by leeter »

monocasa wrote: post #32
leeter wrote: post #30

Earlier quoted context omitted.

True, but they did have the license IIRC. Otherwise they'd be licensing from VIA or whomever owns that license now. That license AFAIK would include up to SSE4. It's not like Apple is going to tell us. But the JIT nature makes me think it's Transmeta as the company currently holding that IP is a "Patent enforcement entity".

Or they're just giving Intel the finger, banking on having a warchest of defensive patents from acquiring nearly every promising fabless CPU startup of the past 15 years. Edit: Also, I don't think Transmeta's license would include SSE4. They were defunct at that point.

Possible, I kinda doubt they would as Intel could just cut them off at the knees as they threatened MS with for the Surface Pro X. There is the remote possibility they are licensing from Intel too. At the end of the day I doubt they are going to tell us. Once people start getting the dev machines they can find the edges of the implementation. I suspect it has some quirks we'll discover over time. Regardless this is speculation.

Re: About the Rosetta Translation Environment

#47

Post by mkl »

unicornfinder wrote: post #18
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?

If I had to guess it's because Rosetta isn't fully emulating an x86_64 instruction set but rather dynamically translating API calls for the most part.

I think it's neither of those things. The x86_64 machine code instructions are translated into ARM instructions, so there's no emulation and the API calls don't need to change.

Re: About the Rosetta Translation Environment

#48

Post by fsflyer »

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?

Apple spent $1B buying Intel's modem business last year. https://www.apple.com/newsroom/2019/07/apple-to-acquire-the-... Apple knew this transition was coming. They could have easily slipped in other terms to deal with any IP licensing issues around implementing the x86_64 instruction set.

Re: About the Rosetta Translation Environment

#49

Post by monocasa »

Bigpet wrote: post #44
godzillabrennus wrote: post #38

The Apple transition to ARM for me is sad. There was so much positivity around the Intel transition. It opened up the Mac platform. Now it’s going back into a closed black box.

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?

They'll almost certainly only allow their signed kernels to run.

And that's in addition to not documenting any of the peripherals.

Re: About the Rosetta Translation Environment

#50

Post by monocasa »

mkl wrote: post #47
unicornfinder wrote: post #18

Earlier quoted context omitted.

If I had to guess it's because Rosetta isn't fully emulating an x86_64 instruction set but rather dynamically translating API calls for the most part.

I think it's neither of those things. The x86_64 machine code instructions are translated into ARM instructions, so there's no emulation and the API calls don't need to change.

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

That's what emulation is.

Post reply on HN