Hallo Leute! Ich suche verzweifelt eine Auflistung, wieviele Taktzyklen jeder C Befehl benötigt, finde aber leider keine und kann mir auch nicht wirklich vorstellen, dass es soetwas überhaupt nicht gibt :( Vielen Dank im Voraus, nosico
nosico wrote: > Hallo Leute! > > Ich suche verzweifelt eine Auflistung, wieviele Taktzyklen jeder C > Befehl benötigt, finde aber leider keine und kann mir auch nicht > wirklich vorstellen, dass es soetwas überhaupt nicht gibt :( Du solltest dich an den Gedanken gewöhnen. Wieviele Taktzyklen ein Befehl in C tatsächlich benötigt, hängt davon ab, wie der Compiler den Befehl umsetzt (von Compiler zu Compiler verschieden), sowie, und das ist viel wichtiger, wie der Compiler eine etwaige Optimierung damit macht. Im Extremfall kann ein Compiler ganze Befehlsketten komplett aus deinem Programm herausoptimieren, sodass sie effektiv 0 Taktzyklen benötigen. Wenn man tatsächlich zyklengenau programmieren muss, was sehr selten vorkommt, dann führt an Assembler kein Weg vorbei.
Lerne lieber, dir das vorzustellen. Wieviele Taktzyklen braucht wohl ein schnödes
1 | a=b; |
? Oder gar ein
1 | while(1); |
? Es gibt also keine eindeutigen Antwort, was ein Befehl in C braucht. Architekturunterschiede und Compiler erledigen den Rest.
So eine Antwort habe ich ja befürchtet, aber die habe die Hoffnung halt nicht aufgegeben ;) Gibt es nicht einmal eine Auflistung von der Umwandlung im AVR-GCC ohne Optimierung? Soetwas würde mir ja auch schon weiterhelfen...
nosico wrote: > Gibt es nicht einmal eine Auflistung von der Umwandlung im AVR-GCC ohne > Optimierung? Soetwas würde mir ja auch schon weiterhelfen... Wobei würde dir das weiterhelfen? In den meisten Fällen ist die Notwendigkeit der Kentniss der Taktzyklen in Indiz dafür, dass * ein falscher Algorithmus gewählt wurde * Der Programmierer mit seinen bescheidenen Kenntnissen versucht besser zu sein als der Compiler und versucht händisch zu optimieren (was meist schief geht). Im gcc gibt es ein paar Bereiche in denen der Compiler tatsächlich nicht besonders gut optimiert (speziell wenn es um Berechnungen mit reinen 8-Bit Variablen geht, da kommen dem gcc manchmal die C alles_wird_in_int_gerechnet-Regel in die Quere) aber in den meisten Fällen muss man schon sehr gut in Assembler sein, um den Compiler zu schlagen. Ansonsten gilt die Regel: Schreibe dein Programm zuerst mal so, dass es funktioniert. Klarheit geht dabei vor 'Cleverheit'. Wenn es dann zu langsam ist, versuche rauszufinden, wo die Rechenzeit verbraten wird und setzte dort den Optimierungshebel an. Aber nicht dadurch optimieren, indem an low level Operationen herumgefrickelt wird, das kann der Compiler nämlich besser. Sondern sieh nach ob es systematische Optimierungen im verwendeten Algorithmus gibt oder ob nicht ein anderer Algorithmus besser geeignet wäre. Natürlich gibt es auch Ausnahmen: Wenn man ein Videosignal erzeugen muss, dann muss das taktgenau sein. Da kommt man aber mit C nicht weiter und muss auf Assembler ausweichen.
Es geht mir ja genauso so wie Du geschrieben hast, zuerst wurde ein Code erzeugt, der einmal funktioniert und jetzt muss dieser Algorithmus optimiert werden, damit weitere Module angehängt werden können. In diesem konkreten Projekte geht es zufällig auch wirklich um eine Datenaufbereitung für ein Videosignal und genau für die die Algoritmus-Optimierung würde mir eine entsprechende Liste gewaltig weiterhelfen, da somit eine Abschätzung einfacher zum Durchführen ist, da natürlich ein dermaßen komplexer Algorithmus sehr schwer zum durchblicken ist
nosico wrote: > Algoritmus-Optimierung würde mir eine entsprechende Liste gewaltig > weiterhelfen, es gibt keine, weil es nicht nur vom Befehl selbst abhängt wie er umgesetzt wird sondern auch von der 'Programm-Umgebung', in der er eingestzt wird. > da somit eine Abschätzung einfacher zum Durchführen ist, > da natürlich ein dermaßen komplexer Algorithmus sehr schwer zum > durchblicken ist Wie gesagt: die Low Level Dinge überlasse getrost dem Compiler, der kann das besser und holt das Optimum heraus. Deine Aufgabe ist es, auf High Level Dingen nach Optimierungsmöglichkeiten zu suchen.
Schau dir die vom Compiler erzeugt .lss-Datei an. Darin kann man genau sehen, was der Compiler aus jeden Befehl gemacht hat.
> Oder gar ein > while(1); Dessen Verbrauch an Taktzyklen läßt sich recht genau ermitteln.
> Dessen Verbrauch an Taktzyklen läßt sich recht genau ermitteln.
Findest du? Wie gross ist denn die MTBF, in Takten?
> Wenn man tatsächlich zyklengenau programmieren muss, was sehr > selten vorkommt, dann führt an Assembler kein Weg vorbei. Und selbst das kannste bei moderneren CPUs mit Pipelining und CISC-Kern mal getrost vergessen. Ich hatte mal nen Listing fuer nen 8088 hehe...
>> Dessen Verbrauch an Taktzyklen läßt sich recht genau ermitteln. > > Findest du? Einfach einen Zähler parallel zum Takteingang des Prozessors hängen und vor der Schleife diesen Zähler resetten. Nachdem die CPU abgeschaltet ist, den Zähler auslesen ;-) > Wie gross ist denn die MTBF, in Takten? Kommt auf die Taktfrequenz an :)
>Kommt auf die Taktfrequenz an :)
Versteh ich was falsch oder ist ein Takt jetzt nicht mehr
Taktfrequenzunabhängig ?
> Versteh ich was falsch oder ist ein Takt jetzt nicht mehr > Taktfrequenzunabhängig ? Der Takt nicht, aber deren Anzahl bis zum Tod schon. Übertakter können davon ein Lied singen.
Außerdem wird die MTBF in der Regel in Stunden angegeben. Wenn man das in Takte umrechnen will, braucht man die Taktfrequenz.
Also beim gcc kannst du mit 'make Deindateiname.s' dir ein Assemblerlisting zur Datei Deintdateiname.c generieren. Aus der erzeugten Deindateiname.s suchst du dir die passende Stelle, meist sind die Zeilennummern und Funktionsnamen des C-codes als Kommentar angegeben. Dann darfst du anfangen zu zählen ;-). Wie viele Takte ein einzelner Befehl dauert steht beim AVR Datenblatt, das ist aber nicht bei allen Architekturen immer eine feste Menge. Natürlich kann die Sache wie oben schon beschrieben wieder ein paar Haken haben: 1. Der Compiler optimiert es weg und du findest keine Code. 2. Der erzeugte Code ist von der Compiler Version und den Optimierungsstufen abhängig. 3. Der Code verwendet Unterfunktionen aus der Bibliothek, bei dem du dann erstmal nicht weißt wie lange er braucht. 4. Je nach Ausgangssituation braucht der Code unterschiedlich viele Zyklen.
Bitte 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.