RE: [avr-gcc-list] gcc signal overhead, redundant code, bug (?), far from optimal

[Szikra Istvan]

Thx J"org for the great insight, now I can imagine that __zero_reg__ not
always zero :)
(although I'm pretty sure I don't use hw mul anywhere in my entire program)

So fine that ISR cannot rely on __zero_reg__ really being zero, but in this
case it does not use zero reg (I mean the isr is not using it at all, the
main program might does), so why should even care what is in it? 
I guess the "compiler simply doesn't analyze that level of detail" applies
to this too. 

This problem not entirely new to this list, Brian already wrote this
optimization suggestion:
http://lists.gnu.org/archive/html/avr-gcc-list/2005-01/msg00107.html
If we can believe him the IAR compiler does this kind of analysis.

I know "wishing for things won't get them done" (as Eric said) :(

I have already guessed I should write it in asm, I just hoped there is other
way.

Thx again



As for David

> Believe J"org addressed everything in full.

Not everything. (see below)

> 
> As for SREG, no telling what another routine was doing with the
> status bits so it too has to be saved and restored before any of its
> contents possibly get modified. CISC CPUs do this for you when
> stacking the IRQ, and on RTI.

And your point ?

(Of course) I know all that.
My point was / is that if the ISR does not modify the SREG then it does not
need saving. (no matter what others are done or will do with it)

The cause of all problems here is the __zero_reg__, because clr __zero_reg__
modifies the SREG. This instruction is redundant, so essentially saving SREG
is redundant too.

Unfortunately the compiler not smart enough to optimize this.

I think some of my questions are still valid:

- Is it possible to write some of the ISR in asm, and the other in c?
(The asm part has to run before the prologue (or even better in the prologue
between the pushes), so it don't need to wait for all the pushes)
Or something like this, any workarounds?

- What is bugging me most is what the hell does clr r25 (eor r25, r25) do in
my ISR? Any ideas?
Should we fill a bug report?

[lss]
    register char output=COAXDATAOUT_IN;
 142:   83 b3           in      r24, 0x13       ; 19

    char Rx=COAXDATAIN_IN;
 144:   23 b3           in      r18, 0x13       ; 19

    if (output & COAXDATAOUT_TxD_PIN) Rx >>=1;
 146:   99 27           eor     r25, r25          <------- WHY GOD, WHY
?????
 148:   84 fd           sbrc    r24, 4
 14a:   26 95           lsr     r18

    if (output & COAXDATAOUT_DTR_PIN) Rx >>=1;
 14c:   85 fd           sbrc    r24, 5
 14e:   26 95           lsr     r18
[/lss]


Thx everyone
Istvan Szikra