Subject: Summary of first meeting decisions...

We decided in general to keep things simple to make the initial
implementation phase short, allowing us to get to more interesting things
later.  In this respect, we decided to:

 * Implement a copying garbage collector.  This was determined to be the
   simplest performant GC to implement.
 * Represent numbers and pointers distinctly, marking pointers as such with
   the low order bit set to one.  This gives integers a range of 2^31, and
   means that integer mul/div need to be adjusted by 2x.  Indexing off
   pointers requires an additional offset of 1 to work correctly.
 * Provide three distinct memory spaces (not counting the stack):
    1. Normal GC'd space that does not provide "root"s.  This is the only
       space that stuff is moved around in.
    2. A permanent space that is set up by the compiler.  This region is
       used for objects that may contain references to other objects.
       This region would be used to hold things like global references
       (implemented as one big object that contains all of the global
       variables).  Having this be in a distinct space from 1 allows it to
       not be compied around a bunch.
    3. A memory space that is also permenant and set up by the compiler,
       but that does not contain references to other objects (and may not
       be modified by the user).  The idea being that constant strings
       (and other objects, etc...) should not be GC'd, nor should anyone
       bother to check to see if they have references.  This will be
       mandatory one OOP is implemented, because vtables (as an example)
 * Plan to add OOP, which is one of the things Chris really wants to do.
 * Plan for a GC, because it will make our lives easier later.
 * Plan to be able to interface with native C code, to allow extensions to
   be written in C as well as implement the runtime in C.  Note that the C
   functions would have to be specially written to follow conventions for
   the GC to work correctly.

 * Because we cannot index off of the ESP register, we decided to
   sacrifice the EBP register to hold the base pointer as in C.  This will
   make interfacing to C code easier as well as...
 * The GC code will walk to EBP chain to scavage information about object
   references in the stack.  Because we know where the return addresses
   are, we can avoid treating them as object references.
 * Additionally, Chris speculates that the EBP chain would be the natural
   way to implement access links.

 * Nick will be the main implementor of the IR layer, Chris will implement
   the IR->i386 compiler.

-Chris