| Zeile 1: | Zeile 1: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
---- | ---- | ||
Die Schleife für die Zeitberechnung für avr-gcc hab ich in inline asm gefasst. | Die Schleife für die Zeitberechnung für avr-gcc hab ich in inline asm gefasst. | ||
| Zeile 115: | Zeile 57: | ||
Es kann nicht sein, daß man einfach hinschreibt, "das geht nicht, da muß du Assembler lernen". | Es kann nicht sein, daß man einfach hinschreibt, "das geht nicht, da muß du Assembler lernen". | ||
--PicNick 18:56, 23. Dez 2005 (CET) | --PicNick 18:56, 23. Dez 2005 (CET) | ||
| + | |||
| + | ---- | ||
| + | Bei der State-Machine ist die Reihenfolge Bascom-GCC-Assembler nicht eingehalten. Ich würde es so lassen, da die Erläuterung der Aufgabe ja bei GCC erfolgt, und Bascom sich darauf bezieht. Wenn das aber jemanden stört, bitte ich ergebenst um Umbau | ||
| + | |||
| + | --PicNick 14:16, 17. Jan 2006 (CET) | ||
Version vom 17. Januar 2006, 15:16 Uhr
Die Schleife für die Zeitberechnung für avr-gcc hab ich in inline asm gefasst. Mit ist nur nicht klar, welche "magische" Zahl was bedeutet. Evtl wäre es klarer defines zu verwenden wie für F_CPU auch. Das ganze in inline zu packen ist der einzige Weg, halbwegs aussagekräftige Werte zu bekommen. Ausserem müssen Interrupts abgeschaltet sein, da sonst die Zeitmessung ebenfalls nicht stimmt. Übrigens ist nicht nur der Optimierungsgrad dafür verantwortlich, wie eine solche Schleife später in asm aussieht, sondern noch ganz viele andere Faktoren. Und es ist auch ziemlich umständlch, aus den Wiki raus in ne Quelle zu kopieren; besonders dann, wenn an vielen Stellen die Quelle durch Wiki-Text auseinandergebrochen ist. Da könnten vielleicht Fussnoten oder so was helfen, oder den Text in die C-Quelle integrieren, so daß man später im Programm auch noch weiß was das alles soll und macht.
--SprinterSB 14:54, 23. Dez 2005 (CET)
Das ist eine Demo, wie man mit C Problem angehen könnte. Wär schön gewesen, wir wären auch bei der Sprache geblieben. Ich mußte nur 1 fremdes Statement reintun, sonst hätte der Optimizer zugeschlagen.
Die magischen Zahlen sind Cycles, INKLUSIVE while Schleife. Ich hoffe, der inline bewirkt das Gewünschte, die "Idle" schleife braucht 6 cycles.
Interrupts hab ich nicht disabled, weil's Bascom auch nicht tut.
Andere Faktoren ? zum Beispiel ? Du muß die Cycles aus der .Lss file zusammenrechnen
rauszukopieren: Ich seh das nicht als download-area. Wer das einfach 1:1 kopieren kann, hat nix davon.
--PicNick 15:12, 23. Dez 2005 (CET)
Das Problem ist ja, daß C keine Vorstellung hat von Taktzyklen oder Ausführungszeiten. Ein Compiler transformiert von C nach Assembler; was dabei rauskommt kann irgendwas sein, solange es die gleiche Semantik hat wie der ursprüngliche C-Code. Das ist bei solchen hardwarenahen Aufgaben teilweise lästig – ohne Frage. Jedenfalls hat man keine Möglichkeit, den generierten asm-Code zu bestimmen. Die einzige Möglichkeit dazu liegt jenseits von C: in Assembler. Alles andere ist trial & error und es ist in keinster Weise gesichert, daß der Code bei jemand anderem genauso erzeugt wird.
Entsprechend BASCOM würde ein C-Beispiel eine Bibliotheksfunktion aufrufen, die in asm implementiert ist (wie in BASCOM auch), und irgendeine Lib mitliefern. Aber sonderlich hilfreich wäre das auch nicht...
Andere Faktoren, die neben dem Optimierungsgrad Einfluss auf den erzeugten Code haben, sind:
- der verwendete Compiler und sein Version(!)
- weitere Kommandozeilen-Parameter, die die Codegenerierung beeinflussen, insbesondere
- der Controller(-Typ), für den generiert wird. Nicht alle Controller hab einen gleich mächtigen Befehlssatz
- die Vorgeschichte der entsprechenden Code-Stelle; dies hat starken Einfluss auf die Registerzuordnungen, für die sich der Compiler entscheidet, und somit auch auf die verwendeten Befehle
- wie die Funktion eingebunden ist: auch eine Funktion, die nicht als inline deklariert ist, darf geinlinet werden. Auch das hat weitreichende Folgen auf die Codeerzeugung
Im lst-File nachzuschauen, wie viel Befehle verwendet werden, das eintragen und ein Rebuilt wird i.d.R. zum Ergebnis führen, aber sichergestellt ist es nicht. Es ist denkbar, daß das lst sagt, die Sequenz dauert n Zyklen. Nach Ändern der Quelle auf n Zyklen dauert die Schleife aber evtl. m Zyklen.
Und so ganz klar, was der ganze Sourcevergleich soll, ist mit immer noch nicht. Äpfel mit Birnen vergleichen ist jedenfalls einfacher... Einem BASCOM-Programmierer bringt es eigentlich ebensowenig wie einem C-Programmierer.
--SprinterSB 16:16, 23. Dez 2005 (CET)
Der Vergleich hat den Sinn, daß bei gleicher Aufgabenstellung der C Programmierer sieht, wie das in Bascom aussehen müßte und vice versa. Das ist nur möglich, wenn man auch dann bis auf den letzten Drücker ausschließlich die Sprachmittel dieser Sprache verwendet. Nur dadurch kann ich dies Sprachmittel auch vergleichen.
Es kann nicht sein, daß man einfach hinschreibt, "das geht nicht, da muß du Assembler lernen".
--PicNick 18:56, 23. Dez 2005 (CET)
Bei der State-Machine ist die Reihenfolge Bascom-GCC-Assembler nicht eingehalten. Ich würde es so lassen, da die Erläuterung der Aufgabe ja bei GCC erfolgt, und Bascom sich darauf bezieht. Wenn das aber jemanden stört, bitte ich ergebenst um Umbau
--PicNick 14:16, 17. Jan 2006 (CET)
