This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: question about RTL


> If there is a defined interface, we shall use it as a basis to
> implement own codegenerators, for instance for the 8051
> microprocessor. [...]
> Do you think that it is possible to use the RTL-Code to solve our
> problem ?

Yes, that should be possible. Very much depends on the details of the
processor, though: For example, gcc has problems dealing with
segmented memory.

> 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 ?

Most definitely. GCC has been ported to a large number of processors
(see the subdirectories of gcc/config). All those back-ends use the
same RTL structures.

> Are the textual and the internal form completely independant from each
> other ? 

What do you mean: independent? Given one, you can construct the other
(with a certain set of restrictions).

> Then is should be possible to interprete the debugging dump files
> seperately for other target machines.

Well, I very much doubt that GCC supports re-initialisation from a
dump. Instead, starting from source code, passing it through the
front-end and the middle-end passes, is the only way that is
officially supported.

> 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.

I believe this is the only reasonable way to port gcc. You absolutely
*have* to write a machine description, telling the compiler how to
convert RTL structures into assembler statements.

I believe this is much simpler than it sounds (although, being a
front-end person, I never tried myself). Just take the machine
description of a processor you are familiar with, and try to
understand it.

Also, you probably can restrict the description to a minimum: Much of
the .md functionality is optional, and depends on the processor having
a certain set of features. GCC will not generate certain RTL
constructs if the back-end does not support them.

> 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.

Well, you don't have to write a new compiler for C. Ideally, when you
have the back-end defined, you immediately get a C compiler, a C++
compiler, and a Java compiler (not to mention the CHILL, Pascal, and
Ada compilers).

Viel Glück,
Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]