Poly/ML

polyml@lists.polyml.org

2 participants
711 discussions

Fixed precision int
by David.Matthews＠prolingua.co.uk 10 Feb '16

10 Feb '16

On 10/02/2016 16:18, Anthony Fox wrote: >> Can you provide some more information and try to narrow the problem down? There certainly shouldn't be bus errors or segmentation faults anywhere. > > I removed the files > > $POLYDIR/lib/libpoly* > > before doing an Poly/ML install and that seemed to fix things. OK. The libraries have the same version number as the last release so that may cause problems. I seem to recall reading that one was supposed to increment the version number just before a release but maybe it would be better to increment the version immediately after so that versions from git always have a different version from the last release. David

1 0

Fixed precision int
by David.Matthews＠prolingua.co.uk 10 Feb '16

10 Feb '16

On 10/02/2016 15:41, Anthony Fox wrote: > This is significant change. Would it be possible to make this user selectable? MLton has the command line flag > > -default-type intinf > > when IntInf is preferred for Int. Perhaps there could be a switch to "configure". It's really a question of how the basis library is built. > I had been programming on the basis that Int was arbitrary precision in Poly/ML. I certainly need IntInf in places and it was very convenient to not have to worry about this sort of thing. Having to use ?to? and ?from? functions is a nuisance. I?ve attempted to update my code for this change and the diff was > > 19 files changed, 334 insertions(+), 275 deletions(-) > > In itself this wasn?t too bad. However, after this I have less confidence in the robustness of the code. Poly/ML programmer?s have not needed to insert ?handle Overflow? before now, which is great advantage over ?performance obsessed? compilers. > > Anyhow, HOL4 doesn?t build using the FixedPrecisionInt branch. An early problem was due to Position.int no longer being the same as Int.int. Then I got a > > Segmentation fault: 11 > > error when trying to build a parser. This problem may be related to > > Bus error: 10 > > errors that I?ve been getting. For example, if I use polyc to compile > > val main = PolyML.rootFunction > > then the resulting program gives this bus error when trying to process anything (such as ?val x = 1;?). Can you provide some more information and try to narrow the problem down? There certainly shouldn't be bus errors or segmentation faults anywhere. David

1 0

Fixed precision int
by David.Matthews＠prolingua.co.uk 10 Feb '16

10 Feb '16

From the start int in Poly/ML has been arbitrary precision. After around thirty years I think it's time to make a change. The current plan is to introduce a fixed precision integer type and use that as the default int. Arbitrary precision will remain as LargeInt.int/IntInf.int. The reason for the change is that it is becoming clear that having arbitrary precision int as the only integer type imposes restrictions on the code both as regards the integer type itself but also more widely. The arbitrary precision type in Poly/ML is implemented using a tagged representation. Small values that will fit in 31/63 bits are represented as the value shifted one bit left and with the bottom bit set. Larger values are represented as pointers to arrays of bytes, either in the GMP format or Poly's own format. Since pointers are always word-aligned it's possible to distinguish the two forms by looking at the bottom bit. The "tag-bit" also serves another purpose. The garbage-collector can use it to distinguish pointers from non-pointers so all non-pointer values, e.g. bool, char and word, are represented using the tagged form. Arbitrary precision operations are handled directly by the code-generator. The idea is that when the values are small, as they usually are, the machine can execute the appropriate instruction directly. For example, addition is generated as an add instruction. It is preceded by a test on the tags and followed by a test for overflow. If the arguments were not tagged or the result overflowed there is a call into the run-time system. This emulates the instruction and returns with the result in the correct register. Emulation has limitations. Currently only (in)equality, comparison, addition and subtraction are emulated. Other operations such as multiplication and division involve calls to assembly code. This means that code that makes significant use of arithmetic incurs overheads even if it only ever uses small values. There is also a more subtle cost. Because emulating addition and subtraction could involve allocating memory on the heap for the long-format result every addition and subtraction could result in a garbage-collection. This means that the registers, which could be holding intermediate results, have to be treated as the roots for the GC. That in turn means that they must always contain either valid pointers or tagged values. This sometimes involves adding extra instructions simply to ensure this is the case. It also means that whenever the code returns from the run-time system to ML all the registers have to be loaded with known values, adding to the cost of a RTS call. The plan is to retain the existing arbitrary precision using the current tagged values but remove emulation. All arbitrary precision operations will involve an ML function call to the assembly code. This will compute the result directly if it is short and call into the run-time system if it is long. This is actually likely to faster than the current scheme if the values are long. Some cases, for example equality between an arbitrary precision value and a short constant, can continue to be handled by the code-generator since they do not require emulation. Fixed precision int will be based on the current short format i.e. 31 bits on 32-bit machines, 63 bits on 63-bit machines. Operations on these can be handled directly by the code-generator. These changes are currently being tested in the FixedPrecisionInt branch. This requires at least one, preferably two, calls to "make compiler" to build a version of the compiler that generates fixed precision operations. For backwards compatibility it does not yet gain all the advantages of the change; in particular it still clears all the registers on return from the run-time system.

1 0

ML debugging within Isabelle/PIDE
by makarius＠sketis.net 04 Feb '16

04 Feb '16

Dear users of the best unknown programming language in the world. Isabelle/ML is based on Poly/ML and thus benefits from the source-level debugger of that implementation of Standard ML. The Prover IDE provides the Debugger dockable to connect to running ML threads, inspect the stack frame with local ML bindings, and evaluate ML expressions in a particular run-time context. More explanations with a screenshot on http://sketis.net/2016/ml-debugging-within-the-prover-ide Makarius

2 11

Assertion `costMin > userGCRatio' failed
by phil.clayton＠lineone.net 28 Jan '16

28 Jan '16

I am getting the following assertion failure with Poly/ML 5.6: eg_test: heapsizing.cpp:602: bool HeapSizeParameters::getCostAndSize(POLYUNSIGNED&, double&, bool): Assertion `costMin > userGCRatio' failed. To get some timing stats, I was running a test application repeatedly to take an average time. It would appear that the sooner I re-run the application after the previous run has terminated, the more likely the above failure is to occur. There is no failure when I run the test once per second manually. Running the test application in quick succession using the command ./eg_test ; ./eg_test gives the failure every 3 to 4 invocations. Is there more information I can provide? Poly/ML 5.5.2 doesn't exhibit this issue. Phil

2 3

Rounding Mode
by jrtc27＠jrtc27.com 27 Jan '16

27 Jan '16

Hi David (cc?d mailing list back in), Of course "bytes 00 00 00 00 00 followed by 00 00 00/01/02" is meant to be "bytes 00 00 00 00 followed by 00 00 00 00/01/02". Regards, James > On 26 Jan 2016, at 14:13, James Clarke <jrtc27 at jrtc27.com> wrote: > > Hi David, > I initially tried to do something like you did (I had val supported = (setRoundingMode TO_NEAREST; true) handle Fail _ => false or similar, and wrapped the whole thing in one if succeeded let ... in () end else ()), but ran into issues where it was failing on x86; I imagine that was because the compiler was performing the operations on constants at compile-time like you said, as it didn?t seem to be following the rounding mode. > > Yes, when I was making the S/390 port, all the streams had streamNo 0 (bytes 00 00 00 00 00 followed by 00 00 00/01/02), so it thought fd 1 and 2 had closed early, causing polyimport to exit with status code 1 without printing anything. The same thing was happening on big-endian 64-bit PPC. > > Regards, > James > >> On 26 Jan 2016, at 14:05, David Matthews <David.Matthews at prolingua.co.uk> wrote: >> >> Hi James, >> I was trying to separate out the change to the tests from the change to reals.cpp. I don't like the idea of changing the test driver and I'd prefer to alter the test itself to deal correctly with the fact that setRoundingMode may raise an exception. I'm aware that it doesn't do that at the moment and it will need your patch or something like it. >> >> You're right that the change I've made is wrong and will also catch the exception raised in "check". Fixing that has, though, shown up a different bug where the compiler is trying to perform the real operations on constants at compile-time before the rounding mode has been set. That didn't show up when they were all top-level expressions. >> >> On your other patch: Was there an issue with the "streamNo" that caused you to make that change? I can see the possibility that unsigned might be different from POLYUNSIGNED (it certainly is on Windows/X64) and that the effect could be to set the wrong part of a word. I'll have to make some further changes because there are now warnings on Windows/64-bit. >> >> Regards, >> David >> >> On 26/01/2016 12:43, James Clarke wrote: >>> Hi, >>> I notice you committed https://github.com/polyml/polyml/commit/891e8122dcca36f9c2e9eea5a3eca7cf5de…. However, as it stands, on armel the calls do not raise an exception like https://github.com/polyml/polyml/pull/16, which could be misleading for the user, as as far as they are aware setting the mode has succeeded (and getting the mode may return the new mode). Also, unless I?m mistaken, you have effectively just completely disabled that test on every platform, as any failure will be caught. >>> >>> Regards, >>> James >>> >>> >>> >>> _______________________________________________ >>> polyml mailing list >>> polyml at inf.ed.ac.uk >>> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml >>> >

2 3

Inspecting structures
by ramana.kumar＠gmail.com 27 Jan '16

27 Jan '16

Is there a way to look at the contents (i.e. signature) of a structure without opening it? (I suppose you could just open it then call a lot of PolyML.Compiler.forgetXXX, but that's quite tedious) Also, is it possible to retrieve the long path of an identifier in scope? Something that will, for example, take the rev in scope and say that it came from List. Finally, what about searching for an identifier that would come into scope if you opened some structures?

3 5

Release of 5.6
by David.Matthews＠prolingua.co.uk 26 Jan '16

26 Jan '16

I've just "released" 5.6 on Github and also on SourceForge. As well as the tar sources for Unix there are installers for 32-bit and 64-bit Windows. Thanks to everyone who contributed. David

2 4

Rounding Mode
by jrtc27＠jrtc27.com 26 Jan '16

26 Jan '16

Hi, I notice you committed https://github.com/polyml/polyml/commit/891e8122dcca36f9c2e9eea5a3eca7cf5de…. However, as it stands, on armel the calls do not raise an exception like https://github.com/polyml/polyml/pull/16, which could be misleading for the user, as as far as they are aware setting the mode has succeeded (and getting the mode may return the new mode). Also, unless I?m mistaken, you have effectively just completely disabled that test on every platform, as any failure will be caught. Regards, James

1 0

Changes to Foreign structure
by David.Matthews＠prolingua.co.uk 24 Jan '16

24 Jan '16

There have been a few changes to the Foreign structure. The callN functions have been renamed as buildCallN and the way functions are passed as arguments has been changed. The reason for the changes is to make clear that the expensive operations are creating the C functions and closures and that calling a C function or passing a constructed closure are comparatively cheap. It is important to call the buildXXX functions at the top-level e.g. in a structure, so that the C function is created once. The old callN functions were curried and it wasn't apparent that the partial application to the conversions was quite different to the application of this to the arguments. For that reason the buildXXX take a tuple. David

3 12

← Newer
1
...
18
19
20
21
22
23
24
...
72
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML