/usr/share/doc/mlton/guide/MLNLFFIImplementation is in mlton-doc 20100608-5.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta name="robots" content="index,nofollow">
<title>MLNLFFIImplementation - MLton Standard ML Compiler (SML Compiler)</title>
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="all" href="common.css">
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="screen" href="screen.css">
<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="print" href="print.css">
<link rel="Start" href="Home">
</head>
<body lang="en" dir="ltr">
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-833377-1";
urchinTracker();
</script>
<table bgcolor = lightblue cellspacing = 0 style = "border: 0px;" width = 100%>
<tr>
<td style = "
border: 0px;
color: darkblue;
font-size: 150%;
text-align: left;">
<a class = mltona href="Home">MLton MLTONWIKIVERSION</a>
<td style = "
border: 0px;
font-size: 150%;
text-align: center;
width: 50%;">
MLNLFFIImplementation
<td style = "
border: 0px;
text-align: right;">
<table cellspacing = 0 style = "border: 0px">
<tr style = "vertical-align: middle;">
</table>
<tr style = "background-color: white;">
<td colspan = 3
style = "
border: 0px;
font-size:70%;
text-align: right;">
<a href = "Home">Home</a>
<a href = "TitleIndex">Index</a>
</table>
<div id="content" lang="en" dir="ltr">
MLton's implementation(s) of the <a href="MLNLFFI">MLNLFFI</a> library differs from the SML/NJ implementation in two important ways:
<ul>
<li>
<p>
MLton cannot utilize the <tt>Unsafe.cast</tt> "cheat" described in Section 3.7 of <a href = "References#Blume01">Blume01</a>. (MLton's representation of <a href="Closure">closures</a> and <a href="PackedRepresentation">aggressive representation</a> optimizations make an <tt>Unsafe.cast</tt> even more "unsafe" than in other implementations.) We have considered two solutions:
</p>
</li>
<ul>
<li>
<p>
One solution is to utilize an additional type parameter (as described in Section 3.7 of <a href = "References#Blume01">Blume01</a>):
</p>
</li>
<ul>
<pre class=code>
<B><FONT COLOR="#0000FF">signature</FONT></B> C = <B><FONT COLOR="#0000FF">sig</FONT></B>
<B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> ('t, 'f, 'c) obj
</FONT></B><B><FONT COLOR="#A020F0">eqtype</FONT></B><B><FONT COLOR="#228B22"> ('t, 'f, 'c) obj'
</FONT></B>...
<B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> ('o, 'f) ptr
</FONT></B><B><FONT COLOR="#A020F0">eqtype</FONT></B><B><FONT COLOR="#228B22"> ('o, 'f) ptr'
</FONT></B>...
<B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> 'f fptr
</FONT></B><B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> 'f ptr'
</FONT></B>...
<B><FONT COLOR="#0000FF">structure</FONT></B> T : <B><FONT COLOR="#0000FF">sig</FONT></B>
<B><FONT COLOR="#A020F0">type</FONT></B><B><FONT COLOR="#228B22"> ('t, 'f) typ
</FONT></B>...
<B><FONT COLOR="#0000FF">end</FONT></B>
<B><FONT COLOR="#0000FF">end</FONT></B>
</PRE>
<p>
<em>The rule for <tt>('t, 'f, 'c) obj</tt>,<tt>('t, 'f, 'c) ptr</tt>, and also <tt>('t, 'f) T.typ</tt> is that whenever <tt>F fptr</tt> occurs within the instantiation of <tt>'t</tt>, then <tt>'f</tt> must be instantiated to <tt>F</tt>. In all other cases, <tt>'f</tt> will be instantiated to <tt>unit</tt>.</em> (In the actual MLton implementation, an abstract type <tt>naf</tt> (not-a-function) is used instead of <tt>unit</tt>.)
</p>
</ul>
While this means that type-annotated programs may not type-check under both the SML/NJ implementation and the MLton implementation, this should not be a problem in practice. Tools, like <tt>ml-nlffigen</tt>, which are necessarily implementation dependent (in order to make <a href="CallingFromSMLToCFunctionPointer">calls through a C function pointer</a>), may be easily extended to emit the additional type parameter. Client code which uses such generated glue-code (e.g., Section 1 of <a href = "References#Blume01">Blume01</a>) need rarely write type-annotations, thanks to the magic of type inference. <li class="gap">
<p>
The above implementation suffers from two disadvantages. First, it changes the MLNLFFI Library interface, meaning that the same program may not type-check under both the SML/NJ implementation and the MLton implementation (though, in light of type inference and the richer <tt>MLRep</tt> structure provided by MLton, this point is mostly moot).
</p>
<p>
Second, it appears to unnecessarily duplicate type information. For example, an external C variable of type <tt>int (* f[3])(int)</tt> (that is, an array of three function pointers), would be represented by the SML type <tt>(((sint -> sint) fptr, dec dg3) arr, sint -> sint, rw) obj</tt>. One might well ask why the <tt>'f</tt> instantiation (<tt>sint -> sint</tt> in this case) cannot be <em>extracted</em> from the <tt>'t</tt> instantiation (<tt>((sint -> sint) fptr, dec dg3) arr</tt> in this case), obviating the need for a separate <em>function-type</em> type argument. There are a number of components to an complete answer to this question. Foremost is the fact that <a href="StandardML"> Standard ML</a> supports neither (general) type-level functions nor intensional polymorphism.
</p>
<p>
A more direct answer for MLNLFFI is that in the SML/NJ implemention, the definition of the types <tt>('t, 'c) obj</tt> and <tt>('t, 'c) ptr</tt> are made in such a way that the type variables <tt>'t</tt> and <tt>'c</tt> are <a href="PhantomType"> phantom</a> (not contributing to the run-time representation of an <tt>('t, 'c) obj</tt> or <tt>('t, 'c) ptr</tt> value), despite the fact that the types <tt>((sint -> sint) fptr, rw) ptr</tt> and <tt>((double -> double) fptr, rw) ptr</tt> necessarily carry distinct (and type incompatible) run-time (C-)type information (RTTI), corresponding to the different calling conventions of the two C functions. The <tt>Unsafe.cast</tt> "cheat" overcomes the type incompatibility without introducing a new type variable (as in the first solution above).
</p>
<p>
Hence, the reason that <em>function-type</em> type cannot be extracted from the <tt>'t</tt> type variable instantiation is that the type of the representation of RTTI doesn't even <em>see</em> the (phantom) <tt>'t</tt> type variable. The solution which presents itself is to give up on the phantomness of the <tt>'t</tt> type variable, making it available to the representation of RTTI.
</p>
<p>
This is not without some small drawbacks. Because many of the types used to instantiate <tt>'t</tt> carry more structure than is strictly necessary for <tt>'t</tt>'s RTTI, it is sometimes necessary to wrap and unwrap RTTI to accommodate the additional structure. (In the other implementations, the corresponding operations can pass along the RTTI unchanged.) However, these coercions contribute minuscule overhead; in fact, in a majority of cases, MLton's optimizations will completely eliminate the RTTI from the final program.
</p>
</li>
</ul>
The implementation distributed with MLton uses the second solution. <p>
Bonus question: Why can't one use a <a href="UniversalType"> universal type</a> to eliminate the use of <tt>Unsafe.cast</tt>?
</p>
<ul>
<li>
<p>
Answer: ???
</p>
</li>
</ul>
<li class="gap">
<p>
MLton (in both of the above implementations) provides a richer <tt>MLRep</tt> structure, utilizing <tt>Int<N></tt> and <tt>Word<N></tt> structures.
<pre class=code>
<B><FONT COLOR="#0000FF">structure</FONT></B> MLRep = <B><FONT COLOR="#0000FF">struct</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Char =
<B><FONT COLOR="#0000FF">struct</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int8
<B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word8
<I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
<B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
<B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
<B><FONT COLOR="#0000FF">end</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Short =
<B><FONT COLOR="#0000FF">struct</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int16
<B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word16
<I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
<B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
<B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
<B><FONT COLOR="#0000FF">end</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Int =
<B><FONT COLOR="#0000FF">struct</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int32
<B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word32
<I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
<B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
<B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
<B><FONT COLOR="#0000FF">end</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Long =
<B><FONT COLOR="#0000FF">struct</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int32
<B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word32
<I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
<B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
<B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
<B><FONT COLOR="#0000FF">end</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> LongLong =
<B><FONT COLOR="#0000FF">struct</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Signed = Int64
<B><FONT COLOR="#0000FF">structure</FONT></B> Unsigned = Word64
<I><FONT COLOR="#B22222">(* word-style bit-operations on integers... *)</FONT></I>
<B><FONT COLOR="#0000FF">structure</FONT></B> SignedBitops = IntBitOps(<B><FONT COLOR="#0000FF">structure</FONT></B> I = Signed
<B><FONT COLOR="#0000FF">structure</FONT></B> W = Unsigned)
<B><FONT COLOR="#0000FF">end</FONT></B>
<B><FONT COLOR="#0000FF">structure</FONT></B> Float = Real32
<B><FONT COLOR="#0000FF">structure</FONT></B> Double = Real64
<B><FONT COLOR="#0000FF">end</FONT></B>
</PRE>
This would appear to be a better interface, even when an implementation must choose <tt>Int32</tt> and <tt>Word32</tt> as the representation for smaller C-types.
</p>
</li>
</ul>
</div>
<p>
<hr>
Last edited on 2007-08-15 22:06:50 by <span title="fenrir.uchicago.edu"><a href="MatthewFluet">MatthewFluet</a></span>.
</body></html>
|