treelang.texi

来自「理解和实践操作系统的一本好书」· TEXI 代码 · 共 1,311 行 · 第 1/3 页

In a non-Treelang installation, @code{gcc} recognizes C, C++,
and Objective-C source files.

In a GNU Treelang installation, @code{gcc} also recognizes Treelang source
files and accepts Treelang-specific command-line options, plus some
command-line options that are designed to cater to Treelang users
but apply to other languages as well.

@xref{G++ and GCC,,Programming Languages Supported by GCC,GCC,Using
the GNU Compiler Collection (GCC)},
for information on the way different languages are handled
by the GCC compiler (@code{gcc}).

You can use this, combined with the output of the @samp{gcc -v x.tree}
command to get the options applicable to treelang.  Treelang programs
must end with the suffix @samp{.tree}.

@cindex preprocessor

Treelang programs are not by default run through the C
preprocessor by @code{gcc}. There is no reason why they cannot be run through the
preprocessor manually, but you would need to prevent the preprocessor
from generating #line directives, using the @samp{-P} option, otherwise
tree1 will not accept the input.

@node Compiler, Other Languages, TREELANG and GCC, Top
@chapter The GNU Treelang Compiler

The GNU Treelang compiler, @code{treelang}, supports programs written
in the GNU Treelang language.

@node Other Languages, treelang internals, Compiler, Top
@chapter Other Languages

@menu
* Interoperating with C and C++::  
@end menu

@node Interoperating with C and C++,  , Other Languages, Other Languages
@section Tools and advice for interoperating with C and C++

The output of treelang programs looks like C program code to the linker
and everybody else, so you should be able to freely mix treelang and C
(and C++) code, with one proviso.

C promotes small integer types to 'int' when used as function parameters and 
return values in non-prototyped functions.  Since treelang has no
non-prototyped functions, the treelang compiler does not do this.

@ifset INTERNALS
@node treelang internals, Open Questions, Other Languages, Top
@chapter treelang internals

@menu
* treelang files::              
* treelang compiler interfaces::  
* Hints and tips::              
@end menu

@node treelang files, treelang compiler interfaces, treelang internals, treelang internals
@section treelang files

To create a compiler that integrates into GCC, you need create many
files.  Some of the files are integrated into the main GCC makefile, to
build the various parts of the compiler and to run the test
suite.  Others are incorporated into various GCC programs such as
@file{gcc.c}.  Finally you must provide the actual programs comprising your
compiler. 

@cindex files

The files are:

@enumerate 1

@item
COPYING.  This is the copyright file, assuming you are going to use the
GNU General Public License.  You probably need to use the GPL because if
you use the GCC back end your program and the back end are one program,
and the back end is GPLed.

This need not be present if the language is incorporated into the main
GCC tree, as the main GCC directory has this file. 

@item
COPYING.LIB.  This is the copyright file for those parts of your program
that are not to be covered by the GPL, but are instead to be covered by
the LGPL (Library or Lesser GPL).  This license may be appropriate for
the library routines associated with your compiler. These are the
routines that are linked with the @emph{output} of the compiler.  Using
the LGPL for these programs allows programs written using your compiler
to be closed source. For example LIBC is under the LGPL. 

This need not be present if the language is incorporated into the main
GCC tree, as the main GCC directory has this file. 

@item
ChangeLog.  Record all the changes to your compiler.  Use the same format
as used in treelang as it is supported by an emacs editing mode and is
part of the FSF coding standard.  Normally each directory has its own
changelog.  The FSF standard allows but does not require a meaningful
comment on why the changes were made, above and beyond @emph{why} they
were made.  In the author's opinion it is useful to provide this
information.

@item
treelang.texi.  The manual, written in texinfo. Your manual would have a
different file name.  You need not write it in texinfo if you don't want
do, but a lot of GNU software does use texinfo. 

@cindex Make-lang.in
@item
Make-lang.in.  This file is part of the make file which in incorporated
with the GCC make file skeleton (Makefile.in in the GCC directory) to
make Makefile, as part of the configuration process.

Makefile in turn is the main instruction to actually build
everything.  The build instructions are held in the main GCC manual and
web site so they are not repeated here. 

There are some comments at the top which will help you understand what
you need to do.

There are make commands to build things, remove generated files with
various degrees of thoroughness, count the lines of code (so you know
how much progress you are making), build info and html files from the
texinfo source, run the tests etc.

@item
README.  Just a brief informative text file saying what is in this
directory. 

@cindex config-lang.in
@item
config-lang.in.  This file is read by the configuration progress and must
be present. You specify the name of your language, the name(s) of the
compiler(s) including preprocessors you are going to build, whether any,
usually generated, files should be excluded from diffs (ie when making
diff files to send in patches).  Whether the equate 'stagestuff' is used
is unknown (???).

@cindex lang.opt
@item
lang.opt.  This file is included into @file{gcc.c}, the main GCC driver, and
tells it what options your language supports.  This is also used to
display help.

@cindex lang-specs.h
@item
lang-specs.h.  This file is also included in @file{gcc.c}. It tells
@file{gcc.c} when to call your programs and what options to send them.  The
mini-language 'specs' is documented in the source of @file{gcc.c}.  Do not
attempt to write a specs file from scratch - use an existing one as the base
and enhance it. 

@item
Your texi files.  Texinfo can be used to build documentation in HTML,
info, dvi and postscript formats. It is a tagged language, is documented
in its own manual, and has its own emacs mode.

@item
Your programs.  The relationships between all the programs are explained
in the next section.  You need to write or use the following programs:

@itemize @bullet

@item
lexer.  This breaks the input into words and passes these to the
parser.  This is @file{lex.l} in treelang, which is passed through flex, a lex
variant, to produce C code @file{lex.c}.  Note there is a school of thought
that says real men hand code their own lexers.  However, you may prefer to
write far less code and use flex, as was done with treelang.

@item
parser.  This breaks the program into recognizable constructs such as
expressions, statements etc.  This is @file{parse.y} in treelang, which is
passed through bison, which is a yacc variant, to produce C code
@file{parse.c}.

@item
back end interface.  This interfaces to the code generation back end.  In
treelang, this is @file{tree1.c} which mainly interfaces to @file{toplev.c} and
@file{treetree.c} which mainly interfaces to everything else. Many languages
mix up the back end interface with the parser, as in the C compiler for
example.  It is a matter of taste which way to do it, but with treelang
it is separated out to make the back end interface cleaner and easier to
understand.

@item
header files.  For function prototypes and common data items.  One point
to note here is that bison can generate a header files with all the
numbers is has assigned to the keywords and symbols, and you can include
the same header in your lexer.  This technique is demonstrated in
treelang.

@item
compiler main file.  GCC comes with a file @file{toplev.c} which is a
perfectly serviceable main program for your compiler.  GNU Treelang uses
@file{toplev.c} but other languages have been known to replace it with their
own main program.  Again this is a matter of taste and how much code you
want to write. 

@end itemize

@end enumerate

@node treelang compiler interfaces, Hints and tips, treelang files, treelang internals
@section treelang compiler interfaces

@cindex driver
@cindex toplev.c

@menu
* treelang driver::             
* treelang main compiler::      
@end menu

@node treelang driver, treelang main compiler, treelang compiler interfaces, treelang compiler interfaces
@subsection treelang driver

The GCC compiler consists of a driver, which then executes the various
compiler phases based on the instructions in the specs files. 

Typically a program's language will be identified from its suffix
(e.g., @file{.tree}) for treelang programs.

The driver (@file{gcc.c}) will then drive (exec) in turn a preprocessor,
the main compiler, the assembler and the link editor. Options to GCC allow you
to override all of this. In the case of treelang programs there is no
preprocessor, and mostly these days the C preprocessor is run within the
main C compiler rather than as a separate process, apparently for reasons of speed.

You will be using the standard assembler and linkage editor so these are
ignored from now on. 

You have to write your own preprocessor if you want one.  This is usually
totally language specific.  The main point to be aware of is to ensure
that you find some way to pass file name and line number information
through to the main compiler so that it can tell the back end this
information and so the debugger can find the right source line for each
piece of code.  That is all there is to say about the preprocessor except
that the preprocessor will probably not be the slowest part of the
compiler and will probably not use the most memory so don't waste too
much time tuning it until you know you need to do so.

@node treelang main compiler,  , treelang driver, treelang compiler interfaces
@subsection treelang main compiler

The main compiler for treelang consists of @file{toplev.c} from the main GCC
compiler, the parser, lexer and back end interface routines, and the
back end routines themselves, of which there are many.

@file{toplev.c} does a lot of work for you and you should almost certainly
use it.

Writing this code is the hard part of creating a compiler using GCC.  The
back end interface documentation is incomplete and the interface is
complex. 

There are three main aspects to interfacing to the other GCC code. 

@menu
* Interfacing to toplev.c::     
* Interfacing to the garbage collection::  
* Interfacing to the code generation code. ::  
@end menu

@node Interfacing to toplev.c, Interfacing to the garbage collection, treelang main compiler, treelang main compiler
@subsubsection Interfacing to toplev.c

In treelang this is handled mainly in tree1.c
and partly in treetree.c. Peruse toplev.c for details of what you need
to do.

@node Interfacing to the garbage collection, Interfacing to the code generation code. , Interfacing to toplev.c, treelang main compiler
@subsubsection Interfacing to the garbage collection

Interfacing to the garbage collection. In treelang this is mainly in
tree1.c. 

Memory allocation in the compiler should be done using the ggc_alloc and
kindred routines in ggc*.*. At the end of every 'function' in your language, toplev.c calls
the garbage collection several times. The garbage collection calls mark
routines which go through the memory which is still used, telling the
garbage collection not to free it. Then all the memory not used is
freed.

What this means is that you need a way to hook into this marking
process. This is done by calling ggc_add_root. This provides the address
of a callback routine which will be called duing garbage collection and
which can call ggc_mark to save the storage. If storage is only
used within the parsing of a function, you do not need to provide a way
to mark it. 

Note that you can also call ggc_mark_tree to mark any of the back end
internal 'tree' nodes. This routine will follow the branches of the
trees and mark all the subordinate structures. This is useful for
example when you have created a variable declaration that will be used
across multiple functions, or for a function declaration (from a
prototype) that may be used later on. See the next item for more on the
tree nodes. 

@node Interfacing to the code generation code. ,  , Interfacing to the garbage collection, treelang main compiler
@subsubsection Interfacing to the code generation code. 

In treelang this is done in treetree.c. A typedef called 'tree' which is
defined in tree.h and tree.def in the GCC directory and largely
implemented in tree.c and stmt.c forms the basic interface to the
compiler back end.

In general you call various tree routines to generate code, either
directly or through toplev.c. You build up data structures and
expressions in similar ways. 

You can read some documentation on this which can be found via the GCC
main web page. In particular, the documentation produced by Joachim
Nadler and translated by Tim Josling can be quite useful. the C compiler
also has documentation in the main GCC manual (particularly the current
CVS version) which is useful on a lot of the details.

In time it is hoped to enhance this document to provide a more
comprehensive overview of this topic. The main gap is in explaining how
it all works together. 

@node Hints and tips,  , treelang compiler interfaces, treelang internals
@section Hints and tips

@itemize @bullet

@item
TAGS: Use the make ETAGS commands to create TAGS files which can be used in
emacs to jump to any symbol quickly. 

@item
GREP: grep is also a useful way to find all uses of a symbol.

@item
TREE: The main routines to look at are tree.h and tree.def. You will
probably want a hardcopy of these. 

@item
SAMPLE: look at the sample interfacing code in treetree.c. You can use
gdb to trace through the code and learn about how it all works. 

@item
GDB: the GCC back end works well with gdb. It traps abort() and allows
you to trace back what went wrong. 

@item
Error Checking: The compiler back end does some error and consistency
checking. Often the result of an error is just no code being
generated. You will then need to trace through and find out what is
going wrong. The rtl dump files can help here also.

@item
rtl dump files: The main compiler documents these files which are dumps
of the rtl (intermediate code) which is manipulated doing the code
generation process. This can provide useful clues about what is going
wrong. The rtl 'language' is documented in the main GCC manual.

@end itemize

@end ifset

@node Open Questions, Bugs, treelang internals, Top
@chapter Open Questions

If you know GCC well, please consider looking at the file treetree.c and
resolving any questions marked "???".

@node Bugs, Service, Open Questions, Top
@chapter Reporting Bugs
@cindex bugs
@cindex reporting bugs

You can report bugs to @email{@value{email-bugs}}. Please make
sure bugs are real before reporting them. Follow the guidelines in the
main GCC manual for submitting bug reports.

@menu
* Sending Patches::             
@end menu

@node Sending Patches,  , Bugs, Bugs
@section Sending Patches for GNU Treelang

If you would like to write bug fixes or improvements for the GNU
Treelang compiler, that is very helpful.  Send suggested fixes to
@email{@value{email-patches}}.

@node Service, Projects, Bugs, Top
@chapter How To Get Help with GNU Treelang

If you need help installing, using or changing GNU Treelang, there are two
ways to find it:

@itemize @bullet

@item
Look in the service directory for someone who might help you for a fee.
The service directory is found in the file named @file{SERVICE} in the
GCC distribution.

@item
Send a message to @email{@value{email-general}}.

@end itemize

@end ifset
@ifset INTERNALS

@node Projects, Index, Service, Top
@chapter Projects
@cindex projects

If you want to contribute to @code{treelang} by doing research,
design, specification, documentation, coding, or testing,
the following information should give you some ideas.

Send a message to @email{@value{email-general}} if you plan to add a
feature.

The main requirement for treelang is to add features and to add
documentation. Features are things that the GCC back end can do but
which are not reflected in treelang. Examples include structures,
unions, pointers, arrays.

@end ifset

@node Index,  , Projects, Top
@unnumbered Index

@printindex cp
@summarycontents
@contents
@bye