Hallo allerseits,
ich bin gerade dabei mich mit den "builin" Befehlen des Cortex M4 zu
befassen und wollte mal wissen, ob jemand dazu eine vollständige Liste
aller Befehle mit Erklärungen kennt? Ich habe keinen vergleichbaren
Forenbeitrag gefunden.
Ich habe das Programming manual in gedruckter Form vorliegen, da ich
aber immer noch recht neu in C und der Programmierung bin, bräuchte ich
ein wenig Hilfe mich da durchzufinden. Mich würden alle Funktionen, die
auf Bits Operationen durchführen, und ggf.
Addition/Subtraktion/Multiplikationen von 32-Bit uint{32,64}_t Typen
durchführen. Also insgesamt suche ich nur arithmetische Befehle.
Gefunden habe ich das Buildin "clz" (Count leading zeroes) über eine
Wikipediaseite. Unter welchen Obergruppen müsste ich gucken? Frage ich
google nach "buildin" korrigiert er es automatisch zu "Building".
Vielen Dank für die Unterstützung.
Was du suchst sind die Instruktionen. Unter builtins versteht man
normalerweise Spezialfunktionen des C-Compilers. Der Cortex-M4 ist eine
Implementation der ARMv7M Plattform. Dementsprechend sind die
Instruktionen im "ARMv7M Architecture Reference Manual" erläutert. Als
Anfänger braucht man aber normalerweise die Instruktionen nicht, da
schreibt man lieber einfach nur C-Code...
Den C-Code habe ich fertig. Nun würde ich gerne einige Funktionen gegen
diese built-ins austauschen. Ich verstehe aber noch nicht so recht, wie
ich diese einsetze und wie sie zu interpretieren sind.
Ich habe z.B. im Generic User Guide vom Cortex M4 [1] die Funktionen
ADD, ADCS usw. gefunden. Aber da steht in keiner für mich verständlichen
Art, wie ich den Kram verwende :)
Realisierte habe ich übrigens für 352-Bits große Zahlen eine Modulo
Addition, Subtraktion und Schoolbook-Multiplikation in C. CLZ hat mir
ein wenig geholfen den Blick bereits zu erweitern und neue potentielle
Ansätze zur Beschleunigung zu finden. 800 Additionen und Subtraktionen
werden ohne merkliche Latenz über einen USART ausgegeben. :)
Verifikation mittels Sagemath.
[1]
http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/DUI0553A_cortex_m4_dgug.pdf
Guter Hinweis. Ich weiß nicht, wie der arm-none-eabi-gcc Crosscompiler
den C-Code genau übersetzt und ob man hier im ms Bereich einen Vorteil
bekommt, durch die Instruktionen. Ich nutze die CLZ Instruktion übrigens
so:
#define CLZ(x) (__builtin_clz(x))
#define CLZL(x) (__builtin_clzl(x))
Je nachdem, welchen Datentyp ich rein werfe.
Ich weiß z.B. nicht, ob der C-Compiler eine Addition von uint32_t Typen
(A + B) in den Assembler-Code umwandelt, oder welchen Vorteil man
gewinnen kann, wenn man den Inline-Assembler verwendet.
Christopher S. schrieb:> Ich weiß nicht, wie der arm-none-eabi-gcc Crosscompiler> den C-Code genau übersetzt
Dann hast du das wichtigste noch nicht gemacht: In die Disassembly
schauen.
Christopher S. schrieb:> Ich weiß z.B. nicht, ob der C-Compiler eine Addition von uint32_t Typen> (A + B) in den Assembler-Code umwandelt,
Vermutlich nach "ADD". Da gibts nichts mehr dran zu optimieren. Ob du
mit deinem Wissensstand es wirklich schaffst, einen aufwändig
optimierten Compiler (der außerdem so Dinge wie Pipeline-Effekte
beachtet) zu schlagen, ist fraglich. Es ist fast immer besser,
allgemeinen portablen C-Code zu schreiben, zu schauen was der Compiler
draus macht, und ggf. den Code anzupassen. Assembler bzw. die
entsprechenden Compiler-Builtins sind nur selten nötig.
Es gibt ja auch den STM32F407VGT6 als exakten Befehl für den Compiler.
Ich denke, dass er dann recht gut umwandelt.
CLZ ersetzte bei mir meine Bit-Zählmethode:
while( t <<= 1 ) {ctr +=1;}
(maximal 32 Durchläufe)
Damit bekam ich dann die Bitlänge (also die Position des ersten
gesetzten Bits) zurück und konnte dann die "Fehlstände" berechnen. Ich
vermute, dass CLZ hier schneller ist.
Debugging- und Disassemblermethoden sind mir weitestgehend unbekannt.
Christopher S. schrieb:> Es gibt ja auch den STM32F407VGT6 als exakten Befehl für den Compiler.
Hä? Es gibt einen Befehl namens STM32F407VGT6? Wie sieht der denn aus?
Christopher S. schrieb:> Ich> vermute, dass CLZ hier schneller ist.
Bei Handoptimierung ist Wissen besser als Vermuten. Erst mal gucken was
überhaupt zu langsam ist, dann überlegen ob das Optimieren einzelner
Takte überhaupt lohnt.
Ich wüsste übrigens nicht wie dein Code durch CLZ schneller gemacht
würde, das sind ja zwei völlig verschiedene Berechnungen?
Christopher S. schrieb:> Debugging- und Disassemblermethoden sind mir weitestgehend unbekannt.
Dann befasse dich damit erstmal genauer. Ohne diese kannst du solche
Optimierungen vergessen.
Dr. Sommer schrieb:> Christopher S. schrieb:>> Es gibt ja auch den STM32F407VGT6 als exakten Befehl für den Compiler.> Hä? Es gibt einen Befehl namens STM32F407VGT6? Wie sieht der denn aus?
Damit meinte ich eine Option für den Compiler. Ich habe mich jedoch für
"-mcpu=cortex-m4" entschieden, da ich evtl. auch den F429ZI verwenden
möchte.
> Christopher S. schrieb:>> Ich>> vermute, dass CLZ hier schneller ist.> Bei Handoptimierung ist Wissen besser als Vermuten. Erst mal gucken was> überhaupt zu langsam ist, dann überlegen ob das Optimieren einzelner> Takte überhaupt lohnt.
Wie eignet man sich dieses spezielle Wissen an? Dafür muss man doch
exakt wissen, wie was interpretiert wird und welche Laufzeiten (d.h.
Cycles/Tiks) eeine Operation benötigt? D.h. man muss da auf
Erfahrungswerte setzen und auf dokumentierten Wissen zurückgreifen
können, das genau das spezialisiert.
> Ich wüsste übrigens nicht wie dein Code durch CLZ schneller gemacht> würde, das sind ja zwei völlig verschiedene Berechnungen?
Mir kam es auf die Anzahl fehlender Bits an, um zu überprüfen, mit wie
vielen Bits ich einen Eintrag auffüllen kann.
> Christopher S. schrieb:>> Debugging- und Disassemblermethoden sind mir weitestgehend unbekannt.> Dann befasse dich damit erstmal genauer. Ohne diese kannst du solche> Optimierungen vergessen.
Ich nutze aktuell Notepad++ und den Compiler über die Konsole. Welcher
Debugger ist denn für Anfänger gut geeignet, sodass man die Dinge auch
verstehen kann? Ich hatte mal den von CooCox verwendet, aber konnte den
Debugger weder richtig verwenden, noch verstehen, was er mir da grade
anzeigt.
Christopher S. schrieb:> Damit meinte ich eine Option für den Compiler. Ich habe mich jedoch für> "-mcpu=cortex-m4" entschieden, da ich evtl. auch den F429ZI verwenden> möchte.
Also meines Wissens gibt es da keine Möglichkeit speziell für den
STM32F407VGT6. "cortex-m4" ist da die einzig sinnvolle Möglichkeit.
Christopher S. schrieb:> Wie eignet man sich dieses spezielle Wissen an?
z.B. den Zyklen-Zähler nehmen oder ein Tool wie Segger SystemView und
damit prüfen, welcher Code-Teil am langsamsten ist und als erstes
optimiert werden sollte. Und natürlich die Disassembly betrachten.
Christopher S. schrieb:> Dafür muss man doch> exakt wissen, wie was interpretiert wird und welche Laufzeiten (d.h.> Cycles/Tiks) eeine Operation benötigt?
Die meisten datenverarbeitenden Instruktionen brauchen 1 Takt. Das steht
ja alles wie bereits gesagt im Cortex-M4 Technical Reference Manual.
Christopher S. schrieb:> Welcher> Debugger ist denn für Anfänger gut geeignet, sodass man die Dinge auch> verstehen kann?STM32: Programmierung hier sind diverse Umgebungen aufgelistet, z.B.
Keil µVision, oder Eclipse mit GNU MCU Plugin. Letztere und die meisten
anderen Umgebungen sind nur GUI's für den GDB Debugger. Den kannst du
auch direkt auf der Konsole nutzen.
Dr. Sommer schrieb:> Christopher S. schrieb:>> Damit meinte ich eine Option für den Compiler. Ich habe mich jedoch für>> "-mcpu=cortex-m4" entschieden, da ich evtl. auch den F429ZI verwenden>> möchte.> Also meines Wissens gibt es da keine Möglichkeit speziell für den> STM32F407VGT6. "cortex-m4" ist da die einzig sinnvolle Möglichkeit.
Ich habe eben in meinen Unterlagen geschaut und mir nur als Altnernative
"-march=armv7-m" notiert.
> Christopher S. schrieb:>> Wie eignet man sich dieses spezielle Wissen an?> z.B. den Zyklen-Zähler nehmen oder ein Tool wie Segger SystemView und> damit prüfen, welcher Code-Teil am langsamsten ist und als erstes> optimiert werden sollte. Und natürlich die Disassembly betrachten.
Hast Du zu diesem Zyklen-Zähler weiterführende Links? Ich wusste nicht,
dass es sowas überhaupt gibt. Dachte schon, ich müsste mit Perf aus
Ubuntu leben oder mit clock() die Tiks bestimmen.
> Christopher S. schrieb:>> Dafür muss man doch>> exakt wissen, wie was interpretiert wird und welche Laufzeiten (d.h.>> Cycles/Tiks) eeine Operation benötigt?> Die meisten datenverarbeitenden Instruktionen brauchen 1 Takt. Das steht> ja alles wie bereits gesagt im Cortex-M4 Technical Reference Manual.
Ich habe jetzt über mehrere Wege versucht die PDF anzuzeigen oder
herunter zu laden, ich bekam stets einen Network-Time-Out.
> Christopher S. schrieb:>> Welcher>> Debugger ist denn für Anfänger gut geeignet, sodass man die Dinge auch>> verstehen kann?> STM32: Programmierung hier sind diverse Umgebungen aufgelistet, z.B.> Keil µVision, oder Eclipse mit GNU MCU Plugin. Letztere und die meisten> anderen Umgebungen sind nur GUI's für den GDB Debugger. Den kannst du> auch direkt auf der Konsole nutzen.
Den Debugger gucke ich mir gerne an. Mir stehen Win10 Education und
Ubuntu 16.04 LTS zur Verfügung.
Christopher S. schrieb:> Hast Du zu diesem Zyklen-Zähler weiterführende Links? Ich wusste nicht,> dass es sowas überhaupt gibt. Dachte schon, ich müsste mit Perf aus> Ubuntu leben oder mit clock() die Tiks bestimmen.
Seit wann läuft Ubuntu auf STM32? Siehe Kapitel C1.8.3 im ARMv7M
Architecture Reference Manual.
Christopher S. schrieb:> Ich habe jetzt über mehrere Wege versucht die PDF anzuzeigen oder> herunter zu laden, ich bekam stets einen Network-Time-Out.
Ja die Seite scheint gerade defekt zu sein... Versuchs später nochmal
oder Google das Dokument einfach.
Christopher S. schrieb:> Den Debugger gucke ich mir gerne an. Mir stehen Win10 Education und> Ubuntu 16.04 LTS zur Verfügung.
Wie hast du denn bisher überhaupt ohne Debugger gearbeitet? Nur per
Bootloader geflasht? Welche JTAG/SWD-Hardware hast du?
Christopher S. schrieb:> Hast Du zu diesem Zyklen-Zähler weiterführende Links?
Dort, wo du die Takte dokumentiert findest, solltest du auch den Systick
dokumentiert finden. WIMRE gibts im Debug-Modul dann noch einen weiteren
Zähler dieser Art.
Also in der Dokumentation des betreffenden Cores von ARM, sowie wohl
auch in der davon abgeleiteten Doku von ST.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten