C parsing + register allocation

C parsing + register allocation

[Philip Herron]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey

This a design question about the c front-end of 'a' compiler. I am
working on a basic compiler atm. But i was wondering, should you have
2 parsers, it seems it may be a good idea to have a seperate parser to
run first, to do all c-preprocessor work, then have the 2nd to do the
actual code parsing into internal representation, then output assembly...

I am looking through old gcc to get to grips with how its working at
the moment, but i was also wondering for the compilation process, does
gcc output asm then call gas from something like 'execl' or does it do
this internaly at the moment? Its something i don't really see. It
seems in old gcc it was called as there was direct paths hard-coded to
the bin-utils binaries like ld,as in gcc. To call to compile. Or is it
better to directly have some interface to an assembler. Passing a
gimple like representation to it or somthing.

My knowledge is bad when it comes to interfacing with bin-utils, there
isn't much documentation on them.

Also i was wondering is there any good documenation on how gcc or in
general on linux or otherwise the register allocation process.

- -Phil
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknzQZAACgkQAhcOgIaQQ2GsyQCcCFmqMxYgcmsTTzD37ev8c7EC
5vMAnira8dOVBi1UyXnWJONYzYO4sjUD
=IUvp
-----END PGP SIGNATURE-----

Re: C parsing + register allocation

[Ian Lance Taylor]

Philip Herron <herron.philip@googlemail.com> writes:

> This a design question about the c front-end of 'a' compiler. I am
> working on a basic compiler atm. But i was wondering, should you have
> 2 parsers, it seems it may be a good idea to have a seperate parser to
> run first, to do all c-preprocessor work, then have the 2nd to do the
> actual code parsing into internal representation, then output assembly...

Yes, it's easier if the preprocessor is separate from the language
parser.  In gcc the preprocessor is a library, libcpp, which emits a
token stream.  The C or C++ parser then operates on that stream.

> I am looking through old gcc to get to grips with how its working at
> the moment, but i was also wondering for the compilation process, does
> gcc output asm then call gas from something like 'execl' or does it do
> this internaly at the moment? Its something i don't really see. It
> seems in old gcc it was called as there was direct paths hard-coded to
> the bin-utils binaries like ld,as in gcc. To call to compile. Or is it
> better to directly have some interface to an assembler. Passing a
> gimple like representation to it or somthing.

gcc has always emitted a text file and then invoked the assembler via
something like 'execl'.  gcc can literally write a text file or it can
use a pipe to the assembler.  This is all done in the gcc driver, in
gcc.c.  The gcc driver is not the compiler proper.  Use the -v option to
see the programs that are run.

It would be slightly faster to invoke the assembler as a library.
However, the time required to generate out the assembler file and the
time required for the assembler to run is normally a small fraction of
the time required to compile a file.  So there is a limit to how much
faster it would be to avoid using an external program.

> Also i was wondering is there any good documenation on how gcc or in
> general on linux or otherwise the register allocation process.

The gcc documentation is at http://gcc.gnu.org/onlinedocs/ .  You may be
interested in the internals manual which you can find at the bottom of
that page.  Unfortunately the register allocation process is not well
documented.  Also, note that the register allocator was completely
rewritten in the 4.4.0 release of gcc.

Ian

Re: C parsing + register allocation

[Philip Herron]

Hey

Thanks very much, thats a pretty detailed respone! :)

> The gcc documentation is at http://gcc.gnu.org/onlinedocs/ .  You may be
> interested in the internals manual which you can find at the bottom of
> that page.  Unfortunately the register allocation process is not well
> documented.  Also, note that the register allocator was completely
> rewritten in the 4.4.0 release of gcc.
>
> Ian
>   
I kind of thought it would be the case that it wasn't well documented.
But i have been compiling my own version of gcc for ages, so i might as
well take a peek into the sources for once.

I would love to try and contribute to gcc, but i am a little overwhelmed
with how much code there is to get around for such a long standing
project. But if there are some code cleanups or something i might take a
stab at it. If its possible :)

Regards the parser thing yeah thats the way i started implementing it,
just its nice to know i have went about doing it the completely wrong
way ;). But i am thinking of working a little at a simple assembler and
elf linker for now and make a library interface to it, might be a nice
way to work with it. Thought not too sure.

Anyways thanks for that. Seeing the notes for gcc 4.4.0 seems like a lot
of cool work was done! anyways any tips on small contributions for gcc
that i might take a stab at would be nice.



Thanks
-Phil

Re: C parsing + register allocation

[Ian Lance Taylor]

Philip Herron <herron.philip@googlemail.com> writes:

> anyways any tips on small contributions for gcc
> that i might take a stab at would be nice.

This for your interest.  We have some notes on the wiki at
http://gcc.gnu.org/wiki , under "Improving GCC".

Ian