‹ BackHN Continuity

Thread

The scourge of x86 emulation

295 points · 100 comments · dagmx

  1. modeless · · focus · HN ↗
    As noted in the article, Apple solved this problem six years ago by simply adding an x86-compatible memory ordering mode to their chip when x86 emulation became important. Yet another way Apple's chips lead the industry.
    1. saagarjha · · focus · HN ↗
      Well well well “modeless” has decided to finally see the light of modes
      1. tancop · · focus · HN ↗
        Arm was never modeless. Thumb is a separate encoding with different instruction semantics and Jazelle ran Java bytecode. Both of them need a special branch instruction to enter. What they don't have is legacy modes like real, v8086 or native 16/32 protected that have no reason to exist when a CPU in long mode can run 16 and 32 bit code (in compatibility sub mode) just fine.
        1. sgerenser · · focus · HN ↗
          It was a joke based on the commenter’s username.
    2. gavinsyancey · · focus · HN ↗
      And as noted in the article, while that helps a lot with most of the issues, there are some corner-cases they still don't handle.
      1. MBCook · · focus · HN ↗
        Yeah, I thought that was interesting. Knowing Apple they must’ve profiled a ton of code and decided the hit from not “fixing“ that wasn’t worth enough.

        The M chips were already so much faster then the Intel chips Apple was using before (except on Mac Pro maybe) that it was probably still a net win.

    3. karel-3d · · focus · HN ↗
      The word "simply" is doing a lot of work there
    4. mitxela · · focus · HN ↗
      A legitimate benefit of vertical integration. They control their own CPUs so they can just do that. Linux has to run on whatever it's given.
    5. astrange · · focus · HN ↗
      It's not the only such CPU, Fujitsu's also have TSO.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.