• hellofriend@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    2 days ago

    So, when I think “emulation” I usually consider it to be software emulating a hardware device (e.g. the original Gameboy, audio cards for legacy programmes that required audio cards, etc.). What they’re describing in the article is what has been described to me as being an abstraction/compatibility layer. So my questions are: 1.a. Is that really what this is or is it actually an emulator? b. If the latter, what makes it an emulator rather than a compat layer? 2. In general, how much do the two concepts interact? E.g. separate concepts entirely, ends of some continuum, etc.

    • Mihies@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      2 days ago

      To me it sounds like what Java or .NET JIT does. I doubt it falls strictly into emulation 🤷‍♂️

      • LeFantome@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 day ago

        In Java or .NET, the JIT is still going from a higher level abstraction to a lower one. You JIT from CIL (common intermediate language) or Java Bytecode down to native machine code.

        When you convert from a high level language to a low level language, we call it compiling.

        Here, you are translating the native machine code of one architecture to the native machine code of another (x86-64 to RISC-V).

        When you run code designed for one platform on another platform, we call it emulation.

        JIT means Just-in-Time which just means it happens when you “execute” the code instead of Ahead-of-Time.

        In .NET, you have a JIT compiler. Here, you have a JIT emulator.

        A JIT is faster than an interpreter. Modern web browsers JIT JavaScript to make it faster.