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.matth...@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@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