PIC16 Anweisungen wegoptimiert

[Silvio G. (technofreak)]

Hallo

ich lese hier schon seit längerem mit und habe auch schon so manches 
Problem lösen können durch die Beiträge anderer User. Heute hab ich auch 
mal ein Problem was ich noch nicht lösen konnte.

Ich nutze folgende Funktion um die Parität eines Zeichens zu berechnen 
und übergebe dann die 9 Bit an die Hardware-UART. Bei der Compoilierung 
werden die beiden Zeilen, die um 1 bzw. 2 Bit shiften einfach 
wegoptimiert, alle anderen bleiben bestehen.

Wie kann das sein? Wie kann ich das verhindern?

Silvio

//
/*  Zeichen per UART senden*/
void zeichen_senden(unsigned char zeichen)
{
  bit9 = (bit9 ^ (zeichen & 0b00000001));                    //  \
  bit9 = (bit9 ^ ((zeichen >> 1) & 0b00000001));                //   \
  bit9 = (bit9 ^ ((zeichen >> 2) & 0b00000001));                //    \Paritätsberechnung
  bit9 = (bit9 ^ ((zeichen >> 3) & 0b00000001));                //    /
  bit9 = (bit9 ^ ((zeichen >> 4) & 0b00000001));                //   /
  bit9 = (bit9 ^ ((zeichen >> 5) & 0b00000001));                //  /
  bit9 = (bit9 ^ ((zeichen >> 6) & 0b00000001));                // /
  bit9 = (bit9 ^ ((zeichen >> 7) & 0b00000001));
  TX2STAbits.TX9D = bit9;                            //9. Bit zuweisen
  TX2REG = zeichen;                              //Daten ins Ausgaberegister schieben, Übertragung beginnt
}

[Kein Name (Gast)]

Der Backslash maskiert das Newline?

[Karl H. (kbuchegg)]

Kein Name schrieb:
> Der Backslash maskiert das Newline?


Oh, ja. Der Programmier-Fehler ist wirklich fies.

INteressant ist, dass auch die Forensoftware das hinkriegt, dass die 
beiden Zeilen auskommentiert sind, weil sie mit dem \ alle zu einer 
Zeile zusammengezogen wurden und daher alles nach dem \\ in der ersten 
Zeile als Kommentar gewertet wird. Hätte ich jetzt nicht gedacht, dass 
die das schafft.

[Karl H. (kbuchegg)]

abgesehen davon

void zeichen_senden(unsigned char zeichen)
{
  bit9 = (bit9 ^ (zeichen & 0b00000001));                    //  \

bist du dir sicher, dass die Paritätsberechnung mit einem nicht näher 
bekannten Wert von bit9 beginnen soll?

Alles in allem ist deine Paritätsberechnung mit den vielen 
Schiebeoperationen alles andere als µC-schonend implementiert. Hoffen 
wir mal, dass der Optimizer des Compilers erkennt, dass er das jeweilige 
Ergebnis der Stufe davor weiterverwenden kann.

[Silvio G. (technofreak)]

Hallo

auf diese Idee mit dem fortsetzen der Zeile bin ich noch gar nicht 
gekommen. Ich dachte imme nach // ist alles Kommentar bis zum Zeilenende 
also auch ein \. Habe aber jetzt im Disassambly Listing gesehen daß auch 
an anderen Stellen was als Kommentar angesehen wurde was eigentlich Code 
sein sollte. Hat aber bisher keine Auswirkungen gehabt weil in der 
Initialisierung und nur bei Werten die ich auch so setze wie sie nach 
einem Reset automatisch sind.

Mit dem Startwert für bit9 ist geändert. Die Berechnung in Assambler 
erfolgt folgendermaßen:

bit9 testen
Ergebnis in temporäre Speicherstelle
Zeichen laden
Zeichen shiften
Zeichen Bit 0 testen
Ergebnis in Arbeitsregister
XOR von Arbeitsregister und temporärer Speicherstelle
Ergebnis in Arbeitsregister
Arbeitsregister Bit 0 testen
Ergebnis in Bit9 speichern

Ist für alle 8 Bit gleich bis auf die Anzahl der Stellen beim Shift. 
Sollte also passen. Für die Berechnung werden etwa 200 Assambler-Befehle 
gebraucht.

Vielen dank für die Hilfe, ohne euch hätte ich den Fehler garantiert 
nicht gefunden.

Silvio

[__ (Gast)]

Es gibt auch einen Denkfehler.
{
  bit9 = (bit9 ^ (zeichen & 0b00000001));

sollte eigentlich sein:
{
  bit9 = (zeichen & 0b00000001);


Wechsle das aus und poste auch den ASM Code, welcher der Compiler 
generiert.

Ansonten, eventuell eine ASM Funktion:

 swapf zeichen,W
 xorwf zeichen,W
 andlw 0xf0
 movwf tmp

 rlf   tmp,w
 rlf   tmp
 btfsc tmp,7
 incf  tmp
 btfsc tmp,6
 incf  tmp
 btfsc tmp,
 incf  tmp

 bcf   TX2STAbits,TX9D
 btfsc tmp,0
 bsf   TX2STAbits,TX9D

[Silvio G. (technofreak)]

Hallo

ich habe jetzt vor der Berechnung bit9 auf 0 gesetzt. Damit kann der 
Code so bleiben.

Die ASM-Variante ist zwar schön kurz und auch schnell, aber da ich weder 
mit dem Platz (8k Befehle, 4k genutzt) noch der Ausführungszeit (ca. 
40µs) Probleme habe werde ich das erstmal so lassen.

Der ASM-Code der erzeugt wird ist im Anhang.

Silvio

[Peter II (Gast)]

sa geht doch wohl auch mit C schneller

uint8_t bit9 = 0;
uint8_t tmp = zeichen;
for( uint8_t bit = 0; bit < 7; ++bit ) {
   bit9 = bit9 ^ (zeichen & 1);
   zeichen = zeichen >> 1;
}
TX2STAbits.TX9D = bit9;   
TX2REG = zeichen;

[Karl H. (kbuchegg)]

Silvio G. schrieb:

> Die ASM-Variante ist zwar schön kurz und auch schnell

Sorry. Das würde ich weder kurz noch schnell nennen.

Probier mal diese Variante, ob die schneller geht bzw. weniger Code 
produziert

unsigned char Parity( unsigned char i )
{
  static const unsigned char nibbleParity[] =    // die Parität für jeweils 4 Bit
  {
    0, 1, 1, 0,     // 0000, 0001, 0010, 0011
    1, 0, 0, 1,     // 0100, 0101, 0110, 0111
    1, 0, 0, 1,     // 1000, 1001, 1010, 1011
    0, 1, 1, 0      // 1100, 1101, 1110, 1111
  };

  return nibbleParity[i&0x0F] ^ nibbleParity[i>>4];
}

[Karl H. (kbuchegg)]

Silvio G. schrieb:
> Hallo
>
> auf diese Idee mit dem fortsetzen der Zeile bin ich noch gar nicht
> gekommen. Ich dachte imme nach // ist alles Kommentar bis zum Zeilenende
> also auch ein \.

Die Reihenfolge in der der Präprozessor arbeitet ist:

  Zuerst Line Continuations zusammenziehen
  dann Kommentare durch 1 Leerzeichen ersetzen

[spess53 (Gast)]

Hi

Beitrag "Re: Parität eines Bytes"

MfG Spess

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

Silvio G. schrieb:
> Der ASM-Code der erzeugt wird ist im Anhang.

Nur aus Neugierde: Ist das der erzeugte Code mit eingeschalteter 
Optimierung?

[Silvio G. (technofreak)]

Hallo

mit dem schnell und kurz meinte ich aus dem Post vor mit das

swap...

Meine Version sind ca. 300 Befehlszyklen bei ca. 200 Befehlen.

Die Funtion Parity ergibt 74 Befehle mit ca. 130 Befehlszyklen (ASM im 
Anhang).

Silvio

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

Probier lieber mal PeDas Variante auf die Spess verlinkt hat.

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

Silvio G. schrieb:
> Die Funtion Parity ergibt 74 Befehle mit ca. 130 Befehlszyklen (ASM im
> Anhang).

Zähl nochmal nach und lass dabei jene Daten weg, die nicht dazu gehören. 
Von der Tabelle sind nur die ersten 16 relevant, der Rest sind 
irgendwelche Strings.

[Karl H. (kbuchegg)]

Silvio G. schrieb:


> Die Funtion Parity ergibt 74 Befehle mit ca. 130 Befehlszyklen (ASM im
> Anhang).


Autsch.
Wenn der Compiler ein static Array so einbaut, dass er es jedesmal beim 
Betreten der Funktion wieder neu erzeugt, würde ich ganz schnell den 
Compiler wechseln.

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

Karl Heinz Buchegger schrieb:
> Wenn der Compiler ein static Array so einbaut, dass er es jedesmal beim
> Betreten der Funktion wieder neu erzeugt, würde ich ganz schnell den
> Compiler wechseln.

Wie kommst du darauf?

[Karl H. (kbuchegg)]

Karl Heinz Buchegger schrieb:
> Silvio G. schrieb:
>
>
>> Die Funtion Parity ergibt 74 Befehle mit ca. 130 Befehlszyklen (ASM im
>> Anhang).
>
>
> Autsch.
> Wenn der Compiler ein static Array so einbaut, dass er es jedesmal beim
> Betreten der Funktion wieder neu erzeugt, würde ich ganz schnell den
> Compiler wechseln.

Edit:
Was treibt der Compiler da? Da ist noch mehr in der Funktion als nur die 
Tabelle.

Hast du den Optimizer eingeschaltet?
Oder die Generierung von Debug-Information aktiviert?

[Silvio G. (technofreak)]

@ A. K.

leider nicht, da es für den Compiler 3 Varianten gibt. Die besseren 
beiden kosten Geld, die schlechteste ist frei. Die beste Variante soll 
um 40% kleineren Code erzeugen.

Silvio

[Karl H. (kbuchegg)]

A. K. schrieb:
> Karl Heinz Buchegger schrieb:
>> Wenn der Compiler ein static Array so einbaut, dass er es jedesmal beim
>> Betreten der Funktion wieder neu erzeugt, würde ich ganz schnell den
>> Compiler wechseln.
>
> Wie kommst du darauf?

OK. Ich bin nicht 100% sicher. Aber das hier

653:               unsigned char Parity( unsigned char i )
654:               {
655:                 static const unsigned char nibbleParity[] =    // die Parität für jeweils 4 Bit
  0263    3400     RETLW 0
  0264    3401     RETLW 0x1
  0265    3401     RETLW 0x1
  0266    3400     RETLW 0
  0267    3401     RETLW 0x1
  0268    3400     RETLW 0
  0269    3400     RETLW 0
  026A    3401     RETLW 0x1
  026B    3401     RETLW 0x1
  026C    3400     RETLW 0
  026D    3400     RETLW 0
  026E    3401     RETLW 0x1
  026F    3400     RETLW 0
  0270    3401     RETLW 0x1
  0271    3401     RETLW 0x1
  0272    3400     RETLW 0
  0273    3420     RETLW 0x20
  0274    3450     RETLW 0x50
  0275    3461     RETLW 0x61
  0276    3472     RETLW 0x72
  0277    3469     RETLW 0x69
  0278    3474     RETLW 0x74
  0279    3461     RETLW 0x61
  027A    3465     RETLW 0x65
  027B    3474     RETLW 0x74
  027C    3420     RETLW 0x20
  027D    3400     RETLW 0
  027E    3430     RETLW 0x30
  027F    3431     RETLW 0x31
  0280    3432     RETLW 0x32
  0281    3433     RETLW 0x33
  0282    3434     RETLW 0x34
  0283    3435     RETLW 0x35
  0284    3436     RETLW 0x36
  0285    3437     RETLW 0x37
  0286    3438     RETLW 0x38
  0287    3439     RETLW 0x39
  0288    3400     RETLW 0
  0289    3420     RETLW 0x20
  028A    3457     RETLW 0x57
  028B    3465     RETLW 0x65
  028C    3472     RETLW 0x72
  028D    3474     RETLW 0x74
  028E    3420     RETLW 0x20
  028F    3400     RETLW 0
  0290    344E     RETLW 0x4e
  0291    3472     RETLW 0x72
  0292    342E     RETLW 0x2e
  0293    3420     RETLW 0x20
  0294    3400     RETLW 0
  0295    3430     RETLW 0x30
  0296    3431     RETLW 0x31
  0297    3400     RETLW 0
656:                 {
657:                   0, 1, 1, 0,     // 0000, 0001, 0010, 0011
658:                   1, 0, 0, 1,     // 0100, 0101, 0110, 0111
659:                   1, 0, 0, 1,     // 1000, 1001, 1010, 1011
660:                   0, 1, 1, 0      // 1100, 1101, 1110, 1111
661:                 };
662:               
663:                 return nibbleParity[i&0x0F] ^ nibbleParity[i>>4];
  02C8    00F3     MOVWF 0x73

sieht für mich danach aus. Die RETLW rese.....


Vergiss es. Da hab ich mich vertan.
Das hat er schon gut gemacht.

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

Karl Heinz Buchegger schrieb:
> Oder die Generierung von Debug-Information aktiviert?

Da sind beim Disassembleren irgendwelche Strings mit zugerordnet worden, 
die nicht zu diesem Teil des Codes zählen aber keine Symbole haben.

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

Silvio G. schrieb:
> leider nicht, da es für den Compiler 3 Varianten gibt. Die besseren
> beiden kosten Geld, die schlechteste ist frei. Die beste Variante soll
> um 40% kleineren Code erzeugen.

Gratuliere. Der erzeugte Code der ersten Variante ist selbst für einen 
nicht optimierenden Compiler geradezu abschrenkend schlecht.

[Peter D. (peda)]

Karl Heinz Buchegger schrieb:
> Oh, ja. Der Programmier-Fehler ist wirklich fies.

Der AVR-GCC gibt bei sowas aussagekräftige Meldungen aus.

  irgendwas // \

warning: multi-line comment


Peter

[Karl H. (kbuchegg)]

A. K. schrieb:
> Karl Heinz Buchegger schrieb:
>> Oder die Generierung von Debug-Information aktiviert?
>
> Da sind beim Disassembleren irgendwelche Strings mit zugerordnet worden,
> die nicht zu diesem Teil des Codes zählen aber keine Symbole haben.

Sieht wohl so aus. Mal rückübersetzen

  0273    3420     RETLW 0x20    ' '
  0274    3450     RETLW 0x50    'P'
  0275    3461     RETLW 0x61    'a'
  0276    3472     RETLW 0x72    'r'
  0277    3469     RETLW 0x69    'i'
  0278    3474     RETLW 0x74    't'
  0279    3461     RETLW 0x61    'a'
  027A    3465     RETLW 0x65    'e'
  027B    3474     RETLW 0x74    't'
  027C    3420     RETLW 0x20    ' '
  027D    3400     RETLW 0
  027E    3430     RETLW 0x30    '0'
  027F    3431     RETLW 0x31    '1'
  0280    3432     RETLW 0x32    '2'
  0281    3433     RETLW 0x33    '3'
  0282    3434     RETLW 0x34    '4'
  0283    3435     RETLW 0x35    '5'
  0284    3436     RETLW 0x36    '6'
  0285    3437     RETLW 0x37    '7'
  0286    3438     RETLW 0x38    '8'
  0287    3439     RETLW 0x39    '9'
  0288    3400     RETLW 0
  0289    3420     RETLW 0x20    ' '
  028A    3457     RETLW 0x57    'W'
  028B    3465     RETLW 0x65    'e'
  028C    3472     RETLW 0x72    'r'
  028D    3474     RETLW 0x74    't'
  028E    3420     RETLW 0x20    ' '
  028F    3400     RETLW 0
  0290    344E     RETLW 0x4e    'N'
  0291    3472     RETLW 0x72    'r'
  0292    342E     RETLW 0x2e    '.'
  0293    3420     RETLW 0x20    ' '
  0294    3400     RETLW 0
  0295    3430     RETLW 0x30    '0'
  0296    3431     RETLW 0x31    '1'
  0297    3400     RETLW 0

Jep. Das sind wohl Strings von woanders aus dem Programm, die nur 
zufällig hier beim Disassemblieren mitgekommen sind. Die eigentliche 
Funktion ist das hier

 02C8    00F3     MOVWF 0x73
  02C9    0873     MOVF 0x73, W
  02CA    00F1     MOVWF 0x71
  02CB    3004     MOVLW 0x4
  02CC    36F1     LSRF 0x71, F
  02CD    0B89     DECFSZ 0x9, F
  02CE    2ACC     GOTO 0x2cc
  02CF    0871     MOVF 0x71, W
  02D0    3E63     ADDLW 0x63
  02D1    3182     MOVLP 0x2
  02D2    000A     CALLW
  02D3    3182     MOVLP 0x2
  02D4    00F2     MOVWF 0x72
  02D5    0873     MOVF 0x73, W
  02D6    390F     ANDLW 0xf
  02D7    3E63     ADDLW 0x63
  02D8    3182     MOVLP 0x2
  02D9    000A     CALLW
  02DA    3182     MOVLP 0x2
  02DB    0672     XORWF 0x72, W
  02DC    2ADD     GOTO 0x2dd
664:               }
  02DD    0008     RETURN

[Peter D. (peda)]

Karl Heinz Buchegger schrieb:
> Die eigentliche
> Funktion ist das hier

Die obersten 16 RETLW gehören aber noch dazu.


Peter