Diskussion:Codevergleich AVR-Compiler - Versionsgeschichte

Rolf D._alt am 2. Juli 2007 um 05:57 Uhr

2007-07-02T05:57:06Z

Rolf D._alt am 2. Juli 2007 um 05:45 Uhr

2007-07-02T05:45:05Z

PicNick am 22. August 2006 um 07:00 Uhr

2006-08-22T07:00:29Z

Roberto am 21. August 2006 um 19:14 Uhr

2006-08-21T19:14:26Z

SprinterSB_alt am 21. August 2006 um 13:48 Uhr

2006-08-21T13:48:39Z

Roberto am 10. August 2006 um 05:42 Uhr

2006-08-10T05:42:44Z

Darwin.nuernberg_alt am 26. April 2006 um 21:43 Uhr

2006-04-26T21:43:08Z

SprinterSB_alt am 24. April 2006 um 16:17 Uhr

2006-04-24T16:17:18Z

Frank am 23. April 2006 um 23:12 Uhr

2006-04-23T23:12:07Z

Darwin.nuernberg_alt am 23. April 2006 um 22:32 Uhr

2006-04-23T22:32:50Z

← Nächstältere Version		Version vom 2. Juli 2007, 05:57 Uhr
Zeile 302:		Zeile 302:

	Ich habe mir mal erlaubt, die Beispiele im Keil für Arm 7 CPUs unter die AVR Codeschnipsel zu setzen.		Ich habe mir mal erlaubt, die Beispiele im Keil für Arm 7 CPUs unter die AVR Codeschnipsel zu setzen.
−	Auch die Fassung für ARM 7 mit dem gcc wären hier interssant - ich habe aber grade keinen WinARM zur Hand. Das gcc und Keil den Code wesentlich effizienter als Bascom übersetzen und auch besser optimieren, liegt auf der Hand. ~~Sollte~~ aber keinen Bascom Anwender wirklich bekümmern so lange sie mit ihren Werkzeugen zu passablen Ergebnissen kommen. Das ist schließlich das wichtigste. --[[Benutzer:Rolf D.\|Rolf D.]] 07:45, 2. Jul 2007 (CEST)	+	Auch die Fassung für ARM 7 mit dem gcc wären hier interssant - ich habe aber grade keinen WinARM zur Hand. Das gcc und Keil den Code wesentlich effizienter als Bascom übersetzen und auch besser optimieren, liegt auf der Hand. Das sollte aber keinen Bascom Anwender wirklich bekümmern so lange sie mit ihren Werkzeugen zu passablen Ergebnissen kommen. Das ist schließlich das wichtigste. Man sieht hier auch, das ein RISC CPU-Kern potentiell etwas mehr Befehle benötigt als ein CISC, jedoch dürften dafür die die verbrauchten Taktcycels etwas geringer sein, was sich besonders bei Loops positiv auf die Geschwindigkeit auswirkt. --[[Benutzer:Rolf D.\|Rolf D.]] 07:45, 2. Jul 2007 (CEST)

← Nächstältere Version		Version vom 2. Juli 2007, 05:45 Uhr
Zeile 300:		Zeile 300:

	--PicNick 09:00, 22. Aug 2006 (CEST)		--PicNick 09:00, 22. Aug 2006 (CEST)
		+
		+	Ich habe mir mal erlaubt, die Beispiele im Keil für Arm 7 CPUs unter die AVR Codeschnipsel zu setzen.
		+	Auch die Fassung für ARM 7 mit dem gcc wären hier interssant - ich habe aber grade keinen WinARM zur Hand. Das gcc und Keil den Code wesentlich effizienter als Bascom übersetzen und auch besser optimieren, liegt auf der Hand. Sollte aber keinen Bascom Anwender wirklich bekümmern so lange sie mit ihren Werkzeugen zu passablen Ergebnissen kommen. Das ist schließlich das wichtigste. --[[Benutzer:Rolf D.\|Rolf D.]] 07:45, 2. Jul 2007 (CEST)

← Nächstältere Version		Version vom 22. August 2006, 07:00 Uhr
Zeile 293:		Zeile 293:

	Danke für die ausführliche Beschreibung :-) --[[Benutzer:Roberto\|Roberto]] 21:14, 21. Aug 2006 (CEST)		Danke für die ausführliche Beschreibung :-) --[[Benutzer:Roberto\|Roberto]] 21:14, 21. Aug 2006 (CEST)
		+	----
		+
		+	Zitat SprinterSB:"Mit Optimierungen ist BASCOM sehr zurückhaltend;"
		+	Ich finde, das hast du schön gesagt.
		+	Ich hab den Optimizer von Bascom zwar nicht erforscht, aber ich hätte gerne mal ein Beispiel gesehen, wo von dem Optimzer auch nur ein Pieps zu sehen wäre. Kennt wer sowas ?
		+
		+	--PicNick 09:00, 22. Aug 2006 (CEST)

← Nächstältere Version		Version vom 21. August 2006, 19:14 Uhr
Zeile 291:		Zeile 291:

	--[[Benutzer:SprinterSB\|SprinterSB]] 15:48, 21. Aug 2006 (CEST)		--[[Benutzer:SprinterSB\|SprinterSB]] 15:48, 21. Aug 2006 (CEST)
		+
		+	Danke für die ausführliche Beschreibung :-) --[[Benutzer:Roberto\|Roberto]] 21:14, 21. Aug 2006 (CEST)

@@ Zeile 229: / Zeile 229: @@
 --[[Benutzer:Darwin.nuernberg|Darwin.nuernberg]] 23:43, 26. Apr 2006 (CEST)
 Hallo
@@ Zeile 234: / Zeile 235: @@
 Um wieviel ist C jetzt schneller als Bascom ?
 --[[Benutzer:Roberto|Roberto]] 07:42, 10. Aug 2006 (CEST)

← Nächstältere Version		Version vom 10. August 2006, 05:42 Uhr
Zeile 228:		Zeile 228:

	--[[Benutzer:Darwin.nuernberg\|Darwin.nuernberg]] 23:43, 26. Apr 2006 (CEST)		--[[Benutzer:Darwin.nuernberg\|Darwin.nuernberg]] 23:43, 26. Apr 2006 (CEST)
		+
		+	Hallo
		+
		+	Gibt es jetzt darüber eigentlich schon ein Fazit ?
		+	Um wieviel ist C jetzt schneller als Bascom ?
		+	--[[Benutzer:Roberto\|Roberto]] 07:42, 10. Aug 2006 (CEST)

← Nächstältere Version		Version vom 26. April 2006, 21:43 Uhr
Zeile 223:		Zeile 223:

	Den Assembler-Code von Darwin sehe ich momentan nicht. Das einzige was ich hab, ist ein HEX-Dump (Maschinen-Code) und ein Assembler-Code aus dem hex. Der Code der Routine kann man schon in etwa zuordnen. Und die kleinen Funktiönchen, die Bascom aufruft, sind wahrscheinlich feste Bausteine, die auch von anderen Funktionen (falls vorhanden) mitverwendet würden.		Den Assembler-Code von Darwin sehe ich momentan nicht. Das einzige was ich hab, ist ein HEX-Dump (Maschinen-Code) und ein Assembler-Code aus dem hex. Der Code der Routine kann man schon in etwa zuordnen. Und die kleinen Funktiönchen, die Bascom aufruft, sind wahrscheinlich feste Bausteine, die auch von anderen Funktionen (falls vorhanden) mitverwendet würden.
		+
		+	----
		+	Das sehe ich nicht so. Ein "Bänschmarg" sollte eigentlich die reíne Rechenleistung wiedergeben. Codeoptimierung ist da was ganz anderes. Zumal ein längerer Code durchaus schneller als ein kompakter Code sein KANN. Manche Befehle benötigen mehr "Ticks" als andere. In Vielen Sprachen ist zwar x=x+1 langsamer und länger als inc x, dies muss aber nicht für alle Befehle gelten und ist ja auch noch kein Compilat, es wird aber auf unterschiedliche Weisen das gleiche Ergebniss erzielt (Das Ziel ist der Weg). Waurm wurde wohl der RISC entwickelt (Reduced InStruction Code). Da muss ma auch mehrere Befehle ausführen als mit einem "NonRISC" System, trozdem sollte das "RISC-System" schneller arbeiten.
		+
		+	--[[Benutzer:Darwin.nuernberg\|Darwin.nuernberg]] 23:43, 26. Apr 2006 (CEST)

← Nächstältere Version		Version vom 24. April 2006, 16:17 Uhr
Zeile 213:		Zeile 213:

	--[[Benutzer:Frank\|Frank]] 01:12, 24. Apr 2006 (CEST)		--[[Benutzer:Frank\|Frank]] 01:12, 24. Apr 2006 (CEST)
		+
		+
		+	----
		+	Das "Spaghetti-Code" bezog sich auf das Disassemble der hex-Datei, nicht auf die BASIC-Quelle.
		+
		+	Das "While I >= 0" ist immer noch nicht korrekt. Der erste Wert, der addiert wird, ist dann immer noch N-1 und nicht N. Ausserden würde mit >=0 am Ende eine -1 addiert werden, weil das Decr vor der Summe steht.
		+
		+	Ein Codevergleich ist ja so was wie ein Benchmark. Und einfache Routinen, die in den Sprachen gleich aussehen (die Summenberechnung sieht in C ja genauso aus wie in BASIC), sind ja im Artikel als Vorschlag drinne. Irgendw muss man ja anfangen. Laufzeitbestimmungen könnte man natürlich auch machen...
		+
		+	Den Assembler-Code von Darwin sehe ich momentan nicht. Das einzige was ich hab, ist ein HEX-Dump (Maschinen-Code) und ein Assembler-Code aus dem hex. Der Code der Routine kann man schon in etwa zuordnen. Und die kleinen Funktiönchen, die Bascom aufruft, sind wahrscheinlich feste Bausteine, die auch von anderen Funktionen (falls vorhanden) mitverwendet würden.

← Nächstältere Version		Version vom 23. April 2006, 23:12 Uhr
Zeile 208:		Zeile 208:

	--[[Benutzer:Darwin.nuernberg\|Darwin.nuernberg]] 00:28, 24. Apr 2006 (CEST)		--[[Benutzer:Darwin.nuernberg\|Darwin.nuernberg]] 00:28, 24. Apr 2006 (CEST)
		+
		+	Mich interessiert der Vergleich eigentlich nicht, aber wenn er denn was nützen soll dann sollte der Code auch vergleichbar sein. Mit Codeauszügen ist das schwierig weil es mühseelig ist den speziellen Code der für die Subroutine zuständig ist herauszupicken, zudem greift Bascom auch in Assember sehr schnell auf Subroutinen im Code zurück, so das dies ohnehin schwierig ist. Es wäre viel einfacher und auch aussagekräftiger wenn das komplette Programm auf beidne Seiten als Assembler aufgelistet würde, so wie es Darwin jetzt oben in Bascom gemacht hat.
		+	Ansonsten würden Benchmarks für bestimmte Aufgaben (Rechenzeit/Codegröße) für viele sicher interessanter sein.
		+
		+	--[[Benutzer:Frank\|Frank]] 01:12, 24. Apr 2006 (CEST)

@@ Zeile 202: / Zeile 202: @@
 Also ein Vergleich ist wenn überhaupt am endgültigen Resultat, sprich HEX-File möglich.
 Aber das hattest Du vermutlich nicht vor. Das mit der Korrektur des Schleifendurchlauf es
-wäre kein akt, aber wenn Du das Endresultat nicht zum Vergleich heranziehen willst, macht es keinen Sinn da noch weitere Energie hinein zu stecken. EIgentlich wäre anstelle x>0 x>=0 nötig um die Funktion korrekr zum Ende zu bringen.
+wäre kein akt, aber wenn Du das Endresultat nicht zum Vergleich heranziehen willst, macht es keinen Sinn da noch weitere Energie hinein zu stecken. EIgentlich wäre anstelle "While I > 0" nuer ein "While I >= 0" nötig um die Funktion korrekt zum Ende zu bringen.
 PS: wo ist das denn ein Spagetti-Code? Ist doch schön strukturiert. Nur weil Du die Befehle nicht kennst muss es doch kein Spagetticode sein. Und so schlimm ist es wohl auch nicht. Umgekehrt könnte ich zu C Spagetti sagen, weil mir das nicht zusagt.