Dear Colleague's
Hi!
I am Choudhary Harekrishna D at this end. I do not know the details of
a compiler ... and am planning to work one out. I need to know the art
of making of a compiler .... to make my question more clear let me say
that say someone built the fortran code ... and he runs it on the
appropriate compiler where the compiler finally computes and gives the
result... the language of fortran is understood by the compiler ...
Now, I want to write my own language and develop a compiler to
understand  that language .. so that I write my code and process it
.... write now have no know how of a compiler and hence for my work,
need to know the basic knowhow of the arts of building a compiler ....
and incase their exists any demos .. the minimum financial
requirements that takes to buid a compiler, the general time frame,
the manpower etc ... etc ...

First off, I can't answer your question. Second, do you know assembly
language? I think that you would have to know that, and then have to
associate every command possible in your language with an action in
assembly language that the CPU or whatever is to perform. I hope this
helps you.

making a compiler is a difficult process.. the basic idea is that you
create a set of operators and instructions that you as a human
understand... you would have to create a syntax that those commands
and operators are to be used in as well.. after you have the idea of
how you want your language to work you must write the compiler which
will take the "complex" "high level" code that makes up your language,
and breaks it down into machine code.  machine code can be described
in assembly. gcc, a C compiler, actually lets you see this being
done.. for instance, the following program:

#include <stdio.h>
void main (void)
{
  printf ("hello, world\n");
}

^^ simply prints "hello, world" to the screen

if i save that as "bob.c" and run it through gcc like this:

gcc -S bob.c

i get a file named bob.s which contains:

        .file   "bob.c"
gcc2_compiled.:
.section        .rodata
.LC0:
        .string "hello, world"
.text
        .align 4
.globl main
        .type   main , @function
main:
        pushl %ebp
        movl %esp,%ebp
        subl $8,%esp
        addl $-12,%esp
        pushl $.LC0
        call printf
        addl $16,%esp
.L6:
        leave
        ret  
        .size   main , . - main

which is the assembly equivalent.  from here the compiler assembles
the actual executable that can be understood by the machine. each
assembly command has an equivalent "opcode".  for instance, in
assembly the opcode "nop" -- which means no operation (and does
nothing actually) -- is the value 90 in hexadecimal.

i am no master in this area, but i do a little bit of programming
myself and at one time was into reverse engineering.
if you would like to check out the source code to some already written
compilers, you can check out gcc which you can get from here:

http://gcc.gnu.org/

that compiler, however, is fairly advanced so understanding it may be
a bit difficult.

i also found this article:
http://www.realworldtech.com/page.cfm?ArticleID=RWT041902173146

which does a pretty good job of describing the basic steps in detail.

good luck,
nate

@ a polytech university we learned to build a pascal compiler with
bare bone tools lex and yacc which today have open source equivalents.

you could create very simple lexicons and grammars to start with,
generate code in some language like c for where many (portable)
compilers like gcc exist.

A step further would be to try to create a (subset) compiler for a nice 
formal language like pascal to learn from.

Another direction to go is to generate your own machine code for a machine
to be developed?

Have to say that some theory knowlede is required on formal languages, sets, 
regulair patterns etc. 

After doing this stuff, programming in many languages might become
easier where for example the reason and pitfillas of reserved keywords
in a language might become clear. Then examine Smalltalk fur fun (has
only 15 syntactial elements,
minimal keyword hassle).
 

Check http://dinosaur.compilertools.net

The best place to start is with a good textbook. The classic in the field is

Aho, Sethi, Ullman, Compilers: Principles, Techniques and Tools,
Addison-Wesley, 1986. ISBN 0201100886

currently $96.00 new, but you can probably find second-hand copies.

It's a big sprawling book with more questions than answer, but it
covers all phases of compiler design from front-end all the way
through to back-end design. It also provides a much broader
perspective on compiler design than does the lex & yacc book
(describing, for example, LL grammar systems, and recursive descent
compilers, in addition to the LALR(1) grammar systems like Yacc).

Also a good choice: 

Mason,Levine,Brown, lex & yacc, O'Reilly Press, not sure of the latest edition.

about $30.00.

The recommended approach is to use GNU Flex, and GNU Bison (LGPL
versions of Lex and Yacc), or ATT Lex and Yacc. These are the classic
compiler building tools. There are also a number of freeware compiler
compilers that use LL(n) grammars that are usable.

Yacc and Bison both fall into a class of parsers known as LALR(1)
compilers (a technical term that you'll need to read up on before you
start). These compilers compilers are relatively easy to work with,
but have difficulties with certain kinds of grammar constructs. A lot
of work has been done since the Red Dragon book on LL(n) grammars,
which are more flexible.

There are also some good free LL(n) compiler-compilers on the Java
platform. If Java is ok, you may want to look into them.

Most of the work I've done has been on LALR(1) compiler compilers.
I've done some trial projects on LL(n) systems, but haven't been very
successful. That may just be because I'm a set in my ways. But I'd
recommend LALR(1) compiler compilers over LL(n) compiler compilers
anyway, for no other reason than that I have had some success with
LALR(1) systems.

Writing the front-end (the part that analyzes the grammar) for a
compiler is relatively easy, using the above tools.

The biggest problem with designing compilers is writting the back-end
(the part that generates actual machine code). There are no really
good off-the-shelf toolsets for back-end compiler building. However
there are a number of interesting alternatives. The easiest way to
write compiler back-ends these days is to write a translator, using
lexx and yacc, or flex and bison, that translate your language into
another standard language (such as C, C++, Java, C#) or back-end (e.g.
Microsoft.net CLR, or Java Bytecodes). Other alternatives are writing
your own custom byte-code interpreter, or trying to hook onto the GNU
compiler back-end systems, but these are both much more difficult.

How much time you spend really depends on what you are trying to do. 

A full blown language from scratch is a major undertaking. Designing a
full-blown language from scratch has a reputation for being one of the
most difficult challenges in the software industry. Many programmers
have foundered on this problem. Generally, only the very best succeed.

On the other hand, simple languages, or simple parsing problems can
sometimes be tossed off in hours or days, if you are familiar with the
tools.

Writing a command-line calculator is a couple of hours work. Writing
an interpreted language, where performance isn't an issue at all, is a
couple of weeks work. Writing a C compiler from scratch (with a
suitable off-the-shelf backend, excluding runtime libraries) is
probably a few months work. Writing a C++ compiler is probably several
years work.

Hope that helps.

A modern book which is a lot more suited to 'beginners' than the
classic books mentioned above would be "Virtual Machine Design and
Implementation in C/C++" by Bill Blunden (ISBN: 1556229038). Compiler
design is moving a lot more towards the area of virtualization these
days, particularly with the popularity of .NET, Java, and
pseudo-compiled languages like Perl.

While the older books will cover some of the more traditional ground,
the book I mention above covers everything from the system
architecture, through to developing a compiler, a run time machine,
and even an assembler and debugger. It is particularly well suited for
someone without significant computer science experience, but who wants
to give it a go anyway. Good luck!