[Top][All Lists]

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

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

From: Szikra Istvan
Subject: RE: [avr-gcc-list] gcc signal overhead, redundant code, bug (?), far from optimal
Date: Fri, 19 Aug 2005 02:46:24 +0200

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:
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

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?

    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

Thx everyone
Istvan Szikra

reply via email to

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