RISC-V fans will be interested in this one. felix86 has been announced as a new project with a first release available that enables you to run x86-64 Linux programs on RISC-V processors on Linux.
That was a fascinating read. Thank you. I suppose it is possible that there could be a RISC-V extension for this.
As the article states though, this is an ancient x86 artifact not often used in modern x86-64 software. If the code generated by GCC and Clang does not create such code, it may not exist in Linux binaries in practice. Or perhaps the decider is if such code is found inside Glibc or MUSL.
As this is a JIT and not an AOT compiler, you cannot optimize away unused flags. I expect the default behaviour is going to be not to set these flags on the assumption that modern software will not use them. If you just skip these flags, the generated RISC-V code stays fast.
You could have a command-line switch that enables this flag behaviour for software that needs it (with a big performance hit). This switch could take advantage of the RISC-V extension, if it exists, to speed things up.
Outside of this niche functionally though, it seems that the x86-64 instructions are mapping to RISC-V well. The extensions actually needed for good performance are things like the vector extension and binary bit manipulation.
Linux benefits from a different kind of integration. The article states that Apple is able to pull-off this optimization because they create both the translation software and the silicon. But the reason they need to worry about these obscure instructions is because the x86-64 software targeting macOS arrives as compiled binaries built using who knows what technology or toolchain. The application bundle model for macOS applications encourages ISVs to bundle in whatever crazy dependencies they like. This could include hand-rolled assembler you wrote decades ago. To achieve reliable results, Apple has to emulate these corner cases.
On Linux, the model is that everybody uses the same small subset of compilers to dynamically link against the same c runtimes and supporting libraries (things like OpenSSL or FreeTyoe). Even though we distribute Linux binaries, they are typically built from source that is portable across multiple architectures.
If GCC and Glibc or Clang and MUSL do not output certain instructions, a Linux x86-64 emulator can assume a happy path that does not bother emulating them either.
Ironically, a weakness in my assumptions here could be games. What happens when the x86-64 code we want to emulate is actually Windows code running on Linux. Now we are back to not knowing what crazy toolchain was used to generate the x86-64 and what instructions and behaviour it may depend on.
That was a fascinating read. Thank you. I suppose it is possible that there could be a RISC-V extension for this.
As the article states though, this is an ancient x86 artifact not often used in modern x86-64 software. If the code generated by GCC and Clang does not create such code, it may not exist in Linux binaries in practice. Or perhaps the decider is if such code is found inside Glibc or MUSL.
As this is a JIT and not an AOT compiler, you cannot optimize away unused flags. I expect the default behaviour is going to be not to set these flags on the assumption that modern software will not use them. If you just skip these flags, the generated RISC-V code stays fast.
You could have a command-line switch that enables this flag behaviour for software that needs it (with a big performance hit). This switch could take advantage of the RISC-V extension, if it exists, to speed things up.
Outside of this niche functionally though, it seems that the x86-64 instructions are mapping to RISC-V well. The extensions actually needed for good performance are things like the vector extension and binary bit manipulation.
Linux benefits from a different kind of integration. The article states that Apple is able to pull-off this optimization because they create both the translation software and the silicon. But the reason they need to worry about these obscure instructions is because the x86-64 software targeting macOS arrives as compiled binaries built using who knows what technology or toolchain. The application bundle model for macOS applications encourages ISVs to bundle in whatever crazy dependencies they like. This could include hand-rolled assembler you wrote decades ago. To achieve reliable results, Apple has to emulate these corner cases.
On Linux, the model is that everybody uses the same small subset of compilers to dynamically link against the same c runtimes and supporting libraries (things like OpenSSL or FreeTyoe). Even though we distribute Linux binaries, they are typically built from source that is portable across multiple architectures.
If GCC and Glibc or Clang and MUSL do not output certain instructions, a Linux x86-64 emulator can assume a happy path that does not bother emulating them either.
Ironically, a weakness in my assumptions here could be games. What happens when the x86-64 code we want to emulate is actually Windows code running on Linux. Now we are back to not knowing what crazy toolchain was used to generate the x86-64 and what instructions and behaviour it may depend on.