Asking this again, compiler

How would I write a compiler? gimme an overview, general info, relating to any language (really want to make one in VB, or at least dElphi)

A compiler written in VB is a horrible idea. It would take an annoyingly very long time to compile big programs.

(I tend to view VB as a slow, bulky giant. If you disagree, you are wrong. ;))

A little general info:

A compiler, very basically, translates the source code from the given language to a symbolic language, which uses the same function names, variable names, etc. that you used in your code - but is already structured in some kind of machine-readable format, rather than the human-readable source code.

(The following applies assuming the language discussed isn't an interpreted byte-code language such as Java:)
A linker, which often comes together with the compiler, translates this symbolic language to platform-dependent machine code. The machine code doesn't contain the function and variable names that you used. Also, the linker optimizes the code for the target machine, possibly depending on any optimization options specified.

Writing a compiler requires a lot of work not only in interpreting source code in the given language (difficulty of this varies depending on the complexity of the language - interpretation is pretty easy for very simple languages, such as Brain*****, and extremely difficult for very complex languages, such as C++), but also in translating the code to a linkable byte-code, which would cover all cases defined by the language you're implementing. This often requires deep knowledge of the target platform (if any).

I am taking a compiler class... I would recommend you do the same. Writing a *good* compiler/interpreter is not as easy as you think.

First off you need to learn BNF. This allows you to create the *grammar* for your language.
example:

Program->stmt_list
stmt_list->stmt ; stmt_list | E
stmt->assign | selection | command
...
selection->if rel_expr then stmt_list one_two
one_two->fi | else stmt_list fi
...

The above is a little snippet of a psuedo matlab BNF.
One you do this you use the first() and follow() set and put together a parse table. Once you have created your table, you can then use that to see if the grammar is correct for your program... but this does not prove the semantics is 100%. This is of course one way to do this. There are many different algorithms to use.. LL Parsing, LR Parsing.. etc. We are using a bottom up method here.

Here is another example of how this applies:
F->[RR']
R'->;RR'|E
R->eE'
E'->,eE'|E

F-> [RR']
[eE'R']
[eR']
[e;RR']
[e;eE'R']
[e;eR']
[e;e]

This applies for input in this form.. ex: [4;15]
follow(R')={]}
first(R')={;,E}

Look up these words: Lexemes / Tokens / Terminal / Non-Terminal

Then you have to do *Type Checking*... but basically after you do all this crap you need to think about how you want your *compiler* to work. Do you want it to Compile or Interpret only? Lets go with compile for this example. You are going to want to convert your code into a real or psuedo assembly language. You must have a very very good understanding of asm for this to work.
Once you get your asm code, you convert that to HEX. The HEX code is platform dependant. So lets say I am coding for a P3 or 8051 microcontroller... the hex codes might be different.. and your asm might also... ok.. anyways.
example:
asm: stop: sjmp stop
hex: 80 FE
bin: 1000 0000 1111 1110
then you can convert your hex to machinery language. You will probably create a table of all of this stuff in your compiler to look up how to convert everything.
The hard part about creating a compiler is converting your language into a form that the processor likes, asm.

--------------------------
I know you probably have no clue of *** I am talking about with the lex. analyzer above.. or maybe any of it... but that is not the point. You have a sense of how it works now... you know the keywords so you can look this stuff up on your own... and you realize it is not an easy task. I left out a *lot* of stuff here.

Compilers: Techniques, Principles, and Tools.
I think that is the title... read this book! It is an oldie but goody. I am trying to get my hands on it.. but it costs about 96 bucks... not bad for a book written in the late 80's.

Also... vb is not the best language to write a compiler in because it is slow... but it will work. I like c++, but if you know vb.. go with what you know. You can skip all of the above stuff too.. about the BNF. just worry about converting your language to an asm language... once you can do that... the rest is just icing on the cake.

Quote:

---

(I tend to view VB as a slow, bulky giant. If you disagree, you are wrong. ;))

---

Heh... honest I suppose! ;)