CB> Actually, boot strapping implies starting with a very small and limited
CB> version and use that to compile a more complicated version.  After a
CB> couple of times, you've managed to write the entire compiler on a new
CB> machine with some very crude initial tools.
    Also one of the ideas behind bootstrapping (also used to describe a way
    linking the boot sequence of a machine to some other medium that a 
    boot drive [cdrom,network,etc]). The idea is a starting point (the boot)
    and linking (strapping) to some other entity.
CB> Many compilers were and are done the way you describe, including GNU C.
CB> Not all though.  Some never need or are intended for porting.  Those
CB> include things such as Borelands Turbo C, etc.
    I'm sure that portions of the compiler where re-used like the code
    generator and optimizer. Even if the compiler never leaves a platform,
    its backend portions can be re-used by any front end.
CB> Some newer, more sophisticated compilers aren't done that way either.
CB> From what I've heard, the types of optimizations and instruction
CB> reordering and RISCification/CISCification require too much knowledge
CB> sharing between the language parser, code generator and optimizor, and
CB> it's simply easier and more efficient to remove most of the portability
CB> and just 'be done with it'.
    RISC processors are a weird breed. They support such things as out-of-
    order executions, etc. An example is branching, the instruction after
    ther branch is executed first so its good to place a NOP after it. eg:
    target:
      inst 1;
      inst 2;
    brach condition target
      inst 3;
    Instruction 1,2,and 3 are executed before the branch is made. Also
    all instructions are word sized.
    Luckily, I only had to go through vax macro and not alpha architecture.
CB> To a degree.  The choice between coding for the array type indexing used
CB> or internally converting it to pointers has to be done a bit higher up.
    I've had to do a bit of array indexing for a compiler and it's a bitch.
    Zero based arrays are easier to implement.
    like x(d1,d2,d3,...,dn);
    where the offset is sn + sn-1 * dn
         + sn-2 * dn-1 * dn
         + s1*d2*d3*d4.....dn
    (where d = a dimension and s = the size of a dimension)
    example x(i,j,k)
    offset = k + (j* size(k)) + (i * size(j) * size(k))
    
    As you notice, there's alot wrong with multiply something by the same
    number and adding it into the "pot". This can be re-written to
    ((((s1*d2+s2) * d3 + s3) * d4+s4) * d5 + s5) * .........
    This changes the operation to be linear instead of exponential growth
    as the number of dimesnion increase.
CB> particular compiler.
CB> 
CB> As for the other type optimizations... Well, he was also using a 486, so
CB> that playing field was level.  The differences were caused by 1)
CB> differences in the compiler and the code the generate (most important)
CB> and 2) differences in the system (cache etc.) and 3) differences in the
CB> brands of 486 cpus.
    Not to mention the operating system. Once major example is that if
    compiler used column major arrays instead or row major indexing then
    each sequential access of an array would cause page faults left an
    right. Example
    for i = 1 to 10
         for j = 1 to 10
              c = c + array[i,j];
    Or if you should use your own version of disk caching or if the operating
    system uses its own. Example
        while not eof(file)
           read a character
    Reading a single character at a time is terribly slow method of 
etreiving
    data but it might be lightning fast if the OS reads a block of data at a
    time.
--- GEcho 1.00
---------------