• thingsiplay@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    @keenkoon I wonder if it would make sense to store a regular compiled code and the extensions into one binary. And only load the extensions if the binary is executed on such an architecture, otherwise be compatible to older architecture.

    • Excel@lemmy.megumin.org
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 year ago

      This is why .NET code compiles to platform-independent binaries that get JIT translated to machine code and optimized for the target CPU. Developers don’t need to do anything (the applications don’t even need to be re-compiled), they will just get conditionally optimized when appropriate.

    • VonTum@programming.dev
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      1 year ago

      This is the only way really to move forward with ISA extensions.

      Though, I think for this update we don’t need to be too concerned. Since it changes the code in such an extensive way, compiler writers will be strongly incentivised to produce this duplicate path themselves. Instead of letting the burden of dispatching fall on the programmer like with AVX and friends

    • o11c@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      For an extension like this - unlike most prior extensions - you’re best off with essentially an entirely separately compiled copy of the program/library. So IFUNC is a poor fit, even with peer optimization.