Poly/ML

polyml@lists.polyml.org

695 discussions

Start a nNew thread

Metaprogramming
by antonlobach＠uri.edu 10 Oct '21

10 Oct '21

Hello, Does PolyML support any form of metaprogramming? Best, Anton

2 1

Can't build Poly/ML after introducing RunCall.rtsCallFast1
by phil.clayton＠veonix.com 01 Oct '21

01 Oct '21

I'm adding conversions for other C types, based on the latest master (cf6f86a), but building fails without any error message. polyimport fails on my version of ForeignConstants.sml.? After experimenting, it seems that introducing ? RunCall.rtsCallFast1"f" () where f is a new function that I am also introducing, causes the failure. Is there a different way I should be building?? I'm sure I just ran 'make', 'make compiler' when I did this before.? I have attached the patch in case I've done something silly in there.

1 1

Unix.execute argument list backwards incompatibility
by Ramana.Kumar＠cl.cam.ac.uk 21 Jun '21

21 Jun '21

I think the C code replacing the ML code for Unix.execute does not quite do what the ML code used to. Specifically the execve call here https://github.com/polyml/polyml/blob/master/libpolyml/unix_specific.cpp#L2… does not pass the cmd as the first argument, whereas the ML version did. This is a user-visible change in the API that was probably unintended.

2 3

Git master update: ARM64, PIE and new bootstrap process
by David.Matthews＠prolingua.co.uk 15 May '21

15 May '21

Now that 5.8.2 has been released I've updated Git master with some changes that have been in the pipeline for some time. These affect a number of issues so they probably need a bit of explanation. These are: a basic code-generator for 64-bit ARM, position-independent executables and a new bootstrap process. This is quite a long message since each of these require some explanation. Bootstrap The updated bootstrap process affects all architectures. Because Poly/ML is written in ML there needs to be an ML compiler to compile the source. The solution up to now has been to have pre-built compilers for each architecture. The bootstrap process then compiles the basis library and builds the final binary from that. The problem is that this requires a compiler for each architectures; for 5.8.2 that is seven in all: X86/32, 32-bit interpreted, 64-bit interpreted, X86/64 and X86/64/32, with different version for the last two for Windows and Unix because of the different ABIs. Adding ARM64 would have increased this further. The solution was to bootstrap from the interpreted version. This requires only two pre-built compilers, for 32- and 64-bits. However building a final native code compiler requires the whole system to be compiled several times. This doesn't take long on reasonable hardware but can be slow on under-powered machines or with debugging turned on. The final binary is as fast as before; it's just the bootstrap that is slow. A consequence of this is that it is no longer necessary to run "make compiler" when building from Git. Previously the compiler itself was not rebuilt with a simple "make" so changes that involved the compiler itself needed "make compiler" in order to be incorporated. That is no longer the case since the bootstrap process recompiles the compiler. "make compiler" has been retained for compatibility but it may actually be better not to use it, particularly if --enable-intinf-as-int has been included. --enable-intinf-as-int builds the basis library and any subsequent code with int as arbitrary precision. Running "make compiler" would build the compiler itself with arbitrary precision rather than fixed precision which will be bulkier even if it doesn't noticeably affect the speed. Position-independent code The new version now generates position-independent executables on X86/64 and ARM64. This has been in the pipe-line for a while but was spurred on by the fact that Mac OS requires it for ARM code. What this means is that the code segments in object files created by PolyML.export no longer contain absolute addresses. The "constant area" associated with the code for each function is pulled out and placed in a read-only, non-executable area. It's too complicated to do this X86/32 so 32-bit programs will continue to need special treatment on platforms that have problems with non-PIC but for the majority of code on 64-bits there should no longer be problems in this area. It doesn't apply to Windows, which doesn't need this, or to compact 32-bit or interpreted code where the "code" is not marked as executable. ARM64 Last but not least there is now a basic code-generator for the ARM64. This has been tested on a wide range of hardware and systems including Windows 10, Debian under Windows-subsystem-for-Linux, Mac OS X, PiOS on various 64-bit Raspberry Pis and even big-endian NetBSD on a Raspberry Pi. It is complete including compiled FFI and compact 32-bit. However, at this stage the code-generator has no optimisation or proper register allocation and treats the machine as essentially single-register plus stack. That greatly simplifies the code-generation at the expense of bulky and slow code. On a Mac Mini X86/64 code translated by Rosetta is still roughly 1.5 to 2 times faster. Rosetta code is reported to be about 80% of the speed of optimised ARM code so things should improve with optimisation. There is one point about the ARM code-generator that is worth making. The ARM has a weaker memory model than the X86 and that can affect multi-threaded code with shared references. Code that uses mutexes to protect all accesses to shared references is not affected since the mutex access includes the appropriate memory barriers but during testing I came across a problem with futures in Isabelle. Since once a future is evaluated it can never change it is generally possible to access it without a lock and only use a lock if it appears to be unevaluated. Unlike the X86 the ARM does not guarantee that another thread will see updates to different addresses in the same order as they are made by the thread making the assignments. In this particular case a thread was creating a value on the heap and then assigning the address of this heap cell to a shared reference. On the X86 the update to the heap would always be seen before the update to the shared reference but on the ARM it was possible for another thread to cache that part of the heap and so read values in the heap that were completely random. Since the consequence of this is completely unpredictable behaviour I took the decision to implement '!' and ':=' using instructions that incorporate memory barriers giving read-acquire/store-release semantics. Currently this does not apply to other mutable structures such as arrays but for consistency it probably should. There doesn't seem to be any measurable difference in speed by using these instructions compared with the ones without the memory barriers although the code is slightly longer. David

2 2

5.8.2 Release
by David.Matthews＠prolingua.co.uk 10 May '21

10 May '21

The current master has now been released as 5.8.2. There is a fixes-5.8.2 branch for any bug fixes that are needed. The release notes at https://github.com/polyml/polyml/releases includes a list of the various changes. The major change is the replacement of libffi with the internal FFI compiler. Other changes include the addition of IPv6 structures and PackReal32Big and PackReal32Little structures. The master branch has been stable for a while so there should not be any big surprises but as ever let me know if there are problems. David

2 1

PackReal32
by cannam＠all-day-breakfast.com 27 Apr '21

27 Apr '21

Hello! I find I could do with the PackReal32{Big,Little} structures, 32-bit floats being often more amenable to serialisation and used in some storage formats. Would there be any appetite for adding these? Thanks, Chris

2 7

PolyML and windows
by kostirya＠gmail.com 11 Apr '21

11 Apr '21

Hello. I have questions about PolyML and Windows. Can PolyML run in Windows 32-bit? I see than last version PolyML have binary distribution for 64-bit Windows only. Is it possible to compile PolyML for 32-bit Windows with help Clang? Can I make executable files from PolyML for Windows (with help polyc)? Can I do cross-compiling from UNIX to Windows? Nick.

3 2

Updates in git master including major change to FFI
by David.Matthews＠prolingua.co.uk 11 Mar '21

11 Mar '21

Hi, I've just pushed a collection of changes to master that have been in the pipeline for quite a long time. Some of these are internal changes to the run-time system and some are extensions, such as the addition of IPv6 networking with INet6Sock and Net6HostDB structures. The major change, though, is with the foreign function interface. On X86 platforms libffi is no longer used and the version of it included in the libpolyml directory has been removed. Libffi is still used in the interpreted version but only if the library is installed on the system. Instead the foreign function interface is handled essentially as part of the compiler. The high-level interface in the Foreign structure remains unchanged but the buildCallN functions now actually compile interface functions. This results in foreign function calls being substantially faster than with libffi; at least 10 times faster for trivial calls on the X86/64. The cost is, of course, some extra work when buildCallN is called, meaning that it is essential that these functions are only used at the top level. The reason for the speed-up is that the interface has to place the arguments in the correct registers for the ABI and the rules for placing arguments can be quite complicated, particular on the X86/64 on Unix. Libffi computes the placement on every call whereas the compiler can do this once and build code that moves the arguments into the right registers and returns the result. For backwards compatibility buildClosureN functions have been retained but these are wrappers around new buildCallback functions. The buildCallback functions differ in two respects. Closures created with buildCallback are garbage-collected which means that if they are used to register callbacks with a C library it may be necessary to keep a reference in ML. There is a touchClosure function that should be called when the callback is no longer needed. For compatibility closures created with buildClosure are retained in a global list to avoid garbage collection. The other difference is that the buildCallback functions have a slightly different type from buildClosure and that reflects the underlying implementation. For example, val buildCallback1: 'a conversion * 'b conversion -> ('a -> 'b) -> ('a -> 'b) closure The first application builds the interface code that handle the conversion between the ML and C ABIs. The second application applies this to an ML function to build a closure value that can be passed to C. This second application builds a small additional piece of code that simply loads the address of the ML function into a register and jumps to the interface code. What this means is that while the first application should always be done at the top level it is possible to embed an application of this to a particular ML function inside ML code. There is still an overhead compared with creating a closure in ML and it is better if possible to do the application at the top level but the cost is significantly less than if the whole buildCallback function were called within a function. As always please give this a try and let me know if there are problems. Regards, David

4 22

the design of Poly/ML
by buday.gergely.istvan＠uni-mate.hu 17 Feb '21

17 Feb '21

Hi, is there an academic description of the design of Poly/ML, regarding compilation strategies, intermediate languages etc? Cheers - Gergely

1 0

Announcement: Giraffe Library
by phil.clayton＠veonix.com 17 Feb '21

17 Feb '21

[Apologies if you receive multiple copies this message] Dear Poly/ML users, I would like to announce the first public release of Giraffe Library, an SML interface to libraries that support GObject Introspection, such as GTK. The latest release, 1.0.0-alpha.11, provides GTK 3 and supporting libraries, enabling applications with GUIs to be written entirely in SML. Applications without GUIs may also find some features useful, for example, in GLib, sockets using UDP multicast and various checksums, which are not available in the current Basis Library. For more information, download, documentation and examples, please see: http://giraffelibrary.org/ Regards, Phil

2 2

← Newer
1
2
3
4
5
6
7
...
70
Older →

Jump to page:

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