Performance would have been much better if they did not emulated x86 on arm.
back
1 comments
How would you suggest that they go about doing this?
Port qemu-arm to iOS and run it in syscall emulation mode. You’d then need to implement translations for all the Linux system calls. This would make it quite similar to Windows Subsystem for Linux.
No way Apple will let you put that on the App Store though!
qemu relies on being able to JIT compile, which isn't allowed in the sandbox.
You can JIT compile in the sandbox with certain entitlements that Apple is happy to grant you, as long as you don’t try to put your binary on the App Store.
Care to show how to do this or even an example of this being done?
Extraordinary claims require proof.
Sure. If you have an Xcode and an iOS device on hand, make a new project and cast “\x00\x00\x80\x52\xc0\x03\x5f\xd6” (or your own assembly) to an int (*)(), and check to see if the return value is 42 in the debugger.
That’s not getting the JIT entitlement as your prior comment claimed. ;)
Shouldn't they just run Linux on arm? Seeing as Linux already supports it?
You’re going to have to be more specific; what exactly do you mean by “run Linux on ARM”? Sure, I can compile Linux for ARM and put it in an app, and provided I am careful, I can bootstrap the kernel and get Linux up and running. But what do I do from here? I have Linux “running”, but it no container app around it anymore to allow interaction with iOS. (This is, of course, considering that you have gotten codesigning to work correctly and have full control over when the kernel JITs).
I mean they should have just emulated Linux on an arm processor, seeing as the hardware (Apple A-series) is already arm-based I assume that wouldn't cause as many performance issues as emulating a completely different architecture, x86.
I assume, based on the first comment in this chain - I'm not experienced with emulation of different processor architectures.
Like I said, “emulat[ing] Linux on an arm processor” is not as simple as you make it seem. To do something similar on x86, that is, run Linux on your Intel processor, you need virtualization software that acts as a hypervisor. iOS devices do not provide the capabilities to write software like this, so doing any sort of emulation in this way would not really work.
I believe what the OP is trying to say is, what if this weren't an x86 emulator, but rather just a shim which allows ARM native assembly code to be being run in the context of iOS, only with traps that allow access to a kind of HAL within the context of the App .. meaning that instead of loading up an x86 image containing the Linux kernel and user space, it'd load an ARM-based Linux kernel and does the trapping required to give a native runtime experience .. underneath the iOS layers.
That would be quite feasible and not at all impossible. And given that the original author of this amazing project has the balls required to pull off a JIT-type scheme to do x86-ARM translations, quite probably within their reach.
I don't think it's possible to do something like on iOS, because you can't write to executable pages (IIRC making a page executable requires the "dynamic_codesign" entitlement, which some Apple apps have).
There would need to be some sort of emulation later in place at some point, because traps into the kernel would need to be intercepted by the application and this just isn’t possible (at least, to my knowledge) in any application that just straight up runs unmodified native binaries. So it really doesn’t matter whether the author emulates x86 or ARM because there’ll be a performance hit either way.