This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Incremental gcc
- From: Andrew Haley <aph at redhat dot com>
- To: Camm Maguire <camm at enhanced dot com>
- Cc: gcc at gnu dot org, Robert Boyer <boyer at cs dot utexas dot edu>, gcl-devel at gnu dot org, "Robert Dodier" <robert dot dodier at gmail dot com>
- Date: Mon, 27 Mar 2006 11:22:28 +0100
- Subject: Re: Incremental gcc
- References: <200603181626.k2IGQO3E006491@elgin.cs.utexas.edu> <54psk9dbz5.fsf@intech19.enhanced.com>
Camm Maguire writes:
> Greetings! GCL is a lisp compiler system which outputs C code normally
> compiled by gcc into an object, which is then loaded and relocated
> into the running GCL image. In lisp, compiling is a very incremental
> process, with many, often thousands of small functions compiled one at
> a time. GCL/gcc compilation speed would be greatly improved if gcc
> could be run in some sort of incremental mode, perhaps piping from
> stdin and outputting assemly only on stdout, if there was some way to
> instruct gcc to flush intermediary results. gas, which requires a
> seekable bfd device realistically on some sort of file system, could
> be run separately.
>
> Is anything like this conceivable?
>
> To Robert Dodier -- yes I agree, filesystem i/o is negligible as it is
> all cached anyway on typical modern machines.
>
> To Robert Boyer -- what an idea! Eventually, the proper way is likely
> to write GCL as a gcc frontend, as previously discussed briefly on
> both lists. Now is not the time, however, alas.
Look at http://per.bothner.com/papers/GccSummit03/gcc-server.pdf for some ideas.
What you seem to be describing, though, is a JIT.
Andrew.