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

201–210 of 249 posts

Re: About the Rosetta Translation Environment

#201

Post by classichasclass »

oppositelock wrote: post #141
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…

The original PowerPC on Intel Rosetta was pretty amazing. First, most programs do much of their work inside the OS - rendering, network, interaction, whatever, so that's not emulated, Rosetta just calls the native OS functions after doing whatever input translation is necessary. So, nothing below a certain set of API's is translated. You have to keep a separate translated binary in memory, and be able to compile miss…

> the translated apps frequently faster than running native on PowerPC macs!

This gets repeated a lot and it's generally false. In fact, most of the time they were slower, and realistically you would expect this. On a clock for clock basis, an OG Mac Pro 2.66GHz was about 10-20% slower than a Quad G5 2.5GHz running the same PowerPC software. In some benchmarks, the Quad G5 was still faster at running PowerPC software than the 3.0GHz (see https://barefeats.com/quad06.html ). When the Core Duo had to pay the Rosetta tax, even upper-spec G4s could get past it (https://barefeats.com/rosetta.html) and it stood no chance against the G5.

Where I think this misconception comes from is that on native apps (and Universal apps have native code), these first Intel Macs cleaned the floor with the G4 and most of the time nudged past even the mighty Quad, and by the second generation it wasn't a contest anymore. But for the existing PowerPC software that was available during the early part of the Intel transition, Power Macs still ran PowerPC software best overall. It wasn't Rosetta that made the Intel Macs powerful, it was just bridging things long enough to buy time for Universal apps to emerge. Rosetta/QuickTransit was marvelous technology, but it wasn't that marvelous.

Re: About the Rosetta Translation Environment

#202

Post by classichasclass »

reaperducer wrote: post #165
loph wrote: post #155

What's old is new again. This reminds me of Digital's VEST technology. VEST would convert VAX programs to run on Alpha. From 32-bit CISC to 64-bit RISC. Nearly 30 years ago. https://web.stanford.edu/class/cs343/resources/binary-transl...

Or the PET emulator from 38 years ago that Commodore released because it wasn't sure that the C-64 would have any software. Ditto for the C-64 CP/M cartridge of the same vintage.

The PET emulator was an interesting case. It relied on the fact that BASIC 2.0 on the C64 was similar enough to that on the PET (and IEC serial devices similar enough to IEEE-488 ones, from the BASIC side, at least) that many programs ran unmodified. The interesting bits were adding some goop so that many common POKEs and PEEKs from BASIC would "just work" as well (like CB audio, screen memory, etc.). This was even enough for some machine language programs, though many choked on the different memory map.

Re: About the Rosetta Translation Environment

#203

Post by FireBeyond »

GeekyBear wrote: post #145
monocasa wrote: post #130

Earlier quoted context omitted.

IDK, what I saw was a several year old game running on the lowest settings and still stuttering a bit.

The more interesting point... >The demo wasn't perfect: the game ran at 1080p with fairly middling settings, but did so at what appeared to be at the very least a steady 30FPS, all while being run as an emulated x86 version of the game. That is: the game wasn't even natively compiled for ARM. But consider that Intel's most powerful laptop chipset GPU, found in the 10th generation Ice Lake series, is not capable of br…

> Apple received some snark about this demo being lame, but it's only lame if you don't understand at all just how terrible modern integrated laptop GPUs are.

We do know that. But we also know that the high end laptop market is not all about iGPUs. Entry and mid level consumer and business laptop, maybe, but if you buy a $1,500+ Dell laptop, you're not getting iGPU only.

So not exactly the best comparison. MBPs _start_ at $1,299.

Re: About the Rosetta Translation Environment

#204

Post by coldtea »

monocasa wrote: post #142
dtech wrote: post #140

Earlier quoted context omitted.

I suspect this will change fairly soon now that there will be a significant non-mobile aarch64 market in the future

There's still a non trivial amount of time to get that propagated. First merged into chromium, the merged into electron, then actually used by the client programs.

I'd say it would still be less than the first ARM Mac shipping time

Re: About the Rosetta Translation Environment

#205

Post by coldtea »

vmception wrote: post #139
amaranth wrote: post #134

Earlier quoted context omitted.

I'm not sure why they're making a big deal about this, couldn't the original Rosetta do this too? QEMU has been doing this since (I think) even before the original Rosetta, they call it user mode emulation. You run as if it was a normal emulator but also trap syscalls and forward them to the native kernel instead of emulating a kernel too. I'm more interested in how they're doing the AOT conversion and (presumably) p…

> I'm not sure why they're making a big deal about this, couldn't the That's par for course with Apple. They never acknowledge competitors including when its themselves. Everything they do or describe is awesome and magical, right now! It could be an incremental improvement, it could be a half decade old established technology, it could be something completely unexpected and science fiction turned into reality. Thats…

>That's par for course with Apple. They never acknowledge competitors

Unlike which company that does?

Re: About the Rosetta Translation Environment

#206

Post by comex »

ogre_codes wrote: post #182
comex wrote: post #175

Earlier quoted context omitted.

> There is a very remote possibility that Windows for ARM could be virtualized by some future version of VMware and the proprietary toolset could run under that, but I'm not holding my breath. How is that remote? We've already seen Parallels Desktop virtualize Linux for ARM.

As far as I can tell, you can't buy Windows for ARM, you can only get a license by buying specific hardware. Aside from that, most people who want Windows support on a Mac want support for x86 Windows, not the ARM version. So even if it does run, it's likely to be a hobbyist/ hacker thing, not a product.

Windows for ARM has a built-in emulator for x86 binaries, so I think most users trying to run random legacy programs would be satisfied with it. (Gamers, not so much…)

Re: About the Rosetta Translation Environment

#207

Post by anyfoo »

monocasa wrote: post #184
anyfoo wrote: post #157

Earlier quoted context omitted.

Pages containing x86 code are never actually being marked executable in the (ARM) pagetables, because that would be nonsensical: The CPU itself does not know how to run x86 code. mmap/mprotect from x86 with the exec bit therefore does something else than native code.

Right, but the x86 code _thinks_ it does, and those semantics have to be maintained. What that practically means is that x86 executable pages get mapped as RO by default as seen by the ARM side even if they would normally be RWX. Modifications trap, the handler mprotects the pages as writeable, flush the translation cache for that region, then returns from the trap. Then on an x86 jump to that region, the JIT cache s…

Yeah, I specifically said they don't get marked executable in the page tables. From the x86 code's perspective, they of course look executable.

Re: About the Rosetta Translation Environment

#208

Post by saagarjha »

gpderetta wrote: post #197
saagarjha wrote: post #191

Earlier quoted context omitted.

Then why not expose that to ARM applications running on it?

Apple might not want to promote this to an architectural guarantee. It is only needed for the few years required to transition away from x86, but if applications start relying on it it will need to maintain it forever.

If they run with it for long enough it will all but become an architectural guarantee as people unintentionally write incorrect programs that happen to still work right.

Re: About the Rosetta Translation Environment

#209

Post by saagarjha »

ArgyleSound wrote: post #193
LeoNatan25 wrote: post #183

Earlier quoted context omitted.

It’s already happening. macOS Bug Sur (Apple’s wording) enforces a read only system partition, which cannot be easily disabled or mounted as rw.

Can you not go into recovery mode and turn off all the system integrity features like you always could?

There is no way to boot a with a R/W system partition anymore, nor can you mount it as such. You must reboot, make changes while in recovery, commit them, and then restart again.

Re: About the Rosetta Translation Environment

#210

Post by scarface74 »

classichasclass wrote: post #201
oppositelock wrote: post #141

Earlier quoted context omitted.

The original PowerPC on Intel Rosetta was pretty amazing. First, most programs do much of their work inside the OS - rendering, network, interaction, whatever, so that's not emulated, Rosetta just calls the native OS functions after doing whatever input translation is necessary. So, nothing below a certain set of API's is translated. You have to keep a separate translated binary in memory, and be able to compile miss…

> the translated apps frequently faster than running native on PowerPC macs! This gets repeated a lot and it's generally false. In fact, most of the time they were slower, and realistically you would expect this. On a clock for clock basis, an OG Mac Pro 2.66GHz was about 10-20% slower than a Quad G5 2.5GHz running the same PowerPC software. In some benchmarks, the Quad G5 was still faster at running PowerPC software…

History repeats itself. Even though Apple didn’t make the claim this time, they did claim that PPCs would run 68K apps faster because they would spin much of their time running native code. This wasn’t true then either - at least not for the first gen PPC Macs.
Post reply on HN