treelang is run as part of the gcc
compiler.
gdb
).
ld
command. However, the gcc
command, as with most
compiler commands, automatically performs the linking step by calling on
ld
directly, unless asked to not do so by the user.)
treelang
consists of several components:
gcc
command, which also might be
installed as the system's cc
command.
(In many cases, cc
refers to the
system's "native" C compiler, which
might be a non-GNU compiler, or an older version
of gcc
considered more stable or that is
used to build the operating system kernel.)
treelang
command itself.
libc
run-time library. This library contains the machine
code needed to support capabilities of the Treelang language that are
not directly provided by the machine code generated by the
treelang
compilation phase. This is the same library that the
main c compiler uses (libc).
tree1
.
Note that tree1
does not generate machine code directly--it
generates assembly code that is a more readable form
of machine code, leaving the conversion to actual machine code
to an assembler, usually named as
.
gcc
is often thought of as "the C compiler" only,
but it does more than that.
Based on command-line options and the names given for files
on the command line, gcc
determines which actions to perform, including
preprocessing, compiling (in a variety of possible languages), assembling,
and linking.
For example, the command `gcc foo.c' drives the file
`foo.c' through the preprocessor cpp
, then
the C compiler (internally named
cc1
), then the assembler (usually as
), then the linker
(ld
), producing an executable program named `a.out' (on
UNIX systems).
As another example, the command `gcc foo.tree' would do much the
same as `gcc foo.c', but instead of using the C compiler named
cc1
, gcc
would use the treelang compiler (named
tree1
). However there is no preprocessor for treelang.
In a GNU Treelang installation, gcc
recognizes Treelang source
files by name just like it does C and C++ source files. It knows to use
the Treelang compiler named tree1
, instead of cc1
or
cc1plus
, to compile Treelang files. If a file's name ends in
.tree
then gcc knows that the program is written in treelang. You
can also manually override the language.
Non-Treelang-related operation of gcc
is generally
unaffected by installing the GNU Treelang version of gcc
.
However, without the installed version of gcc
being the
GNU Treelang version, gcc
will not be able to compile
and link Treelang programs.
The command `gcc -v x.tree' where `x.tree' is a file which must exist but whose contents are ignored, is a quick way to display version information for the various programs used to compile a typical Treelang source file.
The tree1
program represents most of what is unique to GNU
Treelang; tree1
is a combination of two rather large chunks of
code.
One chunk is the so-called GNU Back End, or GBE,
which knows how to generate fast code for a wide variety of processors.
The same GBE is used by the C, C++, and Treelang compiler programs cc1
,
cc1plus
, and tree1
, plus others.
Often the GBE is referred to as the "gcc back end" or
even just "gcc"---in this manual, the term GBE is used
whenever the distinction is important.
The other chunk of tree1
is the majority of what is unique about
GNU Treelang--the code that knows how to interpret Treelang programs to
determine what they are intending to do, and then communicate that
knowledge to the GBE for actual compilation of those programs. This
chunk is called the Treelang Front End (FFE). The cc1
and
cc1plus
programs have their own front ends, for the C and C++
languages, respectively. These fronts ends are responsible for
diagnosing incorrect usage of their respective languages by the programs
the process, and are responsible for most of the warnings about
questionable constructs as well. (The GBE in principle handles
producing some warnings, like those concerning possible references to
undefined variables but these warnings should not occur in treelang
programs as the front end is meant to pick them up first).
Because so much is shared among the compilers for various languages, much of the behavior and many of the user-selectable options for these compilers are similar. For example, diagnostics (error messages and warnings) are similar in appearance; command-line options like `-Wall' have generally similar effects; and the quality of generated code (in terms of speed and size) is roughly similar (since that work is done by the shared GBE).
Go to the first, previous, next, last section, table of contents.