About the Rosetta Translation Environment • Hacker News Board

Re: About the Rosetta Translation Environment

#121

Post by BeeOnRope » Tue, Jun 23, 2020, 5:54 PM UTC

monocasa wrote: post #95

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…

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…

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.

Re: About the Rosetta Translation Environment

#122

Post by monocasa » Tue, Jun 23, 2020, 5:59 PM UTC

perardi wrote: post #101

selsta wrote: post #88

Earlier quoted context omitted.

Apple ARM will support kexts. https://developer.apple.com/documentation/apple_silicon/inst...

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".

Re: About the Rosetta Translation Environment

#123

Post by monocasa » Tue, Jun 23, 2020, 6:01 PM UTC

osy wrote: post #108

fsflyer wrote: post #48

Earlier quoted context omitted.

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.

Except AMD owns x86_64 https://en.wikipedia.org/wiki/X86-64#Licensing Rosetta doesn't translate i386 btw.

x86_64 is obviously derived from original x86 and is a rats nest of who owns what. The SSE3/4 extensions (which are supported by Rosetta 2) are obviously in Intel's camp.

Re: About the Rosetta Translation Environment

#124

Post by monocasa » Tue, Jun 23, 2020, 6:02 PM UTC

ATsch wrote: post #112

underdeserver wrote: post #14

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

Historically that work is similar to Transmeta's cores, and IBM's DAISY before that for anyone wanting to dig in further.

Someone reverse engineered large parts of the Transmeta crusoe here:

https://www.realworldtech.com/crusoe-intro/

https://www.realworldtech.com/crusoe-exposed/

DAISY was open sourced at one point, but I haven't been able to find a mirror of it. I wish companies would strive to keep their URLs stable. : \

Re: About the Rosetta Translation Environment

#125

Post by monocasa » Tue, Jun 23, 2020, 6:06 PM UTC

BeeOnRope wrote: post #121

monocasa wrote: post #95

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…

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.

Expect you'd need to do that with every single store since the x86 instruction stream doesn't have those semantics embedded in it.

That'd kill your memory perf by at least an order of magnitude, and kill perf for other cores as well. It'd be cheaper to just say "you only get one core in x86 mode". Essentially you'd be marking every store as an L1 and store buffer flush and only operating out of L2.

Re: About the Rosetta Translation Environment

#126

Post by 013a » Tue, Jun 23, 2020, 6:11 PM UTC

proninyaroslav wrote: post #77

haxxorfreak wrote: post #51

Earlier quoted context omitted.

I'm optimistic and while the constant references to ARM as "Apple Silicon" make it sounds proprietary I see it as an example of Apple following Jobs' goal of "skating to where the puck will be". Microsoft is toying with the same transition with Windows 10 ARM builds and the Surface Pro X, and the news yesterday about an ARM-based supercomputer taking the TOP500 crown are all signs that ARM is the future. It will take…

Can you install something other than Windows 10 on Surface Pro X? I think not. There may be hackers who can crack these things, but this is not an ideal solution. There will also be problems with the drivers, I'm sure of that. Mac is waiting for the same fate.

You can install Linux on an SPX [1]

It sucks, but that's less on Microsoft and more on a combination of Linux having bad AArch64 support, and Linux having bad tablet support.

[1] https://twitter.com/Sonicadvance1/status/1192289419572563968

Re: About the Rosetta Translation Environment

#127

Post by monocasa » Tue, Jun 23, 2020, 6:12 PM UTC

AlphaSite wrote: post #104

Someone wrote: post #78

Earlier quoted context omitted.

AAA games spend lots of times inside system libraries. Porting those to native could be enough to get acceptable performance. So, chess could be more of a challenge for emulation than AAA games (but probably less of an issue, as it would be easily ported, and have fewer users, anyways)

It would be extremely bizarre if x86 programs are linking against arm libraries.

Apple has said that a Rosetta process is entirely x86_64 client code, including shared libraries, but I suppose that might be a "what's good for the goose isn't good for the gander" style white lie.

Re: About the Rosetta Translation Environment

#128

Post by monocasa » Tue, Jun 23, 2020, 6:14 PM UTC

numpad0 wrote: post #83

cpuguy83 wrote: post #19

Earlier quoted context omitted.

Apple mentioned they are specifically "working with Docker to support 'these things' in coming months". Confirmed with some Docker folks they are working on "something". All very nondescript, but they said they can't talk about it yet.

So I had to look this up: Docker do not rely on VT-x. If kernel has cgroups it runs. Hypothetically it could run natively on Windows NT, Linux, Darwin, Solaris, etc if it ported for appropriate APIs. However, most Docker containers contain x86_64 Linux binaries, so the runtime environment has to be binary compatible with x86_64 Linux. Thus, instead of going through the pain similar to WSL1, Docker people just spin up…

Docker on mac does rely on virtualizing a full linux kernel, and xnu doesn't have containerization APIs to do anything different.

> So if ARM macOS runs an x86_64 Ubuntu VM it also means Docker runs.

So far we haven't seen anything like that happening. The State of the Union talk yesterday went as far as running a uname -a just to show that it was an aarch64 debian they were running.

Re: About the Rosetta Translation Environment

#129

Post by monocasa » Tue, Jun 23, 2020, 6:17 PM UTC

jeffbee wrote: post #99

underdeserver wrote: post #98

Earlier quoted context omitted.

You'll still have the address of the fault in si_addr. Addresses are addresses, both in AMD64 and ARM64. What's the difference?

Maybe I'm just imagining things, but if I have a map from PC to function or line and Rosetta rewrites all my functions then I have a problem unless the Rosetta output is by some miracle exactly the same length as the input.

They can keep a translation table around for fixing up what were the original instruction addresses. I've done that for writing emulators before. It ends up looking like DWARF.

Re: About the Rosetta Translation Environment

#130

Post by monocasa » Tue, Jun 23, 2020, 6:19 PM UTC

Angostura wrote: post #59

DCKing wrote: 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…

FWIW they showed the latest Tombraider game running on Rosetta on a dev Mac said to be using the ARM chip from the high-end iPad. It ran pretty well. Not sure if I would quite count this as AAA

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