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