Mill Computing, Inc. Forums The Mill Markets Is binary Translating i386/x86_64 to mill code practical?

  • Author
    Posts
  • mikeakers
    Participant
    Post count: 2
    #1319 |

    Thinking about laptop/desktop applications for The Mill I’m wondering how practical it would be to do binary translation from something like i386 or x86_64 to mill instructions? Would there be too much of a mismatch between the register file that the source binary is expecting and the belt? Seems like lots of other problems would crop up too.

    I’m thinking of something along the lines of Apple’s Rosetta (PPC->x86) translator or DEC’s FX!32 (i386 -> Alpha)

    I recently heard about a project that converts from compiled X86_to LLVM IR, which can then be compiled into a new binary. Maybe this is an approach that would work if there’s an LLVM backend for The Mill. See https://github.com/trailofbits/mcsema for more.

    The Mill is a very interesting design, keep it up!

  • Ivan Godard
    Keymaster
    Post count: 460

    Binary translation is as practical to the Mill as to any other architecture; the task is essentially the same for any S-to-T translation, including the Mill on either end. You un-model the source to an abstract representation similar to a compiler’s IR, optimize that to a fair-thee-well to remove redundant state setting (like condition codes), and then do a normal target code gen from the result.

    The difficulty, for all translations, is when the source code embeds implicit assumptions about the platform. Self-modifying code is obvious, but code often assumes word and pointer sizes, endianness, the presence (and behavior) of I/O devices, and so on.

    There are platform dependencies beyond the ISA too. You may have a Windows x86 binary and translate it to execute on a SPARC or a Mill, but without a Windows OS to run on it’s not going to be able to draw pictures on the screen.

    So the issues with binary translation are roughly the same as for any other port even if you have the source to recompile. If a given code can already successfully run on big- and little-endian machines using both 32-bit and 64-bit models then it is probably port-clean enough to translate well. But even with perfect ISA translation, the port may not succeed.

  • eversl
    Participant
    Post count: 3

    If you manage to compile Qemu or Bochs or some other emulator you should be able to run a complete x86 operating system. It will cost you a great deal in terms of speed though, unless you go out of your way to produce heavily optimised mill code from the x86 instructions in a JIT-like fashion. That is essentially what Transmeta did with their Crusoe processors.
    (And maybe that Soft Machines CPU as well)

    From what I understand so far from the published materials the Mill seems designed well enough to not suffer from the same pitfalls that prevented the Transmeta chips from really performing as promised (Large VLIW instruction words, small 64MB translation cache, low memory bandwidth…). On top of that it would be possible to provide a ‘super speed mode’ that runs applications compiled to the native Mill instruction set right inside of an x86 (or x64) Linux or Windows.

    Sounds like that would make for an appealing desktop or server product. Maybe such a system would benefit from some extra instructions on the Mill CPU that take care of some performance critical stuff (TLB lookups or fast x86 register restores come to mind).

    Would you consider adding some instructions for this purpose?

    • Ivan Godard
      Keymaster
      Post count: 460

      Probably not.

      Directly simulating a general-register machine requires a way to preserve updateable state that in the target would be in registers. The only updateable state on a Mill is memory, so performance would be abysmal. Then there would be problems providing the x86 memory semantics, which are weaker than a Mill.

      But more to the point: binary translation has gotten pretty good these days, so there seems little reason to directly interpret any other chip’s native instruction set. We expect to include a (verrry slow) interpreter for use with device ROMs that contain x86 code when the device is needed by the BIOS. Or maybe we can avoid the problem some other way; hard to tell until we get further along.

      • eversl
        Participant
        Post count: 3

        Indeed, binary translation would be the way to get reasonable (or even good) speed while running a nonnative instruction set. Its just that there are probably lots of corner cases that would require complete emulation of the x86 cpu and system (precise exception semantics and probably the x86 memory addressing) at least some of the time.
        Anyway, this has been done before on multiple CPU architectures, so there is probably also a way to do it with a mill CPU. It just made me think that the wholly admirable goal on which Transmeta was based — running x86 code on a simpler, low power CPU by doing all of the instruction decoding and scheduling in software — might be within reach as just one of the possible applications of a mill CPU. Running code compiled for mill will be even better, but that requires recompiling from source and might not work out of the box, at least initially, so having the option of x86 binary compatibility probably helps to make inroads in markets like desktop and server systems.

        It’s not a trivial thing to build a fully compatible binary translator however, so I can imagine this is not yet on the radar for some time to come.

        • Will_Edwards
          Moderator
          Post count: 97

          Its possible that the lock-in of legacy proprietary apps is no longer the barrier to new ISAs that it used to be? The next generation of OS are being built around running a browser and nothing else (Chrome OS, Firefox OS etc). The other day I tried to run an old program on the latest version of Windows and it wouldn’t run, and I had to resort to running it in Wine on Linux (where it was quiet happy!).

          That aside, business is not my forte so lets keep things technical 🙂 Binary translation e.g. McSema from x86-64 to LLVM IR would then allow the code to be optimized and targeted by the Mill LLVM IR. For on-the-fly emulation of individual programs running in the host environment you could imagine something more like the hot translation that Valgrind does. But to emulate a whole OS (memory management and all) likely needs a conventional VM approach.

          • eversl
            Participant
            Post count: 3

            I agree that with web-apps running in javascript and wide use of java and other VMs legacy binaries are much less of an issue now. If Google or someone else decides to build a Mill-based chromebook or android device we would all be quite happy. And if x86 compatibility becomes an issue, it will be a matter of writing the code for it. It’s been done before…

            But I take it from both of your reactions that x86 (or any other CPU) compatibility is not part of the plan for Mill CPUs (like the SoftMachines guys clearly do). If the power and speed numbers come out as planned I guess there’s plenty of opportunity for a Mill anyway.

You must be logged in to reply to this topic.