[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.
Bernard