The scourge of x86 emulation

(fex-emu.com)

107 points | by dagmx 4 hours ago

3 comments

  • dagmx 2 hours ago
    For reference , Fex is a translation framework for x86 to ARM much like Apple’s Rosetta2 and Microsoft’s Prism.

    Valve sponsor development as it’s also the way the new Steam Frame supports x86 games. It’s also being used (as a fork) in Crossover Beta to replace the use of Rosetta2.

    • MiroslavPokorny 1 hour ago
      Why doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ?

      THen they wouldnt require any emulator for any new compiles.

      • rwmj 46 minutes ago
        I don't know, but assumed that Valve doesn't require studios to recompile their software or use any special tooling, it's basically just packaging of existing executables. This is also why they do Windows on Linux emulation.
      • account42 9 minutes ago
        Because even with their effective monopoly they don't have the power to bully developers into doing whatever suits Valve. And it would be disastrous for the industry if they did.
      • swiftcoder 45 minutes ago
        > Why doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ?

        They still have to support the entire back-catalog. It's not reasonable to expect thousands of existing games to port to ARM

        • DanielHB 5 minutes ago
          This is what Android does with Dalvik/Android Runtime. Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.

          With the compilation making use of the native instruction set supported for your device, so it can make use of newer arm instructions on newer devices while still supporting older devices.

          This is the major reason app installation is so slow in Android compared to iOS (which pre-compiles everything). But it also greatly improves app compatibility with older versions.

          There is no way Valve would be able to convince all the myriad of game engine developers to support a proprietary (or even open source) bytecode format even in the future. Best they could do is make it an opt-in.

          Android only pulled it off because Google provides the "engine" (Android SDK) for all apps made for the platform and it did from the start.

          And even so, most Androids games actually bypass this system entirely and just hand-compile to native binaries anyway. Because, again, the game engines don't want to support this bytecode format and google doesn't offer a C++ toolchain themselves.

      • cwillu 41 minutes ago
        Several games in their library are actually just game updater/launcher binaries, which manage their associated game assets and binaries externally.
      • matheusmoreira 49 minutes ago
        Existing games will not be recompiled for the new bytecode target, and they want all of those games to work regardless.
      • SSLy 26 minutes ago
        because there's no gaming-oriented toolchain for it
  • asksomeoneelse 1 hour ago
    Great article ! This is the kind of content I always hope to find on HN's front page.

    I really wonder how things are organized at Apple to allow for vertical integration to work so well. That feature alone must have involved so many people from so many different teams.

  • modeless 1 hour ago
    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.
    • saagarjha 1 hour ago
      Well well well “modeless” has decided to finally see the light of modes
    • gavinsyancey 25 minutes ago
      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.