Hacker News new | past | comments | ask | show | jobs | submit login

> using a usermode x86 emulator

So, iSH does this amazing stuff by x86 emulation. Aren't iOS devices arm based devices ? Why should they emulate x86 ? Isn't it easier to emulate arm64 linux instead ?

(I mean that arm64 binaries can run on arm64 devices. For example, consider wine which runs windows programs on linux/macos. Only x64 windows apps can run on x64 wine and only arm64 windows apps can run on arm64 devices. To run x64 windows apps on arm64 devices,you need qemu/other virtualization software)




Executing unsigned code on iOS is generally not feasible, which means that this would limit the set of programs you could run to a small prespecified (and signed) set of programs. (These apps exist already on the App Store; here's one: https://blink.sh). iSH can run user-created programs by emulating them. (Plus, with emulation we can run programs without modifying them because we can trap syscalls and such.) It would be nice if we could JIT compile code (since the interpreter is a bit slow compared to native code) or utilize hypervisor facilities, but that doesn't appear to be an option for now.


The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation), so you’re stuck using a pure interpreter, at which point there’s no real benefit to emulating the same architecture you’re running on.


> The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation)

Unless it’s JavaScript. I see a missed opportunity here: compile everything to ASM.js! :)

I’m only half-kidding.


It's been on our minds for a while, the major issues with this is that IPC between the app process and WebKit is like 100µs, so having the interpreter run isolated from the app process is hard. Plus loading WASM is not "free" (that is, essentially an instruction cache flush) because you need to generate a bundle that WebKit will then load, which is slow (although there has been work done in this area: https://www.youtube.com/watch?v=7JUs4c99-mo). So even if we did some sort of WASI thing where everything is going on in the browser, there are hurdles to overcome to make this viable. Plus the current interpreter almost certainly leaves performance on the table ;)


It’s so cool that you have actually considered it.

Imagine what developers could do if Apple loosened those restrictions a bit.


There may be with regards to maintaining memory ordering guarantees, we're looking into a couple of strange hangs that only reproduce on ARM. But yes, in general the choice of architecture does not matter much when interpreting.


Not quite true; some ISA are simpler to decode than other and/or have simpler semantics to implement (eg. not x87). I can pretty much guarantee that you could have gotten [slightly] better performance with an iSH-like approach targeting RISC-V or ARM64.

EDIT: added slightly. For all the OS calls which are 100% native, it wouldn’t matter.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: