[Top][All Lists]

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

Re: [avr-gcc-list] SIGNAL and INTERRUPT overhead

From: Bernard Fouché
Subject: Re: [avr-gcc-list] SIGNAL and INTERRUPT overhead
Date: Tue, 23 Aug 2005 10:19:32 +0200
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Benjamin Titzer wrote:

Sounds to me like the design of GCC and the constraints of a particular
calling convention do not allow it to do something smart here. I think the
solution that would satisfy most everyone involved would be for the
compiler to generate code that only saves the state of registers that it
uses (and overwrites) and then restore them upon exit. This is a simple
use-def analysis on the registers and would be simple enough to implement.
I think that gcc optimizer does that, provided that it can get all the information when compiling. If the interrupt handler calls an external function (external to the source file), then the compiler is not able
to know what to save and what not to save, so it saves everything.

That's a big problem with the usual way of building code, with functions or set of related functions in different files. When the compiler groks the files, it does not have all the information that would help
it build a much better optimized code.

My wish would be to have a tool that disassembles some elf file (there is obj-dump, so that's okay) and re-optimize the assembly flile and then send it to as(1) to make a new, better optimized final file. (I've heard about only a single company makes such tools, and they do not support avr)

In this way, beside calls to external function (say 'system' functions), the resulting code would be shorter (for instance by inlining all functions called only once) and faster (just by removing unnecessary push/pops)
and at last the optimizer would have everything at hand.

Until this, I made a few scripts that help me build a single C file from many differents, and I manually find functions called only once to have them prefixed by something that ccp changes to 'static inline' when
the project is built to produce the final 'big C file'.

(I did not find a gcc option to tell it that all functions are 'static' nor I found one to tell it to
automatically inline functions called only once.)

Working that way, and then checking in the final .lss file everything that was included by the linker to remove things that could be, I got an 8% size reduction on a booloader. However I spent a whole
day setting all this things all right.

An as-optimizer would be very nice, and from what I've understood of gcc, one could probably build such a tool by writing another front end for gcc (reading assembly language) and then using all the
optimization systems that are in the compiler.


reply via email to

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