AVR-GCC 16Bit-Lastigkeit nervt

[Peter D. (peda)]

Warum hängt der AVR-GCC so an 16Bit bei 8Bit Berechnungen?

void test()
{
  if( PINB & (1<<PB0 | 1<<PB1) )
  80:   83 b1           in      r24, 0x03       ; 3
  82:   90 e0           ldi     r25, 0x00       ; 0
  84:   83 70           andi    r24, 0x03       ; 3
  86:   90 70           andi    r25, 0x00       ; 0
  88:   89 2b           or      r24, r25
  8a:   09 f0           breq    .+2             ; 0x8e <test+0xe>
    PORTB = 0;
  8c:   15 b8           out     0x05, r1        ; 5
  8e:   08 95           ret

Statt 6 Byte kostet der Vergleich 12 Byte (= 200%).
Aber nur, wenn der Test auch Bit 0 enthällt.

void test2()
{
  if( PINB & (1<<PB1 | 1<<PB2) )
  90:   83 b1           in      r24, 0x03       ; 3
  92:   86 70           andi    r24, 0x06       ; 6
  94:   09 f0           breq    .+2             ; 0x98 <test2+0x8>
    PORTB = 0;
  96:   15 b8           out     0x05, r1        ; 5
  98:   08 95           ret

Ich benutze WINAVR 2010.


Peter

[Peter II (Gast)]

was passiert bei:

 if( PINB & (1<<PB0) || PINB & (1<<PB1) )

?

[Peter D. (peda)]

Das ist funktional völlig anderer Code, es müssen 2 Zugriffe 
nacheinander auf PINB gemacht werden. Und dazwischen könnte ein 
Interrupt kommen, d.h. dann sind viele µs Unterschied, statt 
gleichzeitig.

Das PINB ist nur als Beispiel gemeint. Es kann auch ein IO-Register im 
RAM-Space sein (>0x0100).



Peter

[Frank M. (ukw) (Moderator)]

Peter Dannegger schrieb:
> Statt 6 Byte kostet der Vergleich 12 Byte (= 200%).

Kann ich bei mir nachvollziehen.

> Aber nur, wenn der Test auch Bit 0 enthällt.

Stimmt nicht, benutze mal

    if( PINB & (1<<PB0 | 1<<PB2))

Hier wird wieder die kurze Variante vom Compiler gewählt.

> Ich benutze WINAVR 2010.

Ich normalerweise auch, konnte aber das Problem sogar mit 
WinAVR-20090313 nachstellen.

EDIT:
Das Problem scheint nur in der Kombination PB0 und PB1, also (PINB & 
3), aufzutreten. Ich habe keine andere hinbekommen.

[Frank M. (ukw) (Moderator)]

Bei avr-gcc 4.7.0 und 4.7.1 besteht dieses Problem nicht mehr.
Vielleicht solltest Du doch mal auf einen neueren Compiler wechseln ;-)

[Peter D. (peda)]

Frank M. schrieb:
> Das Problem scheint nur in der Kombination PB0 und PB1, also (PINB &
> 3), aufzutreten. Ich habe keine andere hinbekommen.

Also bei geht alles von Bit 0 aufsteigend, also Maske 3, 7, 15, 31, 63, 
127.
Mit Lücke oder ohne Bit 0 wirds kurz.

Hier mal die Funktion, wo es mir aufgefallen ist:

void sleep()
{
  cli();
  if( !(ASSR & (1<<TCN2UB | 1<<OCR2AUB | 1<<OCR2BUB | 1<<TCR2AUB | 1<<TCR2BUB)))
  {
    sei();
    sleep_cpu();
    return;
  }
  sei();
}

Frank M. schrieb:
> Vielleicht solltest Du doch mal auf einen neueren Compiler wechseln ;-)

Ist die zu empfehlen:

avr-gcc-4.7.1-rc1-mingw32.zip


Peter

[Jörg W. (dl8dtl) (Moderator)]

Peter Dannegger schrieb:
> avr-gcc-4.7.1-rc1-mingw32.zip

Da 4.7.1 bereits released ist, würde ich keinen RC ("release
candidate") mehr nehmen.

[Frank M. (ukw) (Moderator)]

Peter Dannegger schrieb:
> Ist die zu empfehlen:
>
> avr-gcc-4.7.1-rc1-mingw32.zip

Hier ein Posting von Johann zur Wahl des avr-gcc:

Beitrag "Re: 16Bit aus 2x 8Bit, falsches Ergebnis bei Funktionsrückgabe"

4.7.1 ist also okay (aber nicht unbedingt rc1), 4.7.0 weniger.

[Peter D. (peda)]

Jörg Wunsch schrieb:
> Peter Dannegger schrieb:
>> avr-gcc-4.7.1-rc1-mingw32.zip
>
> Da 4.7.1 bereits released ist, würde ich keinen RC ("release
> candidate") mehr nehmen.

Diesen Link habe ich in AVR Freaks "avr-gcc 4.7.0 for the brave" 
gefunden:

http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/

Hast Du nen Link ohne RC?

Irgendwie fehlt ja nach WINAVR 2010 ne offizielle Anlaufstelle für neue 
Versionen zum Downloaden.


Peter

[Jörg W. (dl8dtl) (Moderator)]

Peter Dannegger schrieb:
> Hast Du nen Link ohne RC?

Nein, ich bau' mir meine Compiler ohnehin immer selbst. ;-)  's ist
ja keine Raketenwissenschaft, das zu tun.

[Johann L. (gjlayde)]

Jörg Wunsch schrieb:
> Peter Dannegger schrieb:
>> avr-gcc-4.7.1-rc1-mingw32.zip
>
> Da 4.7.1 bereits released ist, würde ich keinen RC ("release
> candidate") mehr nehmen.

Wobei diese RC1 Bugfixes anthält, die in der offiziellen 4.7.1 nicht 
enthalten sind  ;-)

Siehe die Patches in ./source

GCC:
 http://gcc.gnu.org/PR53595

Binutils:
 http://sourceware.org/PR13899
 http://sourceware.org/PR14058


Jörg Wunsch schrieb:

> Nein, ich bau' mir meine Compiler ohnehin immer selbst. ;-)
> 's ist ja keine Raketenwissenschaft, das zu tun.

>> "Come on, Rory. It's not rocket science. It's just quantum physics."

[Adib (Gast)]

irgendwo hatte ich mal gelesen, dass bit operationen im C als int 
behandelt werden.

Das würde das Type-Casting erklären.

Adib.

[Jörg W. (dl8dtl) (Moderator)]

Adib schrieb:
> dass bit operationen im C als int
> behandelt werden.

Der C-Standard ist ein "als wäre"-Standard: die Operationen müssen
sich so verhalten, als wären sie als "int" behandelt worden.  Wenn
aber das obere Byte zum Ergebnis nichts beiträgt, steht es dem
Compiler sehr wohl frei, nur das niederwertige Byte überhaupt
ausrechnen zu lassen.