- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: Optimierung Arduino-IDE - Assembler

  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.643

    Optimierung Arduino-IDE - Assembler

    Anzeige

    LiFePo4 Akku selber bauen - Video
    Hallo!

    Eine Frage an diejenigen, die sich besser mit ASM bei den Atmegas auskennen; ich habe zwar 8 Jahre in Assembler mein Unwesen getrieben, aber alles von 8086- bis 80486-Maschinen. Assembler bei den Mikrokontrollern ist ja doch wieder mal was ganz anderes. Und zwar habe ich beispielhaft folgende Codezeilen in der Arduino-IDE:

    Code:
      DDRD = B11111111;
      PORTC = B00110000;
      while(PINC&8){}
    I/O-Ports beschreiben und lesen und eine while-Schleife, in der ein Port abgefragt und das dann logisch verknüpft wird, um auf ein Ereignis zu warten.

    In wie weit wäre das denn mit ASM noch optimierbar, dahingehend, dass evtl. überflüssiger Code entfällt?
    Mir ist noch nicht klar, ob und was für überflüssiger Code, bei der Umwandlung durch den Compiler - für obiges Codebeispiel - entsteht.

    So weit ich mich bis heute damit auseinandergesetzt habe, stehe ich zurzeit auf dem Aussichtspunkt, dass Inline-Assembler für einzelne Portabfragen wenig Sinn macht, weil ja auch Parameter von und in den C-Code drumrum übergeben werden müssen, so dass dort auch wieder, für sehr kurze ASM-Sequenzen, betrachtlicher Overhead entsteht. Deshalb dürfte es dann wohl mehr Sinn machen, ganze Programmteile in ASM zu verfassen.

    Bei obigem Codebeispiel denke ich mir bisher, dass hier das Maschinencode-Ergebnis vom Compiler doch schon recht kurz und knackig ausfallen müsste. Oder lohnt es sich auch solche Sequenzen zu optimieren?

    MfG

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.702
    Blog-Einträge
    133
    Zitat Zitat von Moppi Beitrag anzeigen
    Bei obigem Codebeispiel denke ich mir bisher, dass hier das Maschinencode-Ergebnis vom Compiler doch schon recht kurz und knackig ausfallen müsste. Oder lohnt es sich auch solche Sequenzen zu optimieren?
    Ich denke nicht, daß bei den drei gezeigten Zeilen Laufzeit mit inline asm eingespart werden könnte. Das sieht ja schwer nach C Anweisungen aus und nicht nach Arduino spezifischen Kommandos wie zB. DigitalRead() oder DigitalWrite(). Bei den "Arduino Kommandos" ließe sich einiges einsparen - liest man - ich bin ja kein Arduino User.

    Ich lese mir im Zweifel die von der IDE erzeugte Hexdatei (hoffe die Arduino IDE erzeugt auch eine solche) in einen Disassembler ein und schaue mir die Unterschiede an, nachdem ich vorher die Stelle mit mehreren NOPs hintereinander markiert habe.

    Gruß
    Searcher
    Geändert von Searcher (03.10.2018 um 08:30 Uhr)
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Typischerweise können C-Compiler einem ein Assemblerlisting mit dem C-Code als Kommentar liefern. Und wenn man Pech hat, erkennt man in stark optimiertem Code sein eigenes C-Programm nicht mehr wieder.

    https://www.systutorials.com/240/gen...ing-using-gcc/

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.643
    Ich habe mal weiter gesucht und bin drauf gestoßen, dass auch ASM-Befehle für das Abfragen einzelner Port-Bits existieren. Damit würde sich ein "PINC & 8" beispielsweise erübrigen und eine extra Abfrage drumrum nicht stattfinden müssen, die in einem Vergleich bestehen würde. SBIC und SBIS wären dafür ausreichend. Ich will erst mal herausfinden, was praktisch an Geschwindigkeit herauszuholen wäre. Optimierung ist am Ende ja immer fallspezifisch.
    Geändert von Moppi (03.10.2018 um 09:20 Uhr)

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.702
    Blog-Einträge
    133
    Zitat Zitat von Moppi Beitrag anzeigen
    dass auch ASM-Befehle für das Abfragen einzelner Port-Bits existieren. Damit würde sich ein "PINC & 8" beispielsweise erübrigen und eine extra Abfrage drumrum nicht stattfinden müssen, die in einem Vergleich bestehen würde. SBIC und SBIS wären dafür ausreichend.
    Ein Compiler weiß das auch und verwendet die auch eventuell bei der Optimierung.

    Ich habe auch schon mal fragliche Codestücke in I/O Pin-setzen und -löschen eingeschlossen und mit Oszilloskop die Laufzeit ausgemessen.
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  6. #6
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.651
    .. Bei obigem Codebeispiel denke ich mir bisher, dass hier das Maschinencode-Ergebnis vom Compiler doch schon recht kurz und knackig ausfallen müsste. Oder lohnt es sich auch solche Sequenzen zu optimieren? ..
    Da stelln wa uns ma jaantz domm.

    Und schauen uns die jeweilige *.lls an, nachdem wir in zwei unterschiedlichen Optimierungsstufen compiliert haben. Umgebung: AVRStudio4.18 Build 700, WinAVR-20100110, Win7pro. Die originalen Zeilen sind rot markiert - und an die Fehlermeldungen angepasst.

    Optimiert mit -0s
    Code:
    arno_01-lss-Opt_-0s
    Optimierung -0s
    arno_01.elf:     file format elf32-avr
    //
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Izthrznt      =    20000;     // Der ZeitHorizont in ISR(TIMER2_COMPA_vect)
        12e0:    80 e2           ldi    r24, 0x20    ; 32
        12e2:    9e e4           ldi    r25, 0x4E    ; 78
        12e4:    90 93 40 04     sts    0x0440, r25
        12e8:    80 93 3f 04     sts    0x043F, r24
      Izeit_A       = Izthrznt;     //
        12ec:    80 91 3f 04     lds    r24, 0x043F
        12f0:    90 91 40 04     lds    r25, 0x0440
        12f4:    90 93 33 04     sts    0x0433, r25
        12f8:    80 93 32 04     sts    0x0432, r24
      Isecundn      =        0;     // Sekundenzähler, max 9 Stunden - NUR hier nullen
        12fc:    10 92 fd 03     sts    0x03FD, r1
        1300:    10 92 fc 03     sts    0x03FC, r1
    ** **************************************************************************** */
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    //  DDRD = B11111111;
    //  PORTC = B00110000;
      DDRD  = 0B11111111;
        1304:    8f ef           ldi    r24, 0xFF    ; 255
        1306:    8a b9           out    0x0a, r24    ; 10
      PORTC = 0B00110000;
        1308:    80 e3           ldi    r24, 0x30    ; 48
        130a:    88 b9           out    0x08, r24    ; 8
      while(PINC&8){}
        130c:    33 99           sbic    0x06, 3    ; 6
        130e:    fe cf           rjmp    .-4          ; 0x130c <main+0xb8>
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    /* **************************************************************************** **
    ** **************************************************************************** */
    // - - - - - - - - - - - - - - - -
      Svpt          =        0;     // Servopointer, => ~tmr~/ISR (TIMER1_COMPA_vect)
        1310:    10 92 20 04     sts    0x0420, r1
      TC1TMR_init ( );              // OCR1AV und ~BV in ~com~ gesetzt
        1314:    0e 94 d3 01     call    0x3a6    ; 0x3a6 <TC1TMR_init>
    // - - - - - - - - - - - - - - - -
    Optimiert mit -03 => der Code des >>gesamten Programms<< ist dabei ein vielfaches länger :-/
    Code:
    arno_01-lss-Opt_-03
    Optimierung -03
    arno_01.elf:     file format elf32-avr
    
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Izthrznt      =    20000;     // Der ZeitHorizont in ISR(TIMER2_COMPA_vect)
        b954:    80 e2           ldi    r24, 0x20    ; 32
        b956:    9e e4           ldi    r25, 0x4E    ; 78
        b958:    90 93 40 04     sts    0x0440, r25
        b95c:    80 93 3f 04     sts    0x043F, r24
      Izeit_A       = Izthrznt;     //
        b960:    80 91 3f 04     lds    r24, 0x043F
        b964:    90 91 40 04     lds    r25, 0x0440
        b968:    90 93 33 04     sts    0x0433, r25
        b96c:    80 93 32 04     sts    0x0432, r24
      Isecundn      =        0;     // Sekundenzähler, max 9 Stunden - NUR hier nullen
        b970:    10 92 fd 03     sts    0x03FD, r1
        b974:    10 92 fc 03     sts    0x03FC, r1
    ** **************************************************************************** */
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    //  DDRD = B11111111;
    //  PORTC = B00110000;
      DDRD  = 0B11111111;
        b978:    4a b9           out    0x0a, r20    ; 10
      PORTC = 0B00110000;
        b97a:    80 e3           ldi    r24, 0x30    ; 48
        b97c:    88 b9           out    0x08, r24    ; 8
      while(PINC&8){}
        b97e:    33 99           sbic    0x06, 3    ; 6
        b980:    fe cf           rjmp    .-4          ; 0xb97e <main+0xd0>
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    /* **************************************************************************** **
    ** **************************************************************************** */
    // - - - - - - - - - - - - - - - -
      Svpt          =        0;     // Servopointer, => ~tmr~/ISR (TIMER1_COMPA_vect)
        b982:    10 92 20 04     sts    0x0420, r1
      TC1TMR_init ( );              // OCR1AV und ~BV in ~com~ gesetzt
        b986:    0e 94 3d 01     call    0x27a    ; 0x27a <TC1TMR_init>
    // - - - - - - - - - - - - - - - -
    Geändert von oberallgeier (03.10.2018 um 14:44 Uhr) Grund: Korrektur: Win7pro
    Ciao sagt der JoeamBerg

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.643
    AVRStudio4.18 Build 700, WinAVR-20100110: machen dann ja zumindest das, was man erwarten würde bzw. selber auch in ASM schreiben würde.

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.702
    Blog-Einträge
    133
    Eine interessante Stelle ist die Verwendung von Interruptroutinen. Der Compiler rettet beim Aufruf meist mehr Register auf dem Stack als nötig.
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  9. #9
    HaWe
    Gast
    Zitat Zitat von Searcher Beitrag anzeigen
    Eine interessante Stelle ist die Verwendung von Interruptroutinen. Der Compiler rettet beim Aufruf meist mehr Register auf dem Stack als nötig.
    das stimmt, das ist auch der Grund, weshalb manche Intr nicht mehr korrekt funktionieren, wenn man direkt die GPIOs manipuliert:
    Code:
    direct port manipulation compiles to 1 or 2 instructions, calling digitalRead is dozens.
    One issue to be aware of is interrupts - some of the native direct-port manipulation code will not be
    interrupt-safe, where as digitalRead/digitalWrite/pinMode() are carefully coded to work when used
    both in an ISR and the main program.

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Searcher Beitrag anzeigen
    Eine interessante Stelle ist die Verwendung von Interruptroutinen. Der Compiler rettet beim Aufruf meist mehr Register auf dem Stack als nötig.
    Da wäre ich sehr vorsichtig. C ist eine Sprache, die eigentlich für einen Prozessor mit mindestens 16 Bit gedacht ist. Nun können die 16 Bit Funktionen durch Inline-Code nachgebildet werden. Manche werden aber auch durch Code in der Compiler Library erledigt. Das kann sogar bei sehr änlichem Code unterschiedlich gehandhabt werden. Mal kann man im Assemblerlisting sehen, welche Register benutzt werden, mal wird eine eingebaute Funktion aufgerufen, deren Registerbenutzung man nicht kennt. Das gilt ebenso für die Funktionen der C-Library. Und selbst wenn man das genau untersucht und verfiziert hat, kann einem schon eine neue Version des Compilers oder der Libc ins Bier spucken. Wenn man dabei ist, sein eigenes Programm zu debuggen, möchte man eigentlich nicht, daß noch Fehler durch zerstörte Register dazu kommen.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. PROGMEM und Optimierung
    Von Ceos im Forum C - Programmierung (GCC u.a.)
    Antworten: 6
    Letzter Beitrag: 09.10.2013, 08:15
  2. Optimierung von Funktion
    Von shedepe im Forum C - Programmierung (GCC u.a.)
    Antworten: 7
    Letzter Beitrag: 05.11.2010, 17:32
  3. Code Optimierung
    Von Siro im Forum C - Programmierung (GCC u.a.)
    Antworten: 10
    Letzter Beitrag: 19.08.2010, 23:45
  4. Zusammenbau Optimierung (Spule)
    Von Ichiban im Forum Asuro
    Antworten: 9
    Letzter Beitrag: 11.12.2008, 20:11
  5. Optimierung von Verfahrwegen
    Von N8Surfer im Forum Software, Algorithmen und KI
    Antworten: 1
    Letzter Beitrag: 16.01.2007, 12:32

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test