Re: self-hosting, was Writing A Plain English Compiler

"Richard Hable" <portempa@aon.at> wrote in message
> On 11/09/14 02:16, BartC wrote:
>
>> Self-hosting (implementing a language in itself) is a nice touch, but
>> I don't think it's that important, perhaps because people are
>> realising that the best language to implement a compiler in, is not
>> necessarily the language that is being compiled. Unless of course you
>> are trying to use a single language for everything.)
>
> I think, the main advantage of self-hosting is that it can be used as
> one big unit test: you can compile the compiler with itself, use the
> resulting compiler to compile itself again, and check if the result is
> exactly the same.


Yes, that's partly what I do, because I don't have any substantial
non-compiler, non-language and non-development related applications to try
different versions on.


It does, however, run into problems, such as frequently ending up with
non-working compilers and/or support programs, and with most of the bridges
burnt! Then recovering can be tricky.


It is possible to compile a compiler with itself, and perhaps even repeat
that again, but still end up with something that apparently still works, but
has now developed a bug. Perhaps because it affects some code that is not
executed in the compiler, because the particular language construct to
invoke the bug doesn't occur in the compiler source.


(My setup is a bit awkward to describe, but:


I have an interpreted language M that compiles to bytecode. Its compiler is
written in M.


I have a statically typed language B that compiles to native code. Its
compiler is also written in M.


To run any M bytecode programs, I use an interpreter written in B. So there
are a few cyclic dependencies and you can imagine the fun and games when
some subtle bug gets past or I skimp on testing when I make changes. The bug
can be in either compiler (or in the generated bytecode or native code), or
in the interpreter.


To help out however, I also maintain a version of the interpreter written in
C. (Or near enough C, as I use a slightly different syntax, put through a
simple translator, to end up as proper C. That translator is written in
M...)


BTW if anyone is wondering how well an interpreted compiler performs, this
one can compile itself in about 1.3 seconds on a low-end PC. But it's
divided into modules and the biggest one takes about 1/6th second to
compile. The whole thing isn't very big, about 20Kloc, so the compiled
lines-per-second isn't great, but it's not a problem at the minute.)


--
Bartc
[It's time to reread Ken Thompson's Turing award lecture,
available here: http://cm.bell-labs.com/who/ken/trust.html
-John]

Return to the comp.compilers page.
Search the comp.compilers archives again.