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
200
201
202
203
204
205
|
Release~0.22 is the fourth public release of Glasgow Haskell.
It incorporates our new work for the first half of 1994.
The announcement for this release is distributed as \tr{ANNOUNCE-0.22}
in the top-level directory.
%************************************************************************
%* *
\subsection[0-22-ports]{What machines GHC~0.22 runs on}
%* *
%************************************************************************
We use Sun4s running SunOS~4.1.3 and DEC~Alphas running OSF/1~V2.0, so
those are the ``fully-supported'' platforms, unsurprisingly. For
Sun4s, we have a native-code generator, which makes for somewhat
quicker compilations. (We actually produce better code by compiling
intermediate C with GCC.)
The GHC hierarchy of Porting Goodness: (a)~Best is a native-code
generator [only for Sun4s, now]; (b)~next best is a ``registerised''
port; (c)~the bare minimum is an ``unregisterised'' port.
``Unregisterised'' Haskell programs are much bigger and slower,
but the port is much easier to get going.
Here's everything that's known about GHC ports, as of 0.22:
\begin{description}
%-------------------------------------------------------------------
\item[Sun4 running SunOS~4.1.3:]
Fully supported, including native-code generator.
%-------------------------------------------------------------------
\item[DEC Alpha running OSF/1 V2.0:]
Fully supported, but no native-code generator (none planned).
%-------------------------------------------------------------------
\item[Sun3 running SunOS~4.1.3:]
GHC~0.22 should work, registerised. (0.21 did work.)
%-------------------------------------------------------------------
\item[Sun4 running Solaris 2.x:]
We expect to finish a ``registerised'' port ourselves, in the
foreseeable future. Feel free to ask about it, if interested. Not
sure about native-code...
%-------------------------------------------------------------------
\item[HP-PA box running HP/UX 9.x:]
An unregisterised port of 0.21 (last ``internal'' release before 0.22)
seems to work, except that floating-point is definitely busted.
0.22~should be the same.
%-------------------------------------------------------------------
\item[Silicon Graphics box running IRIX 5.x:]
An unregisterised port of 0.21
seemed to work. 0.22~should be the same.
%-------------------------------------------------------------------
\item[DECstation (MIPS-based):]
An unregisterised port back around the time of 0.17 seemed to work;
0.22~should be the same, modulo a little bit-rot.
%-------------------------------------------------------------------
\item[x86 PCs running Linux/NetBSD/FreeBSD:]
This really needs a native-code generator to be viable. No
recent progress.
%-------------------------------------------------------------------
\item[GRIP multiprocessor:]
GRIP is a 68020-based multiprocessor for running parallel Haskell
programs; too bad we have the only machine! We run GHC~0.16 on it,
with no plans to upgrade.
We are working on other parallel stuff. Stay tuned.
%-------------------------------------------------------------------
\item[NeXT box running whatever NeXTs run:]
Carsten Schultz succeeded with a ``registerised'' port of GHC~0.19.
There's probably a little bit-rot since then, but otherwise it should
still be fine.
%-------------------------------------------------------------------
\item[Macintosh, using MPW:]
As mind-blowing at it may seem, David Wright in Tasmania has actually
gotten GHC to run on a Macintosh. Ditto James Thomson here at Glasgow.
You may be able to get Thomson's from here. (Not sure that it will
excite you to death, but...)
\end{description}
%************************************************************************
%* *
\subsection[0-22-user-visible]{User-visible changes in 0.22, including incompatibilities}
%* *
%************************************************************************
You'll need to recompile everything if you're switching from a
previous version of GHC. (If you don't, you'll get ``consistency
errors''.)
Lazy pattern-matching (e.g., \tr{let (x,y) = ... in ...}) no longer
carries with it the threat of a space leak. (It used to be that, as
long as {\em either} of \tr{x} or \tr{y} was ``live,'' the storage
manager would hang onto {\em both} chunks of graph.) No longer.
We've done a complete overhaul of the state-transformer stuff which
underlies our array, I/O, and C-calling support. The ``state
interface document,'' distributed in \tr{ghc/docs/state-interface.dvi}
defines what we have done. You may wish to check our abstracts
(\tr{ghc/docs/abstracts/}) to find papers about this stuff. If you've
written code that grovels around in GHC innards (e.g., uses
``primitive operations'' directly), it will probably need updating.
We do {\em not} support Haskell~1.3 monadic I/O (any draft version),
but we will once the dust settles. We still support the
\tr{PreludeGlaIO} interface that we have had for some time.
You can now build GHC to support ``threaded'' execution. (Configure
\tr{--with-threads=yes}, then use GHC with a \tr{-threads} option.)
Using the \tr{_seq_} and \tr{_par_} constructs,
GHC does a better job of not stealing from the user's name space (for
its own extensions, etc.). For example, the ``set cost-centre''
keyword is now \tr{_scc_}, rather than \tr{scc} (though the latter
will continue to be accepted for a while). With the
\tr{-fglasgow-exts} flag on, names may begin with an underscore
(\tr{_}).
We have friendly interaction between ``Haskell land'' and ``C land''
via (a)~{\em stable pointers} (pass Haskell pointers to C and have the
garbage-collector not forget about them); and (b)~{\em malloc
pointers} (return C pointers to Haskell and tell Haskell ``throw this
away when you're finished with it''). See the User's Guide for more
info.
%************************************************************************
%* *
\subsection[0-22-support]{New in support tools (e.g., profiling)}
%* *
%************************************************************************
The profiling system of GHC has been improved in version~0.22 in the
following ways:
\begin{description}
\item[Now uses the ``hybrid scheme'':] (Rather than pure ``lexical
scoping'') What this means for you: ``CAF'' cost-centres will no
longer be blamed for gigantic chunks of the time in your program.
\item[Uses the generational garbage-collector:] (At least when doing
time profiling) It used to use a two-space copying GC; it still does
when space profiling. You should be able to profile larger programs.
\end{description}
%************************************************************************
%* *
\subsection[0-22-new-in-compiler]{New in the compiler proper}
%* *
%************************************************************************
The ``simplifier''---the program-transformation engine in the middle
of the compiler---has settled down (at least until Simon has another
Brain Wave). We've made ``per-simplification'' flags, so that each
run of the simplifier can be controlled separately---this allows very
precise control. (But makes it pretty hard to exercise any control
from the command-line.) More in the docs.
Related to simplifier stuff was a revision of the ``unfoldery''
machinery. We try very hard to find and exploit unfolding (or
inlining), including across module boundaries.
%************************************************************************
%* *
\subsection[0-22-new-in-libraries]{In the prelude and runtime support}
%* *
%************************************************************************
We've introduced a ``GHC system library,'' similar to the ``HBC system
library'' which we have supported for some time. Just say
\tr{-syslib ghc} and the GHC library stuff is at your fingertips.
See the User's Guide for exactly what's on offer (not a lot right now,
but more will show up).
The @PackedString@ module that comes with the system is even beefier
than before; see the User's Guide. (This module really should be
in the GHC library.)
%************************************************************************
%* *
\subsection[0-22-new-elsewhere]{Other new stuff}
%* *
%************************************************************************
We have two new mailing lists about Glasgow Haskell.
\begin{description}
\item[glasgow-haskell-users:]
This list is for GHC users to chat among themselves. Subscribe by
sending mail to \tr{glasgow-haskell-users-request@dcs.glasgow.ac.uk}.
Messages for the list go to \tr{glasgow-haskell-users}.
\item[glasgow-haskell-bugs:]
This used to be an address for some lonely person who received bug
reports. It is now a mailing list for the sort of people who discuss,
well, bug reports when they go to a party.
Subscribe via \tr{glasgow-haskell-bugs-request@dcs.glasgow.ac.uk};
send bug reports and rumination thereupon go to
\tr{glasgow-haskell-bugs}.
\end{description}
|
