On 14/06/2012 04:05, Chris Jones wrote:
David Brown wrote:
On 11/06/2012 09:45, Chris Jones wrote:
Is it possible to modify the source code of gcc to enable to compilation
of a completely new programming language, as yet unrecognized? How much
of a big job would I be looking at for such a task?
I would think that would depend entirely on the language you want to
implement. If your language has similar principles to existing gcc
languages, then most of the middle-end and back-end could be left
untouched. But if it has major differences, you might need to change
gcc in all sorts of difficult places.
I guess the best guide here would be to look at the integration of Go
into gcc - I believe it is the most recent addition to gcc.
You could also consider a stepping stone of making a translator
between your new language and C (or C++, D, Go, etc.), then using gcc
to compile the C code. It is not going to be optimal, but it could be
useful in developing your language, testing the concepts, developing
the libraries, etc. And it will also help answer your question - if
you can make a reasonably efficient translator to C (using any gcc
extensions as needed), then you can expect a reasonably
straightforward job in writing a gcc front-end to the language. But if
you find concepts that are particularly alien to C, then you are going
to have a bigger job writing a gcc front-end.
(Note that my opinions here are based on zero experience of developing
new languages, just on my thoughts and observations about the processes,
having observed the creation and development of a few languages.)
So it seems I have two options really. Use a translator to implement my
language with gcc. Or I could develop a new front-end for it to
integrate it into gcc. Am I right?
I don't see these as a choice of two options - I see them as "phase 1"
and "phase 2" of making a compiler. You might also want to include a
"phase 0", which would be an interpreter. Phase 0 and 1 should be
written in a language like Python - performance is totally irrelevant,
but you want something that can easily and naturally work with strings,
dictionaries (hashes), etc., and can be quickly modified.
When you are developing a new language, your main effort has to start
with the language - how it is put together, and how it will work in
practice. So the bulk of your thoughts for now should go in that
direction. You need either an interpreter or a simple language-to-C
translator so that you can get a feel for your language in practice -
this will be changed over time as you develop the language.
Also, my new language is completely written from scratch and is nothing
like any other language currently available.
http://simpledictionarylanguage.weebly.com
It's currently in very early stages and is not yet anything workable,
but development is coming along nicely. But I need to know how I'm gonna
compile the eventual code with gcc before I get myself in too deep. At
least now in the early stages, I can change my development path pretty
easily.
Worrying about a gcc implementation at this stage is premature.
In fact, I would suggest that thinking about being able to compile at
all is premature - especially if your language is very unusual. There
are many alternatives, including interpretation and byte-compiling for
existing virtual machines (JVM, Python PyPy, Perl Parrot, osv.) or your
own virtual machine. If you do end up compiling, then gcc is only one
option - the other obvious choice would be LLVM. There are also more
unusual choices for borrowing an existing compiler, such as the Glasgow
Haskell Compiler or the oocaml tools (which might be a better fit if you
have functional programming style constructs).
I presume that you have more information about your language than is
available via that weblink. My thinking is that you should be building
up an information site, with background for the language, what problems
you see it solving better than existing languages, how the language is
structured, example programs, etc. Then it will be possible to give
more informed suggestions about the best way to implement it.
mvh.,
David