3 ms·

wouldn't one of the real answer to this x86 emulation on ARM? is the reason why it's not happening because of patents only?

• guitarbill 9y ago
  Emulation always involves a hefty performance hit. Many emulators make huge trade-offs in accuracy vs performance, or are only possible because of orders of magnitudes difference in performance. But you don't really want to trade accuracy for most x86 business cases. That's why (backwards) compatible tech is so alluring (x86-64, x86, Eclipse MV/8000, S/360, etc), whereas breaking changes aren't (Itanium et al). So you need either dynamic binary translation, or a processor that can support both x86-64 and whichever ARM instruction sets. Maybe it's possible, but there are two hurdles. Doing that for a gigantic instruction set (x86-64) on a processor with a modest instruction set is going to be challenging. For dynamic binary translation, it's correctness and speed. For supporting two ISAs (somehow), it'd be crazy hard to get the micro-codes right for everything. And most applications aren't multi-threaded, so you're limited by single-core performance. And that has been x86's bread and butter for decades (also POWER/SPARC I guess), whereas ARM has been power efficiency, multiple cores, specialised cores/silicon. (Edit: This also explains why neither Intel nor ARM has any incentive in making a chip that supports both ISAs, even if it took the dreaded mode-bit) But if it could be done, then yes, probably patents. IBM brought Transitive Corp, who's tech Apple had licensed for Rosetta (dynamic binary translation PowerPC -> x86, although even that didn't support PowerPC 970). Of course, IBM then did fuck-all with the tech and people of that acquisition, but they still have that IP.
  • make3 9y ago
    i thought Microsoft had a system of the sort working, to make "legacy" (aka x86) work on an eventual return to ARM with the Surface notebook/tablet
• snvzz 9y ago
  On ARM? Not RV64G?