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.



> 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

Reply via email to