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)
Damit die Links im Inhaltsverzeichnis richtig funktionieren müssen Unterüberschriften verschieden sein. Daher hab ich mal den beispielnamen in Klammern angefügt
--Frank 15:17, 17. Jan 2006 (CET)
Da hast du recht, ist eigentlich auch logisch. Man bessert sich !
--PicNick 16:13, 17. Jan 2006 (CET)
Die Abfolge der Unterabschnitte ist ja nicht sooo wichtig...wir sind ja nicht aufm Amt ;-)
Was steht eigentlich "rechts" vom '.' im Bascom-Beispiel? Ich kann mich da nicht aus.
Argument = "11."
Die Maschine schreibt ja da hin.
--SprinterSB 16:36, 17. Jan 2006 (CET)
Du meinst rechts vom Punkt ? 0x00. Durch das initialisieren ist ja argument ein (20 + 1) byte langes array von 0x00.
Die "Band"längen berechnung von dir hab ich nicht nachvollzogen. Das Platz muß reichen. fix codiert ist die sache sowieso
--PicNick 16:47, 17. Jan 2006 (CET)
Ok, jetzt hab ich's auch gesehen...
--SprinterSB 16:56, 17. Jan 2006 (CET)
