Vergleich wird 16-bittig ausgeführt (avr-gcc)

[Olaf Bellheim (Gast)]

Professor: ATtiny2313
avr-gcc: (AVR_8_bit_GNU_Toolchain_3.4.2_939) 4.7.2

Ich habe eine Frage an die C-Gurus, und zwar habe ich folgendes 
"Problem".
Wie man im Assembler-Listing sehen kann, übersetzt avr-gcc diesen 
Vergleich 16-bittig.
Warum ist das so und kann man es abstellen?

if( statusbyte.rc5_bit ^ ((RC5_INP & RC5_PIN) ? 1 : 0) ) {
  ...
}

IN        R19,0x13       In from I/O location
IN        R18,0x10       In from I/O location
BST       R19,2          Bit store from register to T
CLR       R22            Clear Register
BLD       R22,0          Bit load from T to register
LDI       R23,0x00       Load immediate
BST       R18,4          Bit store from register to T
CLR       R20            Clear Register
BLD       R20,0          Bit load from T to register
LDI       R21,0x00       Load immediate
CP        R22,R20        Compare
CPC       R23,R21        Compare with carry
BREQ      PC+0x20        Branch if equal

[Mark B. (markbrandis)]

if( statusbyte.rc5_bit ^ ((RC5_INP & RC5_PIN) ? 1 : 0) ) {
    ...
}

Probier's mal mit gescheitem Code. Nein, möglichst viel in eine Zeile zu 
quetschen ist nicht gescheit.

[Kirby (Gast)]

Mark B. schrieb:
>

> if( statusbyte.rc5_bit ^ ((RC5_INP & RC5_PIN) ? 1 : 0) ) {
>     ...
> }
>

>
> Probier's mal mit gescheitem Code. Nein, möglichst viel in eine Zeile zu
> quetschen ist nicht gescheit.

Außer für Leute, die 'Professor: ATtiny2313' schreiben.

[Peter D. (peda)]

Warum willst nicht, daß das jemand compilieren kann?

Zu Codefetzen gehören minimal die Definitionen und Macros.

[Yalu X. (yalu) (Moderator)]

Was die Symbole statusbyte, RC5_INP und RC5_PIN bedeuten, ist wohl dein
Geheimnis, also kann man nur raten. Ich habe versucht, die fehlende
Information aus dem generierten Assemblercode zu rekonstruieren.

Wenn ich damit richtig liege, tut folgender C-Code dasselbe:

  uint8_t rc5inp = RC5_INP;
  if(statusbyte.rc5_bit)
    rc5inp = ~rc5inp;
  if(rc5inp & RC5_PIN) {
    ...
  }

GCC 6.2.0 macht daraus

  in r24,0x13
  sbic 0x10,4
  com r24
  sbrs r24,2
  rjmp ...

was IMHO nicht weiter optimiert werden kann.


Übrigens:

Statt

(ausdruck) ? 1 : 0

kann man auch schreiben

(bool)(ausdruck)

[Sebastian V. (sebi_s)]

Yalu X. schrieb:
> Übrigens:
>
> Statt
>
> (ausdruck) ? 1 : 0
>
> kann man auch schreiben
>
> (bool)(ausdruck)

In C? Da gibts bool nur seit C99 und selbst dann ist es nur ein Integer 
imho.

[(prx) A. K. (prx)]

Sebastian V. schrieb:
> In C? Da gibts bool nur seit C99 und selbst dann ist es nur ein Integer
> imho.

"bool" ist per stdint.h definiert als _Bool und ist eine Integer, die 
nur die Wert 0 und 1 annehmen kann: "When any scalar value is converted 
to _Bool, the result is 0 if the value compares equal to 0; otherwise, 
the result is 1."

[Johann L. (gjlayde)]

A. K. schrieb:
> "bool" ist per stdint.h definiert

stdbool.h

[Peter D. (peda)]

Sebastian V. schrieb:
>> Statt
>>
>> (ausdruck) ? 1 : 0
>>
>> kann man auch schreiben
>>
>> (bool)(ausdruck)

oder

 !!(ausdruck)

[Yalu X. (yalu) (Moderator)]

Sebastian V. schrieb:
>> (bool)(ausdruck)
>
> In C? Da gibts bool nur seit C99 und selbst dann ist es nur ein Integer
> imho.

Wir haben jetzt das Jahr 2016 ;-)

Peter D. schrieb:
> oder !!(ausdruck)

So hat man's vor 1999 gemacht.

[A. S. (achs)]

Olaf Bellheim schrieb:
> warum ist das so und kann man es abstellen?

nennt sich integral promotion und kann meist mit Compilerschaltern 
abgeschaltet werden. Dann sind allerdings überläufe bei u16=u8a+u8b ohne 
casts oder Umstellung möglich.

[S. R. (svenska)]

Olaf Bellheim schrieb:
> Wie man im Assembler-Listing sehen kann, übersetzt avr-gcc diesen
> Vergleich 16-bittig.

Weil auf AVR der Integer nur 16 Bit breit ist. Du kannst einen der 
Operanden auf 32 Bit casten, dann sollte ein 32 Bit breiter Vergleich 
dabei rauskommen.

[Olaf Bellheim (Gast)]

Danke, der Cast hats gebracht. Jetzt siehts schon viel besser aus.

IN        R18,0x13       In from I/O location
IN        R19,0x10       In from I/O location
SWAP      R19            Swap nibbles
ANDI      R19,0x01       Logical AND with immediate
BST       R18,2          Bit store from register to T
CLR       R18            Clear Register
BLD       R18,0          Bit load from T to register
CP        R19,R18        Compare
BREQ      PC+0x20        Branch if equal

Gruß Olaf

[Yalu X. (yalu) (Moderator)]

Nur interessehalber: Hat mein Vorschlag von oben

uint8_t rc5inp = RC5_INP;
  if(statusbyte.rc5_bit)
    rc5inp = ~rc5inp;
  if(rc5inp & RC5_PIN) {
    ...
  }

nicht zum erwünschten Erfolg geführt?

Denn der würde ja noch einmal 8 Bytes einsparen :)

[Olaf Bellheim (Gast)]

Yalu X. schrieb:
> Nur interessehalber: Hat mein Vorschlag von oben

Ich denke nicht, ich möchte den Flankenwechsel in der Bitmitte erkennen.
Das ganze basiert auf Peter Dannegers RC5-Code 
Beitrag "Fernbedien RC5 Empfänger"

[Adib (Gast)]

Olaf Bellheim schrieb:
> Danke, der Cast hats gebracht. Jetzt siehts schon viel besser

Wie sieht denn der Code jetzt aus? Was genau sind d nn die Macros?

Ps: im C sind alle Bit-operationen mit int-operanden definiert.

Grüße, Adib.
--

[Markus F. (mfro)]

Adib schrieb:
> Ps: im C sind alle Bit-operationen mit int-operanden definiert.

Nein.

In C sind alle Operationen auf "schmaleren" Datentypen als int als 
Operationen auf int definiert (integer promotion).

Ein optimierender Compiler darf das abkürzen, solange das Ergebnis 
dasselbe bleibt, wie wenn er integer promotion durchgeführt hätte.