This approach will help with none of these
Don't underestimate the community -- a lot of Hackintosh (and emulation) stuff is done for the "just because I can" reasons, and getting a fully emulated ARM Mac working enough for any sort of actual use would be a huge win even if it's slower than their hardware and not 100% complete (just like Hackintoshes usually are.)
pretty cool
I've been thinking about resurrecting my machines with older versions of osx - I'll have to figure out how to boot say 10.11 or 10.12
https://www.nicksherlock.com/2020/04/installing-macos-catali...
one cool thing is - once you have it installed, you can clone it freely and even remote log into several at once.
I believe they even figured out how to run them on those 32-core or 64-core amd threadrippers.
Not long after I got a relatively successful hackintosh going (read: accelerated graphics and working audio), which, besides Linux, helped brew my respect for Unix, BSD, and unique macOS internals.
Altogether it lead me to purchase roughly 5 Macs over the years. I recently got back into it for fun, and the scene is thriving. Will be interesting to see what happens post-AS.
Doing things for the heck of it is, for some reason, a great motivator and educator.
Add: actually never say never. Consoles with custom GPUs have been very successfully emulated. So maybe someday.
I'm less convinced—it sounds like he was largely reusing the setup that can semi-boot iOS (which is of course also totally undocumented, but has had many years to be studied.)
It's still a cool accomplishment, I just don't think it necessarily portends great things.
They are also used when one wants more cores than are possible on Apple hardware. If you want a build engine for a medium to large sized compiled language project, Apple has no options that make economic sense, since a Ryzen Threadripper will beat everything else hands down. The same is true of every other embarrassingly parallel, linearly-scaling compute problem.
In such cases, the "speed" of Apple's own silicon doesn't help at all.
Plenty of people who want MacOS but cannot afford the official Mac will use it instead.
I could afford to buy hardware from Apple, but why would I when the cost/performance ratio for an embarrasingly parallel compute task like compiling is so much worse?
Emulating ARM on x86-64 is doable, but it has dramatically more overhead. It’s doubtful that a high core count would be enough to overcome this relative to just using Apple silicon.
Then again maybe they just have a good JVM and that solves most of the problem for Android apps?
Does anyone know what these instructions are? And could you not trap and emulate them if the hypervisor detects an invalid instruction?
Rosetta 2 != Rosetta
We practice all day for accuracy.
_If you really need to_, Huawei provides the ExaGear Server translator for Linux at https://www.huaweicloud.com/kunpeng/software/exagear.html , which allows to run x86 and x86_64 apps on an arm64 Linux system, including Docker containers for their customers. That translator works pretty well in most cases.
Note however that you need to create a Huawei account to download this.
For Windows guests:
Run arm64 Windows, the JITs to run x86(_64) apps are included with the OS.
The VHDX for virtual machine use can be downloaded from https://www.microsoft.com/en-us/software-download/windowsins...
Why would I want to use a (presumably) closed-source solution from Huawei whose documentation is only in Chinese, when I could instead use a well-known open source project with plentiful documentation in English?
As such, might be a better approach to start with the set of devices exposed by Qemu. :-)
For Apple A11 though, going from 8.3 -> 8.2 is much easier... and doable through a patch on fault method.
Does anybody know where one can learn about how these people approach and learn about the inner workings of what is essentially a black box from the outside?
I guess Jonathan Levin’s Books should then be mentioned here.
However, that then leads to the question how Levin reversed this black box.
