[project @ 1996-07-25 20:43:49 by partain]
authorpartain <unknown>
Thu, 25 Jul 1996 21:33:42 +0000 (21:33 +0000)
committerpartain <unknown>
Thu, 25 Jul 1996 21:33:42 +0000 (21:33 +0000)
Bulk of final changes for 2.01

283 files changed:
ANNOUNCE-2.01
README
config.guess
config.sub
configure.in
ghc/CONTRIB/README
ghc/CONTRIB/haskell-modes/README
ghc/README
ghc/compiler/Jmakefile
ghc/compiler/absCSyn/Costs.lhs
ghc/compiler/basicTypes/Id.lhs
ghc/compiler/basicTypes/UniqSupply.lhs
ghc/compiler/coreSyn/CoreLint.lhs
ghc/compiler/coreSyn/CoreUnfold.lhs
ghc/compiler/coreSyn/CoreUtils.lhs
ghc/compiler/coreSyn/NmbrCore.lhs [new file with mode: 0644]
ghc/compiler/deSugar/DsExpr.lhs
ghc/compiler/hsSyn/HsMatches.lhs
ghc/compiler/nativeGen/StixInteger.lhs
ghc/compiler/prelude/PrelVals.lhs
ghc/compiler/prelude/PrimOp.lhs
ghc/compiler/rename/Rename.lhs
ghc/compiler/rename/RnNames.lhs
ghc/compiler/simplCore/BinderInfo.lhs
ghc/compiler/simplCore/FoldrBuildWW.lhs
ghc/compiler/simplCore/MagicUFs.lhs
ghc/compiler/simplCore/SimplCase.lhs
ghc/compiler/simplCore/SimplEnv.lhs
ghc/compiler/simplCore/SimplVar.lhs
ghc/compiler/simplCore/Simplify.lhs
ghc/compiler/specialise/Specialise.lhs
ghc/compiler/stranal/WorkWrap.lhs
ghc/compiler/typecheck/TcExpr.lhs
ghc/compiler/typecheck/TcInstDcls.lhs
ghc/compiler/typecheck/TcInstUtil.lhs
ghc/compiler/typecheck/TcModule.lhs
ghc/compiler/types/Class.lhs
ghc/compiler/types/PprType.lhs
ghc/compiler/types/Type.lhs
ghc/compiler/utils/Bag.lhs
ghc/compiler/utils/FiniteMap.lhs
ghc/compiler/utils/ListSetOps.lhs
ghc/compiler/utils/Maybes.lhs
ghc/compiler/utils/Pretty.lhs
ghc/compiler/utils/Util.lhs
ghc/docs/ANNOUNCE-0.06 [deleted file]
ghc/docs/ANNOUNCE-0.10 [deleted file]
ghc/docs/ANNOUNCE-0.16 [deleted file]
ghc/docs/ANNOUNCE-0.19 [deleted file]
ghc/docs/ANNOUNCE-0.20 [deleted file]
ghc/docs/ANNOUNCE-0.22 [deleted file]
ghc/docs/ANNOUNCE-0.23 [deleted file]
ghc/docs/ANNOUNCE-0.25 [deleted file]
ghc/docs/ANNOUNCE-0.26 [deleted file]
ghc/docs/ANNOUNCE-0.27 [deleted file]
ghc/docs/Jmakefile
ghc/docs/NOTES.adding-PrimOp [deleted file]
ghc/docs/NOTES.arbitary-ints [deleted file]
ghc/docs/NOTES.c-optimisation [deleted file]
ghc/docs/NOTES.core-overview [deleted file]
ghc/docs/NOTES.desugar [deleted file]
ghc/docs/NOTES.garbage.collection [deleted file]
ghc/docs/NOTES.import [deleted file]
ghc/docs/NOTES.interface [deleted file]
ghc/docs/NOTES.mkworld2 [deleted file]
ghc/docs/NOTES.part-of-book [deleted file]
ghc/docs/NOTES.rename [deleted file]
ghc/docs/NOTES.saving-space [deleted file]
ghc/docs/NOTES.update-mechanism [deleted file]
ghc/docs/Prefix_Form [deleted file]
ghc/docs/README
ghc/docs/abstracts/README [deleted file]
ghc/docs/abstracts/abstracts.sty [deleted file]
ghc/docs/abstracts/abstracts89.tex [deleted file]
ghc/docs/abstracts/abstracts90.tex [deleted file]
ghc/docs/abstracts/abstracts91.tex [deleted file]
ghc/docs/abstracts/abstracts92.tex [deleted file]
ghc/docs/abstracts/abstracts93.tex [deleted file]
ghc/docs/abstracts/abstracts94.tex [deleted file]
ghc/docs/abstracts/before90.tex [deleted file]
ghc/docs/abstracts/reports.tex [deleted file]
ghc/docs/abstracts/slpj.sty [deleted file]
ghc/docs/abstracts/useful.sty [deleted file]
ghc/docs/add_to_compiler/Jmakefile [deleted file]
ghc/docs/add_to_compiler/back-end.verb [deleted file]
ghc/docs/add_to_compiler/core-summary-fig.verb [deleted file]
ghc/docs/add_to_compiler/core-syntax.verb [deleted file]
ghc/docs/add_to_compiler/front-end.verb [deleted file]
ghc/docs/add_to_compiler/howto-add.verb [deleted file]
ghc/docs/add_to_compiler/overview-fig.fig [deleted file]
ghc/docs/add_to_compiler/overview.verb [deleted file]
ghc/docs/add_to_compiler/paper.bbl [deleted file]
ghc/docs/add_to_compiler/paper.verb [deleted file]
ghc/docs/add_to_compiler/slides-root.tex [deleted file]
ghc/docs/add_to_compiler/slides.tex [deleted file]
ghc/docs/add_to_compiler/state-of-play.NOTES [deleted file]
ghc/docs/add_to_compiler/state-of-play.verb [deleted file]
ghc/docs/add_to_compiler/stg-summary-fig.verb [deleted file]
ghc/docs/install_guide/Jmakefile
ghc/docs/install_guide/installing.lit
ghc/docs/release_notes/0-02-notes.lit [deleted file]
ghc/docs/release_notes/0-03-README [deleted file]
ghc/docs/release_notes/0-04-README [deleted file]
ghc/docs/release_notes/0-05-notes.lit [deleted file]
ghc/docs/release_notes/0-06-notes.lit [deleted file]
ghc/docs/release_notes/0-07-README [deleted file]
ghc/docs/release_notes/0-07-notes.lit [deleted file]
ghc/docs/release_notes/0-08-notes.lit [deleted file]
ghc/docs/release_notes/0-10-notes.lit [deleted file]
ghc/docs/release_notes/0-16-notes.lit [deleted file]
ghc/docs/release_notes/0-17-notes.lit [deleted file]
ghc/docs/release_notes/0-18-README [deleted file]
ghc/docs/release_notes/0-19-notes.lit [deleted file]
ghc/docs/release_notes/0-22-notes.lit [deleted file]
ghc/docs/release_notes/0-23-notes.lit [deleted file]
ghc/docs/release_notes/0-26-notes.lit [deleted file]
ghc/docs/release_notes/2-01-notes.lit [new file with mode: 0644]
ghc/docs/release_notes/Jmakefile
ghc/docs/release_notes/release.lit
ghc/docs/simple-monad.lhs
ghc/docs/state_interface/Jmakefile
ghc/docs/state_interface/state-interface.verb
ghc/docs/users_guide/Jmakefile
ghc/docs/users_guide/backwards.lit [new file with mode: 0644]
ghc/docs/users_guide/glasgow_exts.lit
ghc/docs/users_guide/gone_wrong.lit
ghc/docs/users_guide/how_to_run.lit
ghc/docs/users_guide/intro.lit
ghc/docs/users_guide/libraries.lit
ghc/docs/users_guide/parallel.lit
ghc/docs/users_guide/prof-compiler-options.lit
ghc/docs/users_guide/prof-rts-options.lit
ghc/docs/users_guide/profiling.lit
ghc/docs/users_guide/recomp.lit [new file with mode: 0644]
ghc/docs/users_guide/runtime_control.lit
ghc/docs/users_guide/sooner.lit
ghc/docs/users_guide/user.lit
ghc/docs/users_guide/utils.lit
ghc/docs/users_guide/vs_haskell.lit
ghc/driver/Jmakefile
ghc/driver/ghc-asm.lprl
ghc/driver/ghc-iface.lprl
ghc/driver/ghc-recomp.lprl
ghc/driver/ghc.lprl
ghc/driver/test_mangler
ghc/includes/COptRegs.lh
ghc/includes/COptWraps.lh
ghc/includes/CostCentre.lh
ghc/includes/GranSim.lh
ghc/includes/LLC.h
ghc/includes/Parallel.lh
ghc/includes/RtsTypes.lh
ghc/includes/Threads.lh
ghc/includes/c-as-asm.lit [deleted file]
ghc/includes/error.h
ghc/includes/ieee-flpt.h
ghc/includes/libposix.h [deleted file]
ghc/includes/platform.h.in
ghc/includes/root.lit [deleted file]
ghc/includes/stgdefs.h
ghc/includes/timezone.h [deleted file]
ghc/lib/Jmakefile
ghc/lib/MODULES [new file with mode: 0644]
ghc/lib/cbits/Jmakefile
ghc/lib/cbits/getLock.lc [new file with mode: 0644]
ghc/lib/cbits/inputReady.lc [new file with mode: 0644]
ghc/lib/cbits/openFile.lc [new file with mode: 0644]
ghc/lib/cbits/readFile.lc [new file with mode: 0644]
ghc/lib/cbits/removeDirectory.lc [new file with mode: 0644]
ghc/lib/cbits/removeFile.lc [new file with mode: 0644]
ghc/lib/cbits/renameDirectory.lc [new file with mode: 0644]
ghc/lib/cbits/renameFile.lc [new file with mode: 0644]
ghc/lib/cbits/seekFile.lc [new file with mode: 0644]
ghc/lib/cbits/setBuffering.lc [new file with mode: 0644]
ghc/lib/cbits/setCurrentDirectory.lc [new file with mode: 0644]
ghc/lib/cbits/stgio.h
ghc/lib/cbits/system.lc [new file with mode: 0644]
ghc/lib/cbits/writeFile.lc [new file with mode: 0644]
ghc/lib/concurrent/Merge.hs
ghc/lib/concurrent/Parallel.hs
ghc/lib/prelude/GHCbase.hs
ghc/lib/prelude/GHCerr.hs [new file with mode: 0644]
ghc/lib/prelude/Main.mc_hi [new file with mode: 0644]
ghc/lib/prelude/Main.mg_hi [new file with mode: 0644]
ghc/lib/prelude/Main.mp_hi [new file with mode: 0644]
ghc/lib/prelude/Main.p_hi [new file with mode: 0644]
ghc/lib/prelude/Prelude.hs
ghc/lib/prelude/PreludeGlaST.hs
ghc/lib/required/List.hs
ghc/misc/spat-analysers/README [deleted file]
ghc/misc/spat-analysers/REGSTATS [deleted file]
ghc/misc/spat-analysers/StgRegAddrs.h [deleted file]
ghc/misc/spat-analysers/icount.c [deleted file]
ghc/misc/spat-analysers/icount_by_activity.c [deleted file]
ghc/misc/spat-analysers/makefile [deleted file]
ghc/misc/spat-analysers/show_icounts [deleted file]
ghc/misc/spat-analysers/spatmain.c [deleted file]
ghc/misc/spat-analysers/stgregs.c [deleted file]
ghc/mkworld/GHC_OPTS
ghc/mkworld/macros-ghc.jm
ghc/mkworld/root.lit [deleted file]
ghc/runtime/Jmakefile
ghc/runtime/c-as-asm/FreeMallocPtr.lc [deleted file]
ghc/runtime/c-as-asm/HpOverflow.lc
ghc/runtime/gum/LLComms.lc
ghc/runtime/gum/Pack.lc
ghc/runtime/gum/ParInit.lc
ghc/runtime/gum/RBH.lc
ghc/runtime/gum/SysMan.lc
ghc/runtime/hooks/ErrorHdr.lc
ghc/runtime/hooks/FreeForeignObj.lc [new file with mode: 0644]
ghc/runtime/hooks/NoRunnableThrds.lc
ghc/runtime/hooks/OutOfHeap.lc
ghc/runtime/hooks/OutOfStk.lc
ghc/runtime/hooks/OutOfVM.lc
ghc/runtime/hooks/PatErrorHdr.lc
ghc/runtime/hooks/TraceHooks.lc
ghc/runtime/main/GranSim.lc
ghc/runtime/main/RtsFlags.lc
ghc/runtime/main/Signals.lc
ghc/runtime/main/StgUpdate.lhc
ghc/runtime/main/Threads.lc
ghc/runtime/main/Ticky.lc
ghc/runtime/storage/SM1s.lc
ghc/runtime/storage/SM2s.lc
ghc/runtime/storage/SMap.lc
ghc/runtime/storage/SMcopying.lc
ghc/runtime/storage/SMmark.lhc
ghc/runtime/storage/SMmarking.lc
ghc/utils/Jmakefile
ghc/utils/hp2ps/TraceElement.h
ghc/utils/hstags/README
ghc/utils/mkdependHS/mkdependHS.prl
ghc/utils/parallel/AVG.pl [new file with mode: 0644]
ghc/utils/parallel/GrAnSim.el [new file with mode: 0644]
ghc/utils/parallel/Jmakefile
ghc/utils/parallel/RTS2gran.pl [new file with mode: 0644]
ghc/utils/parallel/SN.pl [new file with mode: 0644]
ghc/utils/parallel/SPLIT.pl [new file with mode: 0644]
ghc/utils/parallel/aux.pl [new file with mode: 0644]
ghc/utils/parallel/avg-RTS.pl [new file with mode: 0644]
ghc/utils/parallel/get_SN.pl [new file with mode: 0644]
ghc/utils/parallel/gp-ext-imp.pl [new file with mode: 0644]
ghc/utils/parallel/gr2RTS.pl [new file with mode: 0644]
ghc/utils/parallel/gr2ap.bash [new file with mode: 0644]
ghc/utils/parallel/gr2gran.bash [new file with mode: 0644]
ghc/utils/parallel/gr2java.pl [new file with mode: 0644]
ghc/utils/parallel/gr2jv.bash [new file with mode: 0644]
ghc/utils/parallel/gr2pe.pl [new file with mode: 0644]
ghc/utils/parallel/gr2ps.bash
ghc/utils/parallel/gr2qp.pl
ghc/utils/parallel/gran-extr.pl [new file with mode: 0644]
ghc/utils/parallel/grs2gr.pl
ghc/utils/parallel/ps-scale-y.pl [new file with mode: 0644]
ghc/utils/parallel/qp2ap.pl [new file with mode: 0644]
ghc/utils/parallel/qp2ps.pl
ghc/utils/parallel/sn_filter.pl [new file with mode: 0644]
ghc/utils/parallel/stats.pl [new file with mode: 0644]
ghc/utils/parallel/template.pl [new file with mode: 0644]
ghc/utils/parallel/tf.pl [new file with mode: 0644]
ghc/utils/pvm/README
glafp-utils/Jmakefile
glafp-utils/PATCHLEVEL
glafp-utils/README
glafp-utils/etags/Jmakefile [deleted file]
glafp-utils/etags/README [deleted file]
glafp-utils/etags/etags.c [deleted file]
glafp-utils/etags/jbw-fixes [deleted file]
glafp-utils/etags/wells-fixes [deleted file]
glafp-utils/perl-4.035-fixes [deleted file]
glafp-utils/scripts/Jmakefile
glafp-utils/scripts/lndir.c-X11R5 [deleted file]
glafp-utils/scripts/lndir.man [deleted file]
glafp-utils/scripts/lndir.sh [deleted file]
glafp-utils/scripts/mkdependC.prl
glafp-utils/scripts/mkdirhier.man [deleted file]
glafp-utils/scripts/mkdirhier.sh [deleted file]
glafp-utils/scripts/perltags.prl [deleted file]
glafp-utils/scripts/runstdtest.prl
glafp-utils/scripts/zap-if-same.prl [deleted file]
glafp-utils/verbatim/Jmakefile [deleted file]
glafp-utils/verbatim/verbatim.c [deleted file]
glafp-utils/verbatim/verbatim.lex [deleted file]

index 0fc4ab0..d6014f1 100644 (file)
@@ -1,76 +1,96 @@
             The Glasgow Haskell Compiler -- version 2.01
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-We are proud to announce the first public release of the Glasgow
-Haskell Compiler (GHC) for the revised Haskell 1.3 language. Sources
-and binaries are freely available by anonymous FTP and on the
-World-Wide Web; details below.
+We are pleased to announce the first release of the Glasgow Haskell
+Compiler (GHC, version 2.01) for *Haskell 1.3*.  Sources and binaries
+are freely available by anonymous FTP and on the World-Wide Web;
+details below.
+
+Haskell is "the" standard lazy functional programming language; the
+current language version is 1.3, agreed in May, 1996.  The Haskell
+Report is online at
+http://haskell.cs.yale.edu/haskell-report/haskell-report.html.
 
 GHC 2.01 is a test-quality release, worth trying if you are a gung-ho
-Haskell user or if you want to ensure that we quickly fix bugs that
-affect your programs :-) We advise *AGAINST* deleting your copy of
-that old workhorse GHC 0.26 (for Haskell 1.2), and *AGAINST* relying
-on this compiler (2.01) in any way.  With your help in testing 2.01,
-we hope to release a more solid Haskell 1.3 compiler relatively soon.
+Haskell user or if you are keen to try the new Haskell 1.3 features.
+We advise *AGAINST* relying on this compiler (2.01) in any way.  We
+are releasing our current Haskell 1.2 compiler (GHC 0.29) at the same
+time; it should be pretty solid.
+
+If you want to hack on GHC itself, then 2.01 is for you.  The release
+notes comment further on this point.
 
-Haskell is "the" standard lazy functional programming language [see
-SIGPLAN Notices, May 1992].  The current language version is 1.3,
-agreed in May, 1996.
+What happens next?  I'm on sabbatical for a year, and Will Partain
+(the one who really makes GHC go) is leaving at the end of July 96 for
+a Real Job.  So you shouldn't expect rapid progress on 2.01 over the
+next 6-12 months.  
 
 The Glasgow Haskell project seeks to bring the power and elegance of
 functional programming to bear on real-world problems.  To that end,
 GHC lets you call C (including cross-system garbage collection),
-provides good profiling tools, supports ever richer I/O, and
-concurrency and parallelism.  Our goal is to make it the "tool of
-choice for real-world applications".
-
-GHC 2.01 is quite different from 0.26 (July 1995), as the new version
-number suggests.  (The 1.xx numbers are reserved for any Haskell-1.2
-compiler releases.)  Changes worth noting include:
-
-.......
-
-  * Concurrent Haskell: with this, you can build programs out of many
-    I/O-performing, interacting `threads'.  We have a draft paper
-    about Concurrent Haskell, and our forthcoming Haggis GUI toolkit
-    uses it.
-
-  * Parallel Haskell, running on top of PVM (Parallel Virtual Machine)
-    and hence portable to pretty much any parallel architecture,
-    whether shared memory or distributed memory.  With this, your
-    Haskell program runs on multiple processors, guided by `par` and
-    `seq` annotations.  The first pretty-much-everyone-can-try-it
-    parallel functional programming system!  NB: The parallel stuff is
-    "research-tool quality"... consider this an alpha release.
-
-  * "Foldr/build" deforestation (by Andy Gill) is in, as are
-    "SPECIALIZE instance" pragmas (by Patrick Sansom).
-
-  * The LibPosix library provides an even richer I/O interface than
-    the standard 1.3 I/O library.  A program like a shell or an FTP
-    client can be written in Haskell -- examples included.
-
-  * Yet more cool libraries: Readline (GNU command-line editing),
-    Socket (BSD sockets), Regex and MatchPS (GNU regular expressions).
-    By Darren Moffat and Sigbjorn Finne.
-
-  * New ports -- Linux (a.out) and MIPS (Silicon Graphics).
-
-  * NB: configuration has changed yet again -- for the better, of
-    course :-)
+provides good profiling tools, and concurrency and parallelism.  Our
+goal is to make it the "tool of choice for real-world applications".
+
+GHC 2.01 is substantially changed from 0.26 (July 1995), as the new
+version number suggests.  (The 1.xx numbers are reserved for further
+spinoffs from the Haskell-1.2 compiler.)  Changes worth noting
+include:
+
+  * GHC is now a Haskell 1.3 compiler (only).  Virtually all Haskell
+    1.2 modules need changing to go through GHC 2.01; the GHC
+    documentation includes a ``crib sheet'' of conversion advice.
+
+  * The Haskell compiler proper (ghc/compiler/ in the sources) has
+    been substantially rewritten and is, of course, Much, Much,
+    Better.  The typechecker and the "renamer" (module-system support)
+    are new.
+
+  * Sadly, GHC 2.01 is currently slower than 0.26.  It has taken
+    all our cycles to get it correct.  We fondly believe that the
+    architectural changes we have made will end up making 2.0x
+    *faster* than 0.2x, but we have yet to substantiate this belief;
+    sorry.  Still, 2.01 (built with 0.29) is quite usable.
+
+  * GHC 2.01's optimisation (-O) is not nearly as good as 0.2x, mostly
+    because we haven't taught it about cross-module information
+    (arities, inlinings, etc.).  For this reason, a
+    2.01-built-with-2.01 (bootstrapped) is no fun to use (too slow),
+    and, sadly, that is where we would normally get .hc (intermediate
+    C; used for porting) files from... (hence: none provided).
+
+  * GHC 2.01 is much smarter than 0.26 about when to recompile.  It
+    will abort a compilation that "make" thought was necessary at a
+    very early stage, if none of the imported types/classes/functions
+    *that are actually used* have changed.  This "recompilation
+    checker" uses a completely different interface-file format than
+    0.26.  (Interface files are a matter for the compilation system in
+    Haskell 1.3, not part of the language.)
+
+  * The 2.01 libraries are not "split" (yet), meaning you will end up
+    with much larger binaries...
+
+  * The not-mandated-by-the-language system libraries are now separate
+    from GHC (though usually distributed with it).  We hope they can
+    take on a "life of their own", independent of GHC.
+
+  * All the same cool extensions (e.g., unboxed values), system
+    libraries (e.g., Posix), profiling, Concurrent Haskell, Parallel
+    Haskell,...
+
+  * New ports: Linux ELF (same as distributed as GHC 0.28).
 
 Please see the release notes for a complete discussion of What's New.
 
-To run this release, you need a machine with 16+MB memory, GNU C
-(`gcc'), and `perl'.  We have seen GHC 0.26 work on these platforms:
-alpha-dec-osf2, hppa1.1-hp-hpux9, i386-unknown-linuxaout,
-m68k-sun-sunos4, mips-sgi-irix5, and sparc-sun-{sunos4,solaris2}.
-Similar platforms should work with minimal hacking effort.
-The installer's guide give a full what-ports-work report.
+To run this release, you need a machine with 16+MB memory (more if
+building from sources), GNU C (`gcc'), and `perl'.  We have seen GHC
+2.01 work on these platforms: alpha-dec-osf2, hppa1.1-hp-hpux9,
+sparc-sun-{sunos4,solaris2}, mips-sgi-irix5, and
+i386-unknown-{linux,solaris2,freebsd}.  Similar platforms should work
+with minimal hacking effort.  The installer's guide give a full
+what-ports-work report.
 
-Binaries are now distributed in `bundles', e.g. a "profiling bundle"
-or a "concurrency bundle" for your platform.  Just grab the ones you
-need.
+Binaries are distributed in `bundles', e.g. a "profiling bundle" or a
+"concurrency bundle" for your platform.  Just grab the ones you need.
 
 Once you have the distribution, please follow the pointers in
 ghc/README to find all of the documentation about this release.  NB:
@@ -78,32 +98,31 @@ preserve modification times when un-tarring the files (no `m' option
 for tar, please)!
 
 We run mailing lists for GHC users and bug reports; to subscribe, send
-mail to glasgow-haskell-{users,bugs}-request@dcs.glasgow.ac.uk.
-Please send bug reports to glasgow-haskell-bugs.
+mail to majordomo@dcs.gla.ac.uk; the msg body should be:
+
+    subscribe glasgow-haskell-<which> Your Name <your-email@where.you.are>
 
-Particular thanks to: Jim Mattson (author of much of the code) who has
-now moved to HP in California; and the Turing Institute who donated a
-lot of SGI cycles for the SGI port.
+Please send bug reports about GHC to glasgow-haskell-bugs@dcs.gla.ac.uk.
 
-Simon Peyton Jones and Will Partain
+Simon Peyton Jones
 
-Dated: 95/07/24
+Dated: July '96
 
 Relevant URLs on the World-Wide Web:
 
-GHC home page            http://www.dcs.glasgow.ac.uk/fp/software/ghc.html
-Glasgow FP group page     http://www.dcs.glasgow.ac.uk/fp/
+GHC home page            http://www.dcs.gla.ac.uk/fp/software/ghc/
+Glasgow FP group page     http://www.dcs.gla.ac.uk/fp/
 comp.lang.functional FAQ  http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
 
 ======================================================================
-How to get GHC 0.26:
+How to get GHC 2.01:
 
 This release is available by anonymous FTP from the main Haskell
 archive sites, in the directory pub/haskell/glasgow:
 
-       ftp.dcs.glasgow.ac.uk  (130.209.240.50)
-       ftp.cs.chalmers.se     (129.16.227.140)
-       haskell.cs.yale.edu    (128.36.11.43)
+       ftp.dcs.gla.ac.uk   (130.209.240.50)
+       ftp.cs.chalmers.se  (129.16.227.140)
+       haskell.cs.yale.edu (128.36.11.43)
 
 The Glasgow site is mirrored by src.doc.ic.ac.uk (146.169.43.1), in
 computing/programming/languages/haskell/glasgow.
@@ -111,18 +130,18 @@ computing/programming/languages/haskell/glasgow.
 These are the available files (.gz files are gzipped) -- some are `on
 demand', ask if you don't see them:
 
-ghc-0.26-src.tar.gz    The source distribution; about 3MB.
+ghc-2.01-src.tar.gz    The source distribution; about 3MB.
 
-ghc-0.26.ANNOUNCE      This file.
+ghc-2.01.ANNOUNCE      This file.
 
-ghc-0.26.{README,RELEASE-NOTES} From the distribution; for those who
+ghc-2.01.{README,RELEASE-NOTES} From the distribution; for those who
                        want to peek before FTPing...
 
-ghc-0.26-ps-docs.tar.gz        Main GHC documents in PostScript format; in
+ghc-2.01-ps-docs.tar.gz        Main GHC documents in PostScript format; in
                        case your TeX setup doesn't agree with our
                        DVI files...
 
-ghc-0.26-<platform>.tar.gz Basic binary distribution for a particular
+ghc-2.01-<platform>.tar.gz Basic binary distribution for a particular
                        <platform>.  Unpack and go: you can compile
                        and run Haskell programs with nothing but one
                        of these files.  NB: does *not* include
@@ -130,14 +149,15 @@ ghc-0.26-<platform>.tar.gz Basic binary distribution for a particular
 
        <platform> ==>  alpha-dec-osf2
                        hppa1.1-hp-hpux9
-                       i386-unknown-linuxaout
+                       i386-unknown-freebsd
+                       i386-unknown-linux
                        i386-unknown-solaris2
                        m68k-sun-sunos4
                        mips-sgi-irix5
                        sparc-sun-sunos4
                        sparc-sun-solaris2
 
-ghc-0.26-<bundle>-<platform>.tar.gz
+ghc-2.01-<bundle>-<platform>.tar.gz
 
        <platform> ==>  as above
        <bundle>   ==>  prof (profiling)
@@ -148,18 +168,15 @@ ghc-0.26-<bundle>-<platform>.tar.gz
                        prof-conc (profiling for "conc[urrent]")
                        prof-ticky (ticky for "conc[urrent]")
 
-ghc-0.26-hc-files.tar.gz Basic set of intermediate C (.hc) files for the
+ghc-2.01-hc-files.tar.gz Basic set of intermediate C (.hc) files for the
                         compiler proper, the prelude, and `Hello,
                         world'.  Used for bootstrapping the system.
                         About 4MB.
 
-ghc-0.26-<bundle>-hc-files.tar.gz Further sets of .hc files, for
+ghc-2.01-<bundle>-hc-files.tar.gz Further sets of .hc files, for
                        building other "bundles", e.g., profiling.
 
-ghc-0.26-hi-files-<blah>.tar.gz Sometimes it's more convenient to
+ghc-2.01-hi-files-<blah>.tar.gz Sometimes it's more convenient to
                        use a different set of interface files than
                        the ones in *-src.tar.gz.  (The installation
                        guide will advise you of this.)
-
-We could provide diffs from previous versions of GHC, should you
-require them.  A full set would be very large (7MB).
diff --git a/README b/README
index 590a8bb..f509e56 100644 (file)
--- a/README
+++ b/README
@@ -1,9 +1,10 @@
 This is the root directory for functional-programming tools
 distributed by the Computing Science Department at Glasgow University.
-Simon Peyton Jones <simonpj@dcs.glasgow.ac.uk> is the ringleader
-of this effort.  The tools are:
+Simon Peyton Jones <simonpj@dcs.gla.ac.uk> is the ringleader of this
+effort.  The tools are:
 
     ghc                the Glasgow Haskell compilation system
+    hslibs     collection of Haskell libraries
     haggis     the Haggis GUI toolkit
     happy      the Happy Haskell parser generator
     nofib      the NoFib Haskell benchmarking suite
index c3c4e79..c416b78 100644 (file)
@@ -51,15 +51,13 @@ trap 'rm -f dummy.c dummy.o dummy; exit 1' 1 2 15
 # Note: order is significant - the case branches are not exclusive.
 
 case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
-    alpha:OSF1:[VX]*:*)
-       # After 1.2, OSF1 uses "V1.3" for uname -r.
-       # After 4.x, OSF1 uses "X4.x" for uname -r.
-       echo alpha-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[VX]//'`
-       exit 0 ;;
     alpha:OSF1:*:*)
+       # A Vn.n version is a released version.
+       # A Tn.n version is a released field test version.
+       # A Xn.n version is an unreleased experimental baselevel.
        # 1.2 uses "1.2" for uname -r.
-       echo alpha-dec-osf${UNAME_RELEASE}
-        exit 0 ;;
+       echo alpha-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[VTX]//'`
+       exit 0 ;;
     21064:Windows_NT:50:3)
        echo alpha-dec-winnt3.5
        exit 0 ;;
@@ -118,11 +116,27 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
     VAX*:ULTRIX*:*:*)
        echo vax-dec-ultrix${UNAME_RELEASE}
        exit 0 ;;
-    mips:*:4*:UMIPS)
-       echo mips-mips-riscos4sysv
-       exit 0 ;;
-    mips:*:5*:RISCos)
-       echo mips-mips-riscos${UNAME_RELEASE}
+    mips:*:*:UMIPS | mips:*:*:RISCos)
+       sed 's/^        //' << EOF >dummy.c
+       int main (argc, argv) int argc; char **argv; {
+       #if defined (host_mips) && defined (MIPSEB)
+       #if defined (SYSTYPE_SYSV)
+         printf ("mips-mips-riscos%ssysv\n", argv[1]); exit (0);
+       #endif
+       #if defined (SYSTYPE_SVR4)
+         printf ("mips-mips-riscos%ssvr4\n", argv[1]); exit (0);
+       #endif
+       #if defined (SYSTYPE_BSD43) || defined(SYSTYPE_BSD)
+         printf ("mips-mips-riscos%sbsd\n", argv[1]); exit (0);
+       #endif
+       #endif
+         exit (-1);
+       }
+EOF
+       ${CC-cc} dummy.c -o dummy && ./dummy "${UNAME_RELEASE}" \
+         && rm dummy.c dummy && exit 0
+       rm -f dummy.c dummy
+       echo mips-mips-riscos{UNAME_RELEASE}
        exit 0 ;;
     Night_Hawk:Power_UNIX:*:*)
        echo powerpc-harris-powerunix
@@ -138,8 +152,8 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
        exit 0 ;;
     AViiON:dgux:*:*)
         # DG/UX returns AViiON for all architectures
-        UNAME_PROCESSOR=`uname -p`
-        if [ $UNAME_PROCESSOR = mc88100 -o $UNAME_PROCESSOR = mc88100 ] ; then
+        UNAME_PROCESSOR=`/usr/bin/uname -p`
+        if [ $UNAME_PROCESSOR = mc88100 -o $UNAME_PROCESSOR = mc88110 ] ; then
        if [ ${TARGET_BINARY_INTERFACE}x = m88kdguxelfx \
             -o ${TARGET_BINARY_INTERFACE}x = x ] ; then
                echo m88k-dg-dgux${UNAME_RELEASE}
@@ -213,7 +227,7 @@ EOF
        echo romp-ibm-bsd4.4
        exit 0 ;;
     ibmrt:*BSD:*|romp-ibm:BSD:*)            # covers RT/PC NetBSD and
-       echo romp-ibm-bsd${UNAME_RELEASE}   # 4.3 with uname added to 
+       echo romp-ibm-bsd${UNAME_RELEASE}   # 4.3 with uname added to
        exit 0 ;;                           # report: romp-ibm BSD 4.3
     *:BOSX:*:*)
        echo rs6000-bull-bosx
@@ -330,6 +344,9 @@ EOF
     p*:CYGWIN*:*)
        echo powerpcle-unknown-cygwin32
        exit 0 ;;
+    prep*:SunOS:5.*:*)
+       echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
+       exit 0 ;;
     *:GNU:*:*)
        echo `echo ${UNAME_MACHINE}|sed -e 's,/.*$,,'`-unknown-gnu`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'`
        exit 0 ;;
@@ -347,8 +364,12 @@ EOF
          echo "${UNAME_MACHINE}-unknown-linux" ; exit 0
        elif echo "$ld_help_string" | grep >/dev/null 2>&1 "supported emulations: m68klinux"; then
          echo "${UNAME_MACHINE}-unknown-linuxaout" ; exit 0
+       elif echo "$ld_help_string" | grep >/dev/null 2>&1 "supported emulations: elf32ppc"; then
+         echo "powerpc-unknown-linux" ; exit 0
        elif test "${UNAME_MACHINE}" = "alpha" ; then
          echo alpha-unknown-linux ; exit 0
+       elif test "${UNAME_MACHINE}" = "sparc" ; then
+         echo sparc-unknown-linux ; exit 0
        else
          # Either a pre-BFD a.out linker (linuxoldld) or one that does not give us
          # useful --help.  Gcc wants to distinguish between linuxoldld and linuxaout.
@@ -416,9 +437,15 @@ EOF
        exit 0 ;;
     M680[234]0:*:R3V[567]*:*)
        test -r /sysV68 && echo 'm68k-motorola-sysv' && exit 0 ;;
-    3[34]??:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0)
+    3[34]??:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 4850:*:4.0:3.0)
+       UNAME_REL=4.3
+       if test -f /etc/.relid; then
+         UNAME_REL=4.3.`awk '{ print $3 }' /etc/.relid`
+       fi
         uname -p 2>/dev/null | grep 86 >/dev/null \
-          && echo i486-ncr-sysv4.3 && exit 0 ;;
+          && echo i486-ncr-sysv$UNAME_REL && exit 0
+        uname -p 2>/dev/null | /bin/grep entium >/dev/null \
+          && echo i586-ncr-sysv$UNAME_REL && exit 0 ;;
     3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*)
         uname -p 2>/dev/null | grep 86 >/dev/null \
           && echo i486-ncr-sysv4 && exit 0 ;;
index c462f8a..c697467 100644 (file)
@@ -815,7 +815,7 @@ case $os in
        # Each alternative MUST END IN A *, to match a version number.
        # -sysv* is not here because it comes later, after sysvr4.
        -gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
-             | -vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[3456]* \
+             | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[3456]* \
              | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
              | -amigados* | -msdos* | -moss* | -newsos* | -unicos* | -aos* | -aof* \
              | -nindy* | -mon960* | -vxworks* | -ebmon* | -hms* | -mvs* | -clix* \
@@ -830,7 +830,7 @@ case $os in
        # CYGNUS LOCAL
        -sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \
              | -windows* | -osx | -abug |  -netware* | -proelf | -os9* \
-             | -macos* | -mpw* | -magic*)
+             | -macos* | -mpw* | -magic* | -rtems*)
                ;;
        -mac*)
                os=`echo $os | sed -e 's|mac|macos|'`
index b799d4f..b8f2279 100644 (file)
@@ -648,7 +648,7 @@ AC_ARG_WITH(hc,
         c | C)  WithHc='C'
                 ;;
         in-place )
-                WithHc='IN-PLACE'
+               WithHc='IN-PLACE'
                 ;;
         *)      echo "I don't understand this option: --with-hc=$withval"
                 exit 1
@@ -686,6 +686,7 @@ case $WithHc in
     c | C)  WithHcType='HC_USE_HC_FILES'
             ;;
     IN-PLACE) WithHcType='HC_GLASGOW_GHC'
+             WithHc='$(TOP_PWD)/ghc/driver/ghc'
            ;;
 esac
 AC_SUBST(WithHc)
@@ -699,16 +700,15 @@ AC_ARG_WITH(gcc,
    [HaveGcc=YES; WhatGccIsCalled="$withval"])
 AC_SUBST(WhatGccIsCalled)
 
-dnl ** Choose which make to use (default 'make -r')
-MakeCmd='make -r'
+dnl ** Choose which make to use (default 'make')
+MakeCmd='make'
 AC_ARG_WITH(make,
    [ 
 --with-make=<make command> 
        Use an alternate command instead of 'make'.  This is useful
        when GNU make is required (for instance when the default make
        supplied by the system won't work, as is the case on FreeBSD
-       and NetBSD).  You probably want to include the '-r' flag with
-       make, to exclude implicit suffix rules.],
+       and NetBSD).],
    [MakeCmd="$withval"]) 
 AC_SUBST(MakeCmd)
 
@@ -741,16 +741,19 @@ AC_SUBST(HcMaxHeapWasSet)
 AC_SUBST(HcMaxHeap)
 
 dnl ** figure out about mkdependHS
-MkDependHSCmd=':'
+MkDependHSCmd='mkdependHS'
 if test -f ./ghc/utils/mkdependHS/mkdependHS \
      -o -f ./ghc/utils/mkdependHS/mkdependHS.prl ; then
     MkDependHSCmd='TopDirPwd/ghc/utils/mkdependHS/mkdependHS'
-else
-    AC_CHECK_PROG(have_mkdependHS,mkdependHS,YES,NO)
-    if test $have_mkdependHS = 'YES' ; then
-       MkDependHSCmd='mkdependHS'
-    fi
 fi
+AC_ARG_WITH(mkdependHS,
+   [--with-mkdependHS=<mkdependHS command>
+       Use a different command instead of 'mkdependHS'.],
+   [MkDependHSCmd="$withval"])
+dnl AC_CHECK_PROG(have_mkdependHS,$MkDependHSCmd,YES,NO)
+dnl if test $have_mkdependHS = 'NO' ; then
+dnl     MkDependHSCmd=':'
+dnl fi
 AC_SUBST(MkDependHSCmd)
 
 # -------------------------------------------------------------------------
@@ -764,7 +767,7 @@ if echo $CPP | egrep gcc >/dev/null 2>&1; then
     echo '/(\S+\/cpp)/ && print "$1";' > conftest.pl
     # GNUCPP: used in jmake.c (GnuCppCmd) and in mkdependC
     # (where we could do with the usual pre-#defines)
-    GNUCPP="gcc -E"
+    GNUCPP="`eval $PerlCmd -n conftest.pl conftest.out`"
     test -n "$verbose" && echo "        setting GNUCPP to $GNUCPP"
     # RAWCPP: we do not want *any* pre-#defines...
     # (e.g., hscpp, mkdependHS)
@@ -1558,7 +1561,7 @@ option, if used, overrides --with-hc=<...>:
                 WithHsLibsHc=$withval
                 ;;
         in-place )
-                WithHsLibsHc='IN-PLACE'
+               WithHsLibsHc='IN-PLACE'
                 ;;
         *)      echo "I don't understand this option: --with-hc-for-hslibs=$withval"
                 exit 1
@@ -1582,6 +1585,7 @@ case $WithHsLibsHc in
             fi
             ;;
     IN-PLACE) WithHsLibsHcType='HC_GLASGOW_GHC'
+             WithHsLibsHc='$(TOP_PWD)/ghc/driver/ghc'
            ;;
 esac
 AC_SUBST(WithHsLibsHc)
@@ -1640,7 +1644,7 @@ The Haskell compiler to compile Happy; this option, if used, overrides
         nhc* )  WithHappyHc=$withval
                 ;;
         in-place )
-                WithHappyHc='IN-PLACE'
+               WithHappyHc='IN-PLACE'
                 ;;
         *)      echo "I don't understand this option: --with-hc-for-happy=$withval"
                 exit 1
@@ -1680,6 +1684,7 @@ case $WithHappyHc in
             fi
             ;;
     IN-PLACE) WithHappyHcType='HC_GLASGOW_GHC'
+                WithHappyHc='$(TOP_PWD)/ghc/driver/ghc'
            ;;
 esac
 AC_SUBST(WithHappyHc)
@@ -1715,7 +1720,7 @@ used, overrides --with-hc=<...>:
                 WithHaggisHc=$withval
                 ;;
         in-place )
-                WithHaggisHc='IN-PLACE'
+               WithHaggicHs='IN-PLACE'
                 ;;
         *)      echo "I don't understand this option: --with-hc-for-haggis=$withval"
                 exit 1
@@ -1739,6 +1744,7 @@ case $WithHaggisHc in
             fi
             ;;
     IN-PLACE) WithHaggisHcType='HC_GLASGOW_GHC'
+                WithHaggisHc='$(TOP_PWD)/ghc/driver/ghc'
            ;;
 esac
 AC_SUBST(WithHaggisHc)
@@ -1753,29 +1759,11 @@ fi
 dnl
 dnl * `Literate' CONFIGURATION STUFF
 
-if test "xxx$DoingLiterate" = 'xxxliterate' ; then
-# a very big "if"!
-
-BuildInfoUtils='NO'
-AC_ARG_ENABLE(info-utils,
-   [
-*******************************************************************
-** Literate programming system OPTIONS:
-
---enable-info-utils       build GNU info/makeinfo utilities],
-   [case "$enableval" in
-        yes) BuildInfoUtils='YES'
-             ;;
-        no)  BuildInfoUtils='NO'
-             ;;
-        *)   echo "I don't understand this option: --enable-info-utils=$enableval"
-             exit 1
-             ;;
-    esac])
-AC_SUBST(BuildInfoUtils)
-
-# here ends a very big if DoingLiterate = 'literate' ...
-fi
+dnl if test "xxx$DoingLiterate" = 'xxxliterate' ; then
+dnl # a very big "if"!
+dnl 
+dnl # here ends a very big if DoingLiterate = 'literate' ...
+dnl fi
 #
 # -------------------------------------------------------------------------
 dnl
@@ -1812,7 +1800,7 @@ used, overrides --with-hc=<...>:
         nhc* )  WithNoFibHc=$withval
                 ;;
         in-place )
-                WithNoFibHc='IN-PLACE'
+               WithNoFibHc='IN-PLACE'
                 ;;
         *)      echo "I don't understand this option: --with-hc-for-nofib=$withval"
                 exit 1
@@ -1852,6 +1840,7 @@ case $WithNoFibHc in
             fi
             ;;
     IN-PLACE) WithNoFibHcType='HC_GLASGOW_GHC'
+                WithNoFibHc='$(TOP_PWD)/ghc/driver/ghc'
            ;;
 esac
 AC_SUBST(WithNoFibHc)
@@ -2034,15 +2023,9 @@ for xx in Real Spectral Imaginary GHC_ONLY Specialise PRIVATE Parallel ; do
     echo "#endif"                            >> nofib/mkworld/buildinfo.jm
 done
 
-# Here, by HACK means, we dump all the Build_ info
+# Here, by HACK means, we add all the Build_ info
 # into a file.  See comment above.
-rm -f nofib/mkworld/buildinfo.jm
-echo creating nofib/mkworld/buildinfo.jm
-cat > nofib/mkworld/buildinfo.jm <<EOF
-XCOMM ** DO NOT EDIT! **
-XCOMM This file is obliterated every time 'configure' is run!
 
-EOF
 for xx in normal p t u mc mr mt mp mg 2s 1s du a b c d e f g h i j k l m n o A B ; do
     eval "yy=\$Build_$xx"
     echo "#ifndef Build_$xx"     >> nofib/mkworld/buildinfo.jm
index df029e9..4adab28 100644 (file)
@@ -5,10 +5,12 @@ fptags                Denis Howe <dbh@doc.ic.ac.uk>
                Bourne-shell script.
                Create an emacs tags file for one or more functional programs.
 
-haskell.el     A Haskell mode from Simon Marlow <simonm@dcs.glasgow.ac.uk>.
+haskell-modes/ A collection of all known "Haskell modes" for GNU Emacs.        
 
 haskel.gif     Provided by Lennart Augustsson <augustss@cs.chalmers.se>
 
+haskell_poem   Speaks for itself.
+
 mira2hs                Denis Howe <dbh@doc.ic.ac.uk>
                Bourne-shell script.
                Convert Miranda code to Haskell, more-or-less.
index 248460d..c931787 100644 (file)
@@ -7,7 +7,7 @@ include advertising or testimonials from happy users if they send them
 along...
 
 Will Partain
-partain@dcs.glasgow.ac.uk
+partain@dcs.gla.ac.uk
 95/12/05
 
 =======================================================================
@@ -20,7 +20,7 @@ partain@dcs.glasgow.ac.uk
   chalmers/thiemann -- Peter Thiemann added "indentation stuff"
        and fontification -- version 0.2.
 
-  chalmers/sof -- Sigbjorn Finne's <sof@dcs.glasgow.ac.uk> hacked
+  chalmers/sof -- Sigbjorn Finne's <sof@dcs.gla.ac.uk> hacked
        version of Thiemann's.
 
 .......................................................................
@@ -52,4 +52,4 @@ partain@dcs.glasgow.ac.uk
   yale/chak : "extended by Manuel M.T. Chakravarty with rudimentary
        editing features (including better syntax table) and support
        for the font-lock-mode."  Via Hans Wolfgang Loidl
-       <hwloidl@dcs.glasgow.ac.uk>
+       <hwloidl@dcs.gla.ac.uk>
index ea726df..8dfc890 100644 (file)
@@ -1,12 +1,16 @@
 This is version 2.01 of the Glorious Glasgow Haskell compilation
-system (GHC).  This is a major public release.  The top-level file
-"ANNOUNCE-0.28" says more.
+system (GHC).  GHC 2.01 is a compiler for Haskell 1.3.
 
-Haskell is "the" standard lazy functional programming language [see
-SIGPLAN Notices, May 1992]. Some general merits of GHC are given at
-the end of this file.
+2.01 is a full GHC release; however, as the first release of the 1.3
+compiler, it is "test" quality; it very well may have serious bugs.
+The top-level file "ANNOUNCE-2.01" says more.
 
-Documentation of interest:
+Haskell is "the" standard lazy functional programming language.
+Haskell 1.3 is the current version of the language, released in
+May. 1996.  The language definition is on the Web at
+http://haskell.cs.yale.edu/haskell-report/haskell-report.html
+
+GHC documentation of interest:
 
 * docs/install_guide/installing.{dvi,info,html}: How to configure,
   build, and install the system.
@@ -29,50 +33,54 @@ do not suffer or grumble in silence.  The "bug reports" section of the
 User's Guide (docs/users_guide/user.{dvi,info,html}) says what we
 would like to know when you report a problem.
 
-Current AQUA team (all @dcs.glasgow.ac.uk):
+Current AQUA team (all @dcs.gla.ac.uk):
 
     Sigbjorn Finne     (sof)       [PhD student]
-    Andy Gill          (andy)      [PhD student]
-    Kevin Hammond      (kh)        [GRASP; now a research fellow]
+    Hans Wolfgang Loidl (hwloidl)   [PhD student]
     Simon Marlow       (simonm)    [PhD student]
-    Darren Moffat      (moffatd)   [slave, summer '95]
     Will Partain       (partain)   [hired hand, GRASP/AQUA]
     Simon Peyton Jones (simonpj)   [our Fearless Leader]
-    Patrick Sansom     (sansom)    [hired hand, "Bidirectional Analyses"]
-    Andr\'e Santos     (andre)     [PhD student]
+    Patrick Sansom     (sansom)    [hired hand, Bidirectional Analyses]
+    Phil Trinder       (trinder)   [hired hand, Parade]
+    David N Turner     (dnt)       [hired hand, Linear Types]
 
 Past contributors and/or continuing advisors:
-    Cordy Hall         (cvh)       [GRASP; now at Open University]
-    John Launchbury    (jl)        [AQUA; now at OGI]
-    Jim Mattson                (mattson)   [hired hand, AQUA; just moved to HP]
+
+    Andy Gill          (andy)      [PhD student; at HP]
+    Cordy Hall         (cvh)       [GRASP]
+    Kevin Hammond      (kh)        [GRASP; at St. Andrews]
+    John Launchbury    (jl)        [AQUA; at OGI]
+    Jim Mattson                (mattson)   [hired hand, AQUA; HP]
+    Darren Moffat      (moffatd)   [slave, summer '95; at MoD]
     Bryan O'Sullivan   (bos)       [visiting slave, summer '94; at Sun]
-    Alastair Reid      (areid)     [GHCI god, now working at Yale]
-    Phil Wadler                (wadler)    [GRASP]
+    Alastair Reid      (areid)     [GHCI god, at Yale]
+    Andr\'e Santos     (andre)     [PhD student; back in Brazil]
+    Phil Wadler                (wadler)    [GRASP; at Lucent soon]
 
 Cool people who've let us use their machines:
+
     hppa1.1-hp-hpux    Sam Nelson, Stirling University
-    mips-sgi-irix5     Tim Niblett, Turing Institute, Glasgow
-    sparc-sun-solaris2 Durham University
+    powerpc-ibm-aix    Walter Robinson, Mechanical Eng'g, Glasgow U.
 
 Simon's projects' acronyms:
     GRIP  ('87-'90): Graph reduction in parallel
     GRASP ('90-'92): Graph reduction applications support project
     AQUA  ('93-   ): Declarative systems architecture: a quantitative approach
 
-Dated: 95/07/24
+Dated: 96/07
 
-GHC WWW page: http://www.dcs.glasgow.ac.uk/fp/software/ghc.html
+GHC WWW page: http://www.dcs.gla.ac.uk/fp/software/ghc.html
 
 E-mail contacts:
-    glasgow-haskell-request@dcs.glasgow.ac.uk   (general queries)
+    glasgow-haskell-request@dcs.gla.ac.uk   (admin & general queries)
 
-    glasgow-haskell-bugs@dcs.glasgow.ac.uk     (bug reports mailing list)
-    glasgow-haskell-users@dcs.glasgow.ac.uk    (users' mailing list)
+    glasgow-haskell-bugs@dcs.gla.ac.uk     (bug reports mailing list)
+    glasgow-haskell-users@dcs.gla.ac.uk            (users' mailing list)
 
-    glasgow-haskell-bugs-request@...           to join, send mail *here*
-    glasgow-haskell-users-request@...          to join, send mail *here*
+    glasgow-haskell-bugs-request@...       to join, send mail *here*
+    glasgow-haskell-users-request@...      to join, send mail *here*
 
-Anonymous FTP site: ftp.dcs.glasgow.ac.uk:pub/haskell/glasgow.  Mostly
-mirrored by ftp.cs.chalmers.se and nebula.cs.yale.edu (same
+Anonymous FTP site: ftp.dcs.gla.ac.uk:pub/haskell/glasgow.  Mostly
+mirrored by ftp.cs.chalmers.se and haskell.cs.yale.edu (same
 directory).  Also: src.doc.ic.ac.uk, in
 computing/programming/languages/haskell/glasgow/.
index 7bc091c..925f261 100644 (file)
@@ -819,8 +819,8 @@ NormalLibraryTarget(hsp,$(HSP_OBJS_O))
 /* BuildPgmFromCFiles(hsp,parser/printtree.o parser/main.o,,libhsp.a) */
 
 #if DoInstallGHCSystem == YES
-MakeDirectories(install, $(INSTLIBDIR_GHC))
-InstallBinaryTarget(hsp,$(INSTLIBDIR_GHC))
+/* MakeDirectories(install, $(INSTLIBDIR_GHC)) */
+/* InstallBinaryTarget(hsp,$(INSTLIBDIR_GHC)) */
 #endif /* DoInstall... */
 
 YaccRunWithExpectMsg(parser/hsparser,12,0)
index c32b010..5c03e36 100644 (file)
@@ -368,6 +368,7 @@ stmtMacroCosts macro modes =
     GRAN_RESCHEDULE            ->  nullCosts     {- GrAnSim bookkeeping -}
     GRAN_FETCH_AND_RESCHEDULE  ->  nullCosts     {- GrAnSim bookkeeping -}
     THREAD_CONTEXT_SWITCH      ->  nullCosts     {- GrAnSim bookkeeping -}
+    _ -> trace "Costs.stmtMacroCosts" nullCosts
 
 -- ---------------------------------------------------------------------------
 
index 7096362..79313ba 100644 (file)
@@ -40,6 +40,7 @@ module Id (
        idType,
        idUnique,
 
+       dataConRepType,
        dataConArgTys,
        dataConArity,
        dataConNumFields,
@@ -107,6 +108,7 @@ module Id (
        getIdUpdateInfo,
        getPragmaInfo,
        replaceIdInfo,
+       addInlinePragma,
 
        -- IdEnvs AND IdSets
        SYN_IE(IdEnv), SYN_IE(GenIdSet), SYN_IE(IdSet),
@@ -169,7 +171,7 @@ import MatchEnv             ( MatchEnv )
 import SrcLoc          ( mkBuiltinSrcLoc )
 import TyCon           ( TyCon, mkTupleTyCon, tyConDataCons )
 import Type            ( mkSigmaTy, mkTyVarTys, mkFunTys, mkDictTy,
-                         applyTyCon, instantiateTy,
+                         applyTyCon, instantiateTy, mkForAllTys,
                          tyVarsOfType, applyTypeEnvToTy, typePrimRep,
                          GenType, SYN_IE(ThetaType), SYN_IE(TauType), SYN_IE(Type)
                        )
@@ -816,6 +818,10 @@ idWantsToBeINLINEd :: Id -> Bool
 
 idWantsToBeINLINEd (Id _ _ _ _ IWantToBeINLINEd _) = True
 idWantsToBeINLINEd _                              = False
+
+addInlinePragma :: Id -> Id
+addInlinePragma (Id u sn ty details _ info)
+  = Id u sn ty details IWantToBeINLINEd info
 \end{code}
 
 For @unlocaliseId@: See the brief commentary in
@@ -1392,6 +1398,25 @@ dataConSig (Id _ _ _ (TupleConId arity) _ _)
     tyvars     = take arity alphaTyVars
     tyvar_tys  = mkTyVarTys tyvars
 
+
+-- dataConRepType returns the type of the representation of a contructor
+-- This may differ from the type of the contructor Id itself for two reasons:
+--     a) the constructor Id may be overloaded, but the dictionary isn't stored
+--     b) the constructor may store an unboxed version of a strict field.
+-- Here's an example illustrating both:
+--     data Ord a => T a = MkT Int! a
+-- Here
+--     T :: Ord a => Int -> a -> T a
+-- but the rep type is
+--     Trep :: Int# -> a -> T a
+-- Actually, the unboxed part isn't implemented yet!
+
+dataConRepType :: GenId (GenType tv u) -> GenType tv u
+dataConRepType con
+  = mkForAllTys tyvars tau
+  where
+    (tyvars, theta, tau) = splitSigmaTy (idType con)
+
 dataConFieldLabels :: DataCon -> [FieldLabel]
 dataConFieldLabels (Id _ _ _ (DataConId _ _ fields _ _ _ _) _ _) = fields
 dataConFieldLabels (Id _ _ _ (TupleConId _)                _ _) = []
index 88ac980..3cb2ca7 100644 (file)
@@ -103,7 +103,8 @@ mkSplitUniqSupply (C# c#)
                    returnPrimIO (I# (w2i (mask# `or#` u#)))
     in
 #if __GLASGOW_HASKELL__ >= 200
-    primIOToIO mk_supply#
+    primIOToIO mk_supply#      >>= \ s ->
+    return s
 #else
     mk_supply# `thenPrimIO` \ s ->
     return s
index f72c11e..99afabc 100644 (file)
@@ -18,7 +18,7 @@ import CoreSyn
 import Bag
 import Kind            ( hasMoreBoxityInfo, Kind{-instance-} )
 import Literal         ( literalType, Literal{-instance-} )
-import Id              ( idType, isBottomingId,
+import Id              ( idType, isBottomingId, dataConRepType,
                          dataConArgTys, GenId{-instances-},
                          emptyIdSet, mkIdSet, intersectIdSets,
                          unionIdSets, elementOfIdSet, SYN_IE(IdSet)
@@ -198,14 +198,8 @@ lintCoreExpr (Let binds body)
        (addInScopeVars binders (lintCoreExpr body))
 
 lintCoreExpr e@(Con con args)
-  = lintCoreArgs {-False-} e unoverloaded_ty args
+  = lintCoreArgs {-False-} e (dataConRepType con) args
     -- Note: we don't check for primitive types in these arguments
-  where
-       -- Constructors are special in that they aren't passed their
-       -- dictionary arguments, so we swizzle them out of the
-       -- constructor type before handing over to lintCorArgs
-    unoverloaded_ty = mkForAllTys tyvars tau
-    (tyvars, theta, tau) = splitSigmaTy (idType con)
 
 lintCoreExpr e@(Prim op args)
   = lintCoreArgs {-True-} e (primOpType op) args
index c45c498..247e969 100644 (file)
@@ -48,7 +48,7 @@ import IdInfo         ( arityMaybe, bottomIsGuaranteed )
 import Literal         ( isNoRepLit, isLitLitLit )
 import Pretty
 import TyCon           ( tyConFamilySize )
-import Type            ( getAppDataTyConExpandingDicts )
+import Type            ( maybeAppDataTyConExpandingDicts )
 import UniqSet         ( emptyUniqSet, unitUniqSet, mkUniqSet,
                          addOneToUniqSet, unionUniqSets
                        )
@@ -229,10 +229,16 @@ calcUnfoldingGuidance scc_s_OK bOMB_OUT_SIZE expr
                        (length val_binders)
                        (map discount_for val_binders)
                        size
-              discount_for b | b `is_elem` cased_args = tyConFamilySize tycon
-                             | otherwise              = 0
-                             where
-                               (tycon, _, _) = getAppDataTyConExpandingDicts (idType b)
+
+              discount_for b
+                | is_data && b `is_elem` cased_args = tyConFamilySize tycon
+                | otherwise = 0
+                where
+                  (is_data, tycon)
+                    = --trace "CoreUnfold.getAppDataTyConExpandingDicts:1" $ 
+                       case (maybeAppDataTyConExpandingDicts (idType b)) of
+                         Nothing       -> (False, panic "discount")
+                         Just (tc,_,_) -> (True,  tc)
           in
           -- pprTrace "calcUnfold:" (ppAbove (ppr PprDebug uf) (ppr PprDebug expr))
           uf
@@ -307,7 +313,7 @@ sizeExpr scc_s_OK bOMB_OUT_SIZE args expr
     ------------
     size_up_alts scrut_ty (AlgAlts alts deflt)
       = foldr (addSize . size_alg_alt) (size_up_deflt deflt) alts
-               `addSizeN` (tyConFamilySize tycon)
+               `addSizeN` (if is_data then tyConFamilySize tycon else 1{-??-})
        -- NB: we charge N for an alg. "case", where N is
        -- the number of constructors in the thing being eval'd.
        -- (You'll eventually get a "discount" of N if you
@@ -316,8 +322,11 @@ sizeExpr scc_s_OK bOMB_OUT_SIZE args expr
        size_alg_alt (con,args,rhs) = size_up rhs
            -- Don't charge for args, so that wrappers look cheap
 
-       (tycon, _, _) = --trace "CoreUnfold.getAppDataTyConExpandingDicts" $ 
-                       getAppDataTyConExpandingDicts scrut_ty
+       (is_data,tycon)
+         = --trace "CoreUnfold.getAppDataTyConExpandingDicts:2" $ 
+           case (maybeAppDataTyConExpandingDicts scrut_ty) of
+             Nothing       -> (False, panic "size_up_alts")
+             Just (tc,_,_) -> (True, tc)
 
     size_up_alts _ (PrimAlts alts deflt)
       = foldr (addSize . size_prim_alt) (size_up_deflt deflt) alts
@@ -345,7 +354,6 @@ sizeExpr scc_s_OK bOMB_OUT_SIZE args expr
     sizeZero  = Just (0, [])
     sizeOne   = Just (1, [])
     sizeN n   = Just (n, [])
-    sizeVar v = Just (0, [v])
 
     addSizeN Nothing _ = Nothing
     addSizeN (Just (n, xs)) m
index 9bc5a17..de0d323 100644 (file)
@@ -32,6 +32,7 @@ import CoreSyn
 import CostCentre      ( isDictCC, CostCentre, noCostCentre )
 import Id              ( idType, mkSysLocal, getIdArity, isBottomingId,
                          toplevelishId, mkIdWithNewUniq, applyTypeEnvToId,
+                         dataConRepType,
                          addOneToIdEnv, growIdEnvList, lookupIdEnv,
                          isNullIdEnv, SYN_IE(IdEnv),
                          GenId{-instances-}
@@ -50,7 +51,7 @@ import TyVar          ( cloneTyVar,
                          isNullTyVarEnv, addOneToTyVarEnv, SYN_IE(TyVarEnv)
                        )
 import Type            ( mkFunTy, mkForAllTy, mkForAllUsageTy, mkTyVarTy,
-                         getFunTy_maybe, applyTy, isPrimType,
+                         getFunTyExpandingDicts_maybe, applyTy, isPrimType,
                          splitSigmaTy, splitFunTy, eqTy, applyTypeEnvToTy
                        )
 import TysWiredIn      ( trueDataCon, falseDataCon )
@@ -86,7 +87,7 @@ coreExprType (Coerce _ ty _)  = ty -- that's the whole point!
 -- a Con is a fully-saturated application of a data constructor
 -- a Prim is <ditto> of a PrimOp
 
-coreExprType (Con con args) = applyTypeToArgs (idType    con) args
+coreExprType (Con con args) = applyTypeToArgs (dataConRepType    con) args
 coreExprType (Prim op args) = applyTypeToArgs (primOpType op) args
 
 coreExprType (Lam (ValBinder binder) expr)
@@ -109,7 +110,7 @@ coreExprType (App expr val_arg)
     let
        fun_ty = coreExprType expr
     in
-    case (getFunTy_maybe fun_ty) of
+    case (getFunTyExpandingDicts_maybe False{-no peeking-} fun_ty) of
          Just (_, result_ty) -> result_ty
 #ifdef DEBUG
          Nothing -> pprPanic "coreExprType:\n"
@@ -136,7 +137,7 @@ applyTypeToArgs op_ty args      = foldl applyTypeToArg op_ty args
 
 applyTypeToArg op_ty (TyArg ty)     = applyTy op_ty ty
 applyTypeToArg op_ty (UsageArg _)   = panic "applyTypeToArg: UsageArg"
-applyTypeToArg op_ty val_or_lit_arg = case (getFunTy_maybe op_ty) of
+applyTypeToArg op_ty val_or_lit_arg = case (getFunTyExpandingDicts_maybe False{-no peeking-} op_ty) of
                                        Just (_, res_ty) -> res_ty
 \end{code}
 
diff --git a/ghc/compiler/coreSyn/NmbrCore.lhs b/ghc/compiler/coreSyn/NmbrCore.lhs
new file mode 100644 (file)
index 0000000..f00208d
--- /dev/null
@@ -0,0 +1,163 @@
+%
+% (c) The AQUA Project, Glasgow University, 1996
+%
+\section[NmbrCore]{Renumber Core for printing}
+
+\begin{code}
+#include "HsVersions.h"
+
+module NmbrCore where
+
+IMP_Ubiq(){-uitous-}
+
+import PprEnv          ( NmbrEnv )
+\end{code}
+
+\begin{code}
+nmbrCoreBindings :: [CoreBinding] -> NmbrEnv -> (NmbrEnv, [CoreBinding])
+
+nmbr_bind :: CoreBinding -> NmbrEnv -> (NmbrEnv, CoreBinding)
+nmbr_expr :: CoreExpr    -> NmbrEnv -> (NmbrEnv, CoreExpr)
+nmbr_arg  :: CoreArg     -> NmbrEnv -> (NmbrEnv, CoreArg)
+
+nmbrCoreBindings nenv [] = (nenv, [])
+nmbrCoreBindings nenv (b:bs)
+  = let
+       (new_nenv, new_b)  = nmbr_bind        nenv     b
+       (fin_nenv, new_bs) = nmbrCoreBindings new_nenv bs
+    in
+    (fin_nenv, new_b : new_bs)
+
+nmbr_bind nenv (NonRec binder rhs)
+    -- remember, binder cannot appear in rhs
+  = let
+       (_,     new_rhs)    = nmbr_expr nenv rhs
+       (nenv2, new_binder) = addId     nenv binder
+    in
+    (nenv2, NonRec new_binder new_rhs)
+
+nmbr_bind nenv (Rec binds)
+  = -- for letrec, we plug in new bindings BEFORE cloning rhss
+    let
+       (binders, rhss)      = unzip binds
+
+       (nenv2, new_binders) = mapAccumL addId nenv binders
+
+       (_, new_rhss)        = mapAndUnzip (nmbr_expr nenv2) rhss
+    in
+    returnUs (nenv2, Rec (zipEqual "nmbr_bind" new_binders new_rhss))
+\end{code}
+
+\begin{code}
+nmbr_arg nenv (VarArg v)
+  = let
+       (nenv2, new_v) = nmbrId nenv v
+    in
+    (nenv2, VarArg new_v)
+
+nmbr_arg nenv (TyArg ty)
+  = let
+       (nenv2, new_ty) = nmbrType nenv ty
+    in
+    (nenv2, TyArg new_ty)
+
+nmbr_arg nenv (UsageArg use)
+  = let
+       (nenv2, new_use) = nmbrUsage nenv use
+    in
+    (nenv2, UsageArg new_use)
+\end{code}
+
+\begin{code}
+nmbr_expr :: NmbrEnv
+           -> TypeEnv
+           -> CoreExpr
+           -> UniqSM CoreExpr
+
+nmbr_expr nenv tenv orig_expr@(Var var)
+  = returnUs (
+      case (lookupIdEnv nenv var) of
+       Nothing     -> --false:ASSERT(toplevelishId var) (SIGH)
+                      orig_expr
+       Just expr   -> expr
+    )
+
+nmbr_expr nenv tenv e@(Lit _) = returnUs e
+
+nmbr_expr nenv tenv (Con con as)
+  = mapUs  (nmbr_arg nenv tenv) as `thenUs`  \ new_as ->
+    mkCoCon con new_as
+
+nmbr_expr nenv tenv (Prim op as)
+  = mapUs  (nmbr_arg nenv tenv) as     `thenUs`  \ new_as ->
+    do_PrimOp op                       `thenUs`  \ new_op ->
+    mkCoPrim new_op new_as
+  where
+    do_PrimOp (CCallOp label is_asm may_gc arg_tys result_ty)
+      = let
+           new_arg_tys   = map (applyTypeEnvToTy tenv) arg_tys
+           new_result_ty = applyTypeEnvToTy tenv result_ty
+       in
+       returnUs (CCallOp label is_asm may_gc new_arg_tys new_result_ty)
+
+    do_PrimOp other_op = returnUs other_op
+
+nmbr_expr nenv tenv (Lam binder expr)
+  = dup_binder tenv binder `thenUs` \(new_binder, (old,new)) ->
+    let  new_nenv = addOneToIdEnv nenv old new  in
+    nmbr_expr new_nenv tenv expr  `thenUs` \ new_expr ->
+    returnUs (Lam new_binder new_expr)
+
+nmbr_expr nenv tenv (App expr arg)
+  = nmbr_expr nenv tenv expr   `thenUs` \ new_expr ->
+    nmbr_arg  nenv tenv arg   `thenUs` \ new_arg  ->
+    mkCoApps new_expr [new_arg] -- ToDo: more efficiently?
+
+nmbr_expr nenv tenv (Case expr alts)
+  = nmbr_expr nenv tenv expr       `thenUs` \ new_expr ->
+    do_alts nenv tenv alts         `thenUs` \ new_alts ->
+    returnUs (Case new_expr new_alts)
+  where
+    do_alts nenv tenv (AlgAlts alts deflt)
+      = mapUs (do_boxed_alt nenv tenv) alts `thenUs` \ new_alts ->
+       do_default nenv tenv deflt          `thenUs` \ new_deflt ->
+       returnUs (AlgAlts new_alts new_deflt)
+      where
+       do_boxed_alt nenv tenv (con, binders, expr)
+         = mapAndUnzipUs (dup_binder tenv) binders `thenUs` \ (new_binders, new_vmaps) ->
+           let  new_nenv = growIdEnvList nenv new_vmaps  in
+           nmbr_expr new_nenv tenv expr  `thenUs` \ new_expr ->
+           returnUs (con, new_binders, new_expr)
+
+
+    do_alts nenv tenv (PrimAlts alts deflt)
+      = mapUs (do_unboxed_alt nenv tenv) alts `thenUs` \ new_alts ->
+       do_default nenv tenv deflt            `thenUs` \ new_deflt ->
+       returnUs (PrimAlts new_alts new_deflt)
+      where
+       do_unboxed_alt nenv tenv (lit, expr)
+         = nmbr_expr nenv tenv expr    `thenUs` \ new_expr ->
+           returnUs (lit, new_expr)
+
+    do_default nenv tenv NoDefault = returnUs NoDefault
+
+    do_default nenv tenv (BindDefault binder expr)
+      =        dup_binder tenv binder          `thenUs` \ (new_binder, (old, new)) ->
+       let  new_nenv = addOneToIdEnv nenv old new  in
+       nmbr_expr new_nenv tenv expr    `thenUs` \ new_expr ->
+       returnUs (BindDefault new_binder new_expr)
+
+nmbr_expr nenv tenv (Let core_bind expr)
+  = nmbr_bind nenv tenv core_bind      `thenUs` \ (new_bind, new_nenv) ->
+    -- and do the body of the let
+    nmbr_expr new_nenv tenv expr       `thenUs` \ new_expr ->
+    returnUs (Let new_bind new_expr)
+
+nmbr_expr nenv tenv (SCC label expr)
+  = nmbr_expr nenv tenv expr           `thenUs` \ new_expr ->
+    returnUs (SCC label new_expr)
+
+nmbr_expr nenv tenv (Coerce c ty expr)
+  = nmbr_expr nenv tenv expr           `thenUs` \ new_expr ->
+    returnUs (Coerce c ty new_expr)
+\end{code}
index 4f2760e..cf1cf58 100644 (file)
@@ -424,7 +424,7 @@ dsExpr (RecordUpdOut record_expr dicts rbinds)
     dsRbinds rbinds            $ \ rbinds' ->
     let
        record_ty               = coreExprType record_expr'
-       (tycon, inst_tys, cons) = trace "DsExpr.getAppDataTyConExpandingDicts" $
+       (tycon, inst_tys, cons) = --trace "DsExpr.getAppDataTyConExpandingDicts" $
                                  getAppDataTyConExpandingDicts record_ty
        cons_to_upd             = filter has_all_fields cons
 
index 5800e5e..059db6a 100644 (file)
@@ -120,7 +120,8 @@ pprMatch sty is_case first_match
       = ([], pprGRHSsAndBinds sty is_case grhss_n_binds)
 
     ppr_match sty is_case (SimpleMatch expr)
-      = ([], ppr sty expr)
+      = ([], ppHang (ppStr (if is_case then "->" else "="))
+                4 (ppr sty expr))
 
 ----------------------------------------------------------
 
index a019c52..ef901f0 100644 (file)
@@ -25,7 +25,7 @@ import PrimOp         ( PrimOp(..) )
 import PrimRep         ( PrimRep(..) )
 import SMRep           ( SMRep(..), SMSpecRepKind, SMUpdateKind )
 import Stix            ( getUniqLabelNCG, sStLitLbl, stgHp, stgHpLim,
-                         StixTree(..), StixTreeList(..),
+                         StixTree(..), SYN_IE(StixTreeList),
                          CodeSegment, StixReg
                        )
 import StixMacro       ( macroCode, heapCheck )
index 37d6f6b..84fd4d9 100644 (file)
@@ -109,6 +109,9 @@ openAlphaTy = mkTyVarTy openAlphaTyVar
 
 errorTy  :: Type
 errorTy  = mkSigmaTy [openAlphaTyVar] [] (mkFunTys [mkListTy charTy] openAlphaTy)
+    -- Notice the openAlphaTyVar.  It says that "error" can be applied
+    -- to unboxed as well as boxed types.  This is OK because it never
+    -- returns, so the return type is irrelevant.
 \end{code}
 
 We want \tr{GHCbase.trace} to be wired in
index 413bdf7..1e62e9c 100644 (file)
@@ -1345,7 +1345,7 @@ primOpInfo ErrorIOPrimOp -- errorIO# :: PrimIO () -> State# RealWorld#
 primOpInfo (CCallOp _ _ _ arg_tys result_ty)
   = AlgResult SLIT("ccall#") [] arg_tys result_tycon tys_applied
   where
-    (result_tycon, tys_applied, _) = -- trace "PrimOp.getAppDataTyConExpandingDicts" $
+    (result_tycon, tys_applied, _) = --trace "PrimOp.getAppDataTyConExpandingDicts" $
                                     getAppDataTyConExpandingDicts result_ty
 
 #ifdef DEBUG
index 2d8bd92..54348b9 100644 (file)
@@ -14,7 +14,7 @@ IMP_Ubiq()
 IMPORT_1_3(List(partition))
 
 import HsSyn
-import RdrHsSyn                ( RdrNameHsModule(..), RdrNameImportDecl(..) )
+import RdrHsSyn                ( SYN_IE(RdrNameHsModule), SYN_IE(RdrNameImportDecl) )
 import RnHsSyn         ( RnName(..){-.. is for Ix hack only-}, SYN_IE(RenamedHsModule), isRnTyConOrClass, isRnWired )
 
 --ToDo:rm: all for debugging only
index f787950..28cd29a 100644 (file)
@@ -389,7 +389,10 @@ doImportDecls iface_cache g_info us src_imps
 
            rec_imp_fn :: Name -> (ExportFlag, [SrcLoc])
            rec_imp_fn n = case lookupUFM rec_imp_fm n of
-                            Nothing            -> panic "RnNames:rec_imp_fn"
+                            Nothing            -> (NotExported,[mkBuiltinSrcLoc])
+                                                  -- panic "RnNames:rec_imp_fn"
+                                                  -- but the panic can show up
+                                                  -- in error messages
                             Just (flag, locns) -> (flag, bagToList locns)
 
            i_info = (g_info, emptyFM, emptyFM, rec_imp_fn)
index 43aa0bd..9b44d2e 100644 (file)
@@ -16,7 +16,7 @@ module BinderInfo (
 
        inlineUnconditionally, okToInline,
 
-       addBinderInfo, orBinderInfo, 
+       addBinderInfo, orBinderInfo, andBinderInfo,
 
        argOccurrence, funOccurrence, dangerousArgOcc, noBinderInfo,
        markMany, markDangerousToDup, markInsideSCC,
@@ -117,20 +117,24 @@ okToInline BottomForm occ_info small_enough
                -- This used to be checked for, but I can't
                -- see why so I've left it out.
 
--- Non-WHNFs can be inlined if they occur once, or are small
-okToInline OtherForm (OneOcc _ _ _ n_alts _) small_enough | n_alts <= 1 = True
-okToInline OtherForm any_occ                small_enough               = small_enough
-
--- A WHNF can be inlined if it doesn't occur inside a lambda,
+-- A WHNF can be inlined if it occurs once, or is small
+okToInline form occ_info small_enough
+ | is_whnf_form form
+ = small_enough || one_occ
+ where
+   one_occ = case occ_info of
+               OneOcc _ _ _ n_alts _ -> n_alts <= 1
+               other                 -> False
+       
+   is_whnf_form VarForm   = True
+   is_whnf_form ValueForm = True
+   is_whnf_form other     = False
+    
+-- A non-WHNF can be inlined if it doesn't occur inside a lambda,
 -- and occurs exactly once or 
 --     occurs once in each branch of a case and is small
-okToInline form (OneOcc _ NoDupDanger _ n_alts _) small_enough 
-  = is_whnf_form form && 
-    (n_alts <= 1 || small_enough)
-  where
-    is_whnf_form VarForm   = True
-    is_whnf_form ValueForm = True
-    is_whnf_form other     = False
+okToInline OtherForm (OneOcc _ NoDupDanger _ n_alts _) small_enough 
+  = n_alts <= 1 || small_enough
 
 okToInline form any_occ small_enough = False
 \end{code}
@@ -194,49 +198,55 @@ addBinderInfo info1 DeadCode = info1
 addBinderInfo info1 info2
        = ManyOcc (min (getBinderInfoArity info1) (getBinderInfoArity info2))
 
--- (orBinderInfo orig new) is used in two situations:
--- First, it combines occurrence info from branches of a case
---
--- Second, when a variable whose occurrence
---   info is currently "orig" is bound to a variable whose occurrence info is "new"
---     eg  (\new -> e) orig
---   What we want to do is to *worsen* orig's info to take account of new's
+-- (orBinderInfo orig new) is used when combining occurrence 
+-- info from branches of a case
 
 orBinderInfo DeadCode info2 = info2
 orBinderInfo info1 DeadCode = info1
 orBinderInfo (OneOcc posn1 dup1 scc1 n_alts1 ar_1)
-                     (OneOcc posn2 dup2 scc2 n_alts2 ar_2)
+            (OneOcc posn2 dup2 scc2 n_alts2 ar_2)
   = OneOcc (combine_posns posn1 posn2)
           (combine_dups  dup1  dup2)
           (combine_sccs  scc1  scc2)
           (n_alts1 + n_alts2)
           (min ar_1 ar_2)
-  where
-    combine_dups DupDanger _ = DupDanger       -- Too paranoid?? ToDo
-    combine_dups _ DupDanger = DupDanger
-    combine_dups _ _        = NoDupDanger
-
-    combine_sccs InsideSCC _ = InsideSCC       -- Too paranoid?? ToDo
-    combine_sccs _ InsideSCC = InsideSCC
-    combine_sccs _ _        = NotInsideSCC
-
 orBinderInfo info1 info2
        = ManyOcc (min (getBinderInfoArity info1) (getBinderInfoArity info2))
 
+-- (andBinderInfo orig new) is used in two situations:
+-- First, when a variable whose occurrence info
+--   is currently "orig" is bound to a variable whose occurrence info is "new"
+--     eg  (\new -> e) orig
+--   What we want to do is to *worsen* orig's info to take account of new's
+--
+-- second, when completing a let-binding
+--     let new = ...orig...
+-- we compute the way orig occurs in (...orig...), and then use orBinderInfo
+-- to worsen this info by the way new occurs in the let body; then we use
+-- that to worsen orig's currently recorded occurrence info.
+
+andBinderInfo DeadCode info2 = DeadCode
+andBinderInfo info1 DeadCode = DeadCode
+andBinderInfo (OneOcc posn1 dup1 scc1 n_alts1 ar_1)
+             (OneOcc posn2 dup2 scc2 n_alts2 ar_2)
+  = OneOcc (combine_posns posn1 posn2)
+          (combine_dups  dup1  dup2)
+          (combine_sccs  scc1  scc2)
+          (n_alts1 + n_alts2)
+          ar_1                                 -- Min arity just from orig
+andBinderInfo info1 info2 = ManyOcc (getBinderInfoArity info1)
+
+
 combine_posns FunOcc FunOcc = FunOcc -- see comment at FunOrArg defn
 combine_posns _         _  = ArgOcc
 
-{-
-multiplyBinderInfo orig@(ManyOcc _) new
-  = ManyOcc (min (getBinderInfoArity orig) (getBinderInfoArity new))
-
-multiplyBinderInfo orig new@(ManyOcc _)
-  = ManyOcc (min (getBinderInfoArity orig) (getBinderInfoArity new))
+combine_dups DupDanger _ = DupDanger   -- Too paranoid?? ToDo
+combine_dups _ DupDanger = DupDanger
+combine_dups _ _            = NoDupDanger
 
-multiplyBinderInfo (OneOcc posn1 dup1 scc1 n_alts1 ar_1)
-                  (OneOcc posn2 dup2 scc2 n_alts2 ar_2)  
-  = OneOcc (combine_posns posn1 posn2) ???
--}
+combine_sccs InsideSCC _ = InsideSCC   -- Too paranoid?? ToDo
+combine_sccs _ InsideSCC = InsideSCC
+combine_sccs _ _            = NotInsideSCC
 
 setBinderInfoArityToZero :: BinderInfo -> BinderInfo
 setBinderInfoArityToZero DeadCode    = DeadCode
index a3e559d..19ec58c 100644 (file)
@@ -149,9 +149,7 @@ try_split_bind id expr =
 
        worker_ty = mkForallTy (templ  ++ [alphaTyVar])
                        (foldr mkFunTy n_ty_templ (arg_tys++[c_ty_templ,n_ty_templ]))
-       wrapper_id  = id `replaceIdInfo`
-                             (getIdInfo id     `addInfo_UF`
-                              iWantToBeINLINEd UnfoldAlways)
+       wrapper_id  = addInlinePragma id
        worker_id  = mkWorkerId worker_new_uq id worker_ty
                                noIdInfo
                -- TODO : CHECK if mkWorkerId is thr
index 79f659e..77e43ae 100644 (file)
@@ -16,6 +16,7 @@ module MagicUFs (
 IMP_Ubiq(){-uitous-}
 IMPORT_DELOOPER(IdLoop)                -- paranoia checking
 
+import Id              ( addInlinePragma )
 import CoreSyn
 import SimplEnv                ( SimplEnv )
 import SimplMonad      ( SYN_IE(SmplM), SimplCount )
@@ -446,11 +447,11 @@ foldl_fun env (TypeArg ty1:TypeArg ty2:ValArg arg_k:ValArg arg_z:ValArg arg_list
                                      t] ->
 
         let
-         c     = addIdUnfolding pre_c (iWantToBeINLINEd UnfoldAlways)
+         c     = addInlinePragma pre_c
          c_rhs = Lam b (Lam g' (Lam a
                  (Let (NonRec t (App (App (argToExpr arg_k) (VarArg a)) (VarArg b)))
                         (App (Var g') (VarArg t)))))
-         n     = addIdUnfolding pre_n (iWantToBeINLINEd UnfoldAlways)
+         n     = addInlinePragma pre_n
          n_rhs = Lam a' (Var a')
         in
         returnSmpl (Let (NonRec c c_rhs) $
@@ -489,13 +490,13 @@ foldl_fun env (TypeArg ty1:TypeArg ty2:ValArg arg_k:ValArg arg_z:ValArg arg_list
                                      t] ->
 
         let
-         c     = addIdUnfolding pre_c (iWantToBeINLINEd UnfoldAlways)
+         c     = addInlinePragma pre_c
          c_rhs = Lam b (Lam g_ (Lam a
                  (Let (NonRec t (App (App (argToExpr arg_k) (VarArg a)) (VarArg b)))
                         (App (Var g_) (VarArg t)))))
-         n     = addIdUnfolding pre_n (iWantToBeINLINEd UnfoldAlways)
+         n     = addInlinePragma pre_n
          n_rhs = Lam a' (Var a')
-         r     = addIdUnfolding pre_r (iWantToBeINLINEd UnfoldAlways)
+         r     = addInlinePragma pre_r
          r_rhs = mkGenApp (Var foldrId)
                                        [TypeArg ty2,TypeArg (mkFunTys [ty1] ty1),
                                         ValArg (VarArg c),
index 786f723..4318ec5 100644 (file)
@@ -511,7 +511,8 @@ simplAlts env scrut (AlgAlts alts deflt) rhs_c
            new_env = case scrut of
                       Var v -> extendEnvGivenNewRhs env1 v (Con con args)
                             where
-                               (_, ty_args, _) = getAppDataTyConExpandingDicts (idType v)
+                               (_, ty_args, _) = --trace "SimplCase.getAppData..." $
+                                                 getAppDataTyConExpandingDicts (idType v)
                                args = map TyArg ty_args ++ map VarArg con_args'
 
                       other -> env1
@@ -775,7 +776,8 @@ mkCoCase env scrut (AlgAlts outer_alts
         v | scrut_is_var = Var scrut_var
           | otherwise    = Con con (map TyArg arg_tys ++ map VarArg args)
 
-    arg_tys = case (getAppDataTyConExpandingDicts (idType deflt_var)) of
+    arg_tys = --trace "SimplCase:getAppData...:2" $
+             case (getAppDataTyConExpandingDicts (idType deflt_var)) of
                (_, arg_tys, _) -> arg_tys
 
 mkCoCase env scrut (PrimAlts
index f984764..b2be6a1 100644 (file)
@@ -47,7 +47,7 @@ IMP_Ubiq(){-uitous-}
 
 IMPORT_DELOOPER(SmplLoop)              -- breaks the MagicUFs / SimplEnv loop
 
-import BinderInfo      ( orBinderInfo, noBinderInfo,
+import BinderInfo      ( orBinderInfo, andBinderInfo, noBinderInfo,
                          BinderInfo(..){-instances, too-}, FunOrArg, DuplicationDanger, InsideSCC
                        )
 import CgCompInfo      ( uNFOLDING_CREATION_THRESHOLD )
@@ -76,7 +76,7 @@ import PprCore                -- various instances
 import PprStyle                ( PprStyle(..) )
 import PprType         ( GenType, GenTyVar )
 import Pretty
-import Type            ( eqTy, getAppDataTyConExpandingDicts, applyTypeEnvToTy )
+import Type            ( eqTy, applyTypeEnvToTy )
 import TyVar           ( nullTyVarEnv, addOneToTyVarEnv, growTyVarEnvList,
                          SYN_IE(TyVarEnv), GenTyVar{-instance Eq-}
                        )
@@ -424,9 +424,14 @@ extendEnvGivenBinding env@(SimplEnv chkr encl_cc ty_env in_id_env out_id_env con
        -- If the out_id is already in the OutIdEnv, then just replace the
        -- unfolding, leaving occurrence info alone (this must then
        -- be a call via extendEnvGivenNewRhs).
-    out_id_env_with_unfolding = foldl modifyOccInfo env1 (ufmToList fv_occ_info)
+    out_id_env_with_unfolding = foldl modifyOccInfo env1 full_fv_occ_info
+               -- full_fv_occ_info combines the occurrence of the current binder
+               -- with the occurrences of its RHS's free variables.
+    full_fv_occ_info         = [ (uniq, fv_occ `andBinderInfo` occ_info) 
+                               | (uniq,fv_occ) <- ufmToList fv_occ_info
+                               ]
     env1                     = addToUFM_C modifyOutEnvItem out_id_env out_id 
-                                          (out_id, occ_info, OutUnfolding unf_cc unfolding)
+                                          (out_id, occ_info, rhs_info)
 
        -- Occurrence-analyse the RHS
        -- The "interesting" free variables we want occurrence info for are those
@@ -435,16 +440,10 @@ extendEnvGivenBinding env@(SimplEnv chkr encl_cc ty_env in_id_env out_id_env con
     interesting_fvs        = mkIdSet [id | (id,OneOcc _ _ _ _ _,_) <- eltsUFM out_id_env]
 
        -- Compute unfolding details
-    unfolding    = SimpleUnfolding form_summary guidance template
+    rhs_info     = OutUnfolding unf_cc (SimpleUnfolding form_summary guidance template)
     form_summary = mkFormSummary rhs
 
-    guidance | not (switchIsSet env IgnoreINLINEPragma) && idWantsToBeINLINEd out_id
-            = UnfoldAlways
-
-             | otherwise
-            = calcUnfoldingGuidance True{-sccs OK-} bOMB_OUT_SIZE rhs
-
-    bOMB_OUT_SIZE = getSimplIntSwitch chkr SimplUnfoldingCreationThreshold
+    guidance = mkSimplUnfoldingGuidance chkr out_id rhs
 
        -- Compute cost centre for thing
     unf_cc  | noCostCentreAttached expr_cc = encl_cc
@@ -452,29 +451,63 @@ extendEnvGivenBinding env@(SimplEnv chkr encl_cc ty_env in_id_env out_id_env con
            where
              expr_cc =  coreExprCc rhs
 
+{-     We need to be pretty careful when extending 
+       the environment with RHS info in recursive groups.
+
+Here's a nasty example:
+
+       letrec  r = f x
+               t = r
+               x = ...t...
+       in
+       ...t...
+
+Here, r occurs exactly once, so we may reasonably inline r in t's RHS.
+But the pre-simplified t's rhs is an atom, r, so we may also decide to
+inline t everywhere.  But if we do *both* these reasonable things we get
+
+       letrec  r = f x
+               t = f x
+               x = ...r...
+       in
+       ...t...
+
+(The t in the body doesn't get inlined because by the time the recursive
+group is done we see that t's RHS isn't an atom.)
+
+Bad news!  (f x) is duplicated!  Our solution is to only be prepared to
+inline RHSs in their own RHSs if they are *values* (lambda or constructor).
+
+This means that silly x=y  bindings in recursive group will never go away. Sigh.  ToDo!
+-}
+
 extendEnvForRecBinding env@(SimplEnv chkr encl_cc ty_env in_id_env out_id_env con_apps)
                       (out_id, ((_,occ_info), old_rhs))
   = SimplEnv chkr encl_cc ty_env in_id_env new_out_id_env con_apps
   where
-    new_out_id_env = case guidance of
-                       UnfoldNever -> out_id_env               -- No new stuff to put in
-                       other       -> out_id_env_with_unfolding
+    new_out_id_env = case (form_summary, guidance) of
+                       (ValueForm, UnfoldNever) -> out_id_env          -- No new stuff to put in
+                       (ValueForm, _)           -> out_id_env_with_unfolding
+                       other                    -> out_id_env          -- Not a value
 
        -- If there is an unfolding, we add rhs-info for out_id,
        -- No need to modify occ info because RHS is pre-simplification
     out_id_env_with_unfolding =        addOneToIdEnv out_id_env out_id 
-                               (out_id, occ_info, InUnfolding env unfolding)
+                               (out_id, occ_info, rhs_info)
 
        -- Compute unfolding details
-    unfolding    = SimpleUnfolding form_summary guidance old_rhs
+    rhs_info     = InUnfolding env (SimpleUnfolding form_summary guidance old_rhs)
     form_summary = mkFormSummary old_rhs
+    guidance     = mkSimplUnfoldingGuidance chkr out_id (unTagBinders old_rhs)
 
-    guidance | not (switchIsSet env IgnoreINLINEPragma) && idWantsToBeINLINEd out_id
-            = UnfoldAlways
 
-             | otherwise
-            = calcUnfoldingGuidance True{-sccs OK-} bOMB_OUT_SIZE (unTagBinders old_rhs)
+mkSimplUnfoldingGuidance chkr out_id rhs
+  | not (switchIsOn chkr IgnoreINLINEPragma) && idWantsToBeINLINEd out_id
+  = UnfoldAlways
 
+  | otherwise
+  = calcUnfoldingGuidance True{-sccs OK-} bOMB_OUT_SIZE rhs
+  where
     bOMB_OUT_SIZE = getSimplIntSwitch chkr SimplUnfoldingCreationThreshold
 
 extendEnvGivenRhsInfo :: SimplEnv -> OutId -> BinderInfo -> RhsInfo -> SimplEnv
index 4e4ef55..2a6499e 100644 (file)
@@ -37,7 +37,6 @@ import Pretty         ( ppBesides, ppStr )
 import SimplEnv
 import SimplMonad
 import TyCon           ( tyConFamilySize )
-import Type            ( isPrimType, getAppDataTyConExpandingDicts, maybeAppDataTyConExpandingDicts )
 import Util            ( pprTrace, assertPanic, panic )
 import Maybes          ( maybeToBool )
 \end{code}
index f1ac5d8..2141e07 100644 (file)
@@ -22,13 +22,14 @@ import CoreUtils    ( coreExprType, nonErrorRHSs, maybeErrorApp,
                          unTagBinders, squashableDictishCcExpr
                        )
 import Id              ( idType, idWantsToBeINLINEd,
+                         externallyVisibleId,
                          getIdDemandInfo, addIdDemandInfo,
                          GenId{-instance NamedThing-}
                        )
 import IdInfo          ( willBeDemanded, DemandInfo )
 import Literal         ( isNoRepLit )
 import Maybes          ( maybeToBool )
-import Name            ( isLocallyDefined )
+--import Name          ( isExported )
 import PprStyle                ( PprStyle(..) )
 import PprType         ( GenType{-instance Outputable-} )
 import Pretty          ( ppAbove )
@@ -193,8 +194,8 @@ simplTopBinds env [] = returnSmpl []
 simplTopBinds env (NonRec binder@(in_id,occ_info) rhs : binds)
   =    -- No cloning necessary at top level
        -- Process the binding
-    simplRhsExpr env binder rhs        `thenSmpl` \ rhs' ->
-    completeNonRec True env binder rhs'        `thenSmpl` \ (new_env, binds1') ->
+    simplRhsExpr env binder rhs                `thenSmpl` \ rhs' ->
+    completeNonRec env binder in_id rhs'       `thenSmpl` \ (new_env, binds1') ->
 
        -- Process the other bindings
     simplTopBinds new_env binds        `thenSmpl` \ binds2' ->
@@ -774,7 +775,8 @@ simplBind env (NonRec binder@(id,occ_info) rhs) body_c body_ty
  
     complete_bind env rhs
       = simplRhsExpr env binder rhs            `thenSmpl` \ rhs' ->
-       completeNonRec False env binder rhs'    `thenSmpl` \ (new_env, binds) ->
+       cloneId env binder                      `thenSmpl` \ new_id ->
+       completeNonRec env binder new_id rhs'   `thenSmpl` \ (new_env, binds) ->
         body_c new_env                         `thenSmpl` \ body' ->
         returnSmpl (mkCoLetsAny binds body')
 
@@ -1060,63 +1062,64 @@ x.  That's just what completeLetBinding does.
 
 
 \begin{code}
-       -- Sigh: rather disgusting case for coercions. We want to 
-       -- ensure that all let-bound Coerces have atomic bodies, so
-       -- they can freely be inlined.
-completeNonRec top_level env binder@(_,occ_info) (Coerce coercion ty rhs)
-  = (case rhs of
-       Var v -> returnSmpl (env, [], rhs)
-       Lit l -> returnSmpl (env, [], rhs)
-       other -> newId (coreExprType rhs)                       `thenSmpl` \ inner_id ->
-                completeNonRec top_level env 
-                       (inner_id, dangerousArgOcc) rhs         `thenSmpl` \ (env1, extra_bind) ->
-               -- Dangerous occ because, like constructor args,
-               -- it can be duplicated easily
-               let
-               atomic_rhs = case lookupId env1 inner_id of
-                               LitArg l -> Lit l
-                               VarArg v -> Var v
-               in
-               returnSmpl (env1, extra_bind, atomic_rhs)
-     )                         `thenSmpl` \ (env1, extra_bind, atomic_rhs) ->
-       -- Tiresome to do all this, but we must treat the lit/var cases specially
-       -- or we get a tick for atomic rhs when effectively it's a no-op.
-
-     cloneId env1 binder                                 `thenSmpl` \ new_id ->
-     let 
-       new_rhs = Coerce coercion ty atomic_rhs
-       env2    = extendIdEnvWithClone env1 binder new_id
-       new_env = extendEnvGivenBinding env2 occ_info new_id new_rhs
-     in
-     returnSmpl (new_env, extra_bind ++ [NonRec new_id new_rhs])
-       
-completeNonRec top_level env binder@(id,_) new_rhs
-  -- See if RHS is an atom, or a reusable constructor
-  | maybeToBool maybe_atomic_rhs
-  = let
-       new_env = extendIdEnvWithAtom env binder rhs_atom
-       result_binds | top_level = [NonRec id new_rhs]  -- Don't discard top-level bindings
-                                                       -- (they'll be dropped later if not
-                                                       -- exported and dead)
-                    | otherwise = []
-    in
-    tick atom_tick_type                        `thenSmpl_`
-    returnSmpl (new_env, result_binds)
-  where
-    maybe_atomic_rhs               = exprToAtom env new_rhs
-    Just (rhs_atom, atom_tick_type) = maybe_atomic_rhs
-
-completeNonRec top_level env binder@(old_id,occ_info) new_rhs
-  = (if top_level then
-       returnSmpl old_id               -- Only clone local binders
-     else
-       cloneId env binder
-    )                          `thenSmpl` \ new_id ->
+       -- We want to ensure that all let-bound Coerces have 
+       -- atomic bodies, so they can freely be inlined.
+completeNonRec env binder new_id (Coerce coercion ty rhs)
+  | not (is_atomic rhs)
+  = newId (coreExprType rhs)                           `thenSmpl` \ inner_id ->
+    completeNonRec env 
+                  (inner_id, dangerousArgOcc) inner_id rhs `thenSmpl` \ (env1, binds1) ->
+       -- Dangerous occ because, like constructor args,
+       -- it can be duplicated easily
     let
-        env1    = extendIdEnvWithClone env binder new_id
-       new_env = extendEnvGivenBinding env1 occ_info new_id new_rhs
+       atomic_rhs = case lookupId env1 inner_id of
+                       LitArg l -> Lit l
+                       VarArg v -> Var v
     in
-    returnSmpl (new_env, [NonRec new_id new_rhs])
+    completeNonRec env1 binder new_id
+                  (Coerce coercion ty atomic_rhs)      `thenSmpl` \ (env2, binds2) ->
+
+    returnSmpl (env2, binds1 ++ binds2)
+  where
+    is_atomic (Var v) = True
+    is_atomic (Lit l) = not (isNoRepLit l)
+    is_atomic other   = False
+       
+       -- Atomic right-hand sides.
+       -- We used to have a "tick AtomicRhs" in here, but it causes more trouble
+       -- than it's worth.  For a top-level binding a = b, where a is exported,
+       -- we can't drop the binding, so we get repeated AtomicRhs ticks
+completeNonRec env binder new_id rhs@(Var v)
+  = returnSmpl (extendIdEnvWithAtom env binder (VarArg v), [NonRec new_id rhs])
+
+completeNonRec env binder new_id rhs@(Lit lit)
+  | not (isNoRepLit lit)
+  = returnSmpl (extendIdEnvWithAtom env binder (LitArg lit), [NonRec new_id rhs])
+
+       -- Right hand sides that are constructors
+       --      let v = C args
+       --      in
+       --- ...(let w = C same-args in ...)...
+       -- Then use v instead of w.      This may save
+       -- re-constructing an existing constructor.
+completeNonRec env binder new_id rhs@(Con con con_args)
+  | switchIsSet env SimplReuseCon && 
+    maybeToBool maybe_existing_con &&
+    not (externallyVisibleId new_id)           -- Don't bother for exported things
+                                               -- because we won't be able to drop
+                                               -- its binding.
+  = tick ConReused             `thenSmpl_`
+    returnSmpl (extendIdEnvWithAtom env binder (VarArg it), [NonRec new_id rhs])
+  where
+    maybe_existing_con = lookForConstructor env con con_args
+    Just it           = maybe_existing_con
+
+       -- Default case
+completeNonRec env binder@(id,occ_info) new_id rhs
+ = returnSmpl (new_env, [NonRec new_id rhs])
+ where
+   env1    = extendIdEnvWithClone env binder new_id
+   new_env = extendEnvGivenBinding env1 occ_info new_id rhs
 \end{code}
 
 %************************************************************************
@@ -1133,31 +1136,6 @@ simplArg env (TyArg  ty)  = TyArg  (simplTy env ty)
 simplArg env (VarArg id)  = lookupId env id
 \end{code}
 
-
-\begin{code}
-exprToAtom env (Var var) 
-  = Just (VarArg var, AtomicRhs)
-
-exprToAtom env (Lit lit) 
-  | not (isNoRepLit lit)
-  = Just (LitArg lit, AtomicRhs)
-
-exprToAtom env (Con con con_args)
-  | switchIsSet env SimplReuseCon
-  -- Look out for
-  --   let v = C args
-  --   in
-  --- ...(let w = C same-args in ...)...
-  -- Then use v instead of w.   This may save
-  -- re-constructing an existing constructor.
-  = case (lookForConstructor env con con_args) of
-                 Nothing  -> Nothing
-                 Just var -> Just (VarArg var, ConReused)
-
-exprToAtom env other
-  = Nothing
-\end{code}
-
 %************************************************************************
 %*                                                                     *
 \subsection[Simplify-quickies]{Some local help functions}
index 424bcad..8164e0c 100644 (file)
@@ -1531,7 +1531,8 @@ specAlts (AlgAlts alts deflt) scrutinee_ty args
     -- We use ty_args of scrutinee type to identify specialisation of
     -- alternatives:
 
-    (_, ty_args, _) = getAppDataTyConExpandingDicts scrutinee_ty
+    (_, ty_args, _) = --trace "Specialise.specAlts:getAppData..." $
+                     getAppDataTyConExpandingDicts scrutinee_ty
 
     specAlgAlt ty_args (con,binders,rhs)
       = specLambdaOrCaseBody binders rhs args  `thenSM` \ (binders, rhs, rhs_uds) ->
index 8a8ff80..251b7b2 100644 (file)
@@ -11,12 +11,13 @@ module WorkWrap ( workersAndWrappers ) where
 IMP_Ubiq(){-uitous-}
 
 import CoreSyn
-import CoreUnfold      ( Unfolding(..), UnfoldingGuidance(..) )
-IMPORT_DELOOPER(IdLoop)         -- ToDo:rm when iWantToBeINLINEd goes
+import CoreUnfold      ( Unfolding(..), UnfoldingGuidance(..), SimpleUnfolding )
+import MagicUFs                ( MagicUnfoldingFun )
 
 import CoreUtils       ( coreExprType )
 import Id              ( idWantsToBeINLINEd, getIdStrictness, mkWorkerId,
-                         getIdInfo, replaceIdInfo, GenId
+                         addIdStrictness, addInlinePragma,
+                         GenId
                        )
 import IdInfo          ( noIdInfo, addInfo_UF, indicatesWorker,
                          mkStrictnessInfo, StrictnessInfo(..)
@@ -24,9 +25,6 @@ import IdInfo         ( noIdInfo, addInfo_UF, indicatesWorker,
 import SaLib
 import UniqSupply      ( returnUs, thenUs, mapUs, getUnique, SYN_IE(UniqSM) )
 import WwLib
-
-iWantToBeINLINEd :: UnfoldingGuidance -> Unfolding
-iWantToBeINLINEd x = NoUnfolding --ToDo:panic "WorkWrap.iWantToBeINLINEd (ToDo)"
 \end{code}
 
 We take Core bindings whose binders have their strictness attached (by
@@ -240,12 +238,9 @@ tryWW fn_id rhs
                    -- worker Id:
                    mkStrictnessInfo args_info (Just worker_id)
 
-               wrapper_id  = fn_id `replaceIdInfo`
-                             (getIdInfo fn_id          `addInfo`
-                              revised_strictness_info  `addInfo_UF`
-                              iWantToBeINLINEd UnfoldAlways)
-               -- NB! the "iWantToBeINLINEd" part adds an INLINE pragma to
-               -- the wrapper, which is of course what we want.
+               wrapper_id  = addInlinePragma (fn_id `addIdStrictness`
+                                              revised_strictness_info)
+               -- NB the "addInlinePragma" part; we want to inline wrappers everywhere
            in
            returnUs [ (worker_id,  worker_rhs),   -- worker comes first
                       (wrapper_id, wrapper_rhs) ] -- because wrapper mentions it
index 8015b6d..9c59b43 100644 (file)
@@ -377,7 +377,8 @@ tcExpr (RecordUpd record_expr rbinds)
        -- Check that the field names are plausible
     zonkTcType record_ty               `thenNF_Tc` \ record_ty' ->
     let
-       (tycon, inst_tys, data_cons) = trace "TcExpr.getAppDataTyCon" $ getAppDataTyCon record_ty'
+       (tycon, inst_tys, data_cons) = --trace "TcExpr.getAppDataTyCon" $
+                                      getAppDataTyCon record_ty'
        -- The record binds are non-empty (syntax); so at least one field
        -- label will have been unified with record_ty by tcRecordBinds;
        -- field labels must be of data type; hencd the getAppDataTyCon must succeed.
index df32170..5194f9e 100644 (file)
@@ -61,7 +61,7 @@ import CmdLineOpts    ( opt_GlasgowExts, opt_CompilingGhcInternals,
 import Class           ( GenClass, GenClassOp, 
                          isCcallishClass, classBigSig,
                          classOps, classOpLocalType,
-                         classOpTagByString
+                         classOpTagByString_maybe
                          )
 import Id              ( GenId, idType, isDefaultMethodId_maybe )
 import ListSetOps      ( minusList )
@@ -602,10 +602,13 @@ processInstBinds1 clas avail_insts method_ids mbind
 
     -- Make a method id for the method
     let
-       tag       = classOpTagByString clas occ
-       method_id = method_ids !! (tag-1)
-       method_ty = tcIdType method_id
+       maybe_tag  = classOpTagByString_maybe clas occ
+       (Just tag) = maybe_tag
+       method_id  = method_ids !! (tag-1)
+       method_ty  = tcIdType method_id
     in
+    -- check that the method mentioned is actually in the class:
+    checkMaybeTc maybe_tag (instMethodNotInClassErr occ clas) `thenTc_`
 
     tcInstTcType method_ty             `thenNF_Tc` \ (method_tyvars, method_rho) ->
     let
@@ -921,6 +924,10 @@ omitDefaultMethodWarn clas_op clas_name inst_ty sty
           ppr sty clas_op, ppStr "in instance",
           ppPStr clas_name, pprParendGenType sty inst_ty]
 
+instMethodNotInClassErr occ clas sty
+  = ppHang (ppStr "Instance mentions a method not in the class")
+        4 (ppBesides [ppStr "class `", ppr sty clas, ppStr "' method `",
+                      ppPStr occ, ppStr "'"])
 
 patMonoBindsCtxt pbind sty
   = ppHang (ppStr "In a pattern binding:")
index 38b8f2f..9af279f 100644 (file)
@@ -41,7 +41,8 @@ import Type           ( mkSigmaTy, mkForAllTys, mkDictTy, mkTyVarTys,
                          splitForAllTy, instantiateTy, matchTy, SYN_IE(ThetaType) )
 import TyVar           ( GenTyVar )
 import Unique          ( Unique )
-import Util            ( equivClasses, zipWithEqual, panic )
+import Util            ( equivClasses, zipWithEqual, panic{-, pprTrace-} )
+--import PprStyle
 
 import IdInfo          ( noIdInfo )
 --import TcPragmas     ( tcDictFunPragmas, tcGenPragmas )
@@ -119,6 +120,8 @@ mkInstanceRelatedIds from_here src_loc inst_mod inst_pragmas
        returnTc (mkDictFunId dfun_uniq clas inst_ty dfun_ty from_here src_loc inst_mod dfun_id_info)
     ) `thenTc` \ dfun_id ->
 
+--  pprTrace "DFUN: " (ppr PprDebug dfun_id) $
+
        -- MAKE THE CONSTANT-METHOD IDS
        -- if there are no type variables involved
     (if (null inst_decl_theta)
index 077b079..113c82e 100644 (file)
@@ -128,7 +128,11 @@ tcModule rn_env
        -- pragmas, which is done lazily [ie failure just drops the pragma
        -- without having any global-failure effect].
 
+    -- trace "tc1" $
+
     fixTc (\ ~(_, _, _, _, _, _, sig_ids) ->
+
+       -- trace "tc2" $
        tcExtendGlobalValEnv sig_ids (
 
        -- The knot for instance information.  This isn't used at all
@@ -140,6 +144,7 @@ tcModule rn_env
            tcTyAndClassDecls1 rec_inst_mapper ty_decls_bag cls_decls_bag
                                        `thenTc` \ env ->
 
+           --trace "tc3" $
                -- Typecheck the instance decls, includes deriving
            tcSetEnv env (
            --trace "tcInstDecls:"      $
@@ -147,11 +152,14 @@ tcModule rn_env
                         mod_name rn_env fixities 
            )                           `thenTc` \ (inst_info, deriv_binds, ddump_deriv) ->
 
+           --trace "tc4" $
            buildInstanceEnvs inst_info `thenTc` \ inst_mapper ->
 
            returnTc (inst_mapper, env, inst_info, deriv_binds, ddump_deriv)
 
        ) `thenTc` \ (_, env, inst_info, deriv_binds, ddump_deriv) ->
+
+       --trace "tc5" $
        tcSetEnv env (
 
            -- Default declarations
@@ -181,11 +189,13 @@ tcModule rn_env
            --   we silently discard the pragma
        tcInterfaceSigs sigs            `thenTc` \ sig_ids ->
        tcGetEnv                        `thenNF_Tc` \ env ->
+       --trace "tc6" $
 
        returnTc (env, inst_info, data_binds, deriv_binds, ddump_deriv, defaulting_tys, sig_ids)
 
     )))) `thenTc` \ (env, inst_info, data_binds, deriv_binds, ddump_deriv, defaulting_tys, _) ->
 
+    --trace "tc7" $
     tcSetEnv env (                             -- to the end...
     tcSetDefaultTys defaulting_tys (           -- ditto
 
@@ -197,6 +207,7 @@ tcModule rn_env
        (val_decls `ThenBinds` deriv_binds)
        (       -- Second pass over instance declarations,
                -- to compile the bindings themselves.
+           --trace "tc8" $
            tcInstDecls2  inst_info     `thenNF_Tc` \ (lie_instdecls, inst_binds) ->
            tcClassDecls2 cls_decls_bag `thenNF_Tc` \ (lie_clasdecls, cls_binds) ->
            tcGetEnv                    `thenNF_Tc` \ env ->
@@ -212,6 +223,7 @@ tcModule rn_env
        -- restriction, and no subsequent decl instantiates its
        -- type.  (Usually, ambiguous type variables are resolved
        -- during the generalisation step.)
+    --trace "tc9" $
     tcSimplifyTop lie_alldecls                 `thenTc` \ const_insts ->
 
        -- Backsubstitution.  Monomorphic top-level decls may have
index adfbe51..e7630b0 100644 (file)
@@ -14,7 +14,7 @@ module Class (
        classSuperDictSelId, classOpId, classDefaultMethodId,
        classSig, classBigSig, classInstEnv,
        isSuperClassOf,
-       classOpTagByString,
+       classOpTagByString, classOpTagByString_maybe,
 
        derivableClassKeys, needsDataDeclCtxtClassKeys,
        cCallishClassKeys, isNoDictClass,
@@ -331,17 +331,23 @@ classOpLocalType (ClassOp _ _ ty) = ty
 
 Rather unsavoury ways of getting ClassOp tags:
 \begin{code}
-classOpTagByString :: Class -> FAST_STRING -> Int
+classOpTagByString_maybe :: Class -> FAST_STRING -> Maybe Int
+classOpTagByString       :: Class -> FAST_STRING -> Int
 
 classOpTagByString clas op
+  = case (classOpTagByString_maybe clas op) of
+      Just tag -> tag
+#ifdef DEBUG
+      Nothing  -> pprPanic "classOpTagByString:" (ppCat (ppPStr op : map (ppPStr . classOpString) (classOps clas)))
+#endif
+
+classOpTagByString_maybe clas op
   = go (map classOpString (classOps clas)) 1
   where
+    go []     _   = Nothing
     go (n:ns) tag = if n == op
-                   then tag
+                   then Just tag
                    else go ns (tag+1)
-#ifdef DEBUG
-    go []     tag = pprPanic "classOpTagByString:" (ppCat (ppPStr op : map (ppPStr . classOpString) (classOps clas)))
-#endif
 \end{code}
 
 %************************************************************************
index 7a6480f..3001600 100644 (file)
@@ -453,6 +453,7 @@ getTyDescription ty
       TyConTy tycon _ -> _UNPK_ (getLocalName tycon)
       SynTy tycon _ _ -> _UNPK_ (getLocalName tycon)
       DictTy _ _ _    -> "dict"
+      ForAllTy _ ty   -> getTyDescription ty
       _                      -> pprPanic "getTyDescription: other" (pprType PprDebug tau_ty)
     }
   where
index 7b77b99..d63cecc 100644 (file)
@@ -64,7 +64,7 @@ import Maybes ( maybeToBool, assocMaybe )
 import PrimRep ( PrimRep(..) )
 import Unique  -- quite a few *Keys
 import Util    ( thenCmp, zipEqual, assoc,
-                 panic, panic#, assertPanic,
+                 panic, panic#, assertPanic, pprPanic,
                  Ord3(..){-instances-}
                )
 -- ToDo:rm all these
@@ -78,6 +78,7 @@ import Util   ( thenCmp, zipEqual, assoc,
 --     UniqFM (ufmToList )
 --import {-mumble-}
 --     Outputable
+--import PprEnv
 \end{code}
 
 Data types
@@ -472,7 +473,7 @@ get_app_data_tycon maybe ty
   = case maybe ty of
       Just stuff -> stuff
 #ifdef DEBUG
-      Nothing    -> panic "Type.getAppDataTyCon" -- (pprGenType PprShowAll ty)
+      Nothing    -> panic "Type.getAppDataTyCon"--  (pprGenType PprShowAll ty)
 #endif
 
 
index 36fe314..15678cf 100644 (file)
@@ -4,13 +4,18 @@
 \section[Bags]{@Bag@: an unordered collection with duplicates}
 
 \begin{code}
+#ifdef COMPILING_GHC
 #include "HsVersions.h"
+#endif
 
 module Bag (
        Bag,    -- abstract type
 
        emptyBag, unitBag, unionBags, unionManyBags,
-       mapBag, -- UNUSED: elemBag,
+       mapBag,
+#ifndef COMPILING_GHC
+       elemBag,
+#endif
        filterBag, partitionBag, concatBag, foldBag,
        isEmptyBag, consBag, snocBag,
        listToBag, bagToList
@@ -22,6 +27,8 @@ IMPORT_1_3(List(partition))
 
 import Outputable      ( interpp'SP )
 import Pretty
+#else
+import List(partition)
 #endif
 
 data Bag a
@@ -35,7 +42,7 @@ data Bag a
 emptyBag = EmptyBag
 unitBag  = UnitBag
 
-{- UNUSED:
+#ifndef COMPILING_GHC
 elemBag :: Eq a => a -> Bag a -> Bool
 
 elemBag x EmptyBag        = False
@@ -43,7 +50,7 @@ elemBag x (UnitBag y)     = x==y
 elemBag x (TwoBags b1 b2) = x `elemBag` b1 || x `elemBag` b2
 elemBag x (ListBag ys)    = any (x ==) ys
 elemBag x (ListOfBags bs) = any (x `elemBag`) bs
--}
+#endif
 
 unionManyBags [] = EmptyBag
 unionManyBags xs = ListOfBags xs
@@ -55,8 +62,9 @@ unionBags b EmptyBag = b
 unionBags b1 b2      = TwoBags b1 b2
 
 consBag :: a -> Bag a -> Bag a
-consBag elt bag = (unitBag elt) `unionBags` bag
 snocBag :: Bag a -> a -> Bag a
+
+consBag elt bag = (unitBag elt) `unionBags` bag
 snocBag bag elt = bag `unionBags` (unitBag elt)
 
 isEmptyBag EmptyBag        = True
index c95f0b4..d8c5989 100644 (file)
@@ -25,6 +25,10 @@ near the end (only \tr{#ifdef COMPILING_GHC}).
 #define ASSERT(e) {--}
 #define IF_NOT_GHC(a) a
 #define COMMA ,
+#define _tagCmp compare
+#define _LT LT
+#define _GT GT
+#define _EQ EQ
 #endif
 
 #if defined(COMPILING_GHC) && defined(DEBUG_FINITEMAPS)/* NB NB NB */
index 5a46b23..3917247 100644 (file)
@@ -4,13 +4,15 @@
 \section[ListSetOps]{Set-like operations on lists}
 
 \begin{code}
+#ifdef COMPILING_GHC
 #include "HsVersions.h"
+#endif
 
 module ListSetOps (
        unionLists,
        intersectLists,
        minusList
-#if ! defined(COMPILING_GHC)
+#ifndef COMPILING_GHC
        , disjointLists, intersectingLists
 #endif
    ) where
index 5ed4ac3..1f17679 100644 (file)
@@ -13,7 +13,6 @@ module Maybes (
        MaybeErr(..),
 
        allMaybes,
-       catMaybes,
        firstJust,
        expectJust,
        maybeToBool,
@@ -28,7 +27,9 @@ module Maybes (
        returnMaybe,
        thenMaB
 
-#if ! defined(COMPILING_GHC)
+#if defined(COMPILING_GHC)
+       , catMaybes
+#else
        , findJust
        , foldlMaybeErrs
        , listMaybeErrs
@@ -41,6 +42,8 @@ CHK_Ubiq() -- debugging consistency check
 
 import Unique (Unique) -- only for specialising
 
+#else
+import Maybe -- renamer will tell us if there are any conflicts
 #endif
 \end{code}
 
@@ -63,10 +66,12 @@ a list of @Justs@ into a single @Just@, returning @Nothing@ if there
 are any @Nothings@.
 
 \begin{code}
+#ifdef COMPILING_GHC
 catMaybes :: [Maybe a] -> [a]
 catMaybes []               = []
 catMaybes (Nothing : xs)   = catMaybes xs
 catMaybes (Just x : xs)           = (x : catMaybes xs)
+#endif
 
 allMaybes :: [Maybe a] -> Maybe [a]
 allMaybes [] = Just []
index 985666d..ad2a76f 100644 (file)
 #endif
 
 module Pretty (
-       SYN_IE(Pretty),
 
 #if defined(COMPILING_GHC)
+       SYN_IE(Pretty),
        prettyToUn,
+#else
+       Pretty,
 #endif
        ppNil, ppStr, ppPStr, ppChar, ppInt, ppInteger,
        ppFloat, ppDouble,
@@ -46,6 +48,8 @@ IMPORT_1_3(Ratio)
 IMPORT_1_3(IO)
 
 import Unpretty                ( SYN_IE(Unpretty) )
+#else
+import Ratio
 #endif
 
 import CharSeq
index adc6e65..6d51f3a 100644 (file)
@@ -9,12 +9,16 @@
 # define IF_NOT_GHC(a) {--}
 #else
 # define panic error
-# define TAG_ _CMP_TAG
-# define LT_ _LT
-# define EQ_ _EQ
-# define GT_ _GT
+# define TAG_ Ordering
+# define LT_ LT
+# define EQ_ EQ
+# define GT_ GT
+# define _LT LT
+# define _EQ EQ
+# define _GT GT
 # define GT__ _
-# define tagCmp_ _tagCmp
+# define tagCmp_ compare
+# define _tagCmp compare
 # define FAST_STRING String
 # define ASSERT(x) {-nothing-}
 # define IF_NOT_GHC(a) a
@@ -41,8 +45,8 @@ module Util (
         zipLazy,
        mapAndUnzip, mapAndUnzip3,
        nOfThem, lengthExceeds, isSingleton,
-       startsWith, endsWith,
 #if defined(COMPILING_GHC)
+       startsWith, endsWith,
        isIn, isn'tIn,
 #endif
 
@@ -65,9 +69,12 @@ module Util (
        mapAccumL, mapAccumR, mapAccumB,
 
        -- comparisons
+#if defined(COMPILING_GHC)
        Ord3(..), thenCmp, cmpList,
-       IF_NOT_GHC(cmpString COMMA)
        cmpPString,
+#else
+       cmpString,
+#endif
 
        -- pairs
        IF_NOT_GHC(cfst COMMA applyToPair COMMA applyToFst COMMA)
@@ -88,6 +95,8 @@ CHK_Ubiq() -- debugging consistency check
 IMPORT_1_3(List(zipWith4))
 
 import Pretty
+#else
+import List(zipWith4)
 #endif
 
 infixr 9 `thenCmp`
@@ -212,7 +221,7 @@ startsWith, endsWith :: String -> String -> Maybe String
 startsWith []     str = Just str
 startsWith (c:cs) (s:ss)
   = if c /= s then Nothing else startsWith cs ss
-startWith  _     []  = Nothing
+startsWith  _    []  = Nothing
 
 endsWith cs ss
   = case (startsWith (reverse cs) (reverse ss)) of
@@ -715,7 +724,11 @@ cmpString (x:xs) (y:ys) = if         x == y then cmpString xs ys
 cmpString []     ys    = LT_
 cmpString xs     []    = GT_
 
+#ifdef COMPILING_GHC
 cmpString _ _ = panic# "cmpString"
+#else
+cmpString _ _ = error "cmpString"
+#endif
 \end{code}
 
 \begin{code}
diff --git a/ghc/docs/ANNOUNCE-0.06 b/ghc/docs/ANNOUNCE-0.06
deleted file mode 100644 (file)
index 8a1b633..0000000
+++ /dev/null
@@ -1,116 +0,0 @@
-                 The Glasgow Haskell Compiler
-                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-               Version 0.06 --- Hackers' release
-
-As many of you know, we have been working hard at Glasgow on a modular
-Haskell compiler.  We are proud to announce its first public release.
-
-We are calling it a "Hackers' release" because it is not yet suitable
-for Haskell *programmers*.  It is intended for *implementors* who are
-interested in using our compiler as a substrate for their own work.
-(A later version will indeed be a "Programmers' release".)  We also
-hope that some *porters*, people who would like to see Haskell running
-on their system, will help us debug any Sun dependencies in our
-generated C files.  Finally, the *curious* may simply want to see the
-World's Largest Haskell Program (40,000 lines?)!
-
-The compiler has the following characteristics:
-
-    * It is written in Haskell.
-
-    * It generates C as its target code.
-
-    * It is specifically designed to be modular, so that others can
-    use it as a "motherboard" into which they can "plug in" their
-    latest whizzy strictness analyser, profiler, or whatever.
-
-    * Internally, it uses the polymorphic second-order lambda calculus
-    as a way to preserve correct type information in the face of
-    substantial program transformations.
-
-    * It implements unboxed values as described in [1].  In
-    particular, the implementation of arithmetic and the exploitation
-    of strictness analysis is handled just as described there.
-
-    * Its back end is based on the Spineless Tagless G-machine, an
-    abstract machine for non-strict functional languages.  There is a
-    detailed paper describing this work [2].
-
-    * It plants code to gather quite a lot of simple profiling
-    information.
-
-    * Its runtime system is heavily configurable.  For example, it
-    comes complete with three different garbage collectors: two-space,
-    one-space compacting, and Appel-style generational.  Adding extra
-    fields to heap objects (for debugging or profiling for example) is
-    just a question of altering C macros; the Haskell source doesn't
-    need to be recompiled.  (Caveat: you have to alter them *right*!)
-
-The compiler also suffers its fair share of deficiencies:
-
-    * The compiler itself is large and slow.
-
-    * The code it generates is very, very unoptimised.  Any
-    comparisons you make of runtime speed with good existing compilers
-    will be deeply unflattering.  (Our next priority is optimisation.)
-
-    * Several language features aren't dealt with.  This has not
-    prevented us from compiling and running several quite large
-    Haskell programs.
-
-Please follow the pointers in the top-level README file to find all of
-the documentation in and about this release. Distribution info
-follows below.
-
-We hope you enjoy this system, and we look forward to hearing about
-your successes with it!  Please report bugs to
-glasgow-haskell-bugs@dcs.glasgow.ac.uk and direct general queries to
-glasgow-haskell-request@<same>.
-
-Simon Peyton Jones
-(and his GRASPing colleagues)
-......................................................................
-
-References
-~~~~~~~~~~
-[1] Simon L Peyton Jones and John Launchbury, "Unboxed values as first
-class citizens", Functional Programming Languages and Computer
-Architecture, Boston, ed Hughes, LNCS 523, Springer Verlag, Sept 1991.
-
-[2] Simon L Peyton Jones, "Implementing lazy functional languages on
-stock hardware: the Spineless Tagless G-machine", Journal of
-Functional Programming (to appear).  Also obtainable by anonymous FTP
-from ftp.dcs.glasgow.ac.uk:pub/glasgow-fp/stg.dvi.
-
-Distribution 
-~~~~~~~~~~~~
-This release is available, in whole or in part, from the usual Haskell
-anonymous FTP sites, in the directory pub/haskell/glasgow:
-
-       nebula.cs.yale.edu     (128.36.13.1)
-       ftp.dcs.glasgow.ac.uk  (130.209.240.50)
-       animal.cs.chalmers.se  (129.16.225.66)          
-
-(Beleaguered NIFTP users within the UK can get the same files by using
-a <FP>/haskell/glasgow prefix, instead of pub/haskell/glasgow.)
-
-These are the available files (for the ON DEMAND ones, please ask):
-
-ghc-0.06-src.tar.Z     the basic source distribution; assumes you
-                       will compile it with Chalmers HBC, version
-                       0.997.3 or later.
-
-ghc-0.06-proto-hi-files.tar.Z
-                       An "overlay" of .hi interface files, to be
-                       used when compiling with the *prototype*
-                       Glasgow Haskell compiler (version 0.411 or
-                       later).
-
-ghc-0.06-hc-files.tar.Z An "overlay" of .hc generated-C files; used
-                       either to save you the trouble of compiling
-                       the prelude, or because your only interest is
-                       porting the C to
-
-ghc-0.06-tests.tar.Z   Some of our test files we have used in getting
-                       this beast going.  We hope to grow them into a
-                       semi-respectable benchmark suite.
diff --git a/ghc/docs/ANNOUNCE-0.10 b/ghc/docs/ANNOUNCE-0.10
deleted file mode 100644 (file)
index 04062f1..0000000
+++ /dev/null
@@ -1,135 +0,0 @@
-                 The Glasgow Haskell Compiler
-                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-We are happy to announce the first full release of the Glasgow Haskell
-Compiler (GHC, version 0.10).  It is freely available by FTP; details
-appear below.
-
-To run this release, you need a Sun4, probably with 16+MB memory, and
-GNU C (gcc), version 2.1 or greater, and "perl".  If building from
-source, you will need Chalmers HBC, version 0.998.x.
-
-We hope you enjoy this system, and we look forward to hearing about
-your successes with it!  Please report bugs to
-glasgow-haskell-bugs@dcs.glasgow.ac.uk and direct general queries to
-glasgow-haskell-request@<same>.
-
-Simon Peyton Jones
-(and his GRASPing colleagues)
-
-Why a Haskell programmer might want to use GHC
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-* Almost all of Haskell is implemented.  In particular, the full range
-  of data types is supported: arbitrary precision integers, rationals,
-  double-precision floats, and "real" arrays with O(1) access time.
-  (The release notes list all unimplemented language features.)
-
-* An extensible I/O system is provided, based on a "monad" [1]. (The
-  standard Haskell I/O system is built on this foundation.)
-
-* A number of significant language extensions are implemented:
-       - Fully fledged unboxed data types [2].
-       - Ability to write arbitrary in-line C-language code, using
-         the I/O monad to retain referential transparency.
-       - Incrementally-updatable arrays, also embedded in a monad.
-       - Mutable reference types.
-
-* By default, the system uses a generational garbage collector which
-  lets you run programs whose live data is significantly larger than
-  the physical memory size before thrashing occurs.  (Conventional
-  2-space GC starts thrashing when the live data gets to about half
-  the physical memory size.)
-
-* A new profiling system is supplied, which enables you to find out which
-  bits of your program are eating both *time* and the *space* [3].
-
-* Good error messages.  Well, fairly good error messages.  Line
-  numbers are pretty accurate, and during type checking you get
-  several (accurate) error reports rather than just one.
-
-* Performance: programs compiled with GHC "usually" beat
-  Chalmers-HBC-compiled ones.  If you find programs where HBC wins,
-  send them to us :-).
-
-* We have a pretty good test suite, and this version passes
-  practically all of it.  (Yes, it can compile itself, too.) We hope
-  you will find the system to be robust.
-
-Why a functional-language implementor might want to use GHC
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-* We have tried very hard to write the compiler in a modular and
-  well-documented way, so that other researchers can modify and extend
-  it.  One of our goals is specifically to provide a framework to
-  support others' work.  Several people are already using it in this
-  way.
-
-* Highly configurable runtime system.  Heavy use of C macros means
-  that you can modify much of the storage representation without
-  telling the compiler.  For example, the system comes with 4
-  different garbage collectors! (all working)
-
-* Internals: extensive use of the second-order lambda calculus as an
-  intermediate code; the Spineless Tagless G-machine as evaluation
-  model [4].
-
-* Various performance-measurement hooks.
-
-Main shortcomings
-~~~~~~~~~~~~~~~~~
-* No interactive system.  This is a batch compiler only.  (Any
-  volunteers?)
-
-* Compiler is greedy on resources.  Going via C doesn't help here.
-
-* This system should run on any Unix box.  We haven't had time to do
-  any non-Sun4 ports.  Help or prodding welcome.
-
-References
-~~~~~~~~~~
-All these papers come with the distribution [in ghc/docs/papers].
-
-[1] "Imperative functional programming", Peyton Jones & Wadler, POPL '93
-
-[2] "Unboxed data types as first-class citizens", Peyton Jones &
-    Launchbury, FPCA '91
-
-[3] "Profiling lazy functional languages", Sansom & Peyton Jones,
-    Glasgow workshop '92
-
-[4] "Implementing lazy functional languages on stock hardware", Peyton
-    Jones, Journal of Functional Programming, Apr 1992
-
-How to get it
-~~~~~~~~~~~~~
-This release is available, in whole or in part, from the usual Haskell
-anonymous FTP sites, in the directory pub/haskell/glasgow:
-
-       nebula.cs.yale.edu     (128.36.13.1)
-       ftp.dcs.glasgow.ac.uk  (130.209.240.50)
-       animal.cs.chalmers.se  (129.16.225.66)          
-
-(Beleaguered NIFTP users within the UK can get the same files from
-Glasgow by using a <FP>/haskell/glasgow prefix, instead of
-pub/haskell/glasgow.  Also, we are mirrored by src.doc.ic.ac.uk, in
-languages/haskell/glasgow, and you can get files from there by every
-means known to humanity.)
-
-These are the available files:
-
-ghc-0.10-src.tar.Z     The basic source distribution; assumes you
-                       will compile it with Chalmers HBC, version
-                       0.998.n, on a Sun4, for which you have GNU C
-                       (gcc) version 2.1 or greater.  About 3MB.
-
-ghc-0.10-bin-sun4.tar.Z        A binary distribution -- avoid compiling
-                       altogether!  For SunOS 4.1.x; assumes you
-                       have GNU C (gcc) version 2.x around...
-
-ghc-0.10-patch-*       Patches to the original distribution.  There
-                       are none to start with, of course, but there
-                       might be by the time you grab the files.
-                       Please check for them.
-
-Once you have the distribution, please follow the pointers in the
-ghc/README file to find all of the documentation in and about this
-release.
diff --git a/ghc/docs/ANNOUNCE-0.16 b/ghc/docs/ANNOUNCE-0.16
deleted file mode 100644 (file)
index f642566..0000000
+++ /dev/null
@@ -1,146 +0,0 @@
-            The Glasgow Haskell Compiler -- version 0.16
-            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The second public release of the Glasgow Haskell Compiler is now
-available (GHC, version 0.16). Binaries (recommended) and source are
-freely available by FTP; details appear below.
-
-GHC 0.16 is still alpha-quality software.  This release in an interim
-measure, not as solid as I would prefer.  However, a lot has gone in
-since December.  The profiling system is Way Cool.  The compiler now
-has a strictness analyser and an update analyser.  Compiled programs
-tend to run faster.  Compilation speed is worse.  Bugs remain, but
-they tend to be work-around-able.
-
-To run this release, you need a Sun4 or Sun3, probably with 16+MB
-memory, and GNU C (gcc), version 2.1 or greater, and "perl".
-
-This system can be built from source using: itself (most likely to
-succeed), the previous GHC release (0.10) [least likely], or the
-Chalmers HBC compiler [in-between].  Please see the appropriate
-documentation for details.
-
-Please report bugs to glasgow-haskell-bugs@dcs.glasgow.ac.uk and
-direct general queries to glasgow-haskell-request@<same>.
-
-Will Partain
-(typist for the AQUA [formerly GRASP] project)
-
-....................................................................
-
-Why a Haskell programmer might want to use GHC
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-* GHC provides an extensible I/O system, based on a "monad" [1]. (The
-  standard Haskell I/O system is built on this foundation.)
-
-* A number of significant language extensions are implemented:
-       - Fully fledged unboxed data types [2].
-       - Ability to write arbitrary in-line C-language code, using
-         the I/O monad to retain referential transparency.
-       - Incrementally-updatable arrays, also embedded in a monad.
-       - Mutable reference types.
-
-* A new profiling system is supplied, which enables you to find out
-  which bits of your program are eating both *time* and the *space* [3].
-
-* By default, the system uses a generational garbage collector which
-  lets you run programs whose live data is significantly larger than
-  the physical memory size before thrashing occurs.  (Conventional
-  2-space GC starts thrashing when the live data gets to about half
-  the physical memory size.)
-
-* Good error messages.  Well, fairly good error messages.  Line
-  numbers are pretty accurate, and during type checking you get
-  several (accurate) error reports rather than just one.
-
-* Performance: programs compiled with GHC "often" beat
-  Chalmers-HBC-compiled ones.  If you find programs where HBC wins,
-  please report it to us, as a bug :-).
-
-Why a functional-language implementor might want to use GHC
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-* We have tried very hard to write the compiler in a modular and
-  well-documented way, so that other researchers can modify and extend
-  it.  One of our goals is specifically to provide a framework to
-  support others' work.  Several people are already using it in this
-  way.
-
-* Highly configurable runtime system.  Heavy use of C macros means
-  that you can modify much of the storage representation without
-  telling the compiler.  For example, the system comes with 4
-  different garbage collectors! (all working)
-
-* Internals: extensive use of the second-order lambda calculus as an
-  intermediate code; the Spineless Tagless G-machine as evaluation
-  model [4].
-
-* Various performance-measurement hooks.
-
-Main shortcomings
-~~~~~~~~~~~~~~~~~
-* No interactive system.  This is a batch compiler only.  (Any
-  volunteers?)
-
-* Compiler is greedy on resources.  Going via C doesn't help here.
-
-* This system should run on any Unix box.  We haven't had time to do
-  any non-Sun ports.  Help or prodding welcome.
-
-References
-~~~~~~~~~~
-All these papers come with the distribution [in ghc/docs/papers].
-
-[1] "Imperative functional programming", Peyton Jones & Wadler, POPL '93
-
-[2] "Unboxed data types as first-class citizens", Peyton Jones &
-    Launchbury, FPCA '91
-
-[3] "Profiling lazy functional languages", Sansom & Peyton Jones,
-    Glasgow workshop '92
-
-[4] "Implementing lazy functional languages on stock hardware", Peyton
-    Jones, Journal of Functional Programming, Apr 1992
-
-How to get it
-~~~~~~~~~~~~~
-This release is available, in whole or in part, from the usual Haskell
-anonymous FTP sites, in the directory pub/haskell/glasgow:
-
-       ftp.dcs.glasgow.ac.uk  (130.209.240.50)
-       ftp.cs.chalmers.se     (129.16.225.66)          
-       nebula.cs.yale.edu     (128.36.13.1)
-
-We are mirrored by src.doc.ic.ac.uk, in
-computing/programming/languages/haskell/glasgow, and you can get files
-from there by every means known to humanity.
-
-These are the available files (.Z for compressed, .gz for gzipped) --
-some are `on demand', ask if you don't see them:
-
-ghc-0.16-bin-sun4.tar.{Z,gz} A binary distribution -- avoid compiling
-                       altogether!  For SunOS 4.1.x; assumes you have
-                       GNU C (gcc) version 2.x around...
-
-ghc-0.16-src.tar.gz    The basic source distribution; about 3MB.
-
-ghc-0.16-hi-files-{hbc,ghc-0.10}.tar.gz
-                       Interface files for the compiler proper
-                       (ghc/compiler/*/*.hi), to be used if booting
-                       with either HBC or GHC version 0.10.  (The
-                       distributed .hi files assume GHC version
-                       0.16.)
-                       
-ghc-0.16-hc-files.tar.gz The intermediate C files for the compiler
-                        proper, the prelude, and `Hello, world'.
-                        Used when porting.
-
-ghc-0.16-patch-*       Patches to the original distribution.  There
-                       are none to start with, of course, but there
-                       might be by the time you grab the files.
-                       Please check for them.
-
-There are no diffs from version 0.10, as they would be laughably huge.
-
-Once you have the distribution, please follow the pointers in the
-ghc/README file to find all of the documentation in and about this
-release.
diff --git a/ghc/docs/ANNOUNCE-0.19 b/ghc/docs/ANNOUNCE-0.19
deleted file mode 100644 (file)
index 6f0523f..0000000
+++ /dev/null
@@ -1,130 +0,0 @@
-            The Glasgow Haskell Compiler -- version 0.19
-            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-                       "What a great system!"
-
-The third public release of the Glasgow Haskell Compiler is now
-available (GHC, version 0.19). Binaries and sources are freely
-available by FTP; details below.
-
-Highlights of what's new in 0.19 since 0.16 (July 1993):
-  * Somewhat faster compilation times.
-  * Still better error messages.
-  * Better Haskell 1.2 compliance, including more derived instances,
-    `default' declarations, renaming, etc.
-  * Native-code generator for SPARC.
-  * Unfoldings across module boundaries.
-  * Automatic specialisation of overloaded functions.
-  * Better strictness analysis, including "looking inside tuples" and
-    "absence analysis" (arguments that aren't used).
-  * New "simplifier" (program-transformation engine).
-
-Please see the release notes for a more complete list (including
-Backward Incompatibilities to watch out for).
-
-To run this release, you need a machine with 16+MB memory, GNU C
-(`gcc') [version 2.1 or greater], and `perl'.  We have seen GHC work
-in *some* form or fashion on: Sun4s, Sun3s, DECstations, DEC Alphas,
-HP-PA boxes.  Sun4s, our development platform, are by far the best
-supported.  We will distribute binaries as we build them.
-
-Once you have the distribution, please follow the pointers in
-ghc/README to find all of the documentation in and about this release.
-
-Please report bugs to glasgow-haskell-bugs@dcs.glasgow.ac.uk and
-direct general queries to glasgow-haskell-request@<same>.
-
-We are very grateful to everyone who has sent a bug report, sent a
-"look at this weird result" report, lent us a machine on which to try
-a port, or (best of all) contributed code.  Keep up the good work.
-
-Simon Peyton Jones
-
-Dated: 93/12/16
-....................................................................
-
-"Should I start using GHC 0.19?"
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* If you're using a previous release of GHC: YES.  (Recompile everything.)
-
-* If you want to hack on a Haskell compiler: YES.
-
-* If you're new to Haskell: Try Gofer (an interpreter for a
-  Haskell-like language) first; then come back and say YES.
-
-* If you want time profiling as well as space profiling: YES.
-
-* If you need the Glasgow Haskell extensions, i.e., calling C, unboxed
-  datatypes, monadic I/O etc.: YES.  (ghc/README says a little more
-  about these features.)
-
-* If you're using HBC at the moment: not a clear YES or NO.  *We*
-  really like having both compilers to play against each other.  For
-  example, HBC has better compilation times, but you'll like GHC's
-  error messages.  And you can try them both before submitting a bug
-  report for either one.
-
-* If you want simulated parallel execution on a uniprocessor: NO.
-  (Use the "hbcpp" variant of HBC from York.)
-
-....................................................................
-
-How to make sure every release of GHC will run your program (well)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-*Please* send us a copy!  Part of our work is to collect and study
-large and *realistic* Haskell programs.  Only you can provide them.
-They need not be final, polished versions -- they just have to run.
-
-Among other things, we run every release against our entire
-collection, so if your program's in there...
-
-....................................................................
-
-How to get it
-~~~~~~~~~~~~~
-This release is available, in whole or in part, from the usual Haskell
-anonymous FTP sites, in the directory pub/haskell/glasgow:
-
-       ftp.dcs.glasgow.ac.uk  (130.209.240.50)
-       ftp.cs.chalmers.se     (129.16.225.66)          
-       nebula.cs.yale.edu     (128.36.13.1)
-
-We are mirrored by src.doc.ic.ac.uk, in
-computing/programming/languages/haskell/glasgow, and you can get files
-from there by every means known to humanity.
-
-These are the available files (.Z for compressed, .gz for gzipped) --
-some are `on demand', ask if you don't see them:
-
-ghc-0.19-bin-sun4.tar.{Z,gz} A binary distribution -- unpack & run!
-                       For SunOS 4.1.x; assumes you have GNU C (gcc)
-                       version 2.x around...
-
-ghc-0.19-bin-<other>.tar.gz Other binary distributions -- we will
-                       make them available as we go along; they
-                       will be announced on the Haskell mailing list
-                       (not elsewhere).
-
-ghc-0.19-src.tar.gz    The basic source distribution; about 3MB.
-
-ghc-0.19-hc-files.tar.gz The intermediate C (.hc) files for the
-                        compiler proper, the prelude, and `Hello,
-                        world'.
-
-ghc-0.19.ANNOUNCE      This file
-
-ghc-0.19.{README,RELEASE-NOTES} From the distribution; for those who
-                       want to peek before FTPing...
-
-ghc-0.19-ps-docs.tar.gz        Main GHC documents in PostScript format; in
-                       case your TeX setup doesn't agree with our
-                       DVI files...
-
-ghc-0.19-hi-files-hbc.tar.gz
-                       Interface files for the compiler proper
-                       (ghc/compiler/*/*.hi), to be used if booting
-                       with either HBC.  (The distributed .hi files
-                       assume GHC version 0.19.)
-                       
-There are no diffs from version 0.16, as they would be laughably huge.
diff --git a/ghc/docs/ANNOUNCE-0.20 b/ghc/docs/ANNOUNCE-0.20
deleted file mode 100644 (file)
index 2e7f274..0000000
+++ /dev/null
@@ -1,55 +0,0 @@
-This is version 0.20 of the Glorious Glasgow Haskell compilation
-system (GHC).
-
-Version 0.20 is an "internal" release, intended *ONLY* for the most
-fanatical GHC hackers.
-
-* Many things about it may be broken, though it
-does compile and run most programs.
-
-* I/O and ccall scheme re-done; any such low-level code probably needs
-  fixing; I/O attempts to follow 1.3 I/O proposal.  All ccall
-  arguments and results are automagically "boxed".
-
-* PrimOps fiddled; any code that uses them directly will probably need
-  attention.
-
-* We've renamed some things, so as to move to a we-don't-steal-user-
-  name-space policy.  Thus "tagCmp" has become "_tagCmp".  Names starting
-  with underscores are now cool if -fglasgow-exts.
-
-  You might want to see our "state-interface" document if you mess
-  with all this low-level/non-standard stuff; I'll try to remember to
-  put a copy up for FTP.
-
-* No promises about profiling.
-
-* Documentation is untouched since 0.19.
-
-Version 0.19 was the last public release.  It has held up pretty well
-and should be available wherever you got 0.20 from.  I commend 0.19 to
-all sane people.
-
-Configuring 0.20 is a little different than 0.19:
-
-    % cd <very-top>
-    % ./configure --with-boot=c
-    % ./STARTUP-ghc std
-    % cd ghc; make
-
-Things to note:
-
-* It's wrong for jmake to tell you "0: unknown flag -traditional"; but
-  it is harmless.
-
-* The 0.20 compiler seems more likely to run out of stack; use
-  -Rmax-stksize2m (or something) to increase; within the distribution,
-  probably something like...
-
-    % make EXTRA_HC_OPTS="-H20m -Rmax-stksize4m"
-
-See the "configure" script if you want to know what other options are
--- there is no other documentation at this time!
-
-Will Partain, AQUA project typist
-partain@dcs.glasgow.ac.uk
diff --git a/ghc/docs/ANNOUNCE-0.22 b/ghc/docs/ANNOUNCE-0.22
deleted file mode 100644 (file)
index d7fed2c..0000000
+++ /dev/null
@@ -1,109 +0,0 @@
-            The Glasgow Haskell Compiler -- version 0.22
-            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A new public release of the Glasgow Haskell Compiler is now
-available (GHC, version 0.22). Binaries and sources are freely
-available by FTP; details below.
-
-Highlights of what's new in 0.22 since 0.19 (December 1993):
-
-  * Faster compilation times (now about 40% slower than HBC if not
-    using -O [on a Sun4]).
-  * Revamped state-tranformer stuff, which affects arrays, calling out
-    to C, and I/O (preparing for Haskell 1.3).
-  * "Threads" stuff -- can do quasi-parallel execution on a
-    uniprocessor.
-  * No more space leaks from lazy pattern-matching.
-  * Alastair Reid's "stable pointers" and "malloc pointers"; friendly
-    interaction with "C Land".
-  * Time profiling no longer attributes great chunks
-    of time to "CAF".  (However, because of the many recent changes,
-    profiling is probably *less* reliable than before.)
-  * New "GHC system library" (analogous to the "HBC system library");
-    not much there, but stay tuned.
-  * Fully supported on DEC Alphas.  Some other porting progress.
-  * Much improved configuration.
-  * Less user namespace pollution by the system.
-  * New mailing lists about Glasgow Haskell.
-
-    - The "glasgow-haskell-users" list is for GHC users to chat among
-      themselves.  Subscribe by sending mail to
-      "glasgow-haskell-users-request@dcs.glasgow.ac.uk".  Messages for the
-      list go to "glasgow-haskell-users".
-
-    - The "glasgow-haskell-bugs" list is for submission of bug reports
-      and discussion thereof.  Subscribe via
-      "glasgow-haskell-bugs-request@dcs.glasgow.ac.uk"; send bug
-      reports and rumination thereupon go to "glasgow-haskell-bugs".
-
-Please see the release notes for a complete discussion of What's New.
-
-To run this release, you need a machine with 16+MB memory, GNU C
-(`gcc') [version 2.1 or greater], and `perl'.  We have seen GHC work
-in *some* form or fashion on: Sun4s, DEC Alphas, Sun3s, NeXTs,
-DECstations, HP-PA and SGI boxes.  Sun4s and Alphas, our development
-platforms, are fully supported.  We distribute binaries for them.
-
-*** LATE NEWS: Don't use GCC 2.6.0 on the Alpha ***
-
-Once you have the distribution, please follow the pointers in
-ghc/README to find all of the documentation in and about this release.
-
-Please report bugs to glasgow-haskell-bugs@dcs.glasgow.ac.uk and
-direct general queries to glasgow-haskell-request@<same>.
-
-Simon Peyton Jones
-
-Dated: 94/07/27
-....................................................................
-
-How to get it
-~~~~~~~~~~~~~
-This release is available, in whole or in part, from the usual Haskell
-anonymous FTP sites, in the directory pub/haskell/glasgow:
-
-       ftp.dcs.glasgow.ac.uk  (130.209.240.50)
-       ftp.cs.chalmers.se     (129.16.225.66)          
-       nebula.cs.yale.edu     (128.36.13.1)
-
-The Glasgow site is mirrored by src.doc.ic.ac.uk, in
-computing/programming/languages/haskell/glasgow.
-
-These are the available files (.gz files are gzipped) -- some are `on
-demand', ask if you don't see them:
-
-ghc-0.22-bin-sun4.tar.gz A binary distribution -- unpack & run!
-                       For SunOS 4.1.x; assumes you have GNU C (gcc)
-                       version 2.x around...
-
-ghc-0.22-bin-alpha.tar.gz A binary distribution -- unpack & run!
-                       Built on OSF1 V2.0; assumes you have GNU C (gcc).
-
-ghc-0.22-bin-<other>.tar.gz Other binary distributions -- we will
-                       make them available as we go along; they
-                       will be announced on the Haskell mailing list
-                       (not elsewhere).
-
-ghc-0.22-src.tar.gz    The basic source distribution; about 3MB.
-
-ghc-0.22-hc-files.tar.gz The intermediate C (.hc) files for the
-                        compiler proper, the prelude, and `Hello,
-                        world'.  About 4MB.
-
-ghc-0.22.ANNOUNCE      This file
-
-ghc-0.22.{README,RELEASE-NOTES} From the distribution; for those who
-                       want to peek before FTPing...
-
-ghc-0.22-ps-docs.tar.gz        Main GHC documents in PostScript format; in
-                       case your TeX setup doesn't agree with our
-                       DVI files...
-
-ghc-0.22-hi-files-hbc.tar.gz
-                       Interface files for the compiler proper
-                       (ghc/compiler/*/*.hi), to be used if booting
-                       with HBC.  Not recommended, but some might
-                       want to.  (The distributed .hi files assume
-                       GHC version 0.22.)
-                       
-There are no diffs from version 0.19, as they would be monstrous.
diff --git a/ghc/docs/ANNOUNCE-0.23 b/ghc/docs/ANNOUNCE-0.23
deleted file mode 100644 (file)
index d7e7d94..0000000
+++ /dev/null
@@ -1,124 +0,0 @@
-            The Glasgow Haskell Compiler -- version 0.23
-            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A new public release of the Glasgow Haskell Compiler is now available
-(GHC, version 0.23). Binaries and sources are freely available by
-anonymous FTP; details below.
-
-Haskell is "the" standard lazy functional programming language [see
-SIGPLAN Notices, May 1992].  The current language version is 1.2.
-
-GHC is a state-of-the-art batch compiler.  For some idea of how it
-compares against the competition, see Pieter Hartel's recent revision
-of his FPCA '93 paper.  Reference attached.  Summary: we win!
-
-Highlights of what's new in GHC 0.23 since 0.22 (July 1994):
-
-  * Faster compilation times (less than 10% slower than HBC if not
-    using -O [on a Sun4]).
-
-  * Produces 10-15% smaller executables. The main compiler binary is
-    1MB smaller than in 0.22.
-
-  * >>> USER-VISIBLE changes <<< to "monadic I/O", because we are
-    switching to the Haskell 1.3 *draft* I/O proposal.  Please see the
-    relevant bit of the User's Guide before doing monadic I/O things
-    with 0.23.
-
-  * Native-code generator for DEC Alphas.
-
-  * A _selective_ lambda lifter.
-
-  * The yacc-based parser is now called directly from Haskell.
-
-  * Configuration changed enough that "the same old thing" *won't* work.
-    Configuring binary distributions should be trivial now.
-
-  * Quite a few bugs fixed; the usual big wad of code added.
-
-Please see the release notes for a complete discussion of What's New.
-
-Should you upgrade to 0.23?  If you are a contented 0.22 user,
-probably not.  Otherwise, probably yes.
-
-To run this release, you need a machine with 16+MB memory, GNU C
-(`gcc'), and `perl'.  We have seen GHC work in *some* form or fashion
-on: Sun4s, DEC Alphas, Sun3s, NeXTs, DECstations, HP-PA and SGI boxes.
-Sun4s and Alphas, our development platforms, are fully supported; we
-distribute binaries for them.  The release notes give a full
-what-ports-work report.
-
-Once you have the distribution, please follow the pointers in
-ghc/README to find all of the documentation in and about this release.
-NB: preserve modification times when un-tarring (no `m' option for
-tar, please)!
-
-We run mailing lists for GHC users and bug reports; to subscribe, send
-mail to glasgow-haskell-{users,bugs}-request@dcs.glasgow.ac.uk.
-Please send bug reports to glasgow-haskell-bugs.
-
-Simon Peyton Jones
-
-Dated: 94/12/21
-
-======================================================================
-Hartel reference:
-
-@techreport{Har94g,
-       author = {P. H. Hartel},
-       title = {Benchmarking implementations of lazy functional
-               languages {II} -- Two years later},
-       institution = {Dept. of Comp. Sys, Univ. of Amsterdam},
-       type = {Technical report},
-       number = {Cs-94-21},
-       month = {Dec},
-       year = {1994}}
-
-The paper is available from ftp.fwi.uva.nl,
-file: pub/computer-systems/functional/reports/benchmarkII.ps.Z
-
-The programs are in file: pub/computer-systems/functional/packages/benchmark.tar.Z
-
-======================================================================
-How to get GHC:
-
-This release is available, in whole or in part, from the usual Haskell
-anonymous FTP sites, in the directory pub/haskell/glasgow:
-
-       ftp.dcs.glasgow.ac.uk  (130.209.240.50)
-       ftp.cs.chalmers.se     (129.16.227.140)
-       haskell.cs.yale.edu    (128.36.11.43)
-
-The Glasgow site is mirrored by src.doc.ic.ac.uk (155.198.191.4), in
-computing/programming/languages/haskell/glasgow.
-
-These are the available files (.gz files are gzipped) -- some are `on
-demand', ask if you don't see them:
-
-ghc-0.23-bin-sun4.tar.gz A binary distribution -- unpack & run!
-                       For SunOS 4.1.x; assumes you have GNU C (gcc)
-
-ghc-0.23-bin-alpha.tar.gz A binary distribution -- unpack & run!
-                       Built on OSF1 V2.0; assumes you have GNU C (gcc).
-
-ghc-0.23-bin-<other>.tar.gz Other binary distributions -- we will
-                       make them available as we go along; they
-                       will be announced on the Haskell mailing list
-                       (not elsewhere).
-
-ghc-0.23-src.tar.gz    The basic source distribution; about 3MB.
-
-ghc-0.23-hc-files.tar.gz The intermediate C (.hc) files for the
-                        compiler proper, the prelude, and `Hello,
-                        world'.  About 4MB.
-
-ghc-0.23.ANNOUNCE      This file
-
-ghc-0.23.{README,RELEASE-NOTES} From the distribution; for those who
-                       want to peek before FTPing...
-
-ghc-0.23-ps-docs.tar.gz        Main GHC documents in PostScript format; in
-                       case your TeX setup doesn't agree with our
-                       DVI files...
-                       
-There are no diffs from version 0.22, as they would be monstrous.
diff --git a/ghc/docs/ANNOUNCE-0.25 b/ghc/docs/ANNOUNCE-0.25
deleted file mode 100644 (file)
index a3da0c2..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-A binary-only from-working-sources no-guarantees snapshot of the
-Glasgow Haskell compiler (GHC) for Linux x86 machines is now available
-by FTP from ftp.dcs.glasgow.ac.uk, in
-pub/haskell/glasgow/ghc-0.25-linux.tar.gz.
-
-This release is the first, long-awaited "registerized" GHC for Linux,
-which produces code of reasonable size and speed.  We use our normal
-technique of "stealing registers" with GCC's
-global-variables-in-registers facility.  We "steal" six of the x86's
-eight general-purpose registers, including the C stack-pointer (%esp),
-which we use for the heap pointer (Hp).
-
-To use this GHC, you need a special version of GCC, which is also
-provided in the distribution (under "gcc-linux-to-linux").  Whatever
-you do, please do *not* report any "bugs" in this GCC to bug-gcc --
-report them to *me* instead.
-
-One special thing you must watch out for: If GCC "crashes" with a
-message about spilling registers, it is *not* a GCC problem.  It means
-you must get GHC to "back off" in its register "stealing".  First try
-a -monly-4-regs flag, then -monly-3-regs, and as a last resort,
--monly-2-regs.  As far as we know, all Haskell code goes through GHC
-with a -monly-2-regs flag (but it produces substantially worse code
-with that flag).
-
-Profiling is not provided in this release.
-
-Please report any bugs to glasgow-haskell-bugs@dcs.glasgow.ac.uk.
-
-Will Partain
-AQUA project (slave)
-
-Dated: 95/04/01
-
-=== INSTALLATION NOTES ==============================================
-
-Unpack the distribution.
-
-Move "gcc-linux-to-linux" and "ghc-0.25-linux" wherever you like.
-
-Alter the "gcc" script to point to wherever you've put
-"gcc-linux-to-linux", and put the "gcc" script wherever you wish in
-your PATH.
-
-Make a link to ghc-0.25-linux/ghc/driver/ghc, so that "ghc" will be in
-your PATH.
-
-Change *all* hardwired paths in ghc/driver/ghc and in
-ghc/utils/hscpp/hscpp to point to where things are on your system.
-Notably: where "perl" is (first line of each script), where $TopPwd is
-(ghc script), where your gcc cpp is (hscpp script).
-
-GHC should then work.  Try "ghc -v" on something simple, to make sure
-it compiles and links a program correctly.
diff --git a/ghc/docs/ANNOUNCE-0.26 b/ghc/docs/ANNOUNCE-0.26
deleted file mode 100644 (file)
index fa35253..0000000
+++ /dev/null
@@ -1,153 +0,0 @@
-            The Glasgow Haskell Compiler -- version 0.26
-            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-We are proud to announce a new public release of the Glasgow Haskell
-Compiler (GHC, version 0.26). Sources and binaries are freely
-available by anonymous FTP and on the World-Wide Web; details below.
-
-Haskell is "the" standard lazy functional programming language [see
-SIGPLAN Notices, May 1992].  The current language version is 1.2.  GHC
-provides some proposed features of 1.3, notably monadic I/O.
-
-The Glasgow Haskell project seeks to bring the power and elegance of
-functional programming to bear on real-world problems.  To that end,
-GHC lets you call C (including cross-system garbage collection),
-provides good profiling tools, supports ever richer I/O, and (with
-this release) adds concurrency.  Our goal is to make it the "tool of
-choice for real-world applications".
-
-Highlights of what's new in GHC 0.26 since 0.24 (March 1995):
-
-  * Concurrent Haskell: with this, you can build programs out of many
-    I/O-performing, interacting `threads'.  We have a draft paper
-    about Concurrent Haskell, and our forthcoming Haggis GUI toolkit
-    uses it.
-
-  * Parallel Haskell, running on top of PVM (Parallel Virtual Machine)
-    and hence portable to pretty much any parallel architecture,
-    whether shared memory or distributed memory.  With this, your
-    Haskell program runs on multiple processors, guided by `par` and
-    `seq` annotations.  The first pretty-much-everyone-can-try-it
-    parallel functional programming system!  NB: The parallel stuff is
-    "research-tool quality"... consider this an alpha release.
-
-  * "Foldr/build" deforestation (by Andy Gill) is in, as are
-    "SPECIALIZE instance" pragmas (by Patrick Sansom).
-
-  * The LibPosix library provides an even richer I/O interface than
-    the standard 1.3 I/O library.  A program like a shell or an FTP
-    client can be written in Haskell -- examples included.
-
-  * Yet more cool libraries: Readline (GNU command-line editing),
-    Socket (BSD sockets), Regex and MatchPS (GNU regular expressions).
-    By Darren Moffat and Sigbjorn Finne.
-
-  * New ports -- Linux (a.out) and MIPS (Silicon Graphics).
-
-  * NB: configuration has changed yet again -- for the better, of
-    course :-)
-
-Please see the release notes for a complete discussion of What's New.
-
-To run this release, you need a machine with 16+MB memory, GNU C
-(`gcc'), and `perl'.  We have seen GHC 0.26 work on these platforms:
-alpha-dec-osf2, hppa1.1-hp-hpux9, i386-unknown-linuxaout,
-m68k-sun-sunos4, mips-sgi-irix5, and sparc-sun-{sunos4,solaris2}.
-Similar platforms should work with minimal hacking effort.
-The installer's guide give a full what-ports-work report.
-
-Binaries are now distributed in `bundles', e.g. a "profiling bundle"
-or a "concurrency bundle" for your platform.  Just grab the ones you
-need.
-
-Once you have the distribution, please follow the pointers in
-ghc/README to find all of the documentation about this release.  NB:
-preserve modification times when un-tarring the files (no `m' option
-for tar, please)!
-
-We run mailing lists for GHC users and bug reports; to subscribe, send
-mail to glasgow-haskell-{users,bugs}-request@dcs.glasgow.ac.uk.
-Please send bug reports to glasgow-haskell-bugs.
-
-Particular thanks to: Jim Mattson (author of much of the code) who has
-now moved to HP in California; and the Turing Institute who donated a
-lot of SGI cycles for the SGI port.
-
-Simon Peyton Jones and Will Partain
-
-Dated: 95/07/24
-
-Relevant URLs on the World-Wide Web:
-
-GHC home page            http://www.dcs.glasgow.ac.uk/fp/software/ghc.html
-Glasgow FP group page     http://www.dcs.glasgow.ac.uk/fp/
-comp.lang.functional FAQ  http://www.cs.nott.ac.uk/Department/Staff/mpj/faq.html
-
-======================================================================
-How to get GHC 0.26:
-
-This release is available by anonymous FTP from the main Haskell
-archive sites, in the directory pub/haskell/glasgow:
-
-       ftp.dcs.glasgow.ac.uk  (130.209.240.50)
-       ftp.cs.chalmers.se     (129.16.227.140)
-       haskell.cs.yale.edu    (128.36.11.43)
-
-The Glasgow site is mirrored by src.doc.ic.ac.uk (146.169.43.1), in
-computing/programming/languages/haskell/glasgow.
-
-These are the available files (.gz files are gzipped) -- some are `on
-demand', ask if you don't see them:
-
-ghc-0.26-src.tar.gz    The source distribution; about 3MB.
-
-ghc-0.26.ANNOUNCE      This file.
-
-ghc-0.26.{README,RELEASE-NOTES} From the distribution; for those who
-                       want to peek before FTPing...
-
-ghc-0.26-ps-docs.tar.gz        Main GHC documents in PostScript format; in
-                       case your TeX setup doesn't agree with our
-                       DVI files...
-
-ghc-0.26-<platform>.tar.gz Basic binary distribution for a particular
-                       <platform>.  Unpack and go: you can compile
-                       and run Haskell programs with nothing but one
-                       of these files.  NB: does *not* include
-                       profiling (see below).
-
-       <platform> ==>  alpha-dec-osf2
-                       hppa1.1-hp-hpux9
-                       i386-unknown-linuxaout
-                       i386-unknown-solaris2
-                       m68k-sun-sunos4
-                       mips-sgi-irix5
-                       sparc-sun-sunos4
-                       sparc-sun-solaris2
-
-ghc-0.26-<bundle>-<platform>.tar.gz
-
-       <platform> ==>  as above
-       <bundle>   ==>  prof (profiling)
-                       conc (concurrent Haskell)
-                       par  (parallel)
-                       gran (GranSim parallel simulator)
-                       ticky (`ticky-ticky' counts -- for implementors)
-                       prof-conc (profiling for "conc[urrent]")
-                       prof-ticky (ticky for "conc[urrent]")
-
-ghc-0.26-hc-files.tar.gz Basic set of intermediate C (.hc) files for the
-                        compiler proper, the prelude, and `Hello,
-                        world'.  Used for bootstrapping the system.
-                        About 4MB.
-
-ghc-0.26-<bundle>-hc-files.tar.gz Further sets of .hc files, for
-                       building other "bundles", e.g., profiling.
-
-ghc-0.26-hi-files-<blah>.tar.gz Sometimes it's more convenient to
-                       use a different set of interface files than
-                       the ones in *-src.tar.gz.  (The installation
-                       guide will advise you of this.)
-
-We could provide diffs from previous versions of GHC, should you
-require them.  A full set would be very large (7MB).
diff --git a/ghc/docs/ANNOUNCE-0.27 b/ghc/docs/ANNOUNCE-0.27
deleted file mode 100644 (file)
index 843b3e2..0000000
+++ /dev/null
@@ -1,72 +0,0 @@
-A binary-only from-working-sources no-guarantees snapshot of the
-Glasgow Haskell compiler (GHC) for i386-unknown-linuxaout and
-i386-unknown-solaris2 platforms is now available from
-ftp://ftp.dcs.glasgow.ac.uk/pub/haskell/glasgow/ghc-0.27-<platform>.tar.gz.
-(The files ghc-0.26-docs-and-examples.tar.gz and
-ghc-0.26-ps-docs.tar.gz [PostScript] may also be of interest.)
-
-This pseudo-release adds profiling and concurrent-Haskell support for
-i386-*-linuxaout.  It is the first GHC that works on i386-*-solaris2
-machines (sequential, profiling, and concurrent support provided).
-
-As 0.27 is a snapshot and not a "proper" release, it may have serious,
-show-stopping bugs in it.  If you *need* what 0.27 provides, use it;
-otherwise, you should stick with 0.26.
-
-It should be relatively straightforward to tweak
-ghc/driver/ghc-asm.(l)prl to support Linux ELF format; ditto for other
-Unices on x86 platforms.  Please let us know if you make such changes.
-
-GCC 2.7.x is required; GCC 2.6.x will *not* work.
-
-Binaries (.o files and executables) produced by GHC 0.27 cannot be
-intermixed with those from GHC 0.26 or 0.25; you'll need to recompile
-everything.
-
-The -concurrent stuff *definitely* has at least one bug we haven't
-been able to catch.  Concurrent programs that show
-readily-reproducible buggy behavior would be most welcome.
-
-The profiling libraries for *solaris2 are huge, for reasons we don't
-understand.  If you need to scrap them for space reasons, see the end
-of the installation notes below.  Insights into the problem would also
-be most appreciated.
-
-Please report any bugs to glasgow-haskell-bugs@dcs.glasgow.ac.uk.
-
-Will Partain
-AQUA project (slave)
-
-Dated: 95/12/20
-
-=== INSTALLATION NOTES ==============================================
-
-Ignore the installation instructions in any documentation.  This is
-the stuff that applies for this distribution.
-
-Unpack the distribution.
-
-Move "ghc-0.27-<platform>" to wherever you like.
-
-Make a link to ghc-0.27-<platform>/ghc/driver/ghc, so that "ghc" will
-be in your PATH.
-
-Change the hardwired paths in ghc/driver/ghc and in
-ghc/utils/hscpp/hscpp to point to where things are on your system.
-(Also: ghc/utils/mkdependHS/mkdependHS, if you want to use it.)
-Notably: where "perl" is (first line of each script), where $TopPwd is
-(ghc script), where your gcc cpp ($OrigCpp) is (hscpp and mkdependHS
-scripts).  *Don't* set any environment variables to do this.
-
-GHC should then work.  Try "ghc -v" on something simple, to make sure
-it compiles and links a program correctly.
-
-If you don't want the profiling libraries (e.g., to save disk space), do:
-
-    cd ghc
-    rm runtime/*_p.a lib/*_p.a
-
-If you don't want to concurrent-Haskell libraries (e.g., same reason), do:
-
-    cd ghc
-    rm runtime/*_mc.a lib/*_mc.a
index 9e9510c..ca56ede 100644 (file)
@@ -7,15 +7,7 @@
 #define NoInstallTargetForSubdirs
 #define NoTagTargetForSubdirs
 
-SUBDIRS = add_to_compiler      \
-         users_guide           \
+SUBDIRS = users_guide          \
          install_guide         \
          release_notes         \
          state_interface
-
-XCOMM    developers_guide ?
-XCOMM    interfaces ?
-XCOMM    pragmas ?
-
-XCOMM grasp_overview ?
-XCOMM style_guide ?
diff --git a/ghc/docs/NOTES.adding-PrimOp b/ghc/docs/NOTES.adding-PrimOp
deleted file mode 100644 (file)
index 2d5b475..0000000
+++ /dev/null
@@ -1,51 +0,0 @@
-This is a short note describing how I (ADR <areid@dcs.glasgow.ac.uk>)
-added a new primitive operation (makeStablePtr#) to the compiler. It
-serves as documentation of what I did and as a guide to anyone else
-wanting to try it.
-
-1) Change compiler/prelude/PrimOps.lhs:
-
-   - add @MakeStablePtrOp@ to the datatype @PrimitiveOp@.
-
-   - add the following case to @primOpInfo@
-
-       primOpInfo MakeStablePtrOp
-         = AlgResult "makeStablePtr#" []
-       [(ioWorldTy `UniFun` intPrimAndIoWorldTy), ioWorldTy]
-       intPrimAndIoWorldTyCon  []
-    -- makeStablePtr# :: IO_Int# -> IO_Int#
-    -- == makeStablePtr# :: (IoWorld -> (Int#, IoWorld)) -> (IoWorld -> (Int#, IoWorld))
-
-2) Change compiler/prelude/AbsPrel.lhs:
-
-   - add @MakeStablePtrOp@ to an appropriate place in @list_of_val_assoc_lists@
-
-     (This makes the operation visible to the programmer).
-
-     Since this is a glasgow extension, I added it to one of
-     @extra_known_vals_2@, @unboxed_ops@, @boxed_ops@. @unboxed_ops@
-     is made up of several lists of operators including
-     @prim_ops_used_unboxed_only@. By inspection I decided that this
-     (@prim_ops_used_unboxed_only@) was the one to go for.
-
-At this point I started recompiling the compiler - this took a long
-time since the change to @PrimitiveOp@ changed the @.hi@ file
-resulting in a complete (or near as makes no odds) recmpilation of the
-compiler. (Is there a way of using fastmake that avoids this?
-
-3) Change imports/StgMacros.lh to generate code for @MakeStablePtr#@
-
-   - this is just adding a macro that calls the appropriate operation.
-
-   (I suspect I could omit this step if I wanted since all this does
-   (ahem, will do) is call a function in the runtime system.)
-
-4) Change runtime/storage/SMap.lc to implement the new operation.
-
-   I won't bother describing this just now.
-
-
-This is a little untidy. I should perhaps add a new flag to the system
-which turns my extension off and checks that it is only used in
-conjunction with the Appel generational collector. But we're going to
-do the same to every collector eventually aren't we?
diff --git a/ghc/docs/NOTES.arbitary-ints b/ghc/docs/NOTES.arbitary-ints
deleted file mode 100644 (file)
index 964a2cf..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-
-Boxed structure of BigInts
-
-
----->  Info1   Pointer
-               |               Pointer passed to BigNum package
-               |               |
-               \/              \/
-               Info2   Size    Integer ....
-
-                       (size excludes info ptr & size field)
-
-Unboxed (Compiler must place on pointer stack not data stack
-        Must also tell GC if it is in a register when GC invoked)
-
----->  Info2   Size    Integer
-
-
-
-Info1:
-       SPEC_INFO_TABLE(Info1, BigNum_entry, 1, 1);     (Min Size 2 ?)
-
-       Entering this returns the BigNum using agreed return convention
-
-Info2:
-       DATA_INFO_TABLE(Info2, Dummy_entry);
-
-       This never actually entered -- just required for GC.
-
-------------------------------------------------------------------------------
-
-Boxed structure of BigInts (the alternative one)
-
-                       Pointer passed to BigNum package
-                       |
-                       \/
----->  Info    Size    Integer ....
-
-               (size excludes info ptr & size field)
-
-Unboxed (Compiler must place on pointer stack not data stack
-        Must also tell GC if it is in a register when GC invoked)
-
-
-Info:
-       DATA_INFO_TABLE(Info, BigNum_entry);
-
-       Entering this returns the BigNum using agreed return convention
-
-
-
-Note that the Boxed and Unboxed representation are identical !!!
-
-(unboxing represents evaluationhood, not pointerhood)
diff --git a/ghc/docs/NOTES.c-optimisation b/ghc/docs/NOTES.c-optimisation
deleted file mode 100644 (file)
index 3320ae1..0000000
+++ /dev/null
@@ -1,2361 +0,0 @@
-Optimisation of C-code (runtime and compiled)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- Placing of STG registers in machine registers
-- Optimisation of interpreter loop (tail calls)
-
-/* TODO: flags */
--OC flag to ghc causes optimisation
-
-
-ANSI C
-~~~~~~
-For functions with no args we declare them as 
-
-       foo( STG_NO_ARGS )
-
-rather than foo(), because you can tell ANSI C a little more
-by making STG_NO_ARGS expand to void.  Maybe something to do with
-forward declarations?
-
-
-Optimisation with GCC
-~~~~~~~~~~~~~~~~~~~~~
-
-We are concentrating most optimisation with gcc which allows
-suitable global register declarations.
-
-
-REGISTERS:
-
-See StgOpt.h for a description of register usage
-
-Note that all modules that reference the STG registers must be
-compiled the same way so they look at the registers and not the
-global variables.
-
-
-TAIL CALLS:
-
-Seperate modules for tail call optimisations are required.
-Requitre to partition runtime system code.
-
-.hc:
-       Modules with tail call routines (most runtime and all compiled)
-       are labeled .hc (literate = .lhc).
-       These are compiled to assember with tail call optimisation on
-       and then post processed with sed (Yuk!)
-
-       All routines which return a continuation (STGJUMP) must be
-       compiled this way. 
-
-       (The only exeption to this is continuations which exit/abort which
-        may live in .c files)
-
-.c:
-       These modules are not compiled with the tail call optimisation
-       and don't have sed processing. 
-       Sed processing would destroy the code!
-
-       All routines which are not continuations (called and return
-       conventionally) must be compiled this way.
-
-       This includes various parts of the runtime system.
-
-
-
-
-See Also  ~sansom/work/gcstats/OBSERVATIONS
-
-
-
-
-Info Recieved from Eliot Miranda:
-
-Received: from dcs.glasgow.ac.uk (tutuila) by vanuata.dcs.glasgow.ac.uk; Thu, 4 Jul 91 09:40:34 BST
-Message-Id: <15456.9107040841@dcs.glasgow.ac.uk>
-X-Comment1: #############################################################
-X-Comment2: #     uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs     #
-X-Comment3: #     If this address does not work please ask your mail    #
-X-Comment4: #     administrator to update your NRS & mailer tables.     #
-X-Comment5: #############################################################
-To: simonpj
-Cc: sansom
-Subject: Miranda's original msg
-Date: Thu, 04 Jul 91 09:41:19 +0100
-From: Simon L Peyton Jones <simonpj>
-
-
-
-
-
->From eliot@.cs.qmw.ac.uk Mon Apr  1 11:16:06 1991
-From: eliot@.cs.qmw.ac.uk (Eliot Miranda)
-Newsgroups: comp.compilers
-Subject: Portable Fast Direct Threaded Code
-Keywords: interpreter, design
-Date: 28 Mar 91 12:20:06 GMT
-Reply-To: Eliot Miranda <eliot@.cs.qmw.ac.uk>
-Organization: Computer Science Dept, QMW, University of London, UK.
-
-Various people have asked me for details on how I do threaded code
-in my dynamic translation Smalltalk-80 VM. So here's the gory details
-as well as the first published benchmarks for the system.
-
-       How to do "Machine-Independent" Fast Direct Threaded Code:
-
-
-First off, use C (although other flexible machine-oriented imperative
-languages would probably work too).
-
-Global registers:
-       If you can use GCC >v1.33 you can use global register variables to
-hold the threaded code machine's registers.  If you have various forms of
-stupid C compiler then you can get global register variables by declaring
-your globals as register variables in every function, and later editing the
-assembler generated by the C compiler to remove global register saves &
-restores (details in [Miranda]).
-
-
-Threaded Code:
-       Threaded code instructions (TCIs) are written as C procedures. 
-They are compiled to assembler by the C compiler.  Subsequently a simple
-editor script is run on the assembler to remove the prologues and epilogues
-from the threaded code procedures, and possibly to insert direct threaded
-code jumps.
-
-How to Identify Threaded Code Instructions:
-       The method I prefer is to segregate TCIs from other procedures &
-functions in the machine by placing related groups of TCIs in separate
-source files.   I give my threaded code source files the .tc extension and
-they have a rule in the makefile that will run the editor script on the
-assembler.  An alternative is to identify each threaded code procedure with
-a special prefix which is spotted by the editor script.  This is probably
-more error prone & doesn't fit well with leaf-routine optimization (see
-below).
-
-How to Write Threaded Code Instructions:
-Each TCI is writen an a void function of no arguments.  It is wise to start
-and end each TCI with two special macros to replace '{' and '}'.  So, using
-GCC on the SPARC, given some declarations:
-
-
-       typedef void    (*TCODE)(); /* a TCODE is a pointer to a function */
-       typedef ????    ObjectPointer;
-
-       . . .
-
-       register TCODE  *tcip asm("%g7"); /*threaded code instruction pointer*/
-       register ObjectPointer  *stackPointer asm("%g5");
-
-e.g. popStack would be written:
-
-       void    popStack()
-       TBEGIN
-               stackPointer--;
-       TEND
-
-With GCC TBEGIN is
-
-       #define TBEGIN {
-
-With stupid C compilers it can be defined to be the list of global register
-variables.  Further, if you want to build a debuger for your threaded code
-machine you could compile the system with
-
-       #define TBEGIN { int frig = checkForBreakPoint();
-
-and ignore lots of warnings about variable frig being unused :-).
-
-TEND has to do a direct threaded code jump. In my system I want an indirect
-post-increment jump on tcip; i.e. jump to *tcip++.  On the SPARC with tcip
-in %g7 the jump is
-
-       ld [%g7],%o0            ! get *tcip
-       jmpl %o0,%g0            ! jump to it
-       add %g7,4,%g7           ! increment tcip in the jump's delay slot
-
-On the 68k with tcip in a5 the jump is
-
-       movl a5@+,a0
-       jmp a0@
-
-With GCC this is implemented by the JUMPNEXT macro. On the SPARC:
-       #define JUMPNEXT do{ \
-               asm("ld [%g7],%o0; jmpl %o0,%g0; add %g7,4,%g7");\
-               return;}while(0)
-
-Note the return, it tells the compiler that control does not pass this point.
-On the 68k:
-       /* SBD = Silent But Deadly = Stack Bug Dummy. gcc has a bug with
-          no-defer-pop. it always depers the pop of the last function call in
-          a routine. SBD is a dummy call to ensure no other previous call gets
-          its pop deferred.
-        */
-       extern  void    SBD P((void));
-
-       #define JUMPNEXT do{ \
-               asm("movl a5@+,a0; jmp a0@");\
-               SBD();return;}while(0)
-
-SBD is then removed by the editor script.
-
-So TEND is defined to be
-       #define TEND JUMPNEXT; }
-
-On the SPARC popStack is expanded to
-       void    popStack()
-       {
-               stackPointer--;
-               do{asm("ld [%g7],%o0; jmpl %o0,%g0; add
-%g7,4,%g7");return;}while(0);
-       }
-
-Its compiled to:
-       _popStack:
-               !#PROLOGUE# 0
-               save %sp,-80,%sp
-               !#PROLOGUE# 1
-               add %g5,-4,%g5
-               ld [%g7],%o0; jmpl %o0,%g0; add %g7,4,%g7
-               ret
-               restore
-The editor script then reduces this to:`
-       _popStack:
-               ! [gotcher]
-               add %g5,-4,%g5
-               ld [%g7],%o0; jmpl %o0,%g0; add %g7,4,%g7
-
-On the 68k you end up with:
-       .globl _popStack
-       _popStack:
-               subqw #4,a3
-               movl a5@+,a0; jmp a0@
-
-Global Register Variables and Stupid C Compilers:
-       Some C compilers are stupid enough to provide straight-forward global
-registers.  A C compiler on a nat-semi based system I used just allocated
-registers in the order they were declared.  The assembler syntax was very
-simple to edit.  Global register variables could thus be obtained easily.
-
-       Some C compilers are stupid but think they're clever.  Sun's SUN3
-compiler is a case in point. It also allocates registers in the order declared.
-However, it tries to be clever by removing 'dead assignments' (assignments to
-subsequently unused register variables).  These compilers are easy to fool.
-Simply arrange that the register variables are always used before leaving a
-function.  I do this by always writing RETURN or RETURNV(e) instead of
-return and return e.  On systems with such stupid C compilers RETURN(e)
-is defined thus:
-
-       #define RETURNV(e) do{DummyUseRegs(GR1,GR2,GR3); return e;}while(1)
-
-The call on DummyUseRegs fools the compiler into thinking the registers
-are live & hence saves assignments to them.  The editor scripts can then
-remove calls on DumyUseRegs.
-
-       Of course on systems with marginally clever C compilers (SUN4
-HP-UX etc)
-you're stuffed.  However, in clever C compilers like GCC and Acorn's C compiler
-you can declare global registers & everything is clean & wholesome :-).
-
-
-
-Conditional TCODE Jumps:
-       Say we wanted a conditional tcode jump. This might be writen:
-       void    skipIfTrue()
-       TBEGIN
-               if (*stackPointer-- == TrueObject) {
-                       tcip += 1;
-                       JUMPNEXT;
-               }
-       TEND
-
-How this All Works:
-With the above scheme, each threaded code procedure runs in the same C
-stack frame, and jumps directly to the next procedure, eliminating an
-unnecessary <epilogue, return>, <call, prolog> pair.  Once we establish a
-stack frame and call the first function away we go.  Assuming that you've
-produced your first threaded code method (a sequence of pointers to
-threaded code procedures), and that tcip points at the start, then
-StartTCMachine might be defined as follows:
-
-       volatile        void
-       StartTCMachine()
-       {       char    *enoughSpaceForAllTCIStackFrames;
-
-               enoughSpaceForAllTCIStackFrames = alloca(1024);
-
-               while(1) { (*tcip++)(); }
-       }
-
-The alloca allocates space on the stack. After the first (*tcip++)()
-control goes off into threaded code land and never returns.
-
-Leaf Routine Optimization:
-The threaded code machine will make calls on support routines e.g.
-graphics, garbage collector etc.  Any group of routines that dont access
-the global registers and don't directly or indirectly call routines that
-need to access the global registers can be optimized.  These routines
-should be compiled without declaring the global registers.  These routines
-will then use as many registers as the compiler will give them and will
-save & restore any registers they use, preserving the values of the global
-register variables.
-
-
-Details of my Smalltalk Threaded Code Machine:
-       I use a pair of words for each TCI, a pointer to the procedure followed
-by an optional operand.  This avoids going out of line to access arguments.
-e.g. pushLiteral is:
-       void    pushLit()
-       TBEGIN
-               *++stackPointer = (OOP)*tcip++;
-       TEND
-where OOP is an ordinary object pointer. So on entry to push lit we have:
-               <pointer to pushLit>
-       tcip->  <object pointer>
-               <pointer to next TCI>
-               <next TCI's operand>
-and popStack must therefore be written
-       void    popStack()
-       TBEGIN
-               stackPointer--;
-               tcip++;
-       TEND
-
-I dynamically compile Smalltalk-80 bytecodes to threaded code.  I use 128k
-bytes of memory to hold all threaded code. This 'tspace' is periodically
-scavenged to reclaim space.  The architecture is similar to
-[DeutschSchiffman].  Using an eighth of the space used by the Deutch
-Schifman machine I get around 75% of the performance on the non-graphics
-benchmarks.  Here are the Smalltalk macro benchmarks for BrouHaHa
-Smalltalk-80 v2.3.2t running on a monochrome SUN3/60 (20MHz 68020):
-
-       BitBLT                  76.7308
-       TextScanning            222.857
-       ClassOrganizer          80.6667
-       PrintDefinition         59.0278
-       PrintHierachy           142.857
-       AllCallsOn              112.5
-       AllImplementors         130.0
-       Inspect                 116.667
-       Compiler                86.4341
-       Decompiler              101.639
-       KeyboardLookAhead       212.5
-       KeyboardSingle          302.778
-       TextDisplay             148.837
-       TextFormatting          273.81
-       TextEditing             180.342
-       Performance Rating      134.198
-
-and on the same machine under the same conditions are the timings for
-ParcPlace Smalltalk-80 V2.3:
-
-       BitBLT                  99.75
-       TextScanning            390.0
-       ClassOrganizer          155.128
-       PrintDefinition         137.097
-       PrintHierachy           192.308
-       AllCallsOn              120.0
-       AllImplementors         108.333
-       Inspect                 146.774
-       Compiler                118.617
-       Decompiler              129.167
-       KeyboardLookAhead       303.571
-       KeyboardSingle          473.913
-       TextDisplay             172.973
-       TextFormatting          442.308
-       TextEditing             285.135
-       Performance Rating      189.504
-
-134.198/189.504 = 0.708154
-
-WARNING!! These systems ARE different, these benchmarks are included only
-to give a feeling for ball-park performance.
-Example differences:
-       BrouHaHa                                ParcPlace
-       closures                                blue-book BlockContexts
-       immediates:
-         characters, smallints, fixedpoints    immediate smallintegers
-       5844 compiled methods                   5136 compiled methods
-       (5026 ordinary methods)                 (4798 ordinary methods)
-       (818 quick methods)                     (338 quick methods)
-
-
-
-More Portable File Organization:
-To keep the code as clean looking as possible all machine-dependencies are
-isolated in separate files.  e.g. tcode.h gives machine independent
-definitions for TCODE. It includes machine dependencies from another file:
-
-       /* for debugging purposes; single step breakpoint at start of
-each tcode
-        */
-       #define DEBUG_FETCH_BREAK int frig = fetchBrk();
-
-       #ifdef FAST
-       #   include "fasttcode.h"
-       #else
-
-       TCODE   *tcip;          /* the tcode ip points at TCODEs */
-
-       #   define JUMPNEXT return
-       #   ifdef BIDebug
-       #       define TBEGIN { DEBUG_FETCH_BREAK
-       #   else
-       #       define TBEGIN {
-       #   endif
-       #   define TEND }
-       #endif
-
-GCC/SPARC/fasttcode.h:
-       /* tcodeip in g7 */
-       register TCODE  *tcip asm("%g7");
-
-       #define JUMPNEXT do{asm("ld [%g7],%o0; jmpl %o0,%g0; add
-%g7,4,%g7");return;}while(0)
-
-       #ifdef BIDebug
-       #   define TBEGIN { DEBUG_FETCH_BREAK
-       #else
-       #   define TBEGIN {
-       #endif
-       #define TEND JUMPNEXT; }
-
-I also don't want to include the necessary definitions for the global registers
-in every file. So for those non-leaf routines that must avoid using the
-global registers there's a fastglobal.h file that gives dummy definitions for
-these registers. e.g. GCC/SPARC/fastglobal.h:
-       /* machine specific FAST defines.
-          Gnu C 1.33 systems can use nice compiler provided global registers.
-        */
-
-       #define BEGIN {
-       #define END }
-       #define RETURN(e) return e
-       #define RETURNV return
-
-       register char   *GlobRegDummy1 asm("a5");
-       register char   *GlobRegDummy2 asm("a4");
-       register char   *GlobRegDummy3 asm("a3");
-       register char   *GlobRegDummy4 asm("d6");
-
-       #ifdef MASKREGISTER
-       register char   *GlobRegDummy5 asm("d7");
-       #endif
-
-I use symbolic links to set up the machine dependent include files.
-This has the
-advantage that if you add a new machine you don't have to remake all
-the others.
-
-
-The Tedious Bit:
-The only tedious bit is writing the sed-scripts. For the SPARC this took 1 day.
-Here are the sed scripts I use for SUN 3, MAC2AUX (using GAS) and SUN4,
-all using GCC (v1.33 upwards). There's a problem on the SPARC in that the ABI
-does not seem to define the status of the global registers.  Some math and
-library routines stomp on the global registers (beware getwd!), so I've
-included
-GCC/SUN4/sed.globreg.bugfix as an example of how to spot the offending math
-routines:
-
-SUN3/GCC/lib/sed.tcode.opt:
-# script to strip prolog & epilog from threaded code under gcc.
-# WARNING the script may strip a push of a register argument if a call is the
-# first statement of a function!!
-#
-/^_.*:$/{n
-N
-N
-s/     link a6,#[^\n]*\n//
-/      fmovem #[^\n]*,sp@-/{
-N
-s/     fmovem #[^\n]*,sp@-\n//
-}
-s/     moveml .*,sp@-\n//
-s/     movel [ad][0-7],sp@-\n//
-}
-/      moveml a6@(-[1-9][0-9]*),#/{N
-s/     moveml a6@(-[1-9][0-9]*),#[^\n]*\n      unlk a6//
-}
-/      movel a6@(-[1-9][0-9]*),[ad][0-7]/{N
-s/     movel a6@(-[1-9][0-9]*),[ad][0-7]\n     unlk a6//
-}
-/      movel sp@+,/d
-/      moveml sp@+,#/d
-/      unlk a6/d
-/      rts/d
-/      jbsr _SBD/d
-
-MAC2AUX/GCC/lib.gas/sed.tcode.opt:
-/COMMENT/{
-i\
-       script to strip prolog & epilog from threaded code under gcc. WARNING \
-       the script may strip a push of a register argument if a call is the\
-       first statement of a function!!
-}
-/^gcc_compiled:/d
-/^.[^%].*:$/{ n
-/      link %a6/{
-N
-N
-s/     link %a6,#[x0-9-]*\n//
-/      fmovem #[^\n]*,%sp@-/{
-N
-s/     fmovem #[^\n]*,%sp@-\n//
-}
-s/     moveml #[x0-9a-f]*,%sp@-\n//
-s/     movel %[ad][0-7],%sp@-\n//
-n
-}
-}
-/      moveml -[1-9][0-9]*%a6@,#/{ N
-s/     moveml -[1-9][0-9]*%a6@,#[x0-9a-f-]*\n  unlk %a6//
-}
-/      movel -[1-9][0-9]*%a6@,%[ad][0-7]/{ N
-s/     movel -[1-9][0-9]*%a6@,%[ad][0-7]\n     unlk %a6//
-}
-/      movel %sp@+,%/d
-/      moveml %sp@+,#/d
-/      movel %d0,%a0/{
-N
-s/     movel %d0,%a0\n unlk %a6//
-/      movem*l %a6/{
-N
-s/     movel %d0,%a0\n movem*l %a6.*\n unlk %a6//
-/      fmovem %a6/{
-N
-s/     movel %d0,%a0\n movem*l %a6.*\n fmovem %a6.*\n  unlk %a6//
-}
-}
-}
-/      unlk %a6/d
-/      rts/d
-/      jbsr SBD/d
-
-
-SUN4/GCC/lib/sed.tcode.opt:
-# script to strip prolog & epilog from threaded code under gcc.
-#
-/^_.*:$/{n
-N
-N
-s/     !#PROLOGUE# 0\n save %sp,[-0-9]*,%sp\n  !#PROLOGUE# 1/  ! [gotcher]/
-}
-/      ret/d
-/      restore/d
-
-SUN4/GCC/lib/sed.globreg.bugfix:
-# Some of the libc builtin routines (.rem .urem .div & .udiv so far known)
-# stamp on %g3 which is the maskReg (it contains 0x7FFFFF).
-# This script reassigns the value of maskReg after each of these routines
-# has been called.
-/call[         ]\.div,[0-9]/{n
-n
-i\
-       sethi %hi(0x7FFFFF),%g3 ![globregfix]\
-       or %lo(0x7FFFFF),%g3,%g3
-}
-/call[         ]\.udiv,[0-9]/{n
-n
-i\
-       sethi %hi(0x7FFFFF),%g3 ![globregfix]\
-       or %lo(0x7FFFFF),%g3,%g3
-}
-/call[         ]\.rem,[0-9]/{n
-n
-i\
-       sethi %hi(0x7FFFFF),%g3 ![globregfix]\
-       or %lo(0x7FFFFF),%g3,%g3
-}
-/call[         ]\.urem,[0-9]/{n
-n
-i\
-       sethi %hi(0x7FFFFF),%g3 ![globregfix]\
-       or %lo(0x7FFFFF),%g3,%g3
-}
-
-
-You can now see why I put "Machine-Independent" in quotes.  Here's the count
-of machine dependent code for the SPARC:
-
-        25      99     786 fastcache.h
-        68     262    1882 fastglobal.h
-        31     112     906 fasttcode.h
-        28      80     595 ../tcsrc/SUN4/GCC/lib/sed.globreg.bugfix
-         5      34     222 ../tcsrc/SUN4/GCC/lib/sed.peep.opt
-         9      30     173 ../tcsrc/SUN4/GCC/lib/sed.tcode.opt
-       166     617    4564 total
-
-Of these 166 lines 51 lines are banner headers. 100 odd lines are
-machine dependent.  A whole VM is around the 20k lines mark. So
-machine dependencies are down in the 0.5% range.
-
-
-
-Use this stuff as part of what ever you like.  If you try & assert ownership
-I'll fight & batter you over the head with the GPL ('bout time we had some
-serious steel in that thar GPL).
-
-Share And Enjoy!
-
-P.S. The BrouHaHa machine is available to educational institutions with a
-valid ParcPlace Smalltalk-80 licence, subject to a strict non-disclosure
-agreement.  email me if you want it. I am slow to answer requests!
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From crowl@cs.rochester.edu Tue Apr  2 10:34:53 1991
-From: crowl@cs.rochester.edu (Lawrence Crowl)
-Newsgroups: comp.compilers
-Subject: Re: Portable Fast Direct Threaded Code
-Keywords: interpreter, design
-Date: 31 Mar 91 18:06:35 GMT
-Reply-To: crowl@cs.rochester.edu (Lawrence Crowl)
-Organization: Computer Science Department University of Rochester
-
-In article <3035@redstar.cs.qmw.ac.uk>
-Eliot Miranda <eliot@.cs.qmw.ac.uk> writes:
->The threaded code machine will make calls on support routines, e.g. graphics,
->garbage collector etc.  Any group of routines that don't access the global
->registers and don't directly or indirectly call routines that need to access
->the global registers can be optimized.  These routines should be compiled
->without declaring the global registers.  These routines will then use as many
->registers as the compiler will give them and will save & restore any
->registers they use, preserving the values of the global register variables.
-
-This scheme assumes that procedure calls use a "callee saves" register
-convention, and does not work if you allocate the global register
-variables out of the "caller saves" set of registers.  The problem is that
-the caller does not save the register (because it is global) and the
-callee writes over the register (because the caller saved it).  In this
-situation, the programmer must insert explicit saves and restores of the
-global register variables.
-
-The obvious solution to this problem is to allocate all global register
-variables out of the "callee saves" set of registers.  However, the
-Alliant has _no_ callee saves registers.  Library routines on the Alliant
-will trash every register you have.  In addition, implicit library calls
-to routines like bcopy will also trash your registers.  (I learned this
-the hard way.)
-
-The lesson is that calling library routines with global register variables in
-caller saves registers requires special handling.  It is not automagic.
--- 
-  Lawrence Crowl               716-275-9499   University of Rochester
-                     crowl@cs.rochester.edu   Computer Science Department
-                ...!rutgers!rochester!crowl   Rochester, New York, 14627-0226
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From Tom.Lane@G.GP.CS.CMU.EDU Wed Apr  3 10:38:09 1991
-From: Tom.Lane@G.GP.CS.CMU.EDU
-Newsgroups: comp.compilers
-Subject: Re: Portable Fast Direct Threaded Code
-Keywords: interpreter, design
-Date: 1 Apr 91 15:21:14 GMT
-Reply-To: Tom.Lane@G.GP.CS.CMU.EDU
-Organization: Compilers Central
-
-Lawrence Crowl points out one important problem with Eliot Miranda's
-scheme for global register use in C.  There's an even more fundamental
-problem, though: there is *no guarantee whatever* that the compiler will
-assign the same registers to the global variables in every routine.
-
-Compilers that do intelligent allocation of variables to registers may
-refuse to honor the "register" declarations at all if the global variables
-are not heavily used in a given routine, and in any case the globals need
-not be assigned to the same registers every time.  Miranda's scheme thus
-relies heavily on the assumption of a dumb register allocator (or else a
-compiler that supports global register variable declarations).
-
-This scheme may be "fast" direct threaded code, but it's hardly "portable".
--- 
-                       tom lane
-Internet: tgl@cs.cmu.edu       BITNET: tgl%cs.cmu.edu@cmuccvma
-[GCC lets you specify what register to use for global register variables, but
-that is of course both machine and compiler specific. -John]
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From pardo@cs.washington.edu Thu Apr  4 17:34:39 1991
-From: pardo@cs.washington.edu (David Keppel)
-Newsgroups: comp.compilers
-Subject: Re: Portable Fast Direct Threaded Code
-Keywords: interpreter, design, bibliography
-Date: 2 Apr 91 19:21:25 GMT
-Reply-To: pardo@cs.washington.edu (David Keppel)
-Organization: Computer Science & Engineering, U. of Washington, Seattle
-
-metzger@watson.ibm.com (Perry E. Metzger) writes:
->[I'd like a reference on threaded code interpreters.]
-
-3 citations follow:
-
-%A James R. Bell
-%T Threaded Code
-%J Communications of the ACM (CACM)
-%V 16
-%N 2
-%D June 1973
-%P 370-372
-%X Describes the basic idea of threaded code.
-Compares to hard code (subroutine calls) and interpreters.
-
-%A Richard H. Eckhouse Jr.
-%A L. Robert Morris
-%T Minicomputer Systems  Organization, Programming, and Applications
-(PDP-11).  2nd Ed.
-%I Prentice-Hall, Inc.
-%P 290-298
-%X Describes threaded code and ``knotted code''.  I (pardo) think that
-this is a very clear introduction to threaded code.
-
-%A Peter M. Kogge
-%T An Architectural Trail to Threaded Code Systems
-%J IEEE Computer
-%P 22-33
-%D March 1982
-%W rrh (original)
-%W Pardo (copy)
-%X Describes how to build a threaded code interpeter/compiler from
-scratch.
- * Direct threaded/indirect threaded.
- * Less than 2:1 performance hit of threading compared to full
-compilation.
- * Note about bad compilers contributing to relative OK-ness of
-threaded code.
- * Ease of rewriting stuff.
- * Ease of tuning.
-
-My favorite of the three is Eckhouse & Morris; however I don't know
-where to get it.  The pages that I have are photocopies graciously
-sent to me by a friend.  As the title implies, this book is several
-years old and undoubtedly out-of-print.
-
-       ;-D on  ( Following this thread of the discussion... )  Pardo
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From simonpj Fri Apr  5 09:52:33 1991
-Received: from tutuila.dcs.glasgow.ac.uk by vanuata.cs.glasgow.ac.uk;
-Fri, 5 Apr 91 09:52:27 BST
-Message-Id: <2763.9104050851@tutuila.dcs.glasgow.ac.uk>
-X-Comment1: #############################################################
-X-Comment2: #     uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs     #
-X-Comment3: #     If this address does not work please ask your mail    #
-X-Comment4: #     administrator to update your NRS & mailer tables.     #
-X-Comment5: #############################################################
-From: Simon L Peyton Jones <simonpj>
-To: eliot@cs.qmw.ac.uk
-Cc: simonpj, partain
-Subject: Threaded code
-Date: Fri, 05 Apr 91 09:51:48 +0100
-
-
-Eliot 
-
-I saw your article about threaded code.  Like you and others, we are
-using C as an assembler, only for a pure functional language, Haskell.
-I have some brief questions.
-
-1. By telling GCC not to use a frame pointer, one can eliminate
-the prolog entirely, can't one?  So why edit it out?
-
-I guess the answer is going to be local variables, allocated once for
-all by the StartTCMachine routine.  Still, it seems quite a pain.  I guess
-one could sacrifice some (perhaps slight) speed by using a bunch of
-globals instead.
-
-2. You edit out the epilogue for tidiness only, I take it.  It doesn't
-cause any problems if you leave it in, does it?
-
-3. Why do you use no-defer-pop (with the associated bug)?
-
-4. Why does JUMPNEXT have a loop?  Surely the jump leaves the loop right
-away.  Presumably you are tricking the compiler somehow.
-
-Thanks
-
-Simon L Peyton Jones
-Glasgow University
-
-
-
-
-Simon
-============================= Address change =======================
-My email address is now officially:  simonpj@dcs.glasgow.ac.uk
-This may fail if your local site has out-of-date mail tables.
-The old address (simonpj@cs.glasgow.ac.uk) will work for quite a long while, 
-so stay with the old one if the new one fails.
-====================================================================
-
->From eliot@cs.qmw.ac.uk Fri Apr  5 12:18:18 1991
-Via: uk.ac.qmw.cs; Fri, 5 Apr 91 12:18:06 BST
-Received: from aux47 by redstar.cs.qmw.ac.uk id aa26828; 5 Apr 91 12:17 BST
-Reply-To: eliot@cs.qmw.ac.uk
-In-Reply-To: Simon L Peyton Jones's mail message
-<2763.9104050851@tutuila.dcs.glasgow.ac.uk>
-Message-Id:  <9104051217.aa26828@uk.ac.qmw.cs.redstar>
-From: Eliot Miranda <eliot@cs.qmw.ac.uk>
-To: simonpj
-Cc: partain
-Subject:  re: Threaded code
-Date:     Fri, 5 Apr 91 10:54:25 BST
-
->
->Eliot 
->
->I saw your article about threaded code.  Like you and others, we are
->using C as an assembler, only for a pure functional language, Haskell.
->I have some brief questions.
->
->1. By telling GCC not to use a frame pointer, one can eliminate
->the prolog entirely, can't one?  So why edit it out?
-No, registers local to the procedure will still be saved & stack space
-allocated for automatic variables. This IS a problem since the
-threaded-code jump at the end of the procedure will miss the register
-restores before the epilogue.  Consequently the stack will grow unless
-these register saves & stack-space allocations are removed.
->
->I guess the answer is going to be local variables, allocated once for
->all by the StartTCMachine routine.  Still, it seems quite a pain.  I guess
->one could sacrifice some (perhaps slight) speed by using a bunch of
->globals instead.
-For certain routines, not using register variables will be expensive
-(e.g. a simple integer arithmetic primitive).
->
->2. You edit out the epilogue for tidiness only, I take it.  It doesn't
->cause any problems if you leave it in, does it?
-No, but given that the prologue has to be removed & removing the epilogue
-is as easy (& given finite memory :-) one might as well remove it.
->
->3. Why do you use no-defer-pop (with the associated bug)?
-OK. This is again to avoid stack growth.  On conventional stack architectures
-gcc will try & combine the argument popping code of a sequence of
-procedure calls.
-e.g.
-extern long a, b, c;
-void doit() {
-       foo(a); bar(b); baz(c);
-}
-
-with -O -no-defer-pop one might expect gcc to generate
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-       addqw #4,%sp
-       movel c,%sp@-
-       jbsr baz
-       addqw #4,%sp
-       unlk %a6
-       rts
-
-but because gcc knows that the unlk instruction will roll back the stack
-in fact gcc generates:
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-       addqw #4,%sp
-       movel c,%sp@-
-       jbsr baz
-       unlk %a6
-       rts
-
-With -O -fdefer-pop gcc optimizes out the pops completely & generates:
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-       movel c,%sp@-
-       jbsr baz
-       unlk %a6
-       rts
-
-with -O -fomit-frame-pointer -fdefer-pop gcc generates:
-
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-       movel c,%sp@-
-       jbsr baz
-       addw #12,%sp
-       rts
-
-& with -O -fomit-frame-pointer -fno-defer-pop gcc generates:
-
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-       addqw #4,%sp
-       movel c,%sp@-
-       jbsr baz
-       addqw #4,%sp
-       rts
-
-All the above cases are as one would wish.  The elimination of all
-defered pops in the unlk instruction is especially clever.
-
-However, in the presence of the threaded-code jump the waters darken!
-Consider what gcc generates for:
-
-       register void (**tcip)() asm("%a5");
-
-       #define JUMPNEXT do{asm("movl %a5@+,%a0; jmp %a0@");return;}while(0)
-
-       extern long a, b;
-       void doit() {
-               foo(a); bar(b); JUMPNEXT;
-       }
-with -O -fdefer-pop gcc generates
-
-doit:
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       unlk %a6
-       rts
-
-This is clearly no good because the arguments to both foo & bar
-will never be popped. Every time doit() is executed the stack will grow
-by 8 bytes.  Soon your program will dump core with a very large stack
-segment!
-
-with -O -fno-defer-pop gcc generates:
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       unlk %a6
-       rts
-
-Again useless because bar's pop has been folded into the unlk
-which won't be executed.
-
-with -O -fdefer-pop -fomit-frame-pointer gcc generates
-
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-       addqw #8,%sp
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       rts
-
-This is great. However, not all functions are susceptible to
-the omit-frame-pointer optimization (i.e. functions
-with local variables).  E.g. the code generated for:
-
-       register void (**tcip)() asm("%a5");
-
-       #define JUMPNEXT do{asm("movl %a5@+,%a0; jmp %a0@");return;}while(0)
-
-       extern long a, b;
-       void doit() {
-               char    large[1024];
-               foo(a,large); bar(b); JUMPNEXT;
-       }
-
-with -O -fomit-frame-pointer -fdefer-pop is:
-
-       link %a6,#-1024
-       pea %a6@(-1024)
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       unlk %a6
-       rts
-
-so in general one can't rely on -fomit-frame-pointer.
-For the above example both
-       -O -fomit-frame-pointer -fno-defer-pop
-and
-       -O -fno-defer-pop
-generate:
-
-doit:
-       link %a6,#-1024
-       pea %a6@(-1024)
-       movel a,%sp@-
-       jbsr foo
-       addqw #8,%sp
-       movel b,%sp@-
-       jbsr bar
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       unlk %a6
-       rts
-
-This is also useless because bar's argument pop has been folded away.
-The problem is that gcc will always fold away the last call's argument
-pop if the function has a frame pointer, and -fomit-frame-pointer
-can't allways get rid of the frame pointer.  In fact, in the presence
-of variable sized automatic variables or calls on alloca it would be
-very hard (impossible for recursive functions?) to do.
-
-The eatest solution I've come up with is to use -fno-defer-pop
-and a dummy function call between the threaded-code jump and
-the return:
-
-       register void (**tcip)() asm("%a5");
-
-       #define JUMPNEXT do{asm("movl %a5@+,%a0; jmp
-%a0@");SBD();return;}while(0)
-
-       extern long a, b;
-       void doit() {
-               foo(a); bar(b); JUMPNEXT;
-       }
-with -O -fno-defer-pop gcc generates:
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-       addqw #4,%sp
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       jbsr SBD
-       unlk %a6
-       rts
-
-Now bar's argument pop is not folded because its no longer the last
-call in the routine, SBD is.
-So the call to SBD
-       a) prevents gcc's 'last call argument pop fold into unlk' optimization
-          which prevents uncontrolled stack growth.
-       b) doesn't get executed because of the jump
-       c) is trivial to remove from the assembler with a sed-script
-
-
->4. Why does JUMPNEXT have a loop?  Surely the jump leaves the loop right
->away.  Presumably you are tricking the compiler somehow.
->
-This is old C lore.  The problem is
-       'How do you write a macro that is a sequence of statements
-        that can be used wherever a single statement can?'
-
-take the following definition of JUMPNEXT:
-#define JUMPNEXT asm("movl %a5@+,%a0; jmp %a0@");return;
-
-Now invoke it here:
-       if (its_time_to_jump)
-               JUMPNEXT;
-       do_something_else();
-
-This expands to:
-       if (its_time_to_jump)
-               asm("movl %a5@+,%a0; jmp %a0@");
-       return;
-       do_something_else();
-
-Not at all whats intended!
-
-There are two tricks I know of (the first I saw in Berkely Smalltalk,
-the second in Richard Stallman's gcc manual. I expect they're both
-quite old).
-The first is to surround your statements with
-if (TRUE){statements}else
-i.e.
-#define JUMPNEXT if(1){asm("movl %a5@+,%a0; jmp %a0@");return;}else
-So now we get:
-       if (its_time_to_jump)
-               if (1){
-                       asm("movl %a5@+,%a0; jmp %a0@");
-                       return;
-               else;
-       do_something_else();
-
-which works because C binds elses innermost first. However, some
-compilers will whine about dangling elses.  The second scheme is
-more elegant (-:
-
-Surround your statements with
-do{statements}while(FALSE);
-which will execute statements precisely once (its NOT a loop).
-i.e.
-#define JUMPNEXT do{asm("movl %a5@+,%a0; jmp %a0@");SBD();return;}while(0)
-expands to
-
-       if (its_time_to_jump)
-               do {
-                       asm("movl %a5@+,%a0; jmp %a0@");
-                       return;
-               while(0);
-       do_something_else();
-
-which does what's wanted and doesn't incur compiler whines.
-
-
->Thanks
->
->Simon L Peyton Jones
->Glasgow University
-
-Eliot Miranda                  email:  eliot@cs.qmw.ac.uk
-Dept of Computer Science       Tel:    071 975 5229 (+44 71 975 5229)
-Queen Mary Westfield College   ARPA:   eliot%cs.qmw.ac.uk@nsf.ac.uk    
-Mile End Road                  UUCP:   eliot@qmw-cs.uucp
-LONDON E1 4NS
-
->From vestal@SRC.Honeywell.COM Fri Apr  5 12:26:11 1991
-From: vestal@SRC.Honeywell.COM (Steve Vestal)
-Newsgroups: comp.compilers
-Subject: Re: Portable Fast Direct Threaded Code
-Keywords: interpreter, performance, design
-Date: 3 Apr 91 18:23:34 GMT
-Reply-To: vestal@SRC.Honeywell.COM (Steve Vestal)
-Organization: Honeywell Systems & Research Center
-In-Reply-To: pardo@cs.washington.edu's message of 2 Apr 91 19:21:25 GMT
-
-In article <1991Apr2.192125.7464@beaver.cs.washington.edu>
-pardo@cs.washington.edu (David Keppel) writes:
-[references about threaded code, much stuff deleted]
-
-David> %X Describes how to build a threaded code interpeter/compiler from
-David> scratch.
-David>  * Less than 2:1 performance hit of threading compared to full
-David> compilation.
-
-I have a question about this.  Numbers like this are often cited for
-threaded-type code, but in Bell's paper this was for the PDP-11 (whose
-addressing modes made it a natural for threaded code).  Paul Klint's
-"Interpretation Techniques" paper (Software P&E, v11, 1981) cites a
-significant difference for interpreter fetch/decode times on different
-architectures.  He cited numbers around 2:1 for the PDP-11, but something
-more like 9:1 for a Cyber.  I did a Q&D evaluation of this for a RISC, and
-the ratio I guestemated was closer to that Klint gave for the Cyber than
-for the PDP-11 (not unexpectedly).
-
-How architecturally dependent is the performance of these techniques
-(relative to compiling to native code)?
-
-Steve Vestal
-Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 
-Phone: (612) 782-7049                    Internet: vestal@src.honeywell.com
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From E.Ireland@massey.ac.nz Fri Apr  5 12:29:20 1991
-From: E.Ireland@massey.ac.nz (Evan Ireland)
-Newsgroups: comp.lang.functional
-Subject: Three address code
-Date: 4 Apr 91 21:49:21 GMT
-Reply-To: E.Ireland@massey.ac.nz
-Organization: Information Sciences, Massey University, New Zealand
-
-I've had no luck with mail, so this is for csdw at Rhodes University.
-
->
->In an attempt to optimize a functional language, I would like to
->turn the stack based intermediate code into three address code. 
->
->Has anyone done similar conversions?  Any references would be
->greatly appreciated.
-
-I do not have any references, but I thought that one aspect of my FAM
-implementation might be of interest.
-
-A number of interpreters and compilers that I have seen implement a stack
-pointer in a register or global variable.  Then to implement various stack
-operations, they use auto-increment or auto-decrement operations on the stack
-pointer register.  Since I generate portable C, and thus cannot assume I have
-
-    DATA *f (register DATA *fp)
-    {
-       ....
-    }
-
-Thus I pass to each function the current pointer to top of stack, from which it
-can index downwards to find its arguments.  Within the function, I use indexing
-operations on fp, e.g. fp[3] = fp[1], to manipulate values on the stack, so I
-am not continually manipulating the stack pointer.  If "f" calls another
-function, it will pass the address of the current top of stack, e.g. g (&f[5]).
-
-The advantage to me is that I have a register for a stack pointer even though I
-am generating portable C code.
-
-Now the relationship to three-address code.  If you adopt such a scheme, and
-your three address instructions allow some indexing, you can sometimes generate
-
-       ADD     fp[3],f[4],fp[3]
-
-I hope this helps.
-_______________________________________________________________________________
-
-E.Ireland@massey.ac.nz          Evan Ireland, School of Information Sciences,
-  +64 63 69099 x8541          Massey University, Palmerston North, New Zealand.
-
->From pardo@cs.washington.edu Sat Apr  6 14:32:24 1991
-From: pardo@cs.washington.edu (David Keppel)
-Newsgroups: comp.compilers
-Subject: Re: Portable Fast Direct Threaded Code
-Keywords: interpreter, performance, design
-Date: 4 Apr 91 17:10:55 GMT
-Reply-To: pardo@cs.washington.edu (David Keppel)
-Organization: Computer Science & Engineering, U. of Washington, Seattle
-
->>>[Threaded code vs. compilation]
-
->pardo@cs.washington.edu (David Keppel) writes:
->>[Less than 2:1 performance hit of threading vs. full compilation.]
-
-Note also that the reference that claimed 2:1 (Peter M. Kogge, IEEE
-Computer pp 22-33 March 1982) also attributed part of that ratio to the
-poor state of compiler optimization.
-
-
-vestal@SRC.Honeywell.COM (Steve Vestal) writes:
->[Klint says 2:1 for PDP-11 v. 9:1 for Cyber.
-> How architecturally dependent are these techniques?]
-
-Suppose that the statically-compiled code fragments that are threaded
-together are called `primitives'.
-
-
-When the execution time of a primitive is large, then the overhead for the
-interpreter can be large and still have a small effect on performance.
-The performance of the interpreted code is dominated by the time in a
-primitive vs. the overhead of moving between primitives.
-
-When the execution time of the primitives is small, then the overhead for
-moving between primitives can be a large fraction of the total execution
-time.  Overhead comes from at least two sources:
-
- * Control flow: the address of the the next primitive is loaded
-   from data memory and the processor executes an indirect jump.
-
- * Register allocation: a primitive is essentially a function with
-   a fast calling convention (no stack adjustment).  Thus, all the
-   traditional problems with interprocedural register allocation.
-
-Examples of `large primitives' are ``draw circle'' and ``interpolate
-spline''.  Examplees of small primitives are ``push'', ``add'', etc.
-
-
-* Architectural dependency of control flow
-
-Examples:
-
-       Direct jumps in full compilation:
-
-               op1
-               op2
-               br next         // direct jump
-       
-       Indirect jumps for threading for a CISC:
-
-               op1
-               op2
-               br *(r0)+       // load, increment, jump
-
-       Indirect jumps for threading for a RISC:
-
-               ld *r0, r1      // scheduled load
-               op1
-               op2
-               br *r1          // jump
-               add r1, #4, r1  // delay slot increment
-
-Direct jumps in full compilation can frequently use one instruction (a
-``near branch'') both to find the address of the next code fragment and
-perform the control transfer.  On a CISC, branches are typically two or
-three bytes.  On a RISC, branches are typically four bytes.  The threaded
-indirect (load, increment, jump) is typically three bytes on a CISC and
-twelve bytes (three instructions) on a RISC.
-
-Direct jumps in full compilation take typically one instruction time.
-Indirect jumps take at least the following operations: load, increment,
-jump indirect.  On a CISC, the three operations can typically be `folded'
-in to one instruction.  There may be a load penalty of one instruction
-time but the increment is overlapped, so the total time is three machine
-units (one `unit' is about one register->register operation).  On a RISC,
-the total penalty is three machine units.
-
-Direct jumps take one (I-cache) cycle to fetch both the branch instruction
-and the address of the branch target.  Indirect jumps take a D-cache cycle
-to fetch the address of the branch target and an I-cache cycle to fetch
-the branch instruction.
-
-Direct jumps can take advantage of instruction prefetching since the
-address of the next instruction is known at the time that the instruction
-prefetch reads the direct jump.  Threaded indirects require an indirect
-branch off of a register.  Current RISC and CISC machines are about
-equivalent in that they do little prefetching.  Some machines being
-designed do more prefetching so the threading overhead for them will be
-greater.
-
-
-* Architectural dependency of register allocation
-
-In a machine with a small number of registers, many of the registers are
-in-use in each primitive and the best possible register allocation will
-contain many loads and stores.  In a machine with a large number of
-registers, the full-compilation implementation can make much better use of
-registers than the threaded primitives implementation (again, for small
-primitives).  The savings from full compilation are exactly analagous to
-the improvements in register allocation from doing inlining of small
-procedures.
-
-
-* Other points to ponder
-
-In some cases the threaded code implementation is substantially smaller
-than the full-compilation implementation.  For large functions or a
-machine with small caches, the loss of performance from threading might be
-overwhelmed by the gain in cache performance.
-
-On RISC machines, procedure call/return is about twice the cost of other
-control flow, except for the overhead of register management.  Thus,
-call-dense RISC code from full compilation may behave about the same as
-threaded code.
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From airs!ian@uunet.UU.NET Sat Apr  6 14:32:56 1991
-From: airs!ian@uunet.UU.NET (Ian Lance Taylor)
-Newsgroups: comp.compilers
-Subject: Threaded code
-Keywords: books, interpreter, design
-Date: 4 Apr 91 07:19:41 GMT
-Reply-To: airs!ian@uunet.UU.NET (Ian Lance Taylor)
-Organization: Compilers Central
-
-The book ``Threaded Interpretive Languages'' has a quite complete
-implementation of a threaded version of Forth in Z80 assembler.  It's
-a very complete description of why threaded implementations exist and
-how to implement them easily.  It's by R. G. Loeliger and was
-published by Byte Books (ISBN 0-07-038360-X).  It was published in
-1981, though, and I'm sure it's long out of print.
-
-Ian Taylor              airs!ian@uunet.uu.net               uunet!airs!ian
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From firth@sei.cmu.edu Sun Apr  7 14:33:13 1991
-From: firth@sei.cmu.edu (Robert Firth)
-Newsgroups: comp.compilers
-Subject: Re: Portable Fast Direct Threaded Code
-Keywords: interpreter, performance, design
-Date: 4 Apr 91 13:27:21 GMT
-Reply-To: firth@sei.cmu.edu (Robert Firth)
-Organization: Software Engineering Institute, Pittsburgh, PA
-
-In article <1991Apr3.182334.16164@src.honeywell.com>
-vestal@SRC.Honeywell.COM (Steve Vestal) writes:
-
->How architecturally dependent is the performance of these techniques
->(relative to compiling to native code)?
-
-[cost of threaded code on PDP-11, RISC &c]
-
-We might have a misunderstanding here, because what I think of as threaded
-code doesn't have a decoding and interpretation step.  But I'll talk of
-what I know.
-
-A program in threaded code is just an array of addresses, possibly
-interspersed with operands.  So the fragment
-
-       c := a + b
-
-becomes something like
-
-       address of 'load'
-       address of 'a'
-       address of 'load'
-       address of 'b'
-       address of '+'
-       address of 'store'
-       address of 'c'
-
-This implies a very simple virtual stack machine - you can get more clever
-by implementing a virtual register machine.
-
-The basic execution thread then does this.  We point a global register at
-the table of addresses, and each primitive has the form
-
-       treg := treg + address'size
-       ...
-       jump (treg)
-
-As you can see, this is great on the PDP-11, since that reduces to one
-instruction
-
-       MOV (treg)+,PC  ; NOTE TO MAINTAINER: FASTER THAN JMP - DON'T TOUCH!
-
-On a typical RISC machine, it's two cycles, since you can put almost
-anything in the delay slot(s) after the jump.
-
-Now, the load instruction, for instance, would say
-
-load:  treg := treg + address'size
-       load (treg) into tempreg
-       treg := treg + address'size
-       push (tempreg) onto simulated stack
-       jump (treg)
-
-On the PDP-11, that's
-
-       MOV @(treg)+, -(SP)
-       MOV (treg)+, PC
-
-On a RISC, it's much more like
-
-       L R0, 4(treg)           ; get operand address
-       L R0, 0(R0)             ; dereference to get operand
-       SUBI SP, #4             ; decrement simulated SP
-       S R0, 0(SP)             ; push operand on stack
-       ADDI treg, #8           ; step over two addresses (mine & operands)
-       JR (treg)               ; over to you, Moriarty!
-
-[to fill delay slots, shuffle the above to 132564]
-
-Well, if you have one load delay slot and one branch delay slot, you can
-fill all three of them, so that's 6 cycles.  Given that a typical load is
-only 1.1 cycles in direct code (90% of the delays filled), this is
-certainly a lot more than a 2:1 overhead!  When you add the cost of a
-simulated stack (lots of needless loads and stores), I can well believe
-10:1 time expansion for simple code.
-
-In fact, it was more than that on the PDP-11, if you compared threaded
-code with direct code from a decent compiler.  The big win in the Fortran
-compiler came from (a) very compact threaded code, and (b) the floating
-point operations were implemented in software, so the overhead of threaded
-code was swamped by the cost of floating addition, subtraction &c.
-
-Here's the full code of the above example, so you can see for yourself
-
-Direct:
-       MOV a, R0
-       ADD b, R0
-       MOV R0, c
-
-Threaded:
-       MOV @(treg)+, -(SP)
-       MOV (treg)+, PC
-*      MOV @(treg)+, -(SP)
-*      MOV (treg)+, PC
-*      ADD (SP)+,(SP)
-       MOV (treg)+, PC
-       MOV (SP)+, @(treg)+
-       MOV (treg)+, PC
-
-Note that, if you implement a one-address add, you save two instructions,
-since the *** bit reduces to
-
-       ADD @(treg)+, (SP)
-
-But even then, it's coming out at over 4:1.
-
-What architectural features make threaded code more efficient?  The
-fundamental one is main memory that is fast (or not too slow) relative to
-registers, since you're doing a lot more fetching.  Another is a set of
-address modes with double indirection, since you're accessing most
-operands one level of indirection further back.  And good old
-autoincrement helps a little, too.  Alas, none of that says 'risc', and
-much of it says '1960s'.
-
-Incidentally, if I were to do this again today, I'd definitely simulate a
-general-register machine and use a subset of the real machine's registers.
-If you take 8 of them, you then have 8 loads and stores, one for each
-register, but if you make an absolute rule that nobody even thinks about
-touching one of those 8 that doesn't belong to him, then all the good
-tricks about register allocation, slaving &c will still work.  If you then
-implement the operations as one-address general-register, you have again 8
-versions (add into R0, add into R1, ...) and lo! you're programming a very
-familiar old friend.
-
-"But that was in another country, and besides, the machine is dead..."
-
-Robert Firth
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From bpendlet@bambam.es.com Tue Apr  9 20:35:22 1991
-From: bpendlet@bambam.es.com (Bob Pendleton)
-Newsgroups: comp.compilers
-Subject: Re: Portable Fast Direct Threaded Code
-Keywords: interpreter, design
-Date: 8 Apr 91 19:48:00 GMT
-Reply-To: bpendlet@bambam.es.com (Bob Pendleton)
-Organization: Compilers Central
-
-In article <23613@as0c.sei.cmu.edu> you write:
-
-> A program in threaded code is just an array of addresses, possibly
-> interspersed with operands.  So the fragment
-> 
->      c := a + b
-> 
-> becomes something like
-> 
->      address of 'load'
->      address of 'a'
->      address of 'load'
->      address of 'b'
->      address of '+'
->      address of 'store'
->      address of 'c'
-> 
-> This implies a very simple virtual stack machine - you can get more clever
-> by implementing a virtual register machine.
-
-About 10 years ago I was working on a lisp compler that compiled to
-threaded code. I was trying to get small code and still have some
-performance. (Since I wanted to run the code on a Z80 or 8080 small was
-important. My how things change :-)
-
-I found that the 3 most common operations in threaded code were load,
-store, and execute. So I put those operations with the operands. This
-made the operands look rather like classes with load, store, and
-execute as virtual functions. If you let the evaluate operation
-subsume the load and execute operations the threaded code for
-
-       c := a + b;
-
-becomes
-
-       address of 'a.evaluate()'
-       address of 'b.evaluate()'
-       address of '+'
-       address of 'c.store()'
-
-and
-
-       g := F(x, y);
-
-becomes
-
-       address of 'x.evaluate()'
-       address of 'y.evaluate()'
-       address of 'F.evaluate()'
-       address of 'g.store()'
-
-
-Which is much smaller than the original version of threaded code.
-
-Later, while working on a homebrew version of FORTH I gave up on
-threaded code completely. I found, like most who have expolored it,
-that symbolic execution of RPN code is a nice way to generated machine
-code. Machine code that runs much faster than threaded code, and that
-the machine code, even on an 8080, was only about 25% bigger than
-threaded code.
--- 
-              Bob Pendleton
-   bpendlet@dsd.es.com or decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet
-[The DEC PDP-11 Fortran compiler did something similar, writing load routines
-for commonly used variables. -John]
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From pardo@june.cs.washington.edu Wed Apr 24 09:26:32 1991
-From: pardo@june.cs.washington.edu (David Keppel)
-Newsgroups: comp.compilers
-Subject: Re: Fast Interpreted Code
-Keywords: interpreter, threaded code
-Date: 23 Apr 91 02:06:21 GMT
-Reply-To: pardo@june.cs.washington.edu (David Keppel)
-Organization: Computer Science & Engineering, U. of Washington, Seattle
-
-ssinghani@viewlogic.com (Sunder Singhani) writes:
->[Our threaded code isn't fast enough.  What's faster?]
-
-As far as I know, threaded code gives the fastest primitives/second
-dispatch rate on a variety of architectures.  The general techniques for
-making things faster (that I know of!) are to change things so that the
-dispatch rate can go down without changing the work that gets done (or use
-hardware, but we'll ignore that for the moment.)
-
-* Use a different v-machine instruction set
-
-  The overhead of interpreting is almost nothing in generic PostScript
-  imaging code because all the time is spent in non-interpretded
-  primitives.  If you can characterize your key operations (perhaps
-  info in [Davidson & Fraser ??, Fraser, Myers & Wendt 84] can help
-  you analyze for common operations instead of the more normal time in
-  routines) then you can re-code your virtual instruction set to have
-  as primintives oeprations that are performed frequently.
-
-* Dynamic compilation to native machine code
-
-  This is what is done in ParcPlace System's Smalltalk-80
-  implementation,  [Deutsch & Schiffman 84] also Insignia Solution's
-  8086 interpreter.
-
-  Dynamic compilation suffers from the need to do compilation at
-  runtime: a compiler that produces better code will take longer to
-  run and the compile time contributes to the overall program runtime.
-  Also, program text isn't shared, even if multiple instances are
-  running simultaneously.
-* Native-coding key routines
-
-  If you believe that your program spends 80% of its time in a few key
-  routines, then compiling just these routines -- statically, adding
-  them to the primitive set, statically adding them as library
-  routines, or dynamically -- can improve performance substantially
-  [Pittman 87].
-
-
-5 Citations follow:
-
-%A Robert Bedichek
-%T Some Efficient Architecture Simulation Techniques
-%J Winter '90 USENIX Conference
-%D 26 October, 1989
-%W Robert Bedichek.
-%W Pardo has a copy.
-%X Describes a simulator that uses threaded-code techniques to emulate
-a Motorola 88000.  Each 88k instruction is executed in about 20 host
-(68020) instructions.  Discusses techniques used to get the simulation
-down from several thousand host instructions in many other
-simulators.
-
-%A Jack W. Davidson
-%A Chris W. Fraser
-%T Eliminating Redundant Object Code
-%J POPL9
-%P 128-132
-
-%A Peter Deutsch
-%A Alan M. Schiffman
-%T Efficient Implementation of the Smalltalk-80 System
-%J 11th Annual Symposium on Principles of Programming Languages
-(POPL 11)
-%D January 1984
-%P 297-302
-%X Dynamic translatin of p-code to n-code (native code).
-Resons for not using straight p-code or straight n-code:
- * p-code is smaller than n-code (<= 5X).
- * The debugger can debug p-code, improving portability.
- * Native code is faster (<= 2X).  Reasons include
-special fetch/decode/dispatch hardware;
-p-machine and n-machine may be very different, e.g.,
-stack machine vs. register-oriented.
- * Threaded code does reduce the cost of p-code fetch/decode.
-Does not help with operand decoding.
-Does not allow optimizations to span more than one instruction.
-[pardo: that's not technically true, but each optimized
-instruction must exist in addition to the unoptimized version.
-That leads to exponential blowup of the p-code.  Example: delayed
-branch and non-delayed branch versions of Robert Bedichek's 88k
-simulator.]
- The system characteristics:
- * The time to translate to n-code via macro expansion is about the
-same as the execute time to interpret the p-code.
- * (pg 300:) Self-modifying code (SMC) is deprecated but used in a
-``well-confined'' way.  Could indirect at more cost.  Use SMC on the
-machines where it works, indirection where SMC.
-doesn't.
- * Performance is compared to a ``straightforward'' interpreter.
-What's that?
-
-%A Christopher W. Fraser
-%A Eugene W. Myers
-%A Alan L. Wendt
-%T Analyzing and Compressing Assembly Code
-%J CCC84
-%P 117-121
-
-%A Thomas Pittman
-%T Two-Level Hybrid Interpreter/Native Code Execution for Combined
-Space-Time Program Efficiency
-%D 1987
-%J ACM SIGPLAN
-%P 150-152
-%X Talks about native code execution vs. various kinds of interpreting
-and encoding of key routines in assembly.
-
-
-Hope this helps!
-
-       ;-D on  ( This is all open to interpretation )  Pardo
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From eliot@cs.qmw.ac.uk Tue Apr 30 15:55:17 1991
-From: eliot@cs.qmw.ac.uk (Eliot Miranda)
-Newsgroups: comp.compilers,gnu.gcc.bug,alt.sources
-Subject: re: Threaded Code
-Keywords: design, interpreter
-Date: 5 Apr 91 11:43:51 GMT
-Reply-To: Eliot Miranda <eliot@cs.qmw.ac.uk>
-Followup-To: comp.compilers
-Organization: Computer Science Dept, QMW, University of London, UK.
-
-I recently posted articles to comp.compilers & alt.sources on how
-to write threaded code machines in C.  I received the following questions
-from Simon Peyton Jones at Glasgow.  They are specific to GCC.
-Since they have non-obvious answers & since the answers suggest
-augmentation of the GCC compiler I'm posting my response to Simon.
-
->From: Simon L Peyton Jones <simonpj@cs.gla.ac.uk>
->
->I saw your article about threaded code.  Like you and others, we are
->using C as an assembler, only for a pure functional language, Haskell.
->I have some brief questions.
->
->1. By telling GCC not to use a frame pointer, one can eliminate
->the prolog entirely, can't one?  So why edit it out?
-
-No, registers local to the procedure will still be saved & stack space
-allocated for automatic variables. This IS a problem since the
-threaded-code jump at the end of the procedure will miss the register
-restores before the epilogue.  Consequently the stack will grow unless
-these register saves & stack-space allocations are removed.  Also
-GCC can not always eliminate the frame pointer.
-
->I guess the answer is going to be local variables, allocated once for
->all by the StartTCMachine routine.  Still, it seems quite a pain.  I guess
->one could sacrifice some (perhaps slight) speed by using a bunch of
->globals instead.
-For certain routines, not using register variables will be expensive
-(e.g. a simple integer arithmetic primitive).
-
->2. You edit out the epilogue for tidiness only, I take it.  It doesn't
->cause any problems if you leave it in, does it?
-No, but given that the prologue has to be removed & removing the epilogue
-is as easy (& given finite memory :-) one might as well remove it.
->
->3. Why do you use no-defer-pop (with the associated bug)?
-OK. This is again to avoid stack growth.  On conventional stack architectures
-gcc will try & combine the argument popping code of a sequence of
-procedure calls.
-e.g.
-extern long a, b, c;
-void doit() {
-       foo(a); bar(b); baz(c);
-}
-
-with -O -no-defer-pop one might expect gcc to generate
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-       addqw #4,%sp
-       movel c,%sp@-
-       jbsr baz
-       addqw #4,%sp
-       unlk %a6
-       rts
-
-but because gcc knows that the unlk instruction will roll back the stack
-in fact gcc generates:
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-       addqw #4,%sp
-       movel c,%sp@-
-       jbsr baz
-       unlk %a6
-       rts
-
-With -O -fdefer-pop gcc optimizes out the pops completely & generates:
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-       movel c,%sp@-
-       jbsr baz
-       unlk %a6
-       rts
-
-with -O -fomit-frame-pointer -fdefer-pop gcc generates:
-
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-       movel c,%sp@-
-       jbsr baz
-       addw #12,%sp
-       rts
-
-& with -O -fomit-frame-pointer -fno-defer-pop gcc generates:
-
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-       addqw #4,%sp
-       movel c,%sp@-
-       jbsr baz
-       addqw #4,%sp
-       rts
-
-All the above cases are as one would wish.  The elimination of all
-defered pops in the unlk instruction is especially clever.
-
-However, in the presence of the threaded-code jump the waters darken!
-Consider what gcc generates for:
-
-       register void (**tcip)() asm("%a5");
-
-       #define JUMPNEXT do{asm("movl %a5@+,%a0; jmp %a0@");return;}while(0)
-
-       extern long a, b;
-       void doit() {
-               foo(a); bar(b); JUMPNEXT;
-       }
-with -O -fdefer-pop gcc generates
-
-doit:
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       unlk %a6
-       rts
-
-This is clearly no good because the arguments to both foo & bar
-will never be popped. Every time doit() is executed the stack will grow
-by 8 bytes.  Soon your program will dump core with a very large stack
-segment!
-
-with -O -fno-defer-pop gcc generates:
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       unlk %a6
-       rts
-
-Again useless because bar's pop has been folded into the unlk
-which won't be executed.
-
-with -O -fdefer-pop -fomit-frame-pointer gcc generates
-
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-       addqw #8,%sp
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       rts
-
-This is great. However, not all functions are susceptible to
-the omit-frame-pointer optimization (i.e. functions
-with local variables).  E.g. the code generated for:
-
-       register void (**tcip)() asm("%a5");
-
-       #define JUMPNEXT do{asm("movl %a5@+,%a0; jmp %a0@");return;}while(0)
-
-       extern long a, b;
-       void doit() {
-               char    large[1024];
-               foo(a,large); bar(b); JUMPNEXT;
-       }
-
-with -O -fomit-frame-pointer -fdefer-pop is:
-
-       link %a6,#-1024
-       pea %a6@(-1024)
-       movel a,%sp@-
-       jbsr foo
-       movel b,%sp@-
-       jbsr bar
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       unlk %a6
-       rts
-
-so in general one can't rely on -fomit-frame-pointer.
-For the above example both
-       -O -fomit-frame-pointer -fno-defer-pop
-and
-       -O -fno-defer-pop
-generate:
-
-doit:
-       link %a6,#-1024
-       pea %a6@(-1024)
-       movel a,%sp@-
-       jbsr foo
-       addqw #8,%sp
-       movel b,%sp@-
-       jbsr bar
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       unlk %a6
-       rts
-
-This is also useless because bar's argument pop has been folded away.  The
-problem is that gcc will always fold away the last call's argument pop if
-the function has a frame pointer, and -fomit-frame-pointer can't allways
-get rid of the frame pointer.  In fact, in the presence of variable sized
-automatic variables or calls on alloca it would be very hard (impossible
-for recursive functions?) to do.
-
-The neatest solution I've come up with is to use -fno-defer-pop and a
-dummy function call between the threaded-code jump and the return:
-
-       register void (**tcip)() asm("%a5");
-
-       #define JUMPNEXT do{asm("movl %a5@+,%a0; jmp
-%a0@");SBD();return;}while(0)
-
-       extern long a, b;
-       void doit() {
-               foo(a); bar(b); JUMPNEXT;
-       }
-with -O -fno-defer-pop gcc generates:
-
-       link %a6,#0
-       movel a,%sp@-
-       jbsr foo
-       addqw #4,%sp
-       movel b,%sp@-
-       jbsr bar
-       addqw #4,%sp
-#APP
-       movl %a5@+,%a0; jmp %a0@
-#NO_APP
-       jbsr SBD
-       unlk %a6
-       rts
-
-Now bar's argument pop is not folded because its no longer the last
-call in the routine, SBD is.
-So the call to SBD
-       a) prevents gcc's 'last call argument pop fold into unlk' optimization
-          which prevents uncontrolled stack growth.
-       b) doesn't get executed because of the jump
-       c) is trivial to remove from the assembler with a sed-script
-
-
-One an try to use -fcaller-saves, but this surrounds calls with unnecessary
-register saves & restores that for the code to be optimal have to be
-edited out.
-
->4. Why does JUMPNEXT have a loop?  Surely the jump leaves the loop right
->away.  Presumably you are tricking the compiler somehow.
-
-This is old C lore.  The problem is
-       'How do you write a macro that is a sequence of statements
-        that can be used wherever a single statement can?'
-
-take the following definition of JUMPNEXT:
-#define JUMPNEXT asm("movl %a5@+,%a0; jmp %a0@");return;
-
-Now invoke it here:
-       if (its_time_to_jump)
-               JUMPNEXT;
-       do_something_else();
-
-This expands to:
-       if (its_time_to_jump)
-               asm("movl %a5@+,%a0; jmp %a0@");
-       return;
-       do_something_else();
-
-Not at all whats intended!
-
-There are two tricks I know of (the first I saw in Berkely Smalltalk,
-the second in Richard Stallman's gcc manual. I expect they're both
-quite old).
-The first is to surround your statements with
-if (TRUE){statements}else
-i.e.
-#define JUMPNEXT if(1){asm("movl %a5@+,%a0; jmp %a0@");return;}else
-So now we get:
-       if (its_time_to_jump)
-               if (1){
-                       asm("movl %a5@+,%a0; jmp %a0@");
-                       return;
-               else;
-       do_something_else();
-
-which works because C binds elses innermost first. However, some
-compilers will whine about dangling elses.  The second scheme is
-more elegant (-:
-
-Surround your statements with
-do{statements}while(FALSE);
-which will execute statements precisely once (its NOT a loop).
-i.e.
-#define JUMPNEXT do{asm("movl %a5@+,%a0; jmp %a0@");SBD();return;}while(0)
-expands to
-
-       if (its_time_to_jump)
-               do {
-                       asm("movl %a5@+,%a0; jmp %a0@");
-                       return;
-               while(0);
-       do_something_else();
-
-which does what's wanted and doesn't incur compiler whines.
-
-
->Thanks
->
->Simon L Peyton Jones, Glasgow University
-
-More and more people are taking the 'use C as an assembler' route, and
-more and more people are using GCC to do it (because its code quality is
-good, it had global register variables, and it has an excellent asm
-facility).  The threaded-code in C idea is also becomming more popular.
-But as the code above demonstrates, one does have to side-step
-optimizations and develop system-specific assembler editing scripts.
-
-I'd like to ask Richard Stallman & the GCC development team for
-       -fno-prolog -fno-epilog
-flags that instruct gcc to generate
-       a) no register saves or restores
-       b) no automatic variable allocation
-       c) no procedure linkage/frame creation
-
-Then the optimal 'Threaded-Code Machine in GCC C' can be compiled without
-any assembler editing scripts at all.
-
-Also nice would be a way of telling GCC that an asm statement
-changed the flow of control so GCC could
-       a) warn about not-reached code
-       b) eliminate unnecessary code (do more code folding)
--- 
-Eliot Miranda                  email:  eliot@cs.qmw.ac.uk
-Dept of Computer Science       Tel:    071 975 5229 (+44 71 975 5229)
-Queen Mary Westfield College   ARPA:   eliot%cs.qmw.ac.uk@nsf.ac.uk    
-Mile End Road                  UUCP:   eliot@qmw-cs.uucp
-LONDON E1 4NS
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
->From brennan@bcsaic.boeing.com Sat May  4 11:28:41 1991
-From: brennan@bcsaic.boeing.com (Michael D Brennan)
-Newsgroups: comp.compilers
-Subject: re: Threaded code
-Keywords: interpreter, design
-Date: 2 May 91 19:50:23 GMT
-Reply-To: brennan@bcsaic.boeing.com (Michael D Brennan)
-Organization: Boeing Aerospace & Electronics, Seattle WA
-
-Another method for obtaining threaded byte code for an interpreter
-is to edit the assembler output of a big switch
-rather than editing the prologue and epilogue off functions calls.
-
-You don't need gcc, global vars in registers, works with smart and
-dumb compilers, and all optimization can be turned on.
-
-For example:
-
-This C routine executes (unthreaded) byte code for an interpreter 
-that can add, subtract and print.
-
-#define  HALT     0
-#define  PUSH     1
-#define  ADD      2
-#define  SUB      3
-#define  PRINT    4
-
-static int stack[32] ;
-
-void  execute(code_ptr)
-  register int *code_ptr ;
-{
-  register int *stack_ptr = stack - 1 ;
-
-
-  while ( 1 )
-  {
-    switch( *code_ptr++ )
-    {
-      case HALT   :  return ;
-      case PUSH   :
-           * ++ stack_ptr = *code_ptr++ ;
-           break ;
-
-      case  ADD   :
-           stack_ptr-- ;
-           *stack_ptr += stack_ptr[1] ;
-           break ;
-
-      case  SUB   :
-           stack_ptr-- ;
-           *stack_ptr -= stack_ptr[1] ;
-           break ;
-
-      case   PRINT  :
-             printf("%d\n", *stack_ptr--);
-            break ;
-     }
-  }
-}
-
--------------------------------------------------------
-
-to interpret 2 + (3 - 4)
-
-the front end "compiles" in  int code[]
-
-PUSH, 2, PUSH, 3, PUSH, 4, SUB, ADD, PRINT, HALT
-
-and calls  execute(code).
-
-------------------------------------------------------
-
-The difference between this and the threaded code discussed over
-the last few weeks is the switch gets compiled as
-
-      jmp      TABLE[ *code_ptr++ ]
-
-where TABLE is the jump table generated by the compiler which holds
-the addresses of the case labels.
-
-With threading, the transitions between functions become
-
-      jmp      *code_ptr++
-
-
-but this is easy to get by editing the assembler output to
-export the case label and recode the switch.
-
---------------------------------------------------
-
-For example on a SPARC:
-
-code_ptr is %o0
-stack_ptr is %i5
-
-
-       .....
-                             ! case PUSH
-L77004:
-       ld      [%i0],%o1
-       inc     4,%i5
-       inc     4,%i0
-       b       L77008
-       st      %o1,[%i5]
-
-       .....
-
-                            !  the switch, doesn't change structure
-                            !  as you add new op codes
-
-L77008:
-       mov     %i0,%i4
-       ld      [%i4],%i4
-       inc     4,%i0
-       cmp     %i4,4
-       bgu     L77008
-       sll     %i4,2,%i4
-       sethi   %hi(L2000000),%o1
-       or      %o1,%lo(L2000000),%o1   ! [internal]
-       ld      [%i4+%o1],%o0
-       jmp     %o0
-       nop
-L2000000:                !  the jump TABLE
-       .word   L77003    !  HALT  etc
-       .word   L77004
-       .word   L77005
-       .word   L77006
-       .word   L77007
-
-
--------------------------------------------
-modify by adding global labels and edit the switch
-       
-
-
-       .....
-                             ! case PUSH
-_push :
-L77004:
-       ld      [%i0],%o1
-       inc     4,%i5
-       inc     4,%i0
-       b       L77008
-       st      %o1,[%i5]
-
-       .....
-
-                         !  the edited switch
-L77008:
-       mov     %i0,%i4
-       ld      [%i4],%i4
-       inc     4,%i0
-       jmp     %i4
-       nop
-                         !  remove TABLE
-
--------------------------------------------
-
-For another example on an Intel 8088 
-
-stack_ptr is si
-code_ptr  is di
-
-   ;     while ( 1 )
-   ;     {
-   ;       switch( *code_ptr++ )
-   ;   
-@1@50:
-       mov     bx,di
-       inc     di
-       inc     di
-       mov     bx,word ptr [bx]
-       cmp     bx,3
-       ja      short @1@50
-       shl     bx,1
-       jmp     word ptr cs:@1@C738[bx]
-
-
-@1@122:
-   ;   
-   ;         case PUSH   :
-   ;               * ++ stack_ptr = *code_ptr++ ;
-   ;   
-       inc     si
-       inc     si
-       mov     ax,word ptr [di]
-       mov     word ptr [si],ax
-       inc     di
-       inc     di
-   ;   
-   ;               break ;
-   ;   
-       jmp     short @1@50   
-   ;   
-
-       ....
-
-@1@C738        label   word       ;  jump TABLE
-       dw      @1@194     ;  HALT
-       dw      @1@122     ;  PUSH   etc
-       dw      @1@146
-
-       ....
-
-------------------------------------------------
-
-edited the jump can be computed inline
-
-   ;     while ( 1 )
-   ;     {
-   ;       switch( *code_ptr++ )
-   ;   
-@1@50:      ; switch code is replaced by code only executed once
-   
-       inc     di
-       inc     di
-       jmp     [di-2]
-
-       .....
-
-_push :
-@1@122:
-   ;   
-   ;         case PUSH   :
-   ;               * ++ stack_ptr = *code_ptr++ ;
-   ;   
-       inc     si
-       inc     si
-       mov     ax,word ptr [di]
-       mov     word ptr [si],ax
-       inc     di
-       inc     di
-   ;   
-   ;               break ;
-   ;        
-       inc     di         ;  jmp  to *code_ptr++  inline
-       inc     di
-       jmp     [di-2]
-   ;   
-       ....
-
-----------------------------------------------
-
-the "front end" has defines
-
-typedef  void (*TCODE)() ;
-
-extern  void  halt(), push(), add(), sub(), print() ;
-
-TCODE  code[CODESIZE] ;
-
-in the array code[], the front end compiles
-
-
-push, 2, push, 3, push, 4, sub, add, print, halt
-
-and calls execute(code).
-
-
---
-Mike Brennan
-brennan@bcsaic.boeing.com
--- 
-Send compilers articles to compilers@iecc.cambridge.ma.us or
-{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
-
-
diff --git a/ghc/docs/NOTES.core-overview b/ghc/docs/NOTES.core-overview
deleted file mode 100644 (file)
index 8f22299..0000000
+++ /dev/null
@@ -1,94 +0,0 @@
-\documentstyle[11pt,a4wide]{article}
-\begin{document}
-
-%****************************************
-%*                                     *
-%*             The Core language                       *
-%*                                     *
-%****************************************
-
-
-\title{The Core language}
-\author{Simon L Peyton Jones \and 
-Will Partain \and
-Patrick Sansom}
-
-\maketitle
-
-\section{Introduction}
-
-This document describes the Glasgow Haskell Core-language data type 
-in sufficient detail for an implementor to be able to use it.
-
-\section{Overview}
-
-The Core language is, roughly speaking, the second-order polymorphic
-lambda calculus, augmented with @let@, @letrec@ and @case@.
-It is a Haskell data type (defined shortly), but for convenience in this
-document we give it the concrete syntax given in Figure~\ref{fig:core-syntax}.
-
-Here are some of its important characteristics:
-\begin{description}
-\item[The Core language includes the second-order lambda calculus.]
-That is, type abstraction and type application are provided.
-\item[Constructors and primitive operators are always saturated.]
-This is easily done by adding extra lambdas and performing $\eta$-expansion.
-\item[All pattern-matching is done by simple @case@ expressions.]
-The @case@ expressions are simple in the sense that their patterns
-have only one level.
-\item[Every identifier includes its type.]
-This is not immediately obvious from the syntax, but will be fleshed out
-later.  The point is that it is easy to tell the type of any identifier or,
-in general, any Core expression.
-\item[There is no shadowing.]  
-Identifiers may not be globally unique,
-but there are no ``holes in the scope'' of any identifier.
-\end{description}
-All these properties should be maintained by programs which manipulate Core-langauge
-programs.
-
-\section{Identifiers: the type @Id@}
-
-Identifiers have the (abstract) type @Id@. 
-\begin{description}
-\item[Equality.]
-Identifiers have a unique number inside them,
-so they can be compared efficiently for equality.
-They are an instance of the class @Eq@.
-\item[Type.]
-The function 
-\begin{verbatim}
-       getIdUniType :: Id -> UniType
-\end{verbatim}
- gets the type of an identifer.
- \end{description}
- \section{Types: the type @UniType@}
- \subsection{@TyCon@}
- The type @TyCon@ ranges over {\em data} type constructors,
- not over the function type constructor.
- A @TyCon@ can be one of:
- \begin{itemize}
- \item A primitive type.
- \item A tuple type.
- \item An algebraic data type (other than tuples).
- \end{itemize}
- \section{The Core language data type}
- \subsection{@coreExpr@}
-
-Tycon in @case@.
-
-\subsection{@coreBinding@}
-
-\subsection{@coreProgram@}
-
-\subsection{@plainCore@ things}
-
-
-
-\end{document}
diff --git a/ghc/docs/NOTES.desugar b/ghc/docs/NOTES.desugar
deleted file mode 100644 (file)
index b9e6ce7..0000000
+++ /dev/null
@@ -1,323 +0,0 @@
-(91/08/08: OLD!)
-
-These are notes about a _simple_ but complete pattern-matching
-compiler for Haskell.  I presume familiarity with Phil's
-pattern-matching stuff in Simon's book and use roughly the same notation.
-
-Abbreviations: "p" for pattern, "e" (or "E") for expression, "g" for
-guard, "v" for variable, "u" for new variable I made up. "[]" for
-FATBAR.
-
-Subscripts: "p11" is really short for "p_{1,1}".  Sometimes I'll use
-a "?", as in "pm1 ... pm?", to mean the second subscript goes up to
-something I'm really not worried about.
-
-NB: LETRECS NOT DEALT WITH YET.
-
----------------------------------------------------------------------
-We need a slightly souped-up "match" for Haskell (vs the Phil-chapter
-one).  Simon suggested a re-arrangement of things, which I have then
-further re-arranged...
-
-Proposal (Simon)
-~~~~~~~~
-
-Eliminate default arg of match (3rd arg in Phil-chapter match) in
-favour of returning the variable (not special value) fail.  Thus a
-possible translation for
-
-       f [] [] = e1
-       f x  y  = e2
-
-would be
-
-       f p q = case p of 
-               [] -> case q of
-                       [] -> e1
-                       _  -> fail
-               _ -> fail
-               where
-               fail = e2
-
-Now the issue of whether to duplicate code or share it becomes whether
-to substitute copies of e2 or not.  This is a decision we need to take
-anyway for all other let-bound things, so why not for fail too?  If
-fail is used only once, we will certainly substitute for it.
-
-We could even detect that fail is used only in a head position, so it
-can be implemented as a stack-adjust then a jump.  This might well
-apply to other let-bound things too.
-
-Now here's a proposal for the "match" function.  The main difference is
-    1) no default argument
-    2) [contra simon's suggestion]  Patterns are still per-row as in
-       Phil's chapter.
-    3) [partain] even the input exprs are CoreExprs
-
-OK, for a "match" for m equations each with n patterns:
-
-match :: [Name]
-               -- n (variable) names, one per pattern column, bound
-               -- to the n expressions we are matching against the
-               -- patterns
-
-      -> [([Pat], CoreExpr)]
-               -- one pair for each of the m equations: the n
-               -- patterns in that equation, then the CoreExpr that
-               -- is evaluated if we get a match.  The CoreExpr may
-               -- contain free "fail"s; some hackery required to
-               -- ensure that is OK; see below
-
-      -> CoreExpr
-               -- the resulting code to do the matching
-
-In words,
-  takes
-    (1) a list of n (match-expression, pattern-column) pairs
-    (2) a list of m post-match expressions, expr i to be inserted
-       immediately after equation i's lhs matches
-  returns
-    (1) a desugared expr equivalent of the whole "match"
-
-Meaning
-~~~~~~~
-    match [u1, ..., un]
-         [([p11, ..., p1n], e1), ..., ([pm1, ..., pmn], em)]
-
-    match [ (e1, [p11, ...,pm1]), ..., (en, [p1n, ...,pmn])]
-         [ E1, ... Em ]
-
-    ********* MEANS *********
-
-    case (u1, ..., un) of
-        (p11, ..., p1n) -> e1
-        _               -> fail
-    where
-    fail = case (u1, ..., un) of
-               (p21, ..., p2n) -> e2
-               _               -> fail
-    ... and so on ...
-
-Alternatively, this specification could be given in terms of
-pattern-matching lambdas, as in Phil's chapter.
-
-NOT CHANGED BEYOND HERE
-
--------------------------------------------------------------------
-Cranking through a good old function definition with the above:
-
-    f p11 p12 ... p1n | g11 = e11
-                     | g12 = e12
-                     ...
-                     | g1? = e1?
-    ...
-    f pm1 pm2 ... pmn | gm1 = em1
-                     ...
-                     | gm? = em?
-
-The "match" equivalent is:
-
-f = \u1.\u2...\un ->
-       match [ (u1, [p11, ...,pm1]), ..., (un, [p1n, ...,pmn])]
-             [ E1, ..., Em ]
-       where fail = error "pattern-match for f failed\n"
-             E1   = if g11 then e11 else if g12 then ... else fail
-             ...
-             Em   = if gm1 then em1 else if gm2 then ... else fail
-
-Boring, huh?
-
--------------------------------------------------------------------
-It is helpful to me to think about the simple/base cases for this
-complicated "match".
-
-ALL LISTS EMPTY
-
-    match [] []
-
-  corresponds to the syntactically bogus (zero equations!?)
-
-    case () of
-      () -> {- nothing!! -}
-      _  -> fail
-
-
-EMPTY RULE -- no more patterns
-
-    match [] [ ([], E1), ..., ([], Em) ]
-
-  [where, incidentally, each Ei will be of the form
-   (not that it has to be...)
-
-    Ei = let x1 = e1 in
-         let x2 = e2 in
-        ...
-        let x? = e? in
-        if g1 then e'1
-        else if g2 then 
-        ...
-        else if g? then e'?
-        else fail
-  ]
-
-  becomes ("E1 [] E2 [] ... [] Em" in Phil's chapter...)
-
-    E1
-    where
-       fail = E2
-       where
-       ...
-         fail = Em-1
-        where fail = Em
-
-  with any "fail" in Em being bound from an outer scope; perhaps it's
-  easier to see written as:
-
-    let fail = Em
-     in let fail = Em-1
-        in ...
-           let fail = E2 in E1
--------------------------------------------------------------------
-HANDLING LAZY ("TWIDDLE") PATTERNS
-
-For Haskell, the "mixture rule" (p.~88) looks at a pattern-column and
-splits the equations into groups, depending on whether it sees
-
-    * all constructors, or
-    * all variables _OR LAZY PATTERNS_
-
-The following example shows what "match" does when confronted by one
-of these variables/lazy-patterns combinations.  Note the use of the
-binding lists.
-
-    f  v | g11 = e11
-        ...
-        | g1? = e1?
-    f ~p | g21 = e21
-        ...
-        | g2? = e2?
-
-is
-
-    f = \ u1 ->
-       match [(u1, [ v, ~p ])]
-             [ if g11 then e11 else if ... else fail, -- E1
-               if g21 then e21 else if ... else fail  -- E2
-             ]
-    where fail = error "no match in f\n"
-
-which transmogrifies into
-
-    f = \ u1 ->
-       let u2 = u1 in
-       match []
-             [ -- E1 --
-               let v = u2 
-               in
-               if g11 then e11 else if ... else fail
-
-              ,-- E2 --
-               let free_var1_of_p = match [(u2, [ p ])] [ free_var1_of_p ]
-                   ...
-                   free_var?_of_p = match [(u2, [ p ])] [ free_var?_of_p ]
-               in
-               if g21 then e21 else if ... else fail  -- E2
-
-             ]
-    where fail = error "no match in f\n"
-
-For more specific match-failure error messages, one could insert
-"let fail = ..."'s in strategic places.
-
--------------------------------------------------------------------
-"match" EQUIVALENTS FOR VARIOUS HASKELL CONSTRUCTS
-
-* function definition -- shown above
-
-* pattern-matching lambda (souped up version in static semantics)
-
-    \ p1 p2 ... pn | g1 -> e1
-                  | g2 -> e2
-                  ...
-                  | gm -> em
-
-  is the same as
-
-    \ u1.\u2 ... \un ->
-       match [ (u1, [p1]), ..., (un, [pn])]
-             [ if g1 then e1 else if ... then em else fail
-             ]
-       where fail = error "no match in pattern-matching lambda at line 293\n"
-
-* pattern-matching (simple, non-recursive) "let"
-
-    let p = e
-    in E
-
-  corresponds to
-
-    case e of
-      ~p -> E
-
-  which has a "match" equivalent of
-
-    match [(e, [~p])] [ E ]
-
-  The full-blown Haskell "let" is more horrible:
-
-    let p | g1 = e1
-         ...
-         | gn = en
-    in E
-
-  corresponds to
-
-    case ( if g1 then e1 else... else if gn then en else error "?" ) of
-      ~p -> E
-
-  thinking about which I am not able to sleep well at night.
-  (Won't those g's have things bound from inside p ?)
-
-* pattern-matching (not-quite-so simple, non-recursive) "let"
-
-<mumble>
-
-* pattern binding
-
-    p | g1 = e1
-      | g2 = e2
-      ...
-      | gm = em
-
-  That's the same as
-
-    p = if g1 then e1 else if ... else if gm then em else fail
-    where fail = "...some appropriate thing..."
-
-  which corresponds to
-
-    match [ (if g1 ... then em else fail, [ ~p ]) ]
-         [ {-nothing-} ]
-    where fail = "...some appropriate thing..."
-
-* "case" expressions (souped up version in static semantics)
-
-    case e0 of
-      p1 | g11 -> e11
-        ...
-        | g1? -> e1?
-      ...
-      pm | gm1 -> em1
-        ...
-        | gm? -> em?
-
-  is the same as
-
-    match [ (e0, [p1, ..., pm]) ]
-         [ if g11 then e11 else if ... else fail -- E1
-           , ... ,
-           if gm1 then em1 else if ... else fail
-         ]
-    where fail = error "pattern-matching case at line xxx failed\n"
-
-* list comprehensions
diff --git a/ghc/docs/NOTES.garbage.collection b/ghc/docs/NOTES.garbage.collection
deleted file mode 100644 (file)
index 3260df1..0000000
+++ /dev/null
@@ -1,206 +0,0 @@
-
-                       GARBAGE COLLECTION
-                       ~~~~~~~~~~~~~~~~~~
-
-The following discussion outlines how the GC is organised and what C
-the compiler needs to produce to use it.
-
-The files associated with GC are:
-
-       StgGC.h                 header file -- macros and externs
-       StgCreate.lc            GC init routines
-       StgOverflow.lhc         Overflow routines -- interface to GC
-       GC2s.lhc                }
-       GC1s.lhc                } GC control routines
-       GCdm.lhc                } for each particular GC
-       GCap.lhc                }
-       GCevac.lc               Evacuation code fragments (copying GC)
-       GCscav.lhc              Scavenging code fragments (copying GC)
-       GCcompact.lhc           Inplace Compacting GC code fragments
-       GCmark.lhc              Marking code fragments
-
-Other files:
-
-    In gctest/
-       gctest.c                GC Small detail test bed program
-
-    In gcstat/
-                               Performance evaluation stuff
-
-
-Basic Requirements of the C code Produced by the Haskell Compiler
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-There are two main aspects of the compiler generated code that
-interact with GC:
-
-1) Compiled haskell code calls the garbage collection routine when the
-   heap overflows by entering the appropriate _HEAP_OVERFLOW_... routine.
-   
-   These routines isolate register usage and calls the GC control
-   routine that was defined at compile time.
-
-   For a description of the heap overflow conventions see:
-
-       ~grasp/ghc/compiler/absCSyn/RTSLabels.lhs
-
-
-   The following must be adhered to by the mutator:
-
-               REQUIREMENT                              COLLECTOR
-     SpA and SpB point to A and B stacks                 all
-
-     Hp must point to last word allocated                dual,comp
-     All updated closures must "know" their original     dual,comp
-       size
-
-     HpLim must point to one beyond top of root stack    appel
-     Updated closures in the old generation must "know"          appel
-       their original size
-
-   The GC Control routines have to know about the pointer stack and
-   Update Stack.
-
-2) The info tables that are pointed to by closures must have the
-   appropriate GC routines within them. This is achieved by using the
-   following C Macros to declare them:
-
-               table_name --  the name given to the info table
-               entry_code --  the name of the normal evaluation
-                              entry code required for the closure
-               size       --  the No of free var words in the closure
-               ptrs       --  the number of pointers in the closure
-
-
-       SPEC_INFO_TABLE(table_name,entry_code,size,ptrs);
-
-       Declares an info table with specialiazed code fragments
-       These are currently available for the following closure
-       configurations: size, ptrs
-               1,0     2,0     3,0     4,0     5,0
-               1,1     2,1     3,1
-                       2,2
-                               3,3
-                                       4,4
-                                               5,5
-                                                       ...
-                                                               11,11
-
-       GEN_INFO_TABLE(table_name,entry_code,size,ptrs);
-
-       Declares an info table that uses generic code fragments and
-       places data to drive these routines in the info table.
-       These are available for all combinations of size,ptrs (even
-       those for which SPEC routines are provided).
-       
-
-       STATIC_INFO_TABLE(table_name,entry_code);
-
-       Declares an info table suitable for a static closure.
-
-
-       DATA_INFO_TABLE(table_name,entry_code);
-
-       Declares an info table suitable for a data closure.
-       This closure contains no heap pointers and its size
-       (of data and size field) in its first word
-
-               See NOTES.arbitary-ints
-
-
-       IND_INFO_TABLE(table_name,ind_code);
-
-       Declares an info table suitable for an indirection.
-       But see below !! (ToDo)
-
-
-Using a Particular Garbage Collection Scheme
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When deciding which collector to use there are two decision points.
-
-At compile time it must be decided which code fragments are going to
-be attached to closures. This will limit the possible choice of GC
-schemes at run time.
-
-To compile the GC code and compiler-produced C Code for a particular
-set of code fragments an appropriate define (-D) directive is given
-to the compiler.
-
-Possible directives are:
-
-                       Code Fragments          GC Control Routines
-
--DGC2s                 Copying                 Two Space Collection
-
--DGC1s                 Marking & Compacting    Inplace Compaction
-
--DGCdm                 Copying, Marking        DualMode Collection
-                        & Compaction             (+ TwoSpace and Compaction)
--DGCap                 Copying, Marking        Appels Collector
-                        & Compaction             (+ Compaction)
-
-If none of these are defined the result will be No Collection Schame.
-Heap will be allocated but the program will die if it is ever filled.
-
-Other Directives:
-
--D_GC_DEBUG            Provides detailed GC debugging trace output
-                       (if showGCTrace set)
-
-Note that the GC code will eventually be set up already compiled for
-the different schemes and all that will be required will be to link
-with the appropriate object files. The compiler produced C will still
-need to be compiled with the appropriate define.
-
-
-Trace and Statistics Info
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-There are a couple of variables that can be set to provide info about
-GC.
-
-showGCTrace -- Provides detailed trace of GC and closure movement
-       TRUE -- Summary about GC invokation and heap location
-       & 2 -- Detailed trace of copying AND compacting collection
-       & 4 -- More detail about linked location lists during compaction
-       & 8 -- Detalied info about marking
-
-       The & options are only available if compiled with -D_GC_DEBUG
-
-showGCStats -- Provides summary statistics about GC performance
-      (ToDo)
-
-ToDo: These should eventually be able to be set by runtime flages
-
-
-Compiler Extensions Required for Compacting Collection
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-There are a number of additional requirements required of the STG
-machine and the resulting C code for Inplace Compaction to work.
-
-The most important and awkward arises from the fact that updated nodes
-will be scanned. This requires updated nodes (blackholes, indirections
-or inplace updates) to know how big the original closure was (so the
-location of the next closure can be determined).
-
-Implications (Suggestions -- Still to be done):
-
-   Need specialized black holes info pointers which know their size.
-
-   Code on the Update Stack needs to know the orig closure size. Either
-   record this size or have specialised update code fragments.
-
-   Updated closures need to know orig size. Possible solns are:
-
-       Create dummy garbage closures at the end to fill the hole.
-
-       Store size of closure in free space beyond and have GC
-       routines which look here for the size.
-
-       Specialised indirections that know their size.
-
-   May be able to search beyond the end of the closure for the next
-   info pointer. Possibly blanking out the unused portion of the
-   closure.
diff --git a/ghc/docs/NOTES.import b/ghc/docs/NOTES.import
deleted file mode 100644 (file)
index 30e65c4..0000000
+++ /dev/null
@@ -1,90 +0,0 @@
-               Notes on imports
-               ~~~~~~~~~~~~~~~~
-               SLPJ 15 March 91
-
-
-Distinguish three kinds of things in interfaces:
-
-       - type, data, class, instance, value decls at top level
-
-       - the same but imported.  Syntax
-               import B renaming C to D where
-                       data C = ...
-
-       - imports, which serve just to attach original names
-               import B(X,Y)
-
-
-The third group are syntactically stuck at the beginning; the second two
-can be intermingled.
-
-Pass 1
-~~~~~~
-Process each imported interface, and the implementation being compiled,
-scanning *headers of*
-
-       type, data and class decls (incl imported ones in interfaces)
-
-giving the following environments for each
-
-       type/data info  {(ModStr,TyConStr) -> arity}
-       class info      {(ModStr,ClassStr)}
-
-These are filtered (*but not renamed*) by the imports specified in the
-impl (ignore dotdot parts and parts in parens), to give a grand
-environment E1 of the same shape.  It gives the original names of in-scope
-types and classes.
-
-Pass 2
-~~~~~~
-Process each imported interface and the implementation being compiled:
-       
-       - scan its imports and use them to filter and rename E1, to give
-
-                       {TyConStr -> arity}
-                       {ClassStr}
-
-       - scan type, data, class decls, headers of instance decls
-         and value type sigs in interfaces
-
-giving for each:
-
-       class info (CE)         {ClassStr -> (ClassId, [ClassOpStr])}
-       inst info (GIE)         {(ClassId,TyConId) -> (Context, GlobalId)}
-               (info from both class and instance decls)
-
-       type/data info (TCE)    {TyConStr -> (TyConId, [ConstrStr])}
-
-
-       value info (GVE)        {ValStr -> GlobalId}
-               (info from value sigs, and constructors from data decls)
-
-Filter and rename the environments gotten from each import to make a grand
-environment E2. 
-
-Pass 3
-~~~~~~
-Check E2 for class cycles, and type synonym cycles.
-
-Pass 4
-~~~~~~
-Process the value decls in the impl, giving {ValStr -> GlobalId}, and some
-code.
-
-Pass 5
-~~~~~~
-Process the bodies of instance decls, to generate code for methods.
-
-
-
-
-
-
-               UNRESOLVED
-               ~~~~~~~~~~
-1. Who generates the interface?
-
-2. Where is dependency analysis done?
-
-
-
diff --git a/ghc/docs/NOTES.interface b/ghc/docs/NOTES.interface
deleted file mode 100644 (file)
index dfe2d61..0000000
+++ /dev/null
@@ -1,54 +0,0 @@
-
-What gets done when printing an interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Basically, we do three things:
-
-A) Create the import decls. For classes and values, this is easy. We
-   filter the CE and GVE for all exported objects that were not declared 
-   in the module. For types, this is a pain because we may have something
-   which is exported and which refers to a type that isn't. For example,
-   the interface
-   interface C where
-   ...
-   f :: A -> B
-   may export B, but A may be expected to come from somewhere else when
-   C is imported. So, we have to go through all envs which have ranges that
-   may refer to a type. This means the TCE, CE (the class op types), 
-   GIE_inst (instance types) and GVE (types in the sigs). AND we have to
-   filter out prelude defined types from the resulting list.
-
-   Finally, we print the import decls, using the conventions that the renamer
-   expects (no explicit constructors/ class ops, etc.)
-
-B) Print the fixity decls for whatever constructors/ functions are exported
-
-C) Print the rest of the decls needed. 
-       1) Type decls - contents of TCE with export flags
-       2) Class decls - contents of CE with export flags
-       3) Instance decls - contents of GIE_inst that refer to either
-                            an exported type or an exported class
-                            (filter then print)
-       4) Value decls - contents of GVE which are not constructors and
-                         which have an export flag
-
-Issues
-~~~~~~
-
-Type synonyms - to expand or not? Let's not, and complain if a type sig. is
-               used but not defined
-
-Canonical form for interfaces - to get rid of perl post-processing!
-
-Deriving for an abstract data type - shall we worry about this now or later?
-
-Printing issues
-~~~~~~~~~~~~~~~
-
-It's convenient to make all ranges of environments know how to print themselves
-(they do now) and decide whether to do so by looking at the export flag
-in their Name fields. Presumably the constructors of a data type that is
-exported abstractly will decide not to print themselves, so no special code
-is needed.
-
-
diff --git a/ghc/docs/NOTES.mkworld2 b/ghc/docs/NOTES.mkworld2
deleted file mode 100644 (file)
index 3969d82..0000000
+++ /dev/null
@@ -1,48 +0,0 @@
-Include order:
-
-# platform info
-#   discrim on "trigger" symbols in plat-TRIGGER.jm
-#   then slurp in plat-<platform>.jm
-#   *-GEN has defaults [if any]
-
-plat-TRIGGER.jm
-plat-<platform>.jm
-plat-GEN.jm
-
-# site overrides
-
-site-<project>-<setup>.jm
-site-<project>.jm
-site-GEN.jm
-
-# <thing>s just for a <project> and its various <setup>s
-
-<thing>-<project>-<setup>.jm
-<thing>-<project>.jm
-
-# things that many projects are likely to use
-
-<thing>-GEN.jm
-
-# finally, the directory-specific stuff
-
-Jmakefile
-
--------------------------------------------------------------------
-must specify platform explicitly
-setup "std", project "none": nothing included
-
--------------------------------------------------------------------
-<Things> that we have files for:
-
-rules:         macros related to the main "make" targets
-               excpt suffix, everything to make "make" do something is here
-               org by principal make target (all, install, etc.)
-
-suffix:                things to do w/ make suffix rules (i.e., implicit rules)
-
-utils:         utilities that are used in the build process
-               (where they are & default options for them)
-               (proj file must say which sysutils it wants)
-               (the proj files say whether src with or not ==> INeedXXX)
-install:       where things are installed, flags for installing
diff --git a/ghc/docs/NOTES.part-of-book b/ghc/docs/NOTES.part-of-book
deleted file mode 100644 (file)
index 551dd94..0000000
+++ /dev/null
@@ -1,73 +0,0 @@
-E.g., for the typechecker sources of the compiler.
-
-% cd compiler/typechecker/
-
-* make a Jmakefile that is NOT plugged into the overall make-world
-  system; it will probably look like this:
-
-------------------------------
-/* this is a standalone Jmakefile; NOT part of ghc "make world" */
-
-LitDocRootTargetWithNamedOutput(root,lit,root-standalone)
-------------------------------
-
-* make a "root file", root.lit, to glue the modules together.
-
-  At the beginning you'll have something like:
-
-    \begin{onlystandalone}
-    \documentstyle[11pt,literate,a4wide]{article}
-    \begin{document}
-    \title{The Glasgow \Haskell{} typechecker}
-    \author{The GRASP team}
-    \date{October 1991}
-    \maketitle
-    \tableofcontents
-    \end{onlystandalone}
-
-    \begin{onlypartofdoc}
-    \section[Typechecker]{The typechecker}
-    \downsection
-    \end{onlypartofdoc}
-
-  At the end of the file, you'll need something like:
-
-    \begin{onlypartofdoc}
-    \upsection
-    \end{onlypartofdoc}
-
-    \begin{onlystandalone}
-    \printindex
-    \end{document}
-    \end{onlystandalone}
-
-  In between, simply \input all the modules, possibly adding some
-  sectioning hierarchy:
-
-    \section[Typechecker-core]{Typechecking the abstract syntax}
-    \downsection
-    \input{XXXXXXX.lhs}
-    \input{YYYYYYY.lhs}
-    \upsection
-
-    \section[Typechecker-support]{Typechecker: supporting modules}
-    \downsection
-    \input{AAAAAAAAAAA.lhs}
-    \input{BBBBBBBBBBB.lhs}
-    \upsection
-
-* To make your Makefile, do:
-
-    % jmkmf -P ghc
-
-  (because of a bug, you may have to do it twice :-)
-
-* Then do "make depend".
-
-* Now you are ready for business:
-
-    % make root.info
-    
-    or
-    
-    % make root.dvi
diff --git a/ghc/docs/NOTES.rename b/ghc/docs/NOTES.rename
deleted file mode 100644 (file)
index cca2932..0000000
+++ /dev/null
@@ -1,109 +0,0 @@
-
-
-
-Questions concerning the meaning of hiding in certain contexts:
-
-1) Suppose we have the interface
-   interface A where
-   data T = B | C
-
-   and the module
-   module H where
-   import A hiding T
-
-   Should this be an error (because T isn't an abstract type in the module)
-   or does it just mean the same thing as would 
-   import A hiding (T (B,C))
-   or
-   import A hiding (T (..))
-   (in other words, hide all of T)
-   Will require the user to be precise and flag it as an error - otherwise
-   the user may not know that the type is not abstract, thinking that it is.
-
-2) Clearly, we can't allow (assuming the interface above)
-   module H where
-   import A hiding (T (B))
-
-   since that means that a data type with a subset of the constructors is
-   exported - similarly for classes
-
-3) Suppose an interface exports an abstract type H. Can H be referred
-   to as H (..), or is that an error? Let's require precision and call it
-   an error.
-
---------------- new design for renamer -------------------
-
-Changes to abstract syntax
-
-1) ClsSigs becomes Sigs
-
-2) Instances need new syntax (bool) distinguishing between those which
-come from an interface and those which come from a module. 
-
-The renamer is factored into four passes, as follows:
-
-1) FLATTEN INTERFACES -
-   insert original names into interfaces. All of the decls imported
-   from the interfaces are collected and returned, in an otherwise
-   unchanged module. No interfaces exist after this pass.
-
-2) Do consistency checks (equality). Return the module including the surviving declarations.
-
-3) build the global name function, which will maintain two separate
-   namespaces.
-
-4) assign names to the entire module, and do dependency analysis.
-
-As the prelude environments will yield names, the first pass will replace
-QuickStrings with constructors of the ProtoName type, defined as
-
-data ProtoName = Unknown QuickString
-                       -- note that this is the name local to the module
-               | Imported QuickString QuickString QuickString
-               | Prelude Name
-
-The parser will initially make all QuickStrings Unknown.
-
-Modules must now include signatures for value decls at top level.
-
-The entire set of passes have the following types:
-
-type PrelNameFuns = (GlobalNameFun, GlobalNameFun)
-
-type GlobalNameFun = ProtoName -> Maybe Name
-
-renameModule :: PrelNameFuns -> ProtoNameModule -> RenameMonad RenamedModule
-
-renameModule1 :: PrelNameFuns -> ProtoNameModule -> RenameMonad ProtoNameModule
-
-processModImports1 :: PrelNameFuns -> ProtoNameImportDecls 
-                        -> RenameMonad (ProtoNameFixityDecls, ProtoNameTyDecls, 
-                                        ProtoNameClassDecls, ProtoNameInstDecls, 
-                                        ProtoNameSigDecls)
-
-renameModule2 :: ProtoNameModule -> RenameMonad ProtoNameModule
-
-renameModule3 :: PrelNameFuns -> ProtoNameModule -> GlobalNameFun
-
-renameModule4 ::  GlobalNameFun -> ProtoNameModule -> RenameMonad RenamedModule
-
-renameModule :: PrelNameFuns -> ProtoNameModule -> RenameMonad RenamedModule
-renameModule pnf mod 
- = (renameModule1 pnf mod)     `thenRenameM` (\ mod_with_orig_interfaces ->
-   (renameModule2 mod_with_orig_interfaces) 
-                         `thenRenameM` (\ mod_minus_interfaces ->
-   (renameModule3 pnf mod_minus_interfaces)
-                         `thenRenameM` (\ global_name_fun ->
-   (renameModule4 mod_minus_interfaces global_name_fun))))
-
-Namespace confusion: According to the report (1.1), `An identifier must
-not be used as the name of a type constructor and a class in the same 
-scope.' This is apparently the only constraint on the namespace, other
-than those implied by the conventions for identifiers. So, what are the
-namespaces? 
-
-1) variables and class operations, constructors
-
-2) type constructors and classes (because of the statement above)
-
-
diff --git a/ghc/docs/NOTES.saving-space b/ghc/docs/NOTES.saving-space
deleted file mode 100644 (file)
index cd43c37..0000000
+++ /dev/null
@@ -1,250 +0,0 @@
-Ways to save code space
-~~~~~~~~~~~~~~~~~~~~~~~
-SLPJ/BOS 16 Sept 94
-
-
-
-
-
-Heap entry points
-~~~~~~~~~~~~~~~~~
-We have lots of thunks of the form
-
-       let
-          x = f p q r
-       in ...