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.
Ob hier alles steht weiß ich nicht. CLZ findet man auf jeden Fall. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABBBJGA.html Google: Cortex m4 built-in instruction clz
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
Hier noch ein Link zum genannten Manual (das ist sehr gut versteckt): https://static.docs.arm.com/ddi0403/e/DDI0403E_c_armv7m_arm.pdf Den findet man über: https://developer.arm.com/products/architecture/m-profile/docs Wie schnell die einzelnen Instruktionen sind, hängt von der Implementation ab und steht daher in dessen Dokumentation. Beim Cortex-M4 ist das das Cortex-M4 Technical Reference Manual: https://developer.arm.com/docs/100166/latest/preface Kapitel "Programmer's Model -> Instruction Set Summary" (da auch als PDF verfügbar). Christopher S. schrieb: > Nun würde ich gerne einige Funktionen gegen > diese built-ins austauschen. Benutze doch bitte die üblichen Begriffe. Builtins sind sowas: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Was du suchst, sind die Assembler-Instruktionen. Willst du die per Inline-Assembler nutzen? Sicher, dass das mit gutem C-Code nicht genauso gut geht?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.