BeamJIT for 32-bit ARM?

[Jesper Louis Andersen]

On Wed, Oct 21, 2020 at 6:49 PM Raoul Duke <raould@REDACTED> wrote:

> hah somebody should make a startup to make universal assembly code
> translator.
>
>
That was almost done historically. See e.g., FX!32[1] though it was
targeting the major x86 ISA at that point.

However, the more modern approach seems to attack the problem at a
different layer, probably because source code is more readily available and
thus avoids the need for a binary translation pass. LLVM's IR is
essentially a typed assembly language which is universal. Instruction
selection then decides what real machine instructions to map (tiles of) IR
ops to. Another example is Go's assembler, which derives from Plan9's
ditto. Here, the assembler is written such that a lot of the instructions
are common among all architectures and use the same coherent style. For
each architecture a specialized set is added to get access to them. This
means you can often get a new ISA working by targeting the common
instruction set first, and then blend in the more specialized and optimized
instructions later to make the architecture shine.

Real world examples there are prevalent:

* Apple uses a "bitcode" format for iOS, I presume a variant of LLVM IR. So
they can retarget the binary to a new hardware instruction at a later
point. It also gives good statistics on what instructions to add.
* Java's bytecode is a famous example of the above scheme.
* Microsoft's Managed code for the CLR does the same.

All provide the benefit of later translation if needed to optimize older
code. It isn't perfect, but neither is direct binary translation of
assembly. And higher level representations often have structures that are
easier to exploit. Though in the case of the JVM and the CLR the
translation is JIT with an interpretative step.

[1] https://dl.acm.org/doi/10.1109/40.671403
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201023/d6e54f3b/attachment.htm>