Re: How hard is it to write a compiler ?

David Chase wrote:
>
> > Acutally, I am preparing a small business proposal for my management
> > class. I will be happy to get your advices on this.
>
> [It depends a great deal on the programmers. If you have really good
> programmers, two of them should be able to do either project in a year.
> If you don't, it'll take a dozen of them five years. -John]
>
> I am not sure about your estimate; I think it depends upon what
> you want the compiler to do, and the scope of the compiler.


Yep, anyone who has actually done this (including our moderator) would
agree totally with Mr Chase :-) It all depends on exactly what your
compiler is trying to do.


For example, if you're writing a simple Java compiler, just emitting
standard JVM bytecode, then you can pretty much bypass all
optimization, and you can definitely bypass doing the whole runtime
system, so that writing the parser and trivial code generator are all
that's needed. For this, and similar "simple unoptimizing compiler
only" cases, a couple of good programmers can do it in a year for most
realistic languages, or even less time if they've had previous
compiler writing experience.


It becomes especially quick if the language happens to be
yacc-friendly (ie not C++), or even better if you can use an existing
front end like gcc or lcc. At the extreme, you can port lcc to a new
target in less than a week, including testing, provided the target is
reasonably simple and code quality is not an important concern.


At the other extreme, just a single piece of a compiler, such as the
optimizer, is a good 10+ manyear project if your objective is to beat
all existing optimizers, and even more time if you're doing something
not well understood (eg parallelism, predication etc). I don't think
anyone, not even the best programmer alive, could write a serious and
complete state-of-the-art optimizer in less than 3-4 years.


And of course the whole project becomes larger in raw volume terms if
you have to also implement a runtime system, especially if its a
complex one, such as a virtual machine. For example, it's pretty clear
to me that implementing a Java compiler is a lot easier than
implementing the JVM, even if you go for a really trivial interpreter
for the core. The raw volume of the standard libraries is often
overlooked, especially for "big" standard libraries like Java's. The
same applies for writing a debugger, linker, and other support tools.


So I'd say the formula is something like "aggression * scope" where
"aggression" is the degree to which you want to beat the previously
known techniques or existing implementations (be it in optimization,
language features, development environment etc), and "scope" is the
raw size of the project in terms of number of distinct parts.


>> I was just wondering as for how many programmers one needs to design
>> C/C++ and the Java compiler.


Realistically, in your imaginary situation you would probably not want
to write a Java compiler at all, since there are already a couple of
free ones to choose from. The only reason to write a Java _compiler_
(rather than a Java JVM runtime) would be because you want native-code
output, not JVM bytecodes, and for this its easier to write a simple
translator from bytecodes than to write a proper Java compiler.


So I'm guessing you want native-code output from C++ and Java source,
for a new target architecture (embedded?)... In which case you
correctly picked gcc/gjc as a good starting point. For that, and
assuming no standard library and no debugger are required beyond what
gcc gives you, I'd guess it's probably a 1-2 manyear project, assuming
reasonably good programmers, to port gcc/gjc to a new architecture and
tune it for reasonably good performance.


But beware, it might be a bumpy ride... gcc tends to change underneath
you as time goes by, and gjc is not very reliable just yet.




JASON PATTERSON
  jason@pattosoft.com.au http://www.pattosoft.com.au/jason

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