[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: Incremental gcc

From: Camm Maguire
Subject: [Gcl-devel] Re: Incremental gcc
Date: 30 Mar 2006 10:55:17 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and thanks for your reply!

Mike Stump <address@hidden> writes:

> On Mar 25, 2006, at 9:14 PM, Camm Maguire wrote:
> > 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
> Ignoring an ideal world for a second, if you have large amounts of  headers 
> that are stable that are needed for compilation, be sure to
> precompile them.  After that, batch up all code to be compiled into  larger 
> unit and compile it all in one go, as it saves a substantial

Thanks!  We've done this just recently to some benefit.

> amount of time (2x faster maybe), this way startup costs are amortized.

This is often impossible to arrange at the compiler level in lisp.

> Longer term, it would be nice to have someone from your camp layout  where 
> the time is spent and what changes might be worth while in gcc  to
> make it more suitable for that type of work.

This would be interesting, how does one benchmark gcc performance in
this way?

> You can run the compiler via stdin and stdout:
> $ gcc -x c - -o - -S
> int i;
> main() { }
> ^D      .section __TEXT,__text,regular,pure_instructions
>          .section  __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32
>          .machine ppc
>          .text
>          .align 2
>          .globl _main
> _main:
>          stmw r30,-8(r1)
>          stwu r1,-48(r1)
>          mr r30,r1
>          lwz r1,0(r1)
>          lmw r30,-8(r1)
>          blr
> .comm _i,4
>          .subsections_via_symbols
> if you want, so that isn't very hard to do.  The sub-problem of an as  that 
> can operate this way is off-topic for this list, so I won't

This was the most promising.  If I could run gcc as a pipe with
assembler only output, all I need is a 'flush instruction on stdin to
get the assemly of the function(s) input thus far.  Then the pipe
should be ready for another function definition followed by a flush,
etc.  Is there such?

> address it.

The assembly problem is different, as you state.  Among other reasons,
the output must be seekable as it is bfd based.  Coincidentally, GCL's
binary input is bfd based, so it should be possible to incorporate the
assembler and leave the output in memory.

> Long term, might be nice to have a way to wire in the assemblers into  gcc 
> directly.  If you guys feel ambitious, that might be doable; but
> since gc is driven by people that want to code, you'll have to find  someone 
> that wants to code it up.  The java folks might be interested
> in JITifying the compiler as well, if enough people are interested in  doing 
> that, it might be an interesting direction to take gcc, though
> building in as strikes me as a prerequisite.

Thanks again.  There is interest, but it might be a ways off before
sufficient time becomes available.

Take care,


Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]