I have now pushed a major update to git master which is the result of work going back to the beginning of the year. It covers a number of areas but largely the code-generator and the run-time system interface.
The basic design of much of the low-level parts of Poly/ML dated back to the early days. While it has changed a lot in detail the overall structure has remained the same. The idea was to bring the whole thing up to date.
The run-time system interface has been redesigned and instead of a vector of entries to the run-time system the ML code now uses a form of foreign-function interface to call individual functions. The advantage is that it is much easier to add new functions. In addition when building an executable it is possible for the linker to select only the parts of libpolyml that are actually required for the application, at least if the static library version is used. It should be possible to adapt the foreign-function interface it uses to speed up calls made using the Foreign structure, although that's not done at the moment.
The code-generator has been rewritten particularly the register assignment. The previous version had been the result of a series of adaptations to new architectures over the years. The new version focusses solely on the X86. I'm still working on this. Doing this has needed a temporary, slow, code-generator which is why it has taken until now to push this to git master.
The representation of strings has been simplified. Previously, single character strings were represented by the character itself as a tagged value. This was largely a relic of SML 90 which didn't have a separate char type. That has been removed and all strings are now represented as a vector of bytes. This speeds up string operations since the code no longer has to consider the special case.
SSE2 instructions are now used for floating point on the X86/64. Floating point support in the new code-generator is rudimentary at the moment and not to the same extent as the previous code-generator.
The handling of return addresses from functions has been simplified. A consequence of this is that when pieces of code are compiled they are stored in a separate area of memory rather than in the general heap and not garbage-collected. It is no longer possible to get an exception trace so PolyML.exception_trace has no effect. The debugger handles this much better anyway.
Although the focus has been on the X86 the portable byte-code interpreter has been improved and is significantly faster.
The system has had some basic testing but there are bound to be bugs in something as complex as this. I'm also continuing to work on improvements. When testing this it is essential to run "make compiler" at least once and generally twice to build the new compiler and then build the compiler itself with the new compiler.
David