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
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
