David,
I have been having a go at building ProofPower with the latest updates. Here is some miscellaneous feedback:
1) Are these two errors in the configure output harmless? (This is on Mac OS X using Apple?s Xcode tools.)
checking for __attribute__((visibility("hidden")))... no clang: error: unsupported option '-print-multi-os-directory' clang: error: no input files checking that generated files are newer than configure? done
2) SML90.explode crashes. The following patch fixes this:
--- a/basis/SML90.sml +++ b/basis/SML90.sml @@ -81,9 +81,8 @@ struct fun ord "" = raise Ord | ord s = Char.ord(String.sub(s, 0))
fun chr i = str(Char.chr i) - (* Because single character strings are represented by the characters - themselves we just need to coerce String.explode. *) - val explode: string -> string list = RunCall.unsafeCast(String.explode) + + val explode: string -> string list = map str o String.explode val implode = String.concat
type instream = TextIO.instream and outstream = TextIO.outstream
3) If I configure with ?enable-intinf-as-int, make compiler fails:
Use: basis/IMPERATIVE_IO.sml Use: basis/ImperativeIO.sml Use: basis/TextIO.sml Exception- InternalError: findEntry - not found raised while compiling
make[3]: *** [polyexport.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [compiler] Error 2
Not being able to build with ?enable-intinf-as-int isn?t a stopper for me, but when I press on, I am getting a segfault somewhere in the ProofPower parser generator. I will report again when I have isolated that.
Regards,
Rob.
On 16 Sep 2016, at 13:24, David Matthews <David.Matthews at prolingua.co.uk> wrote:
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 at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml