By: Exophase (exophase.delete@this.gmail.com), August 10, 2014 10:20 am
Room: Moderated Discussions
dmcq (dmcq.delete@this.fano.co.uk) on August 9, 2014 10:10 am wrote:
> Well if it is hypothetical perhaps it will also have the special Loongson instructions to help with
> emulating an x86. One can always posit these sorts of things. Personally I think Apple directly
> replacing the x86 in the Macs highly unlikely and I don't see them emulating the x86, though they
> might try to develop the iPad and Ax processors to make it just seem the better choice..
>
I think it won't because I think the special Loongson instructions aren't that useful, especially for ARM64. They made a big deal about it because without them qemu at the time was producing really terrible code. There's an overview here:
http://www.slideshare.net/syuu1228/hardware-assited-x86-emulation-on-godson-3-5040660
Here's what they had and why it's not really that useful:
1) Instructions to generate flags (in addition to separate instructions for doing the operations). The qemu code gen for flag generation was REALLY bad, dozens of instructions, and AFAIK there wasn't liveness analysis for avoiding it. Besides that ARM64 has mostly compatible flags so a lot of it can be kept native, especially if that analysis can deeply cross blocks.
2) Assistance for x87 stack pointer and 80-bit. x87 is probably rarely used on useful x86 Mac code these days, but if you're maintaining a stack pointer in translated code you're probably doing it wrong anyway, you can make the stack pointer part of the compile time block status.
3) MMX/SSE/SSE2 support, which maps a lot better to ARM64 NEON than to what Loongson had at the time. Some new instructions for shuffles and a few other things might not hurt though. Now if the goal is AVX2 instead that's a very different story.
4) Extended addressing modes. Less of a problem with ARM64 since the addressing modes are better than MIPS.
5) Bounded load/store for segment emulation.. where is this coming up exactly? Probably wouldn't for MacOS X user mode.
6) Multiplication and division instructions that target GPRs. Again moot for ARM64.
7) Byte insertion and extraction. ARM64 already has the sort of insert/extract instructions they added, plus it goes further with shift + sign extension modifiers on some of the instructions.
8) A CAM for performing fast translation of guest to host branch targets. This one is actually pretty cool, and would have benefits outside of just emulating x86.
9) 128-bit load/store instructions to help save/restore x86 registers better. Again moot since ARM64 already has it.
> Well if it is hypothetical perhaps it will also have the special Loongson instructions to help with
> emulating an x86. One can always posit these sorts of things. Personally I think Apple directly
> replacing the x86 in the Macs highly unlikely and I don't see them emulating the x86, though they
> might try to develop the iPad and Ax processors to make it just seem the better choice..
>
I think it won't because I think the special Loongson instructions aren't that useful, especially for ARM64. They made a big deal about it because without them qemu at the time was producing really terrible code. There's an overview here:
http://www.slideshare.net/syuu1228/hardware-assited-x86-emulation-on-godson-3-5040660
Here's what they had and why it's not really that useful:
1) Instructions to generate flags (in addition to separate instructions for doing the operations). The qemu code gen for flag generation was REALLY bad, dozens of instructions, and AFAIK there wasn't liveness analysis for avoiding it. Besides that ARM64 has mostly compatible flags so a lot of it can be kept native, especially if that analysis can deeply cross blocks.
2) Assistance for x87 stack pointer and 80-bit. x87 is probably rarely used on useful x86 Mac code these days, but if you're maintaining a stack pointer in translated code you're probably doing it wrong anyway, you can make the stack pointer part of the compile time block status.
3) MMX/SSE/SSE2 support, which maps a lot better to ARM64 NEON than to what Loongson had at the time. Some new instructions for shuffles and a few other things might not hurt though. Now if the goal is AVX2 instead that's a very different story.
4) Extended addressing modes. Less of a problem with ARM64 since the addressing modes are better than MIPS.
5) Bounded load/store for segment emulation.. where is this coming up exactly? Probably wouldn't for MacOS X user mode.
6) Multiplication and division instructions that target GPRs. Again moot for ARM64.
7) Byte insertion and extraction. ARM64 already has the sort of insert/extract instructions they added, plus it goes further with shift + sign extension modifiers on some of the instructions.
8) A CAM for performing fast translation of guest to host branch targets. This one is actually pretty cool, and would have benefits outside of just emulating x86.
9) 128-bit load/store instructions to help save/restore x86 registers better. Again moot since ARM64 already has it.