new snapshot

[Stephen Weeks]

I just put a new snapshot at http://www.star-lab.com/sweeks/src.tgz
This is the aforementioned stable snapshot.  Here's some of the main changes
since 20001004.
  * Added many improvements to the CPS constant folding/algebraic simplification.
  * Split the runtime into many files so that executables are smaller.
  * Removed the defunctorizer.
  * Integrated the x86 floating point stuff.
  * CPS inliner improved to handle problem with mlyacc.  The inliner now uses
    a product metric to estimate code size increases, much like the polyvariance
    pass.  The -inline threshold now has a different meaning.

What I'd like to happen is for Henry to read the algebraic simplifications (fun
apply in atoms/prim.fun) and send me comments and for Matthew to integrate
overflow checking and his other recent improvements to the x86 code generator.
Once y'all get those back to me, I'll make new internal rpms, the first where
-native is the default :-).  Then, we can hopefully live with that for a month
or so and shoot for a release in January.

Matthew, here are some of the changes I made to your files
	x86codegen.h 
		Got rid of the mltonState stuff and changes to MLton_init.
	x86-codegen/x86-codegen.{sig,fun}
		Support for separate assembly files.
	x86-translate.fun 
		SmallIntInfs are gone, and are now explicitly words.
	x86-mlton.fun 
		Added new primitives IntInf_compare, IntInf_equal
		Also, you need to add Int_negCheck, which is a new primitive
		that could conceivably be generated by the algebraic simplier,
		but hasn't yet.

Also, I've changed the implementation and interface for properties.  There are
now two independent choices to make when creating a property.
	1. Do you want it to be destructable (yes or no).
	2. How do you want it to be assignable (not at all, set once, or set).
So, there are now 6 different possible ways of creating a property.  The reason
for all of this mess is that there are performance implications to make a
property destructable (an extra list element) and performance implications to
make it assignable more than once (an extra ref cell).  So, if at all possible,
you should choose to make your property not destructable and not assignable, or
at the worst assignable but not destructable.  

In any case, I went through any of your files that created properties and
changed them to use the new interface.  Since I didn't know how they were used,
I used the most conservative (and least space efficient) choice.  It would be a
good idea for you to go back through each place where you create a property and
decide which kind you want.  I marked all of these property creations with 
(* sweeks *)