Writing a compiler

M

MadDoc

Registered
Hi,

I have aspirations to write my own programming language. I appreciate that it is a big undertaking but seeing projects such as METAL basic have inspired me.

I am only a hobbyist programmer but am pretty much fluent in both Visual BASIC and RealBASIC. Is it possible to write a compiler with an OOP language such as one of these or can one ONLY be written in C? How can I go about learning the concepts behind writing a programming language (web resources preferable - small budget!)?

Many thanks,

MadDoc,
 
Think about it a little more, what's you're real goal? Do you want to make a compiler or an interpreter. Let me illustrate the differences. You can make an interpreter in pretty much any language. It just has to be able to take input - either directly or from a source file - and manipulate text to parse the code.

Writing an interpreter would be easier and a good place to start. All it's doing is reading a script and acting it out. A compiler is much more sophisticated, so yes I would recommend learning C and even Assembly. You'll also need to really understand what a compiler actually does. There's a lot more to it than just parsing source code and assembling instructions. You'll need to understand the Mach-O executable format, how it's structured and how OSX loads those binaries. If you're making a completely new language then it'll also need a linker to accompany the compiler.

Again, ask yourself what purpose your new language will have. Will it just be for scripting, or are you ready to make stand-alone binaries?
 
Thanks for the reply lycander.

I have been doing a little research, and I think an interpreter is what I am after. I would like to write a BASIC-like language that other people can use to write their own programs. If I go for an interpreter - does this mean that people will not be able to use the programs they write as stand alone programs?
 
To go along with what Viro is saying, here's a model just to give you a visual idea.

Runtime interpreter, or also known as Virtual Machine.

When you double click on a file, lets say a text document, your text editing program opens up and displays the contents of the file. This happens with each file type association. If a file type is associated with a program, then that program will be used to view that file.

Now if you were to create a new file type, it can be a plain text file or an encrypted file (to protect the source code if necessary), associate that file type with your interpreter program so that every time the user double clicks on the script file, your interpreter launches and executes the script.

If your interpreter is a Carbon or Cocoa program, capable of creating windows and controls, then your new dev environment will be capable of making GUI programs as well.
 
My compiler class in college involved a lot of work with Lexx and Yacc to parse our "language" (it was extremely simplistic) and then covert them into assembly which could then be passed to another program to covert it into machine code. I never actually got to the assembly part, it took me the whole semester to get my error checking statements and tree-building phases working....

... that class gave me nightmares.
 
I did two courses in interpreters and compilers. We used 'Flex' and 'Bison' (which I think are the latest versions of the packages you mention).

The second course involved producing java-like bytecode, and I assure you that 'compiling' is one of the only projects in CS that includes so many subjects in so many complex areas of CS that it is mind-boggling. ::evil::

To further guide original poster: Yeah, writing an interpreter would be a good start (far easier than a compiler). Be prepared to be *very patient* about it , though.

However, don't despair, you can start up with very simple languages and go learning (first, a simple calculator language, then having variables, a stack... up to a full programming lang.).

There's an interesting opensource package in Java which you could use, it's called ANTLR, look it up in freshmeat.net or google. Take a look at it.

dani++

btoth said:
My compiler class in college involved a lot of work with Lexx and Yacc to parse our "language" (it was extremely simplistic) and then covert them into assembly which could then be passed to another program to covert it into machine code. I never actually got to the assembly part, it took me the whole semester to get my error checking statements and tree-building phases working....

... that class gave me nightmares.
Click to expand...
 
Some languages don't really possess a compiler - Eiffel is typically compiled to C; then the C is compiled to machine code. A big advantage is that there's hardly a CPU out there that doesn't have a C compiler.

So you write one Eiffel-to-C 'compiler' and you get compatibility with about any CPU you could name as a sort of bonus.

Apparently C++ started out as a sort of language hack that was reduced to C by the preprocessor, then compiled as perfectly ordinary C.
 
You must log in or register to reply here.
Back
Top