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

191–200 of 249 posts

Re: About the Rosetta Translation Environment

#191

Post by saagarjha »

gpderetta wrote: post #180
BeeOnRope wrote: post #121

Earlier quoted context omitted.

There's another option: 4) Translate x86 loads and stores to acquire load and release stores, to align with the x86 semantics. These already exist in the ARM ISA, so it's not much of a stretch at all. This is the one I'm betting on.

That would be too expensive, unless the emulation in general is ao high not to matter. If store releases and load aquires were very cheap already why make them distinct from normal one anyway? I suspect that either the CPU is already TSO in practice or has some TSO mode.

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

Re: About the Rosetta Translation Environment

#192

Post by throwaway2048 »

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.

it would be a lot more normal to trap the illegal instruction, the same thing that happens if you give a CPU a nonsense nonexistent instruction.

Re: About the Rosetta Translation Environment

#193

Post by ArgyleSound »

LeoNatan25 wrote: post #183
burlesona wrote: post #113

Earlier quoted context omitted.

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 loc…

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?

Re: About the Rosetta Translation Environment

#194

Post by amaranth »

Someone wrote: post #144
amaranth wrote: post #135

Earlier quoted context omitted.

The page we're discussing here actually says you can't mix arm64 and amd64 code in a single process, if your binary is amd64 all your libraries will be too. I'd be surprised if they put in the work to generate thunks for all their system libraries and then didn't make it possible to use any others. More likely macOS will just have two copies of all the (non-iOS) libraries and the only point they work together is the…

If I read it correctly, it says it prevents you from doing that, “including all code modules that the process loads dynamically”, but I don’t think that means Rosetta won’t call arm64 libraries for libraries linked at program startup. Think about it: Rosetta translates your code to arm64, and your code calls a function in a system library. Why would Rosetta use the x64 version of the library and translate its code to…

I imagine the answer is going to be that it doesn't. Stuff using Accelerate will probably see the biggest performance hit because it _doesn't_ use the arm64 version and the emulator translates those instructions poorly. However, since those are the applications hit the hardest by this switch they'll (hopefully) be some of the first recompiled for the new CPUs as well.

Re: About the Rosetta Translation Environment

#195

Post by jmull »

amaranth wrote: post #134
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…

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

Don’t they need to communicate to developers and users what software will (and will not) run on their upcoming computers?

Re: About the Rosetta Translation Environment

#196

Post by saagarjha »

monocasa wrote: post #122
perardi wrote: post #101

Earlier quoted context omitted.

Well color me surprised. I figured that’d be on the chopping block.

I was surprised too. I wonder which crazy peripheral (or maybe it was antivirus/intrusion detection?) made them not go all in on "only apple gets to be in kernel space".

Maybe Dropbox?

Re: About the Rosetta Translation Environment

#197

Post by gpderetta »

saagarjha wrote: post #191
gpderetta wrote: post #180

Earlier quoted context omitted.

That would be too expensive, unless the emulation in general is ao high not to matter. If store releases and load aquires were very cheap already why make them distinct from normal one anyway? I suspect that either the CPU is already TSO in practice or has some TSO mode.

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.

Re: About the Rosetta Translation Environment

#198

Post by jmull »

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…

> Currently I run it in VMware Fusion

That’s how you’d do it on an ARM Mac too.

Rosetta is about executing Mac apps on ARM Macs. For Windows apps you’re still going to go to a third party, most likely the same third-parties as before.

Re: About the Rosetta Translation Environment

#199

Post by gpderetta »

AndrewStephens wrote: post #188
andoma wrote: post #87

I wonder how it handles the stricter memory ordering from x86? For example, this code: void store_value_and_unlock(int *p, int *l, int v) { *p = v; __sync_lock_release(l, 0); } on x86_64 compiles to: mov dword ptr [rdi], edx mov dword ptr [rsi], 0 ret vs on arm64: str w2, [x0] stlr wzr, [x1] ret Notice how the second store on ARM is a store with release semantics to ensure correct memory ordering as it was intended i…

Elsewhere in the documentation[0] Apple explicitly calls out that code that relies on x86 memory ordering will need to be modified to contain explicit barriers. All sensible code will do this already. [0] https://developer.apple.com/documentation/apple_silicon/addr...

Sure, for source translation that's sorta fine (although I wouldn't want to be the one debugging it). The issue is binary translation, there is really no such a thing as a acquire or release barrier on x86.

Re: About the Rosetta Translation Environment

#200

Post by orangecat »

LeSaucy wrote: post #65
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.

Highly unlikely Apple would cede the software engineering market for a competitor to step in.

If you're not specifically developing for iOS or macOS, Apple doesn't care about you. They'll take your money if you want to write Unix or web software, but they'll drop support in a heartbeat if that makes it easier to support their mobile and consumer segments.

Post reply on HN