Re: beagle compiler

["Michael J. Mahon" <mjmahon@aol.com>]

Paul Schlyter wrote:
> In article <mxIOg.12766$xQ1.3323@newsread3.news.pas.earthlink.net>,
> BluPhoenyx  <bluphoenyx@earthlink.net> wrote:
>
>
> > Michael J. Mahon wrote:
> >
> > > BluPhoenyx wrote:
> > >
> > > > Paul Schlyter wrote:
> > > >
> > > >
> > > > > You had Apple Pascal.
> > > >
> > > > As I understand the term, there is ZBasic, HyperC and Aztec C each of 
> > > > which offer a host environment and compiler. I rather liked ZBasic as 
> > > > it attempted to emulate the BASIC command line features such as 
> > > > calculations.
> > >
> > > But which, if any, of these compilers/enviroments was self-hosted
> > > (compiled using itself)?
> >
> > I think this may only apply to HyperC but I couldn't say for sure. IIRC, 
> > the doc's mention something about this. Since both C systems use byte 
> > code interpreters I would not be surprised if both were self-hosted. 
> > Without original source files we may never know.
> >
> > Cheers,
> > Mike T.
>
>
>
> Now - how does one get the very first version of a self-hosting compiler
> to work?   :-)

There are many different routes that can be taken to "bootstrap" a
compiler running on one machine onto another machine.

The most common for a "native code" compiler is to rewrite the code
generator for the compiler on the "host" machine to generate code for
the "target" machine.  When this version of the compiler is used to
recompile the compiler, it creates a native compiler for the target
machine.  The bootstrap is completed by recompiling the compiler on
the target machine and comparing the code file produced to verify
that it is identical to the one produced on the host cross-compiler.

If the existing compiler compiles to interpretive code, the interpreter
needs to be re-created for the target machine--usually by rewriting it
in assembly language for the target machine, since efficiency of the
interpreter (or "runtime") is critical to the overall efficiency of the
port.  Once the interpreter is ported to the target machine, most of
the work is done, since it can directly interpret the "code" of the
compiler and anything it compiles.

In the less frequent situation of writing a compiler for a language
for which no compiler (on any machine) is available, the strategy is
somewhat different.

Any language can be used to write the "first" compiler, from machine
language to another quite different high-level language.  Popular
approaches are similar (or dissimilar, but widely available) high-level
languages (FORTRAN used to be popular, believe it or not!) or a "pidgin"
version of the new compiler's language (which may be "compilable" using
a macro processor, for example).  This process can be done natively on
the target machine or cross-developed on a host.  The only requirement
is that it be capable of making a version of the compiler that can be
run on the target machine.

It is then possible to transform (or re-write) the source of the
compiler into a form that it can compile.  This is the beginning
of an iterative process of growing the content of the compilable
language and growing the use of those extensions in the compiler
source, resulting eventually in the full version of the self-hosted
compiler.

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."