K |
|||
| Zeile 84: | Zeile 84: | ||
Das Problem ist ja, daß C keine Vorstellung hat von Taktzyklen oder Ausführungszeiten. | Das Problem ist ja, daß C keine Vorstellung hat von Taktzyklen oder Ausführungszeiten. | ||
Ein Compiler transformiert von C nach Assembler; | 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. | + | 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. | Jedenfalls hat man keine Möglichkeit, den generierten asm-Code zu bestimmen. | ||
Die einzige Möglichkeit dazu liegt jenseits von C: in Assembler. | Die einzige Möglichkeit dazu liegt jenseits von C: in Assembler. | ||
Version vom 23. Dezember 2005, 16:16 Uhr
... Vielleicht kann hier ein GCC-Kollege das Beispiel einfügen ...
Vielleicht mal sagen, was man haben will bzw was die Blackox 'Pulsein' tut. Ich hab grad keine Lust, BASCOM zu installieren und zu debuggen ;-)
Es gibt 1000 Möglichkeiten, Zeiten zu messen...
Es geht nicht darum das man die Funktion nachbaut sondern das man die gleiche Aufgabe in GCC erfüllt. Wie du das machst bleibt Dir überlassen, es sollte nur eine möglichst kompakte Lösung sein. Decodieren eines RC-Signales. Dazu muss die Zeit bis zum Pegelwechsel gemessen werden (siehe Servos).
--Frank 02:24, 6. Dez 2005 (CET)
PickNick betrifft das GCC-Beispiel zu Pulsein! Es geht eigentlich nicht darum die Aufgabe Funktionell auf die gleiche Weise zu lösen (kann man natürlich auch machen). Es geht nur darum eine Lösung zu finden und diese aufzuzeigen damit Einsteiger die auch gleich nutzen können. Das könnte auch eine Timerlösung sein. Du hast jetzt einen denkbaren Aufruf eingetragen, aber die Lösung fehlt noch. Der leser sieht so auf den ersten Blick nicht das dort noch Code fehlt und könnte denken das wäre in C genauso einfach zu lösen wie in Bascom. Du solltest nochmal FETT markieren das hier noch die Lösung und das Programmgerüst fehlen, sonst ist die Gegenüberstellung etwas verfälscht.
--Frank 14:40, 21. Dez 2005 (CET)
Ich versteh' schon. Die Vorgabe von "pulsein" ist ja eigentlich unter die Gürtellinie. So zum Drüberstreuen (ohne Timer) mit relativ guter Genauigkeit Pulse messen geht in Hochsprachen (wenn wir C dazurechnen) einfach nicht. Aber gut, irgendwie kriegen wir das Code-Kästchen schon voll
--PicNick 15:01, 21. Dez 2005 (CET)
Siehst du etwas zu verbissen ;-) Es geht ja nicht darum Beispiele zu suchen die überall gleich funktionieren, sondern einfach zu zeigen wie man am schnellsten bestimmte Aufgaben lösen kann, und das wart eine ganz typische Aufgabe die man sehr oft braucht. Hätte es kein PulseIn-Befehl gegeben, hätte ich dort ein Bascom-Timer Beispiel gepostet. Auch ein C-Programmierer kann kleine Aufgaben posten die in Bascom nicht so leicht umzusetzen sind. Es geht um Lösungen nicht um direkte Algorithmen-Vergleiche.
--Frank 16:38, 21. Dez 2005 (CET)
Na, is ja auch egal, jetzt haben wir es schon, das war ja schon peinlich
--PicNick 17:08, 21. Dez 2005 (CET)
Nicht unbedingt peinlich, halt symptomatisch in C. Manche Dinge sind halt wesentlich aufweniger und erfordern viel mehr Zeit als in Basic. Was ist so schlimm daran dieses zuzugeben.
--Frank 15:53, 22. Dez 2005 (CET)
Was so schlimm ist ? Der Stolz, der Stolz ! "Geht nicht, gibt's nicht"
Willst du für Assembler sourcen auch eine "Sourcecode" Kategorie aufmachen a la Bascom und C ?
--PicNick 16:15, 22. Dez 2005 (CET)
Wenn Du ersten Assemblersource posten willst, leg nur an. Einfach Kategorie "Quellcode Assembler" nehmen damit Kategorienamen alphabetisch untereinander stehen.
--Frank 17:32, 22. Dez 2005 (CET)
Ich hab mich bei dem Sourcen-Vergleich mit Assembler-Beispielen wichtig gemacht. Ich würd' sagen, wenn's mehr wird, können wir ja eine Kategorie aufmachen. Wir werden ja sehen, wie das Geschäft läuft
--PicNick 19:24, 22. Dez 2005 (CET)
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)
