Hi Andrei,
It would be interesting to have another back-end but I really don't
think what you are suggesting is feasible. There are currently three
back-ends: native code for the X86(32/64), native code for the ARM64 and
byte code. The byte code is interpreted by part of the run-time system
and is used on architectures other than the X86 and ARM64 but it is also
used during the initial bootstrap on the X86 and ARM64.
Apart from a small amount of architecture-specific code, and of course
the interpreter in C++ for the byte code, all these back-ends make use
of the same run-time system support. The run-time system is intimately
bound up with the ML part of the system. They share a common view of
how values are represented: short integers are tagged, addresses are not
tagged, strings have a length word followed by byte data etc. Any new
back-end has to maintain these representations. Before you even think
about writing a new back-end you need to understand how all this works.
David
On 22/11/2023 18:39, Andrei Formiga wrote:
Hello,
Let's say I want to create a new backend for Poly/ML, generating code for a
virtual machine, for example the Erlang BEAM Virtual Machine. The backend
would not depend on the C++ runtime, because the runtime would be the
virtual machine.
From looking at the source code, the backend should generate target code
from the CodeTree. I could add a new directory to MLCompiler/CodeTree with
the new backend code, and add a GCode.beam.ML file to the MLCompiler
directory that instantiates the GCode structure correctly.
My question is about building the compiler with the new backend enabled.
How would I add the new backend to the build and then build the compiler
with this backend enabled? I have limited experience with autoconf and
automake (mainly as a user), so taking a look at configure.ac and
Makefile.am didn't give me clues on how to tie everything together. I also
see that there is a RootXX.ML file for each target architecture that
compiles the source files in order, but a comment in these files say they
were generated from the make files.
So any tips or pointers are appreciated.
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
