test

From christo@nextsolution.co.jp Thu Apr 1 01:50:21 1999 From: christo@nextsolution.co.jp (Frank A. Christoph) Date: Thu, 1 Apr 1999 10:50:21 +0900 Subject: MLton information Message-ID: <000101be7be2$00ccce00$0150ebca@nextsolution.co.jp> I have looked at the performance page, and I was wondering why the kit example (this is the MLKit, right?) did so poorly. From what I know of MLKit, it is especially designed to be modular, and I would have thought that it could benefit from a whole-program analysis. BTW, are there any technical papers available on the MLton implementation? --FC From suresh@research.nj.nec.com Thu Apr 1 16:16:28 1999 From: suresh@research.nj.nec.com (Suresh Jagannathan) Date: Thu, 1 Apr 1999 11:16:28 -0500 Subject: MLton information In-Reply-To: <000101be7be2$00ccce00$0150ebca@nextsolution.co.jp> (christo@nextsolution.co.jp) Message-ID: <199904011616.LAA12880@vaikuntam.nj.nec.com> From: "Frank A. Christoph" Date: Thu, 1 Apr 1999 10:50:21 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal I have looked at the performance page, and I was wondering why the kit example (this is the MLKit, right?) did so poorly. From what I know of MLKit, it is especially designed to be modular, and I would have thought that it could benefit from a whole-program analysis. BTW, are there any technical papers available on the MLton implementation? --FC Yes, you're right, it was surprising to us as well. One conjecture is that the implementation of the KIT was optimized to work well with NJ. Another is based on the observation that C-function sizes for the kit are quite large, which may reduce the quality of the assembler output produced by C. Interestingly enough, in looking at the number of dispatches and coercions inserted by the closure convertor, we find the kit having far fewer (as percentage of total number of calls) than the self-compile. We're still investigating the discrepancy. We've submitted a paper to ICFP this year; the postscript of the submission follows. Regards, -- Suresh ============================ From sweeks@intertrust.com Thu Apr 1 19:02:57 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Thu, 1 Apr 1999 11:02:57 -0800 Subject: test Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE7C72.43BA2F06 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01BE7C72.43BA2F06 Content-Type: text/html; charset="iso-8859-1" test ------_=_NextPart_001_01BE7C72.43BA2F06-- From sweeks@intertrust.com Fri Apr 2 18:52:11 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Fri, 2 Apr 1999 10:52:11 -0800 Subject: callcc Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE7D39.EE1743A4 Content-Type: text/plain; charset="iso-8859-1" I have an implementation of callcc ready for testing. Does anyone have some SML programs using callcc that I can try? So far, all I've tried is val _ = 1 + callcc(fn k => throw k 2) ------_=_NextPart_001_01BE7D39.EE1743A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable callcc

I have an implementation of callcc ready for = testing. Does anyone have some SML programs using callcc that I = can try? So far, all I've tried is

val _ =3D 1 + callcc(fn k =3D> throw k 2)

------_=_NextPart_001_01BE7D39.EE1743A4-- From sweeks@intertrust.com Sat Apr 3 03:23:27 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Fri, 2 Apr 1999 19:23:27 -0800 Subject: test Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE7D81.596CAC60 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01BE7D81.596CAC60 Content-Type: text/html; charset="iso-8859-1" test ------_=_NextPart_001_01BE7D81.596CAC60-- From rolsson@cs.chalmers.se Tue Apr 6 14:01:23 1999 From: rolsson@cs.chalmers.se (Roland Olsson) Date: Tue, 6 Apr 1999 15:01:23 +0200 (MET DST) Subject: Interfacing with C Message-ID: Most ML and Haskell compilers contain C interfaces, but I couldn't find any instructions for calling C code in "MLton User's Guide". Is there some documentation on how to add C code, for example by placing it in src/runtime/mlton-lib.c? Otherwise, this is a highly interesting and useful compiler. Cheers, Roland Olsson Associate Prof. From suresh@research.nj.nec.com Tue Apr 6 14:42:17 1999 From: suresh@research.nj.nec.com (Suresh Jagannathan) Date: Tue, 6 Apr 1999 09:42:17 -0400 Subject: [rolsson@cs.chalmers.se: Interfacing with C] Message-ID: <199904061342.JAA13878@vaikuntam.nj.nec.com> X-Authentication-Warning: muppet1.cs.chalmers.se: rolsson owned process doing -bs Date: Tue, 6 Apr 1999 15:01:23 +0200 (MET DST) From: Roland Olsson To: MLton@research.nj.nec.com Subject: Interfacing with C MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Most ML and Haskell compilers contain C interfaces, but I couldn't find any instructions for calling C code in "MLton User's Guide". Is there some documentation on how to add C code, for example by placing it in src/runtime/mlton-lib.c? Otherwise, this is a highly interesting and useful compiler. Cheers, Roland Olsson Associate Prof. Since MLton compiles to C, it is fairly easy to make C calls from MLton, at least when passing and returning simple types like char, int, and double. For example, the implementation of the posix basis library modules is done this way (see basis-library/posix/primitive.sml). There isn't yet any documentation on how to call C, so I'll give a first try here. Please keep in mind that what I am about to describe is not part of Standard ML and was really just intended to be used to implement MLton's basis library. It is quite possible that this interface will change, although it has been stable for over 6 months. Suppose you would like to call a C function with the following prototype from ML: int foo(double d, unsigned char c); MLton extends the syntax of SML to allow expressions like the following: _prim "foo": real * char -> int; This expression returns a function of type real * char -> int whose behavior is implemented by calling the C function whose name is foo. What will actually happen in the C code is that there will be a C variable d of type double, c of type unsigned char, and i of type int, and the following C statement will be emitted. i = foo(d, c); The general form of a _prim declaration is _prim "c function name": ty; The semicolon is not optional. Here is a grammar for the types that are currently allowed. ty ::= u | t * ... * t -> u t ::= u | u array | u ref | u vector u ::= bool | char | int | real | string | unit | word | word8 Here is the mapping between SML types and C types. SML type C type ---------- ---------- bool int (0 is false, nonzero is true) char unsigned char int int real double string char * unit void word unsigned int word8 unsigned char u array char * u ref char * u vector char * Passing or returning tuples or datatypes is not allowed because the representation of these is decided quite late in the compilation process and because many optimizations may cause the representation to change. Arrays, refs, and vectors can only be passed as arguments because C functions are not allowed to allocate in the SML heap. Although the C type of an array, ref, or vector is always char*, in reality, the object is layed out in the natural C representation. You are responsible for doing the cast if you want to keep the C compiler from complaining. I'll give an example below. The runtime system also provides the macro GC_arrayNumElements which will return the number of elements in an array or vector. Strings are just like char arrays, and are not null terminated, unless you manually do so from the ML side. One other use of the _prim facility is to use C constants. For example, in basis-library/posix/primitive.sml, you will see the following lines. type syserror = int val acces = _prim "EACCES": syserror; This defines the SML variable acces to be an int whose value is the value of the C variable (macro) EACCESS. In the generated C code, all uses of acces will be replaced by EACCESS. You must be careful with such a constant declaration, because the optimizer assumes that it really is a constant. If you have a C macro whose value is non-constant, then you should declare a C macro of no arguments as a wrapper and declare the SML function as a nullary function. Now for the messiness, which arises because MLton doesn't know what header files to include and what to link with in order to handle the new C functions. Right now, this cannot be done automatically. Instead, you must use the -C option to cause MLton to generate the C file and then you must explicitly modify the C to include the headers. You must also call gcc yourself and pass along the right libraries to link with. You can use MLton -v to find out how MLton calls gcc. By adding just a couple of command-line args to MLton, it should be quite easy to fix this messiness. One command-line arg would specify additional include files, and the other would specify additional files for linking. Hopefully, the following example makes use of the ffi clear. Suppose you have the following files. -------------------------------------------------------------------------------- /* ffi.h */ /* This is the wrapper around ffi that is to be called from MLton. It * does the casts to make MLton arrays and refs look like C arrays and * pointers. * The SML type of FFI is real array * int ref * int -> char. */ #define FFI(ds,r,i) ffi((double*)ds, (int*)r, i) /* ffi is a silly function. It sums the elements ds, stores the * result in p, adds i to each element of ds, and returns 'c'. */ unsigned char ffi(double *ds, int *p, int i); -------------------------------------------------------------------------------- /* ffi.c */ #include "mlton.h" #include "ffi.h" unsigned char ffi(double *ds, int *p, int n) { int i; double sum; sum = 0.0; for (i = 0; i < GC_arrayNumElements(ds); ++i) { sum += ds[i]; ds[i] += n; } *p = (int)sum; return 'c'; } -------------------------------------------------------------------------------- (* ffi.sml *) (* Declare ffi to be implemented by calling the C macro (or function) FFI. *) val ffi = _prim "FFI": real array * int ref * int -> char; open Array val size = 10 val a = tabulate(10, fn i => real i) val r = ref 0 val n = 17 (* Call the C function *) val c = ffi(a, r, n) val _ = print(if c = #"c" andalso !r = 45 then "success\n" else "fail\n") -------------------------------------------------------------------------------- You can now compile the files as follows. % gcc -c ffi.c # you may also need a -I line to specify the location of mlton.h % mlton -o ffi.mlton.c -C ffi.sml You must now edit fft.mlton.c to add the line #include "ffi.h" after the line #include "mlton.h". You can now compile the C file. First, to find out how MLton compiles a C file, do the following. % mlton -v ffi.mlton.c This will fail with an undefined reference to ffi. However, you can now cut and paste the gcc line to do what you want. % gcc -O1 -w -fomit-frame-pointer -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -I/home/sweeks/mlton/include -o /home/sweeks/mlton/c-tests/ffi.mlton ffi.mlton.c /home/sweeks/mlton/lib/libmlton.a /home/sweeks/mlton/lib/libgmp.a -lm ffi.o You can now test the resulting executable % ffi.mlton success As I said, this cutting and pasting of C files and gcc calls is all quite messy and doesn't really need to be, since a couple of extra command-line arguments to MLton could fix it. I'll put them in if there's interest, but this approach is at least usable as a stopgap. From sweeks@intertrust.com Tue Apr 6 19:50:47 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Tue, 6 Apr 1999 11:50:47 -0700 Subject: previous message Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE805E.65275DF4 Content-Type: text/plain; charset="iso-8859-1" I didn't receive the message that you sent to MLton. I haven't received any messages sent to MLton yet, I believe. I think we should wait to put ffi in the documentation until we've added the few little hacks needed to make it easier to use. Namely: * -L flag to specify additional library directories * -l to specify additional libraries to link with * -??? to specify additional include files (suggestions for ??? are appreciated) -----Original Message----- From: Suresh Jagannathan [mailto:suresh@research.nj.nec.com] Sent: Tuesday, April 06, 1999 6:44 AM To: sweeks@intertrust.com Subject: previous message I cut and paste an earlier message you sent about interfacing to C; you should have received this. Since there have been several requests about this, maybe it would be a good idea to put the description on the web page, or in the documentation. -- sj ------_=_NextPart_001_01BE805E.65275DF4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: previous message

I didn't receive the message that you sent to = MLton. I haven't received any messages sent to MLton yet, I = believe.

I think we should wait to put ffi in the = documentation until we've added the few little hacks needed to make it = easier to use. Namely:

* -L flag to specify additional library = directories
* -l to specify additional libraries to link = with
* -??? to specify additional include = files
(suggestions for ??? are = appreciated)

-----Original Message-----
From: Suresh Jagannathan [mailto:suresh@research.nj.nec= .com]
Sent: Tuesday, April 06, 1999 6:44 AM
To: sweeks@intertrust.com
Subject: previous message

I cut and paste an earlier message you sent about = interfacing to C; you should
have received this. Since there have been = several requests about this, maybe it
would be a good idea to put the description on the = web page, or in the
documentation.

= -- sj

------_=_NextPart_001_01BE805E.65275DF4-- From sweeks@intertrust.com Wed Apr 7 01:48:44 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Tue, 6 Apr 1999 17:48:44 -0700 Subject: call/cc Message-ID: I tried out your example (even with GC_EVERY_CHECK) and it seemed to work fine. Let me know (a few days in advance) of when you will need a call/cc enabled version of MLton and I'll make a snapshot. In the absence of any prodding by you, I'll wait to make the snapshot until I fix up some of the FFI stuff. -----Original Message----- From: Simon Helsen [mailto:helsen@informatik.uni-freiburg.de] Sent: Tuesday, April 06, 1999 12:05 PM To: Steve Weeks Subject: call/cc Hi Steve, in the attach. you find a larger example using call/cc. It is a simple lambda calc. specializer and you only have to change the uses of SMLofNJ.Cont.callcc and SMLofNJ.Cont.throw This is really the kind of stuff I'll be doing in the ML partial evaluator, only on a larger scale. I don't think you'll be able to make performance comparisons on this tiny sample. But I am happy to do this later on when I have a full SML Partial Evaluator ready. Simon From Simon Helsen Wed Apr 7 14:11:18 1999 From: Simon Helsen (Simon Helsen) Date: Wed, 7 Apr 1999 15:11:18 +0200 (CEST) Subject: call/cc In-Reply-To: Message-ID: >I tried out your example (even with GC_EVERY_CHECK) and it seemed to work >fine. Let me know (a few days in advance) of when you will need a call/cc >enabled version of MLton and I'll make a snapshot. In the absence of any >prodding by you, I'll wait to make the snapshot until I fix up some of the >FFI stuff. ok, thanks, I won't need it very soon and I develop in SML/NJ anyway. Before the first release I will probably try to get it compiled with MLton and then I'll need it... Thanks for the effort! Simon From sweeks@intertrust.com Tue Apr 13 23:15:45 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Tue, 13 Apr 1999 15:15:45 -0700 Subject: test Message-ID: From sweeks@intertrust.com Wed Apr 14 04:58:11 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Tue, 13 Apr 1999 20:58:11 -0700 Subject: fxp Message-ID: > If you are interested, i can make my files available, so you can play with them. Sure. That would be great. Email or a publicly available web site would be fine. Thanks. From henry@research.nj.nec.com Mon Apr 12 23:19:14 1999 From: henry@research.nj.nec.com (Henry Cejtin) Date: Mon, 12 Apr 1999 18:19:14 -0400 Subject: max heap Message-ID: <199904122219.SAA01149@nimrod.nj.nec.com> The max heap stuff doesn't seem to effect stack growth. I.e., I ran with max-heap 120m and yet it still tried to grow the stack to 256 megabytes. From d97ham@csd.uu.se Thu Apr 15 19:10:46 1999 From: d97ham@csd.uu.se (Hans Molin) Date: Thu, 15 Apr 1999 20:10:46 +0200 Subject: Unix not Linux Message-ID: <37162BA6.9436C002@csd.uu.se> Do you have any plans to make MLton for SunOS/Solaris on Sparc-stations? Or perhaps a Moscow ML version? -- /------------------------------------------------------------\ | Hans "Kvasi" Molin | d97ham@csd.uu.se | | Computer Science | http://www.csd.uu.se/~d97ham/ | | Uppsala University | Tel: 018 - 505 205 | \------------------------------------------------------------/ From suresh@research.nj.nec.com Thu Apr 15 19:11:49 1999 From: suresh@research.nj.nec.com (Suresh Jagannathan) Date: Thu, 15 Apr 1999 14:11:49 -0400 Subject: Unix not Linux In-Reply-To: <37162BA6.9436C002@csd.uu.se> (message from Hans Molin on Thu, 15 Apr 1999 20:10:46 +0200) Message-ID: <199904151811.OAA24811@vaikuntam.nj.nec.com> Sender: d97ham@csd.uu.se Date: Thu, 15 Apr 1999 20:10:46 +0200 From: Hans Molin Organization: Uppsala University X-Mailer: Mozilla 4.08 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Do you have any plans to make MLton for SunOS/Solaris on Sparc-stations? Or perhaps a Moscow ML version? No plans currently, but this might change depending upon how much interest there is from users. Regards, -- Suresh From christo@nextsolution.co.jp Thu Apr 1 01:50:21 1999 From: christo@nextsolution.co.jp (Frank A. Christoph) Date: Thu, 1 Apr 1999 10:50:21 +0900 Subject: MLton information Message-ID: <000101be7be2$00ccce00$0150ebca@nextsolution.co.jp> I have looked at the performance page, and I was wondering why the kit example (this is the MLKit, right?) did so poorly. From what I know of MLKit, it is especially designed to be modular, and I would have thought that it could benefit from a whole-program analysis. BTW, are there any technical papers available on the MLton implementation? --FC From suresh@research.nj.nec.com Thu Apr 1 16:16:28 1999 From: suresh@research.nj.nec.com (Suresh Jagannathan) Date: Thu, 1 Apr 1999 11:16:28 -0500 Subject: MLton information In-Reply-To: <000101be7be2$00ccce00$0150ebca@nextsolution.co.jp> (christo@nextsolution.co.jp) Message-ID: <199904011616.LAA12880@vaikuntam.nj.nec.com> From: "Frank A. Christoph" Date: Thu, 1 Apr 1999 10:50:21 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal I have looked at the performance page, and I was wondering why the kit example (this is the MLKit, right?) did so poorly. From what I know of MLKit, it is especially designed to be modular, and I would have thought that it could benefit from a whole-program analysis. BTW, are there any technical papers available on the MLton implementation? --FC Yes, you're right, it was surprising to us as well. One conjecture is that the implementation of the KIT was optimized to work well with NJ. Another is based on the observation that C-function sizes for the kit are quite large, which may reduce the quality of the assembler output produced by C. Interestingly enough, in looking at the number of dispatches and coercions inserted by the closure convertor, we find the kit having far fewer (as percentage of total number of calls) than the self-compile. We're still investigating the discrepancy. We've submitted a paper to ICFP this year; the postscript of the submission follows. Regards, -- Suresh ============================ From sweeks@intertrust.com Thu Apr 1 19:02:57 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Thu, 1 Apr 1999 11:02:57 -0800 Subject: test Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE7C72.43BA2F06 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01BE7C72.43BA2F06 Content-Type: text/html; charset="iso-8859-1" test ------_=_NextPart_001_01BE7C72.43BA2F06-- From sweeks@intertrust.com Fri Apr 2 18:52:11 1999 From: sweeks@intertrust.com (Stephen Weeks) Date: Fri, 2 Apr 1999 10:52:11 -0800 Subject: callcc Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE7D39.EE1743A4 Content-Type: text/plain; charset="iso-8859-1" I have an implementation of callcc ready for testing. Does anyone have some SML programs using callcc that I can try? So far, all I've tried is val _ = 1 + callcc(fn k => throw k 2) ------_=_NextPart_001_01BE7D39.EE1743A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable callcc

I have an implementation of callcc ready for = testing. Does anyone have some SML programs using callcc that I = can try? So far, all I've tried is

val _ =3D 1 + callcc(fn k =3D> throw k 2)

I didn't receive the message that you sent to = MLton. I haven't received any messages sent to MLton yet, I = believe.

I think we should wait to put ffi in the = documentation until we've added the few little hacks needed to make it = easier to use. Namely:

* -L flag to specify additional library = directories
* -l to specify additional libraries to link = with
* -??? to specify additional include = files
(suggestions for ??? are = appreciated)

-----Original Message-----
From: Suresh Jagannathan [mailto:suresh@research.nj.nec= .com]
Sent: Tuesday, April 06, 1999 6:44 AM
To: sweeks@intertrust.com
Subject: previous message

= -- sj