101–110 of 249 posts
Earlier quoted context omitted.
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...
Apple ARM will support kexts. https://developer.apple.com/documentation/apple_silicon/inst...
Does anyone have any insight into the business logistics involved in a transition like this? I presume Apple has done maintenance on transitioning desktop OS X to ARM as an option for a very long time. How many years ago would they have had to decide that was the direction they were going to make it reality? 2015? How many people would have been working on it? How many billions of dollars? How does the cost of develo…
Porting from PPC to x86 was arguably more difficult as a lot more of the framework code had endianness assumptions baked in.
Earlier quoted context omitted.
Docker on ARM will work, Docker for x86 will not. The State of the Union showed a demo of Hypervisor.framework with Parallels, and they made it clear that Debian AArch64 was running (uname -a). Since Docker runs inside a VM on the Mac, it'll have to be an ARM VM with ARM containers. (Presumably, running docker build with your Dockerfile will make it work just fine, unless you need x86 specific libraries).
Could you run the linux docker machine on aarch64 and just the docker container/process on JIT-x86? The majority of syscalls doesn't care about architecture, do they? And the OS should theoretically be agnostic to the machine code the application is written in. Probably requires some cooperation on part of the linux docker host. Did I get the idea across? You would go to hell for implementing that either way
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…
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)
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.
If Apple wants to, they could even support selected third-party libraries that way.
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…
I would assume that a more strict memory model would be enabled only for processes that needs it (ie, Rosetta translated ones). So a cpu-flag is set/cleared when entering/exiting user mode for those processes. Does this require a separate/special cache coherency protocol? A complete L1d flush when entering/leaving these processes (across all CPUs)? Not and expert in this field and it feels complicated for sure. Is it worth it for just emulating "legacy" applications during a transitional period? Perhaps Apple can pull it off though.
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: >…
It could come down to licensing issues. The ISA extensions for AVX/AVX2/AVX512 are under different licensing and to my knowledge, Intel/AMD are the only legal license holders (and Intel would be the only holder were it not for the arrangement between Intel and AMD formed due to x86_64)
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.
Rosetta doesn't translate i386 btw.
>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?
I think you'd be hard pressed to find programs using AVX that didn't do some sort of feature check. While AVX debuted with Sandy Bridge in 2011, Intel's Celeron/Pentium branded CPUs don't support those instructions (or didn't for a long time).
Earlier quoted context omitted.
They haven’t clarified if Docker is ARM all the way down or if they are using QEMU to emulate x86 somewhere on the stack.
They wouldn't need qemu anywhere either way; they have their own binary translator.