question about RTL

[Mueller-Lehnitz at t-online dot de (Anja Müller)]

Hello Ladies and Gentleman,

We're Thomas and Anja. We're from Germany and we study informatics in
Berlin. We have some very important questions about the GCC. In this
semester we've got a very difficult task: we shall analyse the different
compiler passes of the GCC, especially wether there is a defined
interface between the parsing (syntax and semantic check) and the code
generator. If there is a defined interface, we shall use it as a basis
to implement own codegenerators, for instance for the 8051
microprocessor. So to explain it in another way: we shall try to program
another backend for the gcc, if it is possible.
We have already realized that the GCC uses a special language to be
independant from different machines: the so-called RTL - Register
Transfer Language. Our Question to you is:
Do you think that it is possible to use the RTL-Code to solve our
problem ? Therefore it is necessary that the RTL-Code, that is written
to the different Dump Files, is completely independent from the machine
type and especially from the succeeding passes of the GCC. Referring to
the documentation "Using and porting the GCC" (Chapter 15.18 Reading
RTL) it is an not feasible idea to use RTL as an interface for an
language frontend. But is it possible to use it as an interface for an
backend ?  At the beginning of the chapter is written, that during the
compilation of a program there is an internal and an textual form of the
RTL-Code: the internal form is a structure where the single RTL objects
are connected by pointers. The textual form is used by the machine
descriptions and is also written to the debuggings dumps.
Are the textual and the internal form completely independant from each
other ? Then is should be possible to interprete the debugging dump
files seperately for other target machines.

We've also read in this document that it is possible to expand the GCC
for new machine types by the machine description files. But we think,
that this way is to dfficult for us.

We hope to hear from you soon, because until now we don't know how to go
on solving our task. And we don't want to write a completely new
compiler for c.

We're looking o hear from you.

Kind Regards
Anja Müller, Thomas Schützkowski