Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle Entwicklung im TIOBE-Programmierindex: "Assembler wieder auf dem Sprung nach vorn Ein Blick auf die Plätze 10 bis 20 zeigt vor allem einen großen Aufwärtstrend der Assemblersprache. Nachdem sie Im November 2014 auf Platz 29 lag, erreicht sie im aktuellen Index Position 11. Das Rating von 1,88 Prozentpunkten bedeutet eine Verdreifachung innerhalb des letzten Jahres. Eine mögliche Begründung liegt im wachsenden Bedarf an Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe Prozesse eingesetzt wird" Quelle: http://www.heise.de/newsticker/meldung/Programmiersprachen-Top-10-Java-und-Ruby-weiter-im-Aufwind-2911620.html
:
Gesperrt durch Moderator
Ich stell mir grad Win10 als Assembler-Listing vor... Das erlaubt hardwarenahes Optimizing. :)
>Eine mögliche Begründung liegt im wachsenden Bedarf an >Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe >Prozesse eingesetzt wird" Buhaha. Sehr weit hergeholt der Schwachsinn. Trau keiner Statistik die du nicht selber gefälscht hast;)
holger schrieb: >>Eine mögliche Begründung liegt im wachsenden Bedarf an >>Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe >>Prozesse eingesetzt wird" > > Buhaha. Sehr weit hergeholt der Schwachsinn. Würde ich nicht gerade sagen. Ich denke, da könnte was drann sein. > Trau keiner Statistik die du nicht selber gefälscht hast;) Wenn letztes Jahr von 100 Programmierern gerade 1 in Assembler programmiert hat und heuer sind es 2, dann ist das auch ein Zuwachs von 100%. Ist immer noch unter ferner liefen und völlig uninteressant.
holger schrieb: > Trau keiner Statistik die du nicht selber gefälscht hast;) Wollte ich auch gerade schreiben. Zumal der Index auf Statistiken von Suchmaschinen beruht. Also wenn jemand Leiterplatten bestücken lassen will und einen Assembler sucht, gehen bei der Programmiersprache die Prozente hoch. IoT in Assembler, ich lach mich scheckig.
Uuuuuuund mit den blauen Shorts in der Linnnnnnken Eeeeckääääääää das Team das seine Leiterplatten mit Aufrubbelbahnen zeichnet und auf den Kopierer legt. Uuuuuuuuund mit den roten Shorts in der rääääächten Eeeeckäääää, jener berüchtigte Boxstall der nicht von verkauften Produkten sondern vom ewigen Run auf das letzte Update lebt. Um es mit Werner Wernersens Worten zu sagen: "Ich sach das wird lustig."
Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: ... und wer passend dazu eine neue Episode von "Assembler vs. C/C++" verfolgen will, wird in diesen Kommentaren dazu fündig: http://www.heise.de/forum/heise-Developer/News-Kommentare/Programmiersprachen-Top-10-Java-und-Ruby-weiter-im-Aufwind/Assembler/posting-23896967/show/
Moby A. schrieb: > Assembler wieder auf dem Sprung nach vorn Bemerkenswert. Noch bemerkenswerter ist allerdings: http://kurier.at/sport/fussball/oesterreich-erstmals-in-top-ten-der-fifa-weltrangliste/162.310.129 mfg.
Karl H. schrieb: > Würde ich nicht gerade sagen. Ich denke, da könnte was drann sein. Mario M. schrieb: > IoT in Assembler, ich lach mich scheckig. Einmal um die Ecke denken bitte ;-) Nachdem es nun so viele IoT Geräte gibt, gibts auch wieder Leute, die versuchen, diese Geräte zu "hacken" oder reverse engineering betreiben. Kurz gesagt: Der Code wird ausgelesen und durch den Disassembler gejagt. Und dann wird Assembler plötzlich doch wieder ganz interessant!
Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: Naja, eigentlich zeigt es nur, dass IoT praktisch nix kosten darf, um es (wie von den Apologeten dieser schönen neuen Welt erwartet/herbeigebetet) hinreichend häufig verkaufen zu können. Wenn es klappen würde (und auch nur dann), führt es dazu, dass es sich möglicherweise rechnet, wirkliche Programmierer einzukaufen und deren Leistung durch billigere Hardware über die Stückzahl mehr als kompensieren zu können. Ich persönlich glaube allerdings nicht, dass diese Rechnung am Ende aufgehen wird. Sosehr es für mich persönlich auch wünschenswert wäre... Tatsächlich dürfte der TIOBE-Hype einfach darauf zurückzuführen sein, dass die heutigen Bosse einfach mehrheitlich erstmal rausfinden müssen, was so ein kompetenter Entwickler eigentlich im Einkauf kostet, denn die haben i.d.R. überhaupt keine eigene Erfahrung mehr mit solchem Personal. Die Frage haben sie ihren fast genauso inkompetenten IT-Subalternen der höchsten Ebene aufgetragen und die haben gegoogelt und/oder Fake-Jobs inseriert (Bei größeren Firmen waren natürlich noch ein paar Hierarchiebenen mehr involviert, bis wenigstens der erste halbwegs Google-Kompetente erreicht war, der diesen Plan hätte entwickeln können...). Wie auch immer: Letztlich ist das Ergebnis dieser verteilten Kosten-Recherche ist im TIOBE-Index aufgezeichnet. Nicht mehr...
Der Tiobe-Index ist – wie alle anderen ähnlichen Rankings – immer mit etwas Vorsicht zu genießen. Einmal abgesehen davon, dass die Ergebnisse natürlich ganz stark von der Art der Datenerhebung abhängen, gibt es noch einen anderen Effekt: Der Bewertungsalgorithmus wird von Tiobe immer wieder mal geändert mit dem Ziel, repräsentativere Ergebnisse zu liefern. Jetzt ist es aber so, dass durch so eine Änderung erst einmal alle Zahlen von einem Monat zum nächsten einen Spung nach oben oder unten machen würden, was in den Diagrammen ziemlich komisch aussähe. Vor allem bei den Spitzenreitern (Java und C) würde dies besonders auffallen. Deswegen werden mit ein Korrekturfaktoren die Bewertungen so hingebogen, dass der Verlauf wenigstens für diese Spitzenreiter (am besten auch noch für die Platze 3 bis 5) halbwegs stetig fortgesetzt wird. Durch diese Korrekturen werden aber die nachfolgenden Plätze nicht berücksichtigt, ganz im Gegenteil: Es kann sogar passieren, dass deren Sprünge verstärkt werden. Bei Assembler betrug im Juli 2015 der Anstieg gegenüber dem Vormonat mehr als Faktor 2 (von 0,754% nach 1,535%)! Mir ist kein Ereignis vom Juni bekannt (bspw. die Markteinführung eines neuen Uber-Smartphones, dass nur noch in Assembler programmiert werden kann ;-)), das einen solch plötzlichen Anstieg erklären würde. Ganz abgesehen davon, glaube ich nicht, dass sich der schnelle Anstieg von Assembler durch das IoT erklären lässt. Zum einen ist IoT derzeit ein eher noch langsamer Trend. Zum anderen werden IoT-Geräte wohl kaum in Assembler programmiert. Software für die Kommunikation über das Internet ist normalerweise zu komplex und einem zu schnellen Wandel unterworfen, als Assembler dafür reale Vorteile bringen würde. Selbst Router, die ja im Wesentlichen nur Daten hin- und herschaufeln und wenig Intelligenz haben, sind in C programmiert. Johannes O. schrieb: > Nachdem es nun so viele IoT Geräte gibt, gibts auch wieder Leute, die > versuchen, diese Geräte zu "hacken" oder reverse engineering > betreiben. Das könnte vielleicht eine Erklärung sein. Aber wieviele solcher Hacker wird es wohl geben? Ich würde mal abwarten, ob der Trend anhält, oder ob er sich in 2 bis 3 Monaten vielleicht wieder in Luft aufgelöst hat :)
Ein IoT-Gerät braucht ganz sicher kein Assembler. Wer einen kompletten Wifi- und TCP-Stack an Bord hat, der kann locker etwas C-Code verkraften. Zumal heute nur noch die allerallerkleinsten Controller - wenn überhaupt - mit C schlechter klarkommen, als mit Assembler. Bezeichnenderweise stammt der Thread ja von Moby, der überall seine Assembler-Religion predigen muss ;-)
Yalu X. schrieb: > Bei Assembler betrug im Juli 2015 der Anstieg gegenüber dem Vormonat > mehr als Faktor 2 (von 0,754% nach 1,535%)! Mir ist kein Ereignis vom > Juni bekannt (bspw. die Markteinführung eines neuen Uber-Smartphones, > dass nur noch in Assembler programmiert werden kann ;-)), das einen > solch plötzlichen Anstieg erklären würde. Es könnte ein neues Buch mit dem Titel "___ Assember Programming" erschienen sein. Oder ein vielzitierter Artikel "Why Assember Programming Is Dead".
Yalu X. schrieb: > Der Tiobe-Index ist – wie alle anderen ähnlichen Rankings – immer mit > etwas Vorsicht zu genießen. Wenn man es Böse sagen will: Die Programmiersprachen mit den höchsten Rankings haben die dümmsten Nutzer :) Begründung: Nur dumme Programmierer müssen jeden Mist in einer Suchmaschine suchen. Gute Programmierer müssen normal nicht in Suchmaschinen nach Hilfe zur ihrer Sprache suchen. Sie können die Sprache bereits sehr gut oder wissen wo eine Doku ist.
Mario M. schrieb: > IoT in Assembler, ich lach mich scheckig. Wart's ab, bald stellt Moby hier unter Projekte&Code seinen IPv6-Stack auf dem ATtiny13 vor. :-)
Clemens L. schrieb: > Oder ein vielzitierter Artikel "Why Assember > Programming Is Dead". Wenn dann "Why Assember Programming Is 0xDEAD":
Ermittelt aus Anzahl der Suchanfragen, in denen "Assembler" vorkommt.
Abgesehen davon, daß völlig unbedeutende Sprachen, die nur aus
Kryptischen Sonderzeichen bestehen, die Plätze 1..4 belegen, was sagt
das aus?
Eigentlich sucht man doch nur, wenn man nicht weiter kommt. Und da nicht
mal 2% aller Ratlosen ASM programmieren, kann man sich vorstellen wie
viel einfacher das sein muß, als in allen anderen Sprachen. Ich gehöre
zu denen der Plätze 1..4 und verbringe folglich einen signifikanten Teil
meiner Zeit damit, die Bedeutung von "{" und "}" zu ergründen.
Ich für mich werde nach dieser Mitteilung auf alle nicht-ASM-Sprachen
verzichten. In wenigen Jahren werden sie eh ausgestorben sein.
(nicht immer alles so ernst nehmen ;-)
Eine Statistik, die aus Suchanfragen auf die Anzahl Nutzer schliesst, ist sowieso unsinnig. Bei einfachen, klaren Sprachen wie C wird man nicht viel googeln müssen. Bei C++ oder Assembler sehe ich schon viel mehr Google-Bedarf. Da gibt es einfach mehr, was man nicht sofort weiss. Dann kommt hinzu: Je geübter und professioneller die Programmierer werden, desto weniger Suchanfragen werden sie absenden. Die richtigen Profis fallen also aus der Statistik raus, während Hobbyisten, Einsteiger, Gelegenheitsprogrammierer und Studenten stark überbewertet sind.
Assembler hat wie viele Sprachen seine Existenzberechtigung hauptsächlich noch in sehr speziellen Fällen. Oder, wie ein Ex-Chef von mir mal im Frust abgelassen hat "Es gibt genau 3 Gründe Assembler zu können, 2 davon sind illegal und den dritten tust Dir an wennst dafür viel Geld kriegst". So weit daneben ist das nicht. Es gab mal eine Auswertung darüber dass Programmierer unabhängig von der verwendeten Sprache (immer vorausgesetzt sie können sie, natürlich) immer gleich viel Code produzieren. Und zwar gemessen in Programmzeilen. Sprich, der gleiche Programmierer produziert pro Stunde gleich viel Code in C wie in ASM. Und das ist schon heftig, wenn man sich überlegt wieviel ASM Code zu griffeln ist für 'nen Funktionsaufruf alleine. Gepaart damit, dass (von Atmel Studio mal abgesehen...) Compiler heute wirklich gut darin sind zu optimieren, gibt's weniger und weniger Gründe in den Tiefen der Prozessorlogik umzugraben. Warum also grad beim IoT-Hype jetzt ASM wieder zu Ehren kommen soll kann ich nicht nachvollziehen. Effizienz ist da nicht unbedingt ein Thema. Präzision auch nicht. Schnell das Gerümpel auf den Markt schmeissen können ist. Und "schnell" ist nicht unbedingt das Zauberwort im Bereich der Entwicklung mit Assembler. Also, die Programme werden's schon, nur die Entwicklung ist es halt nicht! Die Dinger dann sicherheitstechnisch zerlegen und in der Luft zerreissen, dafür dient Assembler durchaus. Für die Entwicklung jedoch eher nicht.
P. M. schrieb: > Moby, der überall seine > Assembler-Religion predigen muss ;-) https://youtu.be/iHFm-kVTXW8?t=772 Dave said, he's a dickhead... Köstlich auf den Punkt gebracht :-)
Heinz L. schrieb: > Warum also grad beim IoT-Hype jetzt ASM wieder zu Ehren kommen soll kann > ich nicht nachvollziehen. Aus PR-Sicht ist ein bisschen "IoT!"-Getrolle immer noch besser, als zuzugeben, dass sie keine Ahnung haben, wo die Zahlen wirklich her kommen und was sie bedeuten.
Heinz L. schrieb: > Effizienz ist da nicht unbedingt ein Thema. Effizienz in der Endanwendung ist bei IoT-Sachen doch sowieso wurscht. Der Löwenanteil an Chipfläche/Entwicklungskosten/Energieverbrauch geht für den ganzen Wifi- und TCP-Stack drauf, die popelige Applikation dazu ist, selbst wenn haarsträubend ineffizient programmiert, ein Klacks dagegen.
P. M. schrieb: > die popelige Applikation dazu > ist, selbst wenn haarsträubend ineffizient programmiert, ein Klacks > dagegen. Du hast die ganzen Hintertürchen vergessen, die jeder Dienst auf dem Weg zwischen Produzent und Kunde eingebaut sehen will.
P. M. schrieb: > Ein IoT-Gerät braucht ganz sicher kein Assembler. Wer einen kompletten > Wifi- und TCP-Stack an Bord hat, der kann locker etwas C-Code > verkraften. Zumal heute nur noch die allerallerkleinsten Controller - > wenn überhaupt - mit C schlechter klarkommen, als mit Assembler. > > Bezeichnenderweise stammt der Thread ja von Moby, der überall seine > Assembler-Religion predigen muss ;-) Letzteres mal außen vor gelassen, fürchte ich, daß hier vielfach und auch von Dir ein Aspekt vernachlässigt wird. Klar: wer einen TCP-Stack mit IP, ARP und Bitschicht für Ethernet, WLAN und UPNP im Assembler implementieren will, kann nicht ganz dicht sein. Aber das ist ja nur das "Frontend" von IoT-Geräten. Das "Backend" von IoT-Geräten sind doch meistens Sensoren und Aktoren. Bei deren Ansteuerung spielen Timing und Codegröße oft eine kritische Rolle so daß Assembler dabei eine valide Option ist. Auch alle mir bekannten Bootloader, Betriebssystem- und USB-Kernel nutzen Assembler für bestimmte Aufgaben... Klar, das sind alles Nischenbereiche. Und beinahe überall ergibt sich ein ähnliches Bild: einige wenige besondere Teile des Code sind in Assembler, der Glue-Code aber in C geschrieben. Für andere Projekte dient Python als Glue für C-Code, der wiederum Assemblercode aufruft. Da geht es immer nur um die Ökonomie von Entwicklungs- und Laufzeit! Warum auch nicht? Der Spaß ist doch, viele Technologien zu beherrschen, ihre Stärken zu kennen und zu einem perfekten Ergebnis zu kombinieren. ;-)
Sheeva P. schrieb: > Der Spaß ist doch, viele Technologien zu beherrschen, > ihre Stärken zu kennen und zu einem perfekten Ergebnis zu kombinieren. Was hat Industrie mit Spaß zu tun? Windows 9x enthielt noch ASM-Module, die NT-Linie nicht mehr und ich vermute, dass es sich bei anderen modernen Systemen nicht anders verhält. Das Problem ist nämlich die Austauschbarkeit der Entwickler und der steht ASM ziemlich im Wege, weil es kaum noch wirklich ASM-Könner auf dem Arbeitsmarkt gibt und die Industrie sich natürlich nicht in personelle Abhängigkeiten bei Arbeitsbimbos begeben will.
> "Eine mögliche Begründung liegt im wachsenden Bedarf an > Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe > Prozesse eingesetzt wird" Darauf hätte ich nun auch getippt. So lässt sich auch noch der allerbilligste 8-Bit Controller mit wenig Speicher einsetzen und ich glaube, zu diesem Puzzle gehört ebenso die weite Verbreitung der 8051er. Sensordaten auslesen, verarbeiten, weiterleiten und Aktordaten entgegennehmen ist auch nicht sonderlich anspruchsvoll- typisch eben für abgesetzte IOT Knoten. Die große Auswertung erfolgt dann vielleicht auf potenteren Systemen- oder auch nicht, wenn man (via Asm) etwas mehr aus 8-Bittern herauszuholen weiß ;-)
Moby A. schrieb: > Darauf hätte ich nun auch getippt. So lässt sich auch noch der > allerbilligste 8-Bit Controller mit wenig Speicher einsetzen Damit sich solche Verrenkungen lohnen, müssen allerdings Stückzahlen her, wo eher in Richtung ASIC gearbeitet wird. Ich sehe nur ein sehr schmales Band, wo sich Assembler lohnen kann. Und zwar ein schrumpfendes. Wenn die Hardware-Stückkosten sinken, dann kann man damit immer geringere Software-Einmalkosten amortisieren. Sprich, es lohnt sich immer weniger, das letzte aus dem Controller zu kitzeln.
P. M. schrieb: > Sprich, es lohnt > sich immer weniger, das letzte aus dem Controller zu kitzeln. Wobei wirklich gut optimierende Compiler weit besser kitzeln können, als Programmierer und das vor allem auch noch viel schneller.
:
Bearbeitet durch User
Uhu U. schrieb: > P. M. schrieb: >> Sprich, es lohnt >> sich immer weniger, das letzte aus dem Controller zu kitzeln. > > Wobei wirklich gut optimierende Compiler weit besser kitzeln können, als > Programmierer und das vor allem auch noch viel schneller. Also, ich hab jetzt Atmel Studio 7 in dieser Hinsicht noch nicht getestet, aber bis zum 6er hat der Compiler wirklich besch...eiden optimiert. Da war der Compiler sowohl was Ausführungsgeschwindigkeit als auch Codegröße und Datenmenge angeht gut um Faktor 5 bis 10 schlechter als ich mit ASM.
Heinz L. schrieb: > Atmel Studio 7 Hat das denn einen "wirklich gut optimierenden Compiler"? Wohl eher nicht und für Bastelei reicht das ja auch. Außerdem kostet er ja den Anwender auch nichts - im Gegensatz zu professionellen Entwicklungsumgebungen.
Heinz L. schrieb: > gut um Faktor 5 bis 10 schlechter als ich mit ASM. Für ein 10-Zeilen-Projekt, oder für eins, was auch mal einige 10 KiB an Code benutzt hat?
Jörg W. schrieb: > Für ein 10-Zeilen-Projekt, oder für eins, was auch mal einige 10 KiB > an Code benutzt hat? Oh oh ... das wird nicht wieder von vorne los gehen ;-)
Moby A. schrieb: > zu diesem Puzzle gehört ebenso die weite Verbreitung der 8051er. Ich würde eher sagen, der 8051 war der Startschuß schlechthin, auch bei MCs auf breiter Linie auf den C-Zug aufzuspringen. Der Herr Keil hat mit seinem Compiler C51 wirklich gute Arbeit geleistet und mich voll überzeugt. Ich hatte mal ein Programm in Assembler angefangen und bei ~8kB Codegröße vollständig den Überblick verloren. Nach dem Umstieg auf C konnte ich es dann erfolgreich zu Ende schreiben und auch noch viele Jahre supporten, d.h. weitere Funktionen hinzufügen.
Peter D. schrieb: > Ich hatte mal ein Programm in Assembler angefangen und bei ~8kB > Codegröße vollständig den Überblick verloren. Quellcode oder Hex?
Peter D. schrieb: > Ich hatte mal ein Programm in Assembler angefangen und bei ~8kB > Codegröße vollständig den Überblick verloren. Das kann ja viele Gründe haben. Tatsächlich aber verhelfen die vielen Freiheiten des Asm-Programmierens nicht nur zu effizientem, hochdichten Code ,sondern verleiten zuweilen auch mit diesem und jenen Trick (z.B. bei Vielfachnutzung derselben Ressourcen) zu einem unübersichtlichen Programm. Da gilt es dann, sich in Disziplin zu üben und bei größeren Projekten konsequent funktionell abgeschottet zu strukturieren- mit möglichst wenig gegenseitigen Abhängigkeiten und Nebenwirkungen. Dem Trugschluß während des Programmierens, man hätte die gleiche glasklare Übersicht über das allzu turbulente, tricky Geschehen noch Wochen später gilt es hier zu widerstehen. Dazu gehört auch die genaue Doku aller Funktions-Interfaces. Wo Schatten ist, da ist immer auch Licht. Der Schatten, zeitaufwendiger mit mehr Einsatz zu programmieren relativiert sich eben im Licht bester Ressourcennutzung. Gelungene, tricky Asm-Codes für den Controller eine Nummer kleiner sind wahre Edelsteine- normaler C-Blähcode hingegen ist der dröge Alltag ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Tatsächlich aber verhelfen die vielen Freiheiten des Asm-Programmierens Nein, die Freiheiten sind das größte Hemmnis an Assembler. Man braucht Regeln, um effizient programmieren zu können. Z.B. werden beim C51 bis zu 3 Argumente in Registern übergeben, statt im SRAM. Auch die Overlaytechnik des C51 kann man in Assembler nicht verwenden, da man nach jeder Änderung einen neuen Calling-Tree erstellen müßte. Der Calling-Tree funktioniert selbst über Funktionspointer hinweg. Auch Register-Renaming ist zu Fuß nur schwer zu beherrschen. All das bewirkte, daß die C-Programme schneller und kleiner waren, da sie nicht die bei Assembler nötigen Push/Pop-Orgien brauchten. Ich hab mir zu Anfang viel das Assemblerlisting angeschaut, wie der Compiler so tickt. Die Compilerbauer sind nämlich keine Idioten und weit über dem Niveau eines mittel erfahrenen Assemblerhackers hinaus. Ich hab auch die Libs für Multiplikation und Division disassembliert. Hut ab, das hätte ich im Leben nicht so effizient hingekriegt. Es gibt natürlich Codestellen, die man in Assembler noch optimieren könnte. Im Schnitt sind daher C-Programme etwa 10..50% größer, als wenn man alles als absoluter Assemblerexperte in wahnsinnig viel Zeit zu Fuß selber schreibt. P.S.: Die 8kB waren die reine Binärgröße und ich hatte das Projekt 6 Monate pausieren lassen müssen. Da war der Sprung zu C quasi evident.
Peter D. schrieb: > Die 8kB waren die reine Binärgröße und ich hatte das Projekt 6 Monate > pausieren lassen müssen. Da war der Sprung zu C quasi evident. Das schönste Beispiel für sowas auf dem 8051 war Intel Basic, das mit 8k den 8052 gerade füllte - in purem, trickigen Assembler. Wenn sich nicht ein paar Leute die Mühe gemacht hätten, das ganze auseinander zu dröseln und zu ordnen, hätte man überhaupt keine Chance, zu kapieren, was da vor sich geht. Ich würde also tatsächlich die Grenze irgendwo bei 4k-5k Assembler, wenn er so überschaubar wie MCS51 ist, ziehen und alles jenseits davon wart- und portierbar als C schreiben. Gerade portieren auf eine andere Architektur ist ja der Witz bei C.
Moby A. schrieb: > Tatsächlich aber verhelfen die vielen Freiheiten des Asm Programmierens > nicht nur zu effizientem, hochdichten Code ,sondern verleiten zuweilen > auch mit diesem und jenen Trick (z.B. bei Vielfachnutzung derselben > Ressourcen) zu einem unübersichtlichen Programm. Da gilt es dann, sich > in Disziplin zu üben und bei größeren Projekten konsequent funktionell > abgeschottet zu strukturieren- mit möglichst wenig gegenseitigen > Abhängigkeiten und Nebenwirkungen. > Dem Trugschluß während des Programmierens, man hätte die gleiche > glasklare Übersicht über das allzu turbulente, tricky Geschehen noch > Wochen später gilt es hier zu widerstehen. Dazu gehört auch die genaue > Doku aller Funktions-Interfaces. Genau! Siehe Beitrag "Kleines Tiny13 Sensorboard" Selten so gelacht!
Peter D. schrieb: > Z.B. werden beim C51 bis zu 3 Argumente in Registern übergeben, > Auch die Overlaytechnik des C51 kann man in Assembler nicht > verwenden, > Auch Register-Renaming ist zu Fuß nur schwer zu beherrschen. Klar. Das ist auch der Grund warum komplexere Controller immer schlechter in Asm programmierbar werden. Nicht so bei vielen 8-Bittern, die fürs IOT und sehr oft MSR locker reichen. Peter D. schrieb: > Die Compilerbauer sind nämlich keine Idioten und weit > über dem Niveau eines mittel erfahrenen Assemblerhackers hinaus. Das wird auch keiner bestreiten. Nur daß das Knowhow in die Entwicklung eines pauschal für alle Anwendungsfälle möglichst guten Codes fließen muß- der Asm-Entwickler steckt es hingegen in seine konkrete App mit all ihren individuellen Bedürfnissen, die nur er am besten kennt. Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: ... erhält die Bewertung von -10. Köstlich. So ist das eben wenn Fakten nicht ins Weltbild passen ;-)
Carl D. schrieb: > Genau! Siehe Beitrag "Kleines Tiny13 Sensorboard" > > Selten so gelacht! ... und am wenigsten davon begriffen, trotz MickyMouse-Größenordnung. Deine Kommentare dort sprechen ja auch für sich ;-)
Moby A. schrieb: > Carl D. schrieb: >> Genau! Siehe Beitrag "Kleines Tiny13 Sensorboard" >> >> Selten so gelacht! > > ... und am wenigsten davon begriffen, trotz MickyMouse-Größenordnung. > Deine Kommentare dort sprechen ja auch für sich ;-) Für alle dies nicht lesen wollen/können zusammengefaßt: Trickreicher ASM-Code, der 80% der HW-Resourcen ungenutzt läßt, ohne sinnvolle Beschreibung der Tricks, die ihr Erfinder auch auf Nachfrage kaum erklären kann. Soviel zu "ohne Tricks und mit guter Doku". Aber manchem ist eh nicht zu helfen.
Carl D. schrieb: > Trickreicher > ASM-Code, ... na so sonderlich trickreich war der noch gar nicht. Aber immerhin so ressourcensparend daß dies bislang keiner in C nachbauen konnte. > der 80% der HW-Resourcen ungenutzt läßt, ... die für Erweiterungen offenstehen. Für den C-ler wie Dich ist natürlich hoher Ressourcenverbrauch das Ideal ;-) > ohne sinnvolle > Beschreibung der Tricks, die ihr Erfinder auch auf Nachfrage kaum > erklären kann. Wo kein Trick da auch keine Erklärung. Wo keine Anfrage da keine Antwort. > Aber manchem ist eh nicht zu helfen. Seh ich in Deinem Fall auch so. Jedenfalls nicht mit Asm KnowHow ;-)
:
Bearbeitet durch User
> ... die für Erweiterungen offenstehen. Für den C-ler wie Dich ist natürlich hoher Ressourcenverbrauch das Ideal ;-) Ideal ist es, alles was man bezahlt hat zu nutzen. Ja, du hast mich ertappt, bis vor einer Stunde haben ich noch eine Kiste Programmiert, die mehrere Terrabyte RAM hat. Aber nicht in C. Ich würde auch keinen Tiny13 nehmen sondern eher 45/85. Die kosten wenige Cent mehr, wenn überhaupt, da paßt aber ein 1-Wire-Client rein, so daß ich mir keine Sorgen um die Gegenseite machen muß, ich keinem erklären muß, wie die Bit's flitzen und vor allen keine gelegentlichen Übertragungsfehlers bei nur 300Baud, siehe verlinkten Board, entstehen, die ich Dank 2Bit-CRC nicht erkennen kann. Übrigens: viel schlimmer, ich benutze für AVR's C++. Satanisch, oder? Und warum? Weil ich's kann!
Moby A. schrieb: > Nicht so bei vielen 8-Bittern, die fürs IOT und sehr oft MSR locker > reichen. Reichen sie, aber du weißt auch, wofür das „I“ in „IoT“ steht, ja? Wir sind gespannt auf deinen ersten IPv6-Stack. :)
Carl D. schrieb: > Ideal ist es, alles was man bezahlt hat zu nutzen. Oder ist es nicht besser, sich vorausschauend Ressourcen offenzuhalten? > Ja, du hast mich ertappt, bis vor einer Stunde haben ich noch eine Kiste > Programmiert, die mehrere Terrabyte RAM hat. Solche Leute haben meist wenig Verständnis fürs Kleine & Feine ;-) > Ich würde auch keinen Tiny13 nehmen sondern eher 45/85. Dann mach das! Für eigene Projekte! Wo sind die? > vor allen keine gelegentlichen > Übertragungsfehlers bei nur 300Baud, siehe verlinkten Board, entstehen, > die ich Dank 2Bit-CRC nicht erkennen kann Fehler sind schon aufgrund des Übertragungsverfahrens kaum möglich. Den Rest der Wahrscheinlichkeit erschlägt in der Praxis die kleine Checksumme. > Übrigens: viel schlimmer, ich benutze für AVR's C++. Satanisch, oder? > Und warum? Weil ich's kann! Ich nehme Asm und spare an allen Fronten. Und warum? Weil ich's kann ;-)
ASM ohne Mnemonics ist fast tödlich. Habe es vor 32 Jahren mal gelernt, das war unter Newdos 80. Hatte dann auch schon ein "Evaluierungsboard" mit einem Z80. Hatte damals auch einen TI99/4A mit X-Basic, und das war für mich die bevorzugte Programmiersprache. In der #Schule habe ich das LNW-Basic dem EDTASM ebenfalls vorgezogen, wobei ich ASM nicht grundsätzlich ablehne. Als BASICer habe ich Bascom, die Vollversion, da kann man auch ASM teilweise implementieren, was ich gut finde. Ein komplettes ASM-Programm zu schreiben, entzieht sich meines könnens, wäre dann so, wie einen Lochstreifen von Hand zu lochen, und die Lochfehler dann jedesmal auf fünf Löcher auszustanzen, was dann "Ignorieren" bedeutet. Zeitkritische Aktionen sind mit ASM schon noch gerechtfertigt. Aber der ASM-Dialekt, den ich lernte, eben für den Z80, der gilt nicht mehr für den AVR, ganz anderer Dialekt.
:
Bearbeitet durch User
Jörg W. schrieb: > Wir sind gespannt auf deinen ersten IPv6-Stack. :) Sorry. Der steckt schon in einem gekauften XportPro. Das schmälert den Nutzen des Traumgespanns ASM/AVR aber in keiner Weise ;-)
:
Bearbeitet durch User
Jörg W. schrieb: > Wir sind gespannt auf deinen ersten IPv6-Stack. :) Angesichts der viele 32-Bit Daten darin wär schon IPv4 eine ernste Herausforderung. ;-)
Thomas S. schrieb: > Aber der ASM-Dialekt, den ich lernte, eben für den Z80, der gilt nicht > mehr für den AVR, ganz anderer Dialekt. Stimmt. Ist deshalb jetzt aber auch nicht schwieriger. Im Vergleich zum Z80 ist der AVR mit allem Drum und Dran die wahre Freude.
A. K. schrieb: > Angesichts der viele 32-Bit Daten darin wär schon IPv4 eine ernste > Herausforderung. ;-) Warum muß man auch einen 8-Bitter damit behelligen? Das wird als gekauftes Modul angeflanscht und gut ist.
> Ich nehme Asm und spare an allen Fronten. Und warum? Weil ich's kann ;-) Und wer war nochmal der TO dieses Missions-Threads? >> Ja, du hast mich ertappt, bis vor einer Stunde haben ich noch eine >> Kiste Programmiert, die mehrere Terrabyte RAM hat. > Solche Leute haben meist wenig Verständnis fürs Kleine & Feine ;-) Doch, denn die kennen mehr als nur ihre kleine Nußschale.
Moby A. schrieb: > Klar. Das ist auch der Grund warum komplexere Controller immer > schlechter in Asm programmierbar werden. Was ist denn am 8051 komplex? Ich fand ihn sehr einfach zu lernen. Mit Register-Renaming meinte ich, der Compiler würde gerne R7 nehmen, stellt aber fest, daß ein Unterfunktionsaufruf R7 zerstören würde und entscheidet sich dann für R6 um. Dazu legt der C51 im ersten Paß eine Liste der Registerbenutzung je Funktion an und macht optional weitere Compilerläufe. Mache sowas mal in Assembler, da verlierst Du schnell den Überblick.
Carl D. schrieb: > Und wer war nochmal der TO dieses Missions-Threads? Ach der Carl fühlt sich durch Fakten missioniert? Schade, da kann ich Dir nicht helfen. Einfach nicht lesen könnte für Dich die Lösung sein. Gewissen Broschüren-Verkäufern auf der Straße geh ich auch immer aus dem Weg.
Moby A. schrieb: >> Wir sind gespannt auf deinen ersten IPv6-Stack. :) > > Sorry. Der steckt schon in einem gekauften XportPro. > Das schmälert den Nutzen des Traumgespanns ASM/AVR aber in keiner Weise > ;-) Doch: es ist damit eigentlich komplett überflüssig. Für deine IoT-Anwendungen greifst du auf ein Linux auf einem 32-Bit-Prozessor zurück, und dann argumentierst du, dass ein 8-Bitter dafür doch völlig ausreichend sei und angeblich Assembler durch IoT Aufwind bekäme? Irgendwas passt da nicht.
Peter D. schrieb: > Mache sowas mal in Assembler, da verlierst Du schnell den Überblick. Braucht Moby nicht zu machen. Bei seinen Assembler-Quickies mit 23 Zeilen (oder so) ist es unmöglich, den Überblick zu verlieren. Das passt selbst auf einem VT100 noch auf eine Bildschirmseite.
Peter D. schrieb: > Mit Register-Renaming meinte ich, der Compiler würde gerne R7 nehmen, > stellt aber fest, daß ein Unterfunktionsaufruf R7 zerstören würde und > entscheidet sich dann für R6 um. Dazu legt der C51 im ersten Paß eine > Liste der Registerbenutzung je Funktion an und macht optional weitere > Compilerläufe. > Mache sowas mal in Assembler, da verlierst Du schnell den Überblick. Nein das tue ich nicht! Warum? - Weil genug Register für feste Zuordnungen da sind - Weil ein vorhandenes System der Registerverwendung (in Interrupts, im Hauptprogramm) hier sehr hilfreich ist. Bislang ging da der Überblick bis hoch zu 10K nie flöten. In wenigen Fällen ist manchmal ein Push/Pop nötig von dem man das Gefühl hat, daß dies in optimierterer Form vielleicht überflüssig wäre. Da muß man sich dann aber von einem allzu hohen Perfektionsanspruch freimachen.
Jörg W. schrieb: > Irgendwas passt da nicht. Nicht selten hat man embedded ein Linux laufen, bei dem die schmutzigen Dinge in einen 8-Bitter ausgelagert sind. Moby macht das eben umgekehrt. Er lagert die aus seiner Sicht schmutzigen Dinge in ein eingekauftes 32-Bit Linux Subsystem aus, das er dann mit seinem ATtiny anspricht.
Jörg W. schrieb: > Für deine > IoT-Anwendungen greifst du auf ein Linux auf einem 32-Bit-Prozessor > zurück, Warum nicht? Habe da keine ideologischen Schranken zu überwinden. > dann argumentierst du, dass ein 8-Bitter dafür doch völlig > ausreichend sei und angeblich Assembler durch IoT Aufwind bekäme? Fürs Messen,Verarbeiten,Weiterleiten von Sensor/Aktordaten auf ein übergeordnetes System allemal. Und selbst das kann noch ein AVR sein mit entsprechender angeflanschter Netz-Schnittstelle. Wo ist das Problem?
Moby A. schrieb: >> Mache sowas mal in Assembler, da verlierst Du schnell den Überblick. > > Nein das tue ich nicht! > Warum? > - Weil genug Register für feste Zuordnungen da sind > - Weil ein vorhandenes System der Registerverwendung (in Interrupts, im > Hauptprogramm) hier sehr hilfreich ist. Und genau deshalb ist der Compiler Dir dabei überlegen: Weil er seine Register und Ressourcen dynamisch verwalten und bei jedem Compile-Durchlauf neu optimieren kann. Die einzige ASM-Anwendung sehe ich heute noch in hochoptimierten DSP-Funktionen, wenn der DSP-Core meherere Berechnungen in einem Befehl parallel ausführen kann. Stefan
Stefan K. schrieb: > Und genau deshalb ist der Compiler Dir dabei überlegen: > Weil er seine Register und Ressourcen dynamisch verwalten und bei jedem > Compile-Durchlauf neu optimieren kann Ach was. Der Asm-Programmierer macht seine Optimierung (mit System) im Kopf. Da ist bis zu Projekten einer gewissen Größenordnung auch gar nichts dabei. Damit meine ich noch nicht mal die endgültige Codegröße, sondern die Komplexität der enthaltenen Algorithmen bzw. Funktionalität. Bei großartigen Berechnungen und Operationen mit großen verschiedenartigen Datenmengen ist da um Beispiel eine sinnvolle Grenze in Sichtweite.
:
Bearbeitet durch User
Moby A. schrieb: >> dann argumentierst du, dass ein 8-Bitter dafür doch völlig >> ausreichend sei und angeblich Assembler durch IoT Aufwind bekäme? > > Fürs Messen,Verarbeiten,Weiterleiten von Sensor/Aktordaten auf ein > übergeordnetes System allemal. Das könnte aber der 32-Bitter gleich noch nebenbei erledigen, wenn man ihn direkt programmiert, statt ihn nur als Zukauf zu benutzen.
Jörg W. schrieb: > Das könnte aber der 32-Bitter gleich noch nebenbei erledigen, wenn > man ihn direkt programmiert, statt ihn nur als Zukauf zu benutzen. Das eine System das alles macht? So verlockend das klingt, so unpraktisch ist es. Ein Netz einfacher IOT-Devices dort wo sie gebraucht werden, gekoppelt mit einer zentralen Internet-Schnittstelle ist die optimale Lösung! Und genau für diese verteilten Devices sehe ich Asm im Aufwind.
:
Bearbeitet durch User
Frank M. schrieb: > Bei seinen Assembler-Quickies mit 23 > Zeilen (oder so) ist es unmöglich, den Überblick zu verlieren. Zählen kannst Du also auch nicht. Aber Du hast Recht, für den Überblick habe ich meine Codes gut strukturiert. Nun müssen für den Lesenden nur noch zwei Dinge hinzukommen: Den Code verstehen- und verstehen wollen!
:
Bearbeitet durch User
Moby A. schrieb: > ... erhält die Bewertung von -10. Mach doch einen Link auf diesen Thread in 'Witz der Woche'. Da gibt's sicher richtig Pluspunkte.
Carl D. schrieb: > Für alle dies nicht lesen wollen/können zusammengefaßt: Trickreicher > ASM-Code, der 80% der HW-Resourcen ungenutzt läßt, ohne sinnvolle > Beschreibung der Tricks, die ihr Erfinder auch auf Nachfrage kaum > erklären kann. Soviel zu "ohne Tricks und mit guter Doku". Wer weiß, vielleicht ist er ja so clever, dass er einen genetischen Algorithmus auf sein Problem angesetzt hat. Da fällt es nicht immer leicht, dahinter zu kommen, was der Algorithmus sich so bei der Lösung dabei "gedacht" hat ;-)
:
Bearbeitet durch User
Ralf G. schrieb: > Mach doch einen Link auf diesen Thread in 'Witz der Woche'. Brauch ich nicht. Mich amüsieren ja gerade die Minuspunkte, für Tatsachen wohlgemerkt ;-)
Alle anderen amüsiert Moby's Vorstellung des Begriffes "Tatsachen". Das ist selten das von dem man nachts träumt. Aber träum weiter.
Wenn ich dran denke, welche Klimmzüge ich mit den RAMless AT90S1200, ATtiny12/15 gemacht habe, bekommen ich heute noch das kalte Grausen. Ich hatte sogar ein Pseudo-Call-Macro geschrieben, um den lächerlich kleinen Hardwarestack auszutricksen.
ist das ein Witz Thread? ich sollte mal eine EWSD Baugruppe prüfen, was man mir vorlegte zur Info waren 1200 Seiten ASM Listing, ich lehnte dankend ab ohne weitere Dokumentation, der Dr. der das dann baute baute auch Luftmessungen, der Prüfautomat lieferte auch Ergebnisse wenn die BG nicht mal angeschhlossen war.
Moby A. schrieb: > Carl D. schrieb: >> Alle anderen > > Du solltest nicht unbedingt immer von Dir auf andere schließen ;-) Ach wenn du doch ein besseres Vorbikd wärest ...
Ach Moby. In deiner gemütlichen kleinen Welt schwachbrüstiger 8-Bitter magst du ja teilweise recht haben. In der echten Welt liegen die Herausforderungen der Software-Entwicklung aber längst nicht mehr im Herauskitzeln einzelner Taktzyklen oder Speicherbytes. Vergleiche nur mal die Kosten einer Entwickler-Stunde oder sogar eines erst im Feld entdeckten Bugs mit den Kosten für Speicher oder Rechenleistung...
Peter D. schrieb: > Wenn ich dran denke, welche Klimmzüge ich mit den RAMless AT90S1200, > ATtiny12/15 Ja ja, die ersten und ganz kleinen ihrer Art... Da muß ich an die ersten PICs denken. Grausam. Assembler zum abgewöhnen war das. Aber zum Glück folgten auf dem Fuße schnell die komfortableren AVRs. Joachim B. schrieb: > ist das ein Witz Thread? Nein. Er bezieht sich auf die Meldung im Eröffnungsposting. Auch Du bist aufgerufen, dem Wiedererstarken von Asm auf den Grund zu gehen! > 1200 Seiten ASM Listing, ich lehnte dankend ab ohne weitere > Dokumentation, Genau sooo sollte es ja nun auch nicht sein! P. M. schrieb: > In deiner gemütlichen kleinen Welt > In der echten Welt Da seh ich keinen Unterschied. Immerhin wird IOT gerade in Haushalten bzw. im SmartHome eine große Rolle spielen. P. M. schrieb: > Herauskitzeln einzelner Taktzyklen oder Speicherbytes. Statt dessen werden einfach ein paar MB Controllerspeicher und viele MHz draufgesattelt. Schon klar. Gerade läuft der Download >2GB fürs aktuelle Windows ;-) > Kosten einer Entwickler-Stunde oder sogar eines erst im Feld > entdeckten Bugs mit den Kosten für Speicher oder Rechenleistung... Womit also erklärst Du Dir die steigende Bedeutung von Asm ?
:
Bearbeitet durch User
Moby A. schrieb: > Womit also erklärst Du Dir die steigende Bedeutung von Asm ? Die muss man sich nicht erklären, da es sie nicht gibt. Hey, das ist "TIOBE". Da kann man auch die Wettervorhersage heranziehen, die ist mindestens genauso fundiert, was die Verbreitung von Programmiersprachen angeht.
Moby A. schrieb: > Womit also erklärst Du Dir die steigende Bedeutung von Asm ? Sie ist nicht vorhanden. Du hast ja auch nur so weit den Artikel zitiert, wie es dir zupasse kam. So geht es weiter: "Wie aussagekräftig der TIOBE-Index und ähnliche Rankings sind, ist immer wieder berechtigtes Diskussionsthema. Die Liste entsteht durch das Zählen der Treffer für die Anfrage +"<language> programming" in 25 Suchmaschinen. Damit lässt sie andere Ressourcen der Programmierer außer acht." Für mich sieht das eben genau andersrum aus. Wer sich auf Assembler einlässt, hat viele Fragen - die für andere Sprachen gar nicht nötig werden. Anscheinend haben ein paar Assembler Programmierer das Internet gefunden und löchern es jetzt mit Fragen :-)
:
Bearbeitet durch User
Übrigens erlebt laut Tiobe neben Assembler auch Cobol seit einiger Zeit einen Aufschwung: http://www.tiobe.com/index.php/content/paperinfo/tpci/COBOL.html Auch Fortran ist nach diesem Indes wieder stark auf dem Vormarsch (über Faktor 2 seit Ferbruar 2014) und könnte es in den nächsten paar Monaten durchaus in die Top 20 schaffen. Da ist sicher irgendwo ein großer Nostalgieclub für Programmiersprachen gegründet worden. Neben Cobol und Fortran beschäftigen sich die Mitglieder natürlich auch mit Assembler, aber nicht etwa mit dem für AVRs, sondern mit dem für die IBM-Mainframes: https://en.wikipedia.org/wiki/IBM_Basic_assembly_language_and_successors Damit wurden früher – ähnlich wie mit Cobol – ausgewachsene Anwendungen für Banken, Finanzverwaltung u.ä. programmiert. Dank intensiv genutzter Makrofähigkeiten konnte damit fast so komfortabel programmiert werden wie in einer Hochsprache. Ob damit auch IoT-Devices programmiert werden? Ich würde es mal eher bezweifeln ;-)
Matthias S. schrieb: > "Wie aussagekräftig der TIOBE-Index und ähnliche Rankings sind, ist > immer wieder berechtigtes Diskussionsthema. Die Liste entsteht durch das > Zählen der Treffer für die Anfrage +"<language> programming" in 25 > Suchmaschinen. Damit lässt sie andere Ressourcen der Programmierer außer > acht." @Moby Dieses Zitat sollte reichen. Leg erstmal ein Lesezeichen zu diesem Thread neben 'heise.de'. Und wenn dann Assembler in ein paar Tagen oder Wochen C dicht auf den Fersen ist, kann man die Statistik ja noch mal neu bewerten.
Yalu X. schrieb: > Übrigens erlebt laut Tiobe neben Assembler auch Cobol seit einiger Zeit > einen Aufschwung: Schade, dass die sich auf Programmiersprachen beschränken... Ein Index über die Wirkung der Störche die menschliche Geburtenrate wäre sicherlich sehr erhellen.
Yalu X. schrieb: > Auch Fortran ist nach diesem Indes wieder stark auf dem Vormarsch vielleicht wollen auch einfach nur viele diesen job: http://www.popularmechanics.com/space/a17991/voyager-1-voyager-2-retiring-engineer/ und bereiten sich auf das vorstellungsgespräch vor... ;-)
Uhu U. schrieb: > Schade, dass die sich auf Programmiersprachen beschränken... Ein Index > über die Wirkung der Störche die menschliche Geburtenrate wäre > sicherlich sehr erhellen. Das kannst du haben: http://www.motor-talk.de/bilder/warum-benzinpreise-in-wirklichkeit-immer-noch-preiswert-sind-g45736413/stoerche-geburten-i204391169.html Oder in etwas wissenschaftlicherem Kontext: http://www.univie.ac.at/sowi-online/esowi/cp/methodologiesowi/methodologiesowi-38.html
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Die muss man sich nicht erklären, da es sie nicht gibt. Es kann nicht sein was nicht sein darf... Matthias S. schrieb: > Wer sich auf Assembler > einlässt, hat viele Fragen Andersrum. Der hat die richtigen Antworten wenn es darum geht, performanten Code auf engstem Raum zu verpacken, den nächstkleineren Controller nehmen und überhaupt ganz lange bei nur einer Architektur bleiben zu können ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Der hat die richtigen Antworten wenn es darum geht, > performanten Code auf engstem Raum zu verpacken ;-) Den Smiley kanst du auch weglassen. Weiß doch jeder, dass solche Witze deine Stärke sind.
Ralf G. schrieb: > Den Smiley kanst du auch weglassen. Solange ich das Wegdiskutierenwollen / Ignorieren von Fakten amüsant finde nicht. Aber Du darfst auch lachen, worüber auch immer. Gute Stimmung schadet nie!
:
Bearbeitet durch User
Dieses Jahr habe ich ca. 100% mehr Störche beobachtet als letztes Jahr. Damit wird klar, wie es zu diesem überraschenden Statistik kommen konnte: Störche verfügen über keinerlei Hochsprachenerfahrung und programmieren deshalb ausschließlich in Assembler. Es mag ja schön sein, wenn eine Statistik die persönliche Meinung stützt. Nur dadurch ändert sich ihr Wahrheitsgehalt nicht.
Carl D. schrieb: > Dieses Jahr habe ich ca. 100% mehr Störche beobachtet als letztes Jahr. Ist das wieder Deine Spezialdisziplin "Lächerlichmachen" ? > Es mag ja schön sein, wenn eine Statistik die persönliche Meinung > stützt. Nur dadurch ändert sich ihr Wahrheitsgehalt nicht. Der Wahrheitsgehalt muß sich auch nicht ändern. Er ist gegeben ;-)
:
Bearbeitet durch User
Carl D. schrieb: > Auch 0 ist ein Wert! Das ist Dein Ergebnis! Und es rühmt Dich nicht gerade ;-)
:
Bearbeitet durch User
Moby A. schrieb: > wenn es darum geht, performanten Code auf engstem Raum zu verpacken ... dann zeig uns den halt mal. Aber komm nicht wieder mit deinem (bisher einzigen) "20 Zeilen" Micky Maus programm. LOL
Gu. F. schrieb: > ... dann zeig uns den halt mal. Soweit ich mich erinnere ist das bei Dir sinnlos, da Du Asm nur vom Hörensagen kennst und nach wie vor nicht mal zählen kannst. Alle anderen schauen in das schon erwähnte Projekt. Da wird gezeigt wie sowas geht. Ein spezielles "LOL" nur für Dich ;-)
:
Bearbeitet durch User
Angehängte Dateien:
-
fastest_growing.png
37 KB
Hey, lasst dem Moby doch seine Religion... Quelle: http://www.xkcd.com/1102/
Johann L. schrieb: > Hey, lasst dem Moby doch seine Religion... Nix Religion. Sondern Fakten, Fakten, Fakten. Hat schon seine Gründe, weshalb es Asm immer noch gibt. Zumindest solange noch simple 8-Bitter die MSR+IOT Welt bevölkern stirbt das nicht aus. Und das werden sie noch laaaange... Ganz einfach weil sie die einfachste Lösung für vieles bieten.
:
Bearbeitet durch User
Moby A. schrieb: > Hat schon seine Gründe, weshalb es Asm immer noch gibt. Assembler wird es immer geben. Sowas stirbt doch nicht aus. Es ist nunmal übersichtlicher, die OP-Codes mit einem Kürzel zu kennzeichnen und nicht nur die Beschreibung in die Doku des Prozessors aufzunehem.
Ralf G. schrieb: > Moby A. schrieb: >> Hat schon seine Gründe, weshalb es Asm immer noch gibt. > > Assembler wird es immer geben. Sowas stirbt doch nicht aus. Es ist > nunmal übersichtlicher, die OP-Codes mit einem Kürzel zu kennzeichnen > und nicht nur die Beschreibung in die Doku des Prozessors aufzunehem. Ein Grund mehr ;-))
Moby A. schrieb: > Hat schon seine Gründe, weshalb es Asm immer noch gibt. > Zumindest solange noch simple 8-Bitter die MSR+IOT Welt bevölkern stirbt > das nicht aus. Assembler und IoT in einem Atemzug zu nennen ist mehr als mutig. Gibt es auch nur einen einzigen IP-Stack, der in Assembler geschrieben ist?
Moby schreibt grad dran. IPv6 macht noch Probleme, die Register gehen aus. Nur braucht man das eben für Milliarden Meßplatinen im WLAN.
Jörg W. schrieb: > Moby A. schrieb: >> Nicht so bei vielen 8-Bittern, die fürs IOT und sehr oft MSR locker >> reichen. > > Reichen sie, aber du weißt auch, wofür das „I“ in „IoT“ steht, ja? > > Wir sind gespannt auf deinen ersten IPv6-Stack. :) Moby plagt sich mit sowas nicht rum. Alles, was über ein paar Byte rausschieben rausgeht, kauft er als fertiges Modul, das er mit seinem AVR nur noch per UART dirigiert. So kann man natürlich wirklich alles mit wenig Logik erschlagen, und dafür tut es jeder Tiny. Unter der Prämisse hat er natürlich recht. Ich frage mich dann nur erstens, wozu er dann sein bißchen Logik so unglaublich optimiert haben will, wenn alles doch außerhalb in zugekauften Modulen passiert und schneckenmäßig seriell angesprochen wird. Und zweitens, wieso er am Controller 1 Cent sparen will, wenn für WLAN, Bluetooth und was weiß ich was jeweils mehrere Euro ausgibt (während ein Controller für wenig Geld mehr das alles sparen würde, weil er einfach genug Dampf hat). In jedem seiner zugekauften Teile hat er mehr Kosten, Rechenleistung und Stromverbrauch als andere im Controller - aber sein Tiny, der sich mangels Arbeit nur langweilt, ist top optimiert (wenn sein Programm zufällig überhaupt funktioniert). Aber jeder wie er will... Moby A. schrieb: > A. K. schrieb: >> Angesichts der viele 32-Bit Daten darin wär schon IPv4 eine ernste >> Herausforderung. ;-) > > Warum muß man auch einen 8-Bitter damit behelligen? > Das wird als gekauftes Modul angeflanscht und gut ist. z.B. so > Assembler wieder auf dem Weg nach vorn Ich fasse mal vorläufig zusammen: Assembler ist auf dem Weg nach vorne, ja. Aber alle anderen auch, nur viel schneller.
:
Bearbeitet durch User
Carl D. schrieb: > Moby schreibt grad dran. Moby hat einen XportPro für diese Fälle. Moby braucht sich nicht mit IPVx befassen. Hattest Du bestimmt schon wieder vergessen, passt ja gerade schlecht... Rufus Τ. F. schrieb: > Assembler und IoT in einem Atemzug zu nennen ist mehr als mutig. Siehe hier: > "Eine mögliche Begründung liegt im wachsenden Bedarf an > Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe > Prozesse eingesetzt wird" Warum muß auch jedes IOT Device welches ins Internet will über einen eigenen IP-Stack verfügen? Diese Anbindung macht man (bestens stromversorgt) zentral, alles andere ist (gegenwärtig) Blödsinn.
Klaus W. schrieb: > wenn alles doch außerhalb in > zugekauften Modulen passiert Na na. Das meiste Musik spielt schon noch in vielen Tinys, Megas Xmegas. > schneckenmäßig seriell Langt doch Klaus. Wir reden von SmartHome Anwendungen und nicht von Multimedia. Klaus W. schrieb: > Und zweitens, wieso er am Controller 1 Cent sparen will, wenn für WLAN, > Bluetooth und was weiß ich was jeweils mehrere Euro ausgibt (während ein > Controller für wenig Geld mehr das alles sparen würde, weil er einfach > genug Dampf hat). Vielleicht weil der Controller in Aktor/Sensorknoten kleiner, preiswerter, einfacher programmierbar ausfallen kann? Nochmal speziell für Dich: Die Internet-Anbindung kann zentral geschehen. Klaus W. schrieb: > In jedem seiner zugekauften Teile Das sind nur wenige, dafür die am richtigen Platz. > aber sein Tiny, der sich > mangels Arbeit nur langweilt, ist top optimiert Das gibts schon einige mehr die genau dort Dienst tun wo sie gebraucht werden ;-) > wenn sein Programm > zufällig überhaupt funktioniert Ha ha ha, was für ein lustiger Klaus. Klaus W. schrieb: > Ich fasse mal vorläufig zusammen: > Assembler ist auf dem Weg nach vorne, ja. Prima. Asm spart nämlich Ressourcen und macht Spaß! Andere Wege führen sicher auch zum Ziel. Aber nicht so sparsam und effizient. Und vor allem nicht so einfach !!!
:
Bearbeitet durch User
Moby A. schrieb: > Langt doch Klaus. Wir reden von SmartHome Anwendungen und nicht von > Multimedia. Hmm, ja, den Haustüröffner glaub ich dir. Aber die dort installierte Kamera?
:
Bearbeitet durch User
A. K. schrieb: > Aber die dort installierte Kamera? So es denn eine geben sollte: Webcam-Funktionalität muß man heute gewiss nicht mehr selber basteln.
Moby A. schrieb: > Warum muß auch jedes IOT Device welches ins Internet will über einen > eigenen IP-Stack verfügen? Automatischer Update. Stell dir vor, du hast 50 Stück eingekauftes IoT Zeugs in der Wohnung und jeden Samstag ist Patchday. Ausserdem kommt das I in IoT nicht von I2C.
:
Bearbeitet durch User
A. K. schrieb: > Automatischer Update. Stell dir vor, du hast 50 Stück eingekauftes IoT > Zeugs in der Wohnung und jeden Samstag ist Patchday. Patchday. Genau. Aber nicht beim Selberbastler. Gott sei Dank auch. So ein IOT Device braucht doch nur einmal richtig programmiert zu werden und tut dann seinen Dienst. Updateritis- das haben andere, mit anderer Hard- und Software nötig ;-) > Ausserdem kommt das > I in IoT nicht von I2C. Aber von Anbindung ans Internet. Und die kann auf viele Weisen geschehen. Am sinnvollsten (jedenfalls bei viel SmartHome- typischem Kleinzeug) zentral. Die kleinen Aktor/Sensorknoten können schließlich auch anders als via IP miteinander bzw. mit ihrer Zentrale sprechen.
Moby A. schrieb: > Patchday. Genau. Aber nicht beim Selberbastler. Natürlich nicht dein Tiny, aber für all die kleinen eingekauften 32-Bit Helferlein, mit denen du ihn umgibst.
A. K. schrieb: > aber für all die kleinen eingekauften 32-Bit > Helferlein, Die wenigen Helferlein update ich manuell, sofern erforderlich. Das war es bislang noch NIE. Wofür auch, wenn sie funktionieren? Etwa für "Sicherheitslücken"? Das Thema fällt bei Selbstbau aus, das hat man schließlich selber in der Hand.
Moby A. schrieb: > Warum muß auch jedes IOT Device welches ins Internet will über einen > eigenen IP-Stack verfügen? Ohne IP-Stack ist es kein IoT-Device, sondern nur ein irgendwas mit irgendner Schnittstelle. Nur zu gebrauchen, wenn noch ein korrespondierendes Gegenstück dazukommt.
Rufus Τ. F. schrieb: > Ohne IP-Stack ist es kein IoT-Device, Na schön. Wenn man es so definieren möchte. Ich denke aber daß das nicht so eng festgelegt ist. Internet of Things kann technisch recht flexibel umgesetzt sein. > Nur zu gebrauchen, wenn noch ein > korrespondierendes Gegenstück dazukommt. Genau. Für alles eine Zentrale mit einem IP-Stack. Den dann nicht in Assembler, das will ich zugestehen ;-) @Minus-Bewerter: Nicht nachlassen! Du bist schon hinten dran, jetzt aber hopp hopp ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Etwa für "Sicherheitslücken"? Das Thema fällt bei Selbstbau aus, > das hat man schließlich selber in der Hand. Wie gut, das du im Brustton der Überzeugung von dir behaupten kannst, ausschliesslich sichere Programme zu schreiben. ;-) Ansonsten wird da vielleicht mal ein Webserverlein dabei sein. Wenn es kein SSL kann: unsicher. Und wenn es SSL kann: unsicher, wenn nicht öfter mal gepatcht. In den letzten ca. 2 Jahren ging es allein beim SSL ziemlich rund. Und wenn dir die Sicherheit egal sein sollte, dann wird dir dein Browser irgendwann die Leviten lesen, weil er das alte SSL nicht mehr akzeptiert und dein Haus nicht mehr auf dich hört.
Rufus Τ. F. schrieb: > Ohne IP-Stack ist es kein IoT-Device, sondern nur ein irgendwas mit > irgendner Schnittstelle. Moby ist da flexibel. Sein IOT = I2c-Of-Things reicht ihm.
A. K. schrieb: > Wie gut, das du im Brustton der Überzeugung von dir behaupten kannst, > ausschliesslich sichere Programme zu schreiben. ;-) Selbstverständlich. Darf man nur nicht verwechseln mit 'theoretisch' sicher. Es langt hingegen ein 'praktisch' sicher. Wie schön daß man mit eigenen Controllern, eigener Software und uneingeschränkten Möglichkeiten von Asm alles selbst in der Hand hat! A. K. schrieb: > Ansonsten wird da vielleicht mal ein Webserverlein dabei sein. Wenn es > kein SSL kann: unsicher. Und wenn es SSL kann: unsicher, wenn nicht > öfter mal gepatcht. In den letzten ca. 2 Jahren ging es allein beim SSL > ziemlich rund. Der Webzugriff aufs selbstgebaute Smarthome kann so sicher oder unsicher sein wie er will- wenn der Datenstrom ab Internet-Schnittstelle vollständig in der Hand des Bastlers liegt. > Und wenn dir die Sicherheit egal sein sollte, dann wird > dir dein Browser irgendwann die Leviten lesen, weil er das alte SSL > nicht mehr akzeptiert und dein Haus nicht mehr auf dich hört. Sobald zuviele SSL Restriktionen in die Suppe spucken wird der XPort geupdatet oder ersetzt. Da muß der Hebel nur an einem Punkt ansetzen!
Moby A. schrieb: > Zumindest solange noch simple 8-Bitter die MSR+IOT Welt bevölkern stirbt > das nicht aus. Nochmals: Ein IoT-Gerät muss nur schon für den WLAN-Stack so leistungsfähig sein, dass ein paar zusätzliche Taktzyklen oder Speicherbytes nicht ins Gewicht fallen. Erst recht nicht, wenn man die Zusatzkosten betrachtet, um sie herauszukitzeln. Hast du eigentlich überhaupt mal ein grösseres Projekt gemacht ausserhalb von Assembler und 8-Bittern?
Klaus W. schrieb: > Ich frage mich dann nur erstens, wozu er dann sein bißchen Logik so > unglaublich optimiert haben will, wenn alles doch außerhalb in > zugekauften Modulen passiert und schneckenmäßig seriell angesprochen > wird. Na damit noch Platz für "künftige Erweiterungen" bleibt Prust
Moby A. schrieb: > @Minus-Bewerter: Nicht nachlassen! Du bist schon hinten dran, jetzt aber > hopp hopp ;-) Nun ja, wenn du Wert drauf legst ;-)
P. M. schrieb: > Hast du eigentlich überhaupt mal ein grösseres Projekt gemacht > ausserhalb von Assembler und 8-Bittern? Du kennst unseren Moby nicht? Mehr als diese paar Zeilen sind zumindest mir nicht bekannt. Beitrag "Kleines Tiny13 Sensorboard" Und selbst die waren mit Fehlern gespickt.
:
Bearbeitet durch User
Moby A. schrieb: > Jörg W. schrieb: >> Wir sind gespannt auf deinen ersten IPv6-Stack. :) > > Sorry. Der steckt schon in einem gekauften XportPro. > Das schmälert den Nutzen des Traumgespanns ASM/AVR aber in keiner Weise > ;-) Hi Moby, die X-Ports sind schon ganz nett, aber relativ teuer. So ein Teil kostet um die 70 Euro. Wäre es da nicht sinnvoller einfach einen günstigen 32bitter mit integriertem MAC für etwa 3 Euro zu nehmen, dann einen externen Phy + Buchse drann und fertig? Dann könnte man getrost auf Asm verzichten und gleich alles auf dem 32bitter in einer Hochsprache implementieren. Fertige IP-Stacks gibt es ohnehin schon fertig. Dann noch ev. ein kleines RTOS oder ein anderes Betriebssystem drauf und fertig ist das System zu einem Bruchteil der Kosten. Für mich wäre es einfach ungeschickt erst ein sündhaft teures Modul zu kaufen um dann Klimmzüge in ASM zu machen um Ressourcen in einem 8bit-µC zu sparen, der quasi nur als Anhängsel am Xport hängt. Grüße! Jo
:
Bearbeitet durch User
Moby A. schrieb: > Aber von Anbindung ans Internet. > Und die kann auf viele Weisen geschehen. > Am sinnvollsten (jedenfalls bei viel SmartHome- typischem Kleinzeug) > zentral. > Die kleinen Aktor/Sensorknoten können schließlich auch anders als via IP > miteinander bzw. mit ihrer Zentrale sprechen. Und diese Zentrale kaufst du fertig? Oder ist das ein PC mit XP?
P. M. schrieb: > Ein IoT-Gerät muss nur schon für den WLAN-Stack so > leistungsfähig sein, Muß es nicht. Gibt schließlich auch andere, vor allem energiesparendere Alternativen. Wenn Du freilich von einem IOT Gerät den unmittelbaren Netzzugang forderst wär schon etwas Strom und Leistung angesagt. Leider passt es dann nicht mehr in jede kleinste Ritze ;-) > Hast du eigentlich überhaupt mal ein grösseres Projekt gemacht > ausserhalb von Assembler und 8-Bittern? Mit Asm und 8-Bittern kann man durchaus auch große Projekte machen, bis hin zu 10K kann ich die Möglichkeit aus eigener Erfahrung bestätigen. Wenn sie dann funktionell im Vergleich zum C-Projekt aber meist immer noch MickyMaus- ausfallen ist das ein Qualitätsmerkmal von Asm. Gu. F. schrieb: > Und selbst die waren mit Fehlern gespickt. Erzähl doch keinen Schwachsinn. Konzentrier Dich besser auf die Minus-Bewertungen, damit bist Du ausgelastet ;-)
Klaus W. schrieb: > Und diese Zentrale kaufst du fertig? Oder ist das ein PC mit XP? Ach Gottchen. Stell Dir vor das ist ein Xmega. Könnte aber durchaus auch was kleineres sein, wenn es denn genügend UARTs mitbringen würde. Man muß durchaus nicht jede I-Net Anbindung mit Raspberry oder gar PC erledigen ;-)
Moby A. schrieb: > Du freilich von einem IOT Gerät den unmittelbaren Netzzugang forderst Sonst ist es kein IoT-Gerät. Der Netzzugang (ob nun LAN oder WLAN) ist eine der Kernfunktionen davon. Ohne Netz kein IoT.
Jonny O. schrieb: > die X-Ports sind schon ganz nett, aber relativ teuer. Na ja Jonny nicht ganz so teuer wie Du angibst aber der war auch schon das Teuerste überhaupt. Wir reden aber hier nur von der zentralen Internet-Anbindung und nicht von den vielen Zuträgern, die ich beim Thema Asm auf IOT Devices im Sinn hatte. Du hast sicher Recht, die Zentrale kann man auf viele Weisen (und billiger) realisieren- mir war hier aber die einfachere Zukauf-Lösung lieber. Natürlich kommt in der "Zentrale" nun genauso Asm zur Anwendung so wie überall. Ein Xmega hat dann sowas von Reserven...
Rufus Τ. F. schrieb: > Sonst ist es kein IoT-Gerät. Der Netzzugang (ob nun LAN oder WLAN) ist > eine der Kernfunktionen davon. Ohne Netz kein IoT. Du beißt Dich für meinen Geschmack an Definitionsfragen fest. SmartHome-Devices können via zentralem Interface trotzdem Kontakt zum Netz finden und ich denke, dies ist in den meisten Fällen auch die sinnvollste Lösung.
Moby A. schrieb: > Du beißt Dich für meinen Geschmack an Definitionsfragen fest. Nein. Du beißt Dich auf die nur von Dir wahrgenommene Anwendbarkeit von Assembler fest, und blendest jede weitergehende Anforderung aus, sobald sie nur etwas Realitätsnähe erhält.
Rufus Τ. F. schrieb: > Du beißt Dich auf die nur von Dir wahrgenommene Anwendbarkeit von > Assembler fest, und blendest jede weitergehende Anforderung aus, sobald > sie nur etwas Realitätsnähe erhält. Also: Die Anwendbarkeit von Asm nehme ich nicht nur wahr, die ist schlicht gegeben. Sonst säße ich ganz schnell im Dunklen und Kalten. Ich blende auch nichts aus sondern habe die Anforderungen (m)eines SmartHome fest im Blick. Das bleibt nicht aus wenn man so ein Hobby über viele Jahre pflegt. Die Realität würde mich ganz schnell eines besseren belehren wenn sie ignoriert würde. Gib einfach zu, es führen viele Wege nach Rom- und der Assemblerweg mag zwar länger als manch anderer sein, führt aber zu überaus effizienten Ergebnissen. Ob Du da was ausblendest ???
Moby A. schrieb: > Erzähl doch keinen Schwachsinn. Yalu hat die paar Zeilen doch analysiert. >Moby, deine Prüfsumm ist nicht viel wert, da in ihre Berechnung nur 6 >der 14 Datenbits eingehen. Damit werden nicht einmal die Hälfte aller >Einzelbitfehler erkannt. Das du dich später rausredest nützt da auch nix mehr >Daß es nur eine rudimentäre Prüfsumme mit begrenztem Wert ist OK. Alles nachzulesen im Micky Maus Thread Beitrag "Kleines Tiny13 Sensorboard"
Gu. F. schrieb: > Das du dich später rausredest nützt da auch nix mehr Den einen nennst Du "mit Fehlern gespickt"? Aber wie willst Du das auch beurteilen können. Vermutlich hast Du selber noch keine gemacht- und zwar generell mangels Programmierkenntnissen ;-( Aber danke daß Du den Thread nochmals erwähnst. Ein Projekt ehrt den Schöpfer einer funktionierenden Lösung. Der Kontrast zu gelangweilten Trollen könnte dann nicht größer sein ;-)
:
Bearbeitet durch User
Nun assembler für die AVRs hab ich mir vor ewigen Zeiten angeeignet. Jedenfalls genug um die Listfiles vom GCC lesen zu können. Mehr asm hab ich bisher nicht gebraucht, wozu auch?
> nicht ganz so teuer wie Du angibst
Hi, Hätte interesse an einer günstigen Bezugsquelle. Bei Mouser kosten
die Dinger so um die 70Eur. Hättest Du ev. nen Link?
Edit: Sehe grade das es eine Pro und eine normale Version gibt. Die
einfache kostet so um die 50eur bei Mouser.
Thx
Jonny
:
Bearbeitet durch User
Jonny O. schrieb: > Hättest Du ev. nen Link Ist schon ne Weile her daß ich den gekauft habe, ich kenne auch nicht die Preisentwicklung der letzten Monate... Bei Rs-Online gibts den Pro aktuell für ca. 60€, kann aber gut sein daß sich das noch untertreffen lässt. > Edit: Sehe grade das es eine Pro und eine normale Version gibt Nimm den Pro, der hat IPV6.
A. K. schrieb: > Das kannst du haben: > http://www.motor-talk.de/bilder/warum-benzinpreise-in-wirklichkeit-immer-noch-preiswert-sind-g45736413/stoerche-geburten-i204391169.html Aktuell ist das aber nicht, es besteht also durchaus Bedarf für Leistungen von Tiobe...
Carl D. schrieb: > Moby schreibt grad dran. IPv6 macht noch Probleme, die Register > gehen aus. Dann muss er sie eben wieder anzünden...
Fassen wir diesen Thread mal zusammen. Moby programmiert einen ATTiny13 in Assembler, um höchstens ein paar Bytes in diesem zu verbrauchen und nur wenige Cents dafür auszugeben. Dann klebt er da einen X-Port dran, der das hundertfache eines ATTiny13 kostet und nennt das dann ein "sparsames" IoT - natürlich komplett in Assembler geschrieben. Das ist dasselbe wie: Ich kaufe mir einen Porsche, klebe mir vorne auf dem Amaturenbrett ein Matchbox-Auto drauf und nenne das dann eine "sparsame" Lösung, die 280 km/h fahren kann! Und das alles mit einer Spritzgussmaschine gebaut! Klasse.
Carl D. schrieb: > Dieses Jahr habe ich ca. 100% mehr Störche beobachtet als letztes Jahr. Herzlichen Glückwunsch zu Deiner Schwangerschaft!
Frank M. schrieb: > Fassen wir diesen Thread mal zusammen. > > Moby programmiert einen ATTiny13 in Assembler, um höchstens ein > paar Bytes in diesem zu verbrauchen und nur wenige Cents dafür > auszugeben. Dann klebt er da einen X-Port dran, der das hundertfache > eines ATTiny13 kostet und nennt das dann ein "sparsames" IoT - > natürlich komplett in Assembler geschrieben. Fassen wir mal zusammen: Moby programmiert viele Tinys, Megas und einige Xmegas für sein SmartHome. Größere Chips braucht es jeweils nicht, denn sie sind mit sparsamem Ressourcenverbrauch in einfachem Asm programmiert. Wenige KB, ganz wenige MHz, sehr smart(Home) das Ganze... Der Netz-Zugang ist freulich nicht so leicht zu bekommen, dafür kauft er einen kleinen XPort- und hat fertig ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Moby programmiert viele Tinys, Megas und einige Xmegas für sein > SmartHome. Jeeeetzt verstehe ich den Aufschwung von Assembler! Du sitzt schon über Wochen an diversen Schuchmaschinen und gibst 'assembler programming' ein :-)
Moby A. schrieb: > Der Netz-Zugang ist freulich nicht so leicht zu bekommen, dafür kauft er > einen kleinen XPort- und hat fertig ;-) Der Netz-Zugang ist viel einfacher und billiger zu bekommen. Da reicht ein WIZ5100- oder WIZ5200-Modul aus - ansteuerbar über SPI. Für den Preis eines X-PORTs bekommst Du 3-4 Stück davon http://www.watterott.com/de/WIZnet-WIZ812MJ-Ethernet-Modul http://www.watterott.com/de/WIZ820io (Die ESP8266 mit einem Stückpreis von 4-5 EUR will ich erst gar nicht empfehlen, deren AT-Schnittstelle ist einfach unterirdisch. Bleibt Direkt-Programmierung - aber dafür müsste Moby einen neuen Assembler-Dialekt lernen, während ein C-Programmierer direkt loslegen kann) Aber wenn SPI schon einen ATiny-Assembler-Programmierer überfordert, dann bleib bei Deinen X-Ports.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Aber wenn SPI schon einen ATiny-Assembler-Programmierer überfordert Wird nicht das Problem sein. Er hat halt so viel für seinen XPort ausgeben müssen, dass es beim Rest nur noch für popelige ATtiny13 gereicht hat, die sich noch nichtmal eine USI leisten können. Da er alle anderen, denen die Lebenszeit zu schade ist, sich mit so einer Simpelst-Hardware herumzuschlagen, einfach als „Ressourcenverschwender“ bezichtigen kann, ist zumindest sein Weltbild wieder stimmig, denn bei den anderen liegt es natürlich nur daran, dass sie alle unfähig sind, in klarem und reinem Assembler zu programmieren. Wenn nun TIOBEs astrologische Weissagungen sein Weltbild noch bekräftigen (obwohl er ja sonst nur all die vielen Falschfahrer ihm entgegenkommen sieht), dann muss doch einfach was dran sein, nicht?
Jörg W. schrieb: > Wenn nun TIOBEs astrologische Weissagungen sein Weltbild noch > bekräftigen (obwohl er ja sonst nur all die vielen Falschfahrer ihm > entgegenkommen sieht), dann muss doch einfach was dran sein, nicht? Du hast mich überzeugt. Lasst uns eine neue Sekte gründen! :-)
Frank M. schrieb: > Du hast mich überzeugt. Lasst uns eine neue Sekte gründen! :-) Aber bitte zur Abwechslung mal eine atheistische, dann bin ich auch dabei - die anderen nerven immer mehr.
Klaus W. schrieb: > Aber bitte zur Abwechslung mal eine atheistische, Wie denn, wo ihr doch den Versammlung-Gott anbeten sollt?
Peter D. schrieb: > Shit happens: Klar, und die, die die Soße dann ausbaden müssen, gugeln nun die ganze Zeit nach „Assembler“, und schon ist die TIOBE-Wahrnehmung verschoben. :)
Peter D. schrieb: > Assembler ist ne tickende Zeitbombe. Yeah! Was machen wir dann bloß, wenn Moby sich morgen entscheidet, nur noch Pflanzen in Kolumbien anzubauen?
:
Bearbeitet durch Moderator
Frank M. schrieb: > Peter D. schrieb: >> Assembler ist ne tickende Zeitbombe. > > Yeah! > > Was machen wir dann bloß, wenn Moby sich morgen entscheidet, nur noch > Pflanzen in Kolumbien anzubauen? Wenn er den Pflanzenanbau in Kolumbien handwerklich genauso angeht wie das Programmieren, dann wird die Birne aus Ermangelung stimulierender Zutaten bald wieder klar...
Uhu U. schrieb: > Ein Index > über die Wirkung der Störche die menschliche Geburtenrate wäre > sicherlich sehr erhellen. Der Zusammenhang ist doch eindeutig. In den letzten 25 Jahren wurde so viel für die Storchpopulation getan und die Weltbevölkerung ist gleich mal um fast 50% gestiegen. Gegenmaßnahme: Da brat mir doch einer 'nen Storch.
Vlad T. schrieb: > Da brat mir doch einer 'nen Storch. Da "vegan" aber auch in Mode ist, muss der aus Tofu oder Saitan sein.
Rufus Τ. F. schrieb: > Da "vegan" aber auch in Mode ist, muss der aus Tofu oder Saitan sein. Da haben wir den Salat: Aufgrund der Weigerung der Ökos einen ordentlichen Storchenschmaus wertzuschätzen, steigt die Bevölkerung der Welt ins unermessliche. Hier wird bewusst die natürliche Ordnung der Selbstregulierung (viele Störche -> viele Menschen -> mehr gegessene Störche -> weniger Menschen -> ...) ignoriert und die Erde an den Rand des Kollapses gebracht. (die Theorie werde ich mal bei Atilla Hildemann auf der Facebook-Seite posten ^^)
:
Bearbeitet durch User
Irgendwie so still. .. Habt ihr denn Moby jetzt vergrault odef geheilt?
Tja, mit Galgenhumor ist den vielen Vorteilen von Asm nun auch nicht gerade beizukommen... Aber was bleibt manchem Schreiber hier auch übrig? Für mehr reichts eben nicht mehr ;-)
Moby - der Kurt Bindl der Programmierer... Inline Assembler nehme ich immer gerne, wenn ich zeitkritische Komponenten in meiner C-Programmierung habe..
Peter D. schrieb: > Shit happens: > > Beitrag "Re: AVR ASM soll AVR GCC aufrufen" > > Assembler ist ne tickende Zeitbombe. Ohne AVR GCC wär das alles nicht passiert...
Gu. F. schrieb: > Irgendwie so still. .. Das war die gefrässige Stille bei der Vertilgung des veganen Storches.
Wolfgang R. schrieb: > Inline Assembler nehme ich immer gerne, wenn ich zeitkritische > Komponenten in meiner C-Programmierung habe.. Schau an. Bringt also Vorteile. Und ich nehm gleich 100% Asm, das bringt am meisten ;-)
Also ich genieße die memory allocation und variable features der Hochsprachen... Assembler benutze ich nur, wenn's nötig ist. Alles andere ist mir zu Fehleranfällig. Ich meine, ich nehme ja auch keinen Hammer, wenn ich eine Schraube reindrehen will. Das richtige Werkzeug zum richtigen Einsatzfall. Da ist mir Assembler genau so lieb wie C... Alles andere sieht mir nach Verbohrtheit aus...
A. K. schrieb: > Das war die gefrässige Stille bei der Vertilgung des veganen Storches. Liegt der Tofu zu schwer im Magen? ;-)
Jörg W. schrieb: >> Das war die gefrässige Stille bei der Vertilgung des veganen Storches. > > Liegt der Tofu zu schwer im Magen? ;-) Nee, in den Knien. Von dem kriegt man Gicht.
Moby A. schrieb: > Muß es nicht. Gibt schließlich auch andere, vor allem energiesparendere > Alternativen. Wenn Du freilich von einem IOT Gerät den unmittelbaren > Netzzugang forderst wär schon etwas Strom und Leistung angesagt. Dass jedes Gerät unmittelbaren Netzzugang hat ist so ziemlich die Definition von IoT. Ausser in Mobys Welt natürlich. Moby A. schrieb: > Die Anwendbarkeit von Asm nehme ich nicht nur wahr, die ist schlicht > gegeben. Sonst säße ich ganz schnell im Dunklen und Kalten. > Ich blende auch nichts aus sondern habe die Anforderungen (m)eines > SmartHome fest im Blick. Das bleibt nicht aus wenn man so ein Hobby über > viele Jahre pflegt. Die Realität würde mich ganz schnell eines besseren > belehren wenn sie ignoriert würde. Ich muss längers je mehr schmunzeln: Du kriegst für jeden deiner Beiträge 5 Downvotes, aber redest immer noch mit einer Selbstsicherheit daher, als wärst du hier der Guru...
P. M. schrieb: > Ich muss längers je mehr schmunzeln: Du kriegst für jeden deiner > Beiträge 5 Downvotes, aber redest immer noch mit einer Selbstsicherheit > daher, als wärst du hier der Guru... In seiner 8-Bit Welt hat er es wahrscheinlich mit Vorzeichen nicht so und sieht das deshalb als 251 Up-Votes.
Wolfgang R. schrieb: > Also ich genieße die memory allocation und variable features der > Alles > andere ist mir zu Fehleranfällig. Ich genieße die absoluten Freiheiten bei der Ressourcen(nicht)verwendung. Auch wenn zuweilen dieser oder jener Flüchtigkeitsfehler nicht zu vermeiden ist- es ist alles eine Sache der Übung. Fehleranfälligkeit kann schließlich durch erprobte, vorgefertigte Bausteine genauso eingeschränkt werden wie bei allen anderen Sprachen. > Ich meine, ich nehme ja auch keinen Hammer, wenn ich eine Schraube > reindrehen will. Das richtige Werkzeug zum richtigen Einsatzfall. Da ist > mir Assembler genau so lieb wie C... Das richtige Werkzeug ist für mich: Asm. Weil, es passt fast immer und liefert die besten Ergebnisse. Allenfalls wenn große Berechnungen anstünden oder größere Datenmassen zu handeln wären könnte ich mir etwas "höheres" vorstellen- im normalen Smarthome MSR Alltag ist das eher sehr selten. > Alles andere sieht mir nach Verbohrtheit aus... Man kann Einsicht in die Vorteile und die konsequente Nutzung von Asm auch voreilig mit Verbohrtheit verwechseln ;-)
Alter Assembler, hast Du eine religiöse Erleuchtung gehabt? Das Licht gesehen? Die Band gegründet? Deine Aussagen über die heilige Allmächtigkeit des Assembler machen mir Angst...
Wolfgang R. schrieb: > Deine Aussagen über die heilige Allmächtigkeit des Assembler machen mir > Angst... Keine Angst: ein Selbstmordattentat kann sich Moby für seine Religion nicht leisten. Schließlich wäre danach die Gesamtheit aller daran Gläubigen vernichtet. ;-)
> Ich muss längers je mehr schmunzeln: Du kriegst für jeden deiner > Beiträge 5 Downvotes, aber redest immer noch mit einer Selbstsicherheit > daher, als wärst du hier der Guru... Sicherheit kommt bei jedem Bastler allein von Erfahrung und letztlich von funktionierenden, sehr smarten Devices. Kreiert nur aus Chips und Grips ;-) Warum sollte man diese Downvotes ernst nehmen? Ich weiß ja warum (und z.T. von wem). Und ich habe die Sicherheit...
Jörg W. schrieb: > Keine Angst: ein Selbstmordattentat kann sich Moby für seine Religion > nicht leisten. Schließlich wäre danach die Gesamtheit aller daran > Gläubigen vernichtet. ;-) Junge Junge was traust Du mir da zu... Es geht doch nuuur um Assembler! Aber wie das manch einen hier in Rage bringt- interessant.
Wolfgang R. schrieb: > Deine Aussagen über die heilige Allmächtigkeit des Assembler. Na ja, das 'heilig' kannst Du streichen. Alles andere stimmt!
Jörg W. schrieb: > Schließlich wäre danach die Gesamtheit aller daran > Gläubigen vernichtet. ;-) Das wär ja nicht das Problem. Aber dann... (Offenbarung 16,17ff): "Und der siebente Engel goß aus seine Schale in die Luft; und es ging aus eine Stimme vom Himmel aus dem Stuhl, die sprach: Es ist geschehen. Und es wurden Stimmen und Donner und Blitze; und ward ein solches Erdbeben, wie solches nicht gewesen ist, seit Menschen auf Erden gewesen sind, solch Erdbeben also groß. Und aus der großen Stadt wurden drei Teile, und die Städte der Heiden fielen. Und Babylon, der großen, ward gedacht vor Gott, ihr zu geben den Kelch des Weins von seinem grimmigen Zorn. Und alle Inseln entflohen, und keine Berge wurden gefunden. Und ein großer Hagel, wie ein Zentner, fiel vom Himmel auf die Menschen; und die Menschen lästerten Gott über die Plage des Hagels, denn seine Plage war sehr groß."
Moby A. schrieb: > Allenfalls wenn große Berechnungen > anstünden oder größere Datenmassen zu handeln wären könnte ich mir etwas > "höheres" vorstellen- im normalen Smarthome MSR Alltag ist das eher sehr > selten. Dann stell ich dir mal eine einfache Aufgabe aus diesem Bereich. Du hast z.B. einen Temperatur-/Luftfeuchtigkeitssensor an deinem AVR. DHT22 z.B. Zum Auslesen braucht man nur einen Pin und das traue ich dir mal in ASM zu. Mit einem 2. Pin soll jetzt mal ein Relais geschaltet werden, wenn die Temeratur unter den Taupunkt fällt. Jetzt wäre ich mal gespannt wie du diese Aufgabe in purem ASM löst...
Jürgen L. schrieb: > Jetzt wäre ich mal gespannt wie > du diese Aufgabe in purem ASM löst... Da hast Du Pech. Auftragsarbeiten übernehme ich hier nicht, bin auch so genug beschäftigt. Leider bleibt fürs Hobby zu wenig Zeit ;-( Du kannst aber um mich zu überzeugen gern mal schnell eine C-Lösung meines erwähnten Asm-Projekts erstellen, die weniger Ressourcen benötigt ;-) A. K. schrieb: > Jörg W. schrieb: > Schließlich wäre danach die Gesamtheit aller daran > Gläubigen vernichtet. ;-) > > Das wär ja nicht das Problem. Aber dann... (Offenbarung 16,17ff): "Und > der siebente Engel goß aus seine Schale in die Luft; und es ging aus > eine Stimme vom Himmel aus dem Stuhl... Heiliger Bimbam! Wie kann man aus der kleinen (Asm-) Mücke bloß so einen (C-) Elefanten machen ;-)
Moby A. schrieb: > Wolfgang R. schrieb: >> Inline Assembler nehme ich immer gerne, wenn ich zeitkritische >> Komponenten in meiner C-Programmierung habe.. > > Schau an. Bringt also Vorteile. > Und ich nehm gleich 100% Asm, das bringt am meisten ;-) Ich tu an mein Schnitzel gerne ein Prise Salz, damit es besser schmeckt. Weil das Salz am Schnitzel Vorteile bringt, vertilgt Moby gleich eine ganze Packung davon und lässt dafür das Schnitzel weg ;-)
Yalu X. schrieb: > Ich tu an mein Schnitzel gerne ein Prise Salz, damit es besser schmeckt. > > Weil das Salz am Schnitzel Vorteile bringt, vertilgt Moby gleich eine > ganze Packung davon und lässt dafür das Schnitzel weg ;-) Die Verwendung von Asm in C-Programmen ist doch letztlich eine Kapitulationserklärung von C... Ohne Asm gehts dann sogar im heiligen C-Universum nicht. Im Ergebnis haben wir dann eine unnötig komplexe Lösung, von deren Schwierigkeiten Peter D. weiter oben schon ein Lied singen konnte.
Moby A. schrieb: > Ohne Asm gehts dann sogar im heiligen > C-Universum nicht. Logisch: schließlich generiert der C-Compiler selbst Assemblercode.
Die Verwendung eines Schraubendrehers ist eine Kapitulationserklärung vor dem Hammer?
Jörg W. schrieb: > Moby A. schrieb: > >> Ohne Asm gehts dann sogar im heiligen >> C-Universum nicht. > > Logisch: schließlich generiert der C-Compiler selbst Assemblercode. ... und der Assembler (zumindest der von GNU) ist in C geschrieben. Ist es nicht schön, wie sich die Dinge gegenseitig ergänzen :)
Jörg W. schrieb: > Logisch: schließlich generiert der C-Compiler selbst Assemblercode. War aber natürlich nicht gemeint ;-) Wolfgang R. schrieb: > Die Verwendung eines Schraubendrehers ist eine > Kapitulationserklärung vor dem Hammer? Der Hammer hat seine Berechtigung wie der Schraubenzieher auch. Problematisch wirds, wenn das eine Werkzeug vorgibt, die Arbeit des anderen effizienter tun zu können. 'Arbeit' steht dabei für das Zielgebiet: Asm für einfache MSR, Hochsprache für große, rechen- und datenintensive Anwendungen. Yalu X. schrieb: > ... und der Assembler (zumindest der von GNU) ist in C geschrieben. Das darf er. Was zum Glück nicht die Möglichkeiten schmälert, die man beim Asm-Programmieren später hat. > Ist es nicht schön, wie sich die Dinge gegenseitig ergänzen :) Das ist solange schön wie es die Dinge einfacher macht.
Moby A. schrieb: >> Logisch: schließlich generiert der C-Compiler selbst Assemblercode. > > War aber natürlich nicht gemeint ;-) Ist mir schon klar, aber du überschätzt die Bedeutung maßlos, die Assemblercode heutzutage noch als Ergänzung für einen Compiler hat. Ich habe zwar vor Jahren selbst ein Stück in der avr-libc-Doku der Integration von Assemblercode zusammen mit C-Code gewidmet, aber schon damals war das Fazit (schon fast zu meinem Erstaunen): der Ersatz des für das Beispiel angenommenen ATtiny13 durch einen ATtiny25 hätte all diese Verrenkungen völlig überflüssig gemacht – nicht dank des größeren Speicherplatzes, sondern dank der besseren Features der enthaltenen Timer, wodurch man für die beschriebene Aufgabe (die übrigens aus einer praktischen Anfrage in einem Forum resultierte) keine taktzyklengenaue ISR mehr benötigt hat. Mittlerweile haben wir mehr als ein Jahrzehnt danach, und beim Entwurf des Cortex-M war es erklärtes Ziel, dass selbst für die Laufzeitumgebung des Controllers kein Assemblercode mehr erforderlich ist: man kann von A - Z dort alles in C machen. Bevor du jetzt wieder „Verschwendung“ rufst: der kleinste Cortex-M dürfte kaum mehr Chipfläche haben (und kaum mehr kosten) als dein ATtiny13A (vom nicht-A-Typ ganz zu schweigen). Nur, um dir die Relationen aufzuzeigen:
1 | $ cd /usr/src |
2 | $ find . -name '*.[ch]' | wc -l |
3 | 28504 |
4 | $ find . -name '*.S' | wc -l |
5 | 626 |
Das ist immerhin ein Betriebssystem, also Kernel für mehrere CPU-Architekturen, Bootloader, etc. pp. sowie die zur Basis des Systems gezählten Bibliotheken (einschließlich Systembibliothek) und Grundanwendungen (FreeBSD 10.x). Gerade mal 2 % der Sourcecode-Dateien sind Assemblercode. Bei reinen Anwendungsprogrammen dürfte der Anteil nochmal sehr viel kleiner sein, denn je weiter man von der Hardware weg geht, um so weniger sind Dinge wie taktzyklengenaues Arbeiten oder direktes Herumfummeln an CPU-Registern von Belang.
:
Bearbeitet durch Moderator
Moby, technisch sind deine Aussagen ja gemäss breitem Konsens völliger Dünnpfiff. Aber Unterhaltungswert, wie man sieht, hast du. Ist schon ein Phänomen, dass jeder Moby-Assembler-Thread über dutzende von Beiträgen geht, obwohl völlig klar ist, dass Moby's Behauptungen null Substanz haben.
P. M. schrieb: > Ist schon ein > Phänomen, dass jeder Moby-Assembler-Thread über dutzende von Beiträgen > geht, obwohl völlig klar ist, dass Moby's Behauptungen null Substanz > haben. Schon lustig, wieviele da immer anspringen. Aber wenn er aus seiner Höhle partout nicht raus will... http://www.thur.de/philo/philo5.htm
P. M. schrieb: > obwohl völlig klar ist, dass Moby's Behauptungen null > Substanz haben. Schön, wenn Du das behauptest... Deine Begründung hat jedenfalls Null Substanz, es gibt nämlich schlicht keine. Ein > Phänomen ist meist etwas Unverstandenes ;-) Jörg W. schrieb: > du überschätzt die Bedeutung maßlos, die > Assemblercode heutzutage noch als Ergänzung für einen Compiler hat. Im Prinzip wollte ich das gar nicht einschätzen. Assemblercode steht für sich, gewinnt gemäß obiger Statistik an Bedeutung und ich als AVR/Asm Bastler kann das für MSR + IOT Anwendungen sehr gut nachvollziehen. > beim Entwurf > des Cortex-M war es erklärtes Ziel, dass selbst für die Laufzeitumgebung > des Controllers kein Assemblercode mehr erforderlich ist: man kann von A > - Z dort alles in C machen. Ein ARM ist ob seiner Komplexität für Asm ungeeignet und steht sowieso für rechen- und datenintensive Anwendungen. Nicht mein Zielgebiet!
:
Bearbeitet durch User
Wolfgang R. schrieb: > Ich meine, ich nehme ja auch keinen Hammer, wenn ich eine Schraube > reindrehen will. Das richtige Werkzeug zum richtigen Einsatzfall. Da ist > mir Assembler genau so lieb wie C... > > Alles andere sieht mir nach Verbohrtheit aus... Verbohrt ist doch besser, als behämmert, oder nicht?
Icke ®. schrieb: > Aber wenn er aus seiner > Höhle partout nicht raus will... Deren Adresse lautet: "Dort, wo Projekte mit möglichst geringem Aufwand möglichst einfach realisiert werden."
Moby A. schrieb: > "Dort, wo Projekte mit möglichst geringem Aufwand möglichst einfach > realisiert werden." Du hast da was vergessen: "Dort, wo triviale Projekte ...".
Rufus Τ. F. schrieb: > "Dort, wo triviale Projekte ..." Manches ist jedenfalls trivialer als man denkt ;-) Zu einem komplexeren Projekt gehören auch nicht unbedingt große Berechnungen und Datenmengen.
:
Bearbeitet durch User
Uhu U. schrieb: > Verbohrt ist doch besser, als behämmert, oder nicht? Behämmert riskiert den Daumen, verbohrt das Leben.
Ich hab genau so ein "IoT" System wie der Moby AVR also dezentrale module die per rs485 mit einer "Zentrale" kommunzieren.. mit der Zentral kann man per IPv4 kommunizieren.. * ICH wrüde das aber nich IoT nennen... Solche dezentralen Sensoren die per 2-Draht (CAN, rs485, KNX/TP..) mit einer Zentrale kommunizieren gibt es jetz seit wann? 50 Jahren? nur weil man dazu jetzt IoT sagt, würde das den (angelichen) Hype um ASM also sicher nicht erklären... (und auch nur wenn man sie mit ASM Programmieren würde, was aber eh keiner Macht.., nur Moby AVR glaubt das,...) * falls es wem interssiert: Konkret besteht ein Teil meines SmartHome aus OpenHC Module (http://sourceforge.net/p/openhc/wiki/Home/) vom Jörg Hohensohn, Code ist OpenSource und kann man dort downloaden... IMHO ist da sogar eine Harware-Abstraktoin drinnen, sodass andere µC möglich sind..
Robert L. schrieb: > Solche dezentralen Sensoren die per 2-Draht (CAN, rs485, KNX/TP..) mit > einer Zentrale kommunizieren gibt es jetz seit wann? 50 Jahren? > nur weil man dazu jetzt IoT sagt, würde das den (angelichen) Hype um ASM > also sicher nicht erklären... Naja Hype, das Wort wär jetzt selbst mir zu groß. Es dürfte auch egal sein wer hier nun was IOT nennt. Fakt ist, gemeint sind u.a. vernetzte Sensor- und Aktorknoten, wie man sie auch aus dem SmartHome kennt. Die haben i.d.R. eine einfache Hardware, weil sie nicht viel zu dirigieren, zu messen, zu verarbeiten und weiterzuleiten haben. Es langen sehr oft 8-Bitter, die vorzugsweise und im einfachsten Fall in Asm programmiert werden können.
Moby A. schrieb: > Deren Adresse lautet: "Dort, wo Projekte mit möglichst geringem Aufwand > möglichst einfach realisiert werden." Moby, hast du eigentlich ein einzelnes Beispiel, wo du mit Assembler tatsächlich besser Gefahren bist, als mit C? Und ich meine damit nicht, eine gefühlt supereffiziente Routine implementiert zu haben, sondern tatsächlich mehr aus einem Controller rausgeholt zu haben, als man mit C könnte.
Moby A. schrieb: > Fakt ist, gemeint sind Das ist nicht "Fakt", sondern das ist Deine spezifische Sichtweise. Annähernd alle anderen haben andere Vorstellungen davon, was IoT ist.
Moby A. schrieb: > Fakt ist, gemeint sind u.a. vernetzte Sensor- und Aktorknoten, wie man > sie auch aus dem SmartHome kennt. Moby A. schrieb: > Es langen sehr oft 8-Bitter, die vorzugsweise > und im einfachsten Fall in Asm programmiert werden können. "Im einfachsten Fall" kann man das. Aber sicher nicht "vorzugsweise". Und sobald man "vorzugsweise" Assembler verwendet, ist es sicher kein "einfacher Fall" mehr, sondern dann, wenn der Controller bis unter die Decke voll und ausgelastet ist. Dann sollte man sich aber generell fragen, warum man sich solche Krämpfe antut um 50 Cent für einen grösseren Controller zu sparen...
P. M. schrieb: > Moby, hast du eigentlich ein einzelnes Beispiel, wo du mit Assembler > tatsächlich besser Gefahren bist, als mit C? Und ich meine damit nicht, > eine gefühlt supereffiziente Routine implementiert zu haben, sondern > tatsächlich mehr aus einem Controller rausgeholt zu haben, als man mit C > könnte. Das zitierte Programmbeispiel steht nicht umsonst in der Projektesammlung... Lass da noch ein paar funktionelle Anforderungen hinzukommen und schwupps schauts mit C mangels Platz schlecht aus und ein größerer Controller wird fällig. Denn Peter D. schrieb: > Im Schnitt sind daher C-Programme etwa 10..50% größer Das andere ist dann natürlich die erzielbare Performance. So kann sich der Asm-Programmierer bei geschickter Nutzung seiner Möglichkeiten bei gegebener Taktfrequenz z.B. mehr und längere Interrupts leisten. Natürlich lässt sich alles nach wie vor auch ineffizienter in C lösen. Einfach Controller eine Nummer größer nehmen! Die Taktfrequenz erhöhen! Einfach auf ARM und 32 Bit umsteigen! Wohin die Mentalität führt sieht man bei PC-Software. Springender Punkt aber werden in der Industrie die Kosten sein. Wenn Asm dort an Bedeutung gewinnt wird das damit schon in irgendeiner positiven Beziehung stehen.
Moby A. schrieb: > Es dürfte auch egal sein wer hier nun was IOT nennt. IoT = Illuminates of Thanateros
Rufus Τ. F. schrieb: > Das ist nicht "Fakt", sondern das ist Deine spezifische Sichtweise. > Annähernd alle anderen haben andere Vorstellungen davon, was IoT ist. Tatsächlich? Das ist allgemeiner Konsens? In einer Welt die diesbezüglich noch ganz am Anfang steht? Sehr mutig! Mit "meiner spezifischen Sichtweise" lassen sich alle Anforderungen an ein IOT Gerät genauso lösen, vor allem aber schon heute. P. M. schrieb: > 50 Cent für einen > grösseren Controller ... können bei entsprechenden Stückzahlen sehr schmerzhaft ins Gewicht fallen. Wenn dann nur durchschnittliche C++ Entwickler am Projekt sitzen umso mehr, wenn es viel einfacher in Asm gelöst sein könnte.
Moby A. schrieb: > Mit "meiner spezifischen Sichtweise" lassen sich alle Anforderungen an > ein IOT Gerät genauso lösen, vor allem aber schon heute. Mit Deiner spezifischen Sichtweise ist praktisch alles IoT, was irgendwie einen µC enthält. Damit ist IoT ein Blubberbegriff, der kaum mehr aussagt als "funktioniert mit Strom".
Rufus Τ. F. schrieb: > Mit Deiner spezifischen Sichtweise ist praktisch alles IoT, was > irgendwie einen µC enthält. Damit ist IoT ein Blubberbegriff, der kaum > mehr aussagt als "funktioniert mit Strom". Das ist doch Quatsch. IOT besagt, daß - ein Gerät Verbindung zum Internet hat - Daten aus dem Internet empfangen kann - Daten ins Internet senden kann (z.B. die berüchtigte Bestellung des Kühlschranks)
:
Bearbeitet durch User
Moby A. schrieb: > Lass da noch ein paar funktionelle Anforderungen > hinzukommen und schwupps schauts mit C mangels Platz schlecht aus und > ein größerer Controller wird fällig. Bei einer Stückzahl von 100 Millionen macht eine Verteuerung pro Stück von einem Cent eine Million Piepen aus - dafür kann man sich natürlich schon überlegen, ob eine handzisilierte ASM-Software günstiger kommt. Bei kleineren Stückzahlen müsste man schon einen Billigheimer von Programmierer finden, oder einen in Gefangenschaft mit Zwangsarbeit halten. Eventuell findet man ja in Saudi Arabien oder in Katar die passende Geschäftsform, um das durchzuziehen. Bei einer Auflage < 100.000 Stück braucht man neben den 70 Jungfrauen eine Zugabe von mindestens 50.000 Big Macs im Idiotenhimmel als mantalen Lockstoff, um einen passenden Dummen zu finden, wenn man nicht ganz kräftig drauflegen will...
Moby A. schrieb: > Ein ARM ist ob seiner Komplexität für Asm ungeeignet So ein kleiner Cortex-M0+ ist keineswegs komplexer als ein Xmega, und von denen behauptest du ja auch nicht, dass sie „für Asm ungeeignet“ sein.
Moby, du hast überhaupt nicht die genügende Kenntnis von der Sache, daß du hier mit den großen Jungs mitreden könntest. Von den Leuten, mit denen du hier versuchst zu debattieren, haben die meisten mit Assembler-Programmierung angefangen und jeder einzelne hat in seinem Programmiererleben mehr Codezeilen in Assembler geschrieben, als du jemals in deinem Leben schreiben wirst. Und weil das so ist, wissen diese Leute genau, wie haltlos deine ganze Argumentation ist. Was heißt schon Argumentation? Wenn man sich deine Beiträge durchliest, kommt man auf ungefähr fünf Phrasen, die du gegetsmühlenartig ständig wiederholst.
Mein grosses V. schrieb: > auf ungefähr fünf Phrasen, die du gegetsmühlenartig ständig wiederholst. Muß man auch. Wird zu vieles ignoriert oder einfach vergessen ;-) > daß du hier mit den großen Jungs mitreden könntest. Ich erstarre in Ehrfurcht. > jeder einzelne hat in seinem > Programmiererleben mehr Codezeilen in Assembler geschrieben, als du > jemals in deinem Leben schreiben wirst. Du bist ja gut informiert. Ich habe hier (leider) oft einen ganz anderen Eindruck ;-(
Moby A. schrieb: >> jeder einzelne hat in seinem Programmiererleben mehr Codezeilen in >> Assembler geschrieben, als du jemals in deinem Leben schreiben wirst. > > Du bist ja gut informiert. Hatten wir wohl schon hinreichend in anderen Threads diskutiert. > Ich habe hier (leider) oft einen ganz anderen Eindruck ;-( Im Gegensatz zu dir haben alle anderen irgendwann die Erkenntnis gehabt, dass das einfach nur unproduktiv ist, und dass man diese Variante der Programmierung daher für die (wenigen) Fälle aufhebt, bei denen es wirklich so sehr drauf ankommt, dass man gewillt ist, den Aufwand zu treiben. Es ist doch völlig in Ordnung, wenn du als Hobbyprogrammierer für dich zu der Auffassung gelangt bist, dass die Programmierung von AVRs in reinem Assembler genau das ist, was dir am meisten Spaß macht. Allerdings solltest du das nicht zur Religion erheben und so tun, als sei nur das die reine Lehre und alle ringsum nur zu blöd, das zu kapieren.
Jörg W. schrieb: > So ein kleiner Cortex-M0+ ist keineswegs komplexer als ein Xmega Warum tischt Du mir hier Märchen auf? Noch dazu in jener unredlichen Form, keine konkrete Implementierung zu nennen? Schau mal in den Projekten nach, wieviele Asm-Programme es dort für Xmega und wieviele für es für ARM einschließlich M0+ gibt... Du wirst doch nicht ernsthaft behaupten Asm wäre die Sprache der Wahl bei diesen 32-Bittern ;-( Umgekehrt wurde der Xmega von Atmel sicher für C optimiert. Das ändert aber nichts an seiner einfachen Asm-Programmierbarkeit für jeden Asmler, der aus den unteren AVR-Ligen kommt. Die Asm-Instruktionen sind weitgehend die gleichen, die Ansprache der Peripherie nicht grundverschieden. Jörg W. schrieb: > den Aufwand zu treiben ... ist bei den simplen AVRs kein sonderlich großer Mehraufwand wenn man es richtig macht. Dafür mit allen Freiheiten, simplen Programmiermitteln und einem überzeugenden Ergebnis. > Allerdings solltest du das nicht zur Religion erheben Da mach Dir keine Sorgen, ich bin nicht religiös. Das ändert freilich nichts an der Einfachheit und der überzeugenden Codequalität einer AVR/ASM Lösung für viele viele Einsatzfälle. > als sei nur das die reine Lehre Die reine Lehre sollte sein: Keep it simple. > und alle ringsum nur zu blöd, das > zu kapieren. Wer sich 'blöd' fühlt muß das mit sich ausmachen. Ich würde niemals so persönlich werden, auch wenn sich selbst 'Große Jungs' hier desöfteren unbeherrscht wie kleine Kinder aufführen denen das Spielzeug streitig gemacht wird ;-)
Moby A. schrieb: >> jeder einzelne hat in seinem Programmiererleben mehr Codezeilen in >> Assembler geschrieben, als du jemals in deinem Leben schreiben wirst. > > Du bist ja gut informiert. Bübchen, das umfangreichste Assembler-Programm, das ich je erweitern durfte, hat mir das Rechenzentrum als ASM-Liste auf Einzelblatt ausgedruckt. Das wurde dann in zwei dieser üblichen DruckerPapierkartons angeliefert. Beide randvoll. Da sind üblicherweise 5 Pakete a 500 Blatt drin. Falls das einen Überlauf deiner 8-Bit-ALU gibt: 5 Tausend Seite. Und die CPU, die das ausführte, darf dir nicht auf Fuß fallen, sonst ist der nicht nur ab, sondern der ganze Kerl ist Brei. Passiert ist das 9 Flugstunden Richtung Süden. Erzählt mir also mehr über den ATtiny13, da kann ich sicher noch was lernen! Diese Maschine hat im übrigen vieles gemeinsam mit ARM. Man kann die locker in ASM Programmieren, wenn man's kann und wenn man gerade seinen Compiler verlegt hat. Der macht das nämlich genau so gut!
:
Bearbeitet durch User
Moby A. schrieb: > Jörg W. schrieb: >> So ein kleiner Cortex-M0+ ist keineswegs komplexer als ein Xmega > > Warum tischt Du mir hier Märchen auf? Jetzt wirst du einfach nur noch unverschämt. > Noch dazu in jener unredlichen > Form, keine konkrete Implementierung zu nennen? Wenn dir das hilft, dann guck' dir einen SAMD20 von Atmel an, und vergleiche ihn mit einem XmegaA. Der SAMD20 ist da von der Peripherie her eher noch überschaubarer als der XmegaA. Dass man sich mit der Grundinitialisierung des Taktsystems rumschlagen muss, ist beim Xmega auch schon der Fall (OK, wenn man nicht gerade mit dem Standard-Takt nach Reset arbeiten will, aber das geht natürlich bei beiden). Das Einzige, was beim Cortex grundlegend anders ist als bei AVR (einschließlich Xmega): nach Reset werden nur die wichtigsten Peripheriebausteine mit Takt versorgt, alle anderen schlafen. Beim AVR muss man den Takt für die Baugruppen, die man nicht braucht, explizit abschalten, wenn man Energie sparen will. > Schau mal in den > Projekten nach, wieviele Asm-Programme es dort für Xmega und wieviele > für es für ARM einschließlich M0+ gibt... Welche Relevanz sollte das haben? Es ging um die Komplexität des Controllers und seiner Peripherie. Die ARM-CPU hat übrigens gerade mal 56 Befehle, bei Xmega sind es 142. > Du wirst doch nicht ernsthaft > behaupten Asm wäre die Sprache der Wahl bei diesen 32-Bittern ;-( Nein, das habe ich nicht behauptet. Warum auch? Außer für dich ist es auch bei heutigen 8-Bittern für niemanden die Sprache der Wahl. > [Xmega …], die Ansprache der Peripherie nicht > grundverschieden. Autsch. Jetzt glaube ich dir nicht mehr, dass du überhaupt jemals was mit einem Xmega gemacht hast. Ja, der Befehlssatz ist nur wenig mehr als der der MegaAVRs. Aber die Peripherie ist sowas von grundverschieden, dass du dich mit obiger Aussage einfach nur blamierst. Ehrlich gesagt, mit fällt auf Anhieb kein einziges Peripheral ein, das auch nur annähernd so bedient werden würde wie im MegaAVR. OK, da du (s. o.) sowieso unflätig wirst, genug für mich hier.
Moby A. schrieb: > Umgekehrt wurde der Xmega von Atmel sicher für C optimiert. Das gilt bereits für die alten AVRs. Deshalb auch die vielen Registern, die ein Compiler weit besser zuordnen kann, als ein Mensch. Ausser Moby natürlich ;-) Moby A. schrieb: > Wer sich 'blöd' fühlt muß das mit sich ausmachen. > Ich würde niemals so persönlich werden, auch wenn sich selbst 'Große > Jungs' hier desöfteren unbeherrscht wie kleine Kinder aufführen denen > das Spielzeug streitig gemacht wird ;-) Dafür repetierst du bestimmt zum zwanzigsten Mal deine Meinung, ohne ein einziges Beispiel zu zeigen, wo bei einer einfachen Aufgabe Assembler gegenüber C einen klaren Vorteil bringt. Bin schon gespannt, wie du dich diesmal aus der Forderung nach einem konkreten Beispiel windest.
Jörg W. schrieb: > Autsch. Jetzt glaube ich dir nicht mehr, dass du überhaupt jemals > was mit einem Xmega gemacht hast. Das brauchst Du nicht. Es reicht, daß ich das weiß ;-) > Ehrlich gesagt, mit fällt > auf Anhieb kein einziges Peripheral ein, das auch nur annähernd so > bedient werden würde wie im MegaAVR. Mir dafür genügend. Die (bekannten) Steuerbits sind etwas anders verteilt, ein paar mehr Möglichkeiten gibt es, das wars auch schon. > OK, da du (s. o.) sowieso unflätig wirst, genug für mich hier. Au weia. Ist aber auch ärgerlich, diese permanente Widerrede.
P. M. schrieb: > Dafür repetierst du bestimmt zum zwanzigsten Mal deine Meinung, ohne ein > einziges Beispiel zu zeigen, wo bei einer einfachen Aufgabe Assembler > gegenüber C einen klaren Vorteil bringt. Bin schon gespannt, wie du dich > diesmal aus der Forderung nach einem konkreten Beispiel windest. Da "repetiere" ich doch glatt schon wieder: Schau Dir mein Asm-Projekt an und zeig mir eine C-Lösung die mit weniger Ressourcen auskommt. Dann wird der klare Asm Vorteil für Dich vielleicht etwas klarer ;-) P. M. schrieb: > Moby A. schrieb: >> Umgekehrt wurde der Xmega von Atmel sicher für C optimiert. > > Das gilt bereits für die alten AVRs. Deshalb auch die vielen Registern, > die ein Compiler weit besser zuordnen kann, als ein Mensch. Ausser Moby > natürlich ;-) Ach woher denn. Für Asm gibts hier Projekte wie Sand am Meer, sicher auch von besseren Programmierern als mich. Der Moby ist weißgott nichts besonderes und hat allein die Vorzüge von Asm entdeckt.
:
Bearbeitet durch User
Naja, da es hier um Moby AVR gegen den Rest der Welt geht, sage ich auch noch was dazu. Klar sind die Compiler heute sehr sehr gut. Auch manche Controller sind mit einem minimalem Befehlssatz ausgerüstet, der durch einen Compiler leicht eingesetzt werden kann (z.B. PIC). Die meisten Controller, darunter auch RISC-Typen, bieten aber einen so großen Befehlsumfang, dass ein Compiler viele dieser Opcodes ignorieren muss, da sonst innerhalb des Compiler zu viele Fallunterscheidungen nötig werden. Da ist mit handgestricktem Assemblercode also durchaus noch etwas optimierbar. Ob das angesichts der Rechenleistung halbwegs moderner Controller relevant ist, ist vom Einzelfall abhängig.
Guido B. schrieb: > Die meisten > Controller, darunter auch RISC-Typen, bieten aber einen so großen > Befehlsumfang, dass ein Compiler viele dieser Opcodes ignorieren > muss, da sonst innerhalb des Compiler zu viele Fallunterscheidungen > nötig werden. Da ist mit handgestricktem Assemblercode also durchaus > noch etwas optimierbar. Mit verlaub, aber bevor du das mit Quellen belegen kannst, glaube ich da kein Wort. Opcodes zu ignorieren wegen "Fallunterscheidungen" im Compiler wäre dermassen unsinnig.
Diese Diskussion ist ungefähr genauso unsinnig wie "Python ist nutzlos, C ist viel schneller". Ja, stimmt. Nur dass mir für 99 von 100 Programmen die ich schreibe die Performance völlig egal ist, weil das Ganze schon in Python nur 0.3 Sekunden dauert. Ja, in C wären es vielleicht nur 0.01 Sekunden, aber wen interessiert's? Mich nicht. Dafür brauche ich in C die zehnfache Zeit um's aufzuschreiben. Nur dass bei dieser dämlichen C vs ASM-Debatte der Performance-Unterschied nichtmal 10000% ist wie bei Python vs C sondern vielleicht 10%. Und das auch nur, wenn man sich sehr geschickt anstellt in ASM. Nobody cares. Deal with it.
:
Bearbeitet durch User
@Sven Du hast wohl eher PC-Programme im Sinn ?! Performance ist ja nur der eine Aspekt. Der andere wesentliche ist der Platzbedarf. > Dafür > brauche ich in C die zehnfache Zeit um's aufzuschreiben. Diese Äußerlichkeiten zu erwähnen habe ich mich hier noch gar nicht getraut. Da finde ich Asm, garniert mit entsprechenden Kommentaren zu Funktion und Schnittstellen nämlich auch wesentlich kompakter und übersichtlicher. Ehrlich. Aber lassen wir das, denn dieses Empfinden ist höchst subjektiv und die Meinungen geteilt.
:
Bearbeitet durch User
Moby A. schrieb: > Der andere wesentliche ist der Platzbedarf. Dieses Argument gilt schon mindestens 20 Jahre nicht mehr und es für heutige Hardware vorzubringen, ist einfach nur lächerlich.
Moby A. schrieb: > @Sven > Du hast wohl eher PC-Programme im Sinn ?! > Performance ist ja nur der eine Aspekt. > Der andere wesentliche ist der Platzbedarf. Also mein uC für 8 Euro hat 1 MB Flash und davon hab ich vielleicht 100kB belegt. Moby A. schrieb: > Diese Äußerlichkeiten zu erwähnen habe ich mich hier noch gar nicht > getraut. Da finde ich Asm, garniert mit entsprechenden Kommentaren zu > Funktion und Schnittstellen nämlich auch wesentlich kompakter und > übersichtlicher. Ehrlich. Aber lassen wir das, denn dieses Empfinden ist > höchst subjektiv und die Meinungen geteilt. Schon, aber irgendwie sind 99.x% der Leute (auch in diesem Thread btw) zufällig der Meinung dass C leichter zu lesen ist. Hey, wenn du gern ASM schreibst, tu's doch einfach. Ich hab damit überhaupt kein Problem. Aber dieses rumgestreite, dass das das beste sei seit geschnitten Brot und alle Leute die C benutzen sind nur verblendet und es ginge besser ... was soll das denn. Das ist einfach bloß albern.
:
Bearbeitet durch User
Mein Brötchengeber würde mich rauswerfen, wenn ich jetzt mit Assembler programmieren würde. So von wegen effizientes Entwickeln. Zu Recht würde er das. ;-)
>Assembler wieder auf dem Weg nach vorn Syphilis weiter auf dem Vormarsch http://www.pharmazeutische-zeitung.de/index.php?id=49611 Danke, aber ich muß nicht jeden Trend mitmachen ;-)
Michael K. schrieb: >>Assembler wieder auf dem Weg nach vorn > > Syphilis weiter auf dem Vormarsch > http://www.pharmazeutische-zeitung.de/index.php?id=49611 > > Danke, aber ich muß nicht jeden Trend mitmachen ;-) Muahaha... jetzt hab ich Kaffeeflecken auf der Tastatur... Best answer ever...
Warum sich viele von Moby so angestachelt fühlen, liegt doch nur an folgender Tatsache: Moby verallgemeinert bewusst und provozierend seine Mini-Projekte, für die tatsächlich Assembler reicht, derart, dass er sagt: "Die ganze Welt kommt mit Mini-Programmen aus, Assembler reicht" Und genau hier liegt der Trugschluss. Moby kennt nur seine Mini-Programme, hat aber von Elektronik-Projekten in der Praxis (außer seinen eigenen) überhaupt keine Ahnung. Da, wo ein ATmega reicht, vernetzt er hunderte von ATTinys und sagt: "ATTiny reicht, Assmbler reicht". Warum? Weil er es nicht besser kann! Kann man zwar so machen, ist aber ineffizient. In C macht mans mit dem nächstgrößeren Prozessor in einem zehntel der Zeit. Da wo Moby viele Jahre an seinem Smart-Home-System rumbastelt, machts ein anderer in ein paar Wochen fertig. Die eigentliche Frechheit von Moby ist, von seinem Mikrokosmos auf den Rest der Welt zu schließen. Das ist sein großer Irrtum. Und es kommt absolut arrogant rüber. Wenn alle vor 20 Jahren auf Moby gehört hätten, dann stände bei uns kein PC unterm Tisch, sondern heute noch ein 8-Bit-Prozessor mit angeflanschter HEX-Tastatur. Das wiederum zeigt, dass Programmieren in Assembler eine Sackgasse ist. Soll Moby ruhig noch 20 Jahre mit ATTinys rummachen. Aber er soll einfach dabei die Füße stillhalten.
Moby A. schrieb: > P. M. schrieb: >> obwohl völlig klar ist, dass Moby's Behauptungen null >> Substanz haben. > > Schön, wenn Du das behauptest... Deine Begründung hat jedenfalls Null > Substanz, es gibt nämlich schlicht keine. Sag mal unser Moby hat doch definitiv Verwandte in Katzelsried. So viel Zufall gibts doch gar nicht. Die Krönung wäre jetzt noch beide in den gleichen Thread zu locken. Was würd ich dafür geben...
P. M. schrieb: > Moby, hast du eigentlich ein einzelnes Beispiel, wo du mit Assembler > tatsächlich besser Gefahren bist, als mit C? Das ist ja der Gag an der Geschichte. Mehr als einen 20 Zeiler (schon öfter auch Micky Maus code genannt) hat er nichts auf die Beine gestellt ;-) siehe hier: Beitrag "Kleines Tiny13 Sensorboard" Aber dann soooo ne Klappe ...
:
Bearbeitet durch User
Gu. F. schrieb: > Mehr als einen 20 Zeiler (schon öfter auch Micky Maus code genannt) hat > er nichts auf die Beine gestellt ;-) Naja, mehr hat er zumindest nicht präsentiert und ich würde es an seiner Stelle auch nicht tun. Der arme, sture Kerl hat doch die ganze Programmiererwelt gegen sich aufgebracht ;-)
Dank Moby haben wir alle über die Jahre in epischer Breite erfahren wo Vor- und Nachteile des ASM gegenüber einem Rudel anderer Spachen liegen und wie groß, klein, wesentlich oder unwesentlich die sind. Wir wissen jetzt was die Mehrheit darüber denkt und was Moby unbeeindruckt von jeglicher Argumentation darüber denkt. Wer nach all dieser Zeit wirklich immer noch inhaltlich mit Moby darüber diskutiert ist nicht weniger stur und uneinsichtig. Unnötig zu persönlichen Angriffen überzugehen.
Michael K. schrieb: > Dank Moby haben wir alle über die Jahre in epischer Breite erfahren wo > Vor- und Nachteile des ASM gegenüber einem Rudel anderer Spachen liegen > und wie groß, klein, wesentlich oder unwesentlich die sind. Nein, eben gerade nicht. Moby bringt ja eben gerade keine Fakten in die Diskussion ein, er windet sich bloss indem er jede Gegenrede mit dem nächsten seiner unbegründeten Argumente kontert, und dabei schon lange im Kreis geht. Michael K. schrieb: > Wer nach all dieser Zeit wirklich immer noch inhaltlich mit Moby darüber > diskutiert ist nicht weniger stur und uneinsichtig. Frage mich auch, warum ich das eigentlich mitmache. Keine Ahnung, warum es Spass macht. Überzeugen muss/kann man ja hier niemanden mehr und etwas lernen wird man schon gar nicht.
was man auch immer von Mobys starker Fokussierung auf ASM halten mag: Er bleibt in seiner Argumentation immer sachlich und wird nicht aufbrausend. Das ist ihm auf jeden Fall hoch anzurechnen.
Wegstaben V. schrieb: > was man auch immer von Mobys starker Fokussierung auf ASM halten mag: Er > bleibt in seiner Argumentation immer sachlich und wird nicht > aufbrausend. Das sehe ich anders. Er versieht jeden Satz, wo er lächelnd auf den anderen "herunterschaut", mit einem Smiley ";-)". Das kommt ziemlich herablassend rüber und zeugt von wenig Respekt.
Wegstaben V. schrieb: > Er > bleibt in seiner Argumentation immer sachlich und wird nicht > aufbrausend. Sachlich ist er schonmal nicht, da er bloss seine Argumente wiederholt und umformuliert, aber nicht auf Gegenfragen eingeht. Beispielsweise liefert er keinerlei belastbare Fakten oder konkrete Beispiele für seine Aussagen. Aufbrausend wird er nicht, das stimmt. Es gibt aber auch andere Möglichkeiten, um unanständig zu sein in einer Diskussion. Beispielsweise die freundlich-herablassende Art, die er pflegt.
Wegstaben V. schrieb: > was man auch immer von Mobys starker Fokussierung auf ASM halten mag: Er > bleibt in seiner Argumentation immer sachlich und wird nicht > aufbrausend. Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Sachlich? Würde ich mir anders vorstellen. (Wollte hier eigentlich nichts mehr schreiben, aber das konnte ich nun nicht so stehen lassen.)
:
Bearbeitet durch Moderator
P. M. schrieb: > Frage mich auch, warum ich das eigentlich mitmache. Das gleiche wie alle anderen hier (inklusive mir): unterhalten werden wollen. Es gibt Figuren in diesem Forum, da ist der Name schon ein Garant für beste Unterhaltung zur Mittagszeit. Ich will keine Namen nennen, aber die Diskussionen über Assembler, Basisteilchen und Hexadezimalsysteme sorgen immer wieder für Kurzweil.
P. M. schrieb: > Nein, eben gerade nicht. Moby bringt ja eben gerade keine Fakten in die > Diskussion ein Aber er ist der Tippgeber an denen sich die anderen abackern und viele gute Informationen liefern. Auch eine Leistung. le x. schrieb: > Ich will keine Namen nennen, aber die Diskussionen über Assembler, > Basisteilchen und Hexadezimalsysteme sorgen immer wieder für Kurzweil. https://de.wikipedia.org/wiki/Raymond_Kurzweil ?? Die unheilige Dreieinfältigkeit ... (kommt, soweit ich mich erinnern kann, von Falk) Ja, ist immer wieder lustig, aber wenn einem das Nervenkostüm dünn wird ob dieser Beratungsresistenz darf man auch einfach in den RO Modus wechseln. Ich glaube das Moby nicht halb so verbohrt ist wie man glaubt, er gönnt uns nur nicht das letzte Wort und bepinkelt sich vor Lachen wie viel Energie hier manche reinstecken seine Worte zu widerlegen und wie die aus der Naht gehen wenn nichts davon ankommt. Jörg W. schrieb: > Sachlich? Im Vergleich zu dem was hier oft abgeht, ja.
Assembler ist auch ein hohes Risiko für den Arbeitgeber. Scheidet ein Assemblerprogrammierer aus, ist die Gefahr, daß er verbrannte Erde hinterläßt, viel höher, als bei einem C-Programmierer. C läßt sich auch deutlich besser im Team programmieren, d.h. die Kollegen können gegenseitig die Qualität überwachen.
Uhu U. schrieb: > Moby A. schrieb: > Der andere wesentliche ist der Platzbedarf. > > Dieses Argument gilt schon mindestens 20 Jahre nicht mehr und es für > heutige Hardware vorzubringen, ist einfach nur lächerlich. Lächerlich für aktuell immer fettere Controller vielleicht. Oder gar ein Raspberry für einfache MSR Aufgaben. Woraus leitest Du ab daß diese immer die sinnvollste Lösung darstellen wenn mit etwas Investment in effiziente Asm-Programmierung ein kleiner AVR langt? Wolfgang R. schrieb: > Mein Brötchengeber würde mich rauswerfen, wenn ich jetzt mit > Assembler programmieren würde. Tja den hat der Bastler glücklicherweise nicht. Und damit auch nicht tausend weitere Vorgaben die die Wahl des Controllers beeinflussen. Für den Bastler zählt nur eines: Die konkreten Bedürfnisse seiner Anwendung. Die sind für einfache bis mittelkomplexe MSR Projekte meist locker mit einem AVR erledigt.
Frank M. schrieb: > Moby verallgemeinert bewusst und provozierend seine Mini-Projekte, > für die tatsächlich Assembler reicht Ich verallgemeinere keine Mini-Projekte sondern >90% aller MSR Projekte hier im Forum und im Alltag. > Moby kennt nur seine > Mini-Programme, hat aber von Elektronik-Projekten in der Praxis (außer > seinen eigenen) überhaupt keine Ahnung. Da, wo ein ATmega reicht, > vernetzt er hunderte von ATTinys und sagt: "ATTiny reicht, Assmbler > reicht". Warum? Weil er es nicht besser kann! Ich staune immer über das, was speziell Du zu wissen glaubst. Wenn ein Tiny für ein Projekt genügt dann genügt er- und man muß keinen Cortex-M einsetzen. Das ist Effizienz! Und zwar auf der ganzen Linie. > Da wo Moby viele > Jahre an seinem Smart-Home-System rumbastelt, machts ein anderer in ein > paar Wochen fertig. So ein Smart-Home ist nie fertig. Warum? Weil ständig neue Wünsche hinzukommen. > Die eigentliche Frechheit von Moby ist, von seinem Mikrokosmos auf den > Rest der Welt zu schließen. Das ist sein großer Irrtum. Und es kommt > absolut arrogant rüber. Ein Frank M. muß mir sicher nicht erklären, was frech und arrogant ist. Wenn der Fakt, daß Asm so effizient ist, Dein Weltbild und C-Selbstwertgefühl stört ist das nicht mein Problem. > Wenn alle vor 20 Jahren auf Moby gehört hätten, dann stände bei uns kein > PC unterm Tisch, sondern heute noch ein 8-Bit-Prozessor mit > angeflanschter HEX-Tastatur. Das wiederum zeigt, dass Programmieren in > Assembler eine Sackgasse ist. Jeder Zweck mit den richtigen Mitteln. Ein Asm-Betriebssystem und entsprechende Anwendersoft ginge freilich auf heutigen PC-Systemen ab wie eine Rakete und kein normaler Anwender würde noch von Aufrüstung reden. Klar, daß sowas schlecht für die Industrie wäre! > Aber er soll > einfach dabei die Füße stillhalten. Das könnte Dir so passen. Wenn sich in das Feuer lahmarschiger fetter C-Software eiskaltes Asm-Wasser gießen lässt dann mach ich das mit großer Freude und labe mich an den aufgeschreckt empörten Reaktionen ;-)
Moby A. schrieb: > effiziente Asm-Programmierung Blablabla Du bist einfach ein Schwätzer. Geh endlich heim spielen. Hier diskutierten Fachleute... Man man so viel Käse in einem Thread gibt's sonst nur beim Bindl.
Moby A. schrieb: > eiskaltes Asm-Wasser Dann lern erst mal assembler. Speziell solche Befehle wie EOR :-) Jaja Salz in die Wunde ich weiß...
Witkatz :. schrieb: > Naja, mehr hat er zumindest nicht präsentiert und ich würde es an seiner > Stelle auch nicht tun. Der arme, sture Kerl ... wird ganz sicher mit weiteren Projekten die Begrenztheiten von C vorführen. Aber sicher nicht, weil er arm und stur wäre ;-) Leider passen die großen Asm-Projekte von mir hier nicht rein, u.a. weil sie zu speziell an meine Bedürfnisse angepasst sind. Aber wenn ich es recht bedenke ist das noch lange nicht nötig, solange es die größten Marktschreier und sogenannten "Großen Jungs" hier nicht schaffen, schon für ein ganz kleines Asm-Programm eine ressourcensparendere Lösung mit dem angeblich so hochpoduktiv mönströsen C-Instrumentarium zu liefern ;-)
Uhu U. schrieb: > lächerlich. Moby A. schrieb: > Lächerlich Gu. F. schrieb: > Schwätzer Lächerlicher Schwätzer ! (empört mit dem Fuß aufstampf) So, besser jetzt ? Der eine will Java auf einer 8bit MCU und der andere WIN 10 in Assembler programmieren. Ich will nur weg hier wo sich Erwachsene wie bockige kleine Gören benehmen und das mach ich jetzt auch.
Gu. F. schrieb: > Du bist einfach ein Schwätzer. Warum muß ich da bloß immer zuerst an Dich denken? Stell mal hier was Eigenes auf die Beine dann reden wir weiter. Wenn ichs einfach haben wollte wär ich auch Bayern Fan und nicht der einer drittklassigen Mannschaft ;-) Michael K. schrieb: > Ich will nur weg Du wirst lachen. Das ist auch das Sinnvollste wenn man nicht mehr weiter weiß ;-)
:
Bearbeitet durch User
Moby A. schrieb: > für ein ganz kleines Asm-Programm eine ressourcensparendere Lösung mit > dem angeblich so hochpoduktiv mönströsen C-Instrumentarium zu liefern Genau darum geht es doch gerade nicht, bzw nicht in dem Sinn, wie du es meinst. Arbeitszeit ist auch eine wichtige Ressource, vor allem auch für Hobbyisten (nur wird sie da kurioserweise Freizeit genannt). Es mag ja sein, dass im Vergleich zu dem weltbesten ASM-Programmierer der C-Compiler im Mittel (!) geringfügig langsameren und größeren Code produziert, aber der Code ist sehr viel schneller geschrieben, sehr viel wartbarer und - Risesiger Bonus - problemlos (von der Hardwareabstraktion mal abgesehen) auf andere Platformen übertragbar. Und wenn ich mir für meine Einzelstücke durch einen 50Cent teureren Controller mit mehr Speicher all diese Vorteile erkaufen kann, wäre ich dumm, dies nicht zu tun. Edit: Und warum sollte man > für ein ganz kleines Asm-Programm überhaupt > eine ressourcensparendere Lösung finden wollen? Ein ganz kleines Projekt kriegt den Controller eh nicht voll. Und für gesparten Ram und Cycles gibts kein Geld zurück und noch weniger für die längere Entwicklungszeit
:
Bearbeitet durch User
Peter D. schrieb: > Scheidet ein Assemblerprogrammierer aus, ist die Gefahr, daß er > verbrannte Erde hinterläßt, viel höher, als bei einem C-Programmierer. Weil vielleicht die Doku schlecht ist? Weil vielleicht die Mehrzahl der Nachfolger kein Asm kann? Beides ließe sich korrigieren... > C läßt sich auch deutlich besser im Team programmieren, d.h. die > Kollegen können gegenseitig die Qualität überwachen. So wird es wohl sein. Es müsste aber nicht sein.
Moby A. schrieb: > Weil vielleicht die Doku schlecht ist? ok, kommt bei dir ja nicht vor - dank selbsterklärendem ASM.
Moby A. schrieb: > Ein Asm-Betriebssystem und entsprechende Anwendersoft ginge freilich auf > heutigen PC-Systemen ab wie eine Rakete Eher unwahrscheinlich. Wann hast du das letzte Mal in die Befehlsliste heutiger x86-64 reingesehen? Da lernst du manches Telefonbuch schneller auswendig. Und bis du bei einem solchen Betriebssystem die Handoptimierung des Codes fertig hast ist die dazu empfohlene Strategie aufgrund neuer Implementierungs-Architekturen schon 2 Generationen weiter und du kannst von vorne anfangen. Als einfaches Beispiel, um es nicht zu kompliziert zu machen: Versuch mal, deinen AVR Code so zu schreiben, dass hintereinander stehende Befehle nicht von einander abhängig sind und das Ergebnis eines Ladebefehls möglichst erst 10 Befehle später benötigt wird. Und denk dabei an versteckte Schweinereien, wie etwa ein INC Befehl, der das Carry-Flag zwar nicht nutzt, aber davon abhängt.
Michael K. schrieb: > Unnötig zu persönlichen Angriffen überzugehen. Das wäre in der Tat die nächste Phase, wenn Ignorieren und Lächerlichmachen erfolglos bleiben ;-) P. M. schrieb: > und > etwas lernen wird man schon gar nicht. Doch. Das könntest Du durchaus. Ein (womöglich Uni-) Bildungs-Investment in C oder gar OOP, in die Cortexe und andere Hochbitter dieser Welt lässt man aber nicht so einfach in Frage stellen... Da mag die App noch so einfach sein. Dafür hab ich doch Verständnis ;-)
Frank M. schrieb: > mit einem Smiley ";-)". Das kommt ziemlich > herablassend rüber und zeugt von wenig Respekt. Das soll nur meine Stimmungslage wiedergeben, wenn mal wieder C,OOP,Cortexe und andere Hochbitter für einfache Aufgaben als effiziente einfachste Lösung verkauft werden ;-) Michael K. schrieb: > er gönnt > uns nur nicht das letzte Wort und bepinkelt sich vor Lachen wie viel > Energie hier manche reinstecken seine Worte zu widerlegen und wie die > aus der Naht gehen Nö. Ich lerne auch gern was. Bei Diskussionen über Sinn und Zweck von Asm war das allerdings bislang enttäuschend wenig, so daß eher der Amüsierfaktor (s.o.) überwiegt. Ein praktischer Beweis der C-Effizienz anhand meiner Projektvorlage könnte mich allerdings zum Staunen und Umdenken bewegen- was die Bewertung der Hochsprache angeht.
A. K. schrieb: > versteckte Schweinereien, wie etwa ein INC Befehl, der das > Carry-Flag zwar nicht nutzt, aber davon abhängt. Um das mal an Code eines Pseudo-AVR zu illustrieren, der sich intern wie ein x86er dieses Jahrhunderts verhält: code1: ld r16,x add r16, r17 st x,r16 inc xl dec r16 brnz code1 code2: ld r16,x add r16, r17 st x,r16 subi xl, -1 subi r16, 1 brnz code2 Es geht jetzt nicht darum, den aufgrund der Unterschiede zu x86 nicht-optimalen Code zu verbessern. Sondern um die Frage eines erstaunten Programmierers, weshalb Code2 bei Intel zwischendurch mal viel schneller lief als Code1, während es bei AMD keinen Unterschied ergab.
:
Bearbeitet durch User
Vlad T. schrieb: > Und warum sollte man >> für ein ganz kleines Asm-Programm > überhaupt >> eine ressourcensparendere Lösung > finden wollen? Da fallen mir schon Gründe ein 1. aus sportlichem Ehrgeiz oder zum Spaß 2. als Lernbeispiel 3. um die Ergebnisse des Compilers mit dem ASM Code wirklich vergleichen zu können
A. K. schrieb: > Um das mal an Code eines Pseudo-AVR zu illustrieren, der sich intern wie > ein x86er dieses Jahrhunderts verhält: Sorry, ersetze den loop counter r16 in dec r16 bzw subi r16, 1 durch r18. Also code1: ld r16,x add r16, r17 st x,r16 inc xl dec r18 brnz code1 code2: ld r16,x add r16, r17 st x,r16 subi xl, -1 subi r18, 1 brnz code2
:
Bearbeitet durch User
Vlad T. schrieb: > aber der Code ist sehr viel schneller geschrieben, Das "sehr viel" kannst Du bei einem geübten Asmler streichen, insbesondere wenn er/sie mit System dran geht und das Rad nicht immer wieder neu erfindet. > sehr viel > wartbarer Einspruch. Das ist eine Sache der Doku- und der Übung in Asm. Was dessen Transparenz, Wartbarkeit und Fehlersuche erleichtert ist die Tatsache daß man 100% des endgültigen Codes stets vor sich hat. > und - Risesiger Bonus - problemlos (von der > Hardwareabstraktion mal abgesehen) auf andere Platformen übertragbar. Das erübrigt sich, wenn man wegen Asm bei der gleichen Architektur bleiben kann! > Ein ganz kleines Projekt kriegt den Controller eh nicht voll. Ein etwas größeres eher. Welches man womöglich zukünftig noch etwas erweitern möchte. Ist es nicht schön wenn das Ganze immer noch in den ausgesuchten, billigeren Controller passt ? Jetzt stell Dir mal vor das Ding ist schon irgendwo fix verbaut... Da dankst Du dem Allmächtigen, daß keine Neuentwicklung nötig wird ;-)
:
Bearbeitet durch User
A. K. schrieb: > Sondern um die Frage eines > erstaunten Programmierers, weshalb Code2 bei Intel zwischendurch mal > viel schneller lief als Code1, während es bei AMD keinen Unterschied > ergab. Das passt nicht hierher weil AMD und Intel Prozessoren eines viel komplexeren Kalibers sind. Die eklatanten Performance-Unterschiede zwischen unterschiedlichen Programmiersprachen sind da auf einem Controller viel relevanter und alltäglicher...
Moby A. schrieb: > Weil vielleicht die Doku schlecht ist? > Weil vielleicht die Mehrzahl der Nachfolger kein Asm kann? Beides ließe > sich korrigieren... Dann fang endlich an zu lernen. Deine Kasperei ist mindestens peinlich. Ein Blinder Maler ist eine schwacher Vergleich für Blindgänger wie dich. Ich habe ja immer noch die Hoffnung dass du nur trollst weil ich noch an einen Rest-IQ von dir glaube. Aber irgendwas sagt mir dass ich wieder enttäuscht werden ;-) Wie auch immer, ich kriege langsam Kreuzschmerzen wenn ich mich ständig auf deinen Horizont runterbeugen muss. Ich werde dich darum nicht weiter mit Trollfutter versorgen. Schönes Asm kennen noch. Vlt. schaffst du ja mal ein programm mit 30+ Zeilen...
:
Bearbeitet durch User
Gu. F. schrieb: > Ich werde dich darum nicht weiter > mit Trollfutter versorgen Soooo ein Pech ;-) Allzu erfolgreich warst Du zwar nicht aber ein bunter Farbtupfer in der Diskussion! Deine Minuspunkte werden mir fehlen ;-((
:
Bearbeitet durch User
Yalu X. schrieb: > Nennt man so einen besonders starken Kräuterschnaps? ;-) Will jetzt nicht arrogant wirken aber unter dem scheint mancher Forumsteilnehmer zuweilen zu stehen :-)
Moby A. schrieb: > Das passt nicht hierher weil AMD und Intel Prozessoren eines viel > komplexeren Kalibers sind. Es war dein eigener Vorschlag, heutige PC Systeme in Assembler zu programmieren: Moby A. schrieb: > Ein Asm-Betriebssystem und entsprechende Anwendersoft ginge freilich auf > heutigen PC-Systemen ab wie eine Rakete
A. K. schrieb: > Eher unwahrscheinlich. Wann hast du das letzte Mal in die Befehlsliste > heutiger x86-64 reingesehen? Da lernst du manches Telefonbuch schneller > auswendig. Mag sein. Ein Sammelsurium von Befehlen im krampfhaften Bemühen, über Jahrzehnte kompatibel zu allen möglichen Entwicklungen zu bleiben. Allerdings würden u.U. auch schon die 8086er Codes für hochperformante Asm-Programmierung ausreichen !? > Und bis du bei einem solchen Betriebssystem die Handoptimierung des > Codes fertig hast ist die dazu empfohlene Strategie aufgrund neuer > Implementierungs-Architekturen schon 2 Generationen weiter und du kannst > von vorne anfangen. In der Praxis hast Du angesichts dieser Entwicklung recht: Sich auf eine übergeordnete (Hochsprachen-)Ebene zu begeben scheint geboten. ABER: Wir reden hier vom PC Bereich und nicht von kleinen 8-bittigen MCs, die hardwarenah einfache MSR Aufgaben lösen. > Als einfaches Beispiel, um es nicht zu kompliziert zu machen: Versuch > mal, deinen AVR Code so zu schreiben, dass hintereinander stehende > Befehle nicht von einander abhängig sind und das Ergebnis eines > Ladebefehls möglichst erst 10 Befehle später benötigt wird. Und denk > dabei an versteckte Schweinereien, wie etwa ein INC Befehl, der das > Carry-Flag zwar nicht nutzt, aber davon abhängt. Schwierig. Aber zum Glück bei MCs nicht nötig.
A. K. schrieb: > Es war dein eigener Vorschlag, heutige PC Systeme in Assembler zu > programmieren Der wurde sogar schon umgesetzt. Also möglich wärs.
Moby A. schrieb: > Allerdings würden u.U. auch schon die 8086er Codes für hochperformante > Asm-Programmierung ausreichen !? Kannst du haben. MS-DOS war lange Zeit das auf PCs dominierende Betriebssystem und das wurde in Assembler geschrieben. Anwendungen nicht selten auch. Ich kenne freilich niemanden, der MS-DOS nachtrauert. > Schwierig. Aber zum Glück bei MCs nicht nötig. Pustekuchen. Der Cortex M7 (z.B. im STM32F7) ist dual-issue, d.h. der kann pro Takt 2 Befehle dekodieren und ausführen. Aber natürlich nur, wenn die nicht voneinander abhängen und sich auch nicht anderweitig gegenseitig auf den Füssen stehen. Das ist grob das Niveau vom Pentium P5 der 90er, was die Entwicklung der Implementierungen von Mikrocontrollern angeht. Und ebendieser P5 war der erste x86er, bei dem Handoptimierung in Assembler anfing, kompliziert zu werden. Und der CM7 war sicher nicht das letzte Wort zu diesem Thema.
:
Bearbeitet durch User
Moby A. schrieb: > Deine Minuspunkte werden mir fehlen Hab' dir mal ein paar "lebenswert" gegeben. Und immer schön wacker bleiben. mfg.
Moby A. schrieb: > Welches man womöglich zukünftig noch etwas > erweitern möchte. Und während sich die Programmierer in Villabacho bis spät in der Nacht durch meterweise ASM Code durchquälen, feiert Villariba längst die erfolgreichen Tests des erweiterten C-Projekts. Moby A. schrieb: > Ist es nicht schön wenn das Ganze immer noch in den > ausgesuchten, billigeren Controller passt ? Leidest du vielleicht an digitaler Agoraphobie? Wurde es schon erwähnt, dass ein vernünftig geschreibenes C Projekt genausogut rein passt?
A. K. schrieb: > Schwierig. Aber zum Glück bei MCs nicht nötig. > > Pustekuchen. Der Cortex M7 ... So ist das eben bei zuviel Komplexität. Das trägt sein Scherflein dazu bei daß die ARMen Dinger immer schlechter in Asm zu programmieren sind. Da lob ich mir die AVRs und daß alle einfache Sachen heute noch nicht mit ARM gelöst werden müssen.
Witkatz :. schrieb: > Wurde es schon erwähnt, > dass ein vernünftig geschreibenes C Projekt genausogut rein passt? Peter D. schrieb: > Im Schnitt sind daher C-Programme etwa 10..50% größer Um mir nicht schon wieder einen eigenen "Repetierer" aus dem Hirn leiern zu müssen ;-)
Moby A. schrieb: > Peter D. schrieb: >> Im Schnitt sind daher C-Programme etwa 10..50% größer Selbst verglichen hast du es also nicht, dass du dich auf fremde Statistiken berufen musst? Die Frage war rein rhetorischer Natur, weil es zig mal erwähnt wurde. 10..50% machen nur ganz selten den Ausschlag den µC zu wechseln. Bevor es so weit kommt, hat man auch in C viele Möglichkeiten die Ressourcennutzung zu optimieren. Gute C Programmierer können eben beides ASM und C und können aus dem ASM Listing Rückschlüsse auf die Qualität des C-Codes ziehen, wenn es drauf ankommt.
:
Bearbeitet durch User
Moby A. schrieb: > Woraus leitest Du ab > daß diese immer die sinnvollste Lösung darstellen wenn mit etwas > Investment in effiziente Asm-Programmierung ein kleiner AVR langt? Was ist denn die "sinnvollste Lösung"? Eine für die man Punkte im Programmiererhimmel bekommt, aber pleite geht? Mit deiner Einstellung wirst du jedenfalls im echten Leben ganz schnell einen Bankrott hinlegen. Na wenigstens hast du hinterher die Müße, darüber nachzudenken, ob das sinnvoll war...
Moby A. schrieb: > Ein Asm-Betriebssystem und entsprechende Anwendersoft ginge freilich auf > heutigen PC-Systemen ab wie eine Rakete und kein normaler Anwender würde > noch von Aufrüstung reden. Ich kann mich noch sehr gut an so ein ASM-Betriebssystem erinnern: KOS von Kontron für deren Z80-Rechner. Das lief wunderbar und vor allem sau schnell in der Warteschleife. Wenn es arbeiten sollte, hatte es einen unübersehbaren Hang zu Instabilität...
Moby A. schrieb: > Vlad T. schrieb: >> aber der Code ist sehr viel schneller geschrieben, > > Das "sehr viel" kannst Du bei einem geübten Asmler streichen, > insbesondere wenn er/sie mit System dran geht und das Rad nicht immer > wieder neu erfindet. vergiss es. Modularisierung und Wiederverwendbarkeit erfordert definierte Schnittstellen und Vereinbarungen, wie zB calling conventions, die das parameterpassing und register clobbering festlegen. Gerade die sorgen dafür. dass overhead entsteht, den ein guter compiler sogar beseitigen kann, wenn er eine whole program optimization macht. Ein guter compiler ist auch sehr viel besser darin, registerzuordnungen zu handlen und hinterher noch da durchzusehen, was zu welchem Zeitpunkt wo ist. Für ihn ist es kein Problem bei einer ge-inline-ten Funktion die Variablen so in die Register zu legen, dass sie nicht mit dem Caller collidieren. Mach das mal mit asm-Funktionen, wenn du nicht das Rad neu erfinden willst. Auch hier hat der gnu-Inline-Assembler deutliche vorteile: hier könnte man nämlich tatsächlich einen ASM-BLock definieren und im asm Platzhalter verwenden, so dass sich der Compiler selbst aussuchen kann durch welche Register er die Platzhalter ersetzt.
Yalu hat in diesem Beitrag unlängst bewiesen, dass Moby's Code in allen Belangen schlechter ist: Beitrag "Re: C versus Assembler->Performance"
Michael K. schrieb: > le x. schrieb: >> Ich will keine Namen nennen, aber die Diskussionen über Assembler, >> Basisteilchen und Hexadezimalsysteme sorgen immer wieder für Kurzweil. > ... > Die unheilige Dreieinfältigkeit ... > (kommt, soweit ich mich erinnern kann, von Falk) Beitrag "Re: 8bit-Computing mit FPGA"
Na endlich, jetzt fehlt nur noch Kurt. Das wird herrlich freu
Markus M. schrieb: > Yalu hat in diesem Beitrag unlängst bewiesen, dass Moby's Code in allen > Belangen schlechter ist: > > Beitrag "Re: C versus Assembler->Performance" in genau jenem Thread bin ich, neben jeder Menge Ignoranz und Unbelehrbarkeit als Reaktion (auf in meinen Augen) sinnvolle Anmerkungen/Hinweise/Ratschläge, auf folgende Aussage gestoßen: Beitrag "Re: C versus Assembler->Performance" Karl Heinz B. schrieb: > Das wars. > Mir reichts. Du bist unbelehrbar. Ich versuch dir eine Brücke zu bauen > und du nimmst nichts an. Gar nichts. Du bist wie ein sturer Esel. > Aber ich warne dich: bei der nächsten 'Nimm doch Assembler' Meldung > in einem C Thread, wird gelöscht. Für KHBs Verhältnisse (im Gegensatz zu seiner sonstigen Engelsgeduld, die er selbst den frechsten/dreistesten Fragestellern entgegenbringt) ist das ja schon ein regelrechter Ausraster.
:
Bearbeitet durch User
Uhu U. schrieb: > Was ist denn die "sinnvollste Lösung"? Die einfachste und Ressourcen-sparendste. > Mit deiner Einstellung wirst du jedenfalls im echten Leben ganz schnell > einen Bankrott hinlegen. Im Programmiereralltag bin ich mit den sinnvollsten Lösungen bislang immer gut gefahren ;-)
Witkatz :. schrieb: > aus dem ASM Listing Rückschlüsse auf die > Qualität des C-Codes ziehen Der Assembler-Programmierer muß nicht erst Rückschlüsse aus irgendwelchen Listings ziehen. Er sieht den einzigen, engültigen Code vor sich und das beste ist: Er hat ihn 100%ig selbst in der Hand!
Markus M. schrieb: > Yalu hat in diesem Beitrag unlängst bewiesen, dass Moby's Code in > allen > Belangen schlechter ist: > > Beitrag "Re: C versus Assembler->Performance" Da wurde gar nichts bewiesen. Asm-Code bleibt die Messlatte für alle anderen Sprachen. Der Thread an sich ist aber lesenswert, möge sich jeder selber ein Urteil dazu bilden.
Uhu U. schrieb: > Das lief wunderbar und vor allem sau schnell in der Warteschleife. Wenn > es arbeiten sollte, hatte es einen unübersehbaren Hang zu > Instabilität... Untauglicher Versuch, von der Qualität eines OS auf die Vor- und Nachteile von Asm zu schließen.
Moby A. schrieb: > Der Assembler-Programmierer muß nicht erst Rückschlüsse aus > irgendwelchen Listings ziehen. Er sieht den einzigen, engültigen Code > vor sich und das beste ist: Er hat ihn 100%ig selbst in der Hand! Das wichtigste: Er versteht davon 0%, wenn es nicht sein eigener ist.
Moby A. schrieb: > auf die Vor- und Nachteile von Asm zu schließen. Welche Nachteile hat denn Asm? mfg.
Moby A. schrieb: >> Beitrag "Re: C versus Assembler->Performance" > > Der Thread an sich ist aber lesenswert, Stimmt. ;-)
Das ist aber mal eine fiese Frage.
Frank M. schrieb: > Er versteht davon 0%, wenn es nicht sein eigener ist. Das mag für Dich zutreffen und Du hattest das in meinem erwähnten Projekt auch hinreichend demonstriert. Thomas E. schrieb: > Welche Nachteile hat denn Asm? Die schlechte Nachricht ist: Je nach eigenem Können, Vorbereitung und System ist etwas mehr Mühe und Zeit nötig. Die gute ist: Es zahlt sich aus ;-)
Moby A. schrieb: > Das mag für Dich zutreffen und Du hattest das in meinem erwähnten > Projekt auch hinreichend demonstriert. Achja... Dein Projekt. Wieviele Interessenten haben Dir mittlerweile ein Platinchen abgenommen? > Die schlechte Nachricht ist: Je nach eigenem Können, Vorbereitung und > System ist etwas mehr Mühe und Zeit nötig. Kannst Du das Wort "etwas" quantifizieren?
Vlad T. schrieb: > Karl Heinz B. schrieb: >> Das wars. >> Mir reichts. Du bist unbelehrbar. Ich versuch dir eine Brücke zu bauen >> und du nimmst nichts an. Gar nichts. Du bist wie ein sturer Esel. >> Aber ich warne dich: bei der nächsten 'Nimm doch Assembler' Meldung >> in einem C Thread, wird gelöscht. Ich meine der Zeitpunkt ist schon längst überfällig...
Moby A. schrieb: > Die schlechte Nachricht ist: Je nach eigenem Können, Vorbereitung und > System ist etwas mehr Mühe und Zeit nötig. Ach komm, das ist doch keine Aussage. Das gilt doch für nahezu alles. Sowohl Fahrrad fahren als auch Kuchen backen. So eine Antwort wirft doch nur noch mehr Fragen auf. Was sind denn die von dir angesprochenen Nachteile konkret? Wieviel und welches Können? Wieviel und welche Vorbereitung? Was hat das System damit zu tun? Welche Mühen sind das und wieviel Mühe und Zeit kostet das? mfg.
Eigentlich ist es ja recht einfach: ASM ist in der THEORIE immer besser als alles Andere egal wie groß das Probjekt ist insofern hat Moby AVR natürlich recht.. ein durchschnittlicher Programmierer, wird es aber nur bis zu einer gewissen komplexität schaffen, besser zu sein als mit C mit etwas Aufwand wird er es schaffen diese Grenze nach oben zu verschieben aber irgendwo ist die Grenze (weiter oben kommt dann nochmal eine, wo man nicht mehr C sonder z.b. Pascal/c#/java nimmt, aber das wollen wir jetzt nicht ausarten lassen..) "Argumente" wie "ASM ist einfach" sind natürlich auch recht einfach zu durchschauen: das ist so wie Schach-Regeln, die kann man auch in 5 Minuten erklären.. deshalb ist Schach-Spielen noch lange nicht einfach.. Ich für mich persönlich hab folgende Entscheidung getroffen: 99% meiner Projekte sind WEIT weg von der Linie, wo ich es es selber im ASM schreiben könnte... dort verwende ich auch z.b. fertige "Biliotheken" für 1-wire, crc, 443mhz funk, usw (wo findet man sowas überhaupt in ASM? fix/fertig?) ...von tcp/ip mit W5100 oder EncJ-irgnedwas mal ganz abgesehen.. die Restenlichen 1% der Fälle die ich VIELLEICHT in ASM schreiben könnte, funktionieren auch in C/C++, würde also für MICH überhaupt keinen Sinn ergeben das in ASM zu schreiben... vorallem weil ich dann für dieses 1% länger brauchen würde, als für die restlichen 99% (weil ich erstmal ASM so gut lernen müsste, dass was brauchbares rauskommt..)
:
Bearbeitet durch User
Moby A. schrieb: > Uhu U. schrieb: >> Was ist denn die "sinnvollste Lösung"? > > Die einfachste und Ressourcen-sparendste. Was ist "Ressourcen-sparend"? Wenn man an dem spart, von dem am meisten vorhanden ist, oder wenn man die knappen Resourcen schont? Aber ich sehe schon, derart einfache Überlegungen überfordern dich schon heillos - wie soll das erst bei einem ensthaften ASM-Projekt mit ein paar 100 KB Codeumfang werden...
Moby A. schrieb: > Der Assembler-Programmierer muß nicht erst Rückschlüsse aus > irgendwelchen Listings ziehen. Er sieht den einzigen, engültigen Code > vor sich und das beste ist: Er hat ihn 100%ig selbst in der Hand! Oh je... Du hast noch nie ASM-Code gesehen, der so richtig aus dem Ruder gelaufen und unpflegbar geworden ist... Du gehst offensichtlich davon aus, dass ASM-Programmierer biller sind, als Computer, die ihnen die Dreckarbeit abnehmen und so die Möglichkeit geben, ihren Hirnschmalz in Dinge zu investieren, die einen höheren Ertrag bringen, als das Maschinencodegepfriemel... Du hast das Zeug zum Pleitier. Moby A. schrieb: > Untauglicher Versuch, von der Qualität eines OS auf die Vor- und > Nachteile von Asm zu schließen. Na ja, was soll man von einem völlig unerfahrenen aber ziemlich großmäulugen Greenhorn anderes erwarten...
Moby A. schrieb: > Er sieht den einzigen, engültigen Code > vor sich Er sieht immer nur einen klitzekleinen Ausschnitt davon... ...es sei denn es ist ein 20zeiler. Und entgültig ist der ASM Code eh fast immer. In den packt nämlich keiner mehr gerne rein, wenn die Oberfläche angetrocknet ist.
Witkatz :. schrieb: > Moby A. schrieb: > Er sieht den einzigen, engültigen Code > vor sich > > Er sieht immer nur einen klitzekleinen Ausschnitt davon... Er sieht was -selbstverantwortet- endgültig ist. Was beim C-Code schließlich rauskommt ist je nachdem was verschiedene Compiler und diverse Optimierungen veranstalten nicht ganz so genau vorherbestimmt, das sieht dann man immer erst im (längeren) Asm-Listing. Uhu U. schrieb: > Oh je... Du hast noch nie ASM-Code gesehen, der so richtig aus dem Ruder > gelaufen und unpflegbar geworden ist... Übung, System und Doku können das verhindern. > Du gehst offensichtlich davon aus, dass ASM-Programmierer biller sind, > als Computer, die ihnen die Dreckarbeit abnehmen und so die Möglichkeit > geben, ihren Hirnschmalz in Dinge zu investieren, die einen höheren > Ertrag bringen, als das Maschinencodegepfriemel... Denkarbeit nimmt keine Programmiersprache der Welt ab. Asm verlangt für's Ergebnis manchmal etwas mehr Aufwand, der bei kleinen 8-Bittern aber überschaubar bleibt. > Na ja, was soll man von einem völlig unerfahrenen aber ziemlich > großmäulugen Greenhorn anderes erwarten... Daraus schließe ich, daß Dir auf meinen Einwand hin nur noch persönliche Angriffe bleiben ;-)
Moby A. schrieb: > Da wurde gar nichts bewiesen. Asm-Code bleibt die Messlatte für alle > anderen Sprachen. Das ist selbst bei Performance-Fragen Quatsch: Ein Assembler-Code ist nie um Grössenordnungen, sondern höchstens (seltenst) um einige zehn Prozente schneller. Die Rechenleistung pro Grösse/Preis/Energie verdoppelt sich bekanntlich ca. alle zwei Jahre. Wenn dein Assembler-Code also (unwahrscheinlich) 20% schneller ist, dann holt dich alleine die technische Entwicklung schon nach 6 Monaten wieder ein.
Uhu U. schrieb: > Was ist "Ressourcen-sparend"? Sparen an Flash, RAM, MHz, zuweilen Peripherie... Motivation ist natürlich nicht der Kauf von etwas was man nicht nutzt sondern maximale Nutzung dessen was man (eine Nummer kleiner) gekauft hat. Mit ein paar Reserven für die Zukunft, versteht sich! > Aber ich sehe schon, derart einfache Überlegungen überfordern dich Ich sehe daß Du überfordert bist. Mit Fragen wie der obigen...
:
Bearbeitet durch User
Moby A. schrieb: > Denkarbeit ... Asm verlangt > für's Ergebnis manchmal etwas mehr Aufwand Jetzt hast du selber ASM mindestens zum Denksport degradiert. Denk dran, du kannst nicht ASM sagen, ohne den Begriff SM zu benutzen...
:
Bearbeitet durch User
Moby A. schrieb: > Sparen an Flash, RAM, MHz, zuweilen Peripherie... In der richtigen Welt ist Hardware nur eine von vielen Resourcen, noch davon eine der günstigeren, und noch dazu mit ständig fallendem Preis. Insgesamt hast du ja recht, das muss man dir lassen. Nämlich für den Fall, dass man mit einer höchstens mässig komplexen Software das absolute Maximum aus einem sehr kleinen Controller herausholen will. Diese Ausgangslage trifft immerhin auf ca. 2% aller Hobbyprojekte und vermutlich mehr als 0.1% der kommerziellen Projekte zu.
Robert L. schrieb: > ASM ist in der THEORIE immer besser In der Praxis durchaus genauso. Sonst würde die Sprache längst nicht mehr verwendet. > ein durchschnittlicher Programmierer, wird es aber nur bis zu einer > gewissen komplexität schaffen, besser zu sein als mit C mit etwas > Aufwand wird er es schaffen diese Grenze nach oben zu verschieben > aber irgendwo ist die Grenze (weiter oben kommt dann nochmal eine, wo > man nicht mehr C sonder z.b. Pascal/c#/java nimmt, aber das wollen wir > jetzt nicht ausarten lassen..) Da hast Du sicher recht. Bei kleinen 8-Bittern würde ich die Grenze aber ziemlich weit oben ansiedeln. > "Argumente" wie "ASM ist einfach" sind natürlich auch recht einfach zu > durchschauen: das ist so wie Schach-Regeln, die kann man auch in 5 > Minuten erklären.. deshalb ist Schach-Spielen noch lange nicht einfach.. Asm ist insofern einfach als daß es nicht vieler Instruktionen und Programmiermittel bedarf. C-Bücher sind da ungleich dicker und warten mit vielen Konstruktionen auf die erstmal sinnvoll genutzt sein wollen wenn sie denn im konkreten Einsatzfall überhaupt simnvoll sind- und in Summe ja trotzdem nicht an das Asm-Ergebnis herankommen. Je umfangreicher die Sache allerdings desto mehr schmilzt der Asm-Vorsprung dahin. Hardwarenahe MSR Apps bis hin zu mittlerer Komplexität auf 8-Bittern sind da aber noch nicht oder nur selten betroffen. > Ich für mich persönlich hab folgende Entscheidung getroffen: > 99% meiner Projekte sind WEIT weg von der Linie, wo ich es es selber im > ASM schreiben könnte... dort verwende ich auch z.b. fertige > "Biliotheken" für 1-wire, crc, 443mhz funk, usw (wo findet man sowas > überhaupt in ASM? fix/fertig?) ...von tcp/ip mit W5100 oder > EncJ-irgnedwas mal ganz abgesehen.. Mach das. Für solche Dinge hat der geübte Asm-Programmierer, sofern benötigt, natürlich "längst fertig". Netzwerkzugriff, TCP/IP sollte man da auslagern- da hab ich persönlich keine Lust zu. > weil ich erstmal ASM so gut lernen müsste So viele Instruktionen sinds ja nicht, das lernst auch Du. Aber Übung macht den Meister- so wie überall! Die Verantwortung für alles hat auch was Gutes: Kein anderer Verantwortlicher für Fehler funkt in die eigene Arbeit.
Moby A. schrieb: > Mach das. Für solche Dinge hat der geübte Asm-Programmierer, sofern > benötigt, natürlich "längst fertig". Netzwerkzugriff, TCP/IP sollte man > da > auslagern- da hab ich persönlich keine Lust zu. Achja? Dort wo richtig Programmierarbeit und Rechenleistung anfällt also dann doch lieber kein Assembler? Ist eigentlich das, was wir dir seit einiger Zeit zu erklären versuchen, aber schön, dass du trotzdem noch selbst drauf kommst. Wenn auch vermutlich eher unbewusst.
Thomas E. schrieb: > Ach komm, das ist doch keine Aussage. Das gilt doch für nahezu alles. > Sowohl Fahrrad fahren als auch Kuchen backen. So eine Antwort wirft doch > nur noch mehr Fragen auf. Klar ist das eine Aussage. Kann aber sein, daß es schon einiger konkreter Erfahrung bedarf, den Nutzen von Können, Vorbereitung und System zu verstehen. Ich kann und brauche hier keinen Asm-Kurs zu geben, möchte aber auf Deine Fragen > Wieviel und welche Vorbereitung? > Was hat das System damit zu tun? > Welche Mühen sind das und wieviel Mühe und Zeit kostet das? soviel antworten: Vorbereitung ist wiederverwendbarer Code. System ist das Programmgrundgerüst mit vorbereitetem Code für Standardaufgaben. Mühe und Zeit sind dann je nach Können recht individuell.
Frank M. schrieb: > Achja... Dein Projekt. Wieviele Interessenten haben Dir mittlerweile ein > Platinchen abgenommen? Siehst Du. Projektferne Rumtrollerei war Dein einziger Beitrag. Wenngleich mit klarer Absicht ;-( > Die schlechte Nachricht ist: Je nach eigenem Können, Vorbereitung und > System ist etwas mehr Mühe und Zeit nötig. > Kannst Du das Wort "etwas" quantifizieren? Je nach eigenem Können, Vorbereitung und System ;-) Das kann weniger, gleich viel oder mehr Mühe sein. In der Regel für den geübten Programmierer und übliche MSR Aufgaben 'etwas' mehr.
Moby A. schrieb: > C-Bücher sind da ungleich dicker und warten > mit vielen Konstruktionen auf die erstmal sinnvoll genutzt sein wollen Aus der Perspektive einet Ameise sieht selbst ein Kuchenkrümel aus wie ein Berg ;-) Nicht böse sein ... jedem hier ist klar dass du diesen Seitenhieb nicht verstehst.
P. M. schrieb: > Moby A. schrieb: > Da wurde gar nichts bewiesen. Asm-Code bleibt die Messlatte für alle > anderen Sprachen. > > Das ist selbst bei Performance-Fragen Quatsch: Ein Assembler-Code ist > nie um Grössenordnungen, sondern höchstens (seltenst) um einige zehn > Prozente schneller. Die Rechenleistung pro Grösse/Preis/Energie > verdoppelt sich bekanntlich ca. alle zwei Jahre. Die Komplexität der Controller steigert sich genauso. Heutige ARMe MCUs sind so nicht mehr sinnvoll in Asm programmierbar. Bei einfachen 8 Bittern (möge es sie noch lange geben und das werden sie auch) gilt das. P. M. schrieb: > Insgesamt hast du ja recht, das muss man dir lassen. Nämlich für den > Fall, dass man mit einer höchstens mässig komplexen Software das > absolute Maximum aus einem sehr kleinen Controller herausholen will. > Diese Ausgangslage trifft immerhin auf ca. 2% aller Hobbyprojekte und > vermutlich mehr als 0.1% der kommerziellen Projekte zu. Die einfachen 8-Bitter zählen zu den (sehr) kleinen Controllern. Damit ist immer noch die Mehrzahl der Hobbyprojekte realisiert- und selbst wenn sie das nicht sind könnten sie es oft, vor allem als Asm-Version. Auch kommerziell spielen 8-Bitter nach wie vor eine bedeutende Rolle. Doch hat C hier aus verschiedensten Gründen die Nase vorn, die, wie man der Studie entnehmen kann, aber nicht in jedem Fall ausschlaggebend sind.
:
Bearbeitet durch User
P. M. schrieb: > Achja? Dort wo richtig Programmierarbeit und Rechenleistung anfällt also > dann doch lieber kein Assembler? Die fällt projektindividuell sonst schon genügend an. Gebratene Tauben fliegen niemand in den Mund. Sagte ich nicht, zur Effizienz gehört, das Rad nicht zweimal zu erfinden? Netzwerksachen, Multimedia, SD Interfaces, Grafik-LCD, all das kann man für MSR Anwendungen (sofern benötigt) locker auslagern. Genau dafür sind mir viele UART Schnittstellen wichtig. Meinen Stolz tangiert das alles nicht. Muß es das?
Moby A. schrieb: > verwende ich auch z.b. fertige >> "Biliotheken" für 1-wire, crc, 443mhz funk, usw (wo findet man sowas >> überhaupt in ASM? fix/fertig?) ...von tcp/ip mit W5100 oder >> EncJ-irgnedwas mal ganz abgesehen.. > > Mach das. Für solche Dinge hat der geübte Asm-Programmierer, sofern > benötigt, natürlich "längst fertig". ernsthaft jetzt? 1-wire schreibst du dir selber? abhören eine 433MHZ-Temp/Feuchte senders auch? oder ist mit "geübte Asm-Programmierer," jemand anderer gemeint;-) und ja ich kenn die Antwort schon: DU brauchst es nicht, aber WENN , dann würdes es in ASM schreiben.. ich hingegen verwende es einfach, mir ist es SCH.. egal wie 1-wire funktioniert, welches Protokoll es hat usw. da haben sich schon ein paar andere darüber den Kopf zerbrochen (denen ich sehr dankbar bin, und denen ich auch gerne mal einen Bug melde) (das ist jetzt nur ein beispiel von vielen..) und man ist NICHT darauf "angewiesen" was die verbrechen, sondern ganz im gegenteil ist der C-Code viel verständlicher/änderbarer, als ein ASM-Listing was in jeder 2. Zeile irgend einen unkommentierten "Trick" verwendet um 2 takte zu sparen.. (zu deinem tcp/ip auf xport auslagern sag ich nichts, damit hast dich ja sowieso disqualifiziert...)
:
Bearbeitet durch User
Robert L. schrieb: > als ein > ASM-Listing was in jeder 2. Zeile irgned eine unkommentierten "trick" > verwendet um 2 takte zu sparen.. Das kannst du ihm nicht vorhalten. Wenn du dir den Code von "seinem Projekt" ansiehst, wirst du sehen, dass solche Tricks da gar nicht drin sind. Sowas machen nur Compiler. mfg.
Robert L. schrieb: > 1-wire schreibst du dir selber? > abhören eine 433MHZ-Temp/Feuchte senders auch? 1-wire noch nicht, aber I2C, SPI, UART und analoge Schnittstellen haben bislang noch jedes Mal gelangt > mir ist es SCH.. egal wie 1-wire > funktioniert, Mir auch ;-) Schnittstellen zu verstehen kann aber (auch Dir) nicht schaden- da holt man ggf. mehr und genau das raus was man selber braucht und keine Library in dieser Form bietet > zu deinem tcp/ip auf xport auslagern sag ich nichts, damit hast dich ja > sowieso disqualifiziert Du Dich mit dieser Bemerkung auch. Frag mal bei Lantronix nach warum sie das Ding produzieren ;-)
Thomas E. schrieb: > Sowas machen nur Compiler. Auf ein besseres Compiler-Ergebnis warte ich nach wie vor ;-)
Moby A. schrieb: > Auf ein besseres Compiler-Ergebnis warte ich nach wie vor Das Programm in C hast du gefälligst selbst zu liefern, um zu beweisen, dass dein Code soviel effizienter ist. Seit wann kommt der Knochen zum Hund? mfg.
Thomas E. schrieb: > Das Programm in C hast du gefälligst selbst zu liefern, um zu beweisen, Ha ha... Das ist ja jetzt mal witzig. Meine These ist ja gerade: Unmöglich, es in C ressourcensparender hinzubekommen. Und das schon bei so einem Winzig-Progrämmchen... Was da erst in größeren für Potentiale stecken müssen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Sparen an Flash, RAM, MHz, zuweilen Peripherie... > Motivation ist natürlich nicht der Kauf von etwas was man nicht nutzt > sondern maximale Nutzung dessen was man (eine Nummer kleiner) gekauft > hat. Mit ein paar Reserven für die Zukunft, versteht sich! Aber nur, wenn der Programmierbimbo nix kostet, der das alles macht... Aber besehen wir die Sache doch mal von der anderen Seite: Wozu eigentlich ein Assembler? Das ist doch was für Weicheier: In den 1970ern kannten die richtig harten Jungs die Maschinencodes auswendig und haben die Programme mit dem Hex-Editor ins RAM geklopft. Ich kannte einen, er hielt in der Rechten die Zigarette und haute mit dem linken Mittelfinger seine Hexcodes in den Speicher. Programmkorrekturen - die waren zuweilen auch nötig - wurden per Rucksack in den Code rein gekloppt. Das geht also auch und nun kommst du Waschlappen daher und behauptest, der ASM sei das einzig Wahre. Der Typ mit dem Mittelfinger hätte sich schief gelacht ud gleichzeitig weiter programmiert... Wie willst du diese immense Resourcenverschleuderung, die ein Assembler darstellt rechtfertigen?
> Und das schon bei > so einem Winzig-Progrämmchen... Was da erst in größeren für Potentiale > stecken müssen ;-) Andersrum ;-) Die Effizienz eines ASM-Programms verhält sich praktisch umgekehrt proportional zur Code-Größe. Das ist auch der Grund, warum ASM in der Regel nicht verwendet wird, wenn die Komplexität und Codegröße ein gewisses Maß übersteigt.
Uhu U. schrieb: > Aber besehen wir die Sache doch mal von der anderen Seite... Wen nochmal wolltest Du damit nun beeindrucken? Ich hoffe Du nimmst das nicht selber ernst...
Jonny O. schrieb: > Und das schon bei so einem Winzig-Progrämmchen... Was da erst in > größeren für Potentiale stecken müssen ;-) > > Andersrum ;-) Nö. Die Potentiale sind in jedem Fall da. Und bis zu einer gewissen Projektgröße lohnt es sich, diese mit Asm auszuschöpfen. So wird ein Schuh draus.
> Nö. Die Potentiale sind in jedem Fall da. > Und bis zu einer gewissen Projektgröße lohnt es sich, diese mit Asm > auszuschöpfen. So wird ein Schuh draus. Ab welcher Codegröße / Komplexität lohnt es sich denn nicht mehr ASM einzusetzen?
> Meine These ist ja gerade: > Unmöglich, es in C ressourcensparender hinzubekommen. Und das schon > bei so einem Winzig-Progrämmchen... Was da erst in größeren für > Potentiale stecken müssen ;-) Ein echter Logiker vor dem Herrn. Wenn also das Programm beliebig klein ist, z.B. nur 1 Befehl, RJMP $-2, dann kann es in C nicht kürzer werden. Mit dem Verfahren kann man auch die völlige Sinnlosigkeit von Vektor-Prozessoren beweisen, denn die sind ja schon beim Berechnen von einer Operation nicht schneller als die "Normalen". Es bestreitet ja keiner, daß ein C-Programm, ich verwende mal kaufmännische Begriffe, Fixkosten > 0 hat. Nur sind die variablen Kosten von ASM größer, z.B. in einfachsten Fall, weil man für eine Integer-Addition mehr Zeilen schreiben muß. Und sobald man den Break-Even-Punkt erreicht hat, gewinnt C. Über die Lage dieses Punktes kann man sicher streiten, über seine Existenz nicht. > Netzwerksachen, Multimedia, SD Interfaces, Grafik-LCD, all das kann > man für MSR Anwendungen (sofern benötigt) locker auslagern. Genau > dafür sind mir viele UART Schnittstellen wichtig. Hurra, wenn ich eine kleine Temperatur-Meßbox bauen will, dann muß ich nur einen 1-Wire-Prozessor mit serieller Schnittstelle und einen SE-Card-Rozesser mit serieller Schnittstelle an einen Mega664 hängen (oder gibt's kleinere mit 2xUART?) und kann dann mit wenigen ASM-Zeilen meinen Temperatur-Logger bauen. Resourcenarm, sogar die mir wichtigste Resource, meine Lebenszeit wird nicht durch das Inkludieren von PeDa-/Fleury-Libs verschwendet. Endlich hab ich das Licht gesehen!
Jonny O. schrieb: > Ab welcher Codegröße / Komplexität lohnt es sich denn nicht mehr ASM > einzusetzen? Für Moby >20 Zeilen. Falls EOR drin vorkommt auch mal weniger ROFL
Moby A. schrieb: > Wen nochmal wolltest Du damit nun beeindrucken? > Ich hoffe Du nimmst das nicht selber ernst... Doch doch, das nehme ich sehr ernst und wenn in deiner bisherigen Pro-ASM-Argumentation nur ein Fünkchen Wahrheit steckt, dann wirst du jetzt einen hex-Editor bauen, den Assembler fortschmeißen und resourcensparend Maschinencode programmieren. Da du das aber offensichtlich nicht willst, versuchst du mit diesem billigen Trick deine Argumentationsschwäche zu vertuschen... In Wirklichkeit nimmst du dein ASM-ist-das-Beste-Geschwätz selbst nicht ernst.
:
Bearbeitet durch User
Wegstaben V. schrieb im Beitrag #4354426: > Man kann Moby's ASM-Fundalismus nicht mit rationalen Argumenten > begegnen. Da könntest Du Recht haben. Aber nicht wegen "Fundalismus" ;-) > Karl Heinz B. schrieb: > Du bist wie ein sturer Esel. Ich schätze Freundlichkeit, Hilfsbereitschaft und Kompetenz von Karl-Heinz sehr. Deswegen darf ihm auch mal sowas durchrutschen ;-)
Moby A. schrieb: > So viele Instruktionen sinds ja nicht, das lernst auch Du. C hat noch weniger Instruktionen, ist eben was für Weicheier und nichts für harte Byte-Cowboys wie dich. Moby A. schrieb: > Unmöglich, es in C ressourcensparender hinzubekommen. Für dich unmöglich, es in C überhaupt hinzubekommen. Ist eben eine andere Welt.
Moby A. schrieb: > Ha ha... Das ist ja jetzt mal witzig. Meine These ist ja gerade: > Unmöglich, es in C ressourcensparender hinzubekommen. Was ist denn daran witzig? Genau das sollst du beweisen, indem du ein C-Programm lieferst, dass größer, langsamer und was weiss ich noch alles ist. Wir werden das dann noch ein bisschen optimieren. Oder glaubst du wirklich, dass einer dein Assembler-Programm auseinanderdröselt, um daraus ein C-Programm zu machen? mfg.
Uhu U. schrieb: > resourcensparend Mach Dir bitte nochmal klar was mit "ressourcensparend" gemeint war. Tipp: Weiter oben hat ichs schonmal erklärt.
Thomas E. schrieb: > Oder glaubst du wirklich, dass einer dein Assembler-Programm > auseinanderdröselt, um daraus ein C-Programm zu machen? Nein. Das vorgegebene Ziel ist schlicht nicht erreichbar. Umso spektakulärer "argumentieren" hier auch manche große Experten ;-)
Moby A. schrieb: > Das vorgegebene Ziel ist schlicht nicht erreichbar Traust du dich nicht, deine Behauptung zu beweisen? Oder gibst du jetzt zu, dass alles, was du du von dir gibst, nur hohles Dummgeschwätz ist? mfg.
:
Bearbeitet durch User
Witkatz :. schrieb: > Für dich unmöglich, es in C überhaupt hinzubekommen. Das muß ich auch nicht wenns in Asm effizienter geht.
Thomas E. schrieb: > hohles Dummgeschwätz ist ... die Behauptung C könnte es besser. Beweise es doch. Aber Du kannst es nicht... Wolltest Du davon ablenken?
Moby A. schrieb: > ... die Behauptung C könnte es besser. Wo behaupte ich, dass C das besser kann? Du behauptest, dass du es in Assembler besser kannst. Also beweise es! mfg.
Warum diskutiert ihr mir diesem Kleingeist? Er will Trollen, nicht lernen!
Moby A. schrieb: > Mach Dir bitte nochmal klar was mit "ressourcensparend" gemeint war. > Tipp: Weiter oben hat ichs schonmal erklärt. Vermutlich meinst du diese "Erklärung": Moby A. schrieb: > Tatsächlich aber verhelfen die vielen Freiheiten des Asm-Programmierens > nicht nur zu effizientem, hochdichten Code ,sondern verleiten zuweilen > auch mit diesem und jenen Trick (z.B. bei Vielfachnutzung derselben > Ressourcen) zu einem unübersichtlichen Programm. Wer sagt, dass man mit Maschinencode im Hex-Format nicht auch "zu einem unübersichtlichen Programm" kommen kann? Und resourcensparender als so ein völlig unnützer Assembler ist es allemal, denn der Programmierbimbo kostet ja nix, während Speicherplatz, Rechenkapazität und Strom doch ziemlich teuer sind. Deine Einsilbigkeit ist verräterisch... Also nochmal die Frage: Wozu eigentlich ein Assembler? wenn es ein Hexeditor auch tut.
:
Bearbeitet durch User
> Wozu eigentlich ein Assembler? > wenn es ein Hexeditor auch tut. Weil dann nicht nur EOR ins Reich der Nebel verschwindet ...
Moby A. schrieb: > Witkatz :. schrieb: >> Für dich unmöglich, es in C überhaupt hinzubekommen. > > Das muß ich auch nicht wenns in Asm effizienter geht. Jaja und bitte an dem Glauben immer schön festhalten.
Thomas E. schrieb: > Du behauptest, dass du es in Assembler besser kannst. Also beweise es! Mit meinem Projektchen ist das schon geschehen... Nun beweise die Behauptung, das bischen Funktionalität mit den ach so effizienten Compilern, die jedem Asm-Programmierer was vormachen im Ressourcenverbrauch zu schlagen! Beachte bitte: Meine Asm-Fähigkeiten würde ich eher durchschnittlich nennen... Was? Dir erschließt sich diese Logik der Beweispflicht nicht? Sorry, dann kann ich Dir von dieser Stelle aus nicht mehr weiterhelfen ;-( Witkatz :. schrieb: > Jaja und bitte an dem Glauben immer schön festhalten. Da verwechselst Du was. Bislang ist es immer noch Wissen ;-)
Uhu U. schrieb: > Deine Einsilbigkeit ist verräterisch... So recht magst Du nicht zur Kenntnis nehmen welche Ressourcen Asm spart. Stimmts? Aber ich verstehe Dich. Auf diesem Feld ist gerade kein Blumentopf zu gewinnen ;-)
Moby A. schrieb: > Mit meinem Projektchen ist das schon geschehen... Nein. Du stellst hier eine Behauptung auf und bist nicht bereit, diese auch zu beweisen. Sondern zeigst hier ein Programm, von dem man nicht einmal weiss, ob es überhaupt funktioniert. Die Funktionalität dieses Progrämmchens in C oder wenigstens in Pseudo-Code darzustellen, kann doch nicht so schwer sein. Moby A. schrieb: > Beachte bitte: Meine Asm-Fähigkeiten würde ich eher durchschnittlich > nennen... Was willst du denn damit sagen? Falls es jemandem gelänge, ein C-Programm zu schreiben, dass in allen Belangen besser ist als dein Assembler-Programm, liegt es nicht an Assembler an sich, sondern nur an deinen bescheidenen Fähigkeiten? Und jemand, der mehr auf dem Kasten hätte als du, würde es sicher hinbekommen? mfg.
:
Bearbeitet durch User
Carl D. schrieb: > Wenn also das Programm beliebig klein ist, z.B. nur 1 Befehl, RJMP $-2, > dann kann es in C nicht kürzer werden. Richtig. Deshalb steckt in diesem Fall das geringste Potential der Verbesserungsmöglichkeiten durch Asm, nämlich Null. Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der Asm-Programmierer dieses Potential ob der schieren Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig die Stunde der Hochsprache. Hast Du das jetzt verstanden? > Endlich hab ich das Licht gesehen! Ich gebe die Hoffnung nicht auf ;-)
Thomas E. schrieb: > Moby A. schrieb: >> Beachte bitte: Meine Asm-Fähigkeiten würde ich eher durchschnittlich >> nennen... > Was willst du denn damit sagen? > Falls es jemandem gelänge, ein C-Programm zu schreiben, dass in allen > Belangen besser ist als dein Assembler-Programm, liegt es nicht an > Assembler an sich, sondern nur an deinen bescheidenen Fähigkeiten? Und > jemand, der mehr auf dem Kasten hätte als du, würde es sicher > hinbekommen? Damit will ich nur sagen, daß die Chancen doch gut stehen sollten, meine durchschnittlichen Assemblerfähigkeiten mit hocheffizientem Compilercode zu schlagen. Gelingt das werde ich hier Assembler nicht mehr als ernstzunehmende C-Konkurrenz hinstellen. Was natürlich nicht ausschließt daß wiederum ein anderer besserer ASMler daherkommt und dies mit Nachweis wieder behauptet ;-)
:
Bearbeitet durch User
Damit eine gute Nacht und vielen Dank an alle Mit-Diskutanten, vom redlich konstruktiven, unpolemischen Peter D. bis hin zum komplett gegenteiligen Gu.F(orentroll). Am Wochenende werde ich dann wieder etwas Zeit finden, die Vorteile und Annehmlichkeiten von Asm mit Euch zu diskutieren. Moby
:
Bearbeitet durch User
Moby A. schrieb: > Auf diesem Feld ist gerade kein Blumentopf zu gewinnen ;-) Deswegen meidest du die Antwort auf meine Frage: Wozu eigentlich ein Assembler? wenn es ein Hexeditor auch tut. wie der Teufel das Weihwasser...
Thomas E. schrieb: > Die Funktionalität dieses Progrämmchens in C oder wenigstens in > Pseudo-Code darzustellen, kann doch nicht so schwer sein. Alles, was man nicht kann, ist schwer...
Moby A. schrieb: > Carl D. schrieb: >> Wenn also das Programm beliebig klein ist, z.B. nur 1 Befehl, RJMP $-2, >> dann kann es in C nicht kürzer werden. > > Richtig. Deshalb steckt in diesem Fall das geringste Potential der > Verbesserungsmöglichkeiten durch Asm, nämlich Null. Oh, da bist du aber einem gewaltigen Irrtum aufgesessen. Natürlich bringt ASM in dem Fall einen, wenn auch kleinen Vorteil gegenüber dem C-Compiler, verschwendet dabei aber zur Übersetzungszeit wieder wahnsinnige Mengen an kostbaren Resourcen. Der Hex-Editor machts noch viel billiger: man braucht keinen Assembler und folglich auch keinen Rechner, auf dem er läuft und er spart den ganzen Speicheroverhead, den das C-Programm
1 | void main(void) { |
2 | loop: goto loop; |
3 | }
|
braucht. Ergo: Du hast keine Ahnung wovon dur hier rumschwadronierst...
Uhu U. schrieb: > void main(void) { > loop: goto loop; > } Das sollte man ausdrucken und dir um die Ohren hauen. mfg.
Robert L. schrieb: > ich hingegen verwende es einfach, mir ist es SCH.. egal wie 1-wire > funktioniert, welches Protokoll es hat usw. da haben sich schon ein paar > andere darüber den Kopf zerbrochen (denen ich sehr dankbar bin, und > denen ich auch gerne mal einen Bug melde) (das ist jetzt nur ein > beispiel von vielen..) Oh, kommt jetzt die Arduino-Fraktion auch noch in den Thread? ;-)
Moby A. schrieb: > Uhu U. schrieb: >> Was ist denn die "sinnvollste Lösung"? > > Die einfachste und Ressourcen-sparendste. Ist die Lebenszeit des Programmierers keine Ressource? Mir scheint dies die wertvollste Ressource überhaupt zu sein.
Uhu U. schrieb: > Wieso das denn? Weil "goto" absolut verpönt ist. Aber wenn es unbedingt sein muss, dann:
1 | comefrom: goto comefrom; |
Ausserdem heisst es
1 | int main(void) |
mfg.
Thomas E. schrieb: > Weil "goto" absolut verpönt ist. Ach du lieber Himmel... Das erzählt man den kleinen Buben, um sie zu disziplinieren. Was glaubst du wohl, warum Dennis Ritchie in den frühen 1970ern das goto in C eingebaut und keiner es seither wieder entfernt hat? Nicht um irgend welche Deppen zu verführen, Unsinn damit zu machen, sondern weil es Fälle gibt, in denen es von Nutzen ist und der Klarheit des Programmablaufs dient. > Aber wenn es unbedingt sein muss, dann: > comefrom: goto comefrom; Was soll das denn? > Ausserdem heisst es int main(void) Nö, das heißt int main(int argc, char *argv[]) aber C ist da tolerant und du musst noch viel, viel lernen...
Hier wurde bereits bewiesen, dass C sogar speicherplatzsparender als Mobys Assembler sein kann: Beitrag "Re: C versus Assembler->Performance" Zusätzlich zitiere ich aus dem dort verlinkten Thread: Moby AVR schrieb: > Hans schrieb: >> Wenn du nur 1:1 "übersetztst", dann wird C niemal kleiner als dein ASM >> code werden. > Kleiner? Wie soll denn das passieren? Da muss sich ein Asm-Programmierer > aber schon selten dämlich anstellen :-) Hier zu lesen: Beitrag "Re: C versus Assembler->Performance" Die jetzige "Diskussion" ist damit hinfällig und Moby darf uns nun endlich zeigen, wie man das kleine Progrämmchen mit handoptimiertem Assembler ressourcensparender niederschreiben kann. Uhu U. schrieb: > Nö, das heißt int main(int argc, char *argv[]) Oder eben auch
1 | int main(void){ /* ... */ } |
Dies sind die beiden Varianten, die im Standard definiert sind.
Edit: "or in some other implementation-defined manner."
> aber C ist da tolerant
Wenn, dann ist der Compiler tolerant.
:
Bearbeitet durch User
Moby A. schrieb: > Mit meinem Projektchen Hey, du erkennst also das dein Projektchen ein Projektchen ist :-) Moby A. schrieb: > Meine Asm-Fähigkeiten > würde ich eher durchschnittlich nennen... Ich würde das eher unterdurchschnittlich nennen (--> Micky Maus). Moby A. schrieb: > Sorry, > dann kann ich Dir von dieser Stelle aus nicht mehr weiterhelfen ;-( Dir ist schon lange nicht mehr zu helfen.
Guido B. schrieb: > Robert L. schrieb: >> ich hingegen verwende es einfach, mir ist es SCH.. egal wie 1-wire >> funktioniert, welches Protokoll es hat usw. da haben sich schon ein paar >> andere darüber den Kopf zerbrochen (denen ich sehr dankbar bin, und >> denen ich auch gerne mal einen Bug melde) (das ist jetzt nur ein >> beispiel von vielen..) > > Oh, kommt jetzt die Arduino-Fraktion auch noch in den Thread? ;-) ja, mir geht es eben ums Ergebnis, nicht um den Weg dort hin ;-) normalerweise, wobei ich gestern eclipse+stm32 (mit qemu und auch mit einem st-link + kaum 2€stück großem echtem board) ausprobiert hab.. einfach aus Spaß: wenn man seine Sachen dann auch debuggen kann,ist schon was feines... das Ding hat ja soviel "Moby-Resource" (aka Flash) dass man garnicht weiß was man alles tun soll damit... und ist um welten kleier als alles was man (ich) selber herstellen könnte... wenn ich es könnte.. auch qemu find ich genial, kann man an avr auch simulieren?? ;-) stellt sich echt die frage warum man noch mit 8-bit herumeiert ;-)
:
Bearbeitet durch User
Gu. F. schrieb: > Moby A. schrieb: >> Sorry, >> dann kann ich Dir von dieser Stelle aus nicht mehr weiterhelfen ;-( > Dir ist schon lange nicht mehr zu helfen. Man kann von seiner Meinung halten was man möchte: aber Moby bleibt bei seinen Ausführungen immer höflich. Das sollte auch für die Mitdiskutanten gelten. Das hier ist auch "sein" Thread, also kann er hier auch seine Thesen vertreten wie er möchte. Wir Mods haben nur etwas degegen, wenn er mit seiner Asm/AVR-Affinität andere Threads kapert. Man muss bei allen Meinungsverschiedenheiten auch bedenken, dass Moby das als Hobby betreibt, während die meisten hier wohl auch beruflich coden. Beruflich stellt sich die Frage ASM/Hochsprache kaum noch, weil Arbeitszeit und Portabilität erheblich kostbarer als Speicherplatz sind, wenn man damit Geld verdienen muss. Ich habe ja früher durchaus auch mit reinem Assembler gearbeitet (8048, eigenes BIOS für einen 80286-PC, Bordcomputer mit einem AVR 8535), allerdings war bei etwa 4-8k Codegröße dann Schluß und ich bin auf C umgestiegen. Bei den Projektgrößen und den Anforderungen, wie sie jetzt bei uns vorherrschen, wäre Programmierung in Assembler einfach undenkbar. Moby A. schrieb: > Richtig. Deshalb steckt in diesem Fall das geringste Potential der > Verbesserungsmöglichkeiten durch Asm, nämlich Null. > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der > Asm-Programmierer dieses Potential ob der schieren > Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig > die Stunde der Hochsprache. Und da hat Moby einfach mal Recht. Je mehr Code man hat, desto eher steigen für den Assembler-Programmierer die Chancen, Optimierungsmöglichkeiten zu übersehen. Ein Compiler tut das nicht. Der verliert auch nicht den Überblick. Schaut man sich schon bei kleinen Programmen (4k) an, wo ein Compiler Dinge findet, die er doppelt nutzen kann, dann ist das schon faszinierend (und teilweise unfassbar). Da muss man einfach den Hut vor den Compilerjungs ziehen. Ich würde also aus der Praxis heraus behaupten, dass ab einer gewissen Codegröße der Compiler den Assemblerprogrammierer auch recht locker in der Codegröße schlägt. Ich bin allerdings auch der Meinung, dass es für einen angehenden Programmierer gut ist, wenn er ein paar kleine Projekte in Assembler schreibt. Das hilft dabei, später effizienten Code in C zu schreiben und auch Fehler schneller zu lokalisieren, weil man zumindest erahnen kann, was auf Prozessorebene geschieht.
Uhu U. schrieb: > Nicht um irgend welche Deppen zu verführen, Unsinn damit zu machen, > sondern weil es Fälle gibt, in denen es von Nutzen ist und der Klarheit > des Programmablaufs dient. goto ist die Mutter allen Spaghetticodes. mfg.
Thomas E. schrieb: > goto ist die Mutter allen Spaghetticodes. wie wir wissen, braucht es aber auch noch nen Vater, der mit der Mutter schmutzige Sachen anstellt. So ganz allein, ist die Mutter anständig und kann nützlich sein ;)
Thomas E. schrieb: > Uhu U. schrieb: >> Nicht um irgend welche Deppen zu verführen, Unsinn damit zu machen, >> sondern weil es Fälle gibt, in denen es von Nutzen ist und der Klarheit >> des Programmablaufs dient. > > goto ist die Mutter allen Spaghetticodes. Ich selbst habe in den letzten 30 Jahren C-Programmierung niemals ein goto gebraucht, trotzdem würde ich das nicht so allgemein formulieren. Es gibt durchaus in speziellen Situationen Gründe, ein goto zu verwenden. Zum Beispiel im Linux-Kernel, um von einem Ausnahmezustand einen wohldefinierten "Normalzustand" wieder zu erreichen. Trotzdem würde ich niemals behaupten, dass der Linux-Kernel-Code Spaghetticode wäre.
Frank M. schrieb: > Trotzdem würde ich niemals behaupten, dass der Linux-Kernel-Code > Spaghetticode wäre. Ausnahmen bestätigen die Regel. Aber jetzt lasst uns diesen Thread nicht kapern. Das ist ein ASM-Thread von Moby. Er bekommt auch was auf den Deckel, wenn er in anderen Threads seine ASM-Ansichten verbreitet. mfg.
Chris D. schrieb: > Ich würde also aus der Praxis heraus behaupten, dass ab einer gewissen > Codegröße der Compiler den Assemblerprogrammierer auch recht locker in > der Codegröße schlägt. Das sehe ich absolut genauso. Das Problem ist aber, dass Moby diese kritische Codegrenze noch nie erreicht hat - da er eher kleinere Progrämmchen schreibt. Leider verallgemeinert er aber dermaßen seinen erreichten Zustand, dass es so rüberkommt, als wäre Assembler generell das Mittel der Wahl und alles größer als ATTiny Teufelswerk, was man nicht braucht. Kurzum: Er schließt von seinem Mikrokosmos auf sämtliche µC-Anwendungen, prahlt damit ziemlich großkotzig rum und degradiert jeden C-Programmierer zu einem nichtsnutzigen Wesen, was die Welt nicht braucht. P.S. Deine Meinung, Moby bliebe bei seinen Ausführungen immer höflich, kann ich leider nicht teilen. Er wird zwar nicht verbal ausfallend, jedoch macht er das subtiler. Zum Beispiel hat er Karl Heinz (buchegg) ziemlich kaltschnäuzig (d.h. respektlos) gegen die Wand fahren lassen, so dass ich zum ersten Mal erleben konnte, wie Karl Heinz die Hutschnur platzte. Das kommt nicht von ungefähr. Respekt zeigen ist nicht gerade Mobys Stärke. Die provozierend gesetzten zwinkernden Smileys, die er bei Widerspruch bewusst platziert, führen dazu, dass seine davor platzierte Meinung ziemlich herablassend und schon gar nicht höflich rüberkommt. Fazit: Moby hats drauf, bewusst zu provozieren. Das macht er aber nicht offen, sondern sehr verdeckt.
:
Bearbeitet durch Moderator
Thomas E. schrieb: > goto ist die Mutter allen Spaghetticodes. In der Hand von Stümpern mag das stimmen. Profis wissen, wozu es gut ist und wozu nicht - mit einem Messer kann man auch nicht nur Schlimmes anstellen... Ein Beispiel ist das Verlassen einer inneren Schleife. Man kann die ganze geschachtelte Schleife als Funktion ausführen und mit return in einer inneren herausspringen, oder man lässt die Funktion weg und springt sauber hinter das Ende der äußeren Schleife. Ansonsten gibt es wenig strukturerhaltende Anwendungen für goto. Dogmen sind mit Informatik jedenfalls nicht kompatibel...
Frank M. schrieb: > Deine Meinung, Moby bliebe bei seinen Ausführungen immer höflich, kann > ich leider nicht teilen. Einmal in die Enge getrieben, schlägt er wild um sich. Siehe ganz oben auf dieser Seite, wo er mich des „Märchenerzählers“ bezichtigt, um kurz danach selbst zu behaupten, die Peripherals eines Xmega seien eigentlich die gleichen wie bei einem MegaAVR, nur „die paar Steuerbits anders verteilt“. Argumente akzeptiert er nur, wenn sie in sein Weltbild passen, alles andere wird entweder ignoriert oder verdreht oder es wird eben einfach mal behauptet, das sei jetzt gar nicht so. Aber es ist korrekt, verbal ausfallend wird er nicht. Dann würde ja auch riskieren, dass die entsprechenden Beiträge gelöscht werden.
be s. schrieb: > Uhu U. schrieb: >> Nö, das heißt int main(int argc, char *argv[]) > Oder eben auch > int main(void){ /* ... */ } > Dies sind die beiden Varianten, die im Standard definiert sind. > Edit: "or in some other implementation-defined manner." Gilt nur im Hosted Environment. Sonst: > In a freestanding environment (in which C program execution may take > place without any benefit of an operating system), the name and type > of the function called at program startup are implementation-defined. Und unabhängig vom Ergebnis-Typ von main(): praktisch jeder Embedded-Compiler kann mit den passenden Optionen den Startup-Code auf wenige Bytes eindampfen, wenn man die entsprechenden Features nicht braucht. Der Unterschied ist halt, dass man in Assembler gleich bei Null anfängt und nichts mehr explizit zu entfernen braucht.
Jörg W. schrieb: > Aber es ist korrekt, verbal ausfallend wird er nicht. Dann würde ja > auch riskieren, dass die entsprechenden Beiträge gelöscht werden. Naja, der andere wohlbekannte Asm-Apologet, der hier als Gast nicht mitdiskutieren darf, ist, was die verbalen Ausfälle angeht, genau das Gegenteil von dem. Und die werden auch nur in Ausnahmefällen gelöscht. Im Gegensatz zu Moby, weiss der aber auch genau, wovon er redet. mfg.
Thomas E. schrieb: > goto ist die Mutter allen Spaghetticodes. ... und in Assembler kaum wegzudenken: Alle BRxx-Varianten, alle JMP-Varianten ...
Moby A. schrieb: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt Das ist schlicht und einfach extremer Unsinn. Ab einer gewissen Grösse hat der Mensch unmöglich den Überblick, um weitgreifend zu optimieren. Der Compiler hingegen kann das. Deine hochgelobte Optimierung auf Assembler-Ebene ist nämlich nicht etwa eine hohe Kunst, wie du es zu verkaufen versuchst, sondern letztlich relativ stupides Handwerk. Passt aber zum Horizont mit Radius null, den du hier zeigst.
Um es zusammenzufassen: Wir haben dir schon lange zugestimmt, dass man mit Assembler auf sehr kleinen Mikrocontrollern bei kleinen Projekten mit wenig Zusatzaufwand etwas besser sein kann als mit C. Das ist dein Anwendungsfall. Du versuchst aber bei jeder Gelegenheit, diese Aussage auch für grössere Projekte zu verallgemeinern, was Quatsch ist. Wenn man diesen Standpunkt dann angreift, dann argumentierst du wiederum mit den Miniprojekten. Dort stimmen wir dir ja wie gesagt zu. Aber nicht bei grösseren Projekten, wofür du auch nie Argumente bringst, sondern eben immer auf die Miniprojekte ausweichst.
Chris D. schrieb: > Moby A. schrieb: >> Richtig. Deshalb steckt in diesem Fall das geringste Potential der >> Verbesserungsmöglichkeiten durch Asm, nämlich Null. >> Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das >> Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße >> übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der >> Asm-Programmierer dieses Potential ob der schieren >> Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig >> die Stunde der Hochsprache. > > Und da hat Moby einfach mal Recht. > > Je mehr Code man hat, desto eher steigen für den Assembler-Programmierer > die Chancen, Optimierungsmöglichkeiten zu übersehen. Ein Compiler tut > das nicht. Der verliert auch nicht den Überblick. Schaut man sich schon > bei kleinen Programmen (4k) an, wo ein Compiler Dinge findet, die er > doppelt nutzen kann, dann ist das schon faszinierend (und teilweise > unfassbar). Da muss man einfach den Hut vor den Compilerjungs ziehen. Es ist doch so, dass auf der einen Seite Moby ständig den Vergleich zwischen Assembler und C für irgendwelche Miniprogramme sucht. Auf der anderen Seite sagen die C-Verfechter, dass C seine Vorteile erst ab einer gewissen Codegröße ausspielt. Ich sehe da eigentlich gar keinen Konflikt. Auch Moby ist ja nach eigenen Worten der Ansicht, dass für größere Programme Hochsprachen durchaus von Vorteil sind, und bei Dingen wie dem TCP/IP-Stack geht er sogar noch einen Schritt weiter und kauft sich dafür für fast den 100fachen Preis eines ATtiy13 gleich ein komplettes Hardwaremodul. Die Frage (an der sich wohl hauptsächlich der Streit entzündet) ist nur: Jonny O. schrieb: > Ab welcher Codegröße / Komplexität lohnt es sich denn nicht mehr ASM > einzusetzen? Mobys Antwort darauf könnte die längst festgefahrene Diskussion evtl. wieder etwas weiterbringen: Nennt er als Grenze bspw. 200 Byte, würde ich (und wahrscheinlich viele andere auch) das sofort akzeptieren und die Diskussion als abgeschlossen betrachten. Mein längstes Programm in AVR-Assembler war etwa 512 Byte groß (ein halbvoller ATtiny15), und für dessen Entwicklung brauchte ich einschließlich Fehlersuche und nachträglicher Ergänzungen etwa 2 Stunden. Den größte Anteil daran hatte nicht das Programmieren selber, sondern das Nachschlagen im Datenblatt nach der Verwendung von ADC, Timer, EEPROM usw. auf dem ATtiny15, den ich vorher noch nicht im Einsatz hatte. Unter diesem Gesichtspunkt wäre ich in C auch nicht arg viel schneller gewesen, so dass die 2 Stunden für mich akzeptabel sind. Ich hatte also bei 512 Byte Codegröße durch die Assemblerprogrammierung kaum Nachteile (allerdings auch keine Vorteile). Nennt Moby hingegen einen deutlich höheren Wert, bspw. 4 KiByte, würden diesen die meisten C-Programmierer (mich eingeschlossen) als zu hoch ansehen. Um zu zeigen, dass diese Grenze dennoch richtig ist, müsste Moby in der Lage sein, in der gleichen Entwicklungszeit und mit gleicher Speicher- und Laufzeiteffizienz ein 4-KiByte-Assemblerprogramm zu schreiben wie ein C-Programmierer ein entsprechendes C-Programm. Und da habe ich so meine Zweifel, ob er das schafft. Einen in diese Richtung abzielenden "Wettbewerb", den ihm Karl Heinz Buchegger in einem anderen Thread anbot, hat er jedenfalls abgelehnt.
Xalu X.: > Auch Moby ist ja nach eigenen Worten der Ansicht, dass für größere Programme > Hochsprachen durchaus von Vorteil sind wirklich? Moby: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt. Das ist das, auf dem er immer rum kaut. Es gibt zwei Möglichkeiten: entweder will er uns alle verarschen, dann macht er das wirklich gut, oder er ist genau so wie er sich gibt. Ich habe mir angewöhnt jemandem, der sich doof stellt, zu glauben. Das deckt dann beide Fälle gleichzeitig ab. Chris D.: > Das hier ist auch "sein" Thread, also kann er hier auch seine Thesen > vertreten wie er möchte. Wir Mods haben nur etwas dagegen, wenn er mit > seiner Asm/AVR-Affinität andere Threads kapert. Ersteres muß man zugeben, es ist sein Thread, aber nur wenn er hier Antworten bekommt, bleibt er auch hier. Beim Zweiten kann ich leider nicht zustimmen, denn genau das fehlt, wenn er wieder einen Thread mit C/C++-Themen mit seinem Assembler- Fundamentalismus flutet. Damit hat er sich hier seinen Ruf kreiert.
:
Bearbeitet durch User
Yalu X. schrieb: > Nennt er als Grenze bspw. 200 Byte, würde ich (und wahrscheinlich viele > andere auch) das sofort akzeptieren und die Diskussion als abgeschlossen > betrachten. Bereits hier habe ich Zweifel. Ein so kurzes Programm, das primär aus dem Setzen von Konfigurationsbits besteht, kann selbst ein simpel gestrickter C-Compiler fast 1:1 in Assembler umwandeln. Schwer vorstellbar, wo überhaupt Optimierungspotential herausschauen soll.
Carl D. schrieb: > Beim Zweiten kann ich leider nicht zustimmen Wenn dir das auffällt: Beitrag melden. Mir ist in letzter Zeit kein entsprechender Thread mehr zu Gesicht bekommen, bei dem wir nicht konsequent gelöscht haben, aber wir sehen natürlich auch nicht jeden Thread an.
Carl D. schrieb: > Xalu X.: >> Auch Moby ist ja nach eigenen Worten der Ansicht, dass für größere Programme >> Hochsprachen durchaus von Vorteil sind > > wirklich? Ja, bspw. hier: Moby A. schrieb: > Der Hammer hat seine Berechtigung wie der Schraubenzieher auch. > Problematisch wirds, wenn das eine Werkzeug vorgibt, die Arbeit des > anderen effizienter tun zu können. 'Arbeit' steht dabei für das > Zielgebiet: Asm für einfache MSR, Hochsprache für große, rechen- und > datenintensive Anwendungen. Moby A. schrieb: >> Und bis du bei einem solchen Betriebssystem die Handoptimierung des >> Codes fertig hast ist die dazu empfohlene Strategie aufgrund neuer >> Implementierungs-Architekturen schon 2 Generationen weiter und du kannst >> von vorne anfangen. > > In der Praxis hast Du angesichts dieser Entwicklung recht: Sich auf eine > übergeordnete (Hochsprachen-)Ebene zu begeben scheint geboten. Moby A. schrieb: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der > Asm-Programmierer dieses Potential ob der schieren > Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig > die Stunde der Hochsprache. Allerdings sind diese Programme aus seiner Sicht keine "typischen 8-Bit-Anwendungen" mehr und liegen somit außerhalb seines Horizonts. Aber statt die komplexeren Programmteile in einer Hochsprache zu programmieren oder als Hochsprachenquellcode irgendwo herunterzuladen (was im Falle des TCP/IP-Stack durchaus möglich wäre), kauft er sich für teures Geld lieber ein fertig programmiertes Hardwaremodul (den XPort Pro). P. M. schrieb: > Yalu X. schrieb: >> Nennt er als Grenze bspw. 200 Byte, würde ich (und wahrscheinlich viele >> andere auch) das sofort akzeptieren und die Diskussion als abgeschlossen >> betrachten. > > Bereits hier habe ich Zweifel. Ein so kurzes Programm, das primär aus > dem Setzen von Konfigurationsbits besteht, kann selbst ein simpel > gestrickter C-Compiler fast 1:1 in Assembler umwandeln. Vollkommen richtig. Hinzu kommt allerdings noch der Code für die BSS- und Stack-Initialisierung, der bei solchen Miniprogrammen oft gar nicht erforderlich ist, sich aber trotzdem in der Codegröße niederschlägt. Natürlich stören diese zusätzlichen ca. 20 Byte außer Moby niemanden, da selbst der kleinste AVR deutlich mehr als 200 Byte Flash hat. Mobys Argument, warum dieser Overhead doch stört: Irgendwann möchte man das Miniprogramm vielleicht erweitern, und dann könnten die 20 Byte doch wertvoll sein. Allerdings kratzt der Code in diesem Fall schon etwa 1 KiByte-Grenze des ATtiny13 und ist damit groß genug, dass der C-Compiler mit hoher Wahrscheinlichkeit an anderer Stelle seine Stärken ausspielen kann.
@Xalu: Du gibst aber zu, das in den aufgezählten Moby-Schnipseln sowohl die eine als auch die andere Richtung als die einzig Wahre bezeichnet wird. O-Ton: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender > Programmgröße > übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der > Asm-Programmierer dieses Potential ob der schieren > Programmgröße/komplexität nicht mehr heben kann- dann schlägt Also: - der Vorteil von ASM beginnt bei der ersten Zeile - er wächst mit der Programmgröße - es gibt keine Obergrenze für ASM Alles klar, oder? Ich gebe zu, er kann geschickt Andere manipulieren. Solange man sich einlullen läst.
das nach
>Aber ...
ignorieren wir?
wie ich oben schon mal geschreiben habe..
ist wie mit Schach:
ich kann die Regeln, theoretisch könnte ich also gegen jeden
Schachcomputer gewinnen..
> das nach >>Aber ... > ignorieren wir? Dann hätte ich einfach weggelassen. Wollte ich aber nicht, denn erst am Stück zeigt sich, daß er in 2 aufeinanderfolgende Sätzen von der "unbegrenzten Begrenztheit" schreibt.
PIC10F200: 375B Flash, 16B Ram Ich wäre ja bereit auf ASM zu wechseln, aber der C Compiler weigert sich einfach den Code so aufzublähen das ich das muß. Ich habe auch überhaupt keinen Ergeiz statt 40% freier Recourcen mittels ASM auf 45% zu kommen. Den gleichen Codeschnipsel kann ich fast unverändert auch für AVR, XMEGA, STM8 und diverse PICs verwenden ohne mir nur ein mal die Frage stellen zu müssen wie der entsprechende ASM Befehlssatz aussieht und welche Register mir zur Verfügung stehen. Die 'reine ASM Lehre' habe ich mir das letze mal bei 8085 & 8051 gegeben. Das ging oft garnicht anders um ein definiertes Timing zu bekommen. Ausserdem konnte ich mir die sündhaft teuren und nicht sehr guten C-Kompiler nicht leisten. Das ist aber 25 Jahre her. Für 30Cent bekomme ich heute einen STM8S003 mit 16 MHz, 8KB flash, 1K Ram der vollgestopft ist mit jeder Menge Hardware die exotische Softwareverenkungen unnötig macht. Ist ja toll wenn man so auf ASM abgeht, mir ist das aber zu fixiert auf eine Controller Familie.
Yalu X. schrieb: > Es ist doch so, dass auf der einen Seite Moby ständig den Vergleich > zwischen Assembler und C für irgendwelche Miniprogramme sucht. Auf der > anderen Seite sagen die C-Verfechter, dass C seine Vorteile erst ab > einer gewissen Codegröße ausspielt. > > Ich sehe da eigentlich gar keinen Konflikt. Bis hierhin ist da ja auch kein Konflikt mehr... > Auch Moby ist ja nach eigenen Worten der Ansicht, dass für größere > Programme Hochsprachen durchaus von Vorteil sind, Das ist allerdings eine ganz neue Aussage von ihm. Zuvor hat er etwas ganz anderes behauptet: Hochsprachenentwicklern ginge es nur um Verschleierung, Verkomplizierung und Ressourcenerschwendung, und so ein Compiler würde nur "unzulängliche grobe C-Bausteine" zusammensetzen. Ein paar Zitate dazu: "Weil eine Hochsprache ein Programm quasi aus Fertigbausteinen zusammensetzt und die Aufgabenstellung damit nur unter Verlusten an Platz und Performance gegenüber der feiner an die Gegebenheiten anpassbaren Asm-Programmierung lösen kann." "Ist nur blöd, wenn der Fehler am System liegt- zur eigentlichen zu entwickelnden Programmlogik immer noch zusätzlich die Suche nach dem besten der groben C-Bausteine samt passender Verkettungsausdrücke hinzukommt." "Die optimale Ausnutzung der Hardware ist aber gerade das was den Vorteil von Asm ausmacht [...] alles hat irgendwo seinen Preis. Der bedeutet im Fall der (bequemeren?) Hochsprachenverwendung immer Platz-und Performancenachteile. Ganz gleich, wie gut ein Compiler sein mag." "Nun, Hochsprachenkonzepte sind allesamt ersponnen." "Ich sag Dir mal was man wirklich nur muss:Die paar Asm-Instructions und seinen Controller richtig kennen- das reicht für ewig." (sic!) "Du nimmst natürlich einen 32-Bit ARM! Dann hast Du Spielraum genug für ineffizientes Programmieren." "Mein Gott, ich verstehs ja. Da hat sich jemand eine großartige Entwicklungsumgebung aufgebaut, jahrelang mit 1000 Seiten Schmökern gepaukt, womöglich studiert und muss sich nun von einem dahergelaufenen Bastler sagen lassen, daß sich eine große Abzahl an typischen Programmieraufgaben mit ein paar Asm-Wortfetzen erschlagen lassen." Insofern sollten wir Moby zu seinem Erkenntnisgewinn beglückwünschen, daß er nach vielen Monaten und mehreren ewig langen Threads endlich eingesehen hat: "Aber irgendwann kommt der Punkt, an dem der Asm-Programmierer dieses Potential ob der schieren Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig die Stunde der Hochsprache." Das ist genau das, was ihm zwei Dutzend sehr erfahrene professionelle Entwickler immer wieder mal mit mehr, mal mit weniger Geduld zu erklären versucht haben.
:
Bearbeitet durch User
> Insofern sollten wir Moby zu seinem Erkenntnisgewinn beglückwünschen
Abwarten bis er wieder auftaucht!
:
Bearbeitet durch User
Diese Offenbarung ist tatsächlich neu und bisher weigerte er sich das zu akzeptieren. Mein grösseres Problem ist aber das er meint ein einfacher AVR mit simplen ASM reicht für alles aus. Dabei sagt er selbst, dass er für gewisse Funktionen ein externes Modul anflanscht und dieses dann anspricht. Das auf besagtem Modul ein Cortex-M sitzt und in C oder gar C++ programmiert wurde, hat aber natürlich nichts mit seiner Argumentation zu tun. In einer Parallelwelt würde er argumentieren man brauche doch gar nicht so etwas ineffizientes und kompliziertes wie ein Auto, danach ins Taxi steigen und uns beim wegfahren auslachen.
:
Bearbeitet durch User
Operator S. schrieb: > Mein grösseres Problem ist aber das er meint... Und bestimmt nicht nur deins, denn das ist die Kernaussage dieses Threads ;-) Warum lassen sich professionelle Softwareentwickler von einem Kleinbastler so leicht provozieren? Passt er vielleicht in deren Beuteschema und weckt den Jagdinstinkt? Carl D. schrieb: > Abwarten bis er wieder auftaucht! Die Jagd ist voll im Gange? Jörg W. schrieb: > Einmal in die Enge getrieben, schlägt er wild um sich. Ujujuj, das arme Bastlerchen ;-)
:
Bearbeitet durch User
Witkatz :. schrieb: > Warum lassen sich professionelle Softwareentwickler von einem > Kleinbastler so leicht provozieren? Gut das war falsch formuliert. Insgeheim freue ich mich über jeden seiner Threads, sowohl dieser, wie auch jener des Sensorboards. Es erheitert meinen Tag und befreit die Gedanken, um danach weiter zu arbeiten. Dies meine ich übrigens nicht im ironischen Sinne, sondern ist ernst gemeint. Nun, warum man sich darüber aufregt? Das ist vermutlich gegenstand einiger Doktorarbeiten in der Psychologie. Denn es scheint bereits erwiesen, dass Ings und Infs sich übermässig enervieren können, siehe dazu auch verschiedene Threads im Forum (Warum hier alle so unhöflich sind) oder auch mal einen Artikel über Linus Torvalds sozialverhalten im Internet. Ich muss zugeben das ich mich auch manchmal provozieren lasse. Wichtig ist aber das man das erkennt und im nachhinein darüber lachen kann, oder gar sich Entschuldigen wenns denn ein eigener Fehler war. Im besten Fall ärgert man sich schon im vorherein nicht, aber ohne das Warum zu kennen, wirds schwierig. Ausserdem wäre so manch amüsanter Thread so gar nie entstanden ;-)
Operator S. schrieb: > Diese Offenbarung ist tatsächlich neu und bisher weigerte er sich das zu > akzeptieren. Ganz neu ist sie nicht, sie trat auch schon in früheren Threads zutage. > Mein grösseres Problem ist aber das er meint ein einfacher AVR mit > simplen ASM reicht für alles aus. Genau das ist der Punkt. Und um von seiner These trotz schlagkräftiger Argumente anderer keinen Millimeter abrücken zu müssen, schränkt er einfach das "alles" immer mehr ein. Beispiele: In einem anderen Thread wurde das Thema Arithmetik mit mehr als 8 Bit hervorgebracht, die in C definitiv leichter handzuhaben ist als in AVR-Assembler. Mobys Gegenargument (sinngemäß): Programme, die Berechnungen ausführen, die komplizierter sind als eine 8-Bit-Addition, sind keine typischen 8-Bit-Anwendungen. Sie sind damit für Moby nicht relevant und außerhalb seines Betrachtungsbereichs. In diesem Thread ging es um den TCP/IP-Stack. Der wird von Moby einfach in ein externes Modul ausgelagert und ist damit ebenfalls out-of-scope. Am Schluß besteht "alles" nur noch aus ca. 1% aller µC-Anwendungen, nämlich diejenigen, bei denen Daten von einer einfachen Schnittstelle (bspw. Digital-I/O oder ADC) gelesen, auf einfache Weise verarbeitet (bspw. Entprellung oder Mittelwertbildung) und auf einer anderen einfachen Schnittstelle (bspw. UART) wieder ausgegeben werden. Diese (und nur diese) Aufgaben lassen sich in Assembler tatsächlich fast genauso leicht realisieren wie in C. Dinge wie die Linearisierung von Sensordaten, ein PID-Regler, ein Kalman-Filter oder dergleichen, können i.Allg. ebenfalls sehr gut mit 8-Bit-Controllern wie den AVRs realisiert werden und sind in C immer noch ziemlich leicht zu implementieren. Ihre Programmierung in Assembler erfordert aber deutlich größere Anstrengungen. Anders als für den Rest der Welt sind das für Moby aber keine typischen 8-Bit-Anwendungen. De facto ist es so, dass alles, was in C leichter zu realisieren ist als in AVR-Assembler, für Moby keine typischen 8-Bit-Anwendungen und damit nicht Gegenstand der Diskussion sind. Als typische 8-Bit-Anwendungen und damit als Diskussionsgegenstand bleiben folglich nur die so genannten "Micky-Maus-Progrämmchen" übrig. Trotzdem würde mich nach wie vor interessieren, wo Moby größenmäßig die Grenze der Micky-Maus- ... äh ... der typischen 8-Bit-Anwendungen sieht.
Yalu X. schrieb: > Trotzdem würde mich nach wie vor interessieren, wo Moby größenmäßig die > Grenze der Micky-Maus- ... äh ... der typischen 8-Bit-Anwendungen sieht. ca. 25% der Kapazität eines Attiny13. Damit noch Platz für Erweiterungen bleibt. Nein, ich denke, die Grenze wird erreicht sein, wenn die 32 von ihm fest belegten Register nicht mehr ausreichen. mfg.
Yalu X. schrieb: > De facto ist es so, dass alles, was in C leichter zu realisieren ist als > in AVR-Assembler, für Moby keine typischen 8-Bit-Anwendungen und damit > nicht Gegenstand der Diskussion sind. Das ist doch ziemlich tricky, oder? Wenn man hier die Logikmaschine anwirft, kann man nur zu einem Schluss kommen: "Typische 8-Bit-Anwendungen sind in ASM geschrieben". Denn obige Definition lässt gar keinen anderen Schluß zu.
Frank M. schrieb: > Wenn man hier die Logikmaschine anwirft, kann man nur zu einem Schluss > kommen: > > "Typische 8-Bit-Anwendungen sind in ASM geschrieben". > > Denn obige Definition lässt gar keinen anderen Schluß zu. Eben. Deswegen ist dem Moby ja mit Argumenten auch so schwer beizukommen :)
Frank M. schrieb: > Wenn man hier die Logikmaschine anwirft, kann man nur zu einem Schluss > kommen: Er wirft die Logikmaschine eben gezielt weg. Die Argumentationskette hat immer die Länge 1, so kann man prinzipbedingt keine Widersprüche oder Zirkelschlüsse aufdecken. Diese Diskussionsweise ist durchaus erfolgsversprechend, da der Gegner prinzipiell komplizierter argumentieren muss als man selbst: Man selbst kann immer einen einfachen, "richtigen" Schluss vorbringen, während der Gegner anhand mindestens zwei Argumenten zeigen muss, dass man Unsinn erzählt. Für viele Zuhörer in der Runde mag dies bereits zu viel sein.
:
Bearbeitet durch User
P. M. schrieb: > Er wirft die Logikmaschine eben gezielt weg. Die Argumentationskette hat > immer die Länge 1, Naja, das ist halt in Assembler geschrieben. In Assembler, der Mobys Komplexitätsanforderungen genügt.
Uhu U. schrieb: > Moby A. schrieb: > Auf diesem Feld ist gerade kein Blumentopf zu gewinnen ;-) > > Deswegen meidest du die Antwort auf meine Frage: > > Wozu eigentlich ein Assembler? wenn es ein Hexeditor auch tut. > > wie der Teufel das Weihwasser... Die Frage ist natürlich allenfalls eine praktischer Bequemlichkeit... Ich geh mal davon aus, daß Dir das selbst bewußt ist und der Einwand anderen Zwecken folgt ;-) Sheeva P. schrieb: > Ist die Lebenszeit des Programmierers keine Ressource? Mir scheint dies > die wertvollste Ressource überhaupt zu sein. Absolut. Ich fokussiere mich aber auf die MC-Ressourcen und ggf. Einsparmöglichkeiten bei der puren Hardware-Auswahl. Die Frage des Verhältnisses von Programmier-Zeitbedarf zur MC-Ressourceneinsparung ist trotzdem eine berechtigte. Mindestens mal im Universum typischer 8-Bit MSR Apps lässt sich aber sagen: Die Antwort dürfte höchst individuell ausfallen. Je nach Übung, Vorbereitung, System... was ja auch bei Hochsprache hilfreich ist, nur leider ohne die letztlich erreichbare Asm-Effizienz ;-(
be s. schrieb: > Hier wurde bereits bewiesen, dass C sogar speicherplatzsparender > als Mobys Assembler sein kann: > Beitrag "Re: C versus Assembler->Performance" Und nochmal: Da wird nichts bewiesen. Freilich kann prinzipiell auch jeder ASMler den Flash unnütz füllen. Chris D. schrieb: > allerdings war bei etwa 4-8k Codegröße dann Schluß So. Und nun überlegt Euch einmal, wieviel Millionen MSR Anwendungen sich schon in 1-2KB Asm Code verpacken lassen. > Und da hat Moby einfach mal Recht. Unfassbar. Das muss ich erstmal sacken lassen ;-) > Je mehr Code man hat, desto eher steigen für den Assembler-Programmierer > die Chancen, Optimierungsmöglichkeiten zu übersehen. Ein Compiler tut > das nicht. Nicht unbedingt. Oft folgen die Optimierungsmöglichkeiten von Asm bei der freien Wahl der MC-Ressourcen einem einfachen System, nutzen prinzipielle Schwächen einer Compiler-Lösung aus. Und sie sind bei sagen wir mal bis 10K Code durchaus überschaubar! > bei kleinen Programmen (4k) an, wo ein Compiler Dinge findet, die er > doppelt nutzen kann, dann ist das schon faszinierend (und teilweise > unfassbar). Da muss man einfach den Hut vor den Compilerjungs ziehen. Ja, ganz nett. Aber das reicht nicht, um an gut handoptimiertem Asm vorbeizuziehen! > Ich würde also aus der Praxis heraus behaupten, dass ab einer gewissen > Codegröße der Compiler den Assemblerprogrammierer auch recht locker in > der Codegröße schlägt. Richtig. Weil ab einer bestimmten Projektgröße der Überblick verlorengeht. Trotzdem sind der Möglichkeiten des Asm-Programmierers diesen zu behalten auch nicht gerade wenige.
Frank M. schrieb: > das Mittel der Wahl und alles größer als ATTiny Teufelswerk, was man > nicht braucht. Für jeden Zweck die richtigen Mittel. Die AVR-Reihe bis hoch zum XMega stemmt einen Großteil typischer 8-Bit MSR Apps, wobei die Verwendung von Asm den Einsatzhorizont noch einmal ordentlich ausdehnt. Was ist daran nur so schwer zu verstehen? > Fazit: Moby hats drauf, bewusst zu provozieren. Das macht er aber nicht > offen, sondern sehr verdeckt. Eine Deiner vielen Unterstellungen. Warum willst Du den Fall, daß Asm tatsächlich Vorteile bietet auch partout nicht in Deine Überlegungen einbeziehen? <Beileid> Ist es so schlimm? </Beileid> Jörg W. schrieb: > Einmal in die Enge getrieben, schlägt er wild um sich. Siehe ganz oben > auf dieser Seite, wo er mich des „Märchenerzählers“ bezichtigt, um kurz > danach selbst zu behaupten, die Peripherals eines Xmega seien eigentlich > die gleichen wie bei einem MegaAVR, nur „die paar Steuerbits anders > verteilt“. Wo siehst Du da einen Widerspruch? Genauso ist das. Wie es ausschauen würde wenn ich wild um mich schlüge hast Du hier noch nicht erlebt- das wär auch wenig überzeugend ;-)
P. M. schrieb: > Moby A. schrieb: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt > > Das ist schlicht und einfach extremer Unsinn. Ab einer gewissen Grösse > hat der Mensch unmöglich den Überblick, um weitgreifend zu optimieren. Du hast einfach nicht bis zum Ende gelesen... > Um es zusammenzufassen: Wir haben dir schon lange zugestimmt, dass > man mit Assembler auf sehr kleinen Mikrocontrollern bei kleinen > Projekten mit wenig Zusatzaufwand etwas besser sein kann als mit C. ... um dann wenigstens das zuzugestehen (wenn auch wieder mit vielerlei Relativierung). Immerhin ;-) > eben immer auf die Miniprojekte ausweichst. Ja. So ein praktisches Miniprojekt verdeutlicht das Prinzip -hier- am besten, ist am ehesten nachvollziehbar. Aber Code ist Code, ob mehr, ob weniger...
Yalu X. schrieb: > bei Dingen wie dem TCP/IP-Stack geht er > sogar noch einen Schritt weiter und kauft sich dafür für fast den > 100fachen Preis eines ATtiy13 gleich ein komplettes Hardwaremodul. Das hast Du aber jetzt schön in Beziehung gesetzt. Hatte ich nicht schon erwähnt daß mein Xport an einem Xmega hängt? > Nennt er als Grenze bspw. 200 Byte, würde ich (und wahrscheinlich viele > andere auch) das sofort akzeptieren Grenzen zu nennen ist inakzeptabel... Wenn mein größtes Asm Projekt 10K erreicht heißt das noch lange nicht daß da nicht noch mehr ginge! > Um zu zeigen, dass diese Grenze dennoch richtig ist, müsste > Moby in der Lage sein, in der gleichen Entwicklungszeit und mit gleicher > Speicher- und Laufzeiteffizienz ein 4-KiByte-Assemblerprogramm zu > schreiben wie ein C-Programmierer ein entsprechendes C-Programm. Es gibt keine "richtige" Grenze sondern nur eine, die von Übung, Vorbereitung, System und konkreter App höchst individuell ausfällt. Die Entwicklungszeit des Asm-Projekts dürfte grob geschätzt länger sein, ja. Aber die Effizienzvorteile von Asm sind auch kein Geschenk... Hatte ich das irgendwo behauptet?
Carl D. schrieb: > Ersteres muß man zugeben, es ist sein Thread, aber nur wenn er hier > Antworten bekommt, bleibt er auch hier. Darauf würde ich mich nicht verlassen, denn > wenn er wieder einen Thread mit > C/C++-Themen mit seinem Assembler- Fundamentalismus flutet. nutzt er nur die Gelegenheit am praktischen Beispiel, die Ineffizienz von C++ nicht nur vom resultierenden Code her, sondern auch die unnütze Komplexität der Programmerstellung selber bloßzustellen. Unvergessen sind mir da manche monströsen Ausdrücke bloß um ein paar Portpins zu beeinflussen. Fundamentalismus schließlich ist etwas anderes: Das wäre dann der Fall würde man die Sinnhaftigkeit einer Programmiersprache von der Anwendung entkoppeln; Vor-und Nachteile der Sprachen ignorieren. Michael K. schrieb: > Ist ja toll wenn man so auf ASM abgeht, mir ist das aber zu fixiert auf > eine Controller Familie Zwischem beidem existiert ein Zusammenhang ;-) Sheeva P. schrieb: > Das ist genau das, was ihm zwei Dutzend > sehr erfahrene professionelle Entwickler immer wieder mal mit mehr, mal > mit weniger Geduld zu erklären versucht haben. Irrtum. Dazu mal ein Tipp: Zähl mal wie oft ich den Ausdruck "für typische 8-Bit'"MSR-Apps verwende. Das hat einen Hintergrund! Darauf und nur darauf beziehe ich die Vorteile von Asm seit jeher! Das fällt auch immer wieder bevorzugt unter den Tisch.
Operator S. schrieb: > Diese Offenbarung ist tatsächlich neu und bisher weigerte er sich > das zu akzeptieren. S.O. > Mein grösseres Problem ist aber das er meint ein einfacher AVR mit > simplen ASM reicht für alles aus. Ach was. Größere Berechnungen und Datenmengen hatte ich hier schon als Gegenindikation genannt. > Dabei sagt er selbst, dass er für > gewisse Funktionen ein externes Modul anflanscht und dieses dann > anspricht. Das auf besagtem Modul ein Cortex-M sitzt und in C oder gar > C++ programmiert wurde, hat aber natürlich nichts mit seiner > Argumentation zu tun. Warum sollte ich das ideologisch beschränkt verweigern? Soll der Cortex-M doch dort seine Berechtigung haben (obwohl ich das jetzt aus eigener Erfahrung nicht bestätigen kann). Der Einsatz externer Module ist, zumindest für mich als Bastler, auch eine Frage von Effizienz- auf einer übergeordneten Ebene quasi. Niemand hat dem Sinn von 32-Bit ARM hier widersprochen, wär auch reichlich blöd bei dem Boom den die gerade erleben. Aber: Das muß bei den Millionen Anwendungen denen ein 8-Bitter genügt nicht nennenswert beeindrucken ;-)
:
Bearbeitet durch User
Operator S. schrieb: > Insgeheim freue ich mich über jeden > seiner Threads, sowohl dieser, wie auch jener des Sensorboards. Es > erheitert meinen Tag und befreit die Gedanken, um danach weiter zu > arbeiten. > Dies meine ich übrigens nicht im ironischen Sinne, sondern ist ernst > gemeint. Da freu ich mich auch. > Nun, warum man sich darüber aufregt? Das ist vermutlich gegenstand > einiger Doktorarbeiten in der Psychologie. Denn es scheint bereits > erwiesen, dass Ings und Infs sich übermässig enervieren können, Ich sehe eher ein gewisses C-Selbstbewußtsein getroffen. Kann doch nicht sein daß man so vieles auch einfacher in Asm erledigen kann! Yalu X. schrieb: > Am Schluß besteht "alles" nur noch aus ca. 1% aller µC-Anwendungen, > nämlich diejenigen, bei denen Daten von einer einfachen Schnittstelle > (bspw. Digital-I/O oder ADC) gelesen, auf einfache Weise verarbeitet > (bspw. Entprellung oder Mittelwertbildung) und auf einer anderen > einfachen Schnittstelle (bspw. UART) wieder ausgegeben werden. Diese > (und nur diese) Aufgaben lassen sich in Assembler tatsächlich fast > genauso leicht realisieren wie in C. Deine 1% würde ich eher denen hier zuordnen (solange tatsächlich 8-bittig verwirklicht): > Dinge wie die Linearisierung von Sensordaten, ein PID-Regler, ein > Kalman-Filter oder dergleichen, können i.Allg. ebenfalls sehr gut mit > 8-Bit-Controllern wie den AVRs realisiert werden Im SmartHome beispielsweise braucht man viele verschiedene Funktionen für Sensor- und Aktordaten. Größere Datenmengen und Berechnungen gibts da sehr wenig. Vielleicht bau ich ja mal einen Quadrocopter. Da nehm ich dann 32-Bit mit Hochsprache, versprochen ;-)
Moby A. schrieb: > Größere Datenmengen und Berechnungen gibts da sehr wenig. Ich weiß ja nicht …
1 | sht21_measure(0xe3, b, 3); |
2 | v = ((uint16_t)b[0] << 8) | b[1]; |
3 | double t = -46.85 + 175.72 * (double)v / 65536.0; |
4 | |
5 | ht21_measure(0xe5, b, 3); |
6 | v = ((uint16_t)b[0] << 8) | (b[1] & 0xfc); |
7 | double h = -6.0 + 125.0 * (double)v / 65536.0; |
8 | |
9 | TRX_PRINTF("SHT-21#1 %5.2f oC, %5.2f %% RH\r\n", t, h); |
Man kann die Berechnung sicher auch irgendwo mit scaled integers durchziehen statt mit float/double, aber wenn ich mit den durch den SHT21 gemessenen Werten für Temperatur und Feuchtigkeit etwas anfangen will, dann muss ich rechnen. Noch schlimmer sieht's bei so einem Luftdrucksensor (MPL1115) aus:
1 | barometer_init(); |
2 | |
3 | uint8_t params[8]; |
4 | barometer_read(4, 8, params); |
5 | |
6 | int a0_int = (params[0] << 8) + params[1]; |
7 | a0 = a0_int / 8.0; |
8 | int b1_int = (params[2] << 8) + params[3]; |
9 | b1 = b1_int / 8192.0; |
10 | int b2_int = (params[4] << 8) + params[5]; |
11 | b2 = b2_int / 16384.0; |
12 | int c12_int = (params[6] << 8) + params[7]; |
13 | c12 = c12_int / (16384.0 * 1024.0); |
14 | |
15 | //…
|
16 | uint8_t results[4]; |
17 | |
18 | barometer_read(0, 4, results); |
19 | unsigned padc = (results[0] << 2) + (results[1] >> 6); |
20 | unsigned tadc = (results[2] << 2) + (results[3] >> 6); |
21 | |
22 | double pcomp = a0 + (b1 + c12 * (double)tadc) |
23 | * (double)padc + b2 * (double)tadc; |
24 | double pressure = pcomp * ((115 - 50) / 1023.0) + 50; |
25 | |
26 | PRINTF("0000: %.1f hPa" NL, pressure * 10); |
Initial muss man sich dort ein paar Kalibrierwerte auslesen, dann muss man bei jeder Messung die interne Temperatur messen zusätzlich zu den Messwerten des Druckaufnehmers, und diese gemäß der Formel im Datenblatt umrechnen. Wie gesagt, über floating point vs. scaled integer würde ich hier nicht diskutieren, geht sicher auch mit letzterem. Aber „keine Berechnungen“? Oder ist jetzt das Messen von Temperatur, Luftdruck und Luftfeuchtigkeit plötzlich „keine typische Aufgabe für einen 8-Bitter“ mehr?
Thomas E. schrieb: > Nein, ich denke, die Grenze wird erreicht sein, wenn die 32 von ihm fest > belegten Register nicht mehr ausreichen. So wird nie eine Grenze erreicht. Asm-Programmierer-System bedingt ;-) Frank M. schrieb: > "Typische 8-Bit-Anwendungen sind in ASM geschrieben". So es der Programmierer einzusetzen weiß und keine der erwähnten Gründe entgegenstehen ist das von Vorteil! P. M. schrieb: > Frank M. schrieb: > Wenn man hier die Logikmaschine anwirft, kann man nur zu einem Schluss > kommen: > > Er wirft die Logikmaschine eben gezielt weg. Die Argumentationskette hat > immer die Länge 1, so kann man prinzipbedingt keine Widersprüche oder > Zirkelschlüsse aufdecken. Diese Diskussionsweise ist durchaus > erfolgsversprechend, da der Gegner prinzipiell komplizierter > argumentieren muss als man selbst: Man selbst kann immer einen > einfachen, "richtigen" Schluss vorbringen, während der Gegner anhand > mindestens zwei Argumenten zeigen muss, dass man Unsinn erzählt. Für > viele Zuhörer in der Runde mag dies bereits zu viel sein. Machts doch nicht wieder (C-Programmierer typisch;-) so kompliziert! Ich habe mir die Mühe gemacht hier ein praktisches Asm-Projektbeispiel mit wenig Funktionalität zur Veranschaulichung reinzustellen. Soll das doch jemand effizienter in C coden. Solange das nicht passiert brauchen wir hier nicht theoretisch mit Logikmaschinen, Argumentationsketten und Zirkelschlüssen herumlamentieren ;-(
Jörg W. schrieb: > Initial muss man sich dort ein paar Kalibrierwerte auslesen, dann muss > man bei jeder Messung die interne Temperatur messen zusätzlich zu den > Messwerten des Druckaufnehmers, und diese gemäß der Formel im Datenblatt > umrechnen. DESHALB sagte ich "sehr wenig"! Ich habe auch einen ähnlichen Kombisensor in meiner Wetterstation mit ähnlichem Procedere. Das ging natürlich auch in Asm, ist aber etwas aufwendig. > Oder ist jetzt das Messen von Temperatur, Luftdruck und Luftfeuchtigkeit > plötzlich „keine typische Aufgabe für einen 8-Bitter“ mehr? Dem umständlichen Messwert-Berechnen kann man übrigens mit vielen einfachen analogen Sensoren für jede der 3 Größen effektiv aus dem Wege gehen...
:
Bearbeitet durch User
Moby A. schrieb: > Dem umständlichen Messwert-Berechnen kann man übrigens mit vielen > einfachen analogen Sensoren für jede der 3 Größen effektiv aus dem Wege > gehen... Warum sollte man? Die Berechnung oben ist wenige Zeilen, und der kleinste Controller, den ich dafür habe, hat sowieso 128 KiB Flash. Das sind ATmega128RFA1, die ich u. a. eben auch wegen der eingebauten Funkschnittstelle nehme. Ersatz durch einen ATtiny* fällt also schon mal aus, denn das Anflanschen irgendwelcher externer Datenübertragung wäre in jedem Falle umständlicher. Die Analogbausteine werden ohnehin kaum genauer sein, der Vorteil der digitalen ist ja gerade, dass sie all ihre Analogverarbeitung on-board direkt auf dem Chip machen können, das minimiert die Störeinflüsse.
Moby A. schrieb: > Uhu U. schrieb: >> Moby A. schrieb: >> Auf diesem Feld ist gerade kein Blumentopf zu gewinnen ;-) >> >> Deswegen meidest du die Antwort auf meine Frage: >> >> Wozu eigentlich ein Assembler? wenn es ein Hexeditor auch tut. >> >> wie der Teufel das Weihwasser... > > Die Frage ist natürlich allenfalls eine praktischer Bequemlichkeit... Aha, wir kommen dem Kern der Sache näher... Der Hex-Editor ist zweifellos unbequemer, als ein Assembler, man kann aber dasselbe damit erreichen, nur mit höherem Aufwand, d.h. auf unbequemerem Weg. Wir können das Modell nach "oben" und nach "unten erweitern. Nach "oben": der C-Compiler ist bequemer, als der ASM; ein Generator, der automatisch beliebige Probleme analysiert und dann eine Software generiert, die genau das macht, was nötig ist, das Problem zu lösen, ist noch viel Bequemer, als ein C-Compiler usw. usf... Nach "unten": Man braucht überhaupt keine Microcontroller, man kann die damit gelösten und die dadurch erst geschaffenen Probleme auch umgehen. Man landet irgendwann auf dem Niveau des primitivst möglichen Organismus, der keine Bedürfnisse mehr hat und nur noch vom evolutionären Druck getrieben ist, an dem er scheitern muss, weil er sich ja nicht weiter entwickeln "will". Durch ständige Weiterentwicklung der Technik wird die relative Distanz des ASM-Puristen zur Comutersteinzeit immer geringer, d.h. seine Arbeitsweise wird immer unbequemer, weil immer unproduktiver - im Geschäftsleben ist das ein Aussterbegrund: der arme ASM-Purist bekommt nicht mehr genug zu fressen und verhungert. Deswegen geht der Trend in Richtung des skizzierten allwissenden Generators, der dem Leuten letztlich alle Arbeit abnimmt. Da beginnt das nächste Problem: was sollen die dann tun, um sich nicht zu langweilen? Den ganzen Tag fressen bringts nicht, davon wird man zu fett. Man wird also den Generator befragen und der generiert möglicherweise diese Antwort:
1 | Baue zum Spaß einen Hexeditor und programmiere damit auf einem fossilen |
2 | Microcontroller ein in 20 Befehlen lösbares Problem deiner Wahl. |
Damit steht der Generatorverwöhnte - der natürlich den Generator nicht im entfernten durchschaut, sondern ihn für eine göttliche Wundermaschine hält - vor dem Problem, die Grundzüge der Computertechnik aus grauer Vorzeit neu erfinden zu müssen. Ganz besonders schwer tut er sich dabei mit dem EOR-Befehl und das gibt uns wiederum einen heißen Tipp, womit wir es hier zu tun haben: Es ist Moby, der zu faul is, sich die Grundzüge unserer Informatik zu rekonstruieren und sich deswegen einfach vom Generator auf die Zeitreise ins frühe 21. Jahrhundert schicken ließ um sich von uns alles erklären zu lassen. Mittlerweile hat ihn aber wieder die alte Bequemlicheit erfasst, zu der er vom Generator erzogen wurde und er will nichts mehr lernen. Außerdem hat der den Trick vergessen, mit dem er die Zeitheimreise antreten kann und nun hockt er hier und dreht auf dem Assembler hohl. Die Moral von der Geschicht: Wenn man der Zeit so viel voraus ist, wie Moby, sollte man ihr nicht hinterher hinken ;-)
Moby A. schrieb: > Thomas E. schrieb: >> Nein, ich denke, die Grenze wird erreicht sein, wenn die 32 von ihm fest >> belegten Register nicht mehr ausreichen. > > So wird nie eine Grenze erreicht. Asm-Programmierer-System bedingt ;-) den Teil solltst nochmal erklären .. der Optimale ASM code verwendet soviele Register wie möglich (also im besten Fall alle..) jegliches "Asm-Programmierer-System" welches ja dazu dient, dir die Übersichtlichkeit oder Erweiterbarkeit oder ... zu verbesser, bedingt aber automatisch dass dein Code nicht Optimal (siehe oben) ist... ps. eigentlich kommt beim Optimalem ASM code, auch erstmal geschwindigkeit vor größe... also erstmal ALLE verfügbaren Resourcen* nutzen, erst wenn diese ausgehen, muss man Resourcen* sparen.. *Moby Resourcen sind gemeint..
Uhu U. schrieb: > Wenn man der Zeit so viel voraus ist, wie Moby, sollte man ihr nicht > hinterher hinken ;-) Herrliche Story, danke!
Moby A. schrieb: > Irrtum. Dazu mal ein Tipp: Zähl mal wie oft ich den Ausdruck "für > typische 8-Bit'"MSR-Apps verwende. Das hat einen Hintergrund! Darauf und > nur darauf beziehe ich die Vorteile von Asm seit jeher! Das fällt auch > immer wieder bevorzugt unter den Tisch. Dann hör jetzt endlch auf um den heisen Brei rum zu reden und zeig endlich eine dieser Anwendungen und zwar eine von DIR (!) und eine mir mehr als 20 Zeilen. Sagen wir mal lockere 2kB hex code. Dokumentiere die Funktionalität so, dass eine eindeutiges Pflichtenheft dabei raus kommt. Ich halte jede Wette das dich jeder C Neuling der sich im Forum herumtreibt deinen code sowohl in Ausführungszeit als auch bzgl. der codegröße um Längen schlägt! Na ja, natürlich kenne jetzt schon deine Antwort... so wie die meisten hier ;-)
Jörg W. schrieb: > Die Analogbausteine werden ohnehin kaum genauer sein, der Vorteil der > digitalen ist ja gerade, dass sie all ihre Analogverarbeitung on-board > direkt auf dem Chip machen können, das minimiert die Störeinflüsse. Schon klar. Dafür benötigen die analogen eben keine langwierigen Berechnungen und langen oft genauso. Keep it simple! Uhu U. schrieb: > Der Hex-Editor ist zweifellos unbequemer, als ein Assembler, man kann > aber dasselbe damit erreichen, nur mit höherem Aufwand, d.h. auf > unbequemerem Weg. Wir können das Modell nach "oben" und nach "unten > erweitern... Nette Story. Nur wieder voll am Thema vorbei ;-) Die Programmentwicklung mit Asm selbst ist heute für 8-Bit MSR eine einfache Sache: Code mit den paar dutzend simplen Instruktionen schreiben, assemblieren und rauf auf den Controller. Keine umständliche Compilerwahl, keine umständlichen C-Konstruktionen, keine "Optimierung" usw. usf. Easy und trotzdem effizient. > Die Moral von der Geschicht: > Wenn man der Zeit so viel voraus ist, wie Moby, sollte man ihr nicht > hinterher hinken ;-) Die Moral ist: Die Controller(sprach)welt nicht in veraltet und neu einteilen sondern in einfach und unnötig kompliziert... Immer schön die Bedürfnisse der App im Auge behalten ;-)
Robert L. schrieb: > So wird nie eine Grenze erreicht. Asm-Programmierer-System bedingt ;-) > > den Teil solltst nochmal erklären .. > der Optimale ASM code verwendet soviele Register wie möglich (also im > besten Fall alle..) Soviele Register wie möglich sollte man in jedem Fall verwenden. Sie langen aber auch für jeden Fall, wenn man ein bischen System in die Registerverwendung bringt. Da ist dann etwas Mitdenken angesagt, wenn das Programm nicht ohnehin sehr klein ist. Gerne erläutere ich Dir mal mein System bei größeren Programmen >1K... > ps. eigentlich kommt beim Optimalem ASM code, auch erstmal > geschwindigkeit vor größe... Das ist natürlich falsch. Wenn Speed keine Rolle spielt wird natürlich zuallererst die Codegröße interessant. Gerade die Größe des Flash ist natürlich ein wesentliches Unterscheidungsmerkmal der Controller (und ihrer Baugröße und des Preises). Schließlich wird man die Taktfrequenz noch auf nötiges Minimum justieren und schon kann man sich an einer optimalen Lösung erfreuen ;-)
Gu. F. schrieb: > Ich halte jede Wette das dich jeder C Neuling der sich im Forum > herumtreibt deinen code sowohl in Ausführungszeit als auch bzgl. der > codegröße um Längen schlägt! Lustig. Aber solang das nicht mal die größten Experten hier mit dem hööööchstproduktiveffizienten C bei überschaubarem Winzigfunktionalitätscode schaffen lehne ich mich mal gaaanz entspannt zurück ;-) P.S. Gerade beim 'ganz' s.o. noch zwei a eingefügt
:
Bearbeitet durch User
>Gerne erläutere ich Dir mal >mein System bei größeren Programmen >1K... ja dann, leg mal los..
>> ps. eigentlich kommt beim Optimalem ASM code, auch erstmal >> geschwindigkeit vor größe... > > Das ist natürlich falsch. Wenn Speed keine Rolle spielt wird natürlich > zuallererst die Codegröße interessant. Gerade die Größe des Flash ist > natürlich ein wesentliches Unterscheidungsmerkmal der Controller (und > ihrer Baugröße und des Preises). Schließlich wird man die Taktfrequenz > noch auf nötiges Minimum justieren und schon kann man sich an einer > optimalen Lösung erfreuen ;-) Ohne die geringste Hoffnung daß der Addressat das versteht: Wenn der Takt so niedrig wie möglich sein soll, dann ist Speed des Codes extrem wichtig. Linear runtergeschriebener Code ohne Schleifen braucht zwar mehr Flash (den ja eine "typische 8-Bit MSR" eh zu 80% leer läßt), durchläuft aber je Meßzyklus weniger Befehle und spart damit Strom. >Jörg W. schrieb: >> Die Analogbausteine werden ohnehin kaum genauer sein, der Vorteil der >> digitalen ist ja gerade, dass sie all ihre Analogverarbeitung >> on-board direkt auf dem Chip machen können, das minimiert die >> Störeinflüsse. > > Schon klar. Dafür benötigen die analogen eben keine langwierigen > Berechnungen und langen oft genauso. > Keep it simple! Ja klar, viel simpler sind dann externe OpAmp-"Gräber". Davon kann man nämlich auch "nix verstehen": Beitrag "Analoger Sensor (LM335) mit Operationsverstärker + AVR Asm-Code"
Carl D. schrieb: > Wenn der Takt so niedrig wie möglich sein soll, dann ist Speed des Codes ... Ich sagte wenn Speed keine Rolle spielt... Dann dreh ich am Takt hinterher... Spielt er DIE Rolle, muß ich i.d.R. mehr Flash in die Hand nehmen. Spielt Stromverbrauch DIE Rolle dann für möglichst wenig Takt genauso. Du erzählst mir da nix Neues. > Ja klar, viel simpler sind dann externe OpAmp-"Gräber" Ja klar, ein OpAmp sind für Dich Gräber und der OpAmp als Verstärker hat was mit Asm zu tun... > Ohne die geringste Hoffnung daß der Addressat das versteht Ohne die geringste Hoffnung daß Du mich verstehen willst ;-)
:
Bearbeitet durch User
Robert L. schrieb: > Gerne erläutere ich Dir mal >mein System bei größeren Programmen >>1K... > > ja dann, leg mal los.. Also, es ging drum daß 32 Register auch bei größeren Projekten nie zur Begrenzung werden. Das "System" schaut bei mir so aus: Für Interrupts aller Art die 6 Pointerregister XL-ZH. Diese werden bei Eintritt Zeit/Flash sparend mit MOVW in R10-R15 gesichert. R9 sichert die Flags. Interruptroutinen kommen möglichst nur mit den Pointerregistern aus. Tun sie das nicht werden die weiteren benötigten Register (ab R16) auf dem Stack gesichert. Anzustrebender Sonderfall (öfter möglich): Die Funktionalität steckt allein in (sich nicht gegenseitig unterbrechenden) Interrupts. Da muß dann nix oder nur wenig gesichert werden! Im Hauptprogramm wird hier nur geschlafen... Ansonsten kommt dieses meist mit allen Registern ab R16 aus. R7-R8 enthält einen Systeminterrupt Counter für Timing-Aufgaben. R0-R6 sind für spezielle Zwecke/Instruktionen reserviert. Weitere Fragen und Einsprüche?
:
Bearbeitet durch User
Moby A. schrieb: > Weitere Fragen und Einsprüche? Ja, warum sollte ich über sowas nachdenken müssen?
:
Bearbeitet durch User
Sven B. schrieb: > Ja, warum sollte ich über sowas nachdenken müssen? Stimmt. Du kannst auch Hochsprache mit all ihren Nachteilen verwenden. Und über andere, künstliche Probleme bei der bestmöglichen Sprachverwendung nachdenken ;-)
Moby A. schrieb: > Stimmt. Du kannst auch Hochsprache mit all ihren Nachteilen verwenden. > Und über andere, künstliche Probleme bei der bestmöglichen > Sprachverwendung nachdenken ;-) Die Geschichte der Menschheit ist voll davon, natürliche Probleme durch künstliche zu ersetzen. Statt zu frieren und Fleisch als Rohkost vom Knochen zu nagen könnte ich in den Wald gehen und Holz schlagen. Das war eine der frühen Stufen beim Ersatz natürlicher Probleme durch künstliche. Mittlerweile wurde freilich das bereits künstliche Beschaffungsproblem vom Holz durch mehrere noch künstlichere ersetzt, nämlich jährlich den Öltank aufzufüllen und die Stromrechnung zu zahlen. Die Nachteile dieser Lösung des Wärme- und Beschaffungsproblems liegen auf der Hand. Ohne auf Nahost-Öl basierte Zivilisation gäbe des die aktuelle Form des Terrorismus nicht. Also meine Damen und Herren: back to the roots, allesamt! Schinken-Original, direkt vom noch schlachtwarmen Schwein genagt. ;-)
:
Bearbeitet durch User
Ihr habt ja immer schöne Stories und Vergleiche drauf... Leider trifft das die Situation hier mal wieder nicht. Da liegt es nämlich in der Natur künstlicher Probleme, daß sie sich leicht vermeiden ließen ;-)
:
Bearbeitet durch User
Gu. F. schrieb: > Dann hör jetzt endlch auf um den heisen Brei rum zu reden und zeig > endlich eine dieser Anwendungen und zwar eine von DIR (!) und eine mir > mehr als 20 Zeilen. Und? Wie sind gespannt...
Gu. F. schrieb: > Gu. F. schrieb: > Dann hör jetzt endlch auf um den heisen Brei rum zu reden und zeig > endlich eine dieser Anwendungen und zwar eine von DIR (!) und eine mir > mehr als 20 Zeilen. > > Und? > Wie sind gespannt... Gibts gerade nix zum nachplappern daß Du Dich schon selbst zitieren mußt? Weißt Du worauf ich gespannt bin? Wann Du mal zählen kannst ;-)
Moby A. schrieb: > Weil ab einer bestimmten Projektgröße der Überblick > verlorengeht. Trotzdem sind der Möglichkeiten des Asm-Programmierers > diesen zu behalten auch nicht gerade wenige. Das ist genau das, was du nicht kapierst. Dass man beim Programmieren den Überblick verliert, ist nicht etwa ein blöder Unfall, sondern völlig zwangsläufig: Ein Mensch kann bereits ein kleineres Projekt nicht mehr ohne weiteres überblicken. Den Überblick zu behalten ist die Hauptherausforderung in der Konzeption von Software und Programmiersprachen. Der Flaschenhals liegt beim Überblick (und damit Wartbarkeit, Korrektheit, Sicherheit, Erweiterbarkeit, ...) und nicht bei einzelnen Taktzyklen oder Speicherbytes. Du optimierst schlicht am falschen Ort für 99.9% der praktischen Projekte, kleinste Mikrocontrollerprojekte eingeschlossen. Und ich möchte dich ja mal sehen, einen Code für eine GPU oder einen modernen Mehrkern-Prozessor in Assembler effizienter hinzukriegen als der Compiler es kann. Vermutlich wirst du jetzt argumentieren, dass sei hier gar nicht Thema, aber im übernächsten Beitrag kommt dann trotzdem wieder die Aussage, deine Behauptungen würden prinzipiell für jedes Programm gelten. Nein, tun sich nicht, das ist schlicht und einfach falsch.
P. M. schrieb: > Dass man beim Programmieren > den Überblick verliert, ist nicht etwa ein blöder Unfall, sondern völlig > zwangsläufig Was nun aber nicht bedeutet, daß man dies mit einem gut gegliederten funktionellen System und guter Doku nicht beeinflussen könnte. > Der Flaschenhals liegt beim Überblick > (und damit > Wartbarkeit, Korrektheit, Sicherheit, Erweiterbarkeit, ...) Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10K. Das sagt ein durchschnittlicher Asm-Programmierer. > Du optimierst schlicht am > falschen Ort für 99.9% der praktischen Projekte, kleinste > Mikrocontrollerprojekte eingeschlossen. Nö. Ich optimiere Baugröße, Erweiterbarkeitsreserven und (weniger bedeutsam) die Hardwarekosten. Hinzu kommt die generell einfachere Softwareerstellung, angefangen mit den einfacheren Code- und Programmiermitteln, weniger Schreibaufwand und Verzicht auf suboptimale / fürs Ergebnis überflüssige C-Sprachkonstruktionen. > Und ich möchte dich ja mal sehen, einen Code für eine GPU oder einen > modernen Mehrkern-Prozessor in Assembler effizienter hinzukriegen Da kann ich Dich wieder beruhigen, davon war niemals die Rede (was nicht heißt daß es für Spezialzwecke nicht möglich wäre).
:
Bearbeitet durch User
Moby A. schrieb: > Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10k Die wir sicher gleich zu sehen kriegen. Am Ende stimmt das gar nicht ;-)
P. M. schrieb: > was du nicht kapierst ist, daß Du mit mir einen ASMler vor Dir hast der das nicht erst seit gestern macht und (wenn auch nur für eigene Zwecke) mehr als genug Projekte erfolgreich zu Ende gebracht hat. Was Du schließlich ignorierst sind auch die Massen an Asm-Code, die für AVR (z.B. hier in den Projekten) erstellt wurden. Warum wohl? Alles Umherirrende, die nur nicht Deine Logik kapieren? Es dürfte eher daran liegen, daß bei Dir, sagen wir es freundlich, die Assembler-Erfahrung noch ausbaufähig ist ;-)
:
Bearbeitet durch User
Moby A. schrieb: > ist, daß Du mit mir einen ASMler vor Dir hast der das nicht erst seit > gestern macht und (wenn auch nur für eigene Zwecke) mehr als genug > Projekte erfolgreich zu Ende gebracht hat. Als Biebelforscher mit dem ASM-Turm auf dem Markplatz...
Moby A. schrieb: > Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10K. Das > sagt ein durchschnittlicher Asm-Programmierer. Ok. Dann übersetze doch bitte mal die folgende C++-Funktion in Assembler, sagen wir für uint8_t und uint16_t und erkläre mit, wie die übersichtlicher und effizienter sein soll als in C:
1 | template <class T> |
2 | T max(T a, T b){ |
3 | return (a > b) ? a : b; |
4 | }
|
Uhu U. schrieb: > Als Biebelforscher mit dem ASM-Turm auf dem Markplatz... Ja ja ich weiß, für die Big Player hier mit der dicken C-Biiiiebel bleibt das schwer erträglich ;-) Da bleiben nur solche Argumente.
Moby A. schrieb: > Hinzu kommt die generell einfachere Softwareerstellung, angefangen mit > den einfacheren Code- und Programmiermitteln, weniger Schreibaufwand und > Verzicht auf suboptimale / fürs Ergebnis überflüssige > C-Sprachkonstruktionen. Das ist Satire.
P. M. schrieb: > C:template <class T> > T max(T a, T b){ > return (a > b) ? a : b; > } Was soll daran übersichtlich sein? Das ist kryptischer Kauderwelsch für Eingeweihte. Dessen Studium ist für 8-Bit MSR überflüssig ;-)
Moby A. schrieb: > Rufus Τ. F. schrieb: >> Das ist Satire. > > Das ist Tatsache. Dass es Satire ist? Ja, das ist eine Tatsache. Endlich siehst du das ein. mfg.
Also übersichtlicher als so geht's doch kaum:
1⌈2
2
2⌈1
2
⌈/1 2 3 4 5 3 8 1 3
8
:
Bearbeitet durch User
> Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10k
hmm - die µCs bei mir in der Bastelkiste fangen erst bei 128K an und
hören bei 1M auf (hab nur noch 32bit).
Die kleinen 128er nutze ich für kleinere Bastelsachen (bis runter zum
Lauflicht - ich habe damit aber auch schon einen Quadrokopter mit
kleinem Echtzeitbetriebssystem gebaut). Die kosten so wenig, dass es mir
egal ist, ob ich nur 3K davon benutze - spielt überhaupt keine Rolle.
die "großen" µC mit 1M Flash nutze ich wenn Grafikdisplays angesteuert
werden müssen. Einmal brauchte ich auch eine Soundausgabe und habe die
Sounddaten einfach im Flash abgelegt.
Einzig bei batteriebetriebenen Anwendungen wo es auf jedes µA ankommt,
könnte ich mir vorstellen einen kleinen 16bit msp430 zu nehmen, aber so
eine Anwendung hatte ich bislang noch nicht.
Für 8bit µCs (geschweige denn für ASM) sehe ich bei mir keinerlei
Verwendung mehr. Ich kann mir gut vorstellen, dass vor 20 oder 30 Jahren
die µCs mit viel Ressourcen noch sehr teuer waren. Da hat es sich
bestimmt gelohnt ASM zu nutzen. Das war aber lange vor meiner Zeit. In
meiner Azubizeit bin ich mal mit Embedded-Entwicklern in Kontakt
gekommen (das war so 1999 rum). Von denen hat niemand mehr ASM benutzt.
Die konnten es aber (das waren richtige Profis). Die Aussage war damals:
ASM nur im Notfall nutzen, wenn Handoptimierung notwendig ist. Komplette
Projekte in ASM hätten auf längere Sicht die Portierbarkeit zunichte
gemacht und für die Firma großen finanziellen Schaden bedeutet.
Wenn ich solche komplexen Darstellungsformen von Code sehe bin ich mit Asm immer heilfroh, einfachere Ausdrucksformen verwenden zu können. Z.B. ohne künstliche Kreationen wie Datentypen und dem noch unnützeren Konzept der Typumwandlungen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Da bleiben nur solche Argumente. Für deine Mini-Basteleien mag ASM ja ausreichen, aber für ernsthafte Projekte, die einen größeren Umfang haben und nicht nur Spielerei sind, geht das einfach nicht. Natürlich konnten auch die Menschen in der Altsteinzeit leben - fragt sich nur, warum wir nicht dabei geblieben sind, sondern auf Teufel-komm-raus Computer entwickeln mussten. Die Probleme, die unsere Vorfahren vor 2,5 Millionen Jahren hatten, waren nicht so komplex, dass sie hoch entwickelte Steinwerkzeuge dieser Qualität: http://www.chemieunterricht.de/dc2/pyrit/steinwerkzeug.htm gebraucht hätten - trotzdem hätten sie sie sofort genommen, wenn sie ihnen jemand angeboten hätte. Wenn man die Technikgeschichte von den ersten Anfängen an Revue passieren läßt, sieht man tausendfach Schritte der Qualität "vom Assembler zum C-Compiler" und einen bestimmten Schritt dieser Art zum allein seligmachenden zu erklären, ist genau so lächerlich, wie eine Kameltreiber- oder Schafhirtenreligion im 21. Jahrhundert. Du darfst gerne an sowas glauben, kannst aber nicht erwarten, dass dir zugejubelt wird.
Moby A. schrieb: > Das ist kryptischer Kauderwelsch für Eingeweihte. Wieso? Das ist ganz normales C. Wo bleibt überhaupt die C-Version von deinem "Projekt"? mfg.
Gebt's einfach auf. Der versteht überhaupt nicht was ihr ihm sagen wollt. Insofern ist er in seiner kleinen AVR assembler Welt happy. Lassen wir's dabei bleiben.
Gu. F. schrieb: > Gebt's einfach auf. Man muss das Unmögliche versuchen, um das Mögliche zu erreichen.
Thomas E. schrieb: > Wieso? Das ist ganz normales C. Das ist es nun nicht. Das ist C++; C kennt keine Templates. Moby A. schrieb: > bin ich mit Asm immer heilfroh, einfachere Ausdrucksformen verwenden zu > können. Z.B. ohne künstliche Kreationen wie Datentypen Natürlich. Genau. "Datentypen". Braucht man nicht. Was man nicht mit Werten im Zahlenraum zwischen 0 und 255 ausdrücken kann, ist es nicht wert, gesagt zu werden.
Rufus Τ. F. schrieb: > Natürlich. Genau. "Datentypen". Braucht man nicht. Was man nicht mit > Werten im Zahlenraum zwischen 0 und 255 ausdrücken kann, ist es nicht > wert, gesagt zu werden. Warum so viel? Unsereins kriegte es an der Uni mit einem Assembler zu tun, von dessen zu Grunde liegender Maschine man nicht wusste, ob dessen Byte 0..63 oder 0..99 codiert. Ein Wort hatte 5 solcher Bytes plus Vorzeichen. Alles, was es Wert ist geschrieben zu werden, kann auch in einem Zeichensatz mit 64 Codes ausgedrückt werden.
:
Bearbeitet durch User
Gu. F. schrieb: > Moby A. schrieb: >> Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10k > > Die wir sicher gleich zu sehen kriegen. Da man für das bloße Hin- und Herschieben von Daten¹ zwischen den einzelnen Schnittstellen des µC nie und nimmer 10k Programmcode braucht, würden wir bei der Veröffentlichung von Mobbys 10k-Programm enttäuscht feststellen, dass der größte Teil dieser 10k einfach nur fixe Daten sind, bspw. Textstrings, Fonts oder Grafiken für die Benutzerinteraktion über ein LCD. Damit kann man auch locker ein paar MB voll bekommen, ohne dass die Übersicht darunter leidet. Insofern würde Mobys 10k-Code keine neuen Erkenntnisse vermitteln, so dass er ihn auch gleich für sich behalten kann. ——————————— ¹) Alles andere wäre ja keine typische 8-Bit-Anwendung mehr.
Jonny O. schrieb: > hmm - die µCs bei mir in der Bastelkiste fangen erst bei 128K an und > hören bei 1M auf (hab nur noch 32bit) Wenn Deine Projekte diese Größen rechtfertigen dann sollen sie das. Ich vermute aber eher daß Du programmsprachbedingt eher zu den Leuten gehörst die in 5 Jahren auf 64 Bit mit 1-10M Speicher umsteigen müssen ;-) Für einen Quadrokopter mag die Dimensionierung ja stimmen- da würde ich es als Bastler aber vorziehen eines der zahlreichen Modelle zu kaufen. Den Sinn des Selbstbaus mag ich da schlecht erkennen. Grafik-LCD Ansteuerung ist auch eines der wahrscheinlichen Ausschlußkriterien für 8-Bit, da brauchts dann eben massig Speicher. > Komplette > Projekte in ASM hätten auf längere Sicht die Portierbarkeit zunichte > gemacht und für die Firma großen finanziellen Schaden bedeutet. Das kann ich für eine Firma und große Projekte nachvollziehen. Für 8-Bit MSR /IOT langt AVR/ASM auf ewig. Da ist noch zuviel Luft drin ;-)
Zeig. Ein. Beispiel. Nein, Deine berühmten 20 Zeilen genügen nicht. Zeig ein vollständiges Beispiel. Oh, und lass' das "IoT" weg. Das ist, so wie Du es gebrauchst, unwahr.
Uhu U. schrieb: > Natürlich konnten auch die Menschen in der Altsteinzeit leben Natürlich kann man 8-Bit MSR in Asm machen. Der Witz ist: Es ist einfacher und effizienter. Dafür sind auch keine Zujubler nötig, wenn man die einfache, funktionsfähige, nicht größer als nötige Lösung längst in der Hand hält ;-) Thomas E. schrieb: > Wo bleibt überhaupt die C-Version von deinem "Projekt"? Die Frage stelle ich mir auch. Wo das doch alles so modern und hochproduktiv sein soll... A. K. schrieb: > Man muss das Unmögliche versuchen, um das Mögliche zu erreichen Versuch lieber Dein Möglichstes, das scheinbar Unmögliche (ASM ist manchmal einfach besser) zu begreifen ;-) Rufus Τ. F. schrieb: > Was man nicht mit > Werten im Zahlenraum zwischen 0 und 255 ausdrücken kann, ... macht man in zwei oder drei oder vier! Yalu X. schrieb: > Da man für das bloße Hin- und Herschieben von Daten¹ zwischen den > einzelnen Schnittstellen des µC nie und nimmer 10k Programmcode braucht, > würden wir bei der Veröffentlichung von Mobbys 10k-Programm enttäuscht > feststellen, dass der größte Teil dieser 10k einfach nur fixe Daten > sind, bspw. Textstrings, Fonts oder Grafiken für die Benutzerinteraktion > über ein LCD. Damit kann man auch locker ein paar MB voll bekommen, ohne > dass die Übersicht darunter leidet. Da irrst Du Dich aber gewaltig. So ein Netzwerk vieler Sensoren und Aktoren kann mit Protokollverarbeitung und IfThen Logik ganz schön komplex werden, insbesondere wenn die Absichten von Menschen im SmartHome zu ergründen sind! Was die Texte angeht ist das für ein kleines 2x16 Display und eine auszuliefernde HTML-Seite dagegen nicht der Rede wert.
@Uhu Uhuhu (uhu) >> ist, daß Du mit mir einen ASMler vor Dir hast der das nicht erst seit >> gestern macht und (wenn auch nur für eigene Zwecke) mehr als genug >> Projekte erfolgreich zu Ende gebracht hat. >Als Biebelforscher mit dem ASM-Turm auf dem Markplatz... YMMD! Fällt diese ASM-Diskussion nicht mittlerweile unter das Poliktverbot? Ist das nicht sogar ein moderne Form des Cyber-Terrorismus? 8-0
Rufus Τ. F. schrieb: > Nein, Deine berühmten 20 Zeilen genügen nicht. Zeig ein vollständiges > Beispiel. Das Beitrag "Kleines Tiny13 Sensorboard" ist ein vollständiges Beispiel. Das genügt vollauf.
Moby A. schrieb: > Der Witz ist: Es ist einfacher und effizienter. So nach dem Motto: beide Flügel sind gleich lang, besonders der linke? Ja, es ist tatsächlich ein Witz, wenn man eine Sache mit nichts anderem vergleicht und dann zu dem Schluss kommt, sie sei einfacher und effizienter...
Falk B. schrieb: > Fällt diese ASM-Diskussion nicht mittlerweile unter das Poliktverbot? Damit kennst Du Dich ja jetzt aus, stimmts? Im Gegensatz zu Dir muß ich aber keinen Frust ablassen sondern amüsiere mich. Morgen kanns für mich weitergehen, schönen Abend noch ;-)
@ Moby AVR (moby-project) Benutzerseite >Beitrag "Kleines Tiny13 Sensorboard" >ist ein vollständiges Beispiel. Das genügt vollauf. Wie süß, wir stricken uns einen ADC selber ;-) Es beschreibt deinen Programmiererhorizont nur allzu gut. Viel Spaß noch beim Bastlen (als Brotwerwerb ist es für dich eher nicht geeignet)
@ Moby AVR (moby-project) Benutzerseite >> Fällt diese ASM-Diskussion nicht mittlerweile unter das Poliktverbot? >Damit kennst Du Dich ja jetzt aus, stimmts? Scheint so. >Im Gegensatz zu Dir muß ich aber keinen Frust ablassen sondern amüsiere >mich. Uns. ;-) >Morgen kanns für mich weitergehen, schönen Abend noch ;-) Und täglich grßt das Murmeltier . . . https://de.wikipedia.org/wiki/Und_t%C3%A4glich_gr%C3%BC%C3%9Ft_das_Murmeltier (Meine Herrn, was kennt Wikipedia eigentlich NICHT?)
Moby A. schrieb: > Beispiel. > > Das > Beitrag "Kleines Tiny13 Sensorboard" > > ist ein vollständiges Beispiel. Das genügt vollauf. Ohne Schaltplan... Und da laberst du von "Dokumentation"?
Was anderes in dem Zusammenhang: Moby, Du wolltest doch als Frontend für deine Hausautomatisierung von SerialComInstruments, was bei Dir ja funktioniert hat, nach LabView umschwenken. Beispielbild hattest Du hier gepostet: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle" Seit dem habe ich diesbezüglich von Dir dazu nichts mehr gehört. Ist Dir die Anbindung an LabView inzwischen mit ASM gelungen?
:
Bearbeitet durch User
Moby A. schrieb: > Da irrst Du Dich aber gewaltig. So ein Netzwerk vieler Sensoren und > Aktoren kann mit Protokollverarbeitung und IfThen Logik ganz schön > komplex werden, > insbesondere wenn die Absichten von Menschen im SmartHome zu ergründen > sind! Hmm, ist das alles? Und dafür brauchst du 10k? Da habe ich schon eine Hausautomatisierung gesehen, die tat mit deutlich weniger Code sehr viel mehr als nur einfache Protokolle und eine Latte von If-Abfragen abzuarbeiten. Da waren u.a. richtige Regelungstechnik und noch ein paar Dinge mehr enthalten, die aus deiner Sicht zwar keine typischen 8-Bit-Anwendungen sind, aber – oh Wunder – trotzdem auf einem 8-Bit-Controller liefen. Ok, das Ganze war nicht in Assembler, sondern in C programmiert, da hat es der Programmierer natürlich auch nicht ganz so schwer gehabt ;-)
> Ohne Schaltplan... Und da laberst du von "Dokumentation"? Projekte, die Schaltpläne besitzen, sind niemals typische 8-Bit MSR-Anwendungen. BTW, schon 1983 durfte ich zuschauen, wie zwei Ings eine 8-Bit-MSR-Anwendung in Hochsprache gebaut haben. Die mußten dafür sorgen, daß die 4 Farbenwerke einer x-hundert-Tonnen Druckmaschine übereinander passen. Auf die Idee, das in ASM zu machen wären die nie gekommen. Hatte doch der PLM80 Compiler diese wohldurchdachten ASM-Bausteine im Bauch, die er präzise anordnete um auch mal eine 16-Bit-Intergerzahl auszurechnen. > Gebt's einfach auf. > Der versteht überhaupt nicht was ihr ihm sagen wollt. Insofern ist er > in seiner kleinen AVR assembler Welt happy. > Lassen wir's dabei bleiben. Ich werde mich an Jörg W's Rat halten und einfach jedesmal, wenn er mal wieder Dinge, die er nicht versteht, niedermachen will die "Beitrag melden"-Taste drücken. Es nervt einfach, wenn eine Diskussion über die Abbildung von GPIO's in C++ nur noch der It-Neandertaler zu Wort kommt, weil er das für sein Fachgebiet hält.
Carl D. schrieb: > Ich werde mich an Jörg W's Rat halten und einfach jedesmal, wenn er mal > wieder Dinge, die er nicht versteht, niedermachen will die "Beitrag > melden"-Taste drücken. Es nervt einfach, wenn eine Diskussion über die > Abbildung von GPIO's in C++ nur noch der It-Neandertaler zu Wort kommt, > weil er das für sein Fachgebiet hält. Ich kann mir nicht vorstellen dass du das auf Dauer durchstehst. So eine Hartnäckigkeit kenne ich bisher nur von K.B.
> Ich kann mir nicht vorstellen dass du das auf Dauer durchstehst. > So eine Hartnäckigkeit kenne ich bisher nur von K.B. Man darf sich auch schwer erreichbare Ziele setzen ;-)
Moby A. schrieb: > Jonny O. schrieb: >> hmm - die µCs bei mir in der Bastelkiste fangen erst bei 128K an und >> hören bei 1M auf (hab nur noch 32bit) > > Wenn Deine Projekte diese Größen rechtfertigen dann sollen sie das. > Ich vermute aber eher daß Du programmsprachbedingt eher zu den Leuten > gehörst die in 5 Jahren auf 64 Bit mit 1-10M Speicher umsteigen müssen > ;-) > Für einen Quadrokopter mag die Dimensionierung ja stimmen- da würde ich > es als Bastler aber vorziehen eines der zahlreichen Modelle zu kaufen. > Den Sinn des Selbstbaus mag ich da schlecht erkennen. Grafik-LCD > Ansteuerung ist auch eines der wahrscheinlichen Ausschlußkriterien für > 8-Bit, da brauchts dann eben massig Speicher. > >> Komplette >> Projekte in ASM hätten auf längere Sicht die Portierbarkeit zunichte >> gemacht und für die Firma großen finanziellen Schaden bedeutet. > > Das kann ich für eine Firma und große Projekte nachvollziehen. Für 8-Bit > MSR /IOT langt AVR/ASM auf ewig. Da ist noch zuviel Luft drin ;-) Ich finde es auch absolut okay, wenn man im Hobby gerne und viel ASM benutzt. Ich finde es (hab ich glaube ich schonmal erwähnt) auch toll wenn man sich so gut mit der Architektur eines µCs auskennt und ao hardwarenah programmieren kann. Mach das ruhig weiter so Moby und lass dich da nicht verunsichern. Schlussendlich ist doch das Wichtigste, dass man Spaß am Hobby hat. Klar - du provozierst natürlich auch gerne - Hand aufs Herz ;-) Aber ich habe das Gefühl, dass sich die Leute auch gerne provozieren lassen. Naja nur meine 2 Cents ;)
Moby A. schrieb: > Natürlich kann man 8-Bit MSR in Asm machen. Für sehr einfache Anwendungen kann man das, für kompliziertere nicht. > Der Witz ist: Es ist einfacher und effizienter. Nein, ist es nicht. Assembler ist unlesbar, chaotisch und kryptisch, schon die Atmel-Variante hat über 130 Instruktionen. Die Hochsprachen sind dank Strukturierung und viel weniger Befehlen einfacher, übersichtlicher, klarer, leichter zu erlernen und einfacher zu benutzen. Hochsprachen sparen dadurch die wichtigste und kostbarste Ressource von allen ein: die Lebenszeit der Entwickler. Die ist so wichtig und kostbar, weil sie einerseits endlich ist und andererseits, anders als Hardware-Ressourcen, nicht für Geld zugekauft werden kann. Assembler zu benutzen, wo man auch ebensogut eine Hochsprache einsetzen könnte, ist nurmehr eine anachronistische und dumme Verschwendung der kostbarsten aller Ressourcen.
@Jonny O.: Niemand spricht Moby das Recht ab, seine Zeit mit was aus immer zuzubringen. Solange er anderen das auch zugesteht. Wie gut er das kann sieht man hier: Beitrag "C++ für Mikrocontroller" Es ging nicht um "ist C++ besser als ...", sondern um Fragen innerhalb der C++-Welt. Da braucht es keine "ASM ist besser"-Diskussion. Anderst hier: Die Überschrift lautet "ASM über alles", dann muß auch genau darüber diskutieret werden dürfen.
> Assembler zu > benutzen, wo man auch ebensogut eine Hochsprache einsetzen könnte, ist > nurmehr eine anachronistische und dumme Verschwendung der kostbarsten > aller Ressourcen. So wie ich Moby verstanden habe, macht er das aber als Hobby. Wenn es ihm Spaß macht mit ASM zu programmieren ist das doch okay. Es gibt doch viel verrücktere Hobbys. Manche Leute bauen sich aus TTL-Gattern ganze Computer zusammen. Im Prinzip total irre, aber wenns Spaß macht? Lebenszeit ist nur dann verschwendet, wenn wir sie ohne Freude verbringen. Ich dachte mir mal, weil doch bald Weihnachten ist, kann man mal so einen besinnlichen Spruch raus hauen. ;-D
Carl D. schrieb: > @Jonny O.: > Niemand spricht Moby das Recht ab, seine Zeit mit was aus immer > zuzubringen. Solange er anderen das auch zugesteht. Wie gut er das kann > sieht man hier: > > Beitrag "C++ für Mikrocontroller" > > Es ging nicht um "ist C++ besser als ...", sondern um Fragen innerhalb > der C++-Welt. Da braucht es keine "ASM ist besser"-Diskussion. > Anderst hier: Die Überschrift lautet "ASM über alles", dann muß auch > genau darüber diskutieret werden dürfen. Hi Carl, Wie gesagt: Moby provoziert - und das weiß er auch. Allerdings könnte man ihn auch ignorieren, wenn man nicht drauf anspringen will. Er hindert ja niemanden daran c zu benutzen.
Moby A. schrieb: > IfThen Logik ganz schön komplex werden, Seit wann kann der AVR-Assembler IfThen zur Laufzeit?
> Manche Leute bauen sich aus TTL-Gattern ganze Computer zusammen. Wenn die dann aber in jedem Thread über "Single-Chip-Microcontroller" erklären wollen, daß ihre TTL-Lösung besser ist und nur "immer besser sein kann", dann ist Schluß mit lustig. Du solltest dich mal mit dem Phänomen "Moby" beschäftigen, das ist nicht der "kleine Dicke, der von allen gehänselt wird", den er gerne mal gibt. > Er hindert ja niemanden daran c zu benutzen. Stimmt, nur unterhalten darf man sich darüber nicht, ohne sein Dazwischengeschreie ertragen zu müssen.
:
Bearbeitet durch User
Carl D. schrieb: > daß ihre TTL-Lösung besser ist und nur "immer besser sein kann", dann ist > Schluß mit lustig. Nee, erst dann wirds erst richtig lustig.
Uhu U. schrieb: > Nee, erst dann wirds erst richtig lustig. ... aber nur für Masochisten umd Mobys ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Was soll daran übersichtlich sein? > Das ist kryptischer Kauderwelsch für Eingeweihte. > Dessen Studium ist für 8-Bit MSR überflüssig ;-) Dann zeig doch mal, wie eifach es in Assembler gehen würde! Eine universell brauchbare Maximum-Funktion kann auch sehr gut bei 8-Bit-MSR auftreten. Ich warte auf eine Antwort oder sehe es als definitives Eingeständnis, dass du nicht nur auf dem Holzweg bist, sondern noch nicht mal rudimentär gültige Argumente vorbringen kannst.
Jonny O. schrieb: >> Assembler zu benutzen, wo man auch ebensogut eine Hochsprache einsetzen >> könnte, ist nurmehr eine anachronistische und dumme Verschwendung der >> kostbarsten aller Ressourcen. > > So wie ich Moby verstanden habe, macht er das aber als Hobby. Wenn es > ihm Spaß macht mit ASM zu programmieren ist das doch okay. Es gibt doch > viel verrücktere Hobbys. Natürlich. Der eine programmiert gerne in Assembler, ein anderer träufelt sich heißes Wachs auf die Geschlechtsteile. Damit habe ich überhaupt kein Problem, solange sie mich damit in Ruhe lassen. ;-)
Jonny O. schrieb: > Wie gesagt: Moby provoziert - und das weiß er auch. Allerdings könnte > man ihn auch ignorieren, wenn man nicht drauf anspringen will. Er > hindert ja niemanden daran c zu benutzen. Er zerstört Threads zu anderen Programmiersprachen mit seinem penetranten, provozierenden und beleidigenden Missionieren. Insofern hindert er streng genommen zwar niemanden C zu benutzen, aber er hindert andere daran, sich ungestört darüber auszutauschen.
Sheeva P. schrieb: > aber er hindert andere daran, sich ungestört darüber auszutauschen. Nochmal: in solchen Fällen, bitte „Beitrag melden“.
Sheeva P. schrieb: > Er zerstört Threads zu anderen Programmiersprachen So in der Art wie dieser (sein) Tread zerstört wird ? > penetranten, Ja > provozierenden Ja > und beleidigenden Er wird erheblich heftiger attackiert > Missionieren. Ja Es ist kein Geheimniss das man statt mit Moby auch mit einer Parkuhr über den ASM -> 'alle anderen Sprachen' Konflikt diskutieren könnte. Selbst Moby macht kein Geheimniss aus seiner Tiny + ASM Fixierung. Während Moby Gebetsmühlenartig die immer gleichen (nicht)Argumente bringt und auch überhaupt nicht vorhat sich davon abbringen zu lassen wird es auf der 'Gegenseite' immer verbissener. Ich bin überaupt nicht seiner Meinung, aber von seiner Fähigkeit selbst absolute Tiefschläge mit Herablassung statt Blutspuckend zu beantworten könnten sich hier manche eine Scheibe abschneiden. Was erwartet Ihr ? Es wird einfach nicht passieren das sich am Ende aller Diskussionen ein geläuterer Moby in seinen 'Kerninghan / Ritchie' vertief. Spult Euch gerne weiter auf, werdet beleidigend, zerreist alles was Mob hier ins Netz stellt aber es ist nicht Moby der sich damit lächerlich macht.
Moby A. schrieb: > Für jeden Zweck die richtigen Mittel. > Die AVR-Reihe bis hoch zum XMega stemmt einen Großteil typischer 8-Bit > MSR Apps, wobei die Verwendung von Asm den Einsatzhorizont noch einmal > ordentlich ausdehnt. Was ist daran nur so schwer zu verstehen? Ganz einfach: Du hast eine merkwürdige Auffassung von "typischen 8-Bit-Anwendungen". 99,9% der Entwickler sind da anderer Ansicht als Du. Wenn diese einen ATmega328 nehmen, dann nehmen sie ihn, um ihn auch auszunutzen. Denn sonst würden sie ja einen ATmega168. Während Du nur 0,1% eines ATmegas produktiv nutzen kannst, packen da andere Leute Anwendungen rein, von denen Du nur zu träumen wagst. Das sind typische 8-Bit-Anwendungen! Deine 23-Zeilen-Assembler-Programme sind einfach nur Verschwendung und lassen den Großteil der AVR-HW einfach brachliegen. Du bist also kein Sparfuchs, sondern eher ein Verschwender sondergleichen.
Frank M. schrieb: > Während Du nur 0,1% eines ATmegas produktiv nutzen kannst Ähm, war es nicht Moby der hier in der Kritik steht provozierende und unbewiesene Nichtargumente zu bringen ? Ich denke es steht ausser Frage das der ideale ASM Code eine MCU immer besser ausnutzt als der ideale C Code. Der Punkt über den hier m.E. überwiegend Einigkeit herrscht ist der, das ASM ab einer gewissen Größe von Menschen nicht mehr annähernd ideal zu schreiben ist und ein C Compiler da bessere und schnellere Arbeit abliefert. Ich kann mich noch gut an Zeiten erinnern in denen es oft keinen Weg an ASM vorbei gab weil Compiler und MCUs arg beschränkt waren. ASM hat bis heute seine Daseinsberechtigung. Sicher nicht in der Form wie Moby das propagiert, aber bis heute muß ich teilweise in den ASM Code schauen weil Compiler durchaus manchmal Fehler machen (sehr selten) die im Quellcode nicht zu erkennen sind. Gerade die 'optimierungen' mancher Compiler können einem echt die Karten legen. Z.B. beim Xmega den Takt umschalten geht in GCC je nach Optimierungsstufe mal und mal nicht. Grund ist das zwischen dem freischalten und beschreiben der Taktquellenregister nur x (?) Zyklen vergehen dürfen. Das scheint GCC nicht zu wissen und nicht zu berücksichtigen. Baue ich nicht vorhandenen Hardware in Code nach und brauche Taktgenaues Timing führt auch nichts an ASM vorbei. Ein Umstand der übrigens häufig durch brutal hohe Takte und fette Controller für kleine Aufgabe überdeckt wird. Die sind dann trotz verschwenderischer Programmierung immer noch schnell genug. Ein Punkt um den es Moby übrigens häufg geht und wo er nicht komplett unrecht hat. Man kann also sagen das man ASM Grundlagen beherrschen sollte auch wenn man C schreibt. Als ASM Coder braucht man aber nicht zwangsläufig C Kenntnisse. Mist, jetzt hör ich mich schon an wie Mobys Wassertträger ...
Michael K. schrieb: > Sheeva P. schrieb: >> Er zerstört Threads zu anderen Programmiersprachen > So in der Art wie dieser (sein) Tread zerstört wird ? Wenn ich das richtig sehe, haben anfangs mehrere Leute versucht, sachlich über sein Thema zu diskutieren. Daß der Thread trotzdem abgeglitten ist, liegt vor allem an Mobys vorangegangenen Provokationen, Beleidigungen und penetranten Missionierungen -- zumal das Thema des Threads nichts anderes als die Fortführung der Missionierung mit anderen Mitteln ist. >> und beleidigenden > Er wird erheblich heftiger attackiert Mag sein, aber zuerst gingen die Attacken vom ihm aus -- und schon unsere Mütter haben gewußt: wie man in den Wald hineinruft, so schallt es wieder heraus. Das ist schade, aber menschlich. ;-) Andererseits verstehe ich die Verbissenheit mancher Diskutanten nicht. Solange das Thema aber auf Assembler-Threads beschränkt bleibt, ist es doch ausgesprochen unterhaltsam. > Es ist kein Geheimniss das man statt mit Moby auch mit einer Parkuhr > über den ASM -> 'alle anderen Sprachen' Konflikt diskutieren könnte. > Selbst Moby macht kein Geheimniss aus seiner Tiny + ASM Fixierung. Hm... er bestreitet, daß es sich um eine Fixierung handelt, und behauptet stattdessen, der Rest der Welt sei aus Gründen der Angeberei und bewußten Ressourcenverschwendung auf Hochsprachen fixiert... > Spult Euch gerne weiter auf, werdet beleidigend, zerreist alles was Mob > hier ins Netz stellt aber es ist nicht Moby der sich damit lächerlich > macht. Das stimmt. Moby macht sich hingegen mit seiner totalen Unzugänglichkeit für rationale Argumene lächerlich, insofern besteht Gleichstand. ;-)
Michael K. schrieb: > Ich denke es steht ausser Frage das der ideale ASM Code eine MCU immer > besser ausnutzt als der ideale C Code. Das wird diesseits bestritten. Idealer Code ist immer derselbe, egal womit er ursprünglich entwickelt worden ist. Ein perfekter Compiler würde daher exakt denselben, eben perfekten Code erzeugen, wie der perfekte Assembler-Programmierer, nämlich den einen, perfekten Code. Wobei auch dabei ja noch immer die Frage bestehen bleibt, nach welchen Kriterien ein Code denn als ideal gälte. Schließlich folgt so ein Code mehreren, zum Teil konkurrierenden Zielen. Also was ist idealer Code? Bei minimierter Laufzeit? Minimiertem Flash- oder RAM-Verbrauch? Minimiertem Arbeitsaufwand des Entwicklers? Welche Rolle spielen Pfleg-, Wart- und Erweiterbarkeit, wie steht es um die Funktionalität? Gibt es da objektive, allgemein akzeptierte und einwandfrei meßbare Kriterien? Insofern ist die angebliche Ressourcenverschwendung durch Hochsprachen, die Moby hier so gerne behauptet, letztlich nur eine Kritik an den Optimierern real existierender Compiler. Wobei zu deren Ehrenrettung gesagt werden muß, daß die meisten Compiler nicht für winzigkleine Mikrocontrolleranwendungen, sondern für größere Umgebungen und Programme optimieren.
Sheeva P. schrieb: > er bestreitet, daß es sich um eine Fixierung handelt Ja, das behaupten immer alle von sich selbst. Verbohrt und verblendet sind immer nur die anderen. Ich habe mich selber schon recht eindeutig über Mobys innere Haltung geäussert. Tatsächlich gab es in Diskussionen Momente in denen er Argumenten zugänglich war und man klar erkennen konnte das er kein Idiot ist. Auf jede Form von Druck oder negativer Haltung schaltet der nur einfach ins 'Notlaufprogramm' und läßt alles abtropfen was ihm nicht genehm ist. Ich finde es einfach faszinierend das sobald Kommunikation in Schriftform stattfindet, die Diskutanten sich einen Dreck darum scheren wie der Mensch gestrickt ist der da auf der anderen Seite sitzt. Plötzlich zählt nur noch die eigene Wahrnehmung und die wird jedem um die Ohren gehauen ohne sich darum zu kümmern ob dieser Weg zu irgendeiner Verständigung führt. Ich finde Moby ist so eine art Institution hier. Man kann sich über ihn aufregen, muß es aber nicht. Die Reaktionen die er provoziert zeigen aber auch wie es mit der Offenheit gegenüber anderen Sichtweisen und der Fähigkeit sich in andere reinzuversetzen bei seinen Kontrahenten ausschaut. Mir würde etwas fehlen in diesem Forum wenn Moby plötzlich die Dinge so sehen würde wie alle anderen. Da gibt es ganz andere und ganz andere Sichtweisen die mit die Galle hochkochen lassen. Programmiersprachen lösen im allgemeinen nicht solche Emotionen in mir aus.
Sheeva P. schrieb: > Wobei zu deren Ehrenrettung > gesagt werden muß, daß die meisten Compiler nicht für winzigkleine > Mikrocontrolleranwendungen, sondern für größere Umgebungen und Programme > optimieren. Autsch. Soll heissen das C Compiler für MCU nicht geeignet sind weil die nur für größere Systeme optimieren können ? (binäre Sichtweise) Das wird Moby gerne hören ;-)
Michael K. schrieb: > Soll heissen das C Compiler für MCU nicht geeignet sind weil die nur für > größere Systeme optimieren können ? (binäre Sichtweise) > Das wird Moby gerne hören ;-) Auf einem sehr kleinen uC kann der Mensch vielleicht mit Kreativität noch etwas mehr herausholen als ein Compiler, der seine Stärken dann ausspielen kann, wenn der Mensch die ganzen Graphen an Abhängigkeiten nicht mehr überblicken kann. Ich denke, da sind wir mit Moby einigermassen einverstanden. Der Punkt der Diskussion ist eigentlich, dass Moby behauptet, seine Ansichten würden auch für grosse Programme gelten. Immer mit der selben Dikussionsmechanik: Moby: "Gilt prinzipiell auch für grosse Programme." Benutzer: "Ok, dann zeig doch mal für Fall X." Moby: "Das ist für mich aber nicht typisch 8-Bit." Benutzer: "Ah, dann sind wir uns ja einig, für sehr kleine Dinge mögen deine Ansichten ok sein." Moby: "Gilt prinzipiell auch für grosse Programme." Benutzer: "Ok, dann zeig doch mal..." usw.
Sheeva P. schrieb: > Das wird diesseits bestritten. Idealer Code ist immer derselbe, egal > womit er ursprünglich entwickelt worden ist. Auch bei idealem Code kann es verschiedene Möglichkeiten geben.
Michael K. schrieb: > das > ASM ab einer gewissen Größe von Menschen nicht mehr annähernd ideal zu > schreiben Für mich persönlich ist die Größe bereits da erreicht, wo ich in C mit einfachen Vergleichsoperatoren arbeiten kann. Eine Zeile wie
1 | if(val1 > val2){... |
wird vom XC8 immer richtig ins Maschinencode übersetzt und zwar egal ob die Werte 8bit, 16bit oder 24bit floats sind. Früher habe ich PICs oft in Assembler programmiert. Was habe ich geflucht und Zeit verloren, weil ich an solchen Stellen viele Fehler bei der Auswertung des Carry-Flag gemacht habe. Es entspricht einfach nicht meiner Denke. Wenn ich den ASM Code in Prosa so kommentieren muss, dass die Programmstruktur für mich später erkenntlich ist dann schreibe ich es lieber gleich in C. Das Ergebnis wird dadurch nicht größer, oft ist das Gegenteil der Fall. In C kann ich bei geschachtelten Vergleichen schneller erkennen, ob sich etwas zusammenfassen und verkürzen lässt. Oft fasst der Compiler C-Code skrupellos zu einem ASM Code zusammen, vor dem es mich grausen würde. Beispiel: Test mehrerer auf unterschiedlichen Ports liegenden Signale auf High:
1 | if ((InSensor1 == 1) |
2 | && (InSensor2 == 1) |
3 | && (InSensor3 == 1) |
4 | && (InSensor4 == 1)) |
5 | {
|
würde ich in ASM mit 4 mal BTFSS GOTO schreiben und entspr. kommentieren. Das sind dann 8 Maschinenbefehle. Der Compiler (XC8 free) macht daraus
1 | 03B0 1A85 BTFSC PORTA, 0x5 |
2 | 03B1 1E05 BTFSS PORTA, 0x4 |
3 | 03B2 2BB8 GOTO 0x3B8 |
4 | 03B3 1A87 BTFSC PORTC, 0x5 |
5 | 03B4 1E07 BTFSS PORTC, 0x4 |
6 | 03B5 2BB8 GOTO 0x3B8 |
und gewinnt mit 6 Befehlen 25% Land. Natürlich könnte ich solche Tricks selbst in ASM nutzen und sie mit Prosa umschreiben. Aber dann schreibe ich lieber gleich in C die Programmstruktur lesbar hin und ausserdem ist mein Prosa später vielleicht für mich verständlich, für einen Aussensteheden meistens mindestens erklärungsbedürftig. Die C Syntax ist dagegen für alle verbindlich, C ist nun mal die Weltsprache der µC.
:
Bearbeitet durch User
Witkatz :. schrieb: > Was habe ich geflucht und Zeit verloren, weil > ich an solchen Stellen viele Fehler bei der Auswertung des Carry-Flag > gemacht habe. Es entspricht einfach nicht meiner Denke. Das könnte durchaus erklären, warum Moby so versessen auf sein Assembler ist: Es ist insofern einfacher, dass dort alles per Fleissarbeit zusammengestiefelt wird, dafür ist fast kein abstraktes Denken erforderlich. Man kann sich Schritt für Schritt vorstellen, was der Prozessor macht, wie bei einem Kind, das mit der Finger-Methode rechnet...
Michael K. schrieb: > Tatsächlich gab es in Diskussionen Momente in denen er > Argumenten zugänglich war und man klar erkennen konnte das er kein Idiot > ist. Stimmt. Allerdings ist er in so einer Situation wohl nur nicht in Form. Witkatz :. schrieb: > Oft fasst der Compiler C-Code skrupellos zu einem ASM Code zusammen, vor > dem es mich grausen würde. [...] Natürlich könnte ich solche Tricks > selbst in ASM nutzen und sie mit Prosa umschreiben. 'Skrupellos' ist gut! Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert eventuell komplett neuen Assembler-Code. In 'C' muss man vielleicht nur einen Datentyp ändern. Den Code lässt man machen.
Witkatz :. schrieb: > Für mich persönlich Du sagts es. Persönliche Wahrnehmung. Ich habe eine ganz ähnliche wie Du, Moby hat eine ganz andere wie wir. Da wirklich jede exotische MCU einen Assembler hat aber nur fast jede einen C Compiler (unbewiesene Behauptung) steht das 'Weltsprachenargument' auf tönernen Füssen. Solche Behauptungen stehen auf der gleichen Stufe wie das wofür Moby ans kreuz genagelt wird. Mir wollte vor Jahren ein Softwareinformatiker erzählen C sei Mausetot, jetzt wo es die erste MCU mit Java Interpreter gäbe. Das Argument 'gilt im Prinzip auch für ...' stimmt doch auch. Wenn jemand in der Lage wäre das Projekt noch zu überblicken, man modular genug schreiben würde das auch mehrere daran arbeiten könnten und es weder Zeit noch Kostendruck gäbe, dann würde auch ein großen Projekt von ASM only profitieren können. Es wäre nur zu definieren worin dieser Profit bestünde. Ich stamme aus der Generation C64 und kenne durchaus den Reiz auf unterster Ebene mit der Hardware zu kommunizieren und trickreiche Laufzeitenhacks zu ersinnen die auf die Art mit C nicht möglich sind. Dein 6 Befehl Beispiel liesse sich in dreien lösen wenn alles auf einem Port läge. Port laden, ver-unden, test auf null + sprung. Ich schätze die Bequemlichkeiten von C, aber trotzdem schüttel ich manchmal den Kopf wie wenig sich heute noch darum gekümmert wird was da eigentlich im Hintergrund abläuft. Was haben wir nicht alles mit realen 4Mhz (8031), 64B Ram und einem 8K Eprom gelöst. Was an Power fehlte wurde durch Gehirnschmalz ersetzt. Tabellen im Eprom statt Echzeitberechnungen, Zyklenoptimierte Berechnungsroutinen als Warteschleife statt hirnfreier delay_ms(100) Konstruktionen. Klar, sowas ist heute nicht mehr nötig, aber deswegen kann das immer noch Spaß machen. Dieses ganze Behauptungsgefussel wer wie blöd ist und wer den universellen Plan hat was geht können wir uns wirklich sparen.
P. M. schrieb: > Auf einem sehr kleinen uC kann der Mensch vielleicht mit Kreativität > noch etwas mehr herausholen als ein Compiler, der seine Stärken dann > ausspielen kann, wenn der Mensch die ganzen Graphen an Abhängigkeiten > nicht mehr überblicken kann. Das ist genau das Problem: Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, weil das Flash nur zum kleinen Teil ausgenutzt wird. Und bei großen Programmen optimiert der Compiler besser als der Mensch. Vor > 20 Jahren hätte ich Moby sogar Recht gegeben. Ich kann mich noch an den gruseligen Code erinnern, der aus einen 8051-C-Compiler kam, wenn man externes RAM angesprochen hatte. Aber das war auch eine Kiste, die nie für C-Compiler gebaut wurde. Beim ATmega sieht man dagegen, daß er bereits hochsprachenkomptibel entwickelt wurde. Da sehe ich mit ASM keinerlei Vorteile mehr. Gruß, Stefan
Ralf G. schrieb: > Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert > eventuell komplett neuen Assembler-Code. DAS ist z.B. eines der schlagkräftgsten Argumente für Hochsprache.
Michael K. schrieb: > Da wirklich jede exotische MCU einen Assembler hat aber nur fast jede > einen C Compiler (unbewiesene Behauptung) steht das > 'Weltsprachenargument' auf tönernen Füssen. Hat Kurts CPU einen C-Compiler? Wohl kaum...
Michael K. schrieb: > dreien lösen wenn alles auf einem > Port läge. Port laden, ver-unden, test auf null + sprung Dazu müsste aber ein Befehl existieren, der n Bits eines Registers verknüpfen kann. Sonst werden aus dem einen ver-unden viele einzelne Operationen. mfg.
Uhu U. schrieb: > Hat Kurts CPU einen C-Compiler? Wohl kaum... Du velwechserst da was. Die CPU ist von Josef. Kurt bewegt sich auf anderen Abgründen.
Michael K. schrieb: > Z.B. beim Xmega den Takt umschalten geht in GCC je nach > Optimierungsstufe mal und mal nicht. Grund ist das zwischen dem > freischalten und beschreiben der Taktquellenregister nur x (?) Zyklen > vergehen dürfen. > Das scheint GCC nicht zu wissen und nicht zu berücksichtigen. Für den GCC sind das Zuweisungen an volatile SPeicheradressen, mehr nicht. Wollte man das AVR-Backend des Compilers tatsächlich mit solchen HW-Spitzfindigkeiten bemühen, dann würde man dies als Intrinsic-Funktion anbieten, also Quasi Spezial-ASM-Code injizieren, oder, außerhalb des Compilers, in der RT-(Include-)Lib per Macro Inline-Assembler einfügen würde. Das ist nämlich einer der wenigen Fälle, wo jeder hier zustimmen würde, daß ASM die einzige Wahl ist: Wenn es um Takt-genaue Ausführung geht. (jetzt wird gleich wieder ein Kasper kommen, der sich hier einen Halbsatz rauspickt und laut "Ätsch-Bätsch" schreit)
Michael K. schrieb: > Was haben wir nicht alles mit realen 4Mhz (8031), 64B Ram und einem 8K > Eprom gelöst. Was an Power fehlte wurde durch Gehirnschmalz ersetzt. Genau das wird uns immer von Moby erzählt, aber auf Nachfrage mit nichts belegt. In diesem Thread wurde Moby gefühlte hundert mal nach Beispielen, Projekten und was weis ich noch alles gefragt. Ergebnis --> NULL! Vor diesem Hintergrund kann so ein Gehabe wie: Moby A. schrieb: > Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10K. Das > sagt ein durchschnittlicher Asm-Programmierer. kann einen schon mal leicht ankot*** Wenn ich dieses Projekt zu sehen bekäme (egal wie effizient oder auch nicht) wäre ich sofort still und der Moby hätte einen guten Teil Glaubwürdigkeit erlangt.
Stefan K. schrieb: > Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, > weil das Flash nur zum kleinen Teil ausgenutzt wird. > Und bei großen Programmen optimiert der Compiler besser als der Mensch. Händische Optimierungen sind bei weitem nicht immer Codegrößenoptimierungen. Unter ASM kann ich spezielle Teile auf den Takt genau optimieren. Unter C müsste ich mir erstmal einen Timer + IRQ schnappen um auf ein festes Timing zu kommen. Blöd nur wenn alleine die IRQ Bearbeitung mehr Zyklen kostet als ich zur Verfügung habe. Ja, 100Mhz + 32bit lösen auch dieses Problem... Ich habe mal Code überarbeiten müssen bei dem der Autor in C Konstruktionen gewählt hat die auf unglaublichen Umwegen zum Ziel geführt haben. Hätte der Compiler sinngemäß verstanden was da mal rauskommen soll, hätte der optimieren können, aber in dem Fall ergab das einfach ein Codemonster was die 8K Begrenzung gerissen hat. Der Keil Compiler fing an extrem uncoole moves zu machen als er an die Codegrenze kam. Da war vieles nicht nachvollziehbar weil der völlig aus dem Tritt kam. Erst massives Abspecken und SDCC haben es dann gebracht. Die Hardware war unveränderlich, weil bereits in größeren Stückzahlen gebaut und auslieferbereit. Es gab ein prinzipbedingtes Timingproblem das unter ganz speziellen Umständen auftrat und das produkt quasi unbenutzbar machte. In so einem Fall ist es gut ein bißchen 'Moby' zu sein.
Michael K. schrieb: > In so einem Fall ist es gut ein bißchen 'Moby' zu sein. Natürlich ist es von Nutzen, das ASM-Handwerk zu beherrschen. Beherrschen heißt aber auch, die Grenzen zu kennen.
Gu. F. schrieb: > Wenn ich dieses Projekt zu sehen bekäme (egal wie effizient oder auch > nicht) wäre ich sofort still Das glaube ich zwar nicht, weil dann die Diskussion losginge 'das kann C aber noch viel besser', aber sei es drum. Ich sage auch nicht das man sich das heute noch antun muß. Warum soll ich mich mit einem 8085 oder 8031 abquälen wenn es für einen Bruchteil des Preises MCUs gibt die das alles ohne zucken nebenbei erledigen. Ich habe auch keine Beispielcodes, weil ich von >10Jahren mit dieser Art der Selbstkasteiung aufgehört habe. Ich betreibe kein Codemuseum, das ist alles schon lange dem Verfall anheim gefalen. Gu. F. schrieb: > Vor diesem Hintergrund kann so ein Gehabe wie: > Moby A. schrieb: >> Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10K. Das >> sagt ein durchschnittlicher Asm-Programmierer. > kann einen schon mal leicht ankot*** Er wurde massiv angegriffen und hat damit nur gesagt das er bis hoch zu 10K noch den Überblick über seinen Code behält. Was auch immer er da geschrieben hat ist mir auch egal, aber ich sehe nicht das mich sowas ankot**n müsste. Lass Ihn doch. Er macht tiny, nichts als tiny, ASM nichts als ASM. Natürlich fehlt da der Blick was auf anderen Platformen möglich ist und wo die Schwierigkeiten bei größeren Projekten liegen. Ich verstehe nur nicht das Moby mit Gewalt auf den rechten Pfad zurück geführt werden soll. Er bringt provokante Sprüche, er bekommt provokante Sprüche. Verbohrt und selbstreferenziert sind beide Seiten. Argumente wie: 'glaub ich ihm nicht bis ich nicht seinen Code gesehen habe' hören sich so ein wenig nach Bindl an (Wenn man es nicht wiegen kann ist es real nicht vorhanden) Mit der Coder Erfahrung die sich die meisten Diskutanten hier selbst zuschreiben sollte jedem klar sein das mit handoptimierten ASM auf den alten MCUs / Prozessoren Dinge erschaffen wurden für die man heute erheblich stärkere hardware projektieren würde. So, das kostet mir zuviel zeit, macht mal eine weile ohne mich weiter :-)
Michael K. schrieb: > C Compiler (unbewiesene Behauptung) steht das > 'Weltsprachenargument' auf tönernen Füssen. Ja sorry, es war flapsig ausgedrückt. Ich kann mich nur auf die bastelfreundlichen µC beziehen und selber benutze ich beim Basteln bis jetzt nur 8bit PICs. Un da schätze ich mir die Weltsprache C. Wenn ich ein Programmbeispiel im Netz suche, dann kann ich von C-Codeschnipseln profitieren, sogar wenn sie für AVR oder andere µC erstellt wurden. ASM Codeschnipsel bringen mir dagegen gar nichts, oder wenn dann nur die Kommentare etwas. Michael K. schrieb: > Ich schätze die Bequemlichkeiten von C, aber Ja, weil du die Wahl hast. Ein ASM Freak versperrt sich die Option. Man kann darüber duskutieren aber es bleibt seine Entscheidung.
@Michael K.: Da bin ich 100% Deiner Meinung. Ein DMX-Empfang auf einem mit 8Mhz laufenden 8031 ging definitiv nur in Assembler, und auch da war es sehr knifflig. Allerdings stellen heutige Microcontroller immer mehr Möglichkeiten zur Verfügung, die dieses bitgenaue Timing immer mehr in die Hardware verlagern können, z.B. durch DMA, Timer oder eine andere Hardware-Schnittstelle. Ein STM32Fxxx kann z.B. das Bitttiming zur Ansteuerung eines WS2812-Ledstrangs komplett per DMA übernehmen, die damit zur Nebenaufgabe mit wenigen % CPU-Auslastung mutiert. Ein Atmega ist dagegen mit dem UART-Empfang und der gleichzeitigen WS2812-Ansteuerung komplett ausgelastet. Früher hatten diese Spezial-Optimierungen Sinn, weil es einfach keine andere Möglichkeit gab. Aber heute ist ein Controller mit diesen Features direkt daneben im Regal für praktisch denselben Preis. > Ich habe mal Code überarbeiten müssen bei dem der Autor in C > Konstruktionen gewählt hat die auf unglaublichen Umwegen zum Ziel > geführt haben. Solche Konstrukte gibt es leider auch zur Genüge in Asm. Das Problem dabei ist, daß dort diese "Fehlkonstruktion" viel weniger ersichtlich ist und damit auch viel seltener korrigiert wird. Viele Grüße, Stefan
Witkatz :. schrieb: > 8bit PICs Der muss noch ... PICs ? 8 bit ? Alle Zutaten für zwei weitere Flame War Threads vorhanden. Beides geht ja garnicht wenn man dem Forum glauben schenken will. (ruhig Blut, benutze ich unter anderem auch)
P. M. schrieb: > Das könnte durchaus erklären, warum Moby so versessen auf sein Assembler > ist: Es ist insofern einfacher, dass dort alles per Fleissarbeit > zusammengestiefelt wird, dafür ist fast kein abstraktes Denken > erforderlich. Man kann sich Schritt für Schritt vorstellen, was der > Prozessor macht, wie bei einem Kind, das mit der Finger-Methode > rechnet... Hier mach Moby aber nicht wirklich eine gute Figur, z.B. beim Vergleich einer 32-Bit Zahl gegen eine Konstante: Sein Code ist nicht nur länglich sondern auch falsch, und das obwohl es nur ein unsigned Vergleich ist. Beitrag "Re: C versus Assembler->Performance" Wober Mobys eigentliche Lösung darin besteht, solche Arithmetik als "nicht typisch für 8-Bit Anwendungen" zu definieren. Übrigens wäre der Code auch bei einem 16-Bit Vergleich falsch gewesen...
Danke für die vielen interessanten Rückmeldungen. Ich werde mich bemühen, nach und nach möglichst vielen eine adäquate Antwort zu geben: Falk B. schrieb: > Wie süß, wir stricken uns einen ADC selber ;-) > Es beschreibt deinen Programmiererhorizont nur allzu gut. Das dürfte auch für Dich schnell recht bitter schmecken wenn Du die Aufgabe innerhalb Deines C-Programmiererhorizonts besser lösen solltest ;-) Uhu U. schrieb: > Ohne Schaltplan... Und da laberst du von "Dokumentation"? Das zeugt nun nicht gerade von "Experte", für dieses hinreichend beschriebene, bis zum Erbrechen diskutierte Projektchen noch eines Schaltplans zu bedürfen! Carl D. schrieb: > Projekte, die Schaltpläne besitzen, sind niemals typische 8-Bit > MSR-Anwendungen. Da könnte was dran sein! Carl D. Du überrascht mich ausnahmsweise. > Es nervt einfach, wenn eine Diskussion über die > Abbildung von GPIO's in C++ nur noch der It-Neandertaler zu Wort kommt, > weil er das für sein Fachgebiet hält. Der It-Neandertaler, der es schneller, kürzer und ohne großen abstrakten Theaterdonner löst, den meinst Du sicherlich ;-) Albert M. schrieb: > Seit dem habe ich diesbezüglich von Dir dazu nichts mehr gehört. Ist Dir > die Anbindung an LabView inzwischen mit ASM gelungen? Hallo Albert, danke der Nachfrage, das "Gelingen der Anbindung" von Labview ist natürlich nun just kein Problem der Programmiersprache. Habe das aber nicht vergessen und melde mich sobald das Frontend steht. Momentan stehen noch vielerlei Zuträger auf dem Programm- im Moment gerade ein Controller zur Steuerung u.a. meiner Projektor-Leinwand ;-) Yalu X. schrieb: > Hmm, ist das alles? Und dafür brauchst du 10k? Dein Zweifel wird wohl daran liegen daß Du hier was unterschätzt. Es sind wohl schon zuviele Netzteilnehmer geworden, die natürlich alle ferngesteuert, protokolliert und z.T. via Internet zugänglich gemacht werden wollen.
Michael K. schrieb: > Ich finde es einfach faszinierend das sobald Kommunikation in > Schriftform stattfindet, die Diskutanten sich einen Dreck darum scheren > wie der Mensch gestrickt ist der da auf der anderen Seite sitzt. > Plötzlich zählt nur noch die eigene Wahrnehmung und die wird jedem um > die Ohren gehauen ohne sich darum zu kümmern ob dieser Weg zu > irgendeiner Verständigung führt Ob es soweit ausufern muss, sei mal dahingestellt. Aber du sitzt demjenigen nicht gegenüber. Du siehst nicht sein Gesicht, seine Körpersprache, möglicherweise sein höhnisches Grinsen und hörst nicht seine Stimme. Daraus bilden wir uns aber unser Urteil über den Gesprächspartner. Viele Forumsdiskussionen, die sich elendig lange hinziehen, wären im richtigen Leben nach 5 Minuten zur Zufiedenheit aller Teilnehmer beendet. mfg.
Johann L. schrieb: > Hier mach Moby aber nicht wirklich eine gute Figur, z.B. beim Vergleich > einer 32-Bit Zahl gegen eine Konstante: Sein Code ist nicht nur länglich > sondern auch falsch, und das obwohl es nur ein unsigned Vergleich ist. Nun ja, mein Tag war zuvor recht lang- und trotzdem kam die korrigierte Lösung sehr schnell hinterher. Brauchst nicht unnötig auf ersterer Veröffentlichung rumzureiten :-) Jonny O. schrieb: > Mach das ruhig weiter so Moby und lass > dich da nicht verunsichern. Schlussendlich ist doch das Wichtigste, dass > man Spaß am Hobby hat. Klar - du provozierst natürlich auch gerne - Hand > aufs Herz ;-) Nein, um mich hier verunsichern zu lassen dafür hab ich schon zuviel mit SimplyAVR/ASM realisiert. Und was heißt schon "provozieren"... Wenn sich manch Experte hier mit einfachen Asm-Lösungen vor den Kopf gestoßen fühlt- warum sollte das mein Problem sein? Nein, es amüsiert mich! Sheeva P. schrieb: > Nein, ist es nicht. Assembler ist unlesbar, chaotisch und kryptisch, > schon die Atmel-Variante hat über 130 Instruktionen. Die nutzt man alle zusammen recht selten. Bis ich bei AVR mal wirklich den EOR gebraucht habe, das hat Jahre gebraucht ;-) Auch Dein restliches Hochlied auf die Hochsprache kann ich nicht nachvollziehen. Mit Deinem Versuch der Umsetzung des bischen Funktionalität meines Demo-Projekts bist Du jedenfalls gradios gescheitert, vom Erreichen der eigentlichen Ziele ganz zu schweigen. > Hochsprachen sparen dadurch die wichtigste und kostbarste Ressource von > allen ein: die Lebenszeit der Entwickler. Weißt Du womit meine "Lebenszeit als Entwickler" geschont wird? Damit daß ich mich nicht mit den Tausend Eigenheiten von Hochsprache und ihren komplexen Entwicklungsumgebungen herumschlagen muß. Damit daß ich auf Dauer bei der AVR-Reihe bleiben kann und nicht alle Jahre die Architektur wechseln muss samt erneuter Einarbeitungszeit in die immer komplexeren Einfälle mancher MC-Ingenieure... Vom Verfolgen der Programmiersprach-Weiterentwicklung bis hin zum aberwitzigen OOP für MC ganz abgesehen- was für eine Verschleuderung von (Lern)zeit, wenn man nur seine Projekte einfachstmöglich realisiert haben will... Während Du über Deinen Büchern hängst um nach Wegen zu suchen die allerneuesten Hochsprachenkonstrukte sinnvoll anzuwenden hab ich längst fertig ;-)
Michael K. schrieb: > Argumente wie: 'glaub ich ihm nicht bis ich nicht seinen Code gesehen > habe' hören sich so ein wenig nach Bindl an (Wenn man es nicht wiegen > kann ist es real nicht vorhanden) Sag mal, kannst oder willst du das Problem nicht verstehen. Er stempelt sämtliche Fachleute als Idioten ab, die mit Ihren dämlichen C Kompilern nur Code verschwenden und nicht wissen wie echte Kerle programmieren und dann kann er NICHTS vorweisen als seinen berühmten 20++ Zeiler? Also echt, das ist doch Satire.
Thomas E. schrieb: > Viele Forumsdiskussionen, die sich elendig lange hinziehen, wären im > richtigen Leben nach 5 Minuten zur Zufiedenheit aller Teilnehmer > beendet. Du mußt Dich ja nun nicht auch noch dran beteiligen, noch dazu mit manchem wohl weniger ernst gemeinten Beitrag... Jonny O. schrieb: > So wie ich Moby verstanden habe, macht er das aber als Hobby. Wenn es > ihm Spaß macht mit ASM zu programmieren ist das doch okay. Es gibt doch > viel verrücktere Hobbys. Manche Leute bauen sich aus TTL-Gattern ganze > Computer zusammen. Im Prinzip total irre, aber wenns Spaß macht? Asm auf AVR ist alles andere als irre. Nein, es kommen viele schöne kleine feine Lösungen dabei raus, ohne großen Aufwand, nur die Lösung im Blick. > Lebenszeit ist nur dann verschwendet, wenn wir sie ohne Freude > verbringen. Absolut. Insofern ist das begeisterte Studium hochabstrakter Lösungen für einfache Probleme keine verschwendete Zeit, das will ich mal einräumen.
@ Moby AVR (moby-project) Benutzerseite >Asm auf AVR ist alles andere als irre. Nein, es kommen viele schöne >kleine feine Lösungen dabei raus, ohne großen Aufwand, nur die Lösung im >Blick. Tunnelblick! 8-0
Uhu U. schrieb: > Gilt das nicht für alle deine Tage? Da hast Du recht- heutzutage ist man damit aber sicher kein Einzelfall ;-) Wenn dies allerdings permanent zu Programmierfehlern führen würde hätte ich den Spaß sicher längst verloren ;-) Uhu U. schrieb: > Seit wann kann der AVR-Assembler IfThen zur Laufzeit? Schon klar, Waldvogel. Was man gerne missverstehen will... Erinnere Dich bitte an die weisen Worte von Thomas Eckmann weiter oben zum sinnlosen Verlängern von Diskussionen. Carl D. schrieb: > Wenn die dann aber in jedem Thread über "Single-Chip-Microcontroller" > erklären wollen, daß ihre TTL-Lösung besser ist und nur "immer besser > sein kann", dann ist Schluß mit lustig. Schon klar, Carl D. Ich empfehle statt dem AVR eine TTL-Lösung. Manche Vergleiche sind wirklich himmelschreiend. P. M. schrieb: > Eine > universell brauchbare Maximum-Funktion kann auch sehr gut bei 8-Bit-MSR > auftreten. Falls damit maximale und minimale Stellen einer Wertereihe herauszufinden waren kommt das öfter vor und ist simpel herauszufinden- am besten gleich dynamisch verglichen beim Eintreffen der Werte. > Ich warte auf eine Antwort oder sehe es als definitives > Eingeständnis daß ich mich sicher nicht mit dieser Art, Funktionen zu formulieren auseinandersetzen werde.
Moby A. schrieb: > Du mußt Dich ja nun nicht auch noch dran beteiligen, noch dazu mit > manchem wohl weniger ernst gemeinten Beitrag... Erstens ist der Beitrag durchaus ernst gemeint, zweitens wirst du mir bestimmt nicht vorschreiben, woran ich mich in welcher Forum beteiligen darf. mfg.
Falk B. schrieb: > Tunnelblick! 8-0 Blick aufs Wesentliche! Blick auf die Bedürfnisse der App! Diese Art Tunnelblick ist sehr zu empfehlen- sich nicht unnötig ablenken zu lassen! Witkatz :. schrieb: > immerhin besteht ASM zu 66% aus SM ... sagen die Asm-Laien ;-) Michael K. schrieb: > Es ist kein Geheimniss das man statt mit Moby auch mit einer Parkuhr > über den ASM -> 'alle anderen Sprachen' Konflikt diskutieren könnte. > Selbst Moby macht kein Geheimniss aus seiner Tiny + ASM Fixierung. Fixierung auf genau jene Werkzeuge, die tatsächlich zur Problemlösung nötig sind, meinst Du sicherlich... > Während Moby Gebetsmühlenartig die immer gleichen (nicht)Argumente > bringt und auch überhaupt nicht vorhat sich davon abbringen zu lassen > wird es auf der 'Gegenseite' immer verbissener. Falsch. Ich bin von allem abzubringen wenn es denn Hand und Fuß hätte. Das ist zugegebenermaßen nach ein paar Jahren Asm-Erfahrung recht schwierig. Gleichzeitig kann ich permanent (auch hier) vergleichen, mit welchem Aufwand und mit welchem Ergebnis C(++) Lösungen produziert. Das führt dann regelmäßig dazu daß ich mich entspannt zurücklehnen kann ;-) > Es wird einfach nicht passieren das sich am Ende aller Diskussionen ein > geläuterer Moby in seinen 'Kerninghan / Ritchie' vertief. Damit könntest Du Recht haben. Um es aber ganz klar zu sagen: Ich möchte wirklich niemandem den Spaß an irgendeiner Sache nehmen. Nur sollte es jeder auch genauso handhaben und sein Tun permanent mit den Ergebnissen anderer Wege vergleichen!
:
Bearbeitet durch User
Moby A. schrieb: > Uhu U. schrieb: >> Seit wann kann der AVR-Assembler IfThen zur Laufzeit? > > Schon klar, Waldvogel. Was man gerne missverstehen will... Erinnere Dich > bitte an die weisen Worte von Thomas Eckmann weiter oben zum sinnlosen > Verlängern von Diskussionen. Ha, ha, da konntest du den geheimen Wunsch nach mehr Programmierkomfort nicht ganz unterdrücken und nun ringst du um eine Ausrede... Glaubwürdig geht anders ;-) > Schon klar, Waldvogel. Uhus sind alles, nur keine Waldvögel, Herr Moby Dünn.
Moby A. schrieb: > Nur sollte es > jeder auch genauso handhaben und sein Tun permanent mit den Ergebnissen > anderer Wege vergleichen! Und das tust du? Du hast doch noch nie in C programmiert. Du plapperst nur irgendwelche Dinge aus, die du meinst irgendwo gesehen zu haben, ohne sie verstanden zu haben. mfg.
Frank M. schrieb: > Ganz einfach: Du hast eine merkwürdige Auffassung von "typischen > 8-Bit-Anwendungen". > > 99,9% der Entwickler sind da anderer Ansicht als Du. Wenn diese einen > ATmega328 nehmen, dann nehmen sie ihn, um ihn auch auszunutzen. Denn > sonst würden sie ja einen ATmega168. Dem Asm-Programmierer langt dann ein Mega88. Höchstens. > Während Du nur 0,1% eines ATmegas produktiv nutzen kannst, packen da > andere Leute Anwendungen rein, von denen Du nur zu träumen wagst. Das > sind typische 8-Bit-Anwendungen! Natürlich. Ein Frank M. weiß das. Aber man kann es ja öfter mal behaupten. Verdammt, irgendwann muß doch mal was hängenbleiben!!! (denkt sich Frank M.) > Deine 23-Zeilen-Assembler-Programme sind einfach nur Verschwendung und > lassen den Großteil der AVR-HW einfach brachliegen. Du bist also kein > Sparfuchs, sondern eher ein Verschwender sondergleichen. Oh Gott- mit dieser Logik hätte ich nicht viel Spaß gehabt. Weißt Du eigentlich was "vorausschauend handeln" meint? Noch nie ein bestehendes Projekt erweitert? Deine Äußerungen sind reichlich praxisfern. Aber sonst hast Du wohl auch schon alles hier versucht... ;-(
Moby A. schrieb: > Nur sollte es > jeder auch genauso handhaben und sein Tun permanent mit den Ergebnissen > anderer Wege vergleichen! Schwierig, wenn du uns deine Ergebnisse seit 500 Threads vorenthälst.
Gu. F. schrieb: > Sag mal, kannst oder willst du das Problem nicht verstehen. Doch doch, ich versteh das Problem schon. Du fühlst Dich in Deinem Stolz verletzt und mußt das jetzt unbedingt richtigstellen. Unmöglich aufzuhören bis Moby sich endlich mit einem Strauß Blumen in der Hand bei Dir entschuldigt hat. Jaaaaa ... Ich will nicht sagen das es völlig ausgeschlossen ist das das je passiert, nur ... Hm, wie sag es am besten ? Heul doch, hört sich jetzt etwas hart an, oder ? Es gibt da draussen ein paar Milliarden Menschen die die Dinge anders sehen als ich. Jeder von denen hält sich in irgendwas für den King of Kotelett. Willst Du Dir die Pulsadern öffnen wenn Du nicht jeden einzelnen von Deiner Sicht der Dinge überzegen kannst ? Ist Dir wirklich noch nicht aufgefallen das Du 100 Jahre weitermachen könnstest ohne irgendetwas an seiner Überzeugung zu ändern ? Bist Du denn besser ?
Michael K. schrieb: > Doch doch, ich versteh das Problem schon. > Du fühlst Dich in Deinem Stolz verletzt und mußt das jetzt unbedingt > richtigstellen. > Unmöglich aufzuhören bis Moby sich endlich mit einem Strauß Blumen in > der Hand bei Dir entschuldigt hat. Du bist entweder krank oder Mobys zweit Account. tststs.
Uhu U. schrieb: >> Schon klar, Waldvogel. > > Uhus sind alles, nur keine Waldvögel, Herr Moby Dünn. Aber der Spruch ist trotzdem nicht schlecht. mfg.
Michael K. schrieb: > Frank M. schrieb: >> Während Du nur 0,1% eines ATmegas produktiv nutzen kannst > Ähm, war es nicht Moby der hier in der Kritik steht provozierende und > unbewiesene Nichtargumente zu bringen ? s.o. > Ich denke es steht ausser Frage das der ideale ASM Code eine MCU immer > besser ausnutzt als der ideale C Code. > Der Punkt über den hier m.E. überwiegend Einigkeit herrscht ist der, das > ASM ab einer gewissen Größe von Menschen nicht mehr annähernd ideal zu > schreiben ist und ein C Compiler da bessere und schnellere Arbeit > abliefert. Richtig. Ab einer gewissen Größe. Beim einen 10K, beim anderen 1K, beim dritten Null. > Gerade die 'optimierungen' mancher Compiler können einem echt die Karten > legen. > Z.B. beim Xmega den Takt umschalten geht in GCC je nach > Optimierungsstufe mal und mal nicht. Grund ist das zwischen dem > freischalten und beschreiben der Taktquellenregister nur x (?) Zyklen > vergehen dürfen. > Das scheint GCC nicht zu wissen und nicht zu berücksichtigen. Nettes Detail. Aber danke. Ich muß das gar nicht alles so genau wissen, manches kann auch in dunkler Ahnung verbleiben ;-) > Man kann also sagen das man ASM Grundlagen beherrschen sollte auch wenn > man C schreibt. Als ASM Coder braucht man aber nicht zwangsläufig C > Kenntnisse. So ist es. > Mist, jetzt hör ich mich schon an wie Mobys Wassertträger Nein. Endlich ist mal einer hier ehrlich. Auf dieser Basis lässt sich doch aufbauen...
Moby A. schrieb: > Weißt Du eigentlich was "vorausschauend handeln" meint? > Noch nie ein bestehendes Projekt erweitert? Natürlich, das mache ich stetig. Aber von Dir habe ich noch nie eine Erweiterung gesehen. Erweitere doch mal Dein berühmtes Sensorboard um 2 Sensoren. Wie Dir schon einige im dazugehörenden Thread vorgerechnet haben, musst Du Deinen Source dann komplett neuschreiben - weil die Programmlogik die feste Anzahl von Sensoren ausnutzt. Also: Was ist mit Deinen sogenannten "Erweiterungen"? Es gibt sie nicht.
Uhu U. schrieb: > Uhus sind alles, nur keine Waldvögel, Herr Moby Dünn. Uhus passen sich vielseitig an Lebensräume an- auch an Waldgebiete... Sheeva P. schrieb: > Das stimmt. Moby macht sich hingegen mit seiner totalen Unzugänglichkeit > für rationale Argumene lächerlich, insofern besteht Gleichstand. ;-) Weißt Du was das beste rationale Argument ist? Die fertige Lösung in der Hand und das Wissen, mit welchem simplen Aufwand sie zustande kam... Ich schau gerade nochmal in meinen Projekt-Thread voller seeehr greifbarer rationaler Argumente dieser Art: Beitrag "Kleines Tiny13 Sensorboard" Hey, immer noch keine greifbaren rationalen Gegenargumente ;-(
:
Bearbeitet durch User
Moby A. schrieb: > Fixierung auf genau jene Werkzeuge, die tatsächlich zur Problemlösung > nötig sind, meinst Du sicherlich.. Oh, natürlich habe ich genau das gemeint. Habe mich nur ungeschickt ausgedrückt. Moby A. schrieb: > Falsch. Ich bin von allem abzubringen wenn es denn Hand und Fuß hätte. Aber klar. Es liegt unzweifelhaft an uns das wir es einfach nicht schaffen uns verständlich auszudrücken. Wir können da nichts für, es ist der furchtbare C code der uns das Gehirn verkleister hat so das wir nur noch verschwurbeltes und unstrukturiertes Gebrabbel von uns geben können. Moby A. schrieb: > Ich möchte > wirklich niemandem den Spaß an irgendeiner Sache nehmen. Nur sollte es > jeder auch genauso handhaben und sein Tun permanent mit den Ergebnissen > anderer Wege vergleichen! Ja, das mit dem Vergleichen und dem Behaupten das der eigene Wege viel besser ist und die anderen ein wenig dumm, ist das natürlich so eine Sache. Da hat nicht jeder Deinen Weitblick zu sagen: 'Ich persönlich habe das so gelöst, aber es gibt da bestimmt viele Wege zum Ziel die auch nicht schlechter sind' Ich kann das auch garnicht verstehen sich jemand auf den Schlips getreten fühlt nur weil man ganz freundich darauf hinweist das die Entwicklung der letzten 40 Jahre im Compilerbau auf einem großen Irrtum beruht der einfach genügend Dumme gefunden hat die das unwidersprochen nachäffen. Ich finde das aber sehr nett von Dir das Du so überaus viel Geduld mit uns hast auch wenn es nicht immer leicht ist.
Moby A. schrieb: > Uhus passen sich vielseitig an Lebensräume an- auch an Waldgebiete... Was natürlich eine äußerst dünne Begründung für "Waldvogel" ist, Herr Moby Dünn...
Frank M. schrieb: > Aber von Dir habe ich noch nie eine Erweiterung gesehen. Erweitere > doch mal Dein berühmtes Sensorboard um 2 Sensoren. Wie Dir schon einige > im dazugehörenden Thread vorgerechnet haben, musst Du Deinen Source dann > komplett neuschreiben - weil die Programmlogik die feste Anzahl von > Sensoren ausnutzt. Vielleicht solltest Du dazu erst mal schauen welche Hardwaremöglichkeiten das Board bietet und welches der Sinn des gesamten Projekts ist. Und dann machst Du Dir noch einen Kopf darüber in welchem Rahmen welche Erweiterungen hier in Frage kommen. Im Gegensatz zu dem was Dir so vorschwebt erstelle ich auf den Punkt hin optimierte Lösungen- deshalb sind sie auch so effizient. Wenn ich mehr Sensoren gebraucht hätte überlegt man sich das vorher... Sheeva P. schrieb: > er Rest der Welt sei aus Gründen der Angeberei > und bewußten Ressourcenverschwendung auf Hochsprachen fixiert... Du unterstellst eben auch gerne was ;-) P. M. schrieb: > Der Punkt der Diskussion ist eigentlich, dass Moby behauptet, seine > Ansichten würden auch für grosse Programme gelten. Immer mit der selben > Dikussionsmechanik: > > Moby: "Gilt prinzipiell auch für grosse Programme." Na was heißt denn das, P.M.? Prinzipiell meint: 1. Es ist möglich. (Zum Verbesserungs-Potential von Asm hab ich mich ja schon geäußert) 2. Es hängt von gewissen Randbedingungen ab. Auch diese habe ich hier schon breitgetreten: Übung, Vorbereitung, System ...
Uhu U. schrieb: > Was natürlich eine äußerst dünne Begründung für "Waldvogel" ist, Herr > Moby Dünn... Ich wollte Dir nicht zu nahe treten. Immerhin, der Uhu ist sehr anpassungsfähig- also ein ehrenwerter Nickname ;-) Fehlt nur noch daß Du Deinem Namen alle Ehre machst...
Gu. F. schrieb: > Du bist entweder krank oder Mobys zweit Account. tststs. Klar, deswegen vertrete ich eine ganz andere Ansicht als er und habe auch schon einige Diskussionen mit ihm durch. Moment, vieleicht, wenn ich wirklich so krank bin, dann weiß ich ja garnicht das ich Moby bin. Hm, dumme Sache das. Moby ? Sag mal, bin ich Du, bist Du ich und warum hab ich plötzlich solche Kopfschmerzen. PFLEGER ! ICH WILL SOFORT MEINE MEDIZIN Nein, das ist einfach zu gut um jetzt damit aufzuhören. Was habe ich schon gelacht durch solche Threads. Wikipedia: Uhus haben einen massigen Körper und einen auffällig dicken Kopf mit Federohren. Die Augen sind orangegelb. Igitt, stimmt das ?
>> ATmega168. >Dem Asm-Programmierer langt dann ein Mega88. Höchstens. also 50% ohen Worte, echt..
Moby A. schrieb: > Vielleicht solltest Du dazu erst mal schauen welche > Hardwaremöglichkeiten das Board bietet und welches der Sinn des gesamten > Projekts ist. Und dann machst Du Dir noch einen Kopf darüber in welchem > Rahmen welche Erweiterungen hier in Frage kommen. Moment mal: Du warst es doch, der mit dem Verweis auf eine ominöse „Erweiterbarkeit“ dort bestimmte Implementierungsstrategien deiner Widersacher nicht akzeptieren wollte. Unterm Strich haben wir bislang jedenfalls noch nie etwas auch nur ansatzweise nennenswert Komplexeres als die paar Bytes dieses Sensorboards gesehen.
Moby A. schrieb: > Ich wollte Dir nicht zu nahe treten. > Immerhin, der Uhu ist sehr anpassungsfähig- > also ein ehrenwerter Nickname ;-) Wer sagt, daß er sich nach dem Vogel so nennt und nicht nach dem mehr oder weniger guten Kleber? > Fehlt nur noch daß Du Deinem Namen alle Ehre machst... Klebtomane?
Jörg W. schrieb: > Moby A. schrieb: >> Vielleicht solltest Du dazu erst mal schauen welche >> Hardwaremöglichkeiten das Board bietet und welches der Sinn des gesamten >> Projekts ist. Und dann machst Du Dir noch einen Kopf darüber in welchem >> Rahmen welche Erweiterungen hier in Frage kommen. > > Moment mal: Du warst es doch, der mit dem Verweis auf eine > ominöse „Erweiterbarkeit“ dort bestimmte Implementierungsstrategien > deiner Widersacher nicht akzeptieren wollte. Die ist nicht ominös sondern durchaus real. Das hat Software eigentlich so an sich ;-) Denkbare Beispiele hab ich genannt. Meistens weiß man auch nicht vorher, was die Zunkunft so alles an Ideen bringt. > Unterm Strich haben wir bislang jedenfalls noch nie etwas auch nur > ansatzweise nennenswert Komplexeres als die paar Bytes dieses > Sensorboards gesehen. Unterm Strich nehme ich zur Kenntnis, daß die behauptete Überlegenheit der Compiler für typische 8-Bit MSR Programme gegenüber Asm ein Märchen ist und vermutlich auch bleibt. Dazu bedurfte es nicht viel ;-)
Robert L. schrieb: >>> ATmega168. >>Dem Asm-Programmierer langt dann ein Mega88. Höchstens. > > also 50% > > ohen Worte, echt.. Gut so. Manches sollte man erstmal durchdenken bevor man es ausspricht ;-)
Moby A. schrieb: > Unterm Strich nehme ich zur Kenntnis, daß die behauptete Überlegenheit > der Compiler für typische 8-Bit MSR Programme gegenüber Asm ein Märchen > ist und vermutlich auch bleibt. Die hat wohl nie jemand behauptet, zumindest nicht was die „Dichte“ des Codes angeht (auf die es dir ja nahezu ausschließlich ankommt). Was die Entwicklungszeit angeht, da brauchst du dagegen mit keinem zu diskutieren.
>Die ist nicht ominös sondern durchaus real. Das hat Software eigentlich >so an sich ;-) Denkbare Beispiele hab ich genannt. Meistens weiß man >auch nicht vorher, was die Zunkunft so alles an Ideen bringt. Kurios wie du einerseits mit Erweiterbarkeit "Argumentierst". Andererseits jeglichen Nachteil von ASM dadurch "Rechtfertigst" dass durch gute Planung einmal erstellter Code nicht mehr geänderter werden muss.. z.b. > Im Gegensatz zu dem >was Dir so vorschwebt erstelle ich auf den Punkt hin optimierte >Lösungen- deshalb sind sie auch so effizient. >Wenn ich mehr Sensoren gebraucht hätte überlegt man sich das vorher...
Moby A. schrieb: > Robert L. schrieb: >>>> ATmega168. >>>Dem Asm-Programmierer langt dann ein Mega88. Höchstens. >> >> also 50% >> >> ohen Worte, echt.. > > Gut so. Manches sollte man erstmal durchdenken bevor man es ausspricht > ;-) ja, hättest du sollen
Moby A. schrieb: > Na was heißt denn das, P.M.? > Prinzipiell meint: > 1. Es ist möglich. (Zum Verbesserungs-Potential von Asm hab ich mich ja > schon geäußert) > 2. Es hängt von gewissen Randbedingungen ab. Auch diese habe ich hier > schon breitgetreten: Übung, Vorbereitung, System ... Es ist eben genau nicht möglich. Grössere Programme und grössere Prozessoren holen ihre Performance aus einem sehr komplexen Zusammenspiel diverser Komponenten, da hat der Mensch keine Chance, von Hand zu optimieren. Oder hast du das Gefühl, du könntest eine lange Kombination aus Register-Allokationen besser durchkombinieren als ein Computerprogramm namens Compiler?!?
Moby A. schrieb: > Unterm Strich nehme ich zur Kenntnis, daß die behauptete Überlegenheit > der Compiler für typische 8-Bit MSR Programme gegenüber Asm ein Märchen > ist und vermutlich auch bleibt. Dazu bedurfte es nicht viel ;-) So. Obwohl du im ganzen Thread der einzige mit der entsprechenden Meinung bist, nimmst du das also zur Kenntnis... Eine grössere Menge an Ignoranz ist eigentlich fast nicht mehr denkbar.
A. K. schrieb: > Sheeva P. schrieb: >> Das wird diesseits bestritten. Idealer Code ist immer derselbe, egal >> womit er ursprünglich entwickelt worden ist. > > Auch bei idealem Code kann es verschiedene Möglichkeiten geben. Vielen Dank, daß Du noch einmal auf den Kernpunkt meines darauf folgenden Absatzes ("Wobei auch dabei ja noch immer die Frage bestehen bleibt, nach welchen Kriterien ein Code denn als ideal gälte") hinweist. ;-)
Auf jeden Fall scheint sich die Erwähnung des Wortes "Assembler" auf diesen Thread gleichenfalls auszuwirken, wie auf Assembler-Listings. Viele Hundert Zeilen mit wenig Informationsgehalt.
Michael K. schrieb: > Ich stamme aus der Generation C64 und kenne durchaus den Reiz auf > unterster Ebene mit der Hardware zu kommunizieren und trickreiche > Laufzeitenhacks zu ersinnen die auf die Art mit C nicht möglich sind. Man kann Assembler-Code in C einbetten. Zum Glück ist das immer seltener notwendig, aber das ändert ja nichts daran, daß es geht. ;-) > Was haben wir nicht alles mit realen 4Mhz (8031), 64B Ram und einem 8K > Eprom gelöst. Was an Power fehlte wurde durch Gehirnschmalz ersetzt. Da sind wir wieder bei der kostbarsten Ressource von allen. > Dieses ganze Behauptungsgefussel wer wie blöd ist und wer den > universellen Plan hat was geht können wir uns wirklich sparen. Bis auf Moby haben das hier alle verstanden.
Stefan K. schrieb: > Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, > weil das Flash nur zum kleinen Teil ausgenutzt wird. > Und bei großen Programmen optimiert der Compiler besser als der Mensch. Das ist zweifellos die klügste Aussage, die ich dazu bisher gelesen habe.
Michael K. schrieb: > Unter ASM kann ich spezielle Teile auf den Takt genau optimieren. Nochmal: man kann Assembler in C einbetten, wenn man sowas braucht. > Ich habe mal Code überarbeiten müssen bei dem der Autor in C > Konstruktionen gewählt hat die auf unglaublichen Umwegen zum Ziel > geführt haben. Hätte der Compiler sinngemäß verstanden was da mal > rauskommen soll, hätte der optimieren können, aber in dem Fall ergab das > einfach ein Codemonster was die 8K Begrenzung gerissen hat. Und das soll jetzt ein Argument gegen C sein? Mach' mal die Gegenprobe: was wäre geschehen, wenn Dein Kollege ähnlichen Unsinn in Assembler geschrieben hätte? Dann hättest Du wohl die ganze Veranstaltung neu schreiben müssen. In jeder Programmiersprache kann man Unsinn machen. Das ist dann aber kein Argument gegen die Sprache, sondern nur eins gegen den Programmierer.
A.K.: > Also übersichtlicher als so geht's doch kaum: > 1⌈2 > 2 > 2⌈1 > 2 > ⌈/1 2 3 4 5 3 8 1 3 > 8 Vorsicht, wenn die ASM-Liga rausfindet, um was es sich da handelt, dann Gnade dir Gott. Hab auch etwas gebraucht, denn ich hab das nie selbst benutzt, nur die Sonderzeichen haben es verraten -> Iverson's Bessere Mathematik, noch Eine Programmier Sprache. Hat wie schon das C++-Template Max() den Vorteil, daß man sich nicht die "signed oder unsigned" Frage stellen muß, die "durchschnittlichen ASM-Programmieren" mit Sendungsbewußrsein gerne mal das Ergebnis verhagelt. Es gäbe auch noch: (max 1 2 3 4 5 3 8 1 3)
Carl D. schrieb: > Vorsicht, wenn die ASM-Liga rausfindet, um was es sich da handelt, dann > Gnade dir Gott. Wieso? Die Programmstruktur ist verdammt ähnlich. Goto wohin das Auge blickt, Struktur nicht zu finden. Oft noch nicht einmal mit Labels, sondern mit direkter numerischer Zieladresse. Und compiliert wird auch nicht. > die "durchschnittlichen ASM-Programmieren" mit Sendungsbewußrsein > gerne mal das Ergebnis verhagelt. Der Code war auch ohne Vorzeichen schon falsch.
:
Bearbeitet durch User
Sheeva P. schrieb: > Und das soll jetzt ein Argument gegen C sein? Nö, wo habe ich das gesagt ? Michael K. schrieb: > Erst massives Abspecken und SDCC haben es dann gebracht. Du weist was SDCC ist ?
Moby A. schrieb: > Johann L. schrieb: >> Hier mach Moby aber nicht wirklich eine gute Figur, z.B. beim Vergleich >> einer 32-Bit Zahl gegen eine Konstante: Sein Code ist nicht nur länglich >> sondern auch falsch, und das obwohl es nur ein unsigned Vergleich ist. > > Nun ja, mein Tag war zuvor recht lang- und trotzdem kam die korrigierte > Lösung sehr schnell hinterher. Brauchst nicht unnötig auf ersterer > Veröffentlichung rumzureiten :-) Wenn Assembler wirklich die Eigenschaften hätte, die Du ihm zuschreibst -- insbesondere Einfachheit, Klarheit und Übersichtlichkeit -- dann hättest Du Dich natürlich nicht korrigieren müssen, sondern gleich eine perfekte Lösung abgeliefert. Du schaffst es also offenbar nicht, Deinen eigenen Behauptungen gerecht zu werden. Daß Du Dich selbst nur als mittelmäßigen Assembler-Programmierer bezeichnest, ändert daran auch nichts. ;-) > Sheeva P. schrieb: > >> Nein, ist es nicht. Assembler ist unlesbar, chaotisch und kryptisch, >> schon die Atmel-Variante hat über 130 Instruktionen. > > Die nutzt man alle zusammen recht selten. Bis ich bei AVR mal wirklich > den EOR gebraucht habe, das hat Jahre gebraucht ;-) > Auch Dein restliches Hochlied auf die Hochsprache kann ich nicht > nachvollziehen. Natürlich kannst Du das nicht, weil Du keine Hochsprache beherrschst. Da ich hingegen sowohl Assembler als auch mehrere Hochsprachen beherrsche, kann mir Urteile bilden, die Dir mangels Horizont verwehrt bleiben. :-) > Mit Deinem Versuch der Umsetzung des bischen > Funktionalität meines Demo-Projekts bist Du jedenfalls gradios > gescheitert, vom Erreichen der eigentlichen Ziele ganz zu schweigen. Deine Reaktion auf meinen Code war plötzlich sofort neue Anforderungen zu erfinden. Meine Lebenszeit ist mir zu wertvoll, um sie mit unseriöser und unehrlicher Falschspielerei zu verschwenden. ;-) >> Hochsprachen sparen dadurch die wichtigste und kostbarste Ressource von >> allen ein: die Lebenszeit der Entwickler. > > Weißt Du womit meine "Lebenszeit als Entwickler" geschont wird? Ja, das weiß ich -- und zwar viel besser als Du es wissen kannst. Denn, wie gesagt, ich beherrsche sowohl Assembler als auch Hochsprachen. Und deswegen kann ich Dir mit absoluter Sicherheit sagen: die Hochsprachen haben gewonnen, weil man das Ziel damit viel einfacher, schneller, und preiswerter erreichen kann als mit kryptischem, chaotischem, unles- und unwartbarem Assembler-Spaghettigefumsel. Die Hochsprachen haben gewonnen, weil sie den Entwickler eben nicht dazu zwingen, seine Denk- und Sichtweise auf das Problem an die einer Maschine anzupassen, sondern es ermöglichen, das Problem strukturiert, mithin der natürlichen, menschlichen Gedankenstruktur folgend, einfach, schnell und mit dem geringsten Aufwand zu lösen. Genau deswegen haben übrigens auch die objektorientierten Sprachen über die prozeduralen Sprachen gesiegt: weil man dank Objektorientierung die Entitäten und Vorgänge aus der realen Welt noch einmal viel natürlicher abbilden und miteinander interagieren lassen kann -- wenn man das denn einmal gelernt hat, natürlich. ;-) > Damit daß ich mich nicht mit den Tausend Eigenheiten von Hochsprache und > ihren komplexen Entwicklungsumgebungen herumschlagen muß. Damit daß ich > auf Dauer bei der AVR-Reihe bleiben kann und nicht alle Jahre die > Architektur wechseln muss samt erneuter Einarbeitungszeit in die immer > komplexeren Einfälle mancher MC-Ingenieure... Vom Verfolgen der > Programmiersprach-Weiterentwicklung bis hin zum aberwitzigen OOP für MC > ganz abgesehen- was für eine Verschleuderung von (Lern)zeit, wenn man > nur seine Projekte einfachstmöglich realisiert haben will... Während Du > über Deinen Büchern hängst um nach Wegen zu suchen die allerneuesten > Hochsprachenkonstrukte sinnvoll anzuwenden hab ich längst fertig ;-) Entschuldige, aber da kann ich nur lachen. Strukturierte Programmierung und Objektorientierung zu erlernen, ist in Wahrheit nur ein einmaliger Aufwand, der durch die höhere Produktivität sofort amortisiert. Das ist nämlich in Wirklichkeit für die meisten Menschen gar nicht so schwierig wie Du es gerne behauptest; Menschen denken ohnehin schon in Strukturen und Objekten, und dann geht es nur noch darum, dies mit den Mitteln des jeweiligen Programmierparadigmas auszudrücken. Heute fangen schon Achtjährige mit strukturierter und objektorientierter Programmierung in der Grundschule an; in Großbritannien gehört das schon als Pflichtfach zum ganz normalen Lehrplan. Erzähl' mir also bitte nicht, daß das alles so oberkompliziert und schwierig sei. Oder möchtest Du uns ernsthaft weismachen, daß Dir etwas zu kompliziert ist, das schon Kinder in der Grundschule lernen können? Das würde allerdings vieles erklären. Vielleicht magst Du ja einmal darüber nachdenken, warum Grundschulkinder mit strukturierten und objektorientierten Sprachen an die Programmierung herangeführt werden, anstatt sie mit Assembler zu folter^Hfrustrieren... Obwohl, laß' das lieber: das Ergebnis wird Dir nicht gefallen. ;-)
Uhu U. schrieb: > Moby A. schrieb: >> Nun ja, mein Tag war zuvor recht lang- > > Gilt das nicht für alle deine Tage? Grundsätzlich sind alle Tage gleich lang. Aber verschieden breit! ;-)
Moby A. schrieb: > Um es aber ganz klar zu sagen: Ich möchte wirklich niemandem den Spaß an > irgendeiner Sache nehmen. Davon hat man bisher leider nichts gemerkt.
Moby A. schrieb: > Sheeva P. schrieb: >> er Rest der Welt sei aus Gründen der Angeberei >> und bewußten Ressourcenverschwendung auf Hochsprachen fixiert... > > Du unterstellst eben auch gerne was ;-) LOL! Siehe meine Zitatesammlung weiter oben.
Jörg W. schrieb: > Moby A. schrieb: >> Unterm Strich nehme ich zur Kenntnis, daß die behauptete Überlegenheit >> der Compiler für typische 8-Bit MSR Programme gegenüber Asm ein Märchen >> ist und vermutlich auch bleibt. > > Die hat wohl nie jemand behauptet, zumindest nicht was die „Dichte“ > des Codes angeht (auf die es dir ja nahezu ausschließlich ankommt). > > Was die Entwicklungszeit angeht, da brauchst du dagegen mit keinem zu > diskutieren. Deswegen vermeidet er es ja auch geradezu zwanghaft, auf mein Argument der kostbaren Lebenszeit einzugehen... aber natürlich ist es sehr durchsichtig, sich nur auf einen einzigen Punkt zu kaprizieren und alle anderen einfach geflissentlich zu ignorieren. ;-)
A. K. schrieb: (APL) > Wieso? Die Programmstruktur ist verdammt ähnlich. Goto wohin das Auge > blickt, Struktur nicht zu finden. Oft noch nicht einmal mit Labels, > sondern mit direkter numerischer Zieladresse. Und compiliert wird auch > nicht. ROTFL :)
Jörg W. schrieb: > Was die Entwicklungszeit angeht, da brauchst du dagegen mit keinem zu > diskutieren Doch, das mach ich auch gern. Dankbarerweise findet sich schon ein (nicht funktionsfähiger) C-Nachbau in meinem Projekt. Da war ich in Asm in jedem Falle schneller fertig ;-) Robert L. schrieb: > Kurios wie du einerseits mit Erweiterbarkeit "Argumentierst". > Andererseits jeglichen Nachteil von ASM dadurch "Rechtfertigst" dass > durch gute Planung einmal erstellter Code nicht mehr geänderter werden > muss.. Was ist da kurios? Wenn Code optimal auf die Hardware ausgerichtet ist heißt das noch lange nicht daß er sich funktionell nicht erweitern ließe. Warum siehst Du das so statisch? Schau mal ins Projekt! Das lässt sich z.B. prima mit einem Hauptprogramm erweitern welches die auszugebenden Werte nach irgendwelchen Vorgaben nachbearbeitet. Leute, wo bleibt bloß Eure Fantasie? P. M. schrieb: > Es ist eben genau nicht möglich. Grössere Programme und grössere > Prozessoren holen ihre Performance aus einem sehr komplexen > Zusammenspiel diverser Komponenten, da hat der Mensch keine Chance, von > Hand zu optimieren. Oder hast du das Gefühl, du könntest eine lange > Kombination aus Register-Allokationen besser durchkombinieren als ein > Computerprogramm namens Compiler?!? Ach was. Das Zauberwort lautet einfach: Mit System! Von grösseren Prozessoren war nie die Rede. Register-Allokationen sind kein Hindernis. Meine Vorgehensweise ist weiter oben beschrieben, fertige Funktionsbausteine daran angepasst. Der Compiler optimiert jenes Registerchaos, welches die Hochsprache samt all ihrer Konstruktionen selbst anrichtet, würde ich mal ganz flapsig sagen ;-)
P. M. schrieb: > So. Obwohl du im ganzen Thread der einzige mit der entsprechenden > Meinung bist Der Einzige unter ertappten Hochsprachlern ;-) Von Ignoranz könnt ich Dir auch manches berichten... Unmittelbare Folge ist daß man alles zehntausendmal wiederholen muß. Sheeva P. schrieb: > Stefan K. schrieb: > Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, > weil das Flash nur zum kleinen Teil ausgenutzt wird. > Und bei großen Programmen optimiert der Compiler besser als der Mensch. > > Das ist zweifellos die klügste Aussage, die ich dazu bisher gelesen > habe. Falsch. Sie nutzt eben doch was. Spätestens dann wenn man erweitern möchte. Oder statt einem Mega168 ein Mega88 ausreichen soll. Große, ganz große Programme mit großen Datenmengen und vielen Berechnungen würde ich auch in Hochsprache lösen.
Moby A. schrieb: >> Was die Entwicklungszeit angeht, da brauchst du dagegen mit keinem zu >> diskutieren > > Doch, das mach ich auch gern. Damit begibst du dich endgültig aufs Glatteis. Aber mach' ruhig, du definierst dir deine Welt ja ohnehin so zurecht, wie dir sie gerade passt. Dagegen kann man nicht mit rationalen Argumenten ankommen, denn im nächsten Moment hast du ja sowieso alles umdefiniert.
Jörg W. schrieb: > Damit begibst du dich endgültig aufs Glatteis. > > Aber mach' ruhig, du definierst dir deine Welt ja ohnehin so zurecht, > wie dir sie gerade passt. Dagegen kann man nicht mit rationalen > Argumenten ankommen, denn im nächsten Moment hast du ja sowieso alles > umdefiniert. Das hast Du Dir ja auch schön zurechtdefiniert. Das Wort "endgültig" hab ich auch schon öfter gehört. Bei kleinen Programmen und mit Übung, Vorbereitung, System ist der ASMler vielleicht sogar eher fertig. Ein sbi PortA,1 schreibt sich einfach schneller ;-) Bei größeren Sachen mit viel Optimietungspotential hatte ich mehr Zeitbedarf längst eingeräumt- freilich dann mit mehr Möglichkeiten fürs effizientere Ergebnis. Sheeva P. schrieb: > Wenn Assembler wirklich die Eigenschaften hätte, die Du ihm zuschreibst > -- insbesondere Einfachheit, Klarheit und Übersichtlichkeit -- dann > hättest Du Dich natürlich nicht korrigieren müssen, sondern gleich eine > perfekte Lösung abgeliefert. Na so ein Quatsch. Programmieren bleibt in jedem Fall eine anspruchsvolle Tätigkeit. Vielleicht sollte man etwas zu müde dann keinen Code mehr entwickeln und hier reinstellen... Korrigiert war sie ja trotzdem wenig später. Du hingegen hast es bis heute nicht geschafft, mit Deinem hochgelobten C eine funktionsfähige Version meines Projektcodes zu erstellen... > Da > ich hingegen sowohl Assembler als auch mehrere Hochsprachen beherrsche Das hast Du überzeugend demonstriert ;-) > Deine Reaktion auf meinen Code war plötzlich sofort neue Anforderungen > zu erfinden. Meine Lebenszeit ist mir zu wertvoll, um sie mit unseriöser > und unehrlicher Falschspielerei zu verschwenden. ;-) Alberne Ausreden. Den Ressourcenbedarf mit einer C-Lösung zu untertreffen war seit jeher erklärtes Ziel. Was zu den MC-Ressourcen zählt hatte ich als bekannt vorausgesetzt... > Die Hochsprachen haben gewonnen, weil sie den Entwickler eben nicht dazu > zwingen, seine Denk- und Sichtweise auf das Problem an die einer > Maschine anzupassen, Assembler hat gewonnen weil nur durch genaue Kenntnis der und Anpassung an die Maschine gelingt bestmöglicher effizienter Code. > Strukturierte Programmierung > und Objektorientierung ... bitte dort wo es Sinn macht. Und sie haben in jedem Fall ihren Preis der sich recht anschaulich in den nötigen Festplattengrößen heutiger PCs zeigt. Damit meine ich aber jetzt keine dicken Media-Sammlungen.
> als mit kryptischem, chaotischem, unles- und > unwartbarem Assembler-Spaghettigefumsel. Ich habe schon viel Code gesehen und geschrieben, aber …,Spaghettigefumsel bekommst du in jeder Sprache hin. Besonders Anfänger nach ihren ersten OOP-Kurs + Templates zum Frühstück, neigen gern am Problem vorbei zu designen. Ich will hier niemanden verteidigen, aber strukturierten/lesbaren/kommentierten Code kann man in jeder Sprache schreiben. Es ist aber auch eine typische Assembler vs. Hochsprachen Diskussionen, am Ende drehen alle durch :-) Bereue schon wieder etwas dazu geschrieben zu haben ...
Sheeva P. schrieb: > Deswegen vermeidet er es ja auch geradezu zwanghaft, auf mein Argument > der kostbaren Lebenszeit einzugehen... Lang und breit. Man sollte das nur nicht > einfach geflissentlich .. ignorieren ! P. M. schrieb: > Das könnte durchaus erklären, warum Moby so versessen auf sein Assembler > ist: Es ist insofern einfacher, dass dort alles per Fleissarbeit > zusammengestiefelt wird, dafür ist fast kein abstraktes Denken > erforderlich. Man kann sich Schritt für Schritt vorstellen, was der > Prozessor macht, wie bei einem Kind, das mit der Finger-Methode > rechnet... Da ist was dran. Das macht eben Asm einfach! Das hat es abstrakten Programmierformen voraus. Vom Schrecken der "Fleissarbeit" lässt sich freilich mit Übung, Vorbereitung, System so einiges nehmen. Nichtsdestotrotz sind in Asm genauso komplizierte "Maschinen" und Konstruktionen im Innern des MC zu entwickeln wie mit anderen Sprachen auch. Durch den unmittelbaren Kontakt zur und Kenntnis der Hardware mit optimalem Ergebnissen und allen Freiheiten.
Witkatz :. schrieb: > Für mich persönlich ist die Größe bereits da erreicht, wo ich in C mit > einfachen Vergleichsoperatoren arbeiten kann. Das mit dem Flags geht Dir mit der Zeit ins Blut über. Bei großen Berechnungen könnt ich allerdings schwach werden- nur brauch ich die selten. > Früher habe > ich PICs oft in Assembler programmiert. Was habe ich geflucht und Zeit > verloren, Hey da hab ich auch geflucht! Was war das für ein schlechter Controller samt zugehörigem Assembler! Fast wär ich auf Hochsprache umgestiegen. Zum Glück kamen aber dann die AVRs. > Die C Syntax ist dagegen für alle > verbindlich, C ist nun mal die Weltsprache der µC. Die AVR-Asm Syntax ist auch für alle verbindlich ;-)
Ralf G. schrieb: > Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert > eventuell komplett neuen Assembler-Code. Komplett neu? Welche "winzig kleine Änderung" sollte das bloß nötig machen ???
Moby A. schrieb: > Die AVR-Asm Syntax ist auch für alle verbindlich ;-) Nein. Atmels Assembler unterscheidet sich vom GNU Assembler.
Moby A. schrieb: > Ralf G. schrieb: >> Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert >> eventuell komplett neuen Assembler-Code. > > Komplett neu? Welche "winzig kleine Änderung" sollte das bloß nötig > machen ??? Das wurde doch schon mehrfach geschrieben, u.a. von Frank Frank M. schrieb: > Aber von Dir habe ich noch nie eine Erweiterung gesehen. Erweitere > doch mal Dein berühmtes Sensorboard um 2 Sensoren. Wie Dir schon einige > im dazugehörenden Thread vorgerechnet haben, musst Du Deinen Source dann > komplett neuschreiben - weil die Programmlogik die feste Anzahl von > Sensoren ausnutzt. Ignorieren gehört wohl zu deinen Spezialitäten.
Moby A. schrieb: > Sheeva P. schrieb: >> Stefan K. schrieb: >> Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, >> weil das Flash nur zum kleinen Teil ausgenutzt wird. >> Und bei großen Programmen optimiert der Compiler besser als der Mensch. >> >> Das ist zweifellos die klügste Aussage, die ich dazu bisher gelesen >> habe. > > Falsch. Sie nutzt eben doch was. Spätestens dann wenn man erweitern > möchte. Oder statt einem Mega168 ein Mega88 ausreichen soll. LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und doppelter Programmspeicher) für nur € 1,35. > Große, ganz große Programme mit großen Datenmengen und vielen > Berechnungen würde ich auch in Hochsprache lösen. Als beruflicher Nutzer von Fuzzy Logic, in dessen Alltag es gerade um die Übertragung solcher Aussagen in berechenbare Regelwerke geht, stellt sich mir die Frage: was genau bedeuten hier die Termini "groß" und "ganz groß", bezogen auf Programme, sowie der Terminus "viele" bei den Berechnungen?
@Moby AVR deine Projekte sind gut Dokumentiert, leicht Verständlich, leicht Erweiterbar, 50% kleiner wie mit C möglich.. Sie verfolgen einen SEHR genau definiertem Zweck.. was war jetzt nochmal der Grund warum du den Code deines XMega Projektes (den mit dem Xport) nicht einfach postest?? "klauen" wird ihn keiner, weil die Aufgaben ja so speziell sind andererseits würdest du all das was du seit 500 Beiträgen versuchst zu vermitteln mit einem Schlag beweisen..
Sheeva P. schrieb: > LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, > den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und > doppelter Programmspeicher) für nur € 1,35. ATmega328 für 1,95 im Guloshop: Vierfacher Programmspeicher. Der ATmega88 wird da erst gar nicht angeboten... lohnt sich nicht.
Moby A. schrieb: > Du hingegen hast es bis heute nicht geschafft, mit Deinem hochgelobten C > eine funktionsfähige Version meines Projektcodes zu erstellen... >> Deine Reaktion auf meinen Code war plötzlich sofort neue Anforderungen >> zu erfinden. Meine Lebenszeit ist mir zu wertvoll, um sie mit unseriöser >> und unehrlicher Falschspielerei zu verschwenden. ;-)
Frank M. schrieb: > ATmega328 für 1,95 im Guloshop: Vermutlich ist der nicht für ein typ. "8-Bit MSR Programm" geeignet ;-)
Moby A. schrieb: > Du hingegen hast es bis heute nicht geschafft, > mit Deinem hochgelobten C eine funktionsfähige Version meines > Projektcodes zu erstellen... Du hast es bis heute ja auch nicht geschafft, Deinen unleserlichen Projektcode derart zu dokumenieren, dass man in C eine funktionsfähige Version Deines Codes programmieren kann! ;-) Und weisst Du, warum? Damit Du genau dieses Argument bringen kannst. Volle Absicht! Also: Her mit der Doku. Dann sehen wir weiter.
Marten W. schrieb: > Es ist aber auch eine typische Assembler vs. Hochsprachen Diskussionen, > am Ende drehen alle durch :-) Hihi ... > Bereue schon wieder etwas dazu geschrieben zu haben ... Ach was, mit dem ersten geschriebenen Wort ist klar das Dich alle hassen und es jede Menge Minus gibt. Das ist okay, das muß so sein. Am Rande einer Mittelalterlichen Hexenverbrennung zu versuchen eine sachliche und ausgeglichene Diskussion über Sinn und Zweck des ganzen zu führen ist ja auch eher die letzte dumme Idee die man je hatte. Da kann man nur lauthals lachend seinen Spaß bei haben während einem Blut und Erbrochenes um die Ohren fliegt. Pic gegen AVR 8bit gegen 32bit ASM gegen C Kurze Hosen gegen lange Hosen Fleischesser gegen Veganer Es wird schon einen Grund geben sich wie toll zu gebärden und mit Schaum vom Mund die immer gleichen Argumente in den Wind zu schreien. Ist doch deutlich zu erkennen das es einzig um dem Konflikt geht und nicht um die Gemeinsamkeiten. Selbst wenn mal einer zurücksteckt (Moby würde für große Programe und viel Datenverarbeitung auch C benutzen, hört, hört) wird das einfach ignoriert, denn > Er hat Jehova gesagt, steinigt ihn!
Marten W. schrieb: >> als mit kryptischem, chaotischem, unles- und >> unwartbarem Assembler-Spaghettigefumsel. > > Ich habe schon viel Code gesehen und geschrieben, aber > …,Spaghettigefumsel bekommst du in jeder Sprache hin. Besonders Anfänger > nach ihren ersten OOP-Kurs + Templates zum Frühstück, neigen gern am > Problem vorbei zu designen. Ich will hier niemanden verteidigen, aber > strukturierten/lesbaren/kommentierten Code kann man in jeder Sprache > schreiben. Selbstverständlich kann man in jeder Sprache schlechten Code schreiben. Aber Assembler ist Spaghetticode by Design; es gibt da schlicht und einfach keine Struktur und auch keine Sprachmittel, um das Programm zu strukturieren.
Michael K. schrieb: > Pic gegen AVR > 8bit gegen 32bit > ASM gegen C > Kurze Hosen gegen lange Hosen > Fleischesser gegen Veganer Mir ist es egal, ob ASM oder C. Hauptsache mit dem EMACS geschrieben!
Klaus W. schrieb: > Mir ist es egal, ob ASM oder C. Hauptsache mit dem EMACS geschrieben! ... und in Lisp ausgeführt. ;-)
Sheeva P. schrieb: > Selbstverständlich kann man in jeder Sprache schlechten Code schreiben. Real programmers can write FORTRAN programs in any language. :-)
Moby A. schrieb: > Ach was. Das Zauberwort lautet einfach: Mit System! > Von grösseren Prozessoren war nie die Rede. Siehst du, schon wieder das selbe Spiel. Zuerst behauptest du, es gelte für 8-Bitter. Da stimmt man dir so halb zu. Dann behauptest du, es gelte prinzipiell für jedes Programm. Da widerspricht man dir. Dann sagst du wieder, es gehe nicht um grössere Prozessoren. Also was jetzt, leg dich fest: Gilt deine Ansicht auch für grössere Prozessoren als für kleine 8-Bitter? Ja oder Nein? Moby A. schrieb: > P. M. schrieb: >> Es ist eben genau nicht möglich. Grössere Programme und grössere >> Prozessoren holen ihre Performance aus einem sehr komplexen >> Zusammenspiel diverser Komponenten, da hat der Mensch keine Chance, von >> Hand zu optimieren. Oder hast du das Gefühl, du könntest eine lange >> Kombination aus Register-Allokationen besser durchkombinieren als ein >> Computerprogramm namens Compiler?!? > > Ach was. Das Zauberwort lautet einfach: Mit System! > Von grösseren Prozessoren war nie die Rede. Register-Allokationen sind > kein Hindernis. Meine Vorgehensweise ist weiter oben beschrieben, > fertige Funktionsbausteine daran angepasst. Ok, du scheinst wirklich keine Ahnung zu haben, was in einem modernen Compiler passiert.
P. M. schrieb: > Ok, du scheinst wirklich keine Ahnung zu haben, was in einem modernen > Compiler passiert. Logisch, dass er das nicht hat, hat er ja nie benutzt. Deshalb glaubt er auch immer noch dran, dass er gegenüber einem Compiler tatsächlich 50 % kleineren Code verzapfen könnte.
Moby A. schrieb: > Komplett neu? Welche "winzig kleine Änderung" sollte das bloß nötig > machen ??? Z.B.: Einen auf 'unsigned' optimierten Vergleich einer 32-Bit-Zahl in 'signed' ändern. :-)
Ralf G. schrieb: > Einen auf 'unsigned' optimierten Vergleich einer 32-Bit-Zahl in 'signed' > ändern. :-) Wer seinen Code mit völlig überflüssigen, ressourcenfressenden 32-Bit-Variablen aufbläht, der hat die Effizienz einer hochoptimierten Assemblerprogrammierung in all seiner schlichten Schönheit und Eleganz einfach noch nicht verstanden ... Duck und weg, Stefan
"8bit ought to be enough for anybody [Moby Dick] "Ich bin ASM, Dein Gott. Du sollst keine anderen Programmierspachen neben mir haben." [Erstes Gebot Moby] "Wir sind ASM. Sie werden assimiliert werden. Deaktivieren Sie Ihre Schutzschilde und ergeben Sie sich. Wir werden ihre biologischen und technologischen Charakteristika den unsrigen hinzufügen. Ihre Kultur wird sich anpassen und uns dienen. Widerstand ist zwecklos!" [Raumschiff Entermoby]
Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: Jetzt musst du nur noch damit programmieren lernen Moby. Dann kommt deine Stunde.
@ Moby AVR (moby-project) Hallo! Ich bin ebenfalls begeisterter Assembler-Programmierer; auf vielen Prozessorarchitekturen. Ich programmiere auch in Hochsprache, vom verrückten FORTH über das kinderleichte C bis zu netzwerkfähigen Datenbankanwendungen für komplette Firmen. Für jede Aufgabe das geeignete Werkzeug. Wenn ich hier die engstirnigen Argumente Deiner "Gegner" lese, kann ich nur lächeln. Als ich letztens am Biertisch die Sorgen eines Bekannten hörte, der für die sicherheitsrelevante Software in seiner Firma die Validierung seines verwendeten C-Compilers machen muss, standen mir die Haare zu Berge. Er überlegt, alles in Assembler umzuschreiben, denn das würde der TÜV akzeptieren. Mein Tipp an Dich: lehne dich zurück und lächele! Du mußt Dir doch nicht die Haare wegen ein paar wenigen Leuten raufen. Es gibt genügend Leute, die Deine Meinung teilen, sonst gäbe es überhaupt keine Werkzeuge zur Assemblerprogrammierung.
Route 6. schrieb: > Mein Tipp an Dich: lehne dich zurück und lächele! Du mußt Dir doch nicht > die Haare wegen ein paar wenigen Leuten raufen. Es gibt genügend Leute, > die Deine Meinung teilen, sonst gäbe es überhaupt keine Werkzeuge zur > Assemblerprogrammierung. Vielleicht hättest du den Thread auch lesen sollen, bevor du hier etwas schreibst. Aber sonst scheinst du ja ein ganz toller Typ zu sein. mfg.
Route 6. schrieb: > Er überlegt, alles in Assembler umzuschreiben, denn das würde der TÜV > akzeptieren. Falls er es fertigbekommt, bevor sich die Spezifikation das nächste Mal ändert. ;-) Dass man bei Assembler tatsächlich „jedes Bit im Griff hat“, ich glaube, darüber sind wir uns alle einig. Allerdings mögen die meisten von uns (Moby explizit ausgenommen) den dafür zu zahlenden Preis in Form von Arbeits- oder Lebenszeit nicht zahlen.
Moby A. schrieb: > Hey da hab ich auch geflucht! Was war das für ein schlechter Controller > samt zugehörigem Assembler! Fast wär ich auf Hochsprache umgestiegen. > Zum Glück kamen aber dann die AVRs. >... > Die AVR-Asm Syntax ist auch für alle verbindlich ;-) Ich komme seit >15 Jahren mit PICs wunderbar zurecht. Auch mit Assembler komme ich gut zurecht. Neuerdings fand ich Spaß am XC8 und finde C auf 8bit PICs Klasse. Und jetzt? Jetzt muss ich mich sofort auf AVR Mikrocontroller stürzen, mit ausschließlich AVR-ASM. Ich hasse mein Leben ;-)
:
Bearbeitet durch User
Route 6. schrieb: > Für jede Aufgabe das geeignete Werkzeug. Wenn ich hier die engstirnigen > Argumente Deiner "Gegner" lese, kann ich nur lächeln. Wenn du den Thread gelesen hättest, dann würdest du sehen, dass genau der Standpunkt "geeignetes Werkzeug" hier schon die längste Zeit von den meisten vertreten wird. Und in den meisten Fällen ist das nicht Assembler. Route 6. schrieb: > Als ich letztens am Biertisch die Sorgen eines Bekannten hörte, der für > die sicherheitsrelevante Software in seiner Firma die Validierung seines > verwendeten C-Compilers machen muss, standen mir die Haare zu Berge. Frickler, die denken, ihre Probleme seien die Welt. Sorry, aber es gibt unzählige sicherheitsrelevante Anwendungen, die in C geschrieben sind. Wer das nicht hinkriegt, dann klemmts an einem anderen Ort.
P.M.: > Sorry, aber es gibt unzählige sicherheitsrelevante Anwendungen, die in > C geschrieben sind. Vor allem muß man nicht den kompletten Block zwischen Anforderung und Binärcode validieren, sondern kann auf einen validierten Codegenerator eines Compilers aufsetzen. Oder gibt es irgendwo zertifizierte ASM-Programmierer, die immer exakt gleich codieren?
Ist eig. dieses "C" Route 6. schrieb: > das kinderleichte C ein anderes als dieses "C"? Moby A. schrieb: > Das ist kryptischer Kauderwelsch für Eingeweihte. Vlt. ist ja alles nur ein... ähm... Missverständnis ;-)
Gu. F. schrieb: > Moby A. schrieb: >> Ralf G. schrieb: >>> Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert >>> eventuell komplett neuen Assembler-Code. >> >> Komplett neu? Welche "winzig kleine Änderung" sollte das bloß nötig >> machen ??? > > Das wurde doch schon mehrfach geschrieben, u.a. von Frank > > Frank M. schrieb: >> Aber von Dir habe ich noch nie eine Erweiterung gesehen. Erweitere >> doch mal Dein berühmtes Sensorboard um 2 Sensoren. Wie Dir schon einige >> im dazugehörenden Thread vorgerechnet haben, musst Du Deinen Source dann >> komplett neuschreiben - weil die Programmlogik die feste Anzahl von >> Sensoren ausnutzt. > > Ignorieren gehört wohl zu deinen Spezialitäten. Der Einwand ist aber unberechtigt. Zu einem fertigen Design mal eben ein (paar) Sensoren hinzufügen zu wollen ist eben alles andere als eine Lapalie. Bietet der Controller 8 I/Os, man braucht aber nun partout 9 kann das schon ein komplettes Redesign der Hardware nötig machen. Genauso kann das je nach Funktionalität mit der Software sein. Nun kann man sich entscheiden: mach ich das von vornherein hard/softwareseitig flexibler und reserviere mehr Kapazitäten oder weiß ich von vorn herein was ich will und optimiere auf den Punkt, liefere die Lösung aus einem Guss. Flexibler benötigt dann eben auch mehr Ressourcen- gerade wenns in Hochsprache erfolgen soll. Ohne weiteres lässt sich auch in Assembler mehr Flexibilität verwirklichen, dann mit gleichem Preis. Ich bevorzuge, die benötigte Hardware zuallererst zu ermitteln, passende Software zu schreiben (bei AVR keine Wissenschaft) und damit die optimale Lösung aufs Parkett zu legen- andere Herangehensweisen könnte man glaub ich leicht in der Nähe gepflegten Pfusches ansiedeln. Wer freilich vorher nicht genau weiß was er/sie will muß dafür bezahlen.
Moby A. schrieb: > Flexibler benötigt dann eben auch mehr Ressourcen- gerade wenns in > Hochsprache erfolgen soll. Schreib' doch lieber nicht über Dinge, bei denen du dich nicht auskennst.
Sheeva P. schrieb: > LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, > den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und > doppelter Programmspeicher) für nur € 1,35. Na prima, leider ist diese Logik nicht die Regel... Dann gäbs keine Einwände- wenn der größere Flash dann nur nicht zu generell ineffizienterer Programmierweise verführen würde ;-) Sheeva P. schrieb: > was genau bedeuten hier die Termini "groß" und "ganz > groß", bezogen auf Programme, sowie der Terminus "viele" bei den > Berechnungen? Du denkst einfach zu statisch, willst das alles in Schubladen einsortiert haben. Natürlich gibts da keine Regeln. Das ist so variabel wie Übung, Vorbereitung, System der Programmierer die es umsetzen. Sheeva P. schrieb: > Moby A. schrieb: >> Um es aber ganz klar zu sagen: Ich möchte wirklich niemandem den Spaß an >> irgendeiner Sache nehmen. > > Davon hat man bisher leider nichts gemerkt. Daß Du mit Deiner C-Lösung nicht weitergekommen bist kannst Du nicht mir anlasten ;-)
Moby A. schrieb: > Daß Du mit Deiner C-Lösung nicht weitergekommen bist kannst Du nicht mir > anlasten ;-) Wohl aber, dass du damals auf Teufel komm raus NICHT dein Programm in kurzen, klaren Sätzen beschreiben wolltest. Irgendwer hat sogar den Versuch einer Anforderungsbeschreibung unternommen, die du aber bestätigt hast.
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >Moby A. schrieb: >> Flexibler benötigt dann eben auch mehr Ressourcen- gerade wenns in >> Hochsprache erfolgen soll. >Schreib' doch lieber nicht über Dinge, bei denen du dich nicht >auskennst. Sachkenntnis kann jede lebhafte Diskussion nur behindern! ;-)
Das witzigste: Wenn dieser Thread noch wesentlich länger wird, katapultiert TIOBE Assembler noch auf Platz 1, weil: die bei µC.net schreiben ja monatelang darüber! :-)
Jörg W. schrieb: > Schreib' doch lieber nicht über Dinge, bei denen du dich nicht > auskennst. Tja, leider leider ist es aber so ;-( Flexibilität kostet. In Form von portablem C bis zu 50% mehr Flash (Prognose von Peter D.- kann ich selbst aber nicht bestätigen) Was ich Dich noch fragen wollte, hast Du eigentlich wirklich schon mal was mit Xmega entwickelt? Robert L. schrieb: > was war jetzt nochmal der Grund warum du den Code deines XMega Projektes > (den mit dem Xport) nicht einfach postest?? Hatte ich das nicht schon beantwortet? Bitte such das nochmal raus. Wär auch reichlich unsinnig... Die meisten können schon das bischen Tiny-Code meines Projekts nicht nachvollziehen, obwohl sie hier große Reden schwingen ;-) Frank M. schrieb: > Du hast es bis heute ja auch nicht geschafft, Deinen unleserlichen > Projektcode derart zu dokumenieren, dass man in C eine funktionsfähige > Version Deines Codes programmieren kann! ;-) Das dürfte eher eine Aussage über Deine Kenntnisse sein... Wer aber auch mein kleines Programm mit leerem C-Code übersetzt der muß sich nicht mehr wundern wenn man dessen Beiträge nicht mehr ernst nimmt ;-) Sheeva P. schrieb: > Aber Assembler ist Spaghetticode by Design; es gibt da schlicht und > einfach keine Struktur und auch keine Sprachmittel, um das Programm zu > strukturieren. ... sprach der Experte ;-) Du redest auch viel wenn der Tag lang ist, oder? Zeig mal was Konkretes, das man auch ernst nehmen könnte ;-) Michael K. schrieb: > "8bit ought to be enough for anybody > [Moby Dick] > > "Ich bin ASM, Dein Gott. Du sollst keine anderen Programmierspachen > neben mir haben." > [Erstes Gebot Moby] > > "Wir sind ASM. Sie werden assimiliert werden. Deaktivieren Sie Ihre > Schutzschilde und ergeben Sie sich. Wir werden ihre biologischen und > technologischen Charakteristika den unsrigen hinzufügen. Ihre Kultur > wird sich anpassen und uns dienen. Widerstand ist zwecklos!" > [Raumschiff Entermoby] Das hebt mich und meine Absichten jetzt in Sphären, zu denen ich nie emporsteigen wollte... Nehmt Asm als das was es ist: Als optimale Programmierform kleiner 8-Bitter für übliches MSR.
:
Bearbeitet durch User
Moby A. schrieb: > Zu einem fertigen Design mal eben ein (paar) Sensoren hinzufügen zu > wollen ist eben alles andere als eine Lapalie. Bei mir wäre es das, solange der Bus, an dem die Sensoren hängen, und meine Software entsprechende Reserven haben. Ist der Bus ausgereizt => Worst case. Ist jedoch die Software ausgereizt, änndere ich an genau einer Stelle eine Zahl und die Software kann nun x Sensoren mehr verarbeiten, genügend RAM vorausgesetzt. Diese Änderung ist in unter einer Minute erledigt. Kannst du dir jetzt vorstellen, warum Flexibilität gewüscht ist? Moby A. schrieb: > Ich bevorzuge, die > benötigte Hardware zuallererst zu ermitteln, passende Software zu > schreiben (bei AVR keine Wissenschaft) und damit die optimale Lösung > aufs Parkett zu legen- andere Herangehensweisen könnte man glaub ich > leicht in der Nähe gepflegten Pfusches ansiedeln. passt irgendwie nicht zu Moby A. schrieb: > Meistens weiß man > auch nicht vorher, was die Zunkunft so alles an Ideen bringt.
>> LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, >> den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und >> doppelter Programmspeicher) für nur € 1,35. >Na prima, leider ist diese Logik nicht die Regel... Dann gäbs keine >Einwände- wenn der größere Flash dann nur nicht zu generell >ineffizienterer Programmierweise verführen würde ;-) doch, das ist die Regel.. nicht die Flash-Größe entscheidet den Preis, sondern die Stückzahl.. (vor allem wennst über den Tellerrand schaust, aka stm32 samt "board" für 3$ usw. , ) und JA man Programmiert ja absichtlich "Moby"-Ineffizient.. du bist nur der einzige der damit ein Problem hat ;-)
Frank M. schrieb: > Das witzigste: Wenn dieser Thread noch wesentlich länger wird, > katapultiert TIOBE Assembler noch auf Platz 1, weil: die bei µC.net > schreiben ja monatelang darüber! Das ist eine interessante Betrachtungsweise. Dann ist Moby womöglich gar kein Programmierer, sondern ein Bot. Und die Mehrzahl der "Leute", die ihm hier vehement widersprechen, sind ebenfalls Bots. Und das alles nur, um das Ranking zu verbessern. Jetzt ist die Sache klar. Also ist alles eine Verschwörung. Möglicherweise steckt ein Hasser einer weit verbreiteten Hochsprache dahinter. mfg.
Moby A. schrieb: > Jörg W. schrieb: >> Schreib' doch lieber nicht über Dinge, bei denen du dich nicht >> auskennst. > > Tja, leider leider ist es aber so ;-( Nein, keineswegs. > Flexibilität kostet. In Form von portablem C bis zu 50% mehr Flash > (Prognose von Peter D.- kann ich selbst aber nicht bestätigen) Die ist in dieser Form einfach Quatsch (auch wenn ich Peter sonst schätze), und nichts, auf dem du dich ausruhen solltest. Wenn das typische C-Programm 10 % mehr Code generiert als ein schönes, handgefeiltes Assemblerprogramm, dann dürfte das deutlich näher an der Realität sein, auch über 15 % würde ich hier nicht diskutieren. Aber nicht die Flexibilität selbst ist das, was da etwas kostet – das hatte ich dir mit der Umsetzung einer entsprechenden C++-Klasse für die IO-Zugriffe ja bereits demonstriert. Das hättest du in Assembler auch nicht besser hinbekommen, trotzdem ist die C++-Lösung deutlich flexibler, weil sie bspw. auch mit den IO-Ports direkt zurecht kommt, die nicht über SBI/CBI zugegriffen werden können, sondern nur über Speicher-Operationen. Dein einziges Argument dagegen war dann noch, dass die C++-Variante ja „kryptischer“ sei. Mag für dich eins sein, für viele andere ist es keins. > Was ich Dich noch fragen wollte, hast Du eigentlich wirklich schon mal > was mit Xmega entwickelt? Das musst du gerade fragen, der du der Meinung bist, dass die Peripherie der Xmegas kaum Unterschiede zu MegaAVR hätte … Aber wenn es dich beruhigt: ja, und zwar eins, was einen guten Teil der Hardware des entsprechenden Xmega ausgelastet hat, einfach deshalb, weil ein existierendes Board für einen völlig anderen Zweck mit einem kleinen Huckepack-Board umfunktioniert worden ist, sodass manche IO-Pins etwas unglücklich beschaltet worden sind. Da war dann bis zu DMA und Eventsystem alles mit im Boot. Das einzige, was ich da nicht einmal annähernd ausgelastet habe (trotz Gleitkomma und allem) war der Flash, gerade mal 10 KiB von 256 werden benutzt. Habe leider von Atmel kein Geld für die restlichen reichlich 240 KiB zurück bekommen. > Zeig mal was Konkretes, das man auch ernst nehmen könnte ;-) Das haben wir dich schon mehrmals gebeten, aber mehr als das Ding mit dem Tiny13 bekommen wir ja nicht zu sehen.
:
Bearbeitet durch Moderator
P. M. schrieb: > Siehst du, schon wieder das selbe Spiel. Zuerst behauptest du, es gelte > für 8-Bitter. Da stimmt man dir so halb zu. Dann behauptest du, es gelte > prinzipiell für jedes Programm. Da widerspricht man dir. Dann sagst du > wieder, es gehe nicht um grössere Prozessoren. > > Also was jetzt, leg dich fest: Gilt deine Ansicht auch für grössere > Prozessoren als für kleine 8-Bitter? Ja oder Nein? Welches "Spiel" konstruierst Du hier bloß? 1. Was prinzipiell meint hatte ich ausführlichst erklärt. 2. Grössere Controller oder gar Prozessoren hab ich nie als Ziele aufgeführt sondern das Gegenteil gesagt: Sie sind ob ihrer Komplexität nicht mehr für Asm geeignet. Das liegt aber nicht daran daß es mit Asm kein Verbesserungs- potential gäbe! Cyblord -. schrieb: > Jetzt musst du nur noch damit programmieren lernen Moby. Dann kommt > deine Stunde. Schau Dir mein Projektchen an, vielleicht lernst ja Du was draus ;-) Jörg W. schrieb: > Logisch, dass er das nicht hat, hat er ja nie benutzt. Deshalb > glaubt er auch immer noch dran, dass er gegenüber einem Compiler > tatsächlich 50 % kleineren Code verzapfen könnte. Unterstellungen machen wohl auch Moderatoren Spaß, nicht wahr? Demonstrier doch mal die gepriesene Leistungsfähigkeit an meinem Projekt- nur so kannst Du mich davon überzeugen (weil ichs prima vergleichen könnte). Route 6. schrieb: > Für jede Aufgabe das geeignete Werkzeug. Wenn ich hier die engstirnigen > Argumente Deiner "Gegner" lese, kann ich nur lächeln. > Mein Tipp an Dich: lehne dich zurück und lächele! Du mußt Dir doch nicht > die Haare wegen ein paar wenigen Leuten raufen. Es gibt genügend Leute, > die Deine Meinung teilen, sonst gäbe es überhaupt keine Werkzeuge zur > Assemblerprogrammierung. Das tu ich doch unentwegt... Wenn Fakten trotz zehntausendfacher Wiederholung mit alberner Ignoranz, Unkenntnis, Unterstellungen, Witzchen usw. usf. begegnet wird kann man doch nur lachen. Also mir machts Spaß!
> >Robert L. schrieb: >> was war jetzt nochmal der Grund warum du den Code deines XMega Projektes >> (den mit dem Xport) nicht einfach postest?? >Hatte ich das nicht schon beantwortet? Bitte such das nochmal raus. >Wär auch reichlich unsinnig... Die meisten können schon das bischen >Tiny-Code meines Projekts nicht nachvollziehen, obwohl sie hier große >Reden schwingen ;-) das wäre im Detail auch nicht notwendig, es genügt wenn 2 oder 3 den Code halbwegs verstehen/überschauen, und kundtun wie toll er ist.. es gibt hier genug Leute die wirklich gut ASM können, wenn die Code von einem (wie du selber schreibst) durchschnittlichem ASM Programmieren nicht lesen könne, beweist das doch eh nur dass deine Behauptungen nicht zutreffen..
Jörg W. schrieb: > Dass man bei Assembler tatsächlich „jedes Bit im Griff hat“, ich glaube, > darüber sind wir uns alle einig. Allerdings mögen die meisten von uns > (Moby explizit ausgenommen) den dafür zu zahlenden Preis in Form von > Arbeits- oder Lebenszeit nicht zahlen. ... weils an Übung, Vorbereitung und System mangelt. Falk B. schrieb: > Sachkenntnis kann jede lebhafte Diskussion nur behindern! ;-) Du hattest in Falk B. schrieb: > Naja, ich hab vor länhgerer Zeit mal mit STM32 rumgespielt, was mich > dabei am meisten abschreit sind die ELLLLLLENNLAAAANGEN Namen der > Register und die gefühlt TAUSENDEN Einstellungen, die man selbst für > einfachse IO-Konfifiguration machen muss!!! doch ganz vernünftige Ansichten. Insbesondere der aufgeführte Bläh-Code zur Initialisierung! Einfach köstlich. Sollte man Asm-Gegnern jeden Tag um die Ohren hauen ;-)
Moby A. schrieb: > Schau Dir mein Projektchen an, vielleicht lernst ja Du was draus In der Tat lernt man wirklich daraus. Aber nicht das, was du erwartest. Moby A. schrieb: > Demonstrier doch mal die gepriesene Leistungsfähigkeit an meinem > Projekt- nur so kannst Du mich davon überzeugen (weil ichs prima > vergleichen könnte). Du hast das C-Programm aber leider immer noch nicht geliefert. mfg.
:
Bearbeitet durch User
Witkatz :. schrieb: > Und jetzt? Jetzt muss ich mich sofort auf AVR Mikrocontroller stürzen, > mit ausschließlich AVR-ASM. Ich hasse mein Leben ;-) Nein. Mußt Du nicht. Kannst auch weiter 8-bittig Pic-ken... Mir kommts vor allem auf Eines an: Keep it simple. P. M. schrieb: > Wenn du den Thread gelesen hättest, dann würdest du sehen, dass genau > der Standpunkt "geeignetes Werkzeug" hier schon die längste Zeit von den > meisten vertreten wird. Und in den meisten Fällen ist das nicht > Assembler. Für 8-Bit MSR ist das Assembler. Je nach Übung, Vorbereitung, System. Natürlich hat auch C seine Berechtigung. Wogegen ich mich nur wende ist die These vom besseren C-Code gegenüber Asm. be s. schrieb: > Bei mir wäre es das, solange der Bus, an dem die Sensoren hängen Ja ja schön. An einem Bus. Meine Sensoren hängen an eigenständigen, vorverarbeitenden Knoten die die Ergebnisse an die Zentrale funken. Dort ist ein XMega zugange mit viiielen Reserven. Da spart man nicht. So ein SmartHome ist nie fertig. be s. schrieb: > passt irgendwie nicht zu Das passt schon. Konkrete Hardware mit konkreten Aufgaben. Wo Hardware-Erweiterungen denkbar sind macht mans flexibler. In meinem Kühlschrank und ein einem Badlüfter, da wo mein Projektchen eingesetzt wird, ist die vorgegebene Sensorausstattung absehbar ausreichend ;-)
Thomas E. schrieb: > Du hast das C-Programm aber leider immer noch nicht geliefert. Ich hab auch nicht behauptet, es wäre ressourcensparender! Behauptest Du das? Wenn ja: Dann vorzeigen ;-) Thomas E. schrieb: > Dann ist Moby womöglich gar kein Programmierer, sondern ein Bot. Ich merk schon, mangels weiterer Argumente bist jetzt auch Du am Ende ;-) Robert L. schrieb: > und JA man Programmiert ja absichtlich "Moby"-Ineffizient.. > du bist nur der einzige der damit ein Problem hat ;-) S.O. Beweisen bitte ;-) Jörg W. schrieb: >> Flexibilität kostet. In Form von portablem C bis zu 50% mehr Flash >> (Prognose von Peter D.- kann ich selbst aber nicht bestätigen) > > Die ist in dieser Form einfach Quatsch (auch wenn ich Peter sonst > schätze), und nichts, auf dem du dich ausruhen solltest. > Wenn das typische C-Programm 10 % mehr Code generiert als ein > schönes, handgefeiltes Assemblerprogramm, dann dürfte das deutlich > näher an der Realität sein, auch über 15 % würde ich hier nicht > diskutieren. Selbst die 10-15% gehen mir ja schon runter wie Öl ;-) > Aber nicht die Flexibilität selbst ist das, was da etwas kostet – das > hatte ich dir mit der Umsetzung einer entsprechenden C++-Klasse für > die IO-Zugriffe ja bereits demonstriert. Das hättest du in Assembler > auch nicht besser hinbekommen, trotzdem ist die C++-Lösung deutlich > flexibler, ... mit mehr Ressourcenverbrauch. Intransparent-abstraktem Code mit i.d.R. hohem Schreibaufwand. Aber gut, noch eine Verlängerung der C++ Diskussion hier- das schaff ich jetzt zeitlich nicht mehr ;-) > Das musst du gerade fragen, der du der Meinung bist, dass die > Peripherie der Xmegas kaum Unterschiede zu MegaAVR hätte … Genau. Das ist keine Meinung sondern Kenntnis. Nun könnte man freilich wieder übers Wörtchen "kaum" streiten aber Du wirst doch wenigstens zugeben, daß den Umstieg von AVR auf XMega und von AVR auf Cortex Welten trennen... > Aber wenn es dich beruhigt: ja, und zwar eins, was einen guten Teil > der Hardware des entsprechenden Xmega ausgelastet hat, einfach deshalb, > weil ein existierendes Board für einen völlig anderen Zweck mit einem > kleinen Huckepack-Board umfunktioniert worden ist, sodass manche > IO-Pins etwas unglücklich beschaltet worden sind. Da war dann bis zu > DMA und Eventsystem alles mit im Boot. Das einzige, was ich da nicht > einmal annähernd ausgelastet habe (trotz Gleitkomma und allem) war > der Flash, gerade mal 10 KiB von 256 werden benutzt. Habe leider von > Atmel kein Geld für die restlichen reichlich 240 KiB zurück bekommen. Vermutlich in Hochsprache und irgendwelchen Libraries. Kein Wunder, daß man da die Hardware nicht zu Gesicht bekommt ;-) > Das haben wir dich schon mehrmals gebeten, aber mehr als das Ding > mit dem Tiny13 bekommen wir ja nicht zu sehen. Der reicht auch als Demo der Überlegenheit von Assembler.
:
Bearbeitet durch User
Moby A. schrieb: > Ich hab auch nicht behauptet, es wäre ressourcensparender! > Behauptest Du das? Wenn ja: Dann vorzeigen Ich habe das auch nie behauptet. Moby A. schrieb: > Ich merk schon, mangels weiterer Argumente bist jetzt auch Du am Ende Ich habe noch gar nicht angefangen. Moby A. schrieb: > Selbst die 10-15% gehen mir ja schon runter wie Öl Ein sehr guter Assembler-Programmierer erreicht die vielleicht. Du nicht. Moby A. schrieb: > Der reicht auch als Demo der Überlegenheit von Assembler. Lach. mfg.
Moby A. schrieb: > Zeig mal was Konkretes, das man auch ernst nehmen könnte ;-) Pffffffffff ... ich hab mir grad die Tastatur versaut....
Moby A. schrieb: > Selbst die 10-15% gehen mir ja schon runter wie Öl ;-) Ach, was? Neulich warst du noch der Meinung, dass du mit einem halb so großen Device auskämst. > Nun könnte man freilich > wieder übers Wörtchen "kaum" streiten aber Du wirst doch wenigstens > zugeben, daß den Umstieg von AVR auf XMega und von AVR auf Cortex Welten > trennen... Nein, da stimme ich nicht zu. Sie sind anders, aber es sind da keine Welten dazwischen.
Moby A. schrieb: > Mir kommts vor allem auf Eines an: Keep it simple. Für deinen Horizont keine wirkliche Herausforderung ;-)
Moby A. schrieb: > Für 8-Bit MSR ist das Assembler. Je nach Übung, Vorbereitung, System. > Natürlich hat auch C seine Berechtigung. Wogegen ich mich nur wende ist > die These vom besseren C-Code gegenüber Asm. Das stimmt vielleicht dann, wenn "besser" heisst, dass das letzte Bit und der letzte Taktzyklus herausgequetscht wurden. Das ist in der heutigen Software-Entwicklung meistens aber nicht der Fall, da zählen andere Aspekte wie Entwicklungskosten, Wartbarkeit, Sicherheit, usw. Und zwar auch auf kleinen 8-Bittern.
Jörg W. schrieb: > Ach, was? Neulich warst du noch der Meinung, dass du mit einem > halb so großen Device auskämst. Tut er ja auch. Wenn er alles abgezogen hat, was er für unnötig oder viel zu kompliziert hält und was man davon sowieso nicht braucht, dann passt es auch in die Hälfte rein. So optimiert man Code.
:
Bearbeitet durch User
A. K. schrieb: > Wenn er alles abgezogen hat, was unnötig oder viel zu kompliziert ist > und was man sowieso nicht braucht, dann passt es auch in de Hälfte rein. Allerdings ist dieses Abziehen nur ihm gestattet. Allen anderen ist es verboten, weil ja die Erweiterbarkeit drunter leiden würde. ;-)
> Tut er ja auch. Wenn er alles abgezogen hat, was er für unnötig oder > viel zu kompliziert hält und was man davon sowieso nicht braucht, dann > passt es auch in die Hälfte rein. So optimiert man Code. nur daß ich damals mehrere Vorschläge hatte, die seinen Code noch mal kürzer machten, aber die waren natürlich dann "Schwachsinn", weil "not invented here". Alles was M. schreibt ist ein Fakt. Alles was andere schreiben hat mit dem 8-Bit-MSR-Thema nichts zu tun. Und es natürlich klar, daß sein Postulat "es get nicht besser" von anderen wiederlegt werden muß. Auf seiner Forums-Homepage nennt er sein Interesse an Naturwissenschaft. Ein solcher würde dieses C-Programm selber schreiben, um nachzuweisen, daß er Recht hat. So bleibt das eine These. (Und es könnte ja passieren, daß es bessere C-Programmierer gibt) Zudem vermute ich, es sind eher 8-Bit-M(S)-Anwendungen, denn Regelung kann man sich in M.'s kleiner Welt kaum vorstellen. Da muß man nämlich die Vorzeichen beachten.
:
Bearbeitet durch User
Wie ein kleines Kind vom Sandkasten nebenan doch die halbe Welt beschäftigen kann .... Wieso antwortet ihr überhaupt?
Markus M. schrieb: > Wie ein kleines Kind vom Sandkasten nebenan doch die halbe Welt > beschäftigen kann .... Wieso antwortet ihr überhaupt? Deshalb: Falk B. schrieb: > Schattenbox soll ja auch ganz nett sein. Chinesisches Schattenboxen dient "der Gesundheit, der Persönlichkeitsentwicklung und der Meditation" (Wikipedia).
Route 6. schrieb: > Ich bin ebenfalls begeisterter Assembler-Programmierer; auf vielen > Prozessorarchitekturen. Ich programmiere auch in Hochsprache, vom > verrückten FORTH über das kinderleichte C bis zu netzwerkfähigen > Datenbankanwendungen für komplette Firmen. Für komplette Firmen? Beeindruckend. Die meisten von uns entwickeln nur Anwendungen für halbe, viertel und achtel Firmen. Eine netzwerkfähige Datenbankanwendung in Assembler ist bestimmt sehr spannend, so etwas würde ich wirklich zu gerne mal sehen. ;-) > Für jede Aufgabe das geeignete Werkzeug. Lustigerweise sind hier alle darüber einig, außer Deinem Freund. ;-) > Wenn ich hier die engstirnigen Argumente Deiner "Gegner" lese, kann ich > nur lächeln. Frag' uns mal... > Als ich letztens am Biertisch die Sorgen eines Bekannten hörte, der für > die sicherheitsrelevante Software in seiner Firma die Validierung seines > verwendeten C-Compilers machen muss, standen mir die Haare zu Berge. > Er überlegt, alles in Assembler umzuschreiben, denn das würde der TÜV > akzeptieren. LOL! Was für einen seltsamen Compiler benutzt denn Dein Bekannter, daß er keinen Assembler-Code erzeugen kann? Damit könnte er auf das Neuschreiben verzichten, stattdessen für lange Zeit in Urlaub fahren, und trotzdem den TÜV-Prüfer und seinen Chef gleichzeitig glücklich machen. Das ist sicher nicht die übelste Ausgangslage für die nächste Gehaltsverhandlung.
Moby A. schrieb: > Sheeva P. schrieb: >> LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, >> den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und >> doppelter Programmspeicher) für nur € 1,35. > > Na prima, leider ist diese Logik nicht die Regel... Dann gäbs keine > Einwände- wenn der größere Flash dann nur nicht zu generell > ineffizienterer Programmierweise verführen würde ;-) Dank größeren Flashs könnte man sich die sogar problemlos leisten. Damit hätte man obendrein viel kostbare Lebenszeit für noch bessere Funktionen, noch schönere Dinge und noch interessantere Projekte gewonnen. :-) > Sheeva P. schrieb: >> was genau bedeuten hier die Termini "groß" und "ganz >> groß", bezogen auf Programme, sowie der Terminus "viele" bei den >> Berechnungen? > > Du denkst einfach zu statisch, willst das alles in Schubladen > einsortiert haben. Natürlich gibts da keine Regeln. Das ist so variabel > wie Übung, Vorbereitung, System der Programmierer die es umsetzen. Tatsächlich denke ich da überhaupt gar nicht statisch, im Gegenteil. Die Fuzzy Logic ist bei sowas extrem dynamisch und flexibel. Also beantworte doch bitte meine Frage -- Du kannst das auch gerne in Assembler mit dem Fuzzy-Logic-Befehlssatz des M68HC12 ausdrücken, wie im "Motorola 68HC12 CPU12 Reference Manual" [1] dokumentiert. HF! [1] http://www.freescale.com/files/microcontrollers/doc/ref_manual/CPU12RM.pdf >> Moby A. schrieb: > Daß Du mit Deiner C-Lösung nicht weitergekommen bist kannst Du nicht mir > anlasten ;-) Das trifft leider nicht den Sachverhalt, wie Du ja weißt. Als ich meinen Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue Anforderungen aus dem Hut gezaubert. Du hast behumst, und daraufhin habe ich die Sache abgebrochen und mich den schöneren Dingen in meinem Leben zugewandt. Warum sollte ich weiter denn mit einem Betrüger spielen? Ich hatte alles bewiesen, was zu beweisen war. (Und nein, mein Interesse an schlichtesten Sensorplatinchen, die nichteinmal mit Standardprotokollen kommunizieren, ist haargenau gleich Null.) :-) Insofern kannst Du mit Deiner Behauptung, ich sei "nicht weitergekommen", vielleicht Dich selbst blenden. Alle, die dabei waren, wissen es besser, und die anderen können es dank Deines Links ja selbst nachlesen. :-))
Moby A. schrieb: > Sheeva P. schrieb: >> Aber Assembler ist Spaghetticode by Design; es gibt da schlicht und >> einfach keine Struktur und auch keine Sprachmittel, um das Programm zu >> strukturieren. > > ... sprach der Experte ;-) Du bist ja doch zuem Erkenntnisgewinn fähig. Diese Hoffnung hatte ich fast schon verloren gegeben. ;-) > Du redest auch viel wenn der Tag lang ist, oder? Nein, manchmal rede ich auch an kurzen Tagen viel und an langen Tagen wenig, da bin ich absolut flexibel. > Zeig mal was Konkretes, das man auch ernst nehmen könnte ;-) Warum denn? Du würdest es doch ohnehin nicht verstehen. Davon abgesehen bist natürlich zuerst einmal Du an der Reihe, was Ernstzunehmendes zu zeigen. ;-)
Moby A. schrieb: > Mir kommts vor allem auf Eines an: Keep it simple. Ach Quatsch, dann würdest Du ja C oder C++ benutzen. > Wogegen ich mich nur wende ist die These vom besseren C-Code > gegenüber Asm. Du wendest Dich also gegen etwas, das nie jemand behauptet hat. Bitte grüß' Dulcinea und Sancho.
Gu. F. schrieb: > Michael K. schrieb: >> Doch doch, ich versteh das Problem schon. >> Du fühlst Dich in Deinem Stolz verletzt und mußt das jetzt unbedingt >> richtigstellen. >> Unmöglich aufzuhören bis Moby sich endlich mit einem Strauß Blumen in >> der Hand bei Dir entschuldigt hat. > > Du bist entweder krank oder Mobys zweit Account. tststs. Es steht mir als Neuling und Wenig-Leser bzw. -Schreiber hier sicherlich nicht an, Vorschläge zu machen. Aber wundern wird man sich hoffenlich noch dürfen. Es wundert mich nämlich, mit welcher Inbrust einerseits auf schlimmstenfalls thematisch verfehlte Beiträge eines einzelnen Vielschreibers durch demonstratives Löschen reagiert wird, solche groben Entgleisungen wie die da oben hingegen kommentarlos toleriert werden. Und, nein, ich bin weder ein Alias von "Mobi AVR" noch von Michael Knoelke (bloß um eine weitere vorhersehbaren Giftelei vorwegzunehmen). Ich fand lediglich seine Beiträge bis hierhin (weiter habe ich bisher nicht gelesen) ausgesprochen ausgewogen und neutral. Erstaunlich, daß ausgerechnet das dann offenbar besonders provokant erscheint. Um nun auch was zum Themal selber zu sagen: Wenn man nach ein wenig Fortran und PL/I vor zig Jahren seine ersten umfangreicheren Programmierarbeiten mit Simula 67 und Snobol/Spitbol erledigt hat, dann kann man über die verbalen Schlachten zwischen Fans von Asm hier und C dort nur schmunzeln. Dann erinnert man sich nämlich an auch schon lange zurückliegendes, aber ähnlich verbissenes Geläster von Verfechtern echter Hochsprachen über diesen schlichten Quasiassembler, der sich als Hochsprache aufspielt. 1/2 :)
A. K. schrieb: > Also übersichtlicher als so geht's doch kaum: > 1⌈2 > 2 > 2⌈1 > 2 > ⌈/1 2 3 4 5 3 8 1 3 > 8 Niedlich, APL. Ich habe hier irgendwo noch einen Kugelkopf rumliegen ...
Wolfgang S. schrieb: > Niedlich, APL. Ich habe hier irgendwo noch einen Kugelkopf rumliegen ... und der Durchmesser ist wievel Meter?
Johann L. schrieb: > und der Durchmesser ist wievel Meter? Völlig harmlos. Es gibt keine Kleinbuchstaben und viele Operatoren entstehen durch Übereinanderdruck zweier anderer.
A. K. schrieb: > und viele Operatoren entstehen durch Übereinanderdruck zweier anderer. So habe ich mit meinem ersten elektromechanischen Druckwerk (im Prinzip eine „elektrische“ Schreibmaschine, deren Tasten durch Zugmagneten angesteuert werden konnten) auch die geschweiften Klammern gedruckt. ;-) Eine eckige Klammer, einen Backspace (der eine ganze Umdrehung der Motorwelle braucht :), danach eine Spitzklammer (aka. kleiner/größer als). :.) Aber wir sollten wohl besser einen separaten APL-Thread dafür dann öffnen. Hier geht's ja schließlich darum, dass Assembler jetzt auf dem Vormarsch ist.
Thomas E. schrieb: > Moby A. schrieb: > Der reicht auch als Demo der Überlegenheit von Assembler. > > Lach. Machen. Nicht lachen ;-)
A. K. schrieb: > Wenn er alles abgezogen hat, was er für unnötig oder > viel zu kompliziert hält und was man davon sowieso nicht braucht, dann > passt es auch in die Hälfte rein. So optimiert man Code. ... der dann die gestellte Aufgabe immer noch erfüllt ;-)
Versteh ich nicht! Trollthreads mit echt guten und lustigen Ideen mit Potential zu entspannter Unterhaltung werden sofort gelöscht und so ein Scheisdreck (jaja, mit Verlaub und so...) wird hier ewiglich geduldet :-D Humorloses Volk :-D
Carl D. schrieb: > Alles was M. schreibt ist ein Fakt. Alles was andere schreiben ... überzeugt wenig, wenn's nicht mit Code bewiesen werden kann. Markus M. schrieb: > Wie ein kleines Kind vom Sandkasten nebenan doch die halbe Welt > beschäftigen kann .... Wieso antwortet ihr überhaupt? Sandkasten. Gutes Stichwort. Da sitzt eher mancher Sprücheklopfer hier ;-) Sheeva P. schrieb: > Als ich meinen > Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue > Anforderungen aus dem Hut gezaubert. Der war gut ;-) Nackte Panik. Was man da alles rauslesen kann wenn es unbedingt sein muß... Nö. Du schimpfst wie ein Rohrspatz, um von Deiner gradios gescheiterten C-Programmruine, die Du da in meinen Projektthread reingestellt hast abzulenken. Die ist nun als weithin sichtbares Monument Deiner (Nicht-) Fähigkeiten zu bewundern. Also zu meiner Ehre hätte ja gehört, Fehler nicht nur zuzugeben, sondern ein einmal angefangenes Werk auch mit erhobenem Haupt zu Ende zu bringen... Das hätte Dir auch keiner abgerissen wenn Du das bekannte Ziel nicht erreicht hättest. Alle Infos zur Realisierung waren da, keine der ganz wenigen Fragen blieb unbeantwortet (mit meinem Verweis auf längst Bekanntes natürlich). Sogar gratis Hardware hatte ich Dir zur Unterstützung angeboten... Statt dessen höre ich jetzt nur albernste Ausreden.
Wolfgang S. schrieb: > Ich fand lediglich seine Beiträge bis hierhin (weiter habe ich bisher > nicht gelesen) ausgesprochen ausgewogen und neutral. Erstaunlich, daß > ausgerechnet das dann offenbar besonders provokant erscheint. Wahrheiten die man nicht zur Kenntnis nehmen will können schon sehr provokant wirken. Den Ertappten ist dann kein Mittel zu schade, den Störenfried zur Ruhe zu bringen. Das ist allerdings eine etwas zähe Angelegenheit, wenn dieser seine Behauptungen mit Code untermauert- und wird zu einem echten Ärgernis, wenn man dann als großartiger C-Profi nicht gegenhalten kann. Ertappt halt, das ist echt unangenehm ;-)
Moby A. schrieb: > Sheeva P. schrieb: >> Als ich meinen >> Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue >> Anforderungen aus dem Hut gezaubert. > > Der war gut ;-) Das ist kein Witz, sondern eine Tatsache. Wenn du deine Anforderungen klar aufgelistet hättest, wäre schon lange ein C/C++ Programm rausgehauen worden, das auch deinen Anforderungen entspricht. Ein ASM-Listing und Frasen wie "das ist doch jeden klar" zählen nicht als Anfroderung, aber das hast du ja schon im entsprechenden Thread nicht begreifen wollen. Nachträglich als Anferderung zu definieren, dass kein RAM, das nicht als Register bezeichnet wird, verwendet werden darf, zeugt nicht gerade von Fairness. Moby A. schrieb: > Wahrheiten die man nicht zur Kenntnis nehmen will können schon sehr > provokant wirken. Den Ertappten ist dann kein Mittel zu schade, den > Störenfried zur Ruhe zu bringen. Das spiegelt eher dein Verhalten wieder, siehe meine Erläuterungen oben im Beitrag. Moby A. schrieb: > Das ist allerdings eine etwas zähe > Angelegenheit, wenn dieser seine Behauptungen mit Code untermauert- und > wird zu einem echten Ärgernis, wenn man dann als großartiger C-Profi > nicht gegenhalten kann. Doch, doch, wir können alle sehr gut gegenhalten, nur haben wir alle schon lange erkannt, dass dieses Vorhaben nie Früchte tragen wird und nutzen diesen Umstand, um uns zu amüsieren.
> Carl D. schrieb: >> Alles was M. schreibt ist ein Fakt. Alles was andere schreiben > > ... überzeugt wenig, wenn's nicht mit Code bewiesen werden kann. Es ist nur unter seriösen Wettstreitern so, daß der, der die Behauptung aufstellt, sie auch beweisen muß. Und die Ausgangsbehauptung ist: "ASM ist für 8-Bit-MC-Projekte immer besser" Un diesen Beweis kann man führen, indem man nachweist, daß daß JEDES ASM-Projekt besser ist, oder ein nicht-ASM-Projekt schlechter. Ersteres zählt zu den großen Problemen der Informatik, zweiteres sollte doch für jemanden, der so überzeugt davon ist, kein Problem sein. Alternativ kann man natürlich die These auch einfach unbewiesen stehen lassen, dann ist sie aber auch kein Fakt. (M.'s Verfahren wird nun wieder sein, einige Posts später Bruchstücke davon zu zitieren und ins Lächerliche zu ziehen. Aber alle hacken ja nur auf ihm rum :-(( )
:
Bearbeitet durch User
be s. schrieb: > Nachträglich als Anferderung zu definieren, dass kein > RAM, das nicht als Register bezeichnet wird, verwendet werden darf, > zeugt nicht gerade von Fairness. Unfug. Register hat jeder AVR die gleichen 32 an der Zahl. Im wertvollen, zusätzlichen SRAM unterscheiden sie sich. Der zählt selbstverständlich zu den einzusparenden Ressourcen für einen ordentlichen Vergleich. Das Projektchen ist dermaßen einfach, daß schon in meinen ersten Beiträgen funktionell eigentlich alles klar war. Dennoch findet sich im Thread nochmal eine Anforderungs-Liste die alle Gegebenheiten klarstellt. Ändert aber auch nix... Infos bis zum Erbrechen, die manche Leute oh Wunder einfach nicht zur Kenntnis nehmen können. Das muß irgendeine Wahrnehmungsstörung sein ;-( Nennen wir doch das Kind beim Namen: C bringts (hier und anderswo) einfach nicht ! > Doch, doch, wir können alle sehr gut gegenhalten Hab schon besser gelacht. Lustig ist aber, wie einzelne hier immer für "alle" und "uns" sprechen. Na ja, Gleichgesinnte sollten einfach wieder und wieder einander versichern und sich trösten, das scheint hier auch besonders nötig zu sein ;-) Aber schön, wenn die Unterhaltung auf Gegenseitigkeit beruht, da sind wir "uns" ja mal einig ;-)
Moby A. schrieb: > Sheeva P. schrieb: >> Als ich meinen >> Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue >> Anforderungen aus dem Hut gezaubert. > > Der war gut ;-) Das kann ja jeder im besagten Thread nachlesen. :-)) > Nackte Panik. Was man da alles rauslesen kann wenn es unbedingt sein > muß... > Nö. Du schimpfst wie ein Rohrspatz, um von Deiner gradios gescheiterten > C-Programmruine, die Du da in meinen Projektthread reingestellt hast > abzulenken. Ach, Moby, lernst Du es denn nie? Es wird Dir nicht gelingen, mich zu provozieren. Das können nur Leute, die ich ernst nehme. > Die ist nun als weithin sichtbares Monument Deiner (Nicht-) > Fähigkeiten zu bewundern. Meine Fähigkeiten können andere anhand meines Code beurteilen, ansonsten gilt weiterhin das bereits Gesagte: Als ich meinen Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue Anforderungen aus dem Hut gezaubert. Du hast behumst, und daraufhin habe ich die Sache abgebrochen und mich den schöneren Dingen in meinem Leben zugewandt. Warum sollte ich weiter denn mit einem Betrüger spielen? Ich hatte alles bewiesen, was zu beweisen war. :-)
A. K. schrieb: > Moby A. schrieb: > Unfug. Register hat jeder AVR die gleichen 32 an der Zahl. > > Fast jeder. Ok, fast jeder. Ändert aber jetzt auch nix. Carl D. schrieb: > Es ist nur unter seriösen Wettstreitern so, daß der, der die Behauptung > aufstellt, sie auch beweisen muß. Und die Ausgangsbehauptung ist: > "ASM ist für 8-Bit-MC-Projekte immer besser" Wenn Du seriös argumentieren würdest hättest Du zur Kenntnis genommen, warum ich das Projekt derart positioniert habe: Als von vielen geforderten Beispielcode, um meine Aussagen in anderen Threads zuvor zu belegen und die Apostel der C-Überlegenheit Lügen zu strafen. Bitteschön. Aber es kam ja wie es kommen musste: Außer (z.T. recht hohlem) Reden nix gewesen ;-)
Moby A. schrieb: > Dennoch findet sich im Thread nochmal eine Anforderungs-Liste die alle > Gegebenheiten klarstellt. Hallo Moby, könntest Du bitte die Stelle im Thread zeigen. Ich finde nichts. Vielleicht sehe ich vor lauter Bäume den Wald nicht. Danke
A. K. schrieb: > Moby A. schrieb: > Unfug. Register hat jeder AVR die gleichen 32 an der Zahl. > > Fast jeder. Ok, fast jeder. Ändert aber jetzt auch nix. Carl D. schrieb: > Es ist nur unter seriösen Wettstreitern so, daß der, der die Behauptung > aufstellt, sie auch beweisen muß. Und die Ausgangsbehauptung ist: > "ASM ist für 8-Bit-MC-Projekte immer besser" Wenn Du seriös argumentieren würdest hättest Du zur Kenntnis genommen, warum ich das Projekt derart positioniert habe: Als von vielen geforderten Beispielcode, um meine Aussagen in anderen Threads zuvor zu belegen und die Apostel der C-Überlegenheit Lügen zu strafen. Bitteschön. Aber es kam ja wie es kommen musste: Außer (z.T. recht hohlem) Reden nix gewesen ;-) Sheeva P. schrieb: > Ich hatte alles bewiesen, was zu beweisen war Solange Du an diesen Quatsch glauben magst tu es doch. Bleibt Dir zur Rechtfertigung wohl nichts anderes übrig... Aber glaub mir, da hab ich schon überzeugendere Vorstellungen erlebt ;-)
Werner P. schrieb: > Hallo Moby, > > könntest Du Nein, Moby kann nicht. Die explizite Funktions-Liste darfst Du selber finden. Und nein, da steht nix von SRAM. Das war wie minimaler Flash-Verbrauch = Teil der MC-Ressourcen als selbstverständlich für einen anständigen Vergleich vorausgesetzt... Weil sich daran manche C-Gemüter entzünden scheint es DER Pferdefuß von C zu sein ;-)
:
Bearbeitet durch User
Moby A. schrieb: > be s. schrieb: >> Nachträglich als Anferderung zu definieren, dass kein >> RAM, das nicht als Register bezeichnet wird, verwendet werden darf, >> zeugt nicht gerade von Fairness. > > Unfug. [...] > Nennen wir doch das Kind beim Namen: C bringts (hier und anderswo) > einfach nicht ! Du selbst bist es, der es (hier und anderswo) nicht bringt. Deswegen bist Du auch mit einer so einfachen Sprache wie C schon dermaßen überfordert, daß Du schon nach einem einzigen aufgegeben hast. Aber anstatt nun zuzugeben, daß nur Du selbst zu faul oder zu unfähig warst, beschuldigst Du einfach die Programmiersprache und arbeitest Deinen Neid an ihren Nutzern ab... Schon klar: wenn Du nicht schwimmen kannst, ist die Badehose schuld. :-) > Aber schön, wenn die Unterhaltung auf Gegenseitigkeit beruht, da sind > wir "uns" ja mal einig ;-) Soweit es mich betrifft, muß es "Ihr" und "Euch" heißen; an Deinem "wir" oder "uns" möchte ich mich ausdrücklich ausschließen. Danke.
Moby A. schrieb: > A. K. schrieb: >> Moby A. schrieb: >> Unfug. Register hat jeder AVR die gleichen 32 an der Zahl. >> >> Fast jeder. > > Ok, fast jeder. Ändert aber jetzt auch nix. Fast nix.
> könntest Du bitte die Stelle im Thread zeigen. Ich finde nichts. > Vielleicht sehe ich vor lauter Bäume den Wald nicht. Hies es nicht: Keiner hat vor ein eindeutige Projektanforderung zu schreiben.
https://www.youtube.com/watch?v=t2nIF2ZO5jw Ähnlichkeiten mit lebenden Personen und Threads sind nicht zufällig und voll beabsichtigt.
Sheeva P. schrieb: > Deswegen > bist Du auch mit einer so einfachen Sprache wie C schon dermaßen > überfordert, daß Du schon nach einem einzigen aufgegeben hast. "Überforderung" hatte ich gerade in irgend einem anderen Zusammenhang im Gedächtnis ;-) Na ja "aufgeben" würde ich das nicht nennen- eher die Rückkehr ins bewährt-Einfache! Mit dem C-Programm hab ich mir derart einen abgebrochen daß ich bis Ende meiner Tage kuriert bin. Immerhin, ich habs vollständig bis zur fehlerfreien Endversion durchgezogen ;-) > Danke. Bitte.
@ Sheeva Plug (sheevaplug)
>Schon klar: wenn Du nicht schwimmen kannst, ist die Badehose schuld. :-)
Wieso Badehose? Moby ist nackt, wie Gott ihn schuf! Also
programmiertechnisch gesehen ist er noch im ASM-Paradies, er hat noch
nicht vom Baum der Hochsprachenerkenntnis genascht (C) und somit wurde
er auch noch nicht aus dem Paradies vertrieben! Der Glückliche! Der hast
sich nicht vom Weibe (Ada?) verführen lassen!
Amen!
Moby A. schrieb: > Na ja "aufgeben" würde ich das nicht nennen- eher die Rückkehr ins > bewährt-Einfache! Mit dem C-Programm hab ich mir derart einen > abgebrochen daß ich bis Ende meiner Tage kuriert bin. Immerhin, ich habs > vollständig bis zur fehlerfreien Endversion durchgezogen ;-) Hallo Moby, dann existiert ja ein von Dir erstelltes und lauffähiges C-Programm. Wäre nett wenn Du den Source zur Verfügung stellst. Grüße, Werner
> Moby A. schrieb: >> A. K. schrieb: >>> Moby A. schrieb: >>> Unfug. Register hat jeder AVR die gleichen 32 an der Zahl. >>> >>> Fast jeder. >> >> Ok, fast jeder. Ändert aber jetzt auch nix. > > Fast nix. Typische 8-Bit-MSR-Projekte nutzen kein 6-Pin-AVR's. Da funktioniert ja der Register-Allokator nicht mehr.
Falk B. schrieb: > er hat noch > nicht vom Baum der Hochsprachenerkenntnis genascht (C) Genau so wie beschrieben ;-) Also "Naschen" ist dann doch was anderes, der sperrige umständliche C-Blähcode lag mir schwer im Magen.
Werner P. schrieb: > Hallo Moby, > > dann existiert ja ein von Dir erstelltes und lauffähiges C-Programm. > Wäre nett wenn Du den Source zur Verfügung stellst. > > Grüße, Werner Hallo Werner, hast Du die Funktionsliste schon gefunden oder stellst Du hier nur rhetorische Testfragen? Grüße, Moby
Moby A. schrieb: > Werner P. schrieb: >> Hallo Moby, >> >> dann existiert ja ein von Dir erstelltes und lauffähiges C-Programm. >> Wäre nett wenn Du den Source zur Verfügung stellst. >> >> Grüße, Werner > > Hallo Werner, > > hast Du die Funktionsliste schon gefunden oder stellst Du hier nur > rhetorische Testfragen? > > Grüße, Moby Hallo Moby, nein, habe ich noch nicht gefunden. Kein Wunder bei der Länge des Threads ;-) Der C-Code wäre von Vorteil da ich in C und nicht in ASM programmiere. Grüße, Werner PS: Ich habe nicht die Absicht rhetorische Fragen zu stellen. Mich interessiert einfach nur der C-Code.
Werner P. schrieb: > Mich > interessiert einfach nur der C-Code Ich denk mal da hast Du gerade was falsch verstanden !? Es handelt sich nicht um C-Code für mein Tiny13 Projekt worauf ich selber warte sondern meinen ersten und einzigen (war was für PC DOS-Kommandozeile). Dafür wirst Du Dich jetzt weniger interessieren...
:
Bearbeitet durch User
Moby A. schrieb: > Werner P. schrieb: >> Mich >> interessiert einfach nur der C-Code > > Ich denk mal da hast Du gerade was falsch verstanden !? > Es handelt sich nicht um C-Code für mein Tiny13 Projekt worauf ich > selber warte sondern meinen ersten und einzigen (war was für PC > DOS-Kommandozeile). Dafür wirst Du Dich jetzt weniger interessieren... ah, ok.
Carl D. schrieb: > Typische 8-Bit-MSR-Projekte nutzen kein 6-Pin-AVR's Die nutzen da alles was ein paar Beine hat ;-)
Moby A. schrieb: > > Robert L. schrieb: >> und JA man Programmiert ja absichtlich "Moby"-Ineffizient.. >> du bist nur der einzige der damit ein Problem hat ;-) > > S.O. Beweisen bitte ;-) > ?? ich schreib dass ich absichtlich! mehr speicher (Flash, RAM..) verbrauche als unbedingt (theoritisch) notwendig wäre und ich soll jetzt beweisen, dass du ein Problem damit hast?? ...
Moby A. schrieb: >Mit dem C-Programm hab ich mir derart einen >abgebrochen daß ich bis Ende meiner Tage kuriert bin. Immerhin, ich habs >vollständig bis zur fehlerfreien Endversion durchgezogen ;-) Du meinst sicher sowas...
1 | #include <stdio.h> |
2 | |
3 | int main(void) |
4 | {
|
5 | puts("Hallo Welt!"); |
6 | }
|
:
Bearbeitet durch User
Moby A. schrieb: > Mit dem C-Programm hab ich mir derart einen > abgebrochen daß ich bis Ende meiner Tage kuriert bin. Das scheint hier das eigendliche Problem zu sein. Viele Grüße, Stefan
Und Assembler scheint auch nur deshalb leidlich zu funktionieren, weil Du die Teile des Befehlssatzes, die Du nicht verstehst, einfach ausblendest. "Effizient programmieren" ist bei Dir nur ein Synonym für "Ich programmiere nur das, was ich bereits kann". Denn natürlich ist Lernen immer mit Aufwand verbunden, der beim ersten Projekt noch nicht wieder reingeholt wird - und dieses damit "ineffizient" macht. Stefan
Falk B. schrieb: > @ Sheeva Plug (sheevaplug) > >>Schon klar: wenn Du nicht schwimmen kannst, ist die Badehose schuld. :-) > > Wieso Badehose? Moby ist nackt, wie Gott ihn schuf! Also > programmiertechnisch gesehen ist er noch im ASM-Paradies, er hat noch > nicht vom Baum der Hochsprachenerkenntnis genascht (C) und somit wurde > er auch noch nicht aus dem Paradies vertrieben! Der Glückliche! Der hast > sich nicht vom Weibe (Ada?) verführen lassen! > > Amen! Hätte ich denn schreiben sollen, daß dann die Sackhaare schuld sind? Das ist hier ja wohl immer noch ein Familienforum!
Moby A. schrieb: > Ich denk mal da hast Du gerade was falsch verstanden !? > Es handelt sich nicht um C-Code für mein Tiny13 Projekt worauf ich > selber warte sondern meinen ersten und einzigen (war was für PC > DOS-Kommandozeile). Dafür wirst Du Dich jetzt weniger interessieren... Ach, da haben wir ja dein eigentliches Problem. Du bist seit zig Jahren festgefahren in deinem Handeln, bist außerdem schon ein wenig älter, da fällt das Lernen nicht mehr ganz so leicht. Irgendwann hast du dann doch mal beschlossen dir dieses ominöse "C", von dem alle sprechen, doch mal genauer anzuschauen. Du hast also bisl lustlos irgendwo quergelesen, irgendwie dein Programm durch den Compiler gekriegt, und plötzlich - ging nix! Hinten und vorne keinen Plan was du da eigentlich machst hast du mit der Fehlersuche begonnen und wärst fast daran verzweifelt. Daraufhin hast du dann beschlossen, dieses C abgrundtief zu hassen. So ein unleserlicher, fehlerträchtiger Rotz! Aber halt: es gibt Millionen Leute da draussen, die seit geraumer Zeit Millionen von funktionierenden, wartbaren C-Programmen schreiben. Das passt nicht ganz ins Weltbild, denn nichts ist so schwer wie sich einzugestehen, dass man selbst an einer Hürde gescheitert ist die viele andere locker gepackt haben. Also werden diese erfolgreichen Programmierer kurzerhand zu fehlgeleiteten Wesen erklärt. Arme, verirrte Wanderer oder Masochisten die einzig deswegen in C programmieren weil sie nie das Glück hatten, das Assembler-Licht zu sehen. Weißt du Moby, du erinnerst mich an mich selbst bevor ich studiert hatte. Ich hatte ein wenig in QBasic (unter Win3.1) herumgespielt. Ums kurz zu machen: ich hatte von Tuten und Blasen keine Ahnung, hielt mich aber für den größten Hacker weil ich die Übungen im Informatikunterricht immer am schnellsten erledigt hatte. Dann im Studium wurde ich mit diesem kryptischen C konfrontiert. Und weißt du was? Ich hab genauso reagiert wie du. Was hab ich geschimpft, dass wir diese anachronistische, kryptische Uraltsprache lernen mussten! Nicht mal die Farbe der Kommandozeilenausgabe kann man mit einem simplen "COLOR 1, 2" umstellen! Von den dummen Pointern garnicht zu reden! Meinen Kommilitonen hab ich die ganze Zeit erzählt wie toll und einfach das doch alles in QBasic wäre. Was war ich für ein unwissender, launischer, kleiner Junge... Aber irgendwann hatts Klick gemacht. Mir blieb auch garnichts anders übrig, mussten wir doch die Übungen des Dozenten abgeben. Und als ich mit den AVR anfing hab ich nur deswegen C benutzt weil ja schon rudimentäre Kenntnisse vorhanden waren. Allerdings hatte ich bei diesen privaten Projekten echtes Interesse an der Umsetzung, was man von den Uni-Übungen nicht behaupten konnte. Deswegen ging das Lernen dann fast wie von alleine. Mittlerweile verdiene ich seit Jahren meine Brötchen damit. Auch privat kommt C auf AVR und ARM zum Einsatz. Auf dem PC ist aber C++ oder, bei kleinen Helferlein, Python das Mittel der Wahl. Für jedes Problem das richtige Werkzeug. Erst jetzt kann ich eigentlich beurteilen wie unwissend ich damals war, und darüber lachen. C hat schon eine gewissen Lernkurve, das stimmt. Als Laie gibt es dort 100 Wege, dir selbst ins Knie zu schießen. Aber nicht ohne Grund hat es sich einfach durchgesetzt. Einer davon ist die hardware-nähe bei gleichzeitig relativ hoher Abstraktion. Der Compiler hat, wenn man ihm nicht vorsätzlich Steine in den Weg legt, immer die Möglichkeit optimalen ASM-Code zu erzeugen. Und trotzdem hat man die Bequemlichkeit von Datenstrukturen, Funktionen, muss sich nicht um Register kümmern... Aber um das Beurteilen zu können muss man mal über den Tellerrand geschaut haben...
:
Bearbeitet durch User
Moby A. schrieb: > Ich denk mal da hast Du gerade was falsch verstanden !? > Es handelt sich nicht um C-Code für mein Tiny13 Projekt worauf ich > selber warte sondern meinen ersten und einzigen (war was für PC > DOS-Kommandozeile). Dann zeig doch den mal her. Vermutlich werden wir dann verstehen, warum du C so schrecklich findest...
A. K. schrieb: > Wenn er alles abgezogen hat, was er für unnötig oder > viel zu kompliziert hält und was man davon sowieso nicht braucht, dann > passt es auch in die Hälfte rein. So optimiert man Code. Wenn es denn stimmt das es keine nützliche Funktionalität enthält ist das tatsächlich die beste Art Code zu optimieren. Übrigens vollkommen Sprachenunabhängig. Moby A. schrieb: > Selbst die 10-15% gehen mir ja schon runter wie Öl ;-) Bei 250% für Entwicklung und Wartung fallen mir aber spontan nicht so viele Anwendungen ein wo das auch im gewerblichen Maßstab noch tragfähig ist. Na ja, irgendeine Raumsonde auf dem Weg zu anderen Planeten, da kommt es schon auf jedes Bit an. Moby A. schrieb: >> Das haben wir dich schon mehrmals gebeten, aber mehr als das Ding >> mit dem Tiny13 bekommen wir ja nicht zu sehen. > Der reicht auch als Demo der Überlegenheit von Assembler. Immer das gleiche. Über Glauben läßt sich nicht diskutieren, denn wenn es Beweise gäbe bräuchte es doch keinen Glauben mehr. Deswegen diskutieren Wissenschaftler und Gläubige metzeln sich gegenseitig weg. So wie in diesem Thread.
Moby A. schrieb: > Unfug. Register hat jeder AVR die gleichen 32 an der Zahl. Im > wertvollen, zusätzlichen SRAM unterscheiden sie sich. Der zählt > selbstverständlich zu den einzusparenden Ressourcen für einen > ordentlichen Vergleich. Kannst du eigentlich einen vernünftigen Grund für das "Einsparen" dieser "wertvollen Resourcen nennen"? Aber nicht den, dass du es geil findest, unter dein Porgramm "RAM-Verbrauch 0" zu schreiben. Die Frage musst du nicht wirklich beantworten. Aber etwas interessiert mich doch: Warum verschwendest du in deinem Projekt wertvolle Resourcen damit, dass du den Stack auf den Default-Wert initialisierst und das RAM durchgehend auf 0 setzt? Das kostet dich wertvolle Rechenzeit, unnötig Strom und belegt wertvollen Flash-Speicher. Warum belegst du jeden Interruptvektor mit einem Sprungbefehl, obwohl du die hinteren gar nicht benutzt? Warum beginnt dein Programm nicht direkt nach dem letzten Vektor, der von dir benutzten Interrupts? Du verschwendest massiv wertvolle Resourcen. Flash-Speicher, den du für Erweiterungen nicht mehr nutzen kannst. Warum wird ein Register in deiner Initialisierung zweimal mit dem gleichen Wert beschrieben, anstatt die Initialisierungen so anzuordnen, dass die SFRs, die den gleichen Wert erhalten, direkt hintereinander stehen? Welch eine Verschwendung an Flash-Speicher und Rechenzeit. Nur mal die ersten Kleinigkeiten, die mir in deinem "hoch effizenten" Programm so aufgefallen sind, ohne den Rest weiter angesehen zu haben. Ich dachte, nur C-Compiler machen diese stereotypen Univeralinitialisierungen, ungeachtet dessen, ob man sie wirklich braucht, um ordentlich Resourcen zu verschwenden, damit der Programmierer danach damit angeben kann, was für lange Programme er geschrieben hat. Assembler-Programmierer dagegen haben ihren Controller voll im Griff und lassen nur das ausführen, was nötig ist. Höchstmögliche Effizienz eben und "Keep is simple". Und noch was: Warum trampelst du in deiner Hauptprgramm-Schleife nur auf der Stelle, anstatt die Interrupts zu pollen? Das geht viel schneller, als jedesmal den üblichen Overhead eines Interrupt-Request abarbeiten zu lassen. Das ist auch kürzer und spart wiederum Flash-Speicher. Und - und das ist natürlich der besondere Nutzen davon: Es wird nichts mehr auf den Stack geschrieben! Dein RAM-"Verbrauch" ist jetzt tatsächlich 0. Die wertvolle Resource wird gar nicht angetastet. Ausserdem könntest du das Programm dann bei Adresse 0 starten lassen und du würdest noch einmal Flash einsparen, anstatt diese Resource auch sinnlos zu verschwenden und die Erweiterungsmöglichkeiten einzuschränken. mfg.
Thomas E. schrieb:
Den mit großem Abstand besten und informativsten Beitrag in diesem
elendig langen endlos Thread.
Vielen Dank dafür !
Cyblord -. schrieb: > Treffer und versenkt würde ich sagen. Sehe ich auch so. Allerdings wird das wohl mit einem einzigen Begriff von Tisch gewischt werden, der heist: Erweiterbarkeit!
Gu. F. schrieb: > Erweiterbarkeit! Dann ziehen ihm diesen Zahn: Da das Verhalten des Programms durch Internet-Polling deterministisch ist, lassen sich die Register, die sonst exklusiv in einer ISR vorgehalten werden müssen, flexibel verwenden, was der Erweiterbarkeit sogar noch zu Gute kommt. mfg.
Thomas E. schrieb: [...] Einen großen Teil dieser Optimierungen hatte ich schon im Originalthread angemerkt, aber da kamen dann die üblichen Ausflüchte, wie z.B. RAM muß man initialisieren weil man das ja für Erweiterungen benötigt. Und das mehrfache Ladens der selben Konstante ins gleiche Register zeigt die "Überlegenheit" des selbsternannt "mittelmäßigen Assembler-Programmieres" beim Einsparen von Flash-Zellen und Takt-Zyklen über stupide Compiler.
Michael K. schrieb: > Bei 250% für Entwicklung und Wartung fallen mir aber spontan nicht so > viele Anwendungen ein wo das auch im gewerblichen Maßstab noch tragfähig > ist. > Na ja, irgendeine Raumsonde auf dem Weg zu anderen Planeten, da kommt es > schon auf jedes Bit an. Im Umfeld der zivilen und militärischen Raum- und Luftfahrt scheint vor allem die Hochsprache Ada besonders beliebt zu sein: http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
Thomas E. schrieb: > Warum verschwendest du in deinem Projekt wertvolle Resourcen damit, dass > du den Stack auf den Default-Wert initialisierst und das RAM durchgehend > auf 0 setzt? Das kostet dich wertvolle Rechenzeit, unnötig Strom und > belegt wertvollen Flash-Speicher. Das wurde im Projekt-Thread beantwortet. > Warum belegst du jeden Interruptvektor mit einem Sprungbefehl, obwohl du > die hinteren gar nicht benutzt? Warum beginnt dein Programm nicht direkt > nach dem letzten Vektor, der von dir benutzten Interrupts? Du > verschwendest massiv wertvolle Resourcen. Flash-Speicher, den du für > Erweiterungen nicht mehr nutzen kannst. Das wurde im Projekt-Thread beantwortet. > Nur mal die ersten Kleinigkeiten, die mir in deinem "hoch effizenten" > Programm so aufgefallen sind, ohne den Rest weiter angesehen zu haben. Vieles ist bereits auf Erweiterungen ausgerichtet. Ohne diese könnte man sicher dieses und jenes einsparen- wozu dann aber Einsparen wenn der freie Speicher ohnehin nicht mehr genutzt werden könnte? Zu einem vollständigen, erweiterungsfähigen Programm gehört genau das was Du dort codiert siehst! Du siehst, Deine schrecklich herbeikonstruierte Sichtweise bricht kurzerhand in sich zusammen. Ist ja furchtbar nett, daß Du an der Verbesserung des Asm-Codes solchen Anteil nimmst. Dabei wäre die entscheidende Aufgabe gewesen, das Programm mit C zu toppen. Glaubst Du, daß Du Dich daran jetzt auf diese Weise vorbeigemogelt hast? Und vergiss nicht, mein Asm-Programm stellt noch nicht mal den Anspruch, die Lösung in Perfektion zu sein. Ich sehe mich ja nur als durchschnittlichen Asm Programmierer ;-)
:
Bearbeitet durch User
Cyblord -. schrieb: > Treffer und versenkt würde ich sagen. Besser Du verschwindest mit Deiner Wahrnehmung in Versenkung ;-) Thomas E. schrieb: > Da das Verhalten des Programms durch Internet-Polling deterministisch > ist, lassen sich die Register, die sonst exklusiv in einer ISR > vorgehalten werden müssen, flexibel verwenden, was der Erweiterbarkeit > sogar noch zu Gute kommt. Dieses Vorgehen mag nicht sinnlos sein, meine Hintergedanken waren aber andere: -> Das Hauptprogramm freihalten als übersichtliche Erweiterungsmöglichkeit -> Alle Funktionalität im Interrupt kapseln für die Übersicht -> Bei ungenutztem Hauptprogramm könnte dort energiesparend geschlafen werden Carl D. schrieb: > Einen großen Teil dieser Optimierungen hatte ich schon im Originalthread > angemerkt, aber da kamen dann die üblichen Ausflüchte, Meine sogenannten "Ausflüchte" habe ich umfassend begründet. Und vergiss doch bitte nicht eines, siehe Zitat Moby A. schrieb: > dem beiliegenden > Quelltext (T13.asm) entnehmen, der für ASM-Fans (und solche die es > werden möchten) zur Verschlimmbesserung/Erweiterung beiliegt Das ist ja das schöne an Software ;-)
Moby A. schrieb: > Das wurde im Projekt-Thread beantwortet. Das werde ich bestimmt nicht querlesen. Moby A. schrieb: > Vieles ist bereits auf Erweiterungen ausgerichtet. Dummes Geschwafel. Allein deine Vektortabelle ist eines Assembler-Programmierers absolut unwürdig. Du setzt auf jeden nicht benutzten Vektor einen jump auf eine ISR, in der dann ein reti steht. Das reti gehört aber direkt auf den Vektor. Du argumentierst, ... Überlies das. Du schwafelst hier von der Effizienz deines Assembler-Programms gegenüber C-Programmen. Dabei machst du genau die Sachen, die einen kleinen C-Code unnötig aufblähen. Nämlich das Durchnullen des gesamten RAM, obwohl es nicht nötig ist und das Anlegen einer kompletten Vektortabelle mit jump auf eine Bad Interrupt-ISR. DAS, ich wiederhole, DAS ist ziemlich genau DAS, was ein Progrämmchen, wie das in deinem "Projekt" um die ominösen 10-20% größer macht. Den eigentlichen Funktionscode bekommt ein richtiger Assembler-Programmierer evtl. effektiver hin. Wobei effektiver nicht unbedingt kürzer ist. Moby A. schrieb: > wozu dann aber Einsparen wenn der > freie Speicher ohnehin nicht mehr genutzt werden könnte? Warum soll man den nicht nutzen können? Du kannst den nicht nutzen, weil du nicht programmieren kannst und überhaupt nicht in der Lage bist, die Möglichkeiten eines Makro-Assemblers auszunutzen. Moby A. schrieb: > Ist ja furchtbar nett, daß Du an der Verbesserung des Asm-Codes solchen > Anteil nimmst. Im nehme da keinen Anteil dran. Ich zeige nur auf, dass du unfähig bist, das, von dem du hier ständig schwafelst, auch umzusetzen. Moby A. schrieb: > Dabei wäre die entscheidende Aufgabe gewesen, das > Programm mit C zu toppen. Glaubst Du, daß Du Dich daran jetzt auf diese > Weise vorbeigemogelt hast? Wessen Aufgabe? Meine? Wo ist das C-Programm? Ich werde einen Teufel tun und dein Assembler-Zeugs auseinander friemeln. Moby A. schrieb: > Und vergiss nicht, mein Asm-Programm stellt > noch nicht mal den Anspruch, die Lösung in Perfektion zu sein. Ich sehe > mich ja nur als durchschnittlichen Asm Programmierer Du bist bei weitem nicht einmal das. Bei dir wäre eigentlich in der gesamten Assembler-Zunft kollektives Fremdschämen angesagt. Allerdings müsste man dich dafür ernst nehmen. Um dir noch mal ein von dir hoch geschätztes Beispiel aus dem richtigen Leben zu geben: Du schwafelst davon, dass ein Fußgänger 100m schneller bewältigen kann als ein Radfahrer. Dabei schwadronierst hier rum als wärest du Usain Bolt, bist aber tatsächlich nicht einmal in der Lage, eine alte Oma mit ihrem Rollator zu überholen. mfg.
:
Bearbeitet durch User
Thomas E. schrieb: > Das werde ich bestimmt nicht querlesen. Und ich werde die rhetorische Frage bestimmt nicht zum 10001. Mal beantworten. > Dummes Geschwafel. Deines würde ich so bezeichnen. > Du setzt auf jeden nicht benutzten Vektor einen jump auf eine ISR, in > der dann ein reti steht. Das reti gehört aber direkt auf den Vektor. Könnte man. Für erweiterte Interrupts wird aber wieder der Jump fällig. Und mehr Speicher kostet es auch nicht. > Du schwafelst hier von der Effizienz deines Assembler-Programms > gegenüber C-Programmen. > Im nehme da keinen Anteil dran. Ich zeige nur auf, dass du unfähig bist, > das, von dem du hier ständig schwafelst, auch umzusetzen. Du gibtst hier den großen Experten, bist aber selber unfähig, ein besseres C-Programm zu erstellen oder auch nur anzudeuten, wieso es ressourcen- sparender als die von mir umgesetzte Asm-Lösung sein könnte. > Warum soll man den nicht nutzen können? 'Können' war hier falsch, konnte es nicht mehr korrigieren. 'Würde" sollte es heißen. Man würde den zusätzlichen Speicher nicht nutzen, wenn der Code in Deinem Sinne schon auf Minimum zurechtgestutzt wäre. Ich denke aber an solche Leute die auf dem Code unmittelbar aufbauen wollen. Das werde ich aber jetzt vermutlich nicht in Deinen Kopf bekommen ;-( Alles unwichtige Mätzchen was Du hier glaubst verbessern zu müssen. > Um dir noch mal ein von dir hoch geschätztes Beispiel aus dem richtigen > Leben zu geben: Spare Dir solche Vergleiche. Die sind in den seltensten Fällen gelungen. Und noch eine Bitte: Sofern es noch Verbesserungsvorschläge für meinen Code gibt mache die in meinem Projekt-Thread. Aber keine Augenwischerei mit Verschönerungen der Optik sondern möglichst etwas Substanzielles.
:
Bearbeitet durch User
Also so recht viel konstruktiver Gegenwind für Asm kommt ja nun nicht mehr. Vielleicht sollte ich die Rolle von Assembler mal etwas bildlich verdeutlichen: Wenn auf der Bühne der Controller in Aktion ist sitzen die Assembler-Programmierer am dichtesten dran. Sie sehen jedes noch so kleine Detail im 8-Bit Controller plastisch vor sich. Sie kennen die Bedürfnisse ihrer geplanten App. Nun fällt es leicht, beides optimal miteinander zu kombinieren! Die C-Programmierer sitzen weiter weg. Zwischen ihnen und der Bühne befindet sich der fette Compiler. Der behindert den Blick. Ein paar konstruktiv bedingte Gucklöcher gibts zwar- aber der Programmierer muß sich letztlich über die Compiler-Bauer sein Tun mit dem Controller mehr oder minder effektiv vermitteln lassen. Die Hochsprache dazu muß man kennen. Vor-und Nachteile der einzelnen Hochsprach-Konstruktionen muß man kennen. Die vielen Stellschrauben des Compilers, den Code vielleicht doch noch etwas besser zu optimieren muß man kennen. Und dann beim Niederschreiben bloß keine Syntaxfehler! Bei den komplexen Ausdrücken ja kein Zeichen vergessen! Bürokratie wohin das Auge blickt. Im Interesse schneller, zweitbester Lösungen kann man sich nun in dieses Abhängigkeitsdickicht begeben. Oder, man liebt den klaren Blick auf die Controller-Realitäten, nutzt ihn und erstellt die beste Lösung!
P. M. schrieb im Beitrag #4364606:
> Moby...deine Beiträge bekommen durchs Band 3-5 Downvotes.
Na ja, ausgenommen der Eröffnungspost.
Moby A. schrieb: > Du gibtst hier den großen Experten Ach, Moby. Auch wenn es schon ein paar Jahre her ist, aber ich habe jahrelang Bildverarbeitungsroutinen auf DSP implementiert. Das ist die Königsklasse der Programmierung. In Assembler. Aber irgendwann wird man vom Fortschritt überholt, der da heisst: Schnellere Prozessoren und, noch viel wichtiger, mehr RAM. Dann bringt es einfach irgendwann nichts mehr, es nicht in C(++) zu machen. Denn auch die Compiler werden besser. Und wenn ein Compiler mit seinen Libs erstmal auf eine bestimmte Hardware zugeschnitten ist, kannst du als Assembler-Friggler einpacken. Das ist jetzt durchaus eine Experten-Einsicht. [Polemik entfernt - Mod.]
:
Bearbeitet durch Moderator
Moby A. schrieb: > Du gibtst hier den großen Experten, Vielleicht ist er es? Einige Leute hier haben selbst viel Erfahrung in Assembler. Aber eben nicht nur in Assembler. Programmiersprachen sind Werkzeuge und auch im Werkzeugkasten ist es von Nutzen, wenn er nicht nur Hämmer enthält. Man sucht sich das zum Problem passende Werkzeug. Das kann auch Assembler sein - aber heute eher in kleinen Häppchen wo es sich wirklich lohnt, nicht im ganzen Programm. Ein Problem, dass du bei Compilern siehst, ist Intransparenz. Du siehst nicht, was geschieht. Aber ausgerechnet C ist eine der transparentesten Sprachen, was die Abbildung von Quellcode auf den Maschinencode angeht. Mit etwas Erfahrung kriegt man eine Nase dafür, wie aufwändig der entstehende Code ist. Diese Eigenschaft hatte C früher den Ruf eingebracht, ein besserer Assembler zu sein. Allein - Transparenz ist kein Wert an sich. Ich hatte oben scherzhalber APL aufgeführt, weil das so ziemlich das Gegenteil davon ist. Abgesehen vom Autor des Interpreters hat da niemand eine Ahnung, wie das das intern wirklich abläuft und wie es optimiert wird. Der Abstand zwischen Quellcode und dem Ablauf auf Maschinenebene ist immens. Das führt auch zu einer anderen Denkweise beim Programmieren. Man hat nicht so sehr den sequentiellen Ablauf und den Fluss einzelner Worte eines Programmes vor Augen, sondern denkt in komplexen Datenwolken. Deshalb gehört es eigentlich zum guten Ton, angehende Informatiker mit verschiedenen Prinzipien der Programmiersprachen zu konfrontieren. Also keine Scheinvielfalt prinzipiell ähnlicher Sprachen wie C/Pascal/FORTRAN kennen zu lernen, sondern (früher) auch mal an Prolog zu schnuppern. Allein schon um zu sehen, dass man sich Programmierung auch anders ausdenken kann als ablaufgesteuert und skalar.
Ist zwar Mobys Thread, wenn aber Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: nach nicht mal zwanzig Minuten Karl H. schrieb: > Wenn letztes Jahr von 100 Programmierern gerade 1 in Assembler > programmiert hat und heuer sind es 2, dann ist das auch ein Zuwachs von > 100%. Ist immer noch unter ferner liefen und völlig uninteressant. alles gesagt ist und jetzt sowieso alles gelöscht wird, kann man da nicht einfach dicht machen? Wir warten einfach eine Woche, dann gibt's eine neue Statistik und ein neues Thema: "Assembler wieder auf dem Weg nach hinten".
Moby A. schrieb: > Ohne diese könnte man > sicher dieses und jenes einsparen- wozu dann aber Einsparen wenn der > freie Speicher ohnehin nicht mehr genutzt werden könnte? Daß Du diese Erkenntnis noch bekommst, hätte ich nicht mehr zu hoffen gewagt! Gruß, Stefan
Moby A. schrieb: > Ich denke aber an solche Leute die auf dem Code unmittelbar aufbauen > wollen. Gibts denn welche..?
Stefan K. schrieb: > Moby A. schrieb: >> Ohne diese könnte man >> sicher dieses und jenes einsparen- wozu dann aber Einsparen wenn der >> freie Speicher ohnehin nicht mehr genutzt werden könnte? > > Daß Du diese Erkenntnis noch bekommst, hätte ich nicht mehr zu hoffen > gewagt! > > Gruß, Stefan Ich auch nicht. Was soll dann dieses bescheuerte Argument, dass C 10% mehr Speicher braucht?
Moby A. schrieb: > Also so recht viel konstruktiver Gegenwind für Asm kommt ja nun nicht > mehr. Und genau das liebe ich so an Deinen Beiträgen. Ich gebe zu das mich das früher manchmal aufgeregt hat wie jemand ganz einfach alles wegblendet was ihm nicht gefällt, so tut als hätte nichts davon stattgefunden und einfach wieder an einem Punkt weitermacht den man vor 300 Seiten Diskussion überwunden geglaubt hatte. Mittlerweile finde ich das sehr erfrischend. Es führt mir vor Augen wie vollkommen hoffnungslos der Versuch ist jemanden zu überzeugen der sich einfach fest vorgenommen hat keinen Millimeter von seiner Überzeugung abzuweichen. Wer es geschafft hat einen Deiner ASM Threads durchzuhalten ohne medizinischen Beistand zu benötigen dem kann in keinem Internetforum mehr was schlimmes passieren. Ein wenig bist Du wie ein Boxer, der manches blockt und manchem tänzelnd ausweicht. Treffer werden mit einem Grinsen quittiert, weil es ja garnicht wehgetan hat. Da kann der andere 100 Mal besser sein, Du hast einfach die Ausdauer für 1000 Runden. Da kannst zwar nicht siegen, bist aber unbesiegbar weil Du einfach nicht am Boden bleibst egal wie hart Du getroffen wirst. Diversen Leuten wird jetzt wieder der Kamm schwellen wie man das so sehen kann, aber genau das macht ja den Unterhaltungswert dieses Threads aus. Es wäre tatsächlich ein spannendes Experiment wenn jemand mit unterdurchschnittlichen C Kenntnissen und einem gut optimierenden Compiler Deinen Code toppen würde. Es würde mit Sicherheit alles mögliche passieren, aber niemals nie nicht würdest Du Deine Überzeugung ändern. Das alles ist in etwa so sinnvoll wie 1000 Argumente für gutes Wetter in den Sturm zu brüllen.
Sheeva P. schrieb: > Moby A. schrieb: >> Ich denke aber an solche Leute die auf dem Code unmittelbar aufbauen >> wollen. > > Gibts denn welche..? Nein, es gibt keine. Er ist auf seinen ach so tollen Sensorboards, die er hier angeboten hat, sitzengeblieben. Kein Mensch wollte eins haben. Kein Mensch wollte seine unleserliche und unverständliche Software benutzen - geschweige denn erweitern.
Moby erinnert mich immer an den schwarzen Ritter aus "Ritter der Kokosnuß".
Stefan K. schrieb: > Daß Du diese Erkenntnis noch bekommst, hätte ich nicht mehr zu hoffen > gewagt! Wenn Du und Sven B. sie denn verstanden hättet ;-) Sheeva P. schrieb: > Gibts denn welche..? Bestimmt. Gemeint war aber nicht Dein großartiges C-Werk ;-) Frank M. schrieb: > Kein Mensch wollte seine unleserliche und unverständliche Software > benutzen - geschweige denn erweitern. Du darfst halt nicht immer nur von Dir auf andere schließen ;-)
Michael K. schrieb: > Du hast > einfach die Ausdauer für 1000 Runden. Nein Michael. Ich habe Recht: Asm hat seine Vorteile bei hardwarenahem 8-Bit MSR. > Da kannst zwar nicht siegen Das kann bei der Übermacht von C hier gar kein Ziel sein. Meine Ziele sind längst erreicht- als erfolgreiche Asm-Projekte allemal. > Es wäre tatsächlich ein spannendes Experiment wenn jemand mit > unterdurchschnittlichen C Kenntnissen und einem gut optimierenden > Compiler Deinen Code toppen würde. Das ist nicht passiert und wird nicht passieren, siehe erste Antwort. > Es würde mit Sicherheit alles mögliche passieren, aber niemals nie nicht > würdest Du Deine Überzeugung ändern. Irrtum. Hatte ich aber auch schon öfter gesagt. > Das alles ist in etwa so sinnvoll wie 1000 Argumente für gutes Wetter in > den Sturm zu brüllen. Genau. C-Argumente gegen den Sturm von superfluid-anpassungfähigem Simply Asm. In dem sind die Seeleute des schwerfälligen C-Frachters mit den dicken Büchern hier hoffnungslos untergegangen, sofern sie sich nicht schnell noch auf die Inseln von Satire, Sarkasmus und persönlicher Beleidigung retten konnten ;-)
Michael K. schrieb: > aber niemals nie nicht würdest Du Deine Überzeugung ändern. Hatten wir doch schon. Es werden dann einfach nachträglich die Anforderungen geändert, bis sein Weltbild wieder passt.
Moby A. schrieb: > superfluid-anpassungfähigem Simply Asm "superfluid" ist in etwa "überflüssig"? Und da behaupten hier Leute, du wärst nicht lernfähig...
A. K. schrieb: > Man sucht sich das zum Problem passende Werkzeug. > Das kann auch Assembler sein Für 8-Bit Controller MSR. Genau. So schauts aus. Deine restlichen Ausführungen klingen ja durchaus plausibel, allein meine Wahrnehmung, daß zu vieles mit zunächst mühsam zu erlernenden Werkzeugen zu kompliziert gelöst wird, werde ich damit auch nicht los. > sondern denkt in komplexen Datenwolken Na meinetwegen. Wo aber keine komplexen Datenwolken sind benötigt es auch kein passendes Werkzeug. > Allein schon um zu sehen, dass man sich Programmierung auch anders > ausdenken kann als ablaufgesteuert und skalar. Ich behaupte, das ist und bleibt der intuitivere Zugang. Andere behaupten, es gäbe bessere. Das nehme ich gerne zur Ķenntnis. Verlieren wir doch aber bitte nicht stets das (meinige) Ziel aus den Augen: - Acht Bit Controller Messen Steuern und Regeln! - Millionen Anwendungsfälle. Millionen Einsatzfälle für Asm.
:
Bearbeitet durch User
Jörg W. schrieb: > Es werden dann einfach nachträglich die > Anforderungen geändert, bis sein Weltbild wieder passt Falsch. Ich ändere nichts nachträglich, sondern setze das Wissen, was MC-Ressourcen sind und eine Vorstellung von echtem Vergleich diesbezüglich einfach voraus. Mit echtem Code gehts auch nicht um Weltbilder. Faktenbasierteres als die Fakten zu Codesize, RAM-Verbrauch (und ggf Speed) gibts einfach nicht.
:
Bearbeitet durch User
Moby A. schrieb: > Falsch. Ach, Moby. Du merkst es nicht einmal. Wenn du an einem fairen Vergleich interessiert wärst, würdest du dich mal für irgendein Projekt hinsetzen, verbal alle Anforderungen auf einen Zettel schreiben (die dann auch nicht nachträglich ergänzt werden dürfen, auch nicht mit Begründungen wie „das macht man doch aber immer so!“ und dergleichen), und danach das Projekt genau danach umsetzen und dir parallel von anderen eine Umsetzung des Projekts mit den Mitteln ihrer Wahl machen lassen. Mögliches Erweiterungspotenzial gehört dabei natürlich genauso in die Liste der Anforderungen hinein und darf nicht einfach hinterher postuliert werden. Das ist dir mehrmals angeboten worden, darauf würden sich hier einige Leute durchaus einlassen. Machst du aber nicht, sondern du beharrst darauf, dass der Vergleich ausschließlich an diesem einen vorliegenden Muster zu erfolgen hat, und die Anforderungen werden immer so weiter „verfeinert“, dass die Schnittmenge aus allen Anforderungen am Ende nur durch genau dieses eine Exemplar von Realisierung erfüllt werden kann. Darauf hat einfach keiner mehr Bock. Wir alle wissen, was wir können (und bei vielen hier gehören diverse Dialekte von Assembler mit dazu, nicht nur der eine, den du gerade zufällig beherrschst), und wir lassen dir deinen Glauben, du wärest der größte Programmierer aller Zeiten, naja, oder wenigstens der zweitgrößte. ;-)
Angehängte Dateien:
-
blog_horizontnull.jpg
49 KB
Moby A. schrieb: > allein meine Wahrnehmung Das wirds wohl sein. Ich wollte noch mehr schreiben, habe es aber wegen akuter Wiederholungsgefahr gelöscht... EDIT, eins noch: mein neues Stimmgerät für den Bass basiert auf einem 32-Bit ARM. Und das Ding ist echt mal brauchbar. Garantiert haben die das nicht mit Assembler geschrieben: http://www.tcelectronic.com/de/polytune-clip/ Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde ich niemals mehr mit 8-Bit uC und Assembler anfangen.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Verlieren wir doch aber bitte nicht stets das (meinige) Ziel aus den > Augen: > - Acht Bit Controller Messen Steuern und Regeln! - > Millionen Anwendungsfälle. Millionen Einsatzfälle für Asm. Hör jetzt endlich mal auf mit dem Blödsinn. In diesem Punkt haben wir dir schon lange zugestimmt: Ja, auf kleinsten Controllern kann Assembler ein vernünftiges Werkzeug sein. Dann verallgemeinerst du aber wieder auf grössere Projekte und Prozessoren. Das ist natürlich falsch und wenn dann ein paar Argumente gegen deine Position kommen, dann krebst du wieder auf 8-Bit-MSR zurück. Dieses hin und zurück geht nun über 300+ Beiträge...
Ralf G. schrieb: > Karl H. schrieb: >> Wenn letztes Jahr von 100 Programmierern gerade 1 in Assembler >> programmiert hat und heuer sind es 2, dann ist das auch ein Zuwachs von >> 100%. Ist immer noch unter ferner liefen und völlig uninteressant. > > alles gesagt ist und jetzt sowieso alles gelöscht wird, kann man da > nicht einfach dicht machen? Wir warten einfach eine Woche, dann gibt's > eine neue Statistik und ein neues Thema: "Assembler wieder auf dem Weg > nach hinten". Wieso? Ist einer der beiden verstorben? Mein Beileid.
Karl H. schrieb: > Wieso? Ist einer der beiden verstorben? Moby ja zum Glück nicht, also war's der andere. :)
@ Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >dir deinen Glauben, du wärest der größte Programmierer aller Zeiten, >naja, oder wenigstens der zweitgrößte. ;-) Der GröPaZ! ER ist wieder da! :-=(
Lothar M. schrieb: > Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde > ich niemals mehr mit 8-Bit uC und Assembler anfangen. Wobei das natürlich projektmäßig eher kein Kleingerät ist, denn da wird garantiert eine FFT drin laufen, um aus dem ankommenden Krach die dominierende Frequenz zu ermitteln. Kann man auch auf'm AVR machen, macht aber auf einem größeren Prozessor mehr Spaß. Für einen ATtiny10, benutzt als jumper-einstellbare Taktquelle, schreib' ich die paar Zeilen auch im Assembler runter. Das ist aber als Programmieraufgabe ein Mickeymouseprojekt. Früher hätte man dafür einen 555 genommen und über Jumper Widerstände ausgewählt, heute braucht man halt nur noch zwei Bauteile für sowas (den Controller und den obligatorischen 100-nF-Kerko).
Frank M. schrieb: > Sheeva P. schrieb: >> Moby A. schrieb: >>> Ich denke aber an solche Leute die auf dem Code unmittelbar aufbauen >>> wollen. >> >> Gibts denn welche..? > > Nein, es gibt keine. Er ist auf seinen ach so tollen Sensorboards, die > er hier angeboten hat, sitzengeblieben. Kein Mensch wollte eins haben. > Kein Mensch wollte seine unleserliche und unverständliche Software > benutzen - geschweige denn erweitern. Erweitern? Was willst du da erweitern? Der Code ist so dermassen auf 2 ADC Eingänge und 2 Digitale Eingänge hingeschustert, das Protokoll ist so dermassen auf genau diese Konstellation hingearbeitet, dass man da nichts erweitern kann. Hat man nicht genau diese Anforderungen, dann bleibt nichts anderes übrig, als den Code komplett neu zu machen. Soviel zum Thema, dass Mobby auch ein Erweiterungen bzw. Weiterverwengung denkt. Eines muss man ihm lassen: In seiner Routine zieht er alle Register. Er weiss genau, dass in C alles was nicht in Bytes, Words oder DWords abgehandelt wird eher unhandlich ist. Eine 24 Bit Arithmetik ist in C nun mal ein Krampf, das geht in Assembler besser. Was er aber nicht wahr haben will, und das hat er ja schon oft genug unter Beweis gestellt, das ist das seine Sicht der Dinge für die Mehrzahl der Leute ziemlich uninteressant ist. Von so einem Sensorboard will man Routinen, bei denen man einfach konfigurieren kann wieviele analogen und wieviele digitalen Eingänge man haben will und welche Pins das jeweils sein sollen. Genauso wie man den Protokollaufbau einfach spezifizieren können möchte. So etwas wäre für einen Weiterverwender brauchbar. Nur: genau das spielt sein Code nicht. Der ist noch nicht mal bei der einfachsten Änderung der Anforderungen irgendwie einfach modifizierbar. Und damit für alle anderen ausser ihn völlig uninteressant. Was ihn allerdings nicht daran hindert, dieses Faktum zu ignorieren und darauf hinzuweisem, dass man genau diese Konstallation in C nicht kleiner hinkriegt. Womit er sogar recht hat. Nur wie gesagt interessiert das eigentlich nicht, denn im Zweifel hab ich lieber eine Codebasis, die ich auf meine Bedürfnisse anpassen kann als eine die ich komplett neu schreiben muss, wenn ich nicht genau die vom Autor vorgegebenen Anforderungen habe. Selbst wenn dann der Code ein paar Bytes länger ist und ein paar Taktzyklen mehr braucht.
:
Bearbeitet durch User
Moby A. schrieb: > Irrtum. Hatte ich aber auch schon öfter gesagt. Ja, das hast Du, nur sagst Du mal dieses und dann wieder jenes. Was gerade das Kriterium ist und was aus der Wertung fällt ändert sich nach Wind und Wellenschlag. Verbindliche Kriterien gibt es nicht, vielmehr werden die jederzeit so angepasst das Du in deiner Wahrnehmung im Recht bleibst. Das darfst aber immer nur Du, denn Dein Standpunkt ist immer die absolute Wahrheit, auch wenn er sich wie ein Gummiband in alle Richtungen dehnt. Ich glaube Dir das Du das ganz anders siehst, aber den Rest des Forums treibt das zur Weißglut. Moby A. schrieb: > Asm hat seine Vorteile bei hardwarenahem > 8-Bit MSR. Ja, und C hat die auch und beide haben auch Nachteile. Moby A. schrieb: > Faktenbasierteres als die Fakten zu Codesize, RAM-Verbrauch > (und ggf Speed) gibts einfach nicht. Stimmt, nur das Du Fakten scheust wie der Teufel das Weihwasser. Du behauptest was immer Du willst und nennst das dann Fakten. Es sind aber nur Behauptungen eines Menschen der nur eine Seite kennt. Du behauptest aber man müsse nur eine Seite kennen um alle Seiten bewerten zu können. Du wirfts C Verschwendung vor und verschwendest selber viel mehr. Bei Dir sind es aber Erweiterungsmöglichkeiten. Du singst ein Loblied auf die Lösung die auf den Punkt hin entwickelt wird, stopfst Deinen Code aber mit unsinnigem voll wegen Erweiterbarkeit. Angesprochen darauf das komplett neuer ASM Code fällig wird bei zusätzlichen Sensoren zählt plötzlich die Erweiterbarkeit nichts mehr weil das müsse man sich vorher überlegen. Das ist ein absolut irrer Amoklauf durch alles was unreife Kommunikation ausmacht. Dementsprechend wirst Du behandelt. Ich will Dich nicht ändern und das könnte ich auch nicht. Ich finde es auch sehr unterhaltsam mitanzusehen wie aus einer technischen Diskussion ein Schlagabtausch wird, dann blanker Hass, dann völlige Resignation. Jeder der hier schreibt verändert sich dabei, nur Du bleibst seit 100 Threads genau so wie Du bist. Das ist irgendwie schade das da gar keine Entwicklung mehr stattfindet.
Jörg W. schrieb: > Lothar M. schrieb: >> Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde >> ich niemals mehr mit 8-Bit uC und Assembler anfangen. > Wobei das natürlich projektmäßig eher kein Kleingerät ist Nein, sicher nicht. Aber es zeigt eben, dass wir heute in 2015 leben. Und dass man das Projekt dort nicht mit maximalem Aufwand in die Programmierung in den kleinsten am Markt verfügbaren uC reinprügelt. Sondern "einfach" einen nimmt, der ausreichend leistungsfähig ist, und dann auf eine Softwareplattform setzt, die portierbar und tendenziell abstrakt ist. Das ist "Messen, Steuern und Regeln heute"... Moby A. schrieb: > Faktenbasierteres als die Fakten zu Codesize, RAM-Verbrauch (und ggf > Speed) gibts einfach nicht. Doch: Marktzahlen und Produkteinführungstermine. Was nützt das schönste und optimierteste Gerät, wenn es 2 Jahre zu spät am Markt ist?
Moby A. schrieb: > Ich behaupte, das ist und bleibt der intuitivere Zugang. > Andere behaupten, es gäbe bessere. Das nehme ich gerne zur Ķenntnis. > Verlieren wir doch aber bitte nicht stets das (meinige) Ziel aus den > Augen: > - Acht Bit Controller Messen Steuern und Regeln! - > Millionen Anwendungsfälle. Millionen Einsatzfälle für Asm. Eher ein paar die arithmetisch einfach genug sind, dass man sie in Asm problemlos abhandeln kann. Aber wir können gerne einen Vergleich machen. Wir beide programmieren einen PID Regler. Das ist im Bereich 'Regeln' ein absoluter Standardfall. Wir könnten zb ein umgekehrtes Pendel balanzieren. Ach ja - das geht nicht. Ich vergass. Der AVR hat ja keinen PID Opcode und mit 8 Bit Arithmetik kommt man da auch nicht durch. Und ausserdem hast du mit deiner Zeit bessere zu tun, als dir die Nachmittage um die Ohren zu schlagen, dafür eine saubere Lösung zu bringen. Da hab ich es dann um einiges besser, denn ich brauch dafür höchstens ein paar Stunden (und das ist aus dem Bauch heraus schon recht hoch gegriffen). Mir ist nämlich genau wie dir meine Freizeit etwas wert. Und genau deshalb mach ich das in C.
:
Bearbeitet durch User
Moby A. schrieb: > Deine restlichen Ausführungen klingen ja durchaus plausibel, allein > meine Wahrnehmung, daß zu vieles mit zunächst mühsam zu erlernenden > Werkzeugen zu kompliziert gelöst wird, werde ich damit auch nicht los. Das wäre immer noch nicht das Problem, so lange man sich darüber bewusst ist, dass das Ausmass dieser "Mühsal" individuell recht unterschiedlich ausgeprägt ist. Ein jeder hat in seinem individuellen Abstand sein Brett vor dem Kopf. Aber erst durch den missionarischen Eifer, dies zum Ende der Welt zu definieren, wird es zum Problem.
:
Bearbeitet durch User
Karl H. schrieb: > Der Code ist so dermassen auf 2 ADC Eingänge und 2 Digitale Eingänge > hingeschustert, das Protokoll ist so dermassen auf genau diese > Konstellation hingearbeitet, dass man da nichts erweitern kann. Ganz davon abgesehen, dass (wenn man /RESET noch in seiner Funktion belassen will) sowieso bloß noch maximal ein Pin an dem Teil frei wäre. Ein 8-Pinner hat eben nur fünf frei benutzbare Pins. Dahingehend ist die Anforderung „darf keinen wertvollen RAM brauchen, damit noch Platz für Erweiterungen ist“ ja völlig absurd, zumal Register in einem Prozessor wohl immer teurer sind als RAM (Ausnahme: Z8, bei dem gab es keinen Unterschied zwischen RAM und Registern).
Moby A. schrieb: > Na meinetwegen. Wo aber keine komplexen Datenwolken sind benötigt es > auch kein passendes Werkzeug. Klar. Man kann auch mit einem Satz Feilen aus Stahl das benötigte Werkstück herausholen. Aber mit Drehbank, Fräse und Ständerbohrmaschine gehts dann eben doch in den meisten Fällen einfacher. Und auch klar: man muss lernen damit umzugehen. Selbst wenn man dann in einigen Fällen doch noch an einzelnen Stellen mit der Feile drüber geht um Grate zu entfernen. Du argumentierst hier wie jemand, der sich mit Feile und Gewindeschneider seine 3 benötigten Schrauben selbst hergestellt hat. Das ist super für dich und du kannst auch die benötigte und ausreichende M4.857 Schraube damit herstellen (wenn du das Gewinde selbst feilst). Aber die Verallgemeinerung, damit den Aufbau einer kompletten Halle mit händisch selbstgefertigen Schrauben zu bewerkstelligen, die zieht eben nicht.
:
Bearbeitet durch User
Karl H. schrieb: > Eines muss man ihm lassen: In seiner Routine zieht er alle Register. Er > weiss genau, dass in C alles was nicht in Bytes, Words oder DWords > abgehandelt wird eher unhandlich ist. Au weia, damit hast du wieder Stoff für weitere 100 Sinnlosbeiträge geliefert.
Jörg W. schrieb: > Register in einem Prozessor wohl immer teurer sind als RAM (Ausnahme: > Z8, bei dem gab es keinen Unterschied zwischen RAM und Registern). Die Zugriffspfade (Ports) machen den Hauptunterschied im Aufwand aus. Auf RAM kann immer nur einer zugreifen, auf Register meist mehrere. Ein AVR kann pro Takt 2 Register lesen und eines schreiben. Aber pro Takt kann er nur ein RAM-Byte entweder lesen oder schreiben. Das ist beim Z8 nicht anders (oder früher beim TIs TMS9900), was Folgen für die Laufzeit der Befehle hat.
Gu. F. schrieb: > Karl H. schrieb: >> Eines muss man ihm lassen: In seiner Routine zieht er alle Register. Er >> weiss genau, dass in C alles was nicht in Bytes, Words oder DWords >> abgehandelt wird eher unhandlich ist. > > Au weia, damit hast du wieder Stoff für weitere 100 Sinnlosbeiträge > geliefert. Ist mir klar. Auf der anderen Seite sehe ich die Sache tatsächlich so.
Aber darum geht es doch in diesem Thread überhaupt nicht!
Karl H. schrieb: > Gu. F. schrieb: >> Karl H. schrieb: >>> Eines muss man ihm lassen: In seiner Routine zieht er alle Register. Er >>> weiss genau, dass in C alles was nicht in Bytes, Words oder DWords >>> abgehandelt wird eher unhandlich ist. >> >> Au weia, damit hast du wieder Stoff für weitere 100 Sinnlosbeiträge >> geliefert. > > Ist mir klar. > Auf der anderen Seite sehe ich die Sache tatsächlich so. Der springende Punkt ist doch, dass man für ganz spezifische Einzelfälle immer genau darauf zugeschnittene Produkte händisch fertigen kann. Ich kann, wenn ich gut bin, nicht nur M3 M4 M5 etc. Schrauben machen, sondern auch alle gewünschten Zwischenmasse. Kann ich tun. Nur darf ich mich nicht wundern, dass niemand die aufwändig hergestellte M3.8729 Schrauben im Baumarkt kauft und die im Regal verrotten. Jahrhundertelang hat sich jeder Werkzeugbauer seine Schrauben mit genau den Massen die er gebraucht hat selbst gefertigt, bis es dann den englischen Eisenbahnbauern zu bunt geworden ist und sie standardisierte Schrauben eingführt haben. Der Vorteil war, dass Lokomotiven plötzlich in allen Werkstätten reparierbar wurden, selbst wenn manche Schrauben ein wenig überdimensioniert waren. Die industrielle Revolution hatte begonnen.
Klaus W. schrieb: > Aber darum geht es doch in diesem Thread überhaupt nicht! Ich gebe zu, ein paar Seiten übersprungen zu haben - war im Ausland.
Moby A. schrieb: > Wenn auf der Bühne der Controller in Aktion ist sitzen die > Assembler-Programmierer am dichtesten dran. Sie sehen jedes noch > so kleine Detail Moby sitzt gerne so nah dran, dass er die Haare an den Beinen der Tänzerinnen sieht, aber von der Choreographie nix mitbekommt :-)
Johann L. schrieb: > Moby A. schrieb: >> Wenn auf der Bühne der Controller in Aktion ist sitzen die >> Assembler-Programmierer am dichtesten dran. Sie sehen jedes noch >> so kleine Detail > > Moby sitzt gerne so nah dran, dass er die Haare an den Beinen der > Tänzerinnen sieht, aber von der Choreographie nix mitbekommt :-) Ich wollte mir auch schon zu diesem Thema etwas ausdenken, aber deines ist schöner. Meines wäre in die Richtung gegangen, dass sich der Regisseur nicht um jeden Kleinscheiss selbst kümmert sondern dafür seine Leute hat. Der Regisseur hat den Überblick und sagt seinem Bühnenbildner nur, wo er einen Baum hin haben will. Aber er geht nicht selbst in den Fundus. Er beurteilt das Bühnenbild in seiner Gesamtwirkung aber welche Firma die Lacke liefert ist ihm egal. Er beurteilt die Kostüme aber er schneidert sie nicht selbst. Er sagt dem Lichttechiker, wo er einen Spot hinhaben will, aber kletter nicht selbst zur Montage hoch. Genau das ist das was ihm noch fehlt: Das loslassen können von der Detailkontrolle. Kann ich beim Bau einer Hundehütte mich noch um jede Kleinigkeit selbst kümmern, so geht das für einen Architekten bei einem Wohnblock nicht mehr.
:
Bearbeitet durch User
... und der Lichttechiker schnautzt den Regiseur an dass das Stück ein Reinfall wird, weil er dieser keine Scheinwerfer bauen will.
Jörg W. schrieb: > Machst du aber nicht, sondern du beharrst > darauf, dass der Vergleich ausschließlich an diesem einen vorliegenden > Muster zu erfolgen hat, welcher ganz allein einen Sinn ergibt. > Das ist dir mehrmals angeboten worden, darauf würden sich hier einige > Leute durchaus einlassen. Ich glaube nicht mehr an den Weihnachtsmann ;-) Ich nehme aber zur Kenntnis, daß das Mantra "Anforderungsliste" für die wiederholte Auflistung von längst Bekanntem und einfachster Funktionalität jener Nothaltegriff ist, der als Ausrede für unsere C-Freunde unabdingbar ist um nicht in der Flut guter Argumente und Fakten pro ASM den Halt zu verlieren ;-) Jörg W. schrieb: > wir lassen > dir deinen Glauben, du wärest der größte Programmierer aller Zeiten Schau Jörg, die lieben Unterstellungen wieder! Ich hatte zwar mehrfach von "durchschnittlichem Asm Programmierer" gesprochen aber als so behauptetem Glauben schauts eben viel besser aus, oder? Nein, dahinter steckt aber was anderes: Meine Beharrlichkeit, Asm-Code im Ressourcenverbrauch bei 8-Bit MSR vor C zu sehen zeugt weniger von Glauben denn von der Wahrheit ;-)
Moby A. schrieb: > Schau Jörg, die lieben Unterstellungen wieder! Du hast den Smiley weggelassen. Der war absichtlich da.
Hier!! ... Schon wieder! ... Sowas meinte ich mit meiner Belobigung, die vorgestern gelöscht wurde: Moby A. schrieb: > Ich glaube nicht mehr an den Weihnachtsmann ;-) > Ich nehme aber zur Kenntnis, daß das Mantra "Anforderungsliste" für die > wiederholte Auflistung von längst Bekanntem und einfachster > Funktionalität jener Nothaltegriff ist, der als Ausrede für unsere > C-Freunde unabdingbar ist um nicht in der Flut guter Argumente und > Fakten pro ASM den Halt zu verlieren ;-) ---------- Ihr Beitrag im Forum "Offtopic" wurde gelöscht. Betreff: Re: Assembler wieder auf dem Weg nach vorn Datum: 25.11.2015 21:07 Text des gelöschten Beitrags: ============================================== Moby A. schrieb: > Vielleicht sollte ich die Rolle von Assembler mal etwas bildlich > verdeutlichen: > > Wenn auf der Bühne der Controller in Aktion ist [... u.s.w. u.s.f.] Es ist unglaublich, wie du /[..selbst gelöscht..]/ trotzdem so excellent ausgedrückt auf den Bildschirm bringst. ----------
Moby A. schrieb: > um nicht in der Flut guter Argumente und Fakten pro ASM Software ohne Dokumentation/Anforderungsliste ist Müll. Software, bei der man diese durch Analyse des Quelltextes erst herausfinden muss, ist auch Müll. Software, bei der man die Funktionsweise erst durch ständiges Referenzieren des Datenblatts/UserGuides herausfinden kann, ist ebenfalls Müll. Und das ist auch bei Trivialsoftware wie Deinem Assembler"projekt" der Fall.
Lothar M. schrieb: > Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde > ich niemals mehr mit 8-Bit uC und Assembler anfangen. Was interessieren mich die Gründe des Herstellers diesen Gerätes (vielleicht hat er gute, Berechnungen vielleicht?) wenn 8-Bit MSR ganz offensichtlich einfacher mit AVR/ASM-Power gelöst ist (siehe mein Projektchen)! P. M. schrieb: > In diesem Punkt haben wir > dir schon lange zugestimmt: Ja, auf kleinsten Controllern kann Assembler > ein vernünftiges Werkzeug sein. Dann verallgemeinerst du aber wieder auf > grössere Projekte und Prozessoren. Und auch Du unterstellst schon wieder, daß ich auf entsprechend daten/berechnungsintensive Projekte und große Prozessoren verallgemeinere. Dabei hatte ich das wiederholt klargestellt. Es ist aber erfreulich, hier Asm als "vernünftiges" Werkzeug bezeichnet zu sehen- auch wenn ich die Obergrenze weit höher ziehen würde. Ich finde dabei könnte man es jetzt belassen ;-) Karl H. schrieb: > Erweitern? > Was willst du da erweitern? > Der Code ist so dermassen auf 2 ADC Eingänge und 2 Digitale Eingänge > hingeschustert, das Protokoll ist so dermassen auf genau diese > Konstellation hingearbeitet, dass man da nichts erweitern kann. Hat man > nicht genau diese Anforderungen, dann bleibt nichts anderes übrig, als > den Code komplett neu zu machen. Das habe ich nun auch bis zum Erbrechen erläutert worin die Erweiterungsmöglichkeiten bestehen. Sage bitte jetzt nicht, diese wären nicht sinnvoll. Ansonsten nimm bitte hin, daß dies eine Hard/Software angepasste und optimierte und demzufolge auch so effiziente Lösung ist. Damit chancenlos mit C zu toppen! > denn im Zweifel hab ich lieber eine Codebasis, die > ich auf meine Bedürfnisse anpassen kann als eine die ich komplett neu > schreiben muss, wenn ich nicht genau die vom Autor vorgegebenen > Anforderungen habe. Selbst wenn dann der Code ein paar Bytes länger ist > und ein paar Taktzyklen mehr braucht. Schön und gut. Mach das doch. Asm lässt auch flexibler formulieren! Bei einfachem 8-Bit MSR auf AVR kommt aber noch eines hinzu: Sooo kompliziert ist das alles nicht, sogar mal eben komplett neuen Code für eine andere I/O-Ausstattung zu erstellen wenns meinem Anspruch zufolge so kompakt-optimiert und C-furchtlos bleiben soll. Ich hoffe Du wolltest mir mit Deinem Beitrag nicht wieder eine "Brücke" bauen und ich hab sie jetzt zum Einsturz gebracht ;-)
Moby A. schrieb: > Schön und gut. Mach das doch. Asm lässt auch flexibler formulieren! Irgendwie scheinst du den Sinn einer Codesammlung zur Verfügungstellung allgemeiner Lösungen für alle nicht verstanden zu haben.
Michael K. schrieb: > Was gerade das Kriterium ist und was aus der Wertung fällt ändert sich > nach Wind und Wellenschlag. Verbindliche Kriterien gibt es nicht, > vielmehr werden die jederzeit so angepasst das Du in deiner Wahrnehmung > im Recht bleibst. Unsinn. Alles klar, alles verbindlich. Längst. Ich kann aber unter den herrschenden Umständen hier verstehen wenn es manchem sehr schwer fällt, ein Verständnis des Begriffs "Controller-Ressourcen" zu entwickeln... Das ist alles eine sehr sehr komplexe Angelegenheit (oder sagen wir besser: sie wird zu dieser gemacht ;-) Teil jenes Gummibands mit dem ich mich konfrontiert sehe. Treibt mich aber nicht zur Weißglut. Der Mensch wird halt erfinderisch wenn Offensichtliches doch noch irgendwie vernebelt werden soll. > Du behauptest was immer Du willst und nennst das dann Fakten. Ich behaupte, was mein Code benötigt. Das sind Fakten. Wer bietet weniger? > Du wirfts C Verschwendung vor und verschwendest selber viel mehr. > stopfst Deinen Code aber mit unsinnigem voll Ach wirklich? Dazu müsste es ja erstmal eine C-Lösung geben. Nur wird die nie kommen weil sie BESSER nie kommen kann. Was mancher hier (ich kanns gar nicht ernst nehmen) als Verschwendung bezeichnet gehört für mich schlicht zu einem ordentlichen und erweiterungs-vorbereiteten Programm. Der Strohhalm "Verschwendung" ist noch nichtmal ein ernstzunehmender Strohhalm, sondern als Vorwurf dermaßen abstrus, daß es höchstens noch als weichgekochte Nudel durchgeht ;-) Aber prima Ablenkungstaktik, wenns doch eigentlich um besseren C-Code gehen sollte. Nutzt die Gunst der Stunde! Mein Code ist so unsinnig vollgepackt- ein Leichtes für jede mittelmäßige C-Lösung ;-)) > Das ist ein absolut irrer Amoklauf durch alles was unreife Kommunikation > ausmacht. Dementsprechend wirst Du behandelt. Wie ein anonymer Moby hier behandelt wird interessiert mich nicht. Der Amoklauf ergibt sich aus der Frechheit, wie ein durchschnittlicher Asm-Programmierer hier manchen C-ler vorführt ;-) > technischen Diskussion ein Schlagabtausch wird, dann blanker Hass, dann > völlige Resignation. Na ich hoffe Du verortest blanken Hass und völlige Resignation jetzt nicht auf meiner Seite. Wär nämlich weit gefehlt ;-)
:
Bearbeitet durch User
Karl H. schrieb: > Irgendwie scheinst du den Sinn einer Codesammlung zur Verfügungstellung > allgemeiner Lösungen für alle nicht verstanden zu haben. Humor hast Du ;-) Da verschlägts mir jetzt ausnahmsweise mal wirklich die Sprache! Die Lösung muß also "allgemein" sein. So so.
Karl H. schrieb: > war im Ausland. >>gewünschten Zwischenmasse In der Schweiz? Ich hätte ein ß verwendet, falls die Tastatur das hergibt...
Moby A. schrieb: > Karl H. schrieb: >> Irgendwie scheinst du den Sinn einer Codesammlung zur Verfügungstellung >> allgemeiner Lösungen für alle nicht verstanden zu haben. > > Humor hast Du ;-) > Da verschlägts mir jetzt ausnahmsweise mal wirklich die Sprache! > Die Lösung muß also "allgemein" sein. So so. Ergänzung: Ich hatte das ein meinem Projektthread sogar schon mal scherzhaft vermutet: Moby A. schrieb: > Offensichtlich enthalten die Forenregeln aber den neuen Passus: > "Projekte müssen für jedermann auch ohne Mühe und Vorkenntnis verwend- > und einfachst an alle Situationen anpassbar sein". Nie im Leben hätte ich mir vorstellen können, daß so schnell draus Ernst wird ;-)
Lothar M. schrieb: > Nein, sicher nicht. Aber es zeigt eben, dass wir heute in 2015 leben. Was interessiert mich die Jahreszahl wenn ich die einfachste Lösung will! > Und dass man das Projekt dort nicht mit maximalem Aufwand in die > Programmierung in den kleinsten am Markt verfügbaren uC reinprügelt. Von Reinprügeln kann gar keine Rede sein. > Sondern "einfach" einen nimmt, der ausreichend leistungsfähig ist, und > dann auf eine Softwareplattform setzt, die portierbar und tendenziell > abstrakt ist. Genau. Der PC wird schließlich auch alle paar Jahre aufgerüstet (um unter dem Strich weiter die gleichen Aufgaben zu bearbeiten wie zuvor). >> Faktenbasierteres als die Fakten zu Codesize, RAM-Verbrauch (und ggf >> Speed) gibts einfach nicht. > Doch: Marktzahlen und Produkteinführungstermine. Was nützt das schönste > und optimierteste Gerät, wenn es 2 Jahre zu spät am Markt ist? Da geb ich Dir Recht. Andererseits bedeutet das aber oft nur: Schnelle Quantität geht vor Qualität. Reift ja beim Kunden.
Hmmm, Sisyphos oder doch Prometheus? https://de.wikipedia.org/wiki/Sisyphos https://de.wikipedia.org/wiki/Prometheus#Prometheus-Sage
Rufus Τ. F. schrieb: > Software, bei der man die Funktionsweise erst durch ständiges > Referenzieren des Datenblatts/UserGuides herausfinden kann, ist > ebenfalls Müll. Ziemlich allgemeines Statement ... bei einem Bildbetrachter stimme ich dem zu, bei einem CAD-System schon weniger und bei einem Compiler gar nicht ...
Matthias L. schrieb: > Karl H. schrieb: >> war im Ausland. > >>>gewünschten Zwischenmasse > > > In der Schweiz? Ich hätte ein ß verwendet, falls die Tastatur das > hergibt... Weiter weg. China
A. K. schrieb: > Ein jeder hat in seinem individuellen Abstand sein Brett > vor dem Kopf. Aber erst durch den missionarischen Eifer, dies zum Ende > der Welt zu definieren, wird es zum Problem. Asm auf 8-Bit Controller fürs MSR ist sicher nicht das Ende der Welt. Aber in seinem Bereich optimal. Jörg W. schrieb: > Dahingehend ist die Anforderung „darf keinen wertvollen RAM brauchen, > damit noch Platz für Erweiterungen ist“ ja völlig absurd, zumal > Register in einem Prozessor wohl immer teurer sind als RAM (Ausnahme: > Z8, bei dem gab es keinen Unterschied zwischen RAM und Registern). Suchst Du schon wieder nach Ausreden? Die Anforderung "Kein RAM" kommt Erweiterungen natürlich zugute! Stell Dir eine umfangreiche Vorverarbeitung der Messwerte vor. Vielleicht mit History und statistischer Auswertung. Der eigentliche Grund für die Forderung ist aber ein ganz anderer: Flash und SRAM sind variable MC-Ressourcen und das geniale C mit der Kompetenz tausender Compiler-Bauer soll bei gleicher Funktionalität nur wie behauptet zeigen, daß es damit besser umgehen kann!
Rufus Τ. F. schrieb: > Software, bei der man die Funktionsweise erst durch ständiges > Referenzieren des Datenblatts/UserGuides herausfinden kann, ist > ebenfalls Müll. Du sollst keine Funktions- weise herausfinden sondern schlicht die simple, schon mit dem ersten Diagramm und erst recht mit der zugehörigen Beschreibung bzw. Kommentierung im Quelltext eindeutige Funktion ganz nach Lust und Laune, aber ressourcensparender in C nachbauen. P.S. Mir ist klar, daß ich mit dieser Formulierung jetzt auf gewisse andere Architekturmerkmale meiner Software (wie zuvor verlangt) verzichte. So stur ist der Esel gar nicht, obwohl er natürlich weiß, daß der Schwierigkeitsgrad für die C-Lösung damit nur unmerklich sinkt ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Asm auf 8-Bit Controller fürs MSR ist sicher nicht das Ende der Welt. doch, aber das untere.
Klaus W. schrieb: > doch, aber das untere ... Ende der nötigen Komplexität für 8-Bit MSR. Für die hier einfachste Lösung ;-)
gähn.. wird langweilig hier.. @Moby: kannst nicht einfach irgendeine Erweiterung einbauen, in dein "Projekt" ? (und veröffentlichen) damit wir mal was neues zum Diskudieren haben.. 1-Wire Slave Simiulieren, wäre z.B. interessant... oder du traust dich endlich dein xmega projekt herzuzeigen?
Sven B. schrieb: > Ziemlich allgemeines Statement ... bei einem Bildbetrachter stimme ich > dem zu, bei einem CAD-System schon weniger und bei einem Compiler gar > nicht ... Du hättest erkennen können, daß wir hier vom Quelltext reden. Moby A. schrieb: > Du sollst keine Funktions- weise herausfinden sondern schlicht die > simple, schon mit dem ersten Diagramm und erst recht mit der zugehörigen > Beschreibung bzw. Kommentierung im Quelltext eindeutige Funktion ganz > nach Lust und Laune, aber ressourcensparender in C nachbauen. Kind, ich verdiene mir seit über 25 Jahren mein Geld mit Softwareentwicklung, und ich habe Unmengen an fremdem Quelltext angesehen. Zeug, das so aussieht wie Deins, überfliege ich bestenfalls und dann landets in der Tonne. Das ist ein Muster ohne Wert. Selbst wenn es das tun sollte, was Du behauptest, was es tut, ist es de facto undokumentiertes Gefrickel. Eine "eindeutige Funktion" ist da weder beschrieben noch der Kommentierung im Quelltext entnehmbar. Die existiert nur in Deiner Vorstellung.
Robert L. schrieb: > gähn.. wird langweilig hier.. So durch die Blume hab ich ja Recht erhalten, ganz offen kann das natürlich niemand zugeben. Somit ist glaub ich vorläufig alles gesagt ;-) > @Moby: kannst nicht einfach irgendeine Erweiterung einbauen Nein, aber sollte wieder eine Meldung zu Asm mit meinen persönlichen Erfahrungen deckungsgleich sein bring ich das gern wieder in die Diskussion ein! > 1-Wire Slave Simiulieren, wäre z.B. interessant... brauch ich persönlich aber nicht. > oder du traust dich endlich dein xmega projekt herzuzeigen? Falls Du meine Haussteuerungs-Zentrale meinst hatte ich das aus verständlichen Gründen schon abgelehnt. Wird aber bestimmt weitere Asm-Codes von mir geben, um die effiziente Asm-Programmierung hier zusammen mit anderen hochzuhalten! Falls ihnen K.H. nicht wieder mangelnde "Allgemeinheit für alle" abspricht ;-)
Rufus Τ. F. schrieb: > Kind, ich verdiene mir seit über 25 Jahren mein Geld mit > Softwareentwicklung, und ich habe Unmengen an fremdem Quelltext > angesehen. Aus dem Alter bin ich raus ;-) > Zeug, das so aussieht wie Deins, überfliege ich bestenfalls und dann > landets in der Tonne. Das ist ein Muster ohne Wert ... weils C keine Chance lässt ;-) > Selbst wenn es das > tun sollte, was Du behauptest, was es tut Schon diese Formulierung offenbart jetzt mehr als Du vielleicht sagen möchtest. > Eine "eindeutige Funktion" ist da weder beschrieben noch der > Kommentierung im Quelltext entnehmbar. Die existiert nur in Deiner > Vorstellung. Sagen wir mal so: Natürlich trau ich Dir die "Erkenntnis" der Funktion zu. Vermutlich sogar ohne Worte, allein aus dem Diagramm abgelesen. Du willst nichts zur Kenntnis nehmen. Das ist leider Gottes schon alles.
Rufus Τ. F. schrieb: > Womit verdienst Du Dein Geld? Das solltest Du jetzt schnell selber löschen, denn Du entführst den Thread ;-) Gute Nacht.
Rufus Τ. F. schrieb: > Zeug, das so aussieht wie Deins, überfliege ich bestenfalls und dann > landets in der Tonne. Das ist ein Muster ohne Wert. Selbst wenn es das > tun sollte, was Du behauptest, was es tut, ist es de facto > undokumentiertes Gefrickel. > > Eine "eindeutige Funktion" ist da weder beschrieben noch der > Kommentierung im Quelltext entnehmbar. Die existiert nur in Deiner > Vorstellung. 100% ACK. Moby-Code hat mir das unvergessliche Erlebnis beschert, seinen ASM-Code Bit für Bit und Befehl für Befehl aufdröseln zu müssen, um erahnen zu können, was seine kryptischen Kommentare vielleicht bedeuten könnten. Beitrag "Re: C versus Assembler->Performance" Und das ging nicht nur mir so sondern auch Yalu, einem der hellsten Köpfe hier Beitrag "Re: C versus Assembler->Performance"
Johann L. schrieb: > Und das ging nicht nur mir so sondern auch Yalu, einem der hellsten > Köpfe hier Tja, ihr seid eben alle noch schlechter als ein „mittelmäßiger ASM-Programmierer“. :-) Wenn ich mir überlege, was für einen Sche*** man seinerzeit alles so auf dem Z80 zusammengestrickt hat, wird mir heute noch schlecht. Da ist ein AVR ja harmlos, dank Harvard fällt selstmodifizierender Code praktisch von selbst aus. ;-)
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >Wenn ich mir überlege, was für einen Sche*** man seinerzeit alles so >auf dem Z80 zusammengestrickt hat, wird mir heute noch schlecht. Wir waren jung, wild und schmerzfrei! ;-) > Da >ist ein AVR ja harmlos, dank Harvard fällt selstmodifizierender Code >praktisch von selbst aus. ;-) Auf dem Amiga mit 68000 ging das problemlos, aber solche Stunts hab ich trotzdem nicht gemacht. Kugelfisch essen ist sinnvoller!
Jörg W. schrieb: > Tja, ihr seid eben alle noch schlechter als ein > „mittelmäßiger ASM-Programmierer“. :-) Eher „8-Bit-MSR-Überlauf-brauch-ich-nicht-AVR-only-ASM-Programmierer“
Falk B. schrieb: > aber solche Stunts hab ich trotzdem nicht gemacht. War auf dem Z80 gang und gäbe (auch im CP/M-Code selbst). Beispiel:
1 | buffsize: |
2 | ;; return size of ring buffer |
3 | ld hl, b_start |
4 | put_pointer equ $ - 2 |
5 | ld de, b_start |
6 | get_pointer equ $ - 2 |
7 | and a |
8 | sbc hl, de |
9 | jp p, bfsz1 |
10 | ;; negative amount -> add size; ring buffer |
11 | ld de, b_end - b_start |
12 | add hl, de |
13 | bfsz1: ld a, l |
14 | ret |
[Anm.: JP P,xx = "Jump if Plus"] [Anm.2: AND A war ein gängiger Befehl zum Löschen des Carry-Flags] Man beachte die labels "put_pointer" und "get_pointer". Die zeigen auf den Direktoperanden des vorhergehenden LD RR,NN-Befehls. Benutzt wurden diese dann als ganz normale Variablen:
1 | sioin: di |
2 | call buffsize |
3 | ei |
4 | and a |
5 | jr z, sioin ; must wait |
6 | |
7 | di ; avoid the race condx |
8 | ld hl, (get_pointer) |
9 | ld a, (hl) |
10 | call incr_ptr |
11 | ld (get_pointer), hl |
12 | ei |
13 | |
14 | ret |
Sparte halt zwei extra Bytes für die Daten. ;-)
:
Bearbeitet durch Moderator
Moby A. schrieb: > Robert L. schrieb: >> gähn.. wird langweilig hier.. > > So durch die Blume hab ich ja Recht erhalten, ganz offen kann das > natürlich niemand zugeben. Somit ist glaub ich vorläufig alles gesagt > ;-) nein, hast nu nicht, und ja es wurde schon alles gesagt (ausser das was man hier nicht sagen darf, weil es sonst eine persönliche Beleidigung wäre, und vermutlich glöscht würde..) und langweilig ist es,weil nur immer nur die selben "Argumente" wiederholst.. > >> @Moby: kannst nicht einfach irgendeine Erweiterung einbauen > > Nein, aber sollte wieder eine Meldung zu Asm mit meinen persönlichen > Erfahrungen deckungsgleich sein bring ich das gern wieder in die > Diskussion ein! > du hast unmengen speicher und flash "gespart" damit du dann KEINE erweiterung einbaust.. >> 1-Wire Slave Simiulieren, wäre z.B. interessant... > > brauch ich persönlich aber nicht. > und? >> oder du traust dich endlich dein xmega projekt herzuzeigen? > > Falls Du meine Haussteuerungs-Zentrale meinst hatte ich das aus > verständlichen Gründen schon abgelehnt. nein hast du nicht >Wird aber bestimmt weitere > Asm-Codes von mir geben, um die effiziente Asm-Programmierung hier > zusammen mit anderen hochzuhalten! hast du noch nie > Falls ihnen K.H. nicht wieder > mangelnde "Allgemeinheit für alle" abspricht ;-) ein größeres Projekt, besteht ja, auch bei dir: aus (vielen) "Erweiterungen" (grobe Blöcke) die ja wohl wiederverwendbar (für andere größere Projekte) sind.. sonst müsstest ja jedesmal alles neu schreiben.. deshalb ist deine Angst ja unbegründet..
:
Bearbeitet durch User
Jörg W. schrieb: > Sparte halt zwei extra Bytes für die Daten. ;-) Auch mit Harvard kann man Spässe treiben. Sinngemäss wäre das hier möglich, bei PIC/AVR lohnt es aber aufgrund des steiferen Befehlsformats nicht: entry0: clc ; entrypoint mit C=0 .byte opcode(LDA ZP) entry1: sec ; entrypoint mit C=1 Der LDA befehl dient hier nur dazu, den SEC zu maskieren. Arbeitet also als 1-oder 2-Byte SKIP Befehl. Sowas in der Art hatte beispielsweise der 8KB PL/65 Compiler für den 6502 systematisch verwendet um jeweils 1 Byte einzusparen. Konnte man aber sicherlich analog auch bei 8080/Z80 finden. Besonders fies ist das beim Disassemblieren. Was aber auch dadurch nicht leichter wurde, dass Strings als Parameter nicht umständlich mit expliziter Adresse übergeben wurden, sondern implizit über den Program Counter: jsr puts .byte 'Hallo Wel', 't'+$80 Diese Variante kann sich auch beim AVR lohnen. PS: Bei dem PL/65 Compiler hat Moby Recht: In C hätte der niemals in die 2x 4KB ROMs gepasst.
:
Bearbeitet durch User
Moby A. schrieb: > Lothar M. schrieb: >> Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde >> ich niemals mehr mit 8-Bit uC und Assembler anfangen. > Was interessieren mich die Gründe des Herstellers diesen Gerätes > (vielleicht hat er gute, Berechnungen vielleicht?) wenn 8-Bit MSR ganz > offensichtlich einfacher mit AVR/ASM-Power gelöst ist (siehe mein > Projektchen)! Also. Ich fasse für mich presönlich zusammen: wenn ich genau so ein Projektchen habe, das nur mistt, aber weder steuert und noch viel, viel weniger regelt, dann ist Assembler gerade richtig. Ich habe aber keine solche Projektchen. Und falls doch, dann mache ich die mit der selben Toolchain mit der ich die richtigen Projekte auch mache... A. K. schrieb: > PS: Bei dem PL/65 Compiler hat Moby Recht: In C hätte der niemals in die > 2x 4KB ROMs gepasst. Wir sind heute(!) aber fast 40 Jahre weiter... https://books.google.de/books?id=7mDo3ieRWJEC&pg=PA40&lpg=PA40&dq=PL/65+compiler&source=bl&ots=YEoavGmKT-&sig=R4dC1qQFFTqKKsUjWdsTyj1q6OM&hl=de&sa=X&ved=0ahUKEwiXuc2xhbPJAhUIbRQKHYnZCkMQ6AEIODAC#v=onepage&q=PL%2F65%20compiler&f=false https://books.google.de/books?id=CyW_hu4H-u4C&pg=PA43&lpg=PA43&dq=PL/65+compiler&source=bl&ots=cbmuh_LIRA&sig=rSzojLr5oo9oifoiUz9blKRwZmQ&hl=de&sa=X&ved=0ahUKEwiXuc2xhbPJAhUIbRQKHYnZCkMQ6AEIUDAG#v=onepage&q=PL%2F65%20compiler&f=false
Warum in aller Welt "diskutieren" gestandene Männer mit einem Subjekt wie Moby? Früher (tm) hätte man ihn einfach ausgelacht und links liegen gelassen. Helfersyndrom? Fühlt ihr euch durch Mobys "Argumente" zur Diskussion oder gar Verteidigung eures Standpunkts herausgefordert? Arme Irre gibt es Millionen auf dieser Welt und man wird keinen von ihnen schlau machen.
A. K. schrieb: > Auch mit Harvard kann man Spässe treiben. Sinngemäss wäre das hier > möglich, bei PIC/AVR lohnt es aber aufgrund des steiferen Befehlsformats > nicht: > > entry0: clc ; entrypoint mit C=0 > .byte opcode(LDA ZP) > entry1: sec ; entrypoint mit C=1 > > Der LDA befehl dient hier nur dazu, den SEC zu maskieren. avr-gcc verwendet das an wenigen Stellen, z.B: http://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/lib1funcs.S?revision=219188&view=markup#l1267
1 | DEFUN __mulsidi3 |
2 | set |
3 | skip |
4 | ;; FALLTHRU |
5 | ENDF __mulsidi3 |
6 | |
7 | DEFUN __umulsidi3 |
8 | clt ; skipped |
9 | ... |
Beim Disassemblieren steht natürlich kein "skip" da, sondern CPSE Rn,Rn. Ginge zwar auch mit RJMP, ist aber nun mal so gelöst.
Johann L. schrieb: > 100% ACK. > > Moby-Code hat mir das unvergessliche Erlebnis beschert, seinen ASM-Code > Bit für Bit und Befehl für Befehl aufdröseln zu müssen, um erahnen zu > können, Wenn Du nur soviel sagen kannst solltest Du besser erstmal frühere Erfolge auf Asm-Gebiet unerwähnt lassen. Neben vielen erheiternden Momenten hier macht mich eine solche Äußerung von einem erklärtermaßen erfahrenen Asm-Programmierer eher nachdenklich, fast traurig. Ich kann mir das nur so erklären: - Du willst nicht oder - Du kannst nicht Ist Deine letzte Beschäftigung mit AVR-Assembler vielleicht schon länger her? So wie Du Dich darstellst bzw. dargestellt wirst solltest Du meinen Code bisherigen Umfanges nackt ohne weitere Worte lesen können, allenfalls mit einer kurzen Beschreibung um was es geht... Ich meine, worüber reden wir hier eigenlich? Über die Organisation einer Mondlandung oder über einen kleinen ACHT-BIT-Controller mit ein paar Registern, ein paar Vorschriften wie dessen Steuerregister zu füllen sind und ein paar Dutzend simpler Instruktionen? Nun war noch nichtmal verlangt, meinen Projektcode wirklich zu verstehen. Zur Funktions-Nachbildung in einem C-Programm langt die kurze Beschreibung. Aber wenn man ängstlich ist und um sein C-Effizienzergebnis besorgt, dann kann ich schon verstehen daß man fordert, ihn verstehen zu können... Da muß ich aber sagen: Sorry. Ein Asm-Kurs war nicht inklusive ;-)
Lothar M. schrieb: > Wir sind heute(!) aber fast 40 Jahre weiter... Vor 40 Jahren funktionierte ein Hammer so wie heute auch. Alt/Neu ist längst keine Aussage über Sinnvoll/Unsinnig. > Ich habe aber keine solche Projektchen. Und falls doch, dann mache ich > die mit der selben Toolchain mit der ich die richtigen Projekte auch > mache... ... und bleibst damit mehr oder weniger weit von der möglichen Asm-Effizienz entfernt. Und, hast viel Zeit investieren müssen das Ganze irgendwann mal zu erlernen und zu beherrschen. Aber OK, solange es Projekte gibt die davon wirklich profitieren...
:
Bearbeitet durch User
> Da muß ich aber sagen: Sorry. Ein Asm-Kurs war nicht inklusive ;-)
Der war gut!
Sehe schon in der Zeitung mit den Großen Lettern:
"AVR-GCC Entwicklung muß eingestellt werden!
Moby-AVR verweigert Georg Johann Lay den Assembler-Kurs!"
Falk B. schrieb: > Fühlt ihr euch durch Mobys "Argumente" zur Diskussion oder gar > Verteidigung eures Standpunkts herausgefordert? Ein frustriertes "Subjekt" Falk (ich spare mir weitere beleidigende Untertöne) hat sich an der Diskussion um Fakten, wie in meinem Projektchen dargestellt, fachlich gar nicht beteiligt. Vielleicht dank seiner Einsicht um die Schwächen von C ?
Carl D. schrieb: > Moby-AVR verweigert Georg Johann Lay den Assembler-Kurs! Davon würde ich nicht zu träumen wagen ;-) Speziell von ihm bin ich aber enttäuscht. Sage ich jetzt ohne Smiley.
> Vielleicht dank seiner Einsicht um die Schwächen von C ?
Oder vielleicht weil außer dir niemand an dem interessiert ist, was dir
als Fakten vorschwebt?
Bestimmt komisch, wenn man als einziger Geisterfahrer unterwegs ist...
:
Bearbeitet durch User
Klaus W. schrieb: > Oder vielleicht weil außer dir niemand an dem interessiert ist, was dir > als Fakten vorschwebt? Flash- und SRAM Verbrauch sind Fakten. Asm ist in dieser Disziplin besser. Das interessiert mich. Für wen anderes wichtiger ist soll es anders lösen. Aber nicht obigen Fakten widersprechen.
Moby A. schrieb: > Flash- und SRAM Verbrauch sind Fakten. > Asm ist in dieser Disziplin besser. > Das interessiert mich. Das Wichtigste fehlt: Die Entwicklungszeit. Du da ist jeder Sprache vor ASM. Und das interessiert alle anderen.
Matthias L. schrieb: > Das Wichtigste fehlt: > > Die Entwicklungszeit. Genau. Natürlich kann man ein Haus bauen, indem man die Ziegelsteine aus einzelnen Sandkörnern zusammenklebt. Da bekommt jeder Ziegelstein genau die richtige Form und die richtigen Abmessungen und kann so beispielsweise für Kabel o.ä. schon vor dem Mauern der Wand mit den richtigen Schlitzen, oder für Steckdosen, Lichtschalter o.ä. mit den richtigen Löchern versehen werden. Aber das macht niemand.
Rufus Τ. F. schrieb: > Natürlich kann man ein Haus bauen, indem man die Ziegelsteine aus > einzelnen Sandkörnern zusammenklebt. Und nicht vergessen: die oberen 2 Stockwerke sind für Erweiterungen reserviert und dürfen erst mal nicht bewohnt werden. Und jedem, der am Haus vobeiläuft unbedingt erklären, wie wichtig dieser Leerstand ist.
Carl D. schrieb: > er am Haus vobeiläuft unbedingt erklären Tut ja keiner. Das Grundstück bleibt leer, weil Moby immernoch am ersten Zeigelsteil ist. Dafür wurde kein Milligramm Ton zuviel angerührt
Rufus Τ. F. schrieb: > Natürlich kann man ein Haus bauen, indem man die Ziegelsteine aus > einzelnen Sandkörnern zusammenklebt. Da bekommt jeder Ziegelstein genau > die richtige Form und die richtigen Abmessungen Prima. Ein Vorzug von Asm ist damit gut beschrieben. Mit Übung, Vorbereitung und System kann auch das Haus durchaus ansehnlich werden. Matthias L. schrieb: > Das Wichtigste fehlt: > > Die Entwicklungszeit. Du da ist jeder Sprache vor ASM. Und das > interessiert alle anderen. Mit Übung, Vorbereitung und System kann auch die Entwicklungszeit durchaus im Rahmen bleiben. Matthias L. schrieb: > Tut ja keiner. Das Grundstück bleibt leer, weil Moby immernoch am ersten > Zeigelsteil ist. Nein, Moby hat fertig. Der C-ler ist noch am Lernen und Auseinandersetzen mit seinem Werkzeug ;-) Carl D. schrieb: > Und nicht vergessen: die oberen 2 Stockwerke sind für Erweiterungen > reserviert und dürfen erst mal nicht bewohnt werden. Und jedem, der am > Haus vobeiläuft unbedingt erklären, wie wichtig dieser Leerstand ist. Das muß man glaub ich nicht erklären. Das Platzangebot zieht als Werbeargument von ganz alleine ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Mit Übung, Vorbereitung und System Moby A. schrieb: > Nein, Moby hat fertig. Der C-ler Wie kommst du eigentlich darauf, dass das hier der Kampf des einsamen Rächers der Mnemonic gegen die C-dioten ist? Dieser Thread ist der erfolglose Versuch einiger Leute mit vernünftigen Argumenten mit einem Phrasendrescher zu diskutieren. Insofern hast du also gewonnen. Ist aber ein Pyrrhussieg, weil dich niemand mehr ernst nimmt. mfg.
Moby A. schrieb: > Mit Übung, Vorbereitung und System kann auch das Haus durchaus > ansehnlich werden. Das Problem hierbei ist die viel zu kurze typische Lebenserwartung des Menschen. Kaum jemand, der sich ein Haus bauen möchte, ist bereit, dafür die Bauzeit des Kölner Doms hinzunehmen. Außer dem hier oft beschworenen "ASMler".
Thomas E. schrieb: > Ist aber ein Pyrrhussieg, weil dich niemand mehr ernst nimmt. Das ist dem Moby egal, denn mit jedem Beitrag hier brnigen wir "Assembler weiter auf dem Wag nach vorne". Und da die Häufigheit der Verwendung von Assembler locker im Rauschen untergeht, hat jeder ASM-Pups einen gewaltigen Hebel was wie "Popularität" von Assembler angeht. Also schön weiter pupsen...
Rufus Τ. F. schrieb: > Kaum jemand, der sich ein Haus bauen möchte, ist bereit, dafür > die Bauzeit des Kölner Doms hinzunehmen. Genau an dieser Stelle hakt der Vergleich, was die zeitliche Dimension angeht. Wenn man sich es genau beschaut geht auch gar nicht soviel Zeit in die eigentliche Implementierung. Die meiste Überlegung benötigt ein solider Programmablauf-Plan unter Einbeziehung der vorhandenen Peripherie. Das wär in Hochsprache auch nichts anderes. Sandkorn/Ziegelstein ist eigentlich auch nicht das richtige Größenunterschied. Ich hatte Asm vs. C hinsichtlich Hardware-Anpassungsfähigkeit mal mit Ziegel- vs. Hohlblockstein verglichen. Passt für meinen Geschmack besser. Thomas E. schrieb: > mit einem Phrasendrescher zu diskutieren Fakten-Drescher! Fakten-Drescher! Fakten-Dresche, die mit eigenem Code belegt ist. Das gibt der Provokation gewisser Leute ja gerade die entscheidende Würze ;-) Die war genau dann erfolgreich, wenn nur noch Unterstellungen, Lächerlichmachen und Beleidigungen zurückkommem. Johann L. schrieb: > Und da die Häufigheit der Verwendung von Assembler locker im Rauschen > untergeht, Klare Übertreibung. Selbst in C muß nach wie vor drauf zurückgegriffen werden, auch wenn C der große Standard bleibt. Gerade deshalb fand ich aber die Meldung von der Asm-Entwicklung im Tiobe-Programmierindex so bemerkenswert! Ein redlicher professioneller Programmierer sollte das nicht so abfällig abtun ;-(
:
Bearbeitet durch User
Karl H. schrieb: > Irgendwie scheinst du den Sinn einer Codesammlung zur Verfügungstellung > allgemeiner Lösungen für alle nicht verstanden zu haben. Deshalb schrieb ich ja hier: Beitrag "Re: C versus Assembler->Performance" -------------------------------------------------------------------- "Dann ist das Programm für 99,9% der typischen Anwender sinnlos. Damit erfüllt es weder den Anspruch einer Weiterverwendung, noch hat es etwas in der Codesammlung zu suchen, da für die Allgemeinheit unbrauchbar. Ich plädiere daher dafür, dass ein Mod es aus der Codesammlung verschiebt." -------------------------------------------------------------------- Leider ist es heute noch unter Codesammlung zu finden, obwohl es darunter nichts zu suchen hat. Es ist und bleibt für andere User unbrauchbar.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Leider ist es heute noch unter Codesammlung zu finden, obwohl es > darunter nichts zu suchen hat. Es ist und bleibt für andere User > unbrauchbar. Unbrauchbar ist Deine Art, von Deinen auf die Interessen der Allgemeinheit zu schließen.
@ Frank M. (ukw) Benutzerseite >Leider ist es heute noch unter Codesammlung zu finden, obwohl es >darunter nichts zu suchen hat. Es ist und bleibt für andere User >unbrauchbar. Nicht ist unnütz, es kann auch als schlechtes Beispiel dienen. ;-)
Falk B. schrieb: > Nicht ist unnütz, es kann auch als schlechtes Beispiel dienen. ;-) So wie Dein Auftreten hier, meinst Du? Ein schlechtes, da störendes Beispiel ist Beitrag "Kleines Tiny13 Sensorboard" nur für die, die gern die allumfassende Überlegenheit von Hochsprachen propagieren ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Ein schlechtes, da störendes Beispiel ist > > Beitrag "Kleines Tiny13 Sensorboard" Lustig. Als ich deinem Link folgte, kam ich auf folgenden, sehr guten Beitrag: Beitrag "Re: Kleines Tiny13 Sensorboard" Vielleicht solltest du mal gute Beiträge beherzigen anstatt über andere zu zetern. Oder kannst du nix mehr lernen?
:
Bearbeitet durch User
Johann L. schrieb: > Vielleicht solltest du mal gute Beiträge beherzigen Ohne hier nochmal das Thema "Anforderungsspezifikation" für ein einfaches Projektchen durchzukauen: Keine "Spezifikation" der Welt hätte dazu geführt, daß eine bessere C-Lösung das Licht ebendieser erblickt. Davon abgesehen: Beherzigen tu ich gerne was. Es hilft aber alles nichts, es muß mich überzeugen. Zum Beispiel überzeugt mich, was ich irgendwo von einem Mod gelesen habe: Wenn in einem Thread zuviele Du/Dir/Deine vorkommen, sich die Diskussion also vom Fachlichen komplett ins Persönliche verlagert ist der Zeitpunkt gekommen, einen Thread zu beenden. Ich muß sagen, die Logik kann ich nachvollziehen... Schließlich hätte ich noch etwas was Du beherzigen solltest: Johann L. schrieb: > mit jedem Beitrag hier brnigen wir > "Assembler weiter auf dem Wag nach vorne" ;-)
:
Bearbeitet durch User
Frank M. schrieb: > Leider ist es heute noch unter Codesammlung zu finden, obwohl es > darunter nichts zu suchen hat. Naja, das trifft sicher auf einen nicht ganz kleinen Anteil der Codesammlung zu. Es kann ja einfach jeder für sich entscheiden, ob ihm das nützlich genug wäre für einen Nachnutzung.
Johann L. schrieb: > mit jedem Beitrag hier brnigen wir > "Assembler weiter auf dem Wag nach vorne" Der TIOBE-Index wertet "Suchanfragen an Suchmaschinen" aus. Da "hilft" keine Diskussion um ASM, sondern nur direktes Suchen. Und da man hier ja mit genügend Nutzlosem zum Thema ASM versorgt wird, will davon garnicht mehr. Moby freut sich also zu früh auf den noch größeren Sieg seiner "Fakten" in der nächsten Ausgabe dieser "wertvollen" Statistik. Und die anderen fahren weiter als wäre nichts gewesen und nur einer weiß, daß in De (und AT, ...) inzwischen auf Linksverkehr umgestellt wurde.
Moby A. schrieb: > Thomas E. schrieb: >> mit einem Phrasendrescher zu diskutieren > > Fakten-Drescher! Nee, Phrasendrescher, Thomas hat schon Recht. > Ein redlicher professioneller Programmierer sollte das nicht so abfällig > abtun ;-( Daß ausgerechnet Du Dich nach Deinen miesen Betrügereien und Verdrehungen noch traust, von Redlichkeit zu sprechen, ist der absolute Hohn.
Moby A. schrieb: > Der eigentliche Grund für die Forderung ist aber ein ganz anderer: > Flash und SRAM sind variable MC-Ressourcen und das geniale C mit der > Kompetenz tausender Compiler-Bauer soll bei gleicher Funktionalität nur > wie behauptet zeigen, daß es damit besser umgehen kann! Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein ganz anderer: Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man keinen Krüppel-Code schreiben will), dieser befindet sich traditionell ebenfalls im RAM. Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu gewinnen... Moby A. schrieb: > das geniale C mit der Kompetenz tausender Compiler-Bauer Und diesen Sarkasmus spar dir mal lieber du trauriges Würstchen (Beleidigung intended). Jeder der aktiv an einem Compiler mitgewirkt hat hat wahrscheinlich ein zigfaches deiner bescheidenen ASM-Kenntnisse. Da solltest echt mal lieber haushalten. *Ich sage bewusst "ohne Klimmzüge". Denn dank den genialen Compilerbauern ist C heute hinreichend flexibel um Klimmzüge zu ermöglichen, die einen RAM bei kleinen Projektchen nicht zwingend vorraussetzen. (Z.B. die Möglichkeit, automatische Variablen in Registern zu parken)
:
Bearbeitet durch User
Moby A. schrieb: > Rufus Τ. F. schrieb: >> Natürlich kann man ein Haus bauen, indem man die Ziegelsteine aus >> einzelnen Sandkörnern zusammenklebt. Da bekommt jeder Ziegelstein genau >> die richtige Form und die richtigen Abmessungen > > Prima. Ein Vorzug von Asm ist damit gut beschrieben. > Mit Übung, Vorbereitung und System kann auch das Haus durchaus > ansehnlich werden. Damit ist Mobys Welt/Horizont doch eindeutig beschrieben. Jede weitere Diskussion ist in meinen Augen hinfällig.
Sheeva P. schrieb: > nach Deinen miesen Betrügereien Du hast Dich ganz einfach selbst betrogen. Man sollte schon selber wissen, was man wann in Angriff nimmt. Dir fehlt auch die Einsicht in die Unmöglichkeit der Aufgabe. Nun bin natürlich ich schuld. Schau mal mit offenen Augen, wieviel unter der Gürtellinie ich dafür einstecken musste. Gu. F. schrieb im Beitrag #4368556: > Rufus Τ. F. schrieb: > Womit verdienst Du Dein Geld? > > Trollen Für Deine Trollerei gäbs keinen Cent ;-) So, nun können sich die "getroffenen Hunde" mal richtig ausheulen und gegenseitig die Wunden lecken. Ich denke zum Thema ist hier alles gesagt. Daß ich nicht auf fast jede Äußerung, und sei sie noch so sehr mit Verdrehungen, Unterstellungen und Ablenkungsmanövern gespickt eingegangen bin, kann mir niemand vorwerfen. Gegenseitiges Rumzicken ist aber jetzt von meinem Zeitbudget nicht mehr gedeckt ;-) Moby
:
Wiederhergestellt durch Moderator
Moby A. schrieb: > Johann L. schrieb: >> Vielleicht solltest du mal gute Beiträge beherzigen > > Ohne hier nochmal das Thema "Anforderungsspezifikation" für ein > einfaches Projektchen durchzukauen: Keine "Spezifikation" der Welt hätte > dazu geführt, daß eine bessere C-Lösung das Licht ebendieser erblickt. Da Du es nicht probiert hast, kannst Du das nicht wissen. Im Gegenteil hast Du das mit allen unfairen Mitteln und miesen Tricks behindert. Als Du oben von Redlichkeit gefaselt hast, bin ich vor Lachen fast erstickt! > Davon abgesehen: Beherzigen tu ich gerne was. Nö. > Es hilft aber alles nichts, es muß mich überzeugen. Da Du gar nicht überzeugt werden willst und das mit allen unfairen Mitteln und miesen Tricks behinderst, ist das nutzlos. Ansonsten würdest Du uns ja einen fairen, ergebnisoffenen Wettbewerb liefern. Aber dazu bist Du offenbar zu feige. Wahrscheinlich weißt Du selbst, daß Du dabei nur verlieren kannst, weil Dein Assemblercode so schlecht ist. Viel Gegacker um nichts also, aber das ist man von Dir ja gewohnt. ;-)
le x. schrieb: > Moby A. schrieb: >> Flash und SRAM sind variable MC-Ressourcen und das geniale C mit der >> Kompetenz tausender Compiler-Bauer soll bei gleicher Funktionalität nur >> wie behauptet zeigen, daß es damit besser umgehen kann! > > Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein > ganz anderer: > Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung > eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man > keinen Krüppel-Code schreiben will), dieser befindet sich traditionell > ebenfalls im RAM. > > Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne > Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu > gewinnen... Viel lustiger ist ja, wie es zu dieser Anforderung gekommen ist. Er hatte sich offensichtlich und deutlich erkennbar ja schon die größtmögliche Mühe gegeben, es einem Compiler so schwer wie nur möglich zu machen -- und als bereits mein erster hingerotzter C-Versuch deutlich kleiner aussah als sein Assembler-Gefrickel, hat er die Sache mit dem RAM erfunden. Wie gesagt: er ist nichts weiter als ein Falschspieler und weder an einem fairen, offenen Wettbewerb noch an einem Erkenntnisgewinn interessiert.
Warum kann man sich hier eigentlich nicht einfach darauf einigen, dass einfache Projekte (sagen wir bis 500 Zeilen) in Assembler gegebenenfalls einfacher lösbar sind und komplexere in Hochsprache, z.B. C? Und ja, Teile davon dürfen auch gerne in Assembler programmiert sein. Wenn jemand Freude an Assembler-Programmierung hat, C64, Z80, PIC, Resourcenmangel, Zeitüberschuss, ja freilich, warum nicht. Der Großteil der Leserschaft wird die "bessere" Programmiersprache aber anhand von Eigenschaften wie Zeitersparnis, Wartbarkeit, Komplexität, Fehlerträchtigkeit... beurteilen. Moby, las' uns doch einen Blick auf einen Deiner 10000-Zeiler in Assembler werfen oder nenne zumindest eines, dann können wir darauf basierend weiterdiskutieren. Grüße, Christian <- Der PIC-Controller Zeit seines Lebens nur in Assembler programmiert hat ("wir hatten ja nichts")
> einfache Projekte (sagen wir bis 500 Zeilen) in Assembler > gegebenenfalls einfacher lösbar sind Es könnte aber auch so sein, daß 500 Zeilen Assembler 50 Zeilen C entsprechen. Und kleine Projekte auch mit C-Bloat locker in die kleinste HW passen. Und ganz besonders, daß niemand hier vorschreibt, nur noch in C zu programmieren, sonder eher das Umgekehrte passiert. PS: mein erster Versuch einen AVR zu programmieren, war auch in ASM. Hat funktioniert und dann wollte ich das Ganze in C haben, was nicht funktionierte. Nur war ich mir sicher (nach 20 Jahren C und 10 Jahren C++ auf diversem >= PC), daß es möglich sein mußte. Statt Flinte ins Korn werfen, einfach mal durchbeißen und rausfinden was man falsch gemacht hat. Muß man nicht, aber daß andere deshalb nicht dürfen sollen? PPS: Schade daß Moby's letzte Entgleisungen gelöscht wurden. Die hätten dokumentiert, warum Verständnis für seinen Standpunkt nur schwer Aufkommen kann.
:
Bearbeitet durch User
Moby A. schrieb: > Ich denke zum Thema ist hier alles gesagt. Das denk ich auch. Schon lange. Aber sehr wahrscheinlich noch nicht von Jedem... Und auf diese kuriose Art wird dieser Thread locker auch noch die 1000er Marke knacken. Wetten?
:
Bearbeitet durch Moderator
Eddy C. schrieb: > Warum kann man sich hier eigentlich nicht einfach darauf einigen, dass > einfache Projekte (sagen wir bis 500 Zeilen) in Assembler gegebenenfalls > einfacher lösbar sind und komplexere in Hochsprache, z.B. C? Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C. > Der Großteil der Leserschaft wird die "bessere" Programmiersprache aber > anhand von Eigenschaften wie Zeitersparnis, Wartbarkeit, Komplexität, > Fehlerträchtigkeit... beurteilen. Diese Kategorien sind für Moby vollkommen unwichtig. > Moby, las' uns doch einen Blick auf einen Deiner 10000-Zeiler in > Assembler werfen oder nenne zumindest eines, dann können wir darauf > basierend weiterdiskutieren. Das wird er aus Angst, nach seinen eigenen willkürlichen Kriterien besiegt zu werden, natürlich nicht tun.
Sheeva P. schrieb: > Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C. Das ist genauso Unsinn wie Mobys Ideolgie. Ist aber hier trotzdem (oder deswegen) eine angemessene Aussage.
Klaus W. schrieb: > Sheeva P. schrieb: >> Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C. > > Das ist genauso Unsinn wie Mobys Ideolgie. Das glaube ich nicht, Tim. ;-) In Assembler bedarf es genauer Kenntnis der Hardware (zB. byte order) und ihres Befehlssatzes, sowie der Syntax des zu verwendenden Assemblers. Schon für eine schlichte Addition in Assembler muß ich wissen, was es mit Carry-, Sign-, Zero- und Overflow-Flags auf sich hat, aufpassen, daß ich keine unterschiedlichen Datentypen (signed und unsigned) addiere, ... In C nimmt mir das alles mein Compiler ab. Allerdings hänge ich da keiner Ideologie an und bin für sachliche Argumente natürlich jederzeit offen. Wenn Dir also ein Problem einfällt, das sich mit Assembler einfacher lösen läßt als in C: zeig her, und ich widerrufe. ;-)
Carl D. schrieb: > Es könnte aber auch so sein, daß 500 Zeilen Assembler 50 Zeilen C > entsprechen. Und kleine Projekte auch mit C-Bloat locker in die kleinste > HW passen. Ja, absolut richtig! Mit "gegebenenfalls" wollte ich lediglich eine Pauschalisierung verhindern und meinte eine Wahrscheinlichkeit von nicht höher als 5%, wenn die Makros bereitliegen und Copypasta angerichtet ist. Je kleiner das Projekt, umso höher die Wahrscheinlichkeit, dass es komplett in Assembler implementiert wird. Je jünger der Entwickler ("fang' ich doch mal mit Assembler an"), umso höher die Wahrscheinlichkeit, dass er noch nie was anderes programmiert hat. Somit sind gefühlte 50% aller Einsteiger überzeugte Assemblerprogrammierer ("ASM rulez!")
> Somit sind gefühlte 50% aller Einsteiger überzeugte > Assemblerprogrammierer ("ASM rulez!") Früher (Anfang der 80er) waren es bestimmt 100%. Aber nicht aus Überzeugung, sondern aus Mangel an kaufbaren Compilern. [Ironie]Wenn man das Grundlage nimmt, dann ist zu prognostizieren, daß 2050 niemand mehr Assembler benutzen wird. Somit handelt es sich beim Titel dieses Threads nur um ein Aufbäumen vor dem Untergang.[/Ironie]
bit operationen in C sind wirklich nicht so einfach zu realisieren wie in ASM ;)
Moby A. schrieb: > Wolfgang S. schrieb: >> Ich fand lediglich seine Beiträge bis hierhin (weiter habe ich bisher >> nicht gelesen) ausgesprochen ausgewogen und neutral. Erstaunlich, daß >> ausgerechnet das dann offenbar besonders provokant erscheint. > > Wahrheiten die man nicht zur Kenntnis nehmen will können schon sehr > provokant wirken. Mit "seine Beiträge" meinte ich nicht Deine Beiträge, sorry, das hast Du mißverstanden. Ich ärgerte mich nur über den Mob, bei dem einzelne Figuren mindestens so viel missionarischen Eifer zeigen wie Du und, augenscheinlich im Schutz der Masse, auch auf jeden eindreschen, der nicht eifrig mitdrischt. Also z.B. auf Michael K. Allein dies wäre für mich ein Grund, mich von solchen Diskussionen fernzuhalten - sie machen nicht mal Spaß. :( Mit der Einschränkung doch noch kurz was zum Thema. Ich teile das Vergnügen am Herumbosseln auf Instruktionssatzebene an Kleinstsystemen, sehe das aber vorwiegend als eine Art Ausgleichssport. Andere Leute lösen Kreuzworträtsel, spielen Strategiespiele, joggen oder unterhalten sich sonstwie, ohne sich zu rechtfertigen, daß sie nicht den Bus nehmen oder sich vorhalten zu lassen, daß ein Computer das doch sehr viel schneller könnte. Abgesehen hilft es auch, nicht ganz die Bodenhaftung zu verlieren. Auch meine grundsätzliche Einschätzung, daß der Informatik als Fachrichtung die schnelle Weiterentwicklung der Hardware nicht wirklich gut getan hat, daß dadurch viele langfristig wünschenswerte Entwicklungen abgebrochen oder aufgeschoben wurden und daß wir mittelfristig in eine Komplexitätsfalle laufen, führt eher noch weiter weg von der Vorstellung, daß man Prozessoren auf ISP-Ebene händisch programmiert. Das, was Dir hier oft genug vorgehalten wird, daß Compiler besser und vor allem billiger und schneller optimieren können als Menschen, trifft zu, da ginge aber IMHO noch eine Menge mehr.
le x. schrieb: > Indem du also die Nutzung des RAMs verbietest Da er allerdings Interrupts benutzt, benutzt er auch RAM. Ein Polling der Moby-IRQs wurde natürlich auch als Unsinn abgetan. Dabei bliebe damit das RAM wirklich unberührt. Sein "Projekt" ist nach seiner Aussage eine Vorlage für Anfänger. Deswegen hat er den nahezu gleichen Overhead eingebaut, wie es ein C-Compiler tut. Und auch die Interrupts. Dadurch können seine Asm-Schäflein den Code mühelos erweitern. Und der arme Anfänger packt den leeren RAM bis zum Rand voll, dann kommt der erste Moby-Interrupt und zerschiesst ihm seine Daten. Das passiert einem Fortgeschrittenen natürlich nicht. Der braucht aber auch kein Moby-Asm. mfg.
Winfried J. schrieb: > bit operationen in C sind wirklich nicht so einfach zu > realisieren wie in ASM Auf welchen Assembler bzw. Hardware beziehst du dich? In C gibt es immerhin AND, OR, XOR, NOT und bitweise Schiebeoperationen. Auf einem AVR um konstanten Offset zu schieben ohne eine lahmarschige Schleife herzunehmen ist m.E. nicht per se offensichtlich. Insbesondere wenn mehr als 1 Maschinenwort zu behandeln ist. (Was Moby qua "8-Bit MSR ohne Überlauf" ja bereits ausgeschlossen hat). Natürlich gibt es Instruktionen, die von C aus verwendet werden müssen, aber in C nicht beschreibbar sind. Für AVR sind das z.B. SEI, CLI, NOP, WDR, SLEEP, etc. Das ist aber einfach per Inline-Assembler handhabbar. Und das die C-Sprachdesigner die Möglichkeit von (Inline-)Assembler vorgesehen haben, ist keine Schwäche von C, sondern eine Stärke. Zum Glück hatten sie nicht wie manch anderer -- der die Welt gerne in "C-ler" und "ASM-ler" unterteilt (welches Chromosom codiert eigentlich für diese Eigenschaft?) -- "X-ler" Mauern im Kopf.
Sheeva P. schrieb: > sowie der Syntax des zu verwendenden Assemblers Die C-Syntax musst du aber kennen, sonst wird das nix...
Uhu U. schrieb: > Sheeva P. schrieb: >> sowie der Syntax des zu verwendenden Assemblers > > Die C-Syntax musst du aber kennen, sonst wird das nix... Da hat man dann aber was gelernt, was man vom AVR auf x86 mitnehmen kann. Z.B. um bei einem "Hello C-World" nicht völlig zu verzweifeln. Und: Neuem wird immer zunächst mit Skepsis begegnet. Das ist gut, sollte aber nicht zum Dauerzustand werden, sobald das individuelle Kosten/Nutzenverhältnis es zulässt. Nein, das ist nicht von mir. Das ist unser TO zum Thema "muß mein Haus komplett automatisiert sein". Ich schalte mein Licht immer noch selber ein, aber überlasse dem Compiler die Registerbelegung. Ist das nicht krass?
Carl D. schrieb: > Ich schalte mein Licht immer noch selber ein, aber überlasse dem > Compiler die Registerbelegung. Ist das nicht krass? Woaaah! Steinzeit! ICH steuere die Registerbelegung per Smartphone-App!
Sheeva P. schrieb: > Klaus W. schrieb: >> Sheeva P. schrieb: >>> Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C. >> >> Das ist genauso Unsinn wie Mobys Ideolgie. > > Das glaube ich nicht, Tim. ;-) In Assembler bedarf es genauer Kenntnis > der Hardware (zB. byte order) und ihres Befehlssatzes, sowie der Syntax > des zu verwendenden Assemblers. Schon für eine schlichte Addition in > Assembler muß ich wissen, was es mit Carry-, Sign-, Zero- und > Overflow-Flags auf sich hat, aufpassen, daß ich keine unterschiedlichen > Datentypen (signed und unsigned) addiere, ... In C nimmt mir das alles > mein Compiler ab. Das was du jetzt anbringst, mag stimmen. Aber die Ausage "Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C." hat doch damit nichts zu tun und ist unabhängig davon falsch. Wenn es sehr maschinennah wird, ist Assembler natürlich einfacher. Daß das nur bei wenigen Programmen (und wenn bei größeren dann nur in einem kleinen Teil von denen) so ist, steht auf einem anderen Blatt. (Abgesehen davon bin ich kein Tim.)
@Johann L. (gjlayde) Benutzerseite >ICH steuere die Registerbelegung per Smartphone-App! Manchmal muss man alle verfügbaren Register ziehen! https://de.wiktionary.org/wiki/alle_Register_ziehen http://www.evangelisch.de/inhalte/85999/14-07-2013/der-organist-von-notre-dame Die hatten schon anno Tobak deutlich mehr als 100 Register, da gabs noch gar keine CPUs, nicht mal Silizium ;-)
Klaus W. schrieb: > Aber die Ausage "Es gibt kein Problem, das in Assembler einfacher lösbar > wäre als in C." hat doch damit nichts zu tun und ist unabhängig davon > falsch. > > Wenn es sehr maschinennah wird, ist Assembler natürlich einfacher. Mit "add" und "adc" habe ich das doch sogar schon auf der Ebene einzelner Instruktionen gezeigt. Warum sollte meine Aussage also falsch sein? > (Abgesehen davon bin ich kein Tim.) https://de.wikipedia.org/wiki/H%C3%B6r_mal,_wer_da_h%C3%A4mmert#Al_und_Tool_Time
Klaus W. schrieb: > Aber die Ausage "Es gibt kein Problem, das in Assembler einfacher lösbar > wäre als in C." hat doch damit nichts zu tun und ist unabhängig davon > falsch. Kommt drauf an. Wenn man den Prozessor direkt steuern muss, dann kommt man nicht um Assembler herum. Aber zählt das dann noch als eigentliche Programmierung, oder hat das dann nicht eher den Charakter von Steuerbefehlen - anstatt an ein Peripherie-Gerät halt direkt an den Prozessor. Bei allem, was nicht zur direkten Steuerung des Prozessors dient, stimmt die Aussage IMHO. Bin aber offen für ein Gegenbeispiel.
Für die Fähigkeit einen Thread zu kreieren und am Leben zu erhalten der sich seit vielen 100 Beiträgen nur im Keis dreht, sollte Moby einen Preis bekommen. Im Ernst, er bleibt am Ball, kommentiert fast alles was inhaltlich zu kommentieren ist und hält dabei die Provokation permanent aufrecht so daß der Thread wächst und wächst und wächst. Als Kommunikationsexperiment wirklich recht aussergewöhnlich. Inhaltlich ist das natürlich alles nur noch mäßig interessant und relativ ermüdent. Eine gehobene Form des Clickbaiting. Ganz spannend wenn man sich nicht zu sehr von dem belanglosem Thema ablenken lässt um das es vordergründig geht.
Michael K. schrieb: > Für die Fähigkeit einen Thread zu kreieren und am Leben zu erhalten der > sich seit vielen 100 Beiträgen nur im Keis dreht, sollte Moby einen > Preis bekommen. > Im Ernst, er bleibt am Ball, kommentiert fast alles was inhaltlich zu > kommentieren ist und hält dabei die Provokation permanent aufrecht so > daß der Thread wächst und wächst und wächst. Was das angeht, hat Moby seinen Meister noch lange nicht gefunden. Der unangefochtete Bait-König ist zweifellos Kurt. Dessen Bait-fu ist so progrediert, dass es einen schon gruselt. Und ja, ab einem bestimmten Punkt taugen solche Threads nicht mehr zur Wissensvermittlung und weder als Belustigung noch als Ärgernis, sondern nur noch als Psychogramm der jeweiligen Stars.
Johann L. schrieb: > Und ja, ab einem bestimmten Punkt taugen solche Threads nicht mehr zur > Wissensvermittlung und weder als Belustigung noch als Ärgernis, sondern > nur noch als Psychogramm der jeweiligen Stars. In der Tat kratze ich mich seit längerem am Kopf betreffend der Frage, warum ich in so einem Thread eigentlich noch mitdiskutiere. Über weiteste Strecken war er ja weder sachlich noch rhetorisch interessant. Moby hat sachlich keine Argumente und rhetorisch beschränkt er sich auf das konsequente ignorieren oder belächeln von Gegenargumenten.
P. M. schrieb: > Moby hat sachlich keine Argumente und rhetorisch beschränkt er sich auf > das konsequente ignorieren oder belächeln von Gegenargumenten. Nö, er bekommt das Kunststück fertig, sämtliche Gegenargumente für sich als Gewinn zu verbuchen. ;-)
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >> Moby hat sachlich keine Argumente und rhetorisch beschränkt er sich auf >> das konsequente ignorieren oder belächeln von Gegenargumenten. >Nö, er bekommt das Kunststück fertig, sämtliche Gegenargumente für >sich als Gewinn zu verbuchen. ;-) Ein Meister des Jiu Jitsu! https://de.wikipedia.org/wiki/Jiu_Jitsu "Ziel des Jiu Jitsu ist es, einen Angreifer – ungeachtet dessen, ob er bewaffnet ist oder nicht – möglichst effizient unschädlich zu machen. Dies kann durch Schlag-, Tritt-, Stoß-, Wurf-, Hebel- und Würgetechniken geschehen, indem der Angreifer unter Kontrolle gebracht oder kampfunfähig gemacht wird. Dabei soll beim Jiu Jitsu nicht Kraft gegen Kraft aufgewendet werden, sondern – nach dem Prinzip „Siegen durch Nachgeben“ – so viel wie möglich der Kraft des Angreifers gegen ihn selbst verwendet werden." Ein überaus interessantes Konzept! Auch im verbalen Schlagabtausch!
Jörg W. schrieb: > P. M. schrieb: >> Moby hat sachlich keine Argumente und rhetorisch beschränkt er sich auf >> das konsequente ignorieren oder belächeln von Gegenargumenten. > > Nö, er bekommt das Kunststück fertig, sämtliche Gegenargumente für > sich als Gewinn zu verbuchen. ;-) Vielleicht, weil diese Gegenargumente tatsächlich keine sind ? P. M. schrieb: > Moby hat sachlich keine Argumente Für den Ressourcenvorteil von Asm? Genügend. Inklusive Beispiel. Kann man natürlich "konsequent ignorieren" und "belächeln" ;-)
Moby A. schrieb: > P. M. schrieb: >> Moby hat sachlich keine Argumente > > Für den Ressourcenvorteil von Asm? Genügend. Inklusive Beispiel. > Kann man natürlich "konsequent ignorieren" und "belächeln" ;-) Deine Diskussionstechnik nennt man "Bullshitting": Eine Aussage selbst dann immer und immer wieder vorbringen, wenn völlig klar ist, dass sie falsch ist oder nicht begründet werden kann. In der blinden Hoffnung, dass man irgendwann als "Sieger" aus der Diskussion hervor geht, weil man am lautesten/längsten schreit.
P. M. schrieb: > Eine Aussage selbst > dann immer und immer wieder vorbringen, wenn völlig klar ist, dass sie > falsch ist oder nicht begründet werden kann. Dann liefere doch ein kürzeres C-Beispiel! Kannst Du nicht, kann niemand. Ist halt Asm ;-) > Deine Diskussionstechnik nennt man "Bullshitting" Das Wort hatte ich für manchen Beitrag hier auch schon im Sinn ;-)
:
Bearbeitet durch User
Carl D. schrieb: > Schade daß Moby's letzte Entgleisungen gelöscht wurden. Die hätten > dokumentiert, warum Verständnis für seinen Standpunkt nur schwer > Aufkommen kann. Schade Carl, daß Du zum Instrumentarium psychologischer Kriegführung nun auch noch Unwahrheiten hinzufügst. Muß das sein?
le x. schrieb: > Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein > ganz anderer: > Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung > eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man > keinen Krüppel-Code schreiben will), dieser befindet sich traditionell > ebenfalls im RAM. Jetzt schon ;-) > Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne > Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu > gewinnen... Ist das ein Problem von Asm? > *Ich sage bewusst "ohne Klimmzüge". Denn dank den genialen > Compilerbauern ist C heute hinreichend flexibel um Klimmzüge zu > ermöglichen, die einen RAM bei kleinen Projektchen nicht zwingend > vorraussetzen. (Z.B. die Möglichkeit, automatische Variablen in > Registern zu parken) Ach so? Wo bleibt dann die C-Version? "Klimmzüge" sind vielleicht nicht nur für diese nötig ;-)
Moby A. schrieb: > Dann liefere doch ein kürzeres C-Beispiel! Nochmal (ein letztes Mal von mir): solange dein „Anforderungskatalog“ letztlich immer weiter so zurechtgebogen wird, dass er ausschließlich von einer einzigen existierenden Implementierung erfüllt wird(*), dann gibt es da nichts zu vergleichen. Es müsste ja dann jemand in der Lage sein, ein Programm zu schreiben, welches der Compiler exakt 1:1 so umsetzt, wie es jetzt bereits geschehen ist. (Sollte es dabei aus Versehen wirklich kürzer geworden sein, würdest du ja sofort wieder argumentieren, dass das, was der hypothetische Compiler weggelassen hat, ein wesentliches Feature der bestehenden Implementierung gewesen sei. BTDT.) (*) Letztlich liegt dies ja schon in der Aussage begründet, dass einzig die existierende Implementierung die vollständige Beschreibung der „Anforderungen“ wäre. Das ist in dieser Form sinnlos, und jedem anderen Vorschlag, ein Projekt von einer vollständigen (!) (verbalen) Liste der Anforderungen her “from scratch” in beiden Varianten neu anzugehen, stehst du grundsätzlich ablehnend gegenüber. Damit hat sich die Sache doch einfach erledigt: du willst nicht, und alle anderen wollen auch nicht – nicht zu deinen Bedingungen.
Thomas E. schrieb: > Sein "Projekt" ist nach seiner Aussage eine Vorlage für Anfänger. > Deswegen hat er den nahezu gleichen Overhead eingebaut, wie es ein > C-Compiler tut. Und auch die Interrupts. Dadurch können seine > Asm-Schäflein den Code mühelos erweitern. Der pure Anfänger wird sich sicher noch nicht mit dem Erweitern beschäftigen. Es soll aber auch Personen geben, die über dieses Stadium hinaus sind... > Und der arme Anfänger packt den leeren RAM bis zum Rand voll, dann kommt > der erste Moby-Interrupt und zerschiesst ihm seine Daten. ... und sich an meinen freundlichen Hinweis erinnern werden, daß der vorhandene Timer-Interrupt dann seine Register zu sichern hat, wenn Hauptprogramm und weitere Interrupts genutzt werden. > Das passiert einem Fortgeschrittenen natürlich nicht. Der braucht aber > auch kein Moby-Asm. Mir passiert auch vieles nicht, weil ich C nicht verwenden muß ;-)
Moby A. schrieb: > P. M. schrieb: >> Eine Aussage selbst >> dann immer und immer wieder vorbringen, wenn völlig klar ist, dass sie >> falsch ist oder nicht begründet werden kann. > > Dann liefere doch ein kürzeres C-Beispiel! > Kannst Du nicht, kann niemand. Ist halt Asm ;-) Genau das ist Bullshitting: Obwohl die Diskussion dieses Thema mehr als genügend abhandelt, und zwar im Konsens aller Teilnehmer (ausser dir), hast du doch wieder die Frechheit, so zu tun, als hätte noch überhaupt niemand deinen Punkt widerlegen können. Immer in der blinden Hoffnung, durch Ermüdung des Gegners doch noch mit dem letzten Wort als Sieger aus der Diskussion hervorzugehen oder zumindest keinen Gesichtsverlust eingestehen zu müssen.
Moby A. schrieb: > Mir passiert auch vieles nicht, weil ich C nicht verwenden muß ;-) Nicht können ist etwas anderes als nicht müssen.
Jörg W. schrieb: > (*) Letztlich liegt dies ja schon in der Aussage begründet, dass > einzig die existierende Implementierung die vollständige Beschreibung > der „Anforderungen“ wäre. Nett. Dadurch kann Moby-ASM auch keine Fehler anthalten und ist die erste intrinsisch sichere Programmiersprache: Es ist UNMÖGLICH mit Moby-ASM einen Fehler zu machen. Programmierer aller Kontinente, verneigt euch vor Moby!
Jörg W. schrieb: > solange dein „Anforderungskatalog“ > letztlich immer weiter so zurechtgebogen wird, dass er ausschließlich > von einer einzigen existierenden Implementierung erfüllt wird... Nun, zur Güte hatte ich doch längst schon zugestanden, es langt, die beschriebene Programmfunktion = den Output nachzubilden. Aber weißt Du was? Selbst das ist für C zu hoch, wenn Flash/Ram-Bedarf meines Programms getoppt werden soll. Ich bin mir aber nicht nur darüber im Klaren, daß dies für C unmöglich ist sondern denke auch, daß mangels (farbenprächtig dokumentierter) Eingeständnis-Fähigkeit der C-Fraktion hier früher oder später doch wieder Streit um Belanglosigkeiten an den Haaren herbeigezogen wird ;-) Das ist zwar ein Kampf gegen viele Windmühlen hier- freilich, das geb ich ja zu, er macht Spaß! P. M. schrieb: > die Frechheit, so zu tun, ... daß mein Programm nach wie vor die Überlegenheit von Asm dokumentiert! Sooo ein Pech aber auch ;-)
>wenn Flash/Ram-Bedarf meines Programms getoppt werden soll. Das Wichtigste fehlt wieder: Die Entwicklungszeit. Zumindest für alle ausser Dir. >Streit um Belanglosigkeiten an den Haaren herbeigezogen wird ;-) Wie zB die Entwicklungszeit?
Moby A. schrieb: > Nun, zur Güte hatte ich doch längst schon zugestanden, es langt, die > beschriebene Programmfunktion = den Output nachzubilden. Nein, das genügte dir nicht, denn du hast noch Bedingungen an Speicher- oder Registerbenutzung aufgestellt. Auch die Bedingung, dass partout alles in der ISR abgehandelt werden muss, passt nicht zu dieser eben von dir gemachten Aussage: wenn es nur um ein Gerät gänge, welches “plug compatible” ist, muss man nicht solche Bedingungen aufstellen.
Johann L. schrieb: > Programmierer aller Kontinente, verneigt euch vor Moby! Statt lustiger Sprüche stelle lieber Dein Talent unter Beweis! Matthias L. schrieb: > Das Wichtigste fehlt wieder: Die Entwicklungszeit. Zumindest für alle > ausser Dir. Haben wir damit schon die ersehnte Ausrede gefunden? Mir geht darum, was C im Controller zu leisten imstande ist. Entwicklungszeit ist übrigens, zumindest in dieser Größenordnung hier, was höchst Individuelles. Ich sage nur Übung, Vorbereitung, System ;-)
Moby A. schrieb: > Selbst das ist für C zu hoch, wenn Flash/Ram-Bedarf > meines Programms getoppt werden soll. Hast du denn ein Beispiel, wo die von dir angepriesenen Vorteile dergestalt zum tragen kommen, dass es UNMÖGLICH ist, C zu verwenden, ohne dass es MERKLICHE oder INAKZEPTABLE EINBUSSEN DER FUNKTIONALITÄT gibt?
Jörg W. schrieb: > Nein, das genügte dir nicht, denn du hast noch Bedingungen an > Speicher- oder Registerbenutzung aufgestellt. Auch die Bedingung, > dass partout alles in der ISR abgehandelt werden muss, passt nicht > zu dieser eben von dir gemachten Aussage: wenn es nur um ein Gerät > gänge, welches “plug compatible” ist, muss man nicht solche > Bedingungen aufstellen. Hatte ich das nicht eben klargestellt? Liest Du was ich schreibe?
Moby:
> Hatte ich das nicht eben klargestellt?
Doch! Im Läufe der Zeit schon x-mal und mindestens x-1 mal wieder
zurückgenommen. Alle hätten sich hier auf "Fakten" gefreut. Das sind die
Dinge, die "feststehen". "Variable Fakten" gibt es nicht.
:
Bearbeitet durch User
Johann L. schrieb: > Hast du denn ein Beispiel, wo die von dir angepriesenen Vorteile > dergestalt zum tragen kommen, dass es UNMÖGLICH ist, C zu verwenden, > ohne dass es MERKLICHE oder INAKZEPTABLE EINBUSSEN DER FUNKTIONALITÄT > gibt? C zu verwenden ist natürlich genauso unbeschränkt möglich wie den 32-Bitter für die Blinkschaltung... Die Frage ist aber: Gehts nicht noch eine Nummer kleiner und simpler? Das Tandem ASM/AVR macht das sehr oft möglich! Aus meiner persönlichen Abneigung gegen C mache ich hingegen keinen Hehl. Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen, Operatoren und Gültigkeitsbereiche. Darüber könnte ich hier endlos streiten. Also: Unmöglich ist nichts. Nur, wenn man sich schon auf Hochsprachen einlässt muß man sich auch im klaren sein, daß alles seinen Preis hat. Wie schrieb schon der der große c-hater im Beitrag #4361484 ? > Das mußt du begreifen. Mit C läßt du immer Potential der Hardware > brach liegen. Der Fluch der Abstraktionen. Um verschenktes Potential meiner AVRs tut's mir besonders leid ;-)
Moby A. schrieb: > Die Frage ist aber: Gehts nicht noch > eine Nummer kleiner und simpler? Das Tandem ASM/AVR macht das sehr oft > möglich! LEDs kann ich auch mit einem NE555 blinken lassen.
Klaus W. schrieb: > LEDs kann ich auch mit einem NE555 blinken lassen. Hey, da hat einer das Prinzip verstanden!!! Carl D. schrieb: > Doch! Im Läufe der Zeit schon x-mal und mindestens x-1 mal wieder > zurückgenommen. Alle hätten sich hier auf "Fakten" gefreut. Das sind die > Dinge, die "feststehen". "Variable Fakten" gibt es nicht. So, Du wirst mir jetzt erläutern was an Moby A. schrieb: > hatte ich doch längst schon zugestanden, es langt, die > beschriebene Programmfunktion = den Output nachzubilden. noch unklar ist! Das Ganze bitte mit weniger Flash und gleichviel RAM (oder umgekehrt ;-) Auf gehts, Carl D. Zeig mal, daß Du Probleme auch nichtpolemisch lösen kannst ;-)
:
Bearbeitet durch User
Da sich hier die Argumente nur noch seitenlang wiederholen und das Thema längst nichts mehr mit dem ursprünglichen Thema der TIOBE-"Studie" zu tun hat, plädiere ich dafür, diesen Thread zu schließen. Moby-ASM hat nichts mit TIOBE zu tun.
Moby A. schrieb: > Hey, da hat einer das Prinzip verstanden!!! Ich schon, nur du nimmst dafür einen AVR mit ASM!
Klaus W. schrieb: > Ich schon, nur du nimmst dafür einen AVR mit ASM! Nö. Immer das Einfachste! Frank M. schrieb: > plädiere ich dafür, diesen Thread zu schließen. Bin ich gerührt wie sehr Dir meine Threads am Herzen liegen ;-) Im Ergebnis hast Du aber ausnahmsweise recht- rauskommen wird nix mehr. Für die C-Lösung kann mein entsprechender Projekt-Thread genutzt werden. Stimmts, Frank M? ;-)
Moby A. schrieb: > P. M. schrieb: >> die Frechheit, so zu tun, > > ... daß mein Programm nach wie vor die Überlegenheit von Asm > dokumentiert! Und schon wieder: Ohne mit der Wimper zu zucken behauptest du wieder etwas, das im Thread längst widerlegt wurde. Das ist nun wirklich Bullshitting in Reinform und ohne jegliche Hemmungen.
P. M. schrieb: > Ohne mit der Wimper zu zucken behauptest du wieder > etwas, das im Thread längst widerlegt wurde. Ohne mit der Wimper zu zucken behauptest Du etwas, was mangels Gegenbeispiel noch lange nicht widerlegt wurde. Ohne jegliche Hemmungen... Deine Diskussionstechnik nennt man "Bullshitting": Eine Aussage selbst dann immer und immer wieder vorbringen, wenn völlig klar ist, dass sie falsch ist oder nicht begründet werden kann. Leute, Leute, manchmal frag ich mich, wo bin ich hier hingeraten ;-)
:
Bearbeitet durch User
Warum bist Du dann noch hier? Kanns ja ganz flott wieder raus geraten... Die Diskussion ist sowas von sinnfrei, ich bekomme da keinen OrgASM...
Wolfgang R. schrieb: > Warum bist Du dann noch hier? Kanns ja ganz flott wieder raus > geraten... > > Die Diskussion ist sowas von sinnfrei, ich bekomme da keinen OrgASM... Da hast Du recht. Im Augenblick reichts ;-) Schönen Abend noch.
Moby A. schrieb: > ... daß mein Programm nach wie vor die Überlegenheit von Asm > dokumentiert! Daß das nichts als dummes Gelaber ist, hat Yalu bereits eindeutig bewiesen: Beitrag "Re: C versus Assembler->Performance" Assembler ist C also sogar nach Deinen Kriterien klar unterlegen, mehr muß man über Dich, Dein "Können" und Dein "Urteilsvermögen" nicht wissen. Das macht Dein Gelaber so witzig. Bei dem Wetter ist das genauso lustig, aber viel angenehmer als draußen mit Jehovas Zeugen zu, "diskutieren". :-)
Sheeva P. schrieb: > Daß das nichts als dummes Gelaber ist, hat Yalu bereits eindeutig > bewiesen: Schon bemerkenswert. Da wird der Kollege Moby mal so richtig vorgeführt. Nach allen Regeln der Kunst wird sein Code besiegt. Weniger Features, höherer Ressourcenverbrauch, unleserlich und unportabel. Nicht ein, mindestens 2 blaue Augen fängt er sich ein. Und trotzdem fühlt er sich noch immer als Sieger und tut dies überall kund. Das ist mal ein gesundes Selbstbewusstsein ;-)
le x. schrieb: > Das ist mal ein gesundes Selbstbewusstsein ;-) Yep, daran hatte er noch nie einen Mangel. :)
Moby A. schrieb: > Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und > fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für > oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen, > Operatoren und Gültigkeitsbereiche. Darüber könnte ich hier endlos > streiten. Das ist deine Umschreibung dafür, dass du keine Ahnung von C hast. Vor diesem Hintergrund kannst du nicht über die Vor/Nachteile von C vs. Asm dikutieren. Du schiest dich immer öfter selber ab. Merkst du das nicht?
Gu. F. schrieb: > Moby A. schrieb: >> Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und >> fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für >> oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen, >> Operatoren und Gültigkeitsbereiche. Darüber könnte ich hier endlos >> streiten. > > Das ist deine Umschreibung dafür, dass du keine Ahnung von C hast. Es ist ebenfalls seine Umschreibung dafür, dass er noch nie irgendetwas größeres programmiert hat. Das werfe ich ihm nicht vor. Was ich ihm vorwerfe, das ist, dass er dann nicht so tun soll, als ob das alles einfach linear hochskaliert. Denn das tut es nicht, wie jeder der beruflich programmiert aus leidvoller Erfahrung zu berichten weiss. Auf diesem Ohr ist er allerdings taub, wie seine konsequente Weigerung ein etwas größeres Projekt im Vergleich anzugehen, eindeutig beweist.
:
Bearbeitet durch User
Moby A. schrieb: > Aus meiner persönlichen Abneigung gegen C mache ich hingegen keinen > Hehl. > Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und > fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für > oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen, > Operatoren und Gültigkeitsbereiche. Darüber könnte ich hier endlos > streiten. Was ist an
1 | uint8_t meineVariable; |
bitteschön kryptisch? Das Semikolon? Ist doch perfekt: ich teile dem Compiler nur kurz mit, dass ich einen 8-Bit-Signed Wert haben will. Oder einen 16-Bit Unsigned. Oderoderoder... Sonderbehandlungen übernimmt dann immer der Compiler, und zwar an jeder Stelle, an der meineVariable benutzt wird. Toll oder? Bei einem Signed-Wert wird das Vorzeichen berücksichtigt. Bei einem 16-Bit Wert werden 2 Register allokiert und z.B. bei einer Addition nicht nur add, sonder auch adc-Code erzeugt. Sehr bequem. Du, mein lieber Moby, hast in deinem ASM-Code auch Datentypen (OK, zugegeben, du nicht. Du hast nur 8-Bit-Unsigned, alles andere ist viel zu komplex und wird auf dedizierte Hardware ausgelagert. Aber andere ASM-Programmierer kennen Datentypen). Dein Datentyp taucht natürlich nicht im Code auf. Bei dir steht nirgendwo "uint16_t" oder Ähnliches. Du merkst dir den Datentyp im Kopf. Du schleppst ihn also implizit immer mit dir rum, ob du das möchtest oder nicht. Und jedesmal wenn mit einem Register gerechnet werden soll musst du von Neuem entscheiden wie du vorgesht. Ob ein Carry für den Vergleich berücksichtigt werden soll. Ob du mehrere Register allokieren musst.... Und wehe, wehe, der Datentyp ändert sich weil du beim Entwickeln deiner MSR-Applikation feststellst dass der Wertebereich bei der benötigten Auflösung nicht ausreicht... Das das Fehlerträchtig ist hast du bereits kennen lernen dürfen. Da ist mir mein kryptisches
1 | uint8_t meineVariable; |
schon lieber, denn damit ist die Sache gegessen. Nächstes Stichwort: Operatoren Du findest es kryptisch, zwei Variablen mittels "==" vergleichen zu können? Völlig unabhängig vom Datentyp? Wow. Da fällt mir echt nichts mehr ein. Aber wir wissen ja alle hier dass deine Abneigung gegen C, und wahrscheinlich deine Vorliebe für dein AVR-ASM einzig daher rührt dass deine bisherigrn kurzen C-Versuche gescheitert sind. Im Übrigen würde ich dich bitten nie, NIE wieder von MSR-Anwendungen zu faseln. Denn R-Anwendungen sind mit 8-Bit-Unsigned-Arithmetik einfach nicht zu handeln. Richtiges "R" fordert oft anspruchsvolle Mathematik. Bitte benutze also in Zukunft nur noch den Ausdruck "MS-Applikation", schon aus Respekt vor richtigen Regelungstechnikern.
:
Bearbeitet durch User
le x. schrieb: > Dein Datentyp taucht natürlich nicht im Code auf. Bei dir steht > nirgendwo "uint16_t" oder Ähnliches. In der Intel/Microsoft Notation des 8088 Assembler hätte er auch deklarierte Datentypen. Da hängt es von der Deklaration einer Variablen im Speicher ab, ob add mem, 1 eine 8- oder 16-Bit Operation ist. Und wenn es daraus nicht hervorgeht, dann hat man so Schönheiten wie add word ptr [di], 1 an der Backe.
:
Bearbeitet durch User
A. K. schrieb: > In der Intel/Microsoft Notation des 8088 Assembler hätte er auch > deklarierte Datentypen Wobei dieser Assembler für Moby wohl genauso ein Feindbild darstellt wie C oder Hochsprachen generell. Moby mag nur AVR-ASM. Nicht weil es so toll ist, sondern weil es das einzige ist was er kann :-)
:
Bearbeitet durch User
le x. schrieb: > Wobei dieser Assembler für Moby wohl genauso ein Feindbild darstellt Für mich auch. Ich finde diese Intel-Notation schaurig. ;-)
Das müsste eine ziemliche 1:1 Umsetzung des fraglichen Assembler Codes sein. Uns wie man sieht wird hier etwas zu oft mit dem ADC gemessen. Soviel zum Thema Zeit sparen. Und die Checksumme. Na ja. Ist halt ein Alibi einer Checksumme.
1 | if( SIC & 0x30 ) { |
2 | if( SIC & 0x01 ) |
3 | {
|
4 | if( Data & 0x01 ) |
5 | PORTB |= ( 1 << PB0 ); |
6 | else
|
7 | PORTB &= ~( 1 << PB0 ); |
8 | Data >>= 1; |
9 | }
|
10 | PINB |= ( 1 << PB2 ); |
11 | SIC++; |
12 | ADC1 = ADC2 = 0; |
13 | }
|
14 | |
15 | else { |
16 | if( SIC & 0x08 ) |
17 | ADC2 += ADC; |
18 | else
|
19 | ADC1 += ADC; |
20 | |
21 | if( ( SIC & 0x0F ) == 0x0F ) { |
22 | Data = ADC1 / 8 + ( ADC2 / 8 ) << 10; |
23 | |
24 | if( PINB & ( 1 << PB1 ) |
25 | Data |= ( 1 << 20 ); |
26 | if( PINB & ( 1 << PB5 ) |
27 | Data |= ( 1 << 21 ); |
28 | |
29 | CheckSum = ( Data & 0xFF ) + ( ( Data >> 8 ) & 0xFF ) + (( Data >> 16 ) & 0xFF ); |
30 | if( CheckSum & 0x01 ) |
31 | Data |= ( 1 << 22 ); |
32 | if( CheckSum & 0x02 ) |
33 | Data |= ( 1 << 23 ); |
34 | }
|
35 | |
36 | SIC++; |
37 | if( SIC & 0x08 ) |
38 | ADMUX = A2PINREF + 3; |
39 | else
|
40 | ADMUX = A1PINREF + 2; |
41 | }
|
:
Bearbeitet durch User
le x. schrieb: > Dein Datentyp taucht natürlich nicht im Code auf. Bei dir steht > nirgendwo "uint16_t" oder Ähnliches. > Du merkst dir den Datentyp im Kopf. Du schleppst ihn also implizit immer > mit dir rum, ob du das möchtest oder nicht. > Und jedesmal wenn mit einem Register gerechnet werden soll musst du von > Neuem entscheiden wie du vorgesht. > Ob ein Carry für den Vergleich berücksichtigt werden soll. > Ob du mehrere Register allokieren musst.... > Und wehe, wehe, der Datentyp ändert sich weil du beim Entwickeln deiner > MSR-Applikation feststellst dass der Wertebereich bei der benötigten > Auflösung nicht ausreicht... > Das das Fehlerträchtig ist hast du bereits kennen lernen dürfen. Deine Argumente sehe ich jetzt schon damit vom Tisch gewischt. Moby A. schrieb: > Ich sage nur Übung, Vorbereitung, System ;-) Natürlich nicht ohne ein albernes Zwinkern am Satzende.
le x. schrieb: > Was ist an >
1 | > uint8_t meineVariable; |
2 | > |
> bitteschön kryptisch? Das Semikolon? > > Ist doch perfekt: ich teile dem Compiler nur kurz mit, dass ich einen > 8-Bit-Signed Wert haben will. Oder einen 16-Bit Unsigned. > Oderoderoder... Das kannst du doch jemandem nicht vermitteln, der
1 | ldi r16,$e0 |
2 | out ADCSRA,r16 |
für guten Stil hält und nicht versteht, was daran eigentlich das Problem ist, bzw. wie man es behebt obwohl es ihm überhaupt keine Laufzeit kosten würde. > Im Übrigen würde ich dich bitten nie, NIE wieder von MSR-Anwendungen zu > faseln. > Denn R-Anwendungen sind mit 8-Bit-Unsigned-Arithmetik einfach nicht zu > handeln. > Richtiges "R" fordert oft anspruchsvolle Mathematik. > Bitte benutze also in Zukunft nur noch den Ausdruck "MS-Applikation", > schon aus Respekt vor richtigen Regelungstechnikern. Wo kann man die Petition unterschreiben? :-)
Moby A. schrieb: > Mir ist das zu sperrig, zu aufgeblasen, zu umständlich, zu komplex und > fehlerträchtig in seiner Ausdrucksfähigkeit. Viel zu viel Bürokratie für > oft ganz einfache MSR-Tatbestände. Kryptisches Theater um Typen, > Operatoren und Gültigkeitsbereiche. Kryptisch? Stellen wir uns ein kleines C-Programm vor, das vom ADC liest, einen Mittelwert über die letzten 8 Werte bildet und sobald dieser Mittelwert eine bestimmte Schwelle überschreitet, blinkt kurz eine LED und der Mittelwert wird übers UART gesendet. Ich bin nicht mehr so fit in AVR-Registern, deshalb verwende ich symbolisch erfundene Register, was aber keinen Unterschied macht:
1 | void main(){ |
2 | |
3 | uint8_t threshold = 89; |
4 | |
5 | uint8_t value_ptr = 0; |
6 | uint8_t last_values[8] = {0, 0, 0, 0, 0, 0, 0, 0}; |
7 | |
8 | ADC_CONFIG |= (1 << ADC_ON); |
9 | UART_CONFIG = ...; // set some bits here |
10 | |
11 | |
12 | while(true){ |
13 | if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){ |
14 | |
15 | // save value into ringbuffer
|
16 | last_values[value_ptr] = ADC_VALUE; |
17 | |
18 | // increase ringbuffer pointer
|
19 | value_ptr ++; |
20 | value_ptr = (value_ptr < 5) ? value_ptr : 0; |
21 | |
22 | // sum up values in ringbuffer
|
23 | uint16_t sum = 0; |
24 | for(uint8_t i = 0; i < 8; i ++){ |
25 | sum += last_values[i]; |
26 | }
|
27 | |
28 | // check if average in ringbuffer exceeds threshold
|
29 | // if yes, send over uart
|
30 | if(sum / 8 > threshold){ |
31 | UART_DATA = sum / 8; |
32 | UART_CONFIG |= (1 << UART_DO_SEND); |
33 | }
|
34 | |
35 | }
|
36 | }
|
37 | }
|
Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code umwandeln?
:
Bearbeitet durch User
P. M. schrieb: > Kryptisch? Stellen wir uns ein kleines C-Programm vor, das vom ADC > liest, einen Mittelwert über die letzten 8 Werte bildet und sobald > dieser Mittelwert eine bestimmte Schwelle überschreitet, blinkt kurz > eine LED und der Mittelwert wird übers UART gesendet. > Könntest du das jetzt bitte mal in kurzen, kompakten, übersichtlichen > Assembler-Code umwandeln? Vermutlich ist da zu viel Mathematik drin, daher wird Moby das Angebot nicht wahrnehmen wollen ;-)
:
Bearbeitet durch User
Wegstaben V. schrieb: > Vermutlich ist da zu viel Mathematik drin, daher wird Moby das Angebot > nicht wahrnehmen wollen ;-) Vergleiche jenseits von 8 Bits sind nicht seine starke Seite: if(sum / 8 > threshold){
P. M. schrieb: > value_ptr = (value_ptr < 5) ? value_ptr : 0; warum 5? wäre nicht
1 | value_ptr %= 8; |
einfacher?
Wegstaben V. schrieb: > Vermutlich ist da zu viel Mathematik drin, daher wird Moby das Angebot > nicht wahrnehmen wollen ;-) Er wartet noch auf die Controler-Version mit dem AVR-Befehl. AVR wie average. Nur so ist das kompakt lösbar.
Witkatz :. schrieb: > P. M. schrieb: >> value_ptr = (value_ptr < 5) ? value_ptr : 0; > > warum 5? > wäre nicht
1 | value_ptr %= 8; |
einfacher? Tippfehler, sorry.
Korrigierte Aufgabenstellung für Moby:
1 | void main(){ |
2 | |
3 | uint8_t threshold = 89; |
4 | |
5 | uint8_t value_ptr = 0; |
6 | uint8_t last_values[8] = {0, 0, 0, 0, 0, 0, 0, 0}; |
7 | |
8 | ADC_CONFIG |= (1 << ADC_ON); |
9 | UART_CONFIG = ...; // set some bits here |
10 | |
11 | |
12 | while(true){ |
13 | if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){ |
14 | |
15 | // save value into ringbuffer
|
16 | last_values[value_ptr] = ADC_VALUE; |
17 | |
18 | // increase ringbuffer pointer
|
19 | value_ptr ++; |
20 | value_ptr %= 8; |
21 | |
22 | // sum up values in ringbuffer
|
23 | uint16_t sum = 0; |
24 | for(uint8_t i = 0; i < 8; i ++){ |
25 | sum += last_values[i]; |
26 | }
|
27 | |
28 | // check if average in ringbuffer exceeds threshold
|
29 | // if yes, send over uart
|
30 | if(sum / 8 > threshold){ |
31 | UART_DATA = sum / 8; |
32 | UART_CONFIG |= (1 << UART_DO_SEND); |
33 | }
|
34 | |
35 | }
|
36 | }
|
37 | }
|
Wegstaben V. schrieb: > Vermutlich ist da zu viel Mathematik drin, daher wird Moby das Angebot > nicht wahrnehmen wollen ;-) Vermutlich eher keine typische 8-bit MSR Anwendung...
P. M. schrieb: > Korrigierte Aufgabenstellung für Moby: Ich glaube nicht dass da was draus wird, wegen ... Moby A. schrieb: > P. M. schrieb: > >> C:template <class T> >> T max(T a, T b){ >> return (a > b) ? a : b; >> } > > Das ist kryptischer Kauderwelsch für Eingeweihte. > Dessen Studium ist für 8-Bit MSR überflüssig ;-)
P. M. schrieb: > value_ptr %= 8; Sorry, ich bin immer noch bei PIC ;-) hab gerade ausprobiert was der sehr schwach optimierende XC8 (free mode) aus der zitierten Zeile macht:
1 | 0x7FF8: MOVLW 0x7 |
2 | 0x7FFA: ANDWF __pcstackCOMRAM, F, ACCESS |
Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss man als Assemblist erst mal kommen.
Witkatz :. schrieb: > Auf den Trick muss man als Assemblist erst mal kommen. Assemblerprogrammierer kennen keinen Modulus, die kennen nur AND und Bitmasken. ;-)
Witkatz :. schrieb: > Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss > man als Assemblist erst mal kommen. Ja, Aber nur weil x % 2^n = x & 2^n-1 ist.
Witkatz :. schrieb: > P. M. schrieb: >> value_ptr %= 8; > Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss > man als Assemblist erst mal kommen. Wieso? Das machen Compiler schon seit Jahrzehnten, wenn sie eine Zweierpotenz erkennen. Modulo 8 ist nichts als der Rest einer Division durch 8. Eine Division durch 8 entspricht Schieben um 3 Stellen, damit entspricht Modulo 8 einer Maskierung der letzten 3 Stellen. Man hätte also auch schreiben können:
1 | value_ptr &= 0x07; |
Nichts anderes hat der Compiler in Assembler hingeschrieben.
Witkatz :. schrieb: > Wow, zwei Assemblerbefehle für eine Modulo Operation. Auf den Trick muss > man als Assemblist erst mal kommen. Triviale Grundübung. Interessant wirds erst mit Vorzeichen.
Frank M. schrieb: > Modulo 8 ist nichts als der Rest einer Division durch 8. Eine Division > durch 8 entspricht Schieben um 3 Stellen, damit entspricht Modulo 8 > einer Maskierung der letzten 3 Stellen. Aber nur ohne Vorzeichen.
A. K. schrieb: > Aber nur ohne Vorzeichen. Ja, natürlich. P.S. Genialer als diese Modulo-Sache finde ich übrigens, wie der gcc eine Multiplikation mit 80 löst (auf welchem Prozessor ich das gesehen habe, weiß ich nicht mehr, ist über 20 Jahre her):
1 | y = x * 80 |
2 | <==> y = x * (64 + 16) |
3 | <==> y = x * 64 + x * 16 |
4 | <==> y = (x << 6) + (x << 4) |
Der Compiler zerlegt die Zahl also in Zweierpotenzen und addiert einfach die jeweiligen geschobenen Ergebnisse. Sowas lohnt sich aber nur auf Prozessoren, die von Haus aus nicht multiplizieren können.
:
Bearbeitet durch Moderator
A. K. schrieb: > Aber nur ohne Vorzeichen. Mit "Übung, Vorbereitung und System" braucht man ohnehin keine Vorzeichen :-D
Frank M. schrieb: > Der Compiler zerlegt die Zahl also in Zweierpotenzen und addiert einfach > die jeweiligen geschobenen Ergebnisse. Sowas lohnt sich aber nur auf > Prozessoren, die von Haus aus nicht multiplizieren können. Zumindest nicht kombinatorisch. Bei Prozessoren mit per Sequencer oder Microcode implementierter Multiplikation lohnt sich das schon. Das gehört zu jenen Optimierungen, die einem Asm-Programmierer recht viel Arbeit machen - und mit jeder Änderung der Konstanten komplett neu. Die fortgeschrittene Version verwendet übrigens nicht nur Additionen sondern auch Subtraktionen.
>Mit "Übung, Vorbereitung und System" braucht man ohnehin keine >Vorzeichen :-D ASM (selbst) kennt kein Vorzeichen. Somit existiert das Problem "Vorzeichen" nur in den kryptischen, aufgeblasenen Hochsprachen. ;-)
Chris B. schrieb: > Mit "Übung, Vorbereitung und System" braucht man ohnehin keine > Vorzeichen :-D Moby rechnet Temperaturen vermutlich in Fahrenheit. Das reicht von Saukalt bis Kaffee in 8 Bits ohne Vorzeichen.
Frank M. schrieb: > Wieso? Das machen Compiler schon seit Jahrzehnten, wenn sie eine > Zweierpotenz erkennen. Ich find's nur gut, dass die Compiler solche Gesetzmäßigkeiten erkennen und entspr. optimieren. Frank M. schrieb: > Man hätte also auch schreiben können: value_ptr &= 0x07; Ist zwar formal richtig, aber die Modulooperation gehört zu Ringbufferhandling dazu - die Verundung verschlechter die Lesbarkeit. Lieber würde ich die 8 durch eine symbolische Konstante ersetzen. Dann muss ich nur ein #define anpassen und schon ist der MovingAverageFilter angepasst. Der Compiler macht den mühsamen Rest...
Witkatz :. schrieb: > Lieber würde ich die 8 durch eine symbolische Konstante ersetzen. Ja, das ist in dem Beispiel ungünstig. Das müsste im Code zB sizeof sein. Aber ich wollte das 8 => 19 dann als Erweiterung vorschlagen, damit Moby alles neu schreiben darf.
A. K. schrieb: > Das > gehört zu jenen Optimierungen, die einem Asm-Programmierer recht viel > Arbeit machen - und mit jeder Änderung der Konstanten komplett neu. Eben: Während der C-Programmierer einfach
1 | #define COLS_PER_ROW 80
|
durch
1 | #define COLS_PER_ROW 132
|
ersetzt, muss der Assembler-Programmierer die komplette Plutimikation neu schreiben. > Die fortgeschrittene Version verwendet übrigens nicht nur > Additionen sondern auch Subtraktionen. Hehe :-) Witkatz :. schrieb: > Lieber würde ich die 8 durch eine symbolische Konstante ersetzen. Dann > muss ich nur ein #define anpassen und schon ist der MovingAverageFilter > angepasst. Der Compiler macht den mühsamen Rest... Ja, siehe oben.
Matthias L. schrieb: > ASM (selbst) kennt kein Vorzeichen. Die meisten schon. Eigentlich müsste Intels 8048 sein Ideal sein, denn da gibts weder Vorzeichenabfrage noch Overflow-Flag. Schon der 8051 fällt aufgrund des fatalen Overflow-Flags aus. Auch RCA 1802 kommt aus dem gleichen Grund diesem Ideal nahe, scheitert aber angesichts von 16 16-Bit Registern für die Adressierung an der kaum vermeidbaren Notwendigkeit zur byteweisen 16-Bit Rechnung bei Adressen.
:
Bearbeitet durch User
Frank M. schrieb: > Eben: Während der C-Programmierer einfach > #define COLS_PER_ROW 80 > durch > #define COLS_PER_ROW 132 > > ersetzt, oder einfach die komplette MovinAvg geschichte durch z.B. AdcSmooth = (AdcSmooth * 7 + ADC_VALUE) / 8; und schwupsdiwups probiert er einen anderen Filter mal eben aus ;-)
:
Bearbeitet durch User
Die Frage ist allerdings eher, ob Moby das trivial Optimierungspotential erkennt, das in dieser Funktion noch vorhanden ist.
Hmm, lange kanns ja jetzt nicht mehr bis zum großen Gegenschlag dauern...
Karl H. schrieb: > ob Moby das trivial Optimierungspotential erkennt Wieso? Ich dachte, dass einfache Digitalfilter zu einfacher MSR dazu gehören, oder etwa nicht?
Ich bin echt gespannt, wie sich Moby dieses Mal herausredet. Das Beispiel ist nun wirklich einfachst und perfekt geeignet, um die Überlegenheit von Assembler zu demonstrieren.
Witkatz :. schrieb: > oder einfach die komplette MovinAvg geschichte durch z.B. > AdcSmooth = (AdcSmooth * 7 + ADC_VALUE) / 8; > und schwupsdiwups probiert er einen anderen Filter mal eben aus ;-)
1 | ld a, (adcsmooth) |
2 | ld b, a |
3 | add a |
4 | ld c, a |
5 | add a |
6 | add b |
7 | add c |
8 | ld hl, adc_value |
9 | ld b, (hl) |
10 | add b |
11 | and a |
12 | rr a |
13 | and a |
14 | rr a |
15 | ld (adcsmooth), a |
Ist doch ganz einfach, und sofort klar und verständlich. :-)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Ist doch ganz einfach, Sorry, eine kleine 'kosmetische' Änderung ;-)
1 | float AdcSmooth = (AdcSmooth * 7 + value_ptr) / 8; |
Jörg W. schrieb: >
1 | > ld a, (adcsmooth) |
2 | > [...] |
3 | > ld (adcsmooth), a |
4 | > |
> > Ist doch ganz einfach, und sofort klar und verständlich. :-) Geradezu selbstdokumentierend :-)
Frank M. schrieb: > Geradezu selbstdokumentierend :-) Aber sicher. Manche Maschinen besitzen keine Befehle für Laden/Speichern von Datenworten - ja, auch heute noch! Also weder solche Befehle, noch als implizite Speicheroperanden von Datenbefehlen. Da wird es schon interessant, überhaupt die Speicherzugriffe zu finden, denn die gibt es natürlich trotzdem.
Witkatz :. schrieb: > Karl H. schrieb: >> ob Moby das trivial Optimierungspotential erkennt > > Wieso? Ich dachte, dass einfache Digitalfilter zu einfacher MSR dazu > gehören, oder etwa nicht? Natürlich. Aber dein Originalcode hat noch Potential. In C trivial zu ändern. (Nein, ich sag jetzt noch nicht wie. Aber es hat mit der Summe zu tun. Denk mal über S-= Wert; S += Wert; nach)
:
Bearbeitet durch User
le x. schrieb: > Im Übrigen würde ich dich bitten nie, NIE wieder von MSR-Anwendungen zu > faseln. > Denn R-Anwendungen sind mit 8-Bit-Unsigned-Arithmetik einfach nicht zu > handeln. > Richtiges "R" fordert oft anspruchsvolle Mathematik. > Bitte benutze also in Zukunft nur noch den Ausdruck "MS-Applikation", > schon aus Respekt vor richtigen Regelungstechnikern. Karl H. schrieb: > Wo kann man die Petition unterschreiben? Damit tut ihr ihm wirklich Unrecht. Selbstverständlich sind seine Anwendungen MSR-Anwendungen. Das gilt für alle seine Anwendungen. Ihr befindet euch in einem grossen Irrtum. Denn MSR steht nicht für das, wovon ihr glaubt, wofür es steht. MSR heisst: M oby S part R AM mfg.
Jörg W. schrieb:
...
Oder so:1 | lda adcsmooth |
2 | mov b, a |
3 | add a |
4 | mov c, a |
5 | add a |
6 | add b |
7 | add c |
8 | lxi h, adc_value |
9 | mov b, m |
10 | add b |
11 | and a |
12 | rar a |
13 | and a |
14 | rar a |
15 | sta adcsmooth |
:
Bearbeitet durch User
Karl H. schrieb: > Aber dein Originalcode hat noch Potential. > In C trivial zu ändern. meinst du etwa
1 | int16_t AdcSmooth = (AdcSmooth * 8 - AdcSmooth + ADC_VALUE) / 8; |
:
Bearbeitet durch User
Witkatz :. schrieb: > meinst du etwa >
1 | int16_t AdcSmooth = (AdcSmooth * 8 - AdcSmooth + ADC_VALUE) / |
2 | > 8.0; |
Nein, er meint das:
1 | for(uint8_t i = 0; i < 8; i ++){ |
2 | sum += last_values[i]; |
3 | }
|
Statt immer wieder 7 + 1 = 8 Summen auszurechnen, kannst Du auch einmal die älteste abziehen.
A. K. schrieb: > Oder so: Als Ossi bin ich mit der 8080-Mnemonik nie warm geworden. ;) Die Einleitung müsste auch gehen als:
1 | ld b, a |
2 | add a |
3 | add a |
4 | add a |
5 | sub b |
Ein Befehl weniger, richtig gespart. :-))
Hmm Irgendwie kann ich hier
1 | and a |
2 | rr a |
3 | and a |
4 | rr a |
die Division durch 8 noch nicht erkennen. m.M. nach ist das bisherige eine Division durch 4.
Mensch, Karl Heinz, das war doch die Sollbruchstelle für Mobi. :-) Nee, hatte ich natürlich vergessen, hast recht.
Jörg W. schrieb: > Mensch, Karl Heinz, das war doch die Sollbruchstelle für Mobi. :-) > > Nee, hatte ich natürlich vergessen, hast recht. :-) Da lob ich mir halt C. Da schreibe ich / 8 und der Compiler kümmert sich drum, wie oft verschoben werden muss. Am Anfang hat mich ja auch dein AND verunsichert, bis ich erkannte warum. Allerdings könntest du da auch 2 mal ein AND einsparen :-) Macht sicherlich jeder Compiler problemlos. Nur wenn man es händisch macht, muss man sich darum kümmern. Aber gottlob ist mein 8080 Assembler noch nicht so eingerostet, dass ich es nicht hätte lesen können.
:
Bearbeitet durch User
Karl H. schrieb: > Allerdings könntest du da auch 2 mal ein AND einsparen :-) Nö, beim Rotieren nach rechts wird ja das Carry-Flag wieder befüllt, man muss es daher wieder löschen. > Aber gottlob ist mein 8080 Assembler noch nicht so eingerostet, dass ich > es nicht hätte lesen können. Sach ich doch, klarer, schöner und völlig selbsterklärender Assembler-Code. Es gibt nichts besseres. :-))
Jörg W. schrieb: > Karl H. schrieb: >> Allerdings könntest du da auch 2 mal ein AND einsparen :-) > > Nö, beim Rotieren nach rechts wird ja das Carry-Flag wieder befüllt, > man muss es daher wieder löschen. Aber du weisst wo die 2 (äh 3) Bits im Akku landen und kannst sie hinterher ausmaskieren, sollte da tatsächlich eine 1 aus dem Carry reingekommen sein.
Karl H. schrieb: > Aber du weisst wo die 2 (äh 3) Bits im Akku landen und kannst sie > hinterher ausmaskieren, sollte da tatsächlich eine 1 aus dem Carry > reingekommen sein. Ah, OK. :)
Jörg W. schrieb: > Karl H. schrieb: >> Aber du weisst wo die 2 (äh 3) Bits im Akku landen und kannst sie >> hinterher ausmaskieren, sollte da tatsächlich eine 1 aus dem Carry >> reingekommen sein. > > Ah, OK. :) Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, die jeder Compiler problemlos optimal hinkriegt :-)
Karl H. schrieb: > Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, die > jeder Compiler problemlos optimal hinkriegt :-) .. in einer Zeit, die kürzer ist als der Mausklick auf "Kompilieren"
Karl H. schrieb: > Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, die > jeder Compiler problemlos optimal hinkriegt :-) Ach was! Noch ein weiteres Byte eingespart, das zählt!
Jörg W. schrieb: > Karl H. schrieb: >> Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, die >> jeder Compiler problemlos optimal hinkriegt :-) > > Ach was! Noch ein weiteres Byte eingespart, das zählt! Na das ist doch ein Argument mit dem dein Chef punkten kann, wenn er dem Kunden die Arbeitszeit verrechnet :-)
Frank M. schrieb: > Statt immer wieder 7 + 1 = 8 Summen auszurechnen, kannst Du auch einmal > die älteste abziehen. Achso, P.M.'s Gleitender Mittelwert war gemeint. Also etwa so?
1 | AdcSum += ADC_VALUE; |
2 | if(value_cnt == 8){ |
3 | AdcSum -= AdcLastValue; |
4 | AdcMovingAvg = AdcSum / 8; |
5 | } else value_cnt++; |
6 | AdcLastValue = ADC_VALUE; |
Müsste RAM und zeitsparend sein im Vergleich zu der FOR Schleife mit dem Altwertevektor.
Witkatz :. schrieb: > Frank M. schrieb: >> Statt immer wieder 7 + 1 = 8 Summen auszurechnen, kannst Du auch einmal >> die älteste abziehen. > > Achso, P.M.'s Gleitender Mittelwert war gemeint. >
1 | AdcSum += ADC_VALUE; |
2 | > if(value_cnt == 8){ |
3 | > AdcSum -= AdcLastValue; |
4 | > AdcMovingAvg = AdcSum / 8; |
5 | > } else value_cnt++; |
6 | > AdcLastValue = ADC_VALUE; |
Nein. So
1 | while(true){ |
2 | if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){ |
3 | |
4 | // remove oldest value from sum
|
5 | sum -= last_values[value_ptr]; |
6 | |
7 | // save value into ringbuffer
|
8 | // and add it to sum
|
9 | last_values[value_ptr] = ADC_VALUE; |
10 | sum += last_values[value_ptr]; |
11 | |
12 | // increase ringbuffer pointer
|
13 | value_ptr ++; |
14 | value_ptr %= 8; |
15 | |
16 | // check if average in ringbuffer exceeds threshold
|
17 | // if yes, send over uart
|
18 | if(sum / 8 > threshold){ |
19 | UART_DATA = sum / 8; |
20 | UART_CONFIG |= (1 << UART_DO_SEND); |
21 | }
|
wozu hast du denn das Array mit den letzten Werten? Der gerade zu überschreibende Wert ist der jeweils älteste. Den nimmst du aus der Summe raus und addierst den neuen dafür dazu. Auf die Art bleibt die Summe immer ganz von alleine up to date ohne dass du jedesmal alle Werte im Ringbuffer erneut aufsummieren musst.
:
Bearbeitet durch User
>Achso, P.M.'s Gleitender Mittelwert war gemeint. Also etwa so?
Ich würds etwa so machen:
1 | //-- ältesten Wert entfernen -------------------
|
2 | AdcSum -= Buffer[BufIdx]; |
3 | |
4 | //-- neuen Wert in Puffer ----------------------
|
5 | Buffer[BufIdx] = NewVal; |
6 | |
7 | //-- neuen Wert zur Summe ----------------------
|
8 | AdcSum += Buffer[BufIdx]; |
9 | |
10 | //-- Idx weiterrücken --------------------------
|
11 | BufIdx += 1; |
12 | BufIdx %= BUFLEN; |
13 | |
14 | //-- Mittelwert berechnen ----------------------
|
15 | AdcMovingAvg = AdcSum / BUFLEN; |
Das ignoriert das Befüllen. Aber dann "schwingt" sich das eben während
der ersten BUFLEN Elemente ein...
Denn dieses if:
>>if(value_cnt == 8){
ist ja nur für den Befüllvorgang nicht erfüllt.
Karl H. schrieb: > Nein. > So ... Ach ja sorry, mein Denkfehler. Man muss natürlich den ältesten Wert subtrahieren.
Karl H. schrieb: > Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, Dann bastel doch am GCC. Die sicherste Möglichkeit, dass der von dir designte Assembler-Code nicht nutzlos verraucht, sondern x-fach bei anderen verwendet wird :-)
Witkatz :. schrieb: > Karl H. schrieb: >> Nein. >> So ... > Ach ja sorry, mein Denkfehler. Man muss natürlich den ältesten Wert > subtrahieren. Das sind Optimierungen, die wirklich was bringen. Ok, bei 8 Werten ist das jetzt nicht so toll, aber bei 1024 Werten macht das schon was aus. Nur leider ist es eben keine Optimierung bei der man 1 oder 2 Befehle einspart und damit nichts für "in Assembler - auch noch den letzten Taktzyklus an einer Stelle suchen bei der es völlig uninteressant ist" Programmierer.
Die auf mein einfaches Beispiel folgende Diskussion zeigt noch einen weiteren interessanten Aspekt: Moby's "Vorbereitung und Planung" kann man im echten Leben knicken. Bereits das simple Beispiel wirft verschiedene Verbesserungs- und Modifikationsmöglichkeiten auf. Eine Programmiersprache, worin sicher und übersichtlich Änderungen gemacht werden können, ist somit eine Grundvoraussetzung und nicht ein nice-to-have für jede höhere Software-Entwicklung.
Johann L. schrieb: >> Und schon hat man eine halbe Stunde an einer Codesequenz verbraten, > > Dann bastel doch am GCC. Für den Z80? ;-)
Jörg W. schrieb: >> Dann bastel doch am GCC. > > Für den Z80? ;-) Wieso nicht? Für den 68HC11 gibts ihn doch auch.
:
Bearbeitet durch User
Wow, unsere Mods leben ja richtig auf. So ein Mobythread sollte öfter gestartet werden, das ist gut für eure Seele :-)
So langsam wäre es an der Zeit, dass der Star des Threads sich mit einem überzeugend einfachen Assembler-Beispiel für die obige Aufgabenstellung melden würde. Moby, wo bist du?
Gu. F. schrieb: > Wow, unsere Mods leben ja richtig auf. > So ein Mobythread sollte öfter gestartet werden, das ist gut für eure > Seele :-) Und wem haben wir das zu verdanken ? Richtig, dem Moby. Hätte der frühzeitig aufgegeben als es eklig und persönlich wurde, dann wären wir nie soweit gekommen. Der Vergleich einer realen Implementierung mit Mobys (noch zu erbringendem) ASM code steht natürlich noch aus. Aber Hut ab, das war richig gute und informative Unterhaltung bis hierhin. Über weite Strecken schien der Thread toter als tot zu sein nur um dann noch mal richtig aufzudrehen.
Karl H. schrieb: > Es ist ebenfalls seine Umschreibung dafür, dass er noch nie irgendetwas > größeres programmiert hat. Das werfe ich ihm nicht vor. Was ich ihm > vorwerfe, das ist, dass er dann nicht so tun soll, als ob das alles > einfach linear hochskaliert. Aus einer falschen Unterstellung folgerst du einen falschen Vorwurf. In einigen KB Asm-Code lässt sich ja durchaus schon was 'größeres' unterbringen. Dir waren für ein 'größeres' (C-) Projekt natürlich andere KB-Größen im Sinn ;-) 'Linear hochskaliert' ist auch so ein netter Begriff. Stoff genug für eine Doktor-Arbeit und noch mehr feinsinnigem Streit. Ich behaupte, mit entsprechend Übung, Vorbereitung und System ist der Codehimmel offen und weit... Die Grenzen setzen irgendwann Berechnungen und das Handling großer Datenmengen. Oder übermäßig komplexe Hardware! > beruflich programmiert aus leidvoller Erfahrung zu berichten weiss. > Auf diesem Ohr ist er allerdings taub, Durchaus nicht. Hatte ich auch schon öfter gesagt. Allerdings frage ich mich, warum das, was bei mir und anderen Asm-Programmierern funktioniert, nicht öfter zum Einsatz kommt. Obwohl, lt. Tiobe tut es das ja schon ;-) le x. schrieb: > Nach allen Regeln der Kunst wird sein Code besiegt. Nennt man das nicht Wunschdenken ? Michael K. schrieb: > Der Vergleich einer realen Implementierung mit Mobys (noch zu > erbringendem) ASM code steht natürlich noch aus. So und nicht anders schauts für mein Projekt aus. Zu erbringen hab ich dafür nix mehr. Bleibe am Ball. Das ist freilich bei sovielen netten, tiefgründigen Antworten für einen Einzelkämpfer für Asm hier zeitlich schwer zu stemmen, aber ich bemühe mich.
:
Bearbeitet durch User
Moby A. schrieb: > Die Grenzen setzen irgendwann Berechnungen > und das Handling großer Datenmengen. warum eigentlich? nur bei dir oder generell..? weil früher™ ging mathe noch : http://avr-asm.tripod.com/float128.html http://avr-asm.tripod.com/math32x.html usw. (achtung bei der der Website wird man irgendwie komisch weitergeleitet..) den moving avg hätten wird dann auch gleich gefunden: http://avr-asm.tripod.com/avr222.html natürlich "zufällig" über 8 Werte ;-) (siehst du ich kann auch smilys) >großer Datenmengen auch komisch, früher™ hat man GENAU DORT ASM verwendet.. (Bildbearbeitung usw.) aber auch für "MSR": z.b. messwerte archivieren auf speicherkarte: http://avr-asm.tripod.com/flashcard.html
:
Bearbeitet durch User
Robert L. schrieb: > auch komisch, früher™ hat man GENAU DORT ASM verwendet.. > (Bildbearbeitung usw.) Und noch früher hatte man den Opcode auf Formularen selbst ausgerechnet. Aber wir warten noch auf deine hochoptimierte Implementierung des gleitenden Mittelwerts. Meine hast du ja nun schließlich …
>Aber wir warten noch auf deine hochoptimierte
wer auch immer jetzt "deine" ist
aber ich hab ja freundlicherweise eine ASM version für Moby gepostet..
IMHO zeigt der Verlgeich der ASM und C Version recht schön die nachteil
der ASM Version auf..
ob es auch Vorteile der ASM version gibt, kann man jetzt schwer sagen:
dazu müsste IMHO jemand das Ergebnis des C-Programm durch eine de-asm
schicken..
:
Bearbeitet durch User
Damit ein Vergleich wirklich ehrlich wird, müsste es eine Aufgabenstellung geben, die GENAU spezifiziert, was gemacht werden muss. Ob dabei Ram "verbraucht" wird oder nicht, etc. Danach fangen ein C und ein ASM Programmierer mit der Implementation an und wer zuerst fertig wird, stellt seinen ASM Code hier in eine verschlüsselte .zip Datei rein. Wenn der zweite Programmierer fertig wird, veröffentlicht er seinen Code und der erste veröffentlicht das Passwort für seine ASM Datei. Aber dann wäre das hier ja zu Ende...
das ist sinnlos, wir kenne doch schon alle seine Ausreden, warum er die ASM version dazu nicht abliefern würde...
Operator S. schrieb: > Damit ein Vergleich wirklich ehrlich wird, müsste es eine > Aufgabenstellung geben, die GENAU spezifiziert, was gemacht werden muss. > Ob dabei Ram "verbraucht" wird oder nicht, etc. > > Danach fangen ein C und ein ASM Programmierer mit der Implementation an Das hat Karl Heinz bereits in einem anderen Thread vorgeschlagen: Beitrag "C versus Assembler->Performance" Ein paar Auszüge aus dem Thread: Karl H. schrieb: > Wir vereinbaren einen Zeitpunkt an dem du und ich Zeit haben. Ein paar > Forneteilnehmer denken sich eine Aufgabe aus, irgendjemand (du, ich, wir > beide) wählt eine der Aufgaben aus und dann schaun wir mal, wer > schneller das Programm stehen hat und wer es fehlerfreier hinkriegt. > > Ich hab nur eine Bedingung: es darf kein Pipifax Beispiel sein sondern > sollte schon was ordentliches sein. Es gab in dem Thread auch schon Vorschläge, wie diese Aufgabe aussehen könnte. Aber: Karl H. schrieb: > Aber erst mal muss er den Fehdehandschuh aufgreifen. Mal sehen, obs so > kommt wie es immer kommt, wenn ich sowas anbiete :-) Moby A. schrieb: > Den greife ich natürlich nicht auf, weil ich für solche Späße keine Zeit > investiere. Natürlich hat er dafür keine Zeit, da er diese stattdessen in das Schreiben seiner Beiträge hier steckt. Davon gibt es in diesem Thread und den beiden früheren C-vs-Assembler-Threads¹ immerhin schon 551. Schreibt er jeden Beitrag im Mittel in 5 Minuten², sind das in Summe 46 Stunden, also deutlich mehr als eine Arbeitswoche! Selbst ein nur mittelmäßiger C-Programmierer bräuchte nur einen kleinen Bruchteil dieser Zeit, um die vorgeschlagenenen Aufgaben umzusetzen. Das Ganze allerdings in Assembler zu programmieren, und zwar so, dass die Laufzeit- und Speichereffizienz mit dem C-Programm von Karl Heinz mithalten kann, dürfte eine ziemliche Knochenarbeit sein, die sich durchaus über mehrere Tage erstrecken kann. Deswegen kann ich gut verstehen, warum sich Moby der Herausforderung nicht stellen möchte, zumal er es trotz der deutlich längeren Entwicklungszeit vermutlich nicht schaffen wird, effizienteren Code abzuliefern, von besserer Les- und Wartbarkeit ganz zu schweigen. ———————————— ¹) Beitrag "C versus Assembler->Performance" Beitrag "Kleines Tiny13 Sensorboard" ²) Dieser Wert ist wahrscheinlich noch viel zu niedrig angesetzt, da er ja auch Zeit für das Lesen der anderen Beiträge braucht, auf die er sich bezieht.
Moby A. schrieb: > Bleibe am Ball. Das ist freilich bei sovielen netten, tiefgründigen > Antworten für einen Einzelkämpfer für Asm hier zeitlich schwer zu > stemmen, aber ich bemühe mich. Dann bring doch einfach das Beispiel, anstatt weiter Quatsch zu labern. Hier nochmals die Aufgabenstellung:
1 | void main(){ |
2 | |
3 | uint8_t threshold = 89; |
4 | |
5 | uint8_t value_ptr = 0; |
6 | uint8_t last_values[8] = {0, 0, 0, 0, 0, 0, 0, 0}; |
7 | |
8 | ADC_CONFIG |= (1 << ADC_ON); |
9 | UART_CONFIG = ...; // set some bits here |
10 | |
11 | |
12 | while(true){ |
13 | if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){ |
14 | |
15 | // save value into ringbuffer
|
16 | last_values[value_ptr] = ADC_VALUE; |
17 | |
18 | // increase ringbuffer pointer
|
19 | value_ptr ++; |
20 | value_ptr %= 8; |
21 | |
22 | // sum up values in ringbuffer
|
23 | uint16_t sum = 0; |
24 | for(uint8_t i = 0; i < 8; i ++){ |
25 | sum += last_values[i]; |
26 | }
|
27 | |
28 | // check if average in ringbuffer exceeds threshold
|
29 | // if yes, send over uart
|
30 | if(sum / 8 > threshold){ |
31 | UART_DATA = sum / 8; |
32 | UART_CONFIG |= (1 << UART_DO_SEND); |
33 | }
|
34 | |
35 | }
|
36 | }
|
37 | }
|
P. M. schrieb: > Hier nochmals die Aufgabenstellung: Wo? Ich sehe nur Quellcode. Sieht so eine Spec aus?
Witkatz :. schrieb: > P. M. schrieb: >> Hier nochmals die Aufgabenstellung: > > Wo? Ich sehe nur Quellcode. Sieht so eine Spec aus? Eine bessere Spec als einen kompletten Quellcode kann es gar nicht geben, denn der definiert eindeutig was das Programm tun muss. Und in diesem einfachen Fall kann man den Code in 2-5 Minuten durchlesen und komplett verstehen. Zusätzlich hat es sogar noch Kommentare, die den Code einzelne Abschnitte zusammenfasst. Wenn das nicht ausreicht als Vorgabe, dann weiss ich auch nicht mehr weiter...
P. M. schrieb: > Eine bessere Spec als einen kompletten Quellcode kann es gar nicht > geben, denn der definiert eindeutig was das Programm tun muss. Und in > diesem einfachen Fall kann man den Code in 2-5 Minuten durchlesen und > komplett verstehen. Zusätzlich hat es sogar noch Kommentare, die den > Code einzelne Abschnitte zusammenfasst. Wenn das nicht ausreicht als > Vorgabe, dann weiss ich auch nicht mehr weiter... Moby?? ^^ :-/ :-)
Witkatz :. schrieb: > P. M. schrieb: >> Hier nochmals die Aufgabenstellung: > > Wo? Ich sehe nur Quellcode. Sieht so eine Spec aus? Ich sehe da wie P.M. auch kein größeres Problem. Nach Anschauen des Quellcodes war mir (ich bin wahrlich kein C-Gott) nach gefühlten 30 Sekunden klar, dass das Programm eine über die letzten acht Werte gemittelte Spannung am ADC an die serielle Schnittstelle ausgibt, wenn ein Schwellenwert überschritten wurde. Was genau verlangt wird, ist aus dem Programm also offenbar recht einfach zu entnehmen.
Chris D. schrieb: > Ich sehe da wie P.M. auch kein größeres Problem. > > Nach Anschauen des Quellcodes war mir (ich bin wahrlich kein C-Gott) Ist auch nicht nur für dich. Ihr wollt euch mit einem C-Legastheniker messen und legt eine in C verfasste Spec vor? Ist das nicht ein bisschen unfair?
Witkatz :. schrieb: > Ist auch nicht nur für dich. Ihr wollt euch mit einem C-Legastheniker > messen und legt eine in C verfasste Spec vor? Ist das nicht ein bisschen > unfair? Er konnte ja auch lang und breit erklären, inwiefern Assembler gegenüber C überlegen ist. Also gehe ich mal davon aus, dass er C zumindest verstehen kann, wenn auch mit vielleicht etwas mehr Mühe als andere.
Witkatz :. schrieb: > Ist das nicht ein bisschen unfair? Ist es, aber es ist natürlich genau das, was Moby seit Monaten auch macht. ;-) Wenn man allerdings das von Yalu zitierte Angebot von Karl Heinz liest, sah das dort durchaus anders aus.
Witkatz :. schrieb: > Wo? Ich sehe nur Quellcode. Sieht so eine Spec aus? Gemäss Moby braucht er selber nicht mehr um ein Programm zu verstehen: Moby A. schrieb: > ttyS2 schrieb: >> Dann liefere doch endlich eine ordentliche Beschreibung der >> Anforderungen. > > Siehe Beschreibung, Diagramm, Sourcecode, Threadverlauf. Schaltplan ebensowenig, das Layout ist selbsterklärend.
Operator S. schrieb: > Gemäss Moby braucht er selber nicht mehr um ein Programm zu verstehen: Man muss sich doch aber jetzt nicht selbst auf dieses unterirdische Niveau begeben.
Jörg W. schrieb: > Ist es, aber es ist natürlich genau das, was Moby seit Monaten auch > macht. ;-) Nichts gegen Moby, aber er ist mir zu sehr auf ASM beschränkt. Sein persönlicher Urteil interessiert mich nicht die Bohne, zumal der von vornherein feststeht. Für einen objektiven Vergleich sollte die Aufgabe von guten Programmierern beleuchtet werden, die sowohl ASM als auch C beherrschen. Mein Vorschlag wäre, dass P.M. seine Aufgabe in C ans Laufen bringt und den lauffähigen Quellcode, das ASM Listing und den Ressourcenverbrauch (Flash/RAM/Programmlaufzeit etc.) vorlegt, dann ist schon mal die Hälfte erbracht. Eventuell kann man das auch mit verschiedenen Compilern und Optimierungsstufen vergleichen. Dann kann man auf der ASM Seite (mit oder ohne Moby) schauen, ob und welches Optimierungspotential in ASM steckt. Vielleicht kann dann Moby ein besseres ASM Quellcode vorlegen oder gute Optimierungen vorschlagen?
:
Bearbeitet durch User
Witkatz :. schrieb: > Vielleicht kann dann Moby ein besseres ASM Quellcode vorlegen oder gute > Optimierungen vorschlagen? Klar kann man das immer. Das Problem der Assemblerprogrammierung ist doch, dass es 1.) ziemlich lange dauert, bis man eine erste, (einigermaßen) bugfreie Lösung hat und dass man 2.) immer noch die Chance hat, einiges an Potenzial für Optimierung zu verschenken. Eine einmal existierende Vorlage nachträglich weiter zu verfeinern, ist logischerweise sehr viel einfacher, entspricht ja aber nicht dem Vergleich der beiden Vorgehensweisen. Das, was Karl Heinz im anderen Thread vorgeschlagen hat, hat schon Hand und Fuß, das wäre die korrekte Vorgehensweise. Aber siehe oben, Mobys Antwort dazu war doch eindeutig: „Den greife ich natürlich nicht auf, weil ich für solche Späße keine Zeit investiere.“ (Dass er im Gegenzug als Widerlegung für seine These verlangt, dass alle anderen sich die Zeit für derartige Späße nehmen, ist natürlich bezeichnend für seine Persönlichkeitsstruktur.)
:
Bearbeitet durch Moderator
Witkatz :. schrieb: > Mein Vorschlag wäre, dass P.M. seine Aufgabe in C ans Laufen bringt und > den lauffähigen Quellcode, das ASM Listing und den Ressourcenverbrauch > (Flash/RAM/Programmlaufzeit etc.) vorlegt, dann ist schon mal die Hälfte > erbracht. Eventuell kann man das auch mit verschiedenen Compilern und > Optimierungsstufen vergleichen. Das hört sich auf jeden Fall richtig interessant an :-) Bisher habe ich mich (und vermutlich viele andere auch) noch nicht wirklich in die "Optimierungstiefen" eines C-Compilers gewagt: "was wird wann wie optimiert?" So könnte man aus diesem Thread sogar noch etwas mitnehmen.
>dass P.M. seine Aufgabe in C ans Laufen
Ich würde P.M. vorher noch empfehlen, die 8en im Code durch ein sizeof
oder durch eine Konstante zu ersetzen.
Witkatz :. schrieb: > Mein Vorschlag wäre, dass P.M. seine Aufgabe in C ans Laufen bringt > und den lauffähigen Quellcode, das ASM Listing und den > Resourcenverbrauch (Flash/RAM/Programmlaufzeit etc.) vorlegt, dann ist > schon mal die Hälfte erbracht. Eventuell kann man das auch mit > verschiedenen Compilern und Optimierungsstufen vergleichen. > > Dann kann man auf der ASM Seite (mit oder ohne Moby) schauen, ob und > welches Optimierungspotential in ASM steckt. Vielleicht kann dann Moby > ein besseres ASM Quellcode vorlegen oder gute Optimierungen > vorschlagen? Damit kann man gut die Frage klären, ob Compilercode noch Potential für Handoptimierung hat, aber nicht einen Wettstreit ASM-handgebaut gegen Compiler-Bloat. Letztlich erfährt man nur, ob Moby fehlerfrei abschreiben kann. Zweifel sind erlaubt, besonders wenn der GCC auf die Idee kommt, "seltene Opcodes" zu benutzten.
Jörg W. schrieb: > entspricht ja aber nicht dem > Vergleich der beiden Vorgehensweisen. Den hat P.M. auch nicht vorgeschlagen. Er hat die Aufgabe in Hochsprache bereits gelöst und das ist auch mMn die übliche Vorgehensweise. Um das getestete Projekt vom Test-µC auf einen kleineren Produktions-µC zu portieren, würde man vielleicht anfangen in C zu optimieren oder auf ASM zurückgreifen. Mit so einer Pipifax Aufgabe vielleicht nicht, aber wie soll man das Optimierungspotential von C und ASM für kleine MSR Aufgaben sonst vergleichen, als mit einer kleinen MSR Aufgabe? Als Ergänzung der Aufgabe würde ich noch bei Überschreitung des Grenzwertes einen Ausgang setzen und bei Unterschreitung mit definierter Hysterese zurücksetzen. Als Alibifunktion für das SR in MSR.
Ey Leute, was soll das? Anhand eines einzigen, konstruierten Beispiel die Überlegenheit einer Sprache oder Programmiertechnik aufzeigen zu wollen? Jeder von und weiß, dass die Welt nicht so simpel ist, und dass zudem ein so konstruierten Beispiel wahrscheinlich so gestrickt ist, dass es die eigene Einstellung untermauert. Die meisten hier bevorzugen Hochsprachen für die Umsetzung ihrer Projekte. Moby bevorzugt und liebt sein AVR-ASM für die Umsetzung seiner Projekte und hat eine klar artikulierte Abneigung gegen C. So what? Argumente für und wider gibt es duzende, ich brauch sie hier nicht zu wiederholen. Aber jeder wichtet die Bedeutung der einzelnen Argumente und Software-Metriken anders und sogar mit anderen Vorzeichen (z.B. Kontrolle über "alles" wie etwa Registerlayout zu haben oder haben zu müssen). Und jeder hat andere Vorlieben, Präferenzen, Erfahrungen, Hintergrundwissen, Qualitätsbewusstsein, Grad an Pragmatismus, Perfektionismus, Kontrollzwang. Und am Ende wird jeder eine überwältigende Mehrzal an Argumenten für seine eigene Überzeugung finden. Viele, die hier für C argumentieren, könnten ähnliche Argumente hernehmen, um von C abzuraten und Arduino oder BASCOM zu propagieren... Zumal C nur auf den ersten Blick einfach ist: Es hat genug Fallstricke, und C ist weder von Hobby-Programmierern entworfen worden noch für Hobby-Programmierer entworfen worden. C++ ist nochmals um Größenordnungen komplexer. Inzwischen geht's hier ja nur noch ums Missionieren bzw. um Repliken auf als Missionierung empfundene Repliken auf als Missionierung empfundene Repliken auf...
Johann L. schrieb: > Jeder von und weiß, dass die Welt nicht so simpel ist, und dass zudem > ein so konstruierten Beispiel wahrscheinlich so gestrickt ist, dass es > die eigene Einstellung untermauert. Nö, sehe ich nicht so. Einen Analogwert messen, glätten und auf Grenzwertverletzung reagieren - was ist daran bitte schön künstlich konstruiert um irgedwas zu untermauern?
Johann L. schrieb: > Jeder von und weiß, dass die Welt nicht so simpel ist, und dass zudem > ein so konstruierten Beispiel wahrscheinlich so gestrickt ist, dass es > die eigene Einstellung untermauert. Es verwendet zwei Peripherie-Geräte (ADC und UART), einfache Arithmetik (Mittelwertbildung) und muss auf simple Statusänderungen (ADC hat neuen Wert, Grenzwert zu hoch) reagieren. Ich finde, das ist ein sehr repräsentatives Beispiel für allgemeine MS(R)-Aufgaben. Und ganz ehrlich: Beim Thread geht's ja schon längst nicht mehr darum, ob C oder Assembler "besser" ist. Wir sind uns alle einig, dass C für die meisten Fälle die bessere Wahl ist und Assembler seine volle Berechtiung in gewissen Nischen hat. Es geht schon lange nur noch darum, wie man dies auch Moby klarmachen kann.
P. M. schrieb: > wie man dies auch Moby klarmachen kann. Die Antwort ist doch sonnenklar: gar nicht.
Jörg W. schrieb: > Die Antwort ist doch sonnenklar: gar nicht. Zumal seine Erkenntnisse nicht auf Erfahrungen beruhen, sondern er nur die üblichen Klosprüche nachplappert. mfg.
P. M. schrieb: > Wir sind uns alle einig, dass ... > Assembler seine volle > Berechtiung in gewissen Nischen hat. Für mich sind eben diese Nischen das einzig Interessante an diesem Thread. Ich hätte gerne eine objektive (oder zumindest fundierte subjektive) Antwort auf die akademische Frage ob und wann sich Assembler lohnt und ob in ASM wirklich noch nennenswertes Optimierungspotential steckt, das man mit gut optimierendem Compiler nicht mehr rausholen kann.
:
Bearbeitet durch User
Witkatz :. schrieb: > ob und wann sich Assembler lohnt Dafür wirst du keine pauschale Aussage bekommen, außer sowas wie: wenn du auf den einzelnen Taktzyklus genau sein willst, dann musst du den Maschinencode natürlich komplett selbst zimmern. Je moderner die CPU aber ist, um so schwieriger wird es, die Zyklenzahl überhaupt so genau zu ermitteln, siehe bspw. die Diskussion dort: Beitrag "[ARM / Cortex-M0(+)] delay-Funktionen "avr-libc style"" Da ist so ein Cortex-M0(+) zwar in der Einfachheit der CPU noch relativ nah dran an dem, was man bspw. von einem AVR gewohnt ist (bspw. typisch keinen Cache), aber selbst da hängt es eben nun nicht nur davon ab, wie viele Flash wait states man konfigurieren muss, sondern eben auch davon, dass bei 16-bit-Thumb ein Opcode fetch gleich zwei Befehle mit einem Takt lädt. Ansonsten kannst du dir natürlich immer mal den vom Compiler generierten Assemblercode ansehen um ein Gefühl zu bekommen, was da so läuft. Beispielsweise sowas hier: Beitrag "Re: Codeblähungen beim Rechnen mit globaler Variable" von dem dann Johann meint: „Find ich naheliegend und nicht skurril :-)“
Jörg W. schrieb: > P. M. schrieb: >> wie man dies auch Moby klarmachen kann. > > Die Antwort ist doch sonnenklar: gar nicht. Ist ja auch egal. Er hat sich eh verdrückt.
Moby A. schrieb: > Für den Ressourcenvorteil von Asm? Genügend. Mannmonate sind auch Ressourcen. Sauteure Ressourcen sogar, teurer als jedes MHz und jedes kByte, denn die kB und die MHz entstehen quasi aus dem Nichts, einfach durch Warten und Däumchen drehen: Während der ASM-Coder schwitzend und fluchend Jahre an teurer Zeit verbrennt tauchen noch lange bevor er auch nur ansatzweise fertig ist wie aus dem Nichts schon neue Controller auf mit doppelt so viel Speicher und Rechenkraft fürs halbe Geld, die all diese Bemühungen nun mit einem Schlag obsolet machen.
Witkatz :. schrieb: > Nö, sehe ich nicht so. Einen Analogwert messen, glätten und auf > Grenzwertverletzung reagieren - was ist daran bitte schön künstlich > konstruiert um irgedwas zu untermauern? Na ja. Aber wenn du jetzt ehrlich bist, so herausfordernd ist dieses Beispiel jetzt auch wieder nicht. Auch wenn Moby eine Abneigung gegen alles was mehr als 8 Bit Arithmetik hat, 16 Bit Additionen kriegt er auch hin. Genauso wie der Compiler. Ganz im Gegenteil würde ich sogar erwarten, dass hier der Compiler einen Assembler Code hinlegt, den man auch mit Handoptimierung nicht mehr schneller hinkriegt und wenn dann höchstens um ein paar Takte im kleinen einstelligen Bereich.
Bernd K. schrieb: > Während der > ASM-Coder schwitzend und fluchend Jahre an teurer Zeit verbrennt Weder schwitzend noch fluchend. Die Zeit ist auch nicht teuer. Hobbyzeit ist Spaßzeit! > noch lange bevor er auch nur ansatzweise fertig ist wie aus dem Nichts > schon neue Controller auf mit doppelt so viel Speicher und Rechenkraft > fürs halbe Geld, die all diese Bemühungen nun mit einem Schlag obsolet > machen. Ob aber der 'neue Controller' für die geplante Anwendung überhaupt nötig wäre? (Bitte zweimal lesen) Als Bastler kann ich dank effizientem Asm bei einfachen MSR-Aufgaben auf ewig beim AVR bleiben. Es gibt nicht den geringsten Anlass, den Controller wechseln zu müssen. Deshalb werden auch keine Bemühungen mit einem Schlag obsolet. Wenn sich der gewerbliche Programmierer genötigt sieht, den Controller zu wechseln hat das u.a. einen Grund: Die Ineffizienz der Hochsprache. Die Ineffizienz der Abstraktion. Und das mit steigender Tendenz.
Moby A. schrieb: > Karl H. schrieb: >> Es ist ebenfalls seine Umschreibung dafür, dass er noch nie irgendetwas >> größeres programmiert hat. Das werfe ich ihm nicht vor. Was ich ihm >> vorwerfe, das ist, dass er dann nicht so tun soll, als ob das alles >> einfach linear hochskaliert. > > Aus einer falschen Unterstellung folgerst du einen falschen Vorwurf. > In einigen KB Asm-Code lässt sich ja durchaus schon was 'größeres' > unterbringen. Ansichtssache. einige KB sind für manche hier (mich eingeschlossen) immer noch Kinderkram :-) Aber das hätte ich von dir gar nicht verlangt. > 'Linear hochskaliert' ist auch so ein netter Begriff. Stoff genug für > eine Doktor-Arbeit und noch mehr feinsinnigem Streit. Nicht wirklich. Es ist die einfache Milchmädchenrechnung: Wenn ein Arbeiter einen Graben in 1 Stunde aushebt, dann schaffen 3600 Arbeiter das in 1 Sekunde. > Codehimmel offen und weit... Die Grenzen setzen irgendwann Berechnungen > und das Handling großer Datenmengen. Oder übermäßig komplexe Hardware! Na, na. Wer wird denn gleich. Sargon Chess ist auf dem Z80 in Assembler programmiert. Seine Datenhandhabung ist alles andere als einfach. Ein Lee Algorithmus ist vom Prinzip her nicht schwer, aber die Datenstruktur kann knifflig werden. Hab ich trotzdem in Assembler gemacht. Warum? Zum Spass! Und natürlich weil 1984 die Z80-C Compiler nach sehr, sagen wir mal, in den Kinderschuhen steckten. Als junger Student hatte ich nachts Zeit und die Übung hat mir sicherlich nicht geschadet.
:
Bearbeitet durch User
Moby A. schrieb: > Die Zeit ist auch nicht teuer. > Hobbyzeit ist Spaßzeit! OK. Wenn es nur dein Hobby ist dann ist das OK, dann kannst Du auch ein 2m hohes Eiffelturm-Modell aus 42000 einzelnen Streichhölzern bauen. Vollkommen OK. Macht evtl. sogar Spaß. Aber dann brauchst Du nicht mit dem Wort "Ressourcen" argumentieren, oder irgendwas wäre effizienter als irgendwas anderes, die ganze alberne Diskussion hat sich dann komplett erledigt, Du betreibst dann das ASM-Puzzlespiel nur zum reinen Selbstzweck, völlig losgelöst von irgendwelchen Erwägungen bzgl. Effizienz oder praktischem Nutzen.
K.H.: > Als junger Student hatte ich nachts Zeit und die Übung hat mir > sicherlich nicht geschadet. Du bist aber deshalb nicht dran kleben geblieben und versuchst auch nicht alle anderen, die nicht dran kleben geblieben sind, als faul und unbegabt darzustellen, oder?
:
Bearbeitet durch User
Gu. F. schrieb: > Er hat sich eh verdrückt. Da mach Dir mal keine unnötigen Sorgen. Leider hab ich für diesen Thread keinen Vollzeitjob. Aus Zeitgründen kann ich mir vorerst nur konstruktive Einwände herauspicken. Deine werden fürchte ich jetzt auf der Strecke bleiben ;-( le x. schrieb: > Ist doch perfekt: ich teile dem Compiler nur kurz mit, dass ich einen > 8-Bit-Signed Wert haben will. Oder einen 16-Bit Unsigned. Das ist mit .BYTE x schneller erledigt. Die gebräuchlichsten Variablen sind absehbar eh nur Bytes und Words- mehr braucht man höchstens bei selteneren Berechnungen. > Du, mein lieber Moby, hast in deinem ASM-Code auch Datentypen (OK, > zugegeben, du nicht. Du hast nur 8-Bit-Unsigned, alles andere ist viel > zu komplex und wird auf dedizierte Hardware ausgelagert. Aber andere > ASM-Programmierer kennen Datentypen). War der erste Teil noch richtig wirst Du beim zweiten wieder unsachlich. > Du merkst dir den Datentyp im Kopf. Du schleppst ihn also implizit immer > mit dir rum, ob du das möchtest oder nicht. Ich schleppe gar nichts. Mit der Definition der Variable ist der vorab bestimmte Wertebereich klar. Vermutlich oft sparsamer dimensioniert, als durch den zur Verschwendung neigenden C-Programmierer. > Und jedesmal wenn mit einem Register gerechnet werden soll musst du von > Neuem entscheiden wie du vorgesht. > Ob ein Carry für den Vergleich berücksichtigt werden soll. > Ob du mehrere Register allokieren musst.... Das stellst Du Dir unnötig kompliziert vor. Im Kopf sind die verfügbaren Register. Sooo viele sinds nicht; mein System der Verwendung hatte ich bereits weiter oben skizziert. Das Carry-Bit wird auch selten zum Stolperstein, add/adc und sub/sbc sind gewohnte Kombinationen. Größere Berechnungen werden an die immergleichen fertigen Funktionsbausteine delegiert, die Input (Output) mit System in entsprechenden "standardisierten" Registern empfangen (ausgeben). Und überhaupt Berechnungen: Ja, sie wären ein Argument für C- wenn, ja wenn sie denn so häufig wären. > Und wehe, wehe, der Datentyp ändert sich weil du beim Entwickeln deiner > MSR-Applikation feststellst dass der Wertebereich bei der benötigten > Auflösung nicht ausreicht... Wiegesagt, wenn man sich bitteschön vorher einen Kopf macht welche Wertebereiche (z.B. ab einem ADC) benötigt werden muß man auch hinterher nix mehr ändern. > Du findest es kryptisch, zwei Variablen mittels "==" vergleichen zu > können? Völlig unabhängig vom Datentyp? Wow. Da fällt mir echt nichts > mehr ein. Aber mir fällt spontan cp/cpc dazu ein. Wiegesagt, es sind eh meist nur Byte- oder Word Variablen. > Aber wir wissen ja alle hier dass deine Abneigung gegen C, und > wahrscheinlich deine Vorliebe für dein AVR-ASM einzig daher rührt dass > deine bisherigrn kurzen C-Versuche gescheitert sind. Falsch. Das C-Programm steht und funktioniert- und es war kein kurzes. Aus seinen Erfahrungen sollte man aber lernen. Die Asm-Freiheiten gerade bei der kleinteiligen Auswertung von Hardware habe ich sehr vermisst. Die Möglichkeit kurzer knapper Formulierung ohne viel Palaver. > Im Übrigen würde ich dich bitten nie, NIE wieder von MSR-Anwendungen zu > faseln. Ich fasele nicht. Überdenke Deine Wortwahl. > Denn R-Anwendungen sind mit 8-Bit-Unsigned-Arithmetik einfach nicht zu > Richtiges "R" fordert oft anspruchsvolle Mathematik. > handeln. Also meine Regelung für die Fernheizung funktioniert auch ohne Studium. Ist alles halb so schwer als wie Du glauben machen möchtest ;-) > Bitte benutze also in Zukunft nur noch den Ausdruck "MS-Applikation", > schon aus Respekt vor richtigen Regelungstechnikern. Da habe ich Respekt und ich weiß aus betrieblicher Erfahrung, daß Regelungen durchaus anspruchsvoll sein können. Meine Erfahrung im SmartHome- und das ist auch kein kleiner Bereich- zeigt mir aber, daß Regelungen als Teil von MSR hier den geringsten Teil ausmachen. Aber es gibt sie.
Bernd K. schrieb: > Aber dann brauchst Du nicht mit dem Wort "Ressourcen" argumentieren, > oder irgendwas wäre effizienter als irgendwas anderes Da hat sich nichts erledigt. Mein Programm zeigt C im Ressourcenbedarf die Grenzen auf. Was mein Asm-Programm kann, das können Millionen weitere auch. Lass die Streichhölzer stecken. MSR auf 8-Bittern geht mit Asm sparender und sehr oft leichter. Ich muß gerade wieder über Beitrag "Codeblähungen beim Rechnen mit globaler Variable" schmunzeln... Mein Gott, was für Kopfstände, um seinen Code optimal zu bekommen!!! Karl H. schrieb: > einige KB sind für manche hier (mich eingeschlossen) immer noch > Kinderkram :-) Tja, Kinderkram hin oder her, es reicht fürs komfortable Smarthome. Was dort langt langt noch ganz woanders. 'Kinderkram' nehm ich mal als Kompliment fürs effiziente Tandem AVR/ASM- denn in der Tat, so sind Probleme spielend einfach gelöst! > Aber das hätte ich von dir gar nicht verlangt. Danke. Du bist großzügig. ;-) > Es ist die einfache Milchmädchenrechnung: Wenn ein Arbeiter einen Graben > in 1 Stunde aushebt, dann schaffen 3600 Arbeiter das in 1 Sekunde. Ja ja, die hübschen Vergleiche wieder... Darauf geb ich inzwischen keinen Cent mehr. > Sargon Chess ist auf dem Z80 in Assembler programmiert. Seine > Datenhandhabung ist alles andere als einfach. Glaub ich. Da werden viele Berechnungen gebraucht. Da gibts viele Daten. Hatte ich das nicht schon als Ausschlußkriterium für Asm-Projekte erwähnt? > Und natürlich weil 1984 die Z80-C Compiler > nach sehr, sagen wir mal, in den Kinderschuhen steckten. Compiler werden immer in den Kinderschuhen stecken. Warum? Weil sie den konkreten Anwendungsfall und oft die konkrete Hardware gar nicht im Focus haben. Der Asm-ler, ja deeer hat es! > Als junger > Student hatte ich nachts Zeit und die Übung hat mir sicherlich nicht > geschadet. Ja, Respekt Karl Heinz. Da lernt man was. Mein größtes Z80 Asm Projekt, ein onboard programmierbarer SPS-EPC inklusive eigener Sprache hatte 22KB. Versauert leider im Keller, denn irgendwann hat der AVR das ganze System plötzlich in die Tasche gesteckt. Seitdem kam nichts besseres und einfacheres mehr nach ;-)
:
Bearbeitet durch User
Karl H. schrieb: > Und natürlich weil 1984 die Z80-C Compiler nach sehr, sagen wir mal, in > den Kinderschuhen steckten. Da hat man ja auch Turbo-Pascal benutzt. ;-)
Karl H. schrieb: > Das müsste eine ziemliche 1:1 Umsetzung des fraglichen Assembler Codes > sein. Was hindert Dich daran, daraus einen vollständigen Programmcode zu machen den ich überprüfen kann? Die Vorahnung, daß es mit 1:1 oder dem Ressourcenbedarf doch nicht so weit her ist ? P. M. schrieb: > Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt > bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code > umwandeln? Klar könnte ich. Doch hättest Du mal lieber die Zeit wie K.H. in die Übersetzung meines Projekts gesteckt, dann hätte ich längst vergleichen können. Irgendwelche neue Aufgabenstellungen zu präsentieren trägt nicht dazu bei.
A. K. schrieb: > Vergleiche jenseits von 8 Bits sind nicht seine starke Seite cp+cpc Jungs, so einfach ist das ;-) Matthias L. schrieb: > ASM (selbst) kennt kein Vorzeichen. Somit existiert das Problem > "Vorzeichen" nur in den kryptischen, aufgeblasenen Hochsprachen. Bis 32 Bit hab ich fertige Routinen... Ich müsste aber laaang überlegen wann ich Operationen mit Vorzeichen bei MSR zuletzt gebraucht habe. A. K. schrieb: > Moby rechnet Temperaturen vermutlich in Fahrenheit. Das reicht von > Saukalt bis Kaffee in 8 Bits ohne Vorzeichen. Schon mal was von Angaben in Kelvin gehört? Oft interessiert doch noch nicht einmal die Einheit, wenn es nur um Vergleiche auf Sollwertüberschreitungen geht. Witkatz :. schrieb: > Wieso? Ich dachte, dass einfache Digitalfilter zu einfacher MSR dazu > gehören, oder etwa nicht? Nie gebraucht ! Karl H. schrieb: > Da schreibe ich / 8 und der Compiler kümmert sich drum, wie oft > verschoben werden muss. Genial. Das überzeugt mich jetzt. Wie das Shifting mit dem Divisionsergebnis zusammenhängt ist aber auch sowas von schwer zu merken ;-)
Moby A. schrieb: > Bis 32 Bit hab ich fertige Routinen... > Ich müsste aber laaang überlegen wann ich Operationen mit Vorzeichen bei > MSR zuletzt gebraucht habe. Beim Vergleich der Führungsgröße mit der Rückführung wird klassischerweise Signed-Arithmetik benötigt. Aber nur bei Regelungen, nicht bei Micky Maus. Moby A. schrieb: >> Du findest es kryptisch, zwei Variablen mittels "==" vergleichen zu >> können? Völlig unabhängig vom Datentyp? Wow. Da fällt mir echt nichts >> mehr ein. > > Aber mir fällt spontan cp/cpc dazu ein. Wiegesagt, es sind eh meist nur > Byte- oder Word Variablen. Ach, und "==" ist kryptischer als cp/cpc? Was soll das sein? Chickenpizza/Chickenpizza-Curry?! Das Zeichen "=" ist in der Regel aus der Grundschule bekannt. Moby A. schrieb: > Das ist mit .BYTE x schneller erledigt. Die gebräuchlichsten Variablen > sind absehbar eh nur Bytes und Words- mehr braucht man höchstens bei > selteneren Berechnungen. Moby A. schrieb: > Ich schleppe gar nichts. Mit der Definition der Variable ist der vorab > bestimmte Wertebereich klar. Vermutlich oft sparsamer dimensioniert, als > durch den zur Verschwendung neigenden C-Programmierer. Moby A. schrieb: > Wiegesagt, wenn man sich bitteschön vorher einen Kopf macht welche > Wertebereiche (z.B. ab einem ADC) benötigt werden muß man auch hinterher > nix mehr ändern. Moby A. schrieb: > Mein Programm zeigt C im Ressourcenbedarf > die Grenzen auf. Man verzeihe mir bitte meine Unsachlichkeit, aber jetz muss ich mal blöd fragen: Moby, glaubst du die Scheiße die du hier verzapfst eigentlich wirklich selbst?
le x. schrieb: > Beim Vergleich der Führungsgröße mit der Rückführung wird > klassischerweise Signed-Arithmetik benötigt. Aber nur bei Regelungen, > nicht bei Micky Maus. Das ist keine typische Anwendung für Controller - es reicht doch eine Zweipunktregelung :-)
Moby A. schrieb: > Wenn sich der gewerbliche Programmierer genötigt sieht, den Controller > zu wechseln hat das u.a. einen Grund: Die Ineffizienz der Hochsprache. > Die Ineffizienz der Abstraktion. Und das mit steigender Tendenz. Das stimmt nicht. Bisher habe ich die MCU gewechselt weil ich: a.) spezielle Hardware (Viele Uarts, I²S, viele Hardware PWMs, spezielle Hardware für SMPS) b.) besonders kleine Bauformen c.) einen extrem niedrigen Preis benötigt habe. Der AVR ist ganz nett, aber er ist alt, langsam, teuer, groß und braucht mehr Beschaltung als viele seiner modernen Kollegen. Ein freundlicher Dinosaurierer so wie der 8051 den ich auch lange benutz habe um dann weiterzuziehen. Durch die modernen C Compiler kann ich fröhlich zwischen den MCU Familien hin und herspringen, was immer gerade für mich passt. Niemand hat ein Problem damit wenn Du auf ewig beim AVR bleiben möchtest und ASM Dein erkärter Liebling ist. Aber hör doch bitte auf uns zu erzählen was das beste für uns ist und was wir wirklich brauchen. Du steckst nicht in unseren Schuhen und hast keine Ahnung davon was unsere Gründe sind zu tun was wir tun. Aus Deiner Sicht mag Dein Weg der ideale für Dich sein. Freut mich auch für Dich, bleib dabei wenns für Dich funktioniert. Ich empfinde Deinen Weg als kompliziert, einschränkend und als Relikt einer vergangenen Epoche. Das kann ich sagen weil ich mit ASM auf 8085 / 8051 angefangen und die Annehmlichkeiten moderner MCUs und Sprachen zu schätzen gelernt habe. Ich werde mich stark hüten nun meine Maßstäbe zu nehmen und zu behaupten das mein Weg nun auch für alle anderen der richtige ist. Der richtige Weg ist von derat vielen Parametern abhängig und so stark personenbezogen das den jeder für sich selber finden muß. Manch einer nimmt lieber eine starke MCU und programmiert sich die Hardwareemulation wo die Hardware fehlt,der andere wechselt dafür die MCU Familie, der nächste löst das im FPGA Block usw. Richtig ist das was funktioniert und im persönichen Aufwands-, Kosten-, Zeitrahmen bleibt. Die ganze Diskussion dreht sich immer wieder um Deine Eigenschaft das eigene Vorgehen als die ultimative Wahrheit zu verkaufen und jedes Argument so zurecht zu biegen das es Deine individuelle Sicht der Dinge untermauert. Das ist kindisch und unreif, eine Form des Altersstarrsinns oder ein Defizit in der Persönlichkeit. Sorry, das ich das so sagen muß, aber das geht uns allen hier gehörig auf den Keks. Natürlich ist das auch unterhaltsam, aber eher in der Art wie eine Satiresendung oder ein komödiantisches Bühnenstück. Ob Du das machst weil Du die Konfrontation liebst oder weil Deine Emotionale Intelligenz tatsächlich an der Nulllinie kratzt kann ich nicht sagen, ist mir auch egal. Wenigstens bist Du unterhaltsam ohne extrem ausfallend zu werden. Damit gehörst Du für mich zu den wertvolleren Mitgliedern dieses Forums.
Moby A. schrieb: > Wenn sich der gewerbliche Programmierer genötigt sieht, den Controller > zu wechseln hat das u.a. einen Grund: Die Ineffizienz der Hochsprache. Das heisst, Du bekommst jedes erdenkliche "typische 8-Bit-Programm" in einen Tiny13 gequetscht, weil Du in ASM programmierst? Du brauchst also niemals mehr den Prozessor wechseln? Es passt alles in einen Tiny13? Kompliment!
Frank M. schrieb: > Das heisst, Du bekommst jedes erdenkliche "typische 8-Bit-Programm" in > einen Tiny13 gequetscht, weil Du in ASM programmierst? Du brauchst also > niemals mehr den Prozessor wechseln? Es passt alles in einen Tiny13? Ja, da passt alles rein was sein persönlicher Horizont erfassen kann.
Gu. F. schrieb: > Ja, da passt alles rein was sein persönlicher Horizont erfassen kann. Man kann an seiner Aussage nicht nur seinen persönlichen Horizont erkennen, sondern auch deren Schwachsinnsgehalt.
"Wir leben zwar alle unter dem selben Himmel, haben aber nicht alle den gleichen Horizont"
Gu. F. schrieb: > Ja, da passt alles rein was sein persönlicher Horizont erfassen kann. Wir sollten Sturheit nicht mit Dummheit verwechseln. Moby durchdringt durchaus auch kompliziertere Probleme. Ich finde es wenig hilfreich wieder zu den düsteren Passagen dieses Threads zurückzukehren in denen es eher um persönliche Angriffe ging. Das sind alles nur Steilvorlagen um alles was wir sagen in die Beleidigungsecke zu schieben ohne sich inhaltlich damit beschäftigen zu müssen.
Moby A. schrieb: > P. M. schrieb: >> Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt >> bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code >> umwandeln? > > Klar könnte ich. Doch hättest Du mal lieber die Zeit wie K.H. in die > Übersetzung meines Projekts gesteckt, dann hätte ich längst vergleichen > können. Irgendwelche neue Aufgabenstellungen zu präsentieren trägt nicht > dazu bei. Erinnert mich an meine Kinder.. Ist ja wie im Kindergarten. "Ich hab es aber als erstes gehabt!" Sobald ein Kind diesen Satz sagt, ist jede Diskussion Sinnlos: Damit wird jedes Argument abgeschmettert.. (egal ob das Kind überhaupt noch an der Sache interessiert ist, da man es ja als erster gehabt hat, behält man es natürlich..) Moby hat als erster seine ASM Code gepostet, und erwartet das andere den C-Code liefern.. Damit ist aus Sicht eines 5 Jährigen die Sachlage vollkommen klar: Wenn jemand anderer das selbe macht, also C-Code postet und von Moby das selbe in ASM-Code erwartet ist das natürlich vollkommen illegitim...
:
Bearbeitet durch User
Man muss sich auch mal in die Lage des C-Programmierers versetzen, der nach Mobys Forderung dessen ASM-Programm in C übersetzen soll: Wozu soll dieser sich diese Mühe machen, Mobys Programm zu verstehen (80% der Arbeit) und dann zu übersetzen (20% der Arbeit)? Er braucht das Programm nämlich nicht. Er würde es für die Tonne programmieren. Moby erbringt keine Vorleistung (die 80% könnte er nämlich leisten), bleiben also 100% beim C-Programmierer hängen. 100% Arbeit für die Katz? Nein!
Moby A. schrieb: > P. M. schrieb: >> Ich denke, das ist sehr typisches 8-Bit-MS(R). Könntest du das jetzt >> bitte mal in kurzen, kompakten, übersichtlichen Assembler-Code >> umwandeln? > > Klar könnte ich. Doch hättest Du mal lieber die Zeit wie K.H. in die > Übersetzung meines Projekts gesteckt, dann hätte ich längst vergleichen > können. Soso. Du bist der, der behauptet, aber liefern sollen die andern. Zudem will ich ja die Optimierungsmöglichkeiten von Assembler gegenüber C sehen. Moby A. schrieb: > Da habe ich Respekt und ich weiß aus betrieblicher Erfahrung, daß > Regelungen durchaus anspruchsvoll sein können. Aber wohl bloss vom Hörensagen... ;-) Sag mal: Was hast du überhaupt für eine Ausbildung? Ohne mindestens ein FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen.
P. M. schrieb: > Sag mal: Was hast du überhaupt für eine Ausbildung? Was für eine Rolle sollte das denn spielen? Er hat einfach in erster Linie eine Überzeugung, und ansonsten natürlich die interessante Gabe, alles, aber auch alles, was gesagt wird, zu seinen Gunsten und als Bestätigung seiner Überzeugung auszulegen. Für die Sachen, wo er mit seiner Strategie an seine Grenzen stößt, kauft er dann einfach was dazu. Das passt offensichtlich dennoch mit seiner Überzeugung zusammen …
P. M. schrieb: > Sag mal: Was hast du überhaupt für eine Ausbildung? Ohne mindestens ein > FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler > kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen. Er ist Hobbyprogrammierer und hat den ASM-Befehl EOR vor etwa 4 Jehren kennengelernt: Beitrag "Re: AVR/ASM: Bit in Register invertieren" Aber wie Jörg schon sagt: Die Ausbildung bzw. der Beruf spielt hier überhaupt keine Rolle.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Karl H. schrieb: >> Das müsste eine ziemliche 1:1 Umsetzung des fraglichen Assembler Codes >> sein. > > Was hindert Dich daran, daraus einen vollständigen Programmcode zu > machen den ich überprüfen kann? Weil es mich ehrlich gesagt überhaupt nicht wirklich interessiert. Du weigerst dich ja auch beharrlich auf meinen Vergleichs-Vorschlag einzugehen. Dabei würde es mich wirklich interessieren, was ein guter Assembler Programmierer aus meiner schnell hingeschusterten Heizungssteuerung noch rausholen kann. Nicht das es wichtig wäre. Sie passt in den Mega16, ist schnell genug, ich hab kein Problem damit und die Benutzersteuerung ist für meine Begriffe komfortabel genug. Ob die Zykluszeit da um 2 Millisekunden schneller ist oder nicht ist also völlig uninteressant und für 20 Bytes weniger Flash Verbrauch kann ich mir auch nichts kaufen. Die 2 investierten Samstag Nachmittage haben sich dann auch im Rahmen gehalten. Nur mit einem kann ich nicht dienen: Du wirst nicht nur mit den AVR-Registern auskommen sondern wirst dir ein Konzept zur Registerbenutzung überlegen müssen.
:
Bearbeitet durch User
P. M. schrieb: > Sag mal: Was hast du überhaupt für eine Ausbildung? Ohne mindestens ein > FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler > kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen. Na das mußt Du mir erklären. Ich konnte bisher zwischen Fähigkeit und erfolgreich abgeschlossenem Studium seltenst einen kausalen Zusammenhang finden.
Michael K. schrieb: > Na das mußt Du mir erklären. > Ich konnte bisher zwischen Fähigkeit und erfolgreich abgeschlossenem > Studium seltenst einen kausalen Zusammenhang finden. Naja...Regelungstechnik oder richtiges Software-Design lernt man jedenfalls nicht an der Hauptschule und auch nicht wirklich on-the-job. Und falls keinerlei Zusammenhang besteht zwischen Ausbildung und Fähigkeit, warum sollte man dann überhaupt studieren? Warum sollte man (teure) Hochschulabsolventen einstellen, wenn deren Ausbildung nix wert ist? Jörg W. schrieb: > P. M. schrieb: >> Sag mal: Was hast du überhaupt für eine Ausbildung? > > Was für eine Rolle sollte das denn spielen? In so einer Diskussion interessiere ich mich irgendwann auch für den Hintergrund, den eine Person mitbringt. Wenn ein Uni-Professor etwas sagt, was für mich unglaubwürdig klingt, dann betrachte ich es aus anderen Augen, als wenn ein Gymnasiast das selbe erzählt. Aktuell ist das zwar nicht gerade in Mode, Hinz und Kunz mit ihrem Hauptschulabschluss fühlen sich schnell beleidigt, wenn man ihnen weniger 'credibility' zumisst als gebildeteren Leuten.
>P. M. schrieb: >> Sag mal: Was hast du überhaupt für eine Ausbildung? >Was für eine Rolle sollte das denn spielen? So ganz uninteressant ist es nicht. Zumindest aus dem Bereich wo er beruflich tätig ist. Mit SW Entwicklung offensichtlich nicht.
Matthias L. schrieb: > Mit SW Entwicklung offensichtlich nicht. Dass das rein sein Hobby ist, daraus hat er nie einen Hehl gemacht.
>Dass das rein sein Hobby ist,
Ich fahre auch gern in meiner Freizeit mit meinem Mountainbike auf
Radwegen herum. Das ist nicht sehr effektiv, aber muss es ja nicht.
Zumindest würde ich aus meinem Verhalten nie gegen Rennräder wettern,
das diese zum Fahrradfahren nicht nötig seien. Ein Mountainbike reiche
doch.
Matthias L. schrieb: > Zumindest würde ich aus meinem Verhalten nie gegen Rennräder wettern, > das diese zum Fahrradfahren nicht nötig seien. Ein Mountainbike reiche > doch. Er sagt halt: "Mein Montainbike kann keiner überholen - ein Rennrad schon gar nicht." Obwohl er eher auf einem Dreirad als einem Mountainbike unterwegs ist. Notfalls lässt er sich von einem Porsche (XPORT) abschleppen und sagt: "Seht her! Ich fahre Autobahn (IoT) mit einem Dreirad!" Alles eine Frage der Wahrnehmung.
:
Bearbeitet durch Moderator
P. M. schrieb: > In so einer Diskussion interessiere ich mich irgendwann auch für den > Hintergrund, Mir war nur dieser Text zu provokativ. > Ohne mindestens ein > FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler > kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen. P. M. schrieb: > warum sollte man dann überhaupt studieren? Weil es vieles einfacher macht wenn man in dem Bereich arbeiten will und Personalchefs sowas sehen wollen. P. M. schrieb: > Warum sollte man > (teure) Hochschulabsolventen einstellen, wenn deren Ausbildung nix wert > ist? Eine berechtigte Frage. Ich sage nur das das Studium zu bestehen nicht viel darüber aussagt wie gut man als Entwickler geeignet ist. Gute und Schlechte gibt es mit und ohne Studium.
Michael K. schrieb: > P. M. schrieb: >> warum sollte man dann überhaupt studieren? > Weil es vieles einfacher macht wenn man in dem Bereich arbeiten will und > Personalchefs sowas sehen wollen. Und warum wollen sie es sehen? Weil es für sehr viele Entwicklungsaufgaben schlicht unentbehrlich ist! Klar - ein bisschen C und Elektronik zusammenstiefeln, das kann auch einer mit Abitur oder Berufsausbildung. Und wer sowieso mehr Projektmanagement als Technik macht, der braucht nicht unbedingt klassischen Fähigkeiten aus dem Studium. Aber für sehr viele gehobene Entwicklungsaufgaben geht's ohne Studium einfach nicht. Und ich finde, auch in einer Fachdiskussion (wie wir es hier zumindest formell haben) gehört ein gewisses theoretisches Fundament dazu. Klar, das hören diejenigen nicht gern, die alles on-the-job gelernt haben...
P. M. schrieb: > Klar, das hören diejenigen nicht gern, die alles on-the-job gelernt > haben... Richtig. Ich habe von Programmierung auch nichts im Studium gelernt, falls es dich beruhigt, wenn man mal von einer Pascal-Lehrveranstaltung absieht. Aber die war nur pro Forma, um einen Abschluss zu haben (den ich gegen was anderes „kaubeln“ konnte), denn zu diesem Zeitpunkt konnte ich Pascal bereits fließend. (*) Dass ich dann das vormalige Hobby zum Beruf gemacht habe, lag an der politischen und ökonomischen Entwicklung hier nach der Übernahme der DDR – Elektroniker brauchte gerade niemand, Programmierer schon. (*) Anekdote dazu: Ich war auch nie zur Lehrveranstaltung, habe mich dem Vorlesenden anfangs mal vorgestellt und meine Motivation erläutert. Zum Praktikum war ich (hat ja Spaß gemacht), und er hat sich anschließend bedankt, dass er von mir einige Details seines GRW-Pascals lernen konnte. ;-) „Ja, ich weiß, normalerweise funktioniert das in die andere Richtung, aber warum nicht mal so?“
Moby A. schrieb: > Die Vorahnung, daß es mit 1:1 oder dem > Ressourcenbedarf doch nicht so weit her ist ? Daß ich das noch erleben darf: Männer, die streiten, wer den Kürzesten hat.
Moby A. schrieb: > Wie das Shifting mit dem Divisionsergebnis zusammenhängt ist aber auch > sowas von schwer zu merken Das Konzept "sich etwas merken müssen" widerspricht dem von Dir behaupteten Konzept "ist alles ganz einfach".
P. M. schrieb: > Und warum wollen sie es sehen? Weil es für sehr viele > Entwicklungsaufgaben schlicht unentbehrlich ist! Wenn Du es sagst. Was machen wir jetzt mit den guten Entwicklern ohne Abschluss ? Müssen die jetzt den Hof fegen weil deren Job nun von jemanden gemacht wird der brav alles auswendig gelernt hat um die Scheine zu bekommen, dem aber der Biss und die Fantasie fehlt knifflige Probleme zu lösen ? Was haben eigentlich die Softwarepioniere gemacht bevor es den Studiengang überhaupt gab ? Klar, das Studium sollte viele nützliche Dinge vermitteln. Ob dieses Wissen auf fruchtbaren Boden fällt oder nicht ist ungewiss. 70% dessen was man später im Berufsleben braucht vermittelt aber kein Studium, kann kein Studium vermitteln. Das Studium vermittelt 'Momentaufnahmen' der jeweils aktuellen Entwicklung. Aktuell heißt dann oft jahrealtes Wissen eines Profs. Danach kommen aber nochmal 40Jahre Berufsleben. Da ist mir jemand lieber der das leidenschaftlich tut und sich aus Lust an der Freude alles beibringt was er jeweils braucht um das Projekt durchzuziehen. Jörg W. schrieb: > Dass ich dann das vormalige Hobby zum Beruf gemacht habe, lag an der > politischen und ökonomischen Entwicklung hier nach der Übernahme der > DDR – Elektroniker brauchte gerade niemand, Programmierer schon. Erinnert mich an den Witz der 'hier im Westen' umging. Frage: Wo sitzen die besten Programierer der Welt ? Antwort: In der DDR. Niemand kann mehr aus 8bit / 64K herausholen.
Michael K. schrieb: > der brav alles auswendig gelernt hat um die Scheine zu bekommen Hast du überhaupt studiert? Hast du eine Ahnung, was man in einem Studium lernt? Oder basiert deine Meinung einfach darauf, dass du ein paar Mal die Freude erleben durftest, etwas zu können, was ein Studierter nicht konnte?
P. M. schrieb: > Hast du überhaupt studiert? Komm mal wieder runter. Darum geht's in diesem Thread nicht. Im Gegensatz zu dir postet Michael hier übrigens nicht nur mit vollem Namen, sondern auch mit dem seiner Firma, und wenn du einfach nur mal reinguckst, was sein Laden so macht, dann weißt du, dass er da nicht nur irgendwelche „Zufallstreffer“ landet.
Jörg W. schrieb: > Komm mal wieder runter. Darum geht's in diesem Thread nicht. Sehe ich genauso. Ob man sein Fach tatsächlich an einer Hochschule studiert hat oder nicht, ist vollkommen nebensächlich. Ein Studium mag für viele von persönlichem Vorteil sein, weil man da lernt zu lernen. Aber was bzw. welches Fach man da lernt, ist nicht unbedingt das, was man später mal macht. Das kann man sich später auch autodidaktisch, d.h. im "Selbststudium" aneignen. Gerade das Internet bietet dafür heutzutage fast unbegrenzte Möglichkeiten. Aber: hier ist das offtopic.
:
Bearbeitet durch Moderator
Moby A. schrieb: > A. K. schrieb: >> Vergleiche jenseits von 8 Bits sind nicht seine starke Seite > > cp+cpc Jungs, so einfach ist das ;-) *ROFL* Unser Moby ist einfach Weltklasse! Gibt sich hier als Macker und Assembler-Versteher, wobei hier fast jeder seine armselige Vorstellung diesbezüglich live miterleben durfte. Zur Erinnerung: Rein aus Neugier wollte ich wissen, wie er einen 32-Bit Wert gegen eine Konstante vergleicht; immerhin eine kurze, überschaubare und klar formulierte Aufgabe, die durchaus in 4-5 Instruktionen machbar ist: Beitrag "Re: C versus Assembler->Performance" Nachdem sich Moby in gewohnter Geschmeidigkeit um eine konkrete Antwort drückte, wartete er schließlich mit einer 9 Instruktionen langen Sequenz auf — die falsch war. Die korrigierte Version war dann 12 Instruktionen lang! Okay, geschenkt. Moby hat ja gerne mal nen "langen" Tag, und auch mit "Vorbereitung, Erfahrung und System" ist unser Assembler-Papst nicht unfehlbar. Un dimmerhin hat er in dem Thread einen Zweck von CPC und SBCI gelernt. Viel bezeichnender fand ich, dass er — noch bevor er seine eigene Lösung für das Nobelpreis-würdige Problem präsentierte — darauf hingewiesen wurde, dass GCC nur 4-5 Instruktionen braucht und dies dann als AUSGESCHLOSSEN klassifizierte: Beitrag "Re: C versus Assembler->Performance" Mobys Code ist also IMMER optimal, weil ihm nämlich grad nix besseres eingefallen ist. L'ASM, c'est moi! Da kann man echt nur froh sein, dass er ASM-Populist als Hobby hat und nicht in die Politik gegangen ist.
:
Bearbeitet durch User
Jörg W. schrieb: > Komm mal wieder runter. Darum geht's in diesem Thread nicht. Die Nebendiskussion wurde von dir und Michael gestartet, nicht von mir. Ich habe bloss gefragt, ob Moby denn überhaupt einen entsprechenden Hintergrund hat - Studium oder Berufserfahrung. Berufserfahrung explizit eingeschlossen. Warum fühlt ihr euch so angegriffen, sobald der Begriff "Studium" fällt? Ich glaube absolut, dass Michael und du auch ohne Studium beruflichen Erfolg haben können, keine Frage. Ich würde euch auch als Fachleute nicht geringschätzen wegen fehlendem Studium. Aber ich sehe auch, dass ich im Studium Dinge gelernt haben, die man im Berufsleben einfach nie mehr lernt. Darunter sind durchaus auch Inhalte, die ich für meine tägliche Arbeit brauche. In meinem Fall zwar nicht im Bereich von Programmiersprachen, aber wer mal in das Gebiet des Compilerbaus und der Programmiersprachen-Theorie reingeschaut hat, der weiss, das dort beinharte theoretische Informatik dahintersteckt, die man eigentlich nur via mehrjähriges Studium erwerben kann.
P. M. schrieb: > wer mal in das Gebiet des Compilerbaus und der > Programmiersprachen-Theorie reingeschaut hat, der weiss, das dort > beinharte theoretische Informatik dahintersteckt, die man eigentlich nur > via mehrjähriges Studium erwerben kann. Kann natürlich auch ein Selbststudium sein, aber Compilerbau ist etwas, von dem ich auch die Finger lasse. Da beneide ich Johann für seine vielen Ideen, die er umsetzen konnte.
Angehängte Dateien:
-
7Segment_1_kompensiert.jpg
170 KB -
7Segment_2_kompensiert.jpg
190 KB -
7Segment_3_kompensiert.jpg
180 KB -
7Segment_PeDa1.JPG
190 KB -
7Segment_PeDa2.JPG
190 KB -
7Segment_PeDa3.JPG
160 KB
Gehen wir mal anders an die Sache heran. Nachdem dieser Thread so ausartet habe ich mir mal Moby's Sensor Thread zu Gemüte geführt. Beitrag "Kleines Tiny13 Sensorboard" Also das hoch effiziente ASM Programm holt zwei 10 BIT Analogwerte und zwei Digitalwerte. Was passiert den mit den Werten ? Weiter schreibst du... >> Das heißt natürlich nicht, dass nun keine Erweiterungen denkbar wären. >> Das könnte zum Beispiel... >> - Vorverarbeitung der Messwerte >> - Prüfen auf Bedingungen >> - Ergänzen eines Schalttransistors Ist doch ne Idee, mh, geht das denn ? Da braucht es doch dann Mathematik die auf so kleinen MCs gar nicht hinzubekommen ist. Also im Datenblatt steht: – 1K Bytes of In-System Self-programmable Flash program memory - 64 Bytes EEPROM - 64 Bytes Internal SRAM Puh, das wird eng :-( Im gleichen Sensor Thread schreibst du dann... >> 2) Lässt sich die Genauigkeit der ADU-Wandlung hier mit >> einfachen Mitteln weiter optimieren? Und weiter in diesem Thread hier... >> Die gebräuchlichsten Variablen sind absehbar eh nur Bytes und Words- >> mehr braucht man höchstens bei selteneren Berechnungen. Naja, dann probieren wir mal. Ein wenig Mathematik braucht es da schon aber die hast du ja schon im Fundus. Moby schreibt... >> Bis 32 Bit hab ich fertige Routinen Na dann los... http://www.atmel.com/images/doc8003.pdf http://www.atmel.com/images/doc2559.pdf Da steht wie es geht. Wenn dein Ausgabe Format denn eine Spannung, Temperatur oder sonst was sein soll dann setz doch die ATMEL Tipps um. Ach ja, ist vermutlich ne seltene Berechnung und vermutlich passt es in den kleine Tiny nicht hinein. Mein lieber Moby, dass sind keine seltenen Berechnungen sondern typische Berechnungen. Ich kenne keinen einzigen Sensor der nicht Kalibriert ist. Das gilt auch für typische Messungen. Glaubst du nicht ? Na dann ein Beispiel hierzu. Peda ist bekannt für seinen effizienten Assembler und C Code. In der Codesammlung findet sich ein nettes Beispiel für eine 7 Segment Anzeige... Beitrag "ADC mit Multiplexanzeige" Besser gesagt ein Voltmeter. Da ich faul bin bediene ich mich hier mal. Seine „defines“ sind clever aufgebaut und so lässt sich das schnell an meine Hardware anpassen und flux habe ich ein funktionierendes Voltmeter. Das Ergebnis ist allerdings ein wenig ernüchternd. In den angehängten Bildern (7Segment_PeDa1 – 3) sieht man wie sehr der Messwert von dem vorgegebenen abweicht. 4.96V werden zu 4.62 usw. Das wird bei deinen Messwerten nicht wesentlich anders aussehen. Besser gesagt, bei dir bekomme ich nur den Wandler Wert selbst, nur durchgereicht. Implementieren wir mal die AppNotes von Atmel. Das Ergebnis findet sich in den Bildern 7Segment_1_kompensiert 1 – 3. Siehe da, es geht und auch die letzte Stelle löst auf 1mV auf. Also erzähl mir nicht das sei seltene Mathematik. Das wird so gut wie immer benötigt. Mit der Codeergänzung kompiliert PeDa's Code zu 764 bytes. Das passt noch locker in deinen Tiny hinein. Na dann los Moby, zeig mal was du kannst. Erweitere dein Programm mal um die Kleinigkeit und zeig uns deinen hocheffizienten ASM code. Wir können auch gerne andere Code Beispiele aus der Sammlung nehmen, die Klassiker sind LCD + Co oder kleine Messgeräte aber komm mir nicht mit deinem Assembler Fragment und stelle Vergleiche an. Das waren jetzt Fakten Fakten Fakten, genau wie du es magst :-) und was lernen wir daraus ? Codequalität liest man nicht an der Programmiersprache ab sondern am Gesamtergebnis. Immerhin habe ich mir die Mühe gemacht mein altes AVR Zeugs auszupacken obwohl ich seit mehr als 6 Jahren keinen davon angefasst habe. Compiliert habe ich mit der aktuellen Atmel Studio Version da ich nicht mal eine IDE für AVR hatte. Also, auf geht’s, geb dir auch nen Ruck und zeig mal was du kannst :-) Damit meine ich nicht ASM vs C sondern etwas das durch seine Funktionalität besticht.
P. M. schrieb: > Warum fühlt ihr euch so angegriffen, sobald der Begriff "Studium" fällt? Tue ich nicht. Würdest Du bitte aber auch verstehen das ich darüber spreche das Entwickler zu sein mit viel mehr zu tun hat als 'beinharte Theorie' gelernt zu haben ? Das Studium macht dich nicht gut und das Nichtstudium macht dich nicht schlecht. OT ist es ohnehin, aber wenigstens müsste dieses hier der 1000te Beitrag in diesem Thread sein ;-)
Michael K. schrieb: > Würdest Du bitte aber auch verstehen das ich darüber spreche das > Entwickler zu sein mit viel mehr zu tun hat als 'beinharte Theorie' > gelernt zu haben ? > Das Studium macht dich nicht gut und das Nichtstudium macht dich nicht > schlecht. Würdest du im Gegenzug verstehen, dass zumindest ein Teil dieser Theorie ganz signifikant dazu beiträgt, ein sehr viel besserer Entwickler zu werden oder sogar Grundvoraussetzung ist, um gewisse Problemstellungen zu lösen? Ich habe im übrigen mit keinem Wort behauptet, ohne Studium sei man ein schlechter Entwickler, durfte mir aber Sprüche anhören von wegen "auswendig gelernt" und "nur den Schein holen".
P. M. schrieb: > durfte mir aber Sprüche anhören von > wegen "auswendig gelernt" und "nur den Schein holen". [aufstöhn] Nein, ich habe nur gesagt das es eben diese Kollegen AUCH gibt. Großer Titel, nichts dahinter. Ich kenne beide Varianten. Dich kenne ich garnicht genug um mir anzumaßen etwas über Deine Qualifiation zu sagen. Können wir das jetzt bitte lassen ? Wenn ich Dir zu nahe getreten bin dann tut es mit leid, das war nicht meine Absicht und ich entschuldige mich dafür.
Michael K. schrieb: > Nein, ich habe nur gesagt das es eben diese Kollegen AUCH gibt. Ja. Klar. Die gibts überall. Der Punkt ist, dass es - sobald es um Studierte geht - jeweils explizit erwähnt werden muss. Wenn wir hier über LKW-Führerscheine sprechen, dann wird ja auch keiner erwähnen, dass es unter den LKW-Fahrern auch schwarze Schafe hat. Das irritiert und da fühlt man sich in der Tat angegriffen, ja. Aber ja, können wir gerne lassen. Die Suppe wird meist ja sowieso etwas heisser gekocht als gegessen ;-)
P. M. schrieb: > Michael K. schrieb: >> Nein, ich habe nur gesagt das es eben diese Kollegen AUCH gibt. > > Ja. Klar. Die gibts überall. Der Punkt ist, dass es - sobald es um > Studierte geht - jeweils explizit erwähnt werden muss. Wenn wir hier > über LKW-Führerscheine sprechen, dann wird ja auch keiner erwähnen, dass > es unter den LKW-Fahrern auch schwarze gibt. Der Unterschied ist nur, ohne Führereschein darf er nicht fahren. Ohne Diplomurkunde programmieren dagegen schon.
Bernd N. schrieb: > Gehen wir mal anders an die Sache heran. Nachdem dieser Thread so > ausartet habe ich mir mal Moby's Sensor Thread zu Gemüte geführt. Das ist sehr lobenswert, aber das hättest du dir sparen können. Bernd N. schrieb: > Mit der Codeergänzung kompiliert PeDa's Code zu 764 > bytes. Das beweist nur die Überlegenheit von effizientem Asm-Code. Und das: Bernd N. schrieb: > Na dann los Moby, zeig mal was du kannst. Erweitere dein Programm mal um > die Kleinigkeit und zeig uns deinen hocheffizienten ASM code. wird er auf gar keinen Fall machen. Denn es ist keine typische 8-Bit-Asm-Anwendung. Frag mich nicht warum. Ich programmiere auf 8-Bittern nur untypische Anwendungen. mfg.
:
Bearbeitet durch User
Moby A. schrieb: > Die meisten können schon das bischen > Tiny-Code meines Projekts nicht nachvollziehen, obwohl sie hier große > Reden schwingen ;-) Ich kann deinen ASM Quellcode nicht nachvollzienen, weil ich andere µC benutze. Aber um jetzt themenabschließend für mich den Vergleich zu ziehen, habe ich die Funktion deines Sensorboards anhand der Funktionsbeschreibung im Kommentarteil auf einem kleinen PIC12F675 nachzuprogrammiert. Hier mein QuD Entwurf. Von der Funktion müsste eigentlich alles aus dem Tiny-Projekt drin sein, oder? Wobei ich bei der CRC unsicher bin, weil sich dazu die Funktionsbeschreibung ausschweigt. Es wird von allen Nutzbytes die Summe gebildet und die zwei LSB bits übertragen, richtig?
1 | #include <xc.h> |
2 | #include <stdint.h> |
3 | |
4 | // CONFIG
|
5 | #pragma config FOSC = INTRCIO // Oscillator Selection bits (INTOSC oscillator: I/O function on GP4/OSC2/CLKOUT pin, I/O function on GP5/OSC1/CLKIN)
|
6 | #pragma config WDTE = OFF // Watchdog Timer Enable bit (WDT disabled)
|
7 | #pragma config PWRTE = OFF // Power-Up Timer Enable bit (PWRT disabled)
|
8 | #pragma config MCLRE = OFF // GP3/MCLR pin function select (GP3/MCLR pin function is digital I/O, MCLR internally tied to VDD)
|
9 | #pragma config BOREN = ON // Brown-out Detect Enable bit (BOD enabled)
|
10 | #pragma config CP = OFF // Code Protection bit (Program Memory code protection is disabled)
|
11 | #pragma config CPD = OFF // Data Code Protection bit (Data memory code protection is disabled)
|
12 | |
13 | #define _XTAL_FREQ 4000000
|
14 | #define clockpin GPIObits.GP4
|
15 | #define datapin GPIObits.GP5
|
16 | |
17 | void InitMCU(void){ |
18 | GPIO = 0; |
19 | CMCON = 0x07; // Comparator off |
20 | ADCON0bits.ADFM = 1; // Rigth justified |
21 | ADCON0bits.VCFG = 0; // Vref = Vdd |
22 | ADCON0bits.ADON = 1; // A/D on |
23 | |
24 | ANSELbits.ADCS = 0b101; // TAD = 4µs |
25 | ANSELbits.ANS = 0b0011; // AN0,AN1 |
26 | TRISIO = 0b001111; |
27 | |
28 | }
|
29 | |
30 | void ad_acq(uint8_t chs){ |
31 | ADCON0bits.CHS = chs; |
32 | __delay_us(20); |
33 | ADCON0bits.GO = 1; |
34 | while (ADCON0bits.GO_nDONE){;} |
35 | }
|
36 | |
37 | void sendByte(uint8_t s){ |
38 | uint8_t mask = 0b10000000; |
39 | while(mask){ |
40 | if(s & mask) |
41 | datapin = 1; |
42 | clockpin = 1; |
43 | __delay_ms(5); |
44 | clockpin = 0; |
45 | datapin = 0; |
46 | mask >>= 1; |
47 | __delay_ms(5); |
48 | }
|
49 | }
|
50 | |
51 | void main(void) { |
52 | uint8_t tmpByte3, crc; |
53 | |
54 | InitMCU(); |
55 | while(1){ |
56 | __delay_ms(80); |
57 | |
58 | // AD Channel 0
|
59 | ad_acq(0); // Analog Channel 0 lesen |
60 | sendByte(ADRESL); |
61 | crc = ADRESL; |
62 | tmpByte3 = ADRESH; |
63 | |
64 | // AD Channel 1
|
65 | ad_acq(1); // Analog Channel 1 lesen |
66 | sendByte(ADRESL); |
67 | crc += ADRESL; |
68 | tmpByte3 |= ADRESH << 2; // |
69 | |
70 | // send Byte 3 with CRC
|
71 | tmpByte3 |= (GPIO & 0b00001100) << 2; // Digitaleingänge in Bits 4,5 speichern |
72 | crc += tmpByte3; |
73 | tmpByte3 |= (crc & 0b00000011) << 6; |
74 | sendByte(tmpByte3); |
75 | }
|
76 | }
|
Der XC8 (free mode) übersetzt das zu 164 Befehlsworten und 10 Datenbytes. Der PIC12F675 ist damit zu 16% gefüllt, sowohl Flash als auch Datenspeicher. Das C-Projekt ließe sich das sogar auf einen PIC10F220 ausführen. Mein Fazit in dem Fall: No Need For Assembler!
:
Bearbeitet durch User
Thomas E. schrieb: > Frag mich nicht warum. Ich programmiere auf 8-Bittern nur untypische > Anwendungen. +1
Johann L. schrieb: > Moby A. schrieb: >> A. K. schrieb: >>> Vergleiche jenseits von 8 Bits sind nicht seine starke Seite >> >> cp+cpc Jungs, so einfach ist das ;-) > > *ROFL* Ging mir exakt genauso :D DAS sind genau die Stellen, die die Moby-Threads so herrlich amüsant machen :)
Vielen Dank für die vielen interessanten Beiträge in der Zwischenzeit. Ich fang mal von hinten an: Witkatz :. schrieb: > habe ich die Funktion deines Sensorboards anhand der > Funktionsbeschreibung im Kommentarteil auf einem kleinen PIC12F675 > nachzuprogrammiert Schau einer an. Wie das auf einmal geht wenn man nur will... > Es wird von allen Nutzbytes die Summe > gebildet und die zwei LSB bits übertragen, richtig? Nein, alle 1er Bits werden schlicht gezählt und die zwei niederwertigsten Bits der Summe dann drangehängt. Das wurde allerdings erst später im Thread so geändert weil auf Hinweis von Yalu die einfache Summe etwas witzlos ist. Zu finden später im Projektthread. > Mein Fazit in dem Fall: No Need For Assembler! Mein Fazit: > 10 > Datenbytes ...zu viel. Was die Vergleichbarkeit von PIC-und Asm Code betrifft bin ich auch gerade auch etwas überfragt. Aber danke für Deinen ernsthaften Beitrag. Leider kann ich auch die Funktion mangels C-Kenntnissen nicht nachvollziehen und habe keine PIC-Hardware zum Testen.
:
Bearbeitet durch User
Vielleicht sollte man dazu wissen, daß die 10 Datenbytes beim AVR Register genannt werden. Der Pic12F220 hat nämlich nur 16 Bytes im Registerfile. Also effektiv 10 Register und NULL Byte RAM.
Carl D. schrieb: > Vielleicht sollte man dazu wissen, Ok, hab mir das nicht so genau angeschaut, kann zum PIC und zu PIC-Asm Code jetzt wenig sagen. Was den AVR betrifft hatte ich ja freundlicherweise alle Register zur Verwendung freigegeben, mein Code nutzt derer 11. Nur bei diesem kann ich das Ergebnis wirklich nachprüfen.
Moby A. schrieb: > Leider kann ich auch die Funktion mangels C-Kenntnissen Ach...du hast gar keine C-Kenntnisse? Wie kannst du dann überhaupt irgendwelche Aussagen dazu machen? Moby A. schrieb: > Ok, hab mir das nicht so genau angeschaut, kann zum PIC und zu PIC-Asm > Code jetzt wenig sagen. "Dazu kann ich jetzt wenig sagen" - das ist alles? Diverse Leute haben jetzt mehrfach geliefert, aber du selbst kannst weder zu diesen Beispielen etwas vernünftiges sagen, noch ein C-Beispiel effizienter in Assembler implementieren. Von dir kommt einfach rein gar nichts ausser Sprüche.
Moby: > Ok, hab mir das nicht so genau angeschaut, kann zum PIC und > zu PIC-Asm Code jetzt wenig sagen. Ich habe auch noch nie einen PIC in den Fingern gehabt, aber kenne trotzdem dessen grobes Design und dann gibt's da noch das berühmte Datenblatt, 2 Clicks entfernt im Netz. Besonders wenn man was vergleichen will, ist es besser mindestens zwei Dinge zu kennen. OK, ich vergaß: Es kann nur Einen geben.
P. M. schrieb: > aber du selbst kannst weder zu diesen Beispielen etwas vernünftiges > sagen Du musst ihm nun schon den fertig programmierten PIC mit einer Bedienungsanleitung hinschicken, damit er verifizieren kann, ob der Beitrag seine Bedingungen erfüllt.
le x. schrieb: > Ach, und "==" ist kryptischer als cp/cpc? Was soll das sein? > Chickenpizza/Chickenpizza-Curry?! Das Zeichen "=" ist in der Regel aus > der Grundschule bekannt. Ach Herr je, wenns mal bloß das "==" wär ;-) > Man verzeihe mir bitte meine Unsachlichkeit, aber jetz muss ich mal blöd > fragen: > Moby, glaubst du die Scheiße die du hier verzapfst eigentlich wirklich > selbst? Einen Glauben würde ich als rationaler Mensch nicht so vehement verteidigen ;-) Du solltest bitteschön sachlich bleiben- mit Deiner Wortwahl erreichst Du eher: Nichts!
P. M. schrieb: > Ach...du hast gar keine C-Kenntnisse? Wusstest du das nicht? P. M. schrieb: > Wie kannst du dann überhaupt > irgendwelche Aussagen dazu machen? Er gibt das wieder, was er irgendwo aufgeschnappt hat. P. M. schrieb: > Von dir kommt einfach rein gar nichts ausser > Sprüche. Das ist ihm egal. mfg.
Jörg W. schrieb: > P. M. schrieb: >> aber du selbst kannst weder zu diesen Beispielen etwas vernünftiges >> sagen > > Du musst ihm nun schon den fertig programmierten PIC mit einer > Bedienungsanleitung hinschicken, damit er verifizieren kann, ob > der Beitrag seine Bedingungen erfüllt. Tja hilft nix. In Pic werde ich mich jetzt sicher nicht einarbeiten. Und was heißt schon "meine Bedingungen". Die Funktion ist eindeutig, woran zu sparen ist auch ;-) P. M. schrieb: > "Dazu kann ich jetzt wenig sagen" - das ist alles? Diverse Leute haben > jetzt mehrfach geliefert, aber du selbst kannst weder zu diesen > Beispielen etwas vernünftiges sagen, noch ein C-Beispiel effizienter in > Assembler implementieren. Von dir kommt einfach rein gar nichts ausser > Sprüche. Nun mal langsaaam... Auch Du liest und beantwortest zig Beiträge nicht in ein paar Minuten.
Carl D. schrieb: > Besonders wenn man was vergleichen will, ist es besser mindestens zwei > Dinge zu kennen. OK, ich vergaß: Es kann nur Einen geben. Moby scheint nicht mal C zu können, weiss aber, dass Assembler besser ist... (Bin jetzt gespannt, wie er mir das "besser" im Mund umdreht.) Moby A. schrieb: >> Man verzeihe mir bitte meine Unsachlichkeit, aber jetz muss ich mal blöd >> fragen: >> Moby, glaubst du die Scheiße die du hier verzapfst eigentlich wirklich >> selbst? > > Einen Glauben würde ich als rationaler Mensch nicht so vehement > verteidigen ;-) Du solltest bitteschön sachlich bleiben- mit Deiner > Wortwahl erreichst Du eher: Nichts! Doch, obige Frage ist sowas von berechtigt. Seit über 1000 Beiträgen lässt du dich nun nach Strich und Faden zerpflücken. Wirklich, meinst du das alles ernst oder verarschst du uns einfach? Falls du wirklich mit uns spielst, so könntest du das als fairer Sportsmann nach so vielen Beiträgen auch mal zugeben. Falls du nicht spielst...gute Nacht.
Moby A. schrieb: > Nun mal langsaaam... Auch Du liest und beantwortest zig Beiträge nicht > in ein paar Minuten. Das C-Beispiel ist seit gestern oder vorgestern gestellt und war in ein paar Minuten geschrieben. Sollte in Assembler doch auch eine kurze Sache sein, und dann hättest du den Beweis ja erbracht. Also warum nicht?
P. M. schrieb: > als fairer Sportsmann Ach Du meine Güte. Von fairem Sportsgeist mit Betonung auf 'fair' könnte ich ja hier auch ein Liedchen singen. Nein im Ernst, die Hoffnung darauf sollte man in einem solchen Forum schnellstens begraben. Du kannst aber davon ausgehen, daß mir das Thema als langjährigem ASMler schon am Herzen liegt. Freilich ist die Materie offensichtlich so schnell nicht durchdiskutiert. Deshalb brachte ich gleich ein fertiges Beispiel mit klar definierten Vergleichsmerkmalen. Das kann man nun mit einem C-Beispiel toppen oder man kann es eben nicht. > Moby scheint nicht mal C zu können, weiss aber, dass Assembler besser > ist... (Bin jetzt gespannt, wie er mir das "besser" im Mund umdreht.) Für ein Urteil zum Ressourcenverbrauch langt schon mal locker der Blick auf die Fakten, für ein Urteil zum bürokratischen Aufwand langt ein Blick in jedes C-Buch. Für ein Urteil des Handlings beim Erarbeiten von Lösungen langt ein längerer Selbstversuch. Das Ganze garniert mit vielen netten Infos u.a. von Fachkundigen hier aus dem Forum. Für inmundige Umdreherei bin ich allerdings kein Experte, da sind andere besser ;-)
:
Bearbeitet durch User
Robert L. schrieb: > das ist sinnlos, wir kenne doch schon alle seine Ausreden, warum > er die > ASM version dazu nicht abliefern würde... Nochmal ganz klar zum Mitschreiben: Ich liefere hier keine Lösungen für weitere Aufgaben. Spart Euch die Ablenkungsmanöver und kreativen Ausreden. Es gilt mein Beispiel zu toppen. Ich möchte ein fertiges Gegenbeispiel, daß ich selbst kompilieren und auf Funktion testen kann. Danach investiere ich gern mal meine beschränkte Zeit für angeblich so C-vorteilhafte Beispiele wie den gleitenden Durchschnitt usw.usf. Ich finde es ja ohnehin hochnotpeinlich, wieviele gestandene C-Programmierer hier viele gewichtige Worte verlieren aber ein Beispiel simpelster Funktionalität mit dem angeblich so hochprodukiven C für den easy AVR nicht codiert bekommen. Dafür darf ich dann kreativste Ausreden und Schlimmeres entgegennehmen. Robert L. schrieb: > Ist ja wie im Kindergarten. Na immerhin noch einer mit Unterhaltungswert ;-)
:
Bearbeitet durch User
P. M. schrieb: > Eine bessere Spec als einen kompletten Quellcode kann es gar nicht > geben, denn der definiert eindeutig was das Programm tun muss. Und in > diesem einfachen Fall kann man den Code in 2-5 Minuten durchlesen und > komplett verstehen. Zusätzlich hat es sogar noch Kommentare, die den > Code einzelne Abschnitte zusammenfasst. Wenn das nicht ausreicht als > Vorgabe, dann weiss ich auch nicht mehr weiter... Lustig. Das hatte ich auch schon mal angenommen. Wie utopisch. Daß dann aber weder meine wörtliche Beschreibung mit klarem Output-Diagramm als auch die >300 Beiträge meines Projektthreads nicht zum vollständigen Verständnis des bischen Funktion langen hätte ich dann doch nicht zu träumen gewagt ;-) P. M. schrieb: > Ohne mindestens ein > FH-Studium oder ein paar Jahre Berufserfahrung als Software-Entwickler > kann man dich hier dann wirklich überhaupt nicht mehr ernst nehmen. Meine funktionierenden Projekte darfst Du ernst nehmen. Das tust Du offensichtlich ja auch sonst wärst Du hier nicht weiter munter dabei ;-) Karl H. schrieb: > Weil es mich ehrlich gesagt überhaupt nicht wirklich interessiert. Du > weigerst dich ja auch beharrlich auf meinen Vergleichs-Vorschlag > einzugehen. > Dabei würde es mich wirklich interessieren, was ein guter Assembler > Programmierer aus meiner schnell hingeschusterten Heizungssteuerung noch > rausholen kann. Das hatte ich schon befürchtet, daß zur vollständigen Funktionalität Deines Codes noch einiges fehlt. Die Frage ist warum Du überhaupt damit angefangen hast. Interessieren tut hier nur eine vollständige, vergleichbare Lösung. Privat hätte ich auch so manches zu vergeben ;-) > Du wirst nicht nur mit > den AVR-Registern auskommen sondern wirst dir ein Konzept zur > Registerbenutzung überlegen müssen. Hatte ich das nicht schon? Was hälst Du denn von meinem Konzept? Für meine Begriffe ist es das sinnvollste...
Bernd N. schrieb: > Also das hoch effiziente ASM Programm holt zwei 10 BIT Analogwerte und > zwei Digitalwerte. Was passiert den mit den Werten ? Lass Dir die Funktion im Projektthread erklären. > Weiter schreibst du... >>> Das heißt natürlich nicht, dass nun keine Erweiterungen denkbar wären. >>> Das könnte zum Beispiel... >>> - Vorverarbeitung der Messwerte >>> - Prüfen auf Bedingungen >>> - Ergänzen eines Schalttransistors > Ist doch ne Idee, mh, geht das denn ? Da braucht es doch dann Mathematik > die auf so kleinen MCs gar nicht hinzubekommen ist. Du meine Güte, was denn für großartige Mathematik? Im Flash ist für obige Funktionalität noch 80% Platz frei. Damit lässt sich absolut was anfangen. Natürlich kann man jetzt Anforderungen beliebig hochschrauben- wie fantasievoll. Wenn es Dir an selbiger für den noch freien Platz fehlt kann ich Dir aber leider nicht helfen. Irgendwann hat jeder MC seine Grenze, vermutlich kennst Du auch nur fetten C-Code !? Wie Du dem Projekt entnehmen konntest handelt es sich primär nur um einen Zubringer zu einem größeren System mit dem Sinn, zwei analoge 10-bittige (und zwei digitale) Messwerte über ein längeres, ungeschirmtes Kabel verfügbar zu machen.
:
Bearbeitet durch User
Frank M. schrieb: > Er ist Hobbyprogrammierer und hat den ASM-Befehl EOR vor etwa 4 Jehren > kennengelernt: Erstmalig benötigt. Tatsächlich ist eben eine Teilmenge der AVR-Instruktionen zumeist ausreichend. Wußtest Du natürlich vorher. Frank M. schrieb: > Das heisst, Du bekommst jedes erdenkliche "typische 8-Bit-Programm" in > einen Tiny13 gequetscht, weil Du in ASM programmierst? Du brauchst also > niemals mehr den Prozessor wechseln? Es passt alles in einen Tiny13? Es passt alles in AVRs- vom Tiny bis zum Xmega. Hattest Du gerade wieder vergessen. Frank M. schrieb: > Man kann an seiner Aussage nicht nur seinen persönlichen Horizont > erkennen, sondern auch deren Schwachsinnsgehalt. Ich finde ja reichlich schwachsinnig, wie Du ohne Unterlaß nicht nur mein Projekt mit sinnlosen Einwürfen zu torpedieren versuchst, permanent die gleichen dämlichen Unterstellungen machst und mich wo es nur irgend geht lächerlich machen möchtest. Mit etwas mehr Horizont hättest Du längst erkannt, daß damit nichts Konstruktives zu erreichen ist. Versuch doch Mod zu werden, dann darfst Du endlich Asm-Beiträge nach Belieben löschen und Asm-Threads beenden... Die lassen Deinen fetten C-Code einfach zu schlecht aussehen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > vermutlich kennst Du auch nur fetten C-Code Moby A. schrieb: > Deinen fetten C-Code Woher bringt dich denn eigentlich immer zu dieser Annahme, C-Code sei fett? Ich dachte deine einzige C-Erfahrung war ein mehr oder weniger gescheitertes DOS-Programm (also x86). Hast du dir davon das Assembler-Listing angeschaut und Verbesserungspotential entdeckt? Falls du dieses Märchen hier aus dem Forum hast würd ich vorschlagen die Beiträge hier weniger selektiv zu lesen. Deine These mag sich auf Beiträgen von solch Gestalten wie unsren c-hater, W.S. etc. stützen. Dann frag ich mich aber wieso du soviel auf deren Meinung gibst, Argumente von nachweislichen Experten die seit Jahrzehnten in beiden Welten (eher: in zig Welten) unterwegs sind ignorierst. Weils ins eigene Weltbild passt?
Moby A. schrieb: > Spart Euch die Ablenkungsmanöver und kreativen > Ausreden. Es gilt mein Beispiel zu toppen. das mit dem x < 100000 meinst du, oder ;-) die C-Version war im Ergebnis kürzer als deine ASM Version Wenn also die Vorteile bei einem SOO kurzen Beispiel schon so glasklar sind, brauchen wir uns über "größere" Projekte ja nicht zu unterhalten, solange du keine bessere ASM lösung ablieferst..
le x. schrieb: > Woher bringt dich denn eigentlich immer zu dieser Annahme, C-Code sei > fett? Das ist ein Axiom seines Weltbildes und somit unwiderlegbar.
>Bis 32 Bit hab ich fertige Routinen...
hier könnte man übrigens gut belegen dass ein C-Compilter besser im
Routinen aussuchen ist als du, aber das willst ja eh nicht wissen..
Moby A. schrieb: > Die lassen Deinen fetten C-Code > einfach zu schlecht aussehen ;-) Diese Wahrnehmungsstörung erinnert mich ein wenig an Bulimiker. Die können aussehen wie Haut und Knochen kurz vor dem Exitus, und empfinden sich dennoch als fett.
P. M. schrieb: > Doch, obige Frage ist sowas von berechtigt. Seit über 1000 Beiträgen > lässt du dich nun nach Strich und Faden zerpflücken. Wirklich, meinst du > das alles ernst oder verarschst du uns einfach? Ich habe schon öfter behauptet, dass er bewusst trollt. Möglicherweise ist das aber gegen die Foremregeln, da es regelmäßig gelöscht wurde???
Gu. F. schrieb: > Ich habe schon öfter behauptet, dass er bewusst trollt. Meiner Meinung nach weiss er natürlich alles, was andere ihm beizubringen versuchen, schon lange. Den Rest kann sich jeder denken. > Möglicherweise ist das aber gegen die Foremregeln, da es regelmäßig > gelöscht wurde??? Wir löschten das nur dann, wenn er mit seiner Meinung in Threads auftauchte, die damit nichts zu tun hatten. Hier darf er gerne schreiben. Edit: Noch vergessen: ;-) ;-) ;-)
:
Bearbeitet durch Moderator
Moby A. schrieb: > für ein Urteil zum bürokratischen Aufwand langt ein > Blick in jedes C-Buch. Ja, da siehst Du ganz toll die Beschreibungssprache die sich am englischen Wortschatz und mathematischen Grundbegriffen orientiert um Lesbarkeit und intuitives Verständniss zu fördern. Welch kurzen und eleganten ASM Konstruktionen der Compiler daraus macht kannst Du aber in keinem C Buch lesen. Kann es sein das Dein Kampf mit C bereits bei der englischen Sprache anfängt? Ist jetzt nicht böse gemeint, aber da könnte ich ein klein wenig besser verstehen warum Du C kryptisch findest. Zwei Fremdsprachen auf ein Mal zu lernen ist natürlich schwerer. Andererseits sollte dann auch das AVR Datasheet eine echte Hürde für Dich sein. Moby A. schrieb: > Für ein Urteil des Handlings beim Erarbeiten von > Lösungen langt ein längerer Selbstversuch. Ja genau, und da war für mich nach dem ersten erfolgreich kompiliertem 'HELLO WORLD' Program klar das ich mich mit C ganz wohlfühle. Ja, Asche auf mein Haupt, ohne Informatik Studium bin ich natürlich tatsächlich nicht in der Lage manche Konstruktionen zu verstehen die ein Informatiker völlig selbstverständlich dahinzaubert. Das schöne ist, das ich das meistens auch nicht wissen muß weil es reicht mich an bestimmte Konventionen zu halten und copy / paste Beispiele so lange zu verfeinern bis mich der Schatten einer Ahnung überkommt und es einfach funktioniert. Klar, es gab eine gewisse Frustration bis ich das Zusammenspiel der C toolchain verinnerlicht hatte. Zum einen sind die IDEs heute soweit das ich nur in seltenen Fällen noch tiefer gehen muß, zum anderen muß ich mich ohne C viel tiefer in die Internas der jeweiligen MCU einarbeiten was im Endeffekt viel mehr Zeit kostet. > beim Erarbeiten von Lösungen Eben, Du sagst es Moby. Eine Lösung wird erarbeitet. Einer Lösung ist es aber egal ob noch 10 Bytes mehr frei sind im Ram oder 100Bytes mehr im Flash. Eine Lösung produziert von aussen betrachtet ein Ergebniss. Signale gehen rein, Signale gehen raus. Wenn ein in einer beliebigen Sprache geschriebenes Programm diese verbindlichen Vorgaben erfüllt, dann ist es prinzipiell erstmal ein gutes Programm. Um so besser wenn ich es schnell schreiben konnte, noch besser wenn es auch Jahre später noch ein fremder Programmierer schnell verstehen und ändern kann. 8051 Basic hat selbst fast alle Ressourcen gebraucht. Pascal war kaum für MCUs verfügbar. Bascom-AVR war auf eine MCU Familie beschränkt (ebsenso ASM) C war die erste Sprache die mich weit von der Hardware löst wenn ich das will, mir aber wirklich alle Freiheiten läßt wenn ich es darauf anlege. Ich erlebe gerade ein schönes Beispiel für Licht und Schatten höherer Programmiersprachen. Für eine frisch entwickelte Hardware brauche ich ein steuerndes PC Programm das ein wenig schick ist, also GUI, leicht auf andere Systeme portierbar und durch die späteren Kunden meiner Hardware leicht an eigene Bedürfnisse anpassbar. Ich bin bei Python gelandet und ich hasse es aus tiefstem Herzen. Python + Tk wird laufend kaputtgeändert. Beispiele die unter Python 3.3 noch liefen versagen jetzt Ihren Dienst. Irgendjem gefiel die Syntax nicht und war der Meinung das Dinge die vorher klein geshrieben wurden jetzt groß geschrieben werden müssen, oder einfach anders. Argumente die ich vorher hintereinander wegschreiben konnte müssen nun in einer Tiporgie ganz anders geschreiben werden um genau das gleiche zu tun. Im Netz liegen tausende Beispiele die aber immer nur für eine nicht näher bezeichnete Version funktionieren. Zudem kapier diesen objektorientieren Klassen udn Vererbungs K*ck ehrlich gesagt nicht ganz. So weit so schlecht. Trotz allem habe ich es binnen einer Woche geschafft ein kleines Programm zu schreiben das unter Ausnutzung von extrem mächtigen Bibliotheken, die ich allesamt kein bißchen kapiert habe, mit Schiebereglern und grafischer Echtzeitdarstellung meine Hardware zu steuern. Unter Windows und unter Linux. Wie geil ist das denn ? Natürlich bin ich oft frustriert weil ich nicht wirklich weiß was ich da gerade mache und warum, aber das Ergebniss das ich mit diesem herumgestümper erreiche hätte ich anders nicht erreicht. Das motiviert mich weiterzumachen und mich in diese merkwürdige Sprache hineinzuarbeiten die die Dinge auf eine mir völlig unverständliche Art löst. Irgendwann wird der Groschen fallen und ich werden das was ich heute als überbordende Bürokratie empfinde als nützliche Spracheigenschaften zu schätzen wissen. Die Flinte ins Korn zu werfen und das alles blöd zu finden verurteilt mich dazu auf dem Level zu bleiben auf dem ich heute bin. Ich habe mich mal bei einem studiertem Informatiker darüber ausgeheult das ich Python nicht verstehe. Die Antwort war: 'Niemand versteht Python' Das hat mir echt geholfen.
Michael K. schrieb: > jeweiligen MCU einarbeiten > was im Endeffekt viel mehr Zeit kostet. Das ist aber egal, wie viel Zeit verbraten wird, solange ein Byte RAM/FLASH gespart werden kann. Das ist Mobys beschränkte Welt.
Moby A. schrieb: > Karl H. schrieb: >> Weil es mich ehrlich gesagt überhaupt nicht wirklich interessiert. Du >> weigerst dich ja auch beharrlich auf meinen Vergleichs-Vorschlag >> einzugehen. >> Dabei würde es mich wirklich interessieren, was ein guter Assembler >> Programmierer aus meiner schnell hingeschusterten Heizungssteuerung noch >> rausholen kann. > > Das hatte ich schon befürchtet, daß zur vollständigen Funktionalität > Deines Codes noch einiges fehlt. Nö. Eigentlich fehlt nichts. Nur weil ich sage, dass ich das schnell hingeschustert habe, bedeutet das noch lange nicht, dass sie nicht vollständig wäre. Ich könnte mich rann setzen und ein paar Stellen eleganter schreiben, funktional bringt das keinen Mehrwert. Die Steuerung tut das, was sie tun soll. Und das seit 5 Jahren. >> Du wirst nicht nur mit >> den AVR-Registern auskommen sondern wirst dir ein Konzept zur >> Registerbenutzung überlegen müssen. > > Hatte ich das nicht schon? Du hast so viel von dir gegeben, dass ich schon längst den Überblick verloren habe, was du gesagt hast und was nicht.
Moby A. schrieb: >> Er ist Hobbyprogrammierer und hat den ASM-Befehl EOR vor etwa 4 Jehren >> kennengelernt: > > Erstmalig benötigt. Tatsächlich ist eben eine Teilmenge der > AVR-Instruktionen zumeist ausreichend. Wußtest Du natürlich vorher. Natürlich kann man auch mit dem halben Befehlssatz funktionierende Programme schreiben. Mit Effizienz hat das aber nichts mehr zu tun.
Moby A. schrieb: > Nochmal ganz klar zum Mitschreiben: Ich liefere hier keine Lösungen > für weitere Aufgaben. > Es gilt mein Beispiel zu toppen. Mal angenommen, es gelänge tatsächlich niemandem, dein Programm in C kürzer (auf den Binärcode bezogen) zu schreiben. Was hättest du damit bewiesen? Dass ein ca. 200 Byte großes Programm in Assembler möglicherweise kürzer ist, wenn man in stundenlanger Kleinarbeit jeden einzelnen Befehl so lange dreht und wendet, bis man auch das letzte überflüssige Byte wegoptimiert hat. Nicht mehr und nicht weniger. Wie ich aber früher schon geschrieben habe, interessiert das außer dir kein Huhn auch nur im Allergeringsten, da der ATtiny13 die fünffache Menge Flash-Speicher hat. Deswegen (und wegen deiner ziemlich volatilen Anforderungen an den Programmcode) ist kaum jemand sonderlich motiviert, Arbeit in die Umsetzung in ein C-Programm zu inverstieren. Dein Argument, dass der Code ja vielleicht irgendwann erweitert werden soll, zieht überhaupt nicht. Denn sobald die Code in Richtung 1 KB geht, wirst auch du ihn nicht mehr mit der gleichen Intensität handoptimieren, da der Aufwand dafür mindestens quadratisch mit der Codergröße steigt. Hier wird i.Allg. ein C-Programm größenmäßig gleich gut oder besser, bei der Entwicklungszeit sogar sehr viel besser abschneiden. Wenn deine Aussage also lautet: "Bei Programmen bis ca. 200 Bytes hat die Assembler-Programmierung keine großen Nachteile, aber auch kaum Vorteile." stimme ich (und sicher auch viele andere Diskutanten) dir auch ohne Wettbewerb zu, und wir können die Diskussion beenden. Wenn du aber behauptest: "Assembler bringt auch bei größeren Programmen Vorteile, solange darin keine Arithmetik mit mehr als 8 Bit stattfindet." widerspreche ich (und praktisch alle andere Diskutanten) dir trotz der Einschränkung bei der Arithmetik ganz entschieden. Solltest du an dieser Aussage trotzdem festhalten, liegt es an dir, sie zu beweisen. Das kann dir aber logischerweise nicht mit einem 200-Byte-Progrämmchen gelingen. Solange du diesen Beweis nicht erbracht hast, steht die Aussage eines einzelnen Assembler-Only-Programmierers gegen diejenige von zig Leuten, die Erfahrung in Assembler und C haben. So ist nun mal die Situation und nicht anders. Es hängt jetzt ganz alleine von dir ab, ob sich die Diskussion weiterhin endlos im Kreis dreht, ob vielleicht mal wieder etwas frischer Wind hineinkommt, oder ob wir sie einfach beenden.
Moby A. schrieb: > Meine funktionierenden Projekte darfst Du ernst nehmen. Funktionierende Assembler-Projekt_chen_, aus denen du ableitest, Hochsprachen würden die halbe oder die ganze Software-Welt verderben. Ich will die Studium-Frage nicht nochmals hochkochen, es ging dabei einzig und alleine darum, ob du überhaupt einen minimalen Erfahrungsschatz mitbringst, auf den du deine Ansichten stützt. Die Antwort ist klar: Nein, denn du vergleichst zwar Assembler mit Hochsprachen, kannst aber noch nicht mal eine einzige davon. Du hast somit vermutlich auch noch nie etwas davon gehört, wie Compiler-Optimierung funktioniert oder wo die Flaschenhälse bei heutiger Software-Entwicklung liegen. Kurz: Du bist wirklich nicht qualifiziert, in diesem Thread mitzudiskutieren. Obendrauf, du schaffst es noch nicht mal, in deinem kleinen Bereich richtig Fakten zu liefern. Du kannst das C-Beispiel nicht übersetzen und du quittierst die Untersuchung anderer mit "dazu kann ich jetzt nichts sagen".
Stefan K. schrieb: > Natürlich kann man auch mit dem halben Befehlssatz funktionierende > Programme schreiben. Yep. Moby sollte ich mal der Turing-Maschine widmen. Soweit ich weiss hat dafür noch nie jemand einen vollständigen C-Compiler geschrieben.
Moby A. schrieb: > Robert L. schrieb: >> das ist sinnlos, wir kenne doch schon alle seine Ausreden, warum >> er die ASM version dazu nicht abliefern würde... > > Nochmal ganz klar zum Mitschreiben: Ich liefere hier keine Lösungen > für weitere Aufgaben. Spart Euch die Ablenkungsmanöver und kreativen > Ausreden. Es gilt mein Beispiel zu toppen. Das hat Yalu bereits getan: Beitrag "Re: C versus Assembler->Performance" > Ich möchte ein fertiges Gegenbeispiel, daß ich selbst kompilieren und auf > Funktion testen kann. Das hast Du bekommen, siehe oben. Also spar' Dir die Ablenkungsmanöver und kreativen Ausreden, Du bist an der Reihe.
Gibt's eig. sowas wie eine Forenstatistik über die Bewertungen eines users? Würde mich im Fall Moby mal interessieren.
Moby A. schrieb: > Ich finde ja reichlich schwachsinnig, wie Du ohne Unterlaß [...] permanent > die gleichen dämlichen Unterstellungen machst... > Mit etwas mehr Horizont hättest Du längst erkannt, daß damit nichts > Konstruktives zu erreichen ist. Interessant, was du so von dir gibst. Vor allem diese äusserst konstruktive immer und immer wiederholte Behauptung, die du durch nichts, aber auch gar nichts, belegen kannst: Moby A. schrieb: > Die lassen Deinen fetten C-Code einfach zu schlecht aussehen Hast du überhaupt schon mal einen fetten C-Code gesehen? Bestimmt nicht. Hast du überhaupt schon mal einen hocheffizienten Assembler-Code gesehen? Ganz bestimmt auch nicht. Denn du hast noch nie einen fetten C-Code gesehen. mfg.
A. K. schrieb: > Yep. Moby sollte ich mal der Turing-Maschine widmen. Soweit ich weiss > hat dafür noch nie jemand einen vollständigen C-Compiler geschrieben. Wieso C und nicht TM? Mit GCC kann man inzwischen auch seinen eigenen avr-tm zimmern :-) https://gcc.gnu.org/onlinedocs/gcc-5.2.0/jit/
P. M. schrieb: > Kurz: Du bist wirklich nicht qualifiziert, in diesem Thread > mitzudiskutieren. Moby ist nicht qualifiziert in SEINEM Thread mitzudiskutieren ?
Michael K. schrieb: > Moby ist nicht qualifiziert in SEINEM Thread mitzudiskutieren ? Wo ist dein Problem? Ich könnte hier auch einen Thread über die Stringtheorie anzetteln ohne viel Ahnung davon haben zu müssen.
Johann L. schrieb: > Wieso C und nicht TM? Ich meinte, er solle sich der TM widmen, weil er da schon vorneweg keine Konkurrenz durch C befürchten muss.
Gu. F. schrieb: > Gibt's eig. sowas wie eine Forenstatistik über die Bewertungen eines > users? Würde mich im Fall Moby mal interessieren. Die Bewertungen werden überwiegend nach Sympathie gegeben. Hat mal jemand verschi**en werden alle seine Beiträge schlecht bewertet, auch die guten. Viele machen sich einen Sport daraus alles, wirklich alles von diesem User schlecht zu bewerten. Lächerlich, aber wenn es einem gut tut, bitteschön. Mich würde dann auch die Statistik interessieren wer hier wie viele schlechte Bewertungen gegeben hat und wie viele gute. Gu. F. schrieb: > Wo ist dein Problem? Hochnäsigkeit, ist z.B. ein Problem für mich. Jemanden pauschal die Kompetenz absprechen weil man selber per Definition und Titel automatisch besser ist, ist ein Problem für mich. Sich bevorzugt am basching zu beteiligen statt den Druck rauszunehmen und einen vernünftigen Ton anzuschlagen, ist ein Problem für mich. Persönlich zu werden wenn man mit seinen Argumenten nicht mehr weiterkommt ist ebenfalls ein Problem für mich. Schlechte Bewertungen oder jemanden auf die Füsse zu treten der das meiner Meinung nach verdient hat und das alles unter Klarnamen und für jederman nachvollziehbar: Überhaupt kein Problem für mich.
Michael K. schrieb: > Moby ist nicht qualifiziert in SEINEM Thread mitzudiskutieren ? Ja. Das ist doch auch kein Widerspruch. Du oder ich könnten auch einen Thread eröffnen, um über regelmässig auftretende Probleme der Hälfte der erwachsenen Weltbevölkerung zu diskutieren. Ob wir dazu auch nur einen einzigen konstruktiven Beitrag aus persönlicher Erfahrung beisteuern könnten, wage ich aber sehr zu bezweifeln. mfg.
Michael K. schrieb: > Ich bin bei Python gelandet und ich hasse es aus tiefstem Herzen. > Python + Tk wird laufend kaputtgeändert. Meine uralten Tk- und Tix-Programme laufen bis heute unverändert auf allen Python-Versionen < 3, so daß ich mich über solche Aussagen sehr wundere. Wenn man es schick haben will, benutzt man übrigens lieber Tix als Tk, und wenn es wirklich hübsch werden soll, Qt. Das hat auch den Vorteil, daß man sein Programm relativ leicht auf C++ portieren kann. Und wer modern sein will, baut heute keine Fat-Clients mit GUI mehr, sondern ein Webinterface mit -- zum Beispiel -- Flask. > Beispiele die unter Python 3.3 noch liefen versagen jetzt Ihren Dienst. Die einzige größere Änderung in den letzten Jahren war der Schritt von Python 2.x zu Python 3.x, aber auch diese Änderung ist von überschaubarem Umfang und erfordert, wenn man zuvor sauber programmiert hat, eher wenig Anpassung. Und weil das so überschaubar und einfach ist, kann das sogar automatisiert mit einem kleinen Skript geschehen, das mitgeliefert wird und "2to3.py" heißt. Die Unterschiede zwischen Python 2.x und Python 3.x betreffen meist eher fortgeschrittene und exotische Features, und sind in der Praxis ziemlich überschaubar. Einen guten Überblick über die Änderungen mit Codebeispielen findest Du hier: http://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html > Zudem kapier diesen objektorientieren Klassen udn > Vererbungs K*ck ehrlich gesagt nicht ganz. Das ist bei der Entwicklung von GUI-Software ein echtes Problem, das Du unbedingt angehen solltest, wenn Du so etwas öfter machen willst. Aber keine Sorge, an sich ist das gar nicht so schwer. > Ich habe mich mal bei einem studiertem Informatiker darüber ausgeheult > das ich Python nicht verstehe. Die Antwort war: 'Niemand versteht > Python' Wenn ein studierter Informatiker das nicht versteht, dann hat er seinen Beruf verfehlt -- ich habe schließlich nicht einmal Informatik studiert und, von Perl kommend, Python in knapp einer Woche verstanden. Tatsächlich ist Python nämlich sehr einfach und deswegen nicht nur bei Nicht-Informatikern, sondern auch für als erste Sprache für Grundschüler besonders beliebt. Vor allem in der Finanzwirtschaft wird besonderen Wert die Kontinuität und die Langzeitstabilität von Softwarelösungen gelegt, und auch da erfreut sich Python großer Beliebtheit. Vielleicht magst Du ja einen eigenen Thread aufmachen und dort über Deine Schwierigkeiten und Verständnisprobleme mit Python diskutieren. Es gibt hier außer mir sicher auch noch andere, die Dir dabei gerne helfen.
Thomas E. schrieb: > Du oder ich könnten auch einen Thread eröffnen, um über regelmässig > auftretende Probleme der Hälfte der erwachsenen Weltbevölkerung zu > diskutieren. Ob wir dazu auch nur einen einzigen konstruktiven Beitrag > aus persönlicher Erfahrung beisteuern könnten, wage ich aber sehr zu > bezweifeln. Zu unserem großen Glück hat Andreas hier ein Forum geschaffen in dem jeder diskutieren darf. Ich persönlich spreche ja einigen Teilnehmern die persönliche Kompetenz ab sich in einem öffentlichen Forum mit widersprüchlichen Meinungen und Ansichten auseinanderzusetzen. Die fachliche Kompetenz mag ja teilweise vorhanden sein, aber herje was da oft von sich gegeben wird da kann es einem schon grausen. Damit muß ich aber zurechtkommen, denn das sind die Regeln. Für die harten Fälle gibt es dann den Moderator der eingreift. Stell ich mich jetzt hin und sage: 'Du darfst hier jetzt mal die Klappe halten, denn Deine Fähigkeit wie ein Erwachsener verbal Probleme zu lösen und mit Konflikten umzugehen ist stark verbessererungswürdig' Nein, tue ich nicht, denn das steht mir nicht zu. Ich kann mein eigenes Forum aufmachen und da König spielen.
Gu. F. schrieb: > Gibt's eig. sowas wie eine Forenstatistik über die Bewertungen eines > users? Würde mich im Fall Moby mal interessieren. So gesehen halte ich es für sinnvoller, nicht +1 oder -1 eins beim Drücken der Bewertung zu rechnen, sondern direkt anzuzeigen, wie viele "lesenswert" und "nicht lesenswert" gedrückt haben. Thomas E. schrieb: > Moby A. schrieb: >> Die lassen Deinen fetten C-Code einfach zu schlecht aussehen Langsam glaube ich, Moby vergleicht den (compilierten) ASM-Code mit der Dateigrösse alle c/h-Files.
Sheeva P. schrieb: > Meine uralten Tk- und Tix-Programme laufen bis heute unverändert auf > allen Python-Versionen < 3, so daß ich mich über solche Aussagen sehr > wundere. Wie gesagt, ich weiß das ich ein absoluter Python Stümper bin. Die Problem die ich derzeit noch damit habe liegen mit Sicherheit an mir, aber ich verzeihe mir das, weil ich da ganz am Anfang stehe. Mit meinem kleinen Code habe ich so ziemlich das ganze Sprachkonzept vergewaltigt und das rächt sich nun. Ich kann ja nicht mal genau sagen ob meine Probleme am Python, am TK an PyCharm oder Anaconda liegen. Es sollte auch eher ein Bespiel dafür sein wie das Ergebniss einer sehr schlecht beherrschten Hochsprache trotzdem besser ist als alles was man ohne diese erreicht hätte. Ohne Frust und eine gewisse Verbissenheit lernt man nunmal nichts neues.
Moby A. schrieb: >> Es wird von allen Nutzbytes die Summe >> gebildet und die zwei LSB bits übertragen, richtig? > > Nein, alle 1er Bits werden schlicht gezählt und die zwei > niederwertigsten Bits der Summe dann drangehängt. Das wurde allerdings > erst später im Thread so geändert weil auf Hinweis von Yalu die einfache > Summe etwas witzlos ist. Zu finden später im Projektthread. Danke. Eigentlich wollte ich mich nicht durch den ellenlangen Thread durchkämpfen, aber jetzt sehe ich, dass dort Andere für dich die Anforderungsspezifikation erstellt und fortlaufend verfeinert haben. Es kommt in meinem Code eine triviale Checksummenfunktion hinzu, das macht das den C-Kohl auch nicht fett. Und ich habe jetzt noch den Fehler gesehen, dass ich die Bits in falscher Reihenfolge sende, das ist in der Senderoutine im Handumdrehen geändert. Hab die Änderungen eben ausprobiert - 2% mehr Flashverbrauch also jetzt 18% - ändert nichts an meinem Fazit. Über 80% der Ressourcen eines PIC12F675 liegen bei dieser trivialen Aufgabe brach - trotz C ;-)
Michael K. schrieb: > Jemanden pauschal die Kompetenz absprechen weil man selber per > Definition und Titel automatisch besser ist, ist ein Problem für mich. Du beziehst dich wohl auf mich und ein, zwei meiner Posts. Ich habe dort kein Wort von einem Titel geschrieben, ich habe einzig verlangt, man solle über einen entsprechenden Wissens-/Erfahrungsschatz verfügen - Studium, Berufserfahrung oder meinetwegen auch "nur"* Hobby. Der einzige, der immer wieder mit Titeln kommt, bist eigentlich du. Was die Frage sachlich/nicht sachlich angeht: Auf einer sachlichen Ebene ist der Thread schon längst erledigt. Wir sind uns ja alle einig, und Moby scheint weder fähig noch willens zu sein, unsere gefestigte Position zu widerlegen. Es geht nun wirklich nur noch darum, Moby klarzumachen, wie absurd (und teilweise unsportlich) er sich in dieser Diskussion verhält. ___ * "nur" deshalb, weil man in einem Hobby rein schon stundenmässig kaum so viel Erfahrung aufbauen kann, wie wenn man etwas Vollzeit betreibt.
>etwas Vollzeit betreibt,
nur kurz dazu: Vollzeit als Programmiere, ist oft nur ein "Fließband"
job..
und/oder auch oft sehr Spezialisiert auf irgend ein spezialgebiet..
als Hobby hat man dann doch oft sehr unterschiedliche "Gebiete"..
wer Informatik studiert, wird wohl kaum als Programmierer arbeiten,
sondern als Softwareentwickler(=architekt).. und Programmieren lassen..
:
Bearbeitet durch User
Witkatz :. schrieb: > Hab die Änderungen eben ausprobiert - 2% mehr Flashverbrauch also jetzt > 18% - ändert nichts an meinem Fazit. Über 80% der Ressourcen eines > PIC12F675 liegen bei dieser trivialen Aufgabe brach - trotz C ;-) Das ändert jetzt leider nichts daran, daß ich es nicht nachprüfen und mir keine weiteren Aussagen dazu erlauben kann. Aus meiner Erinnerung an PIC-Asm heraus wär ich allerdings auch schon längst auf C umgestiegen ;-) P. M. schrieb: > Moby scheint weder fähig noch willens zu sein, unsere gefestigte > Position zu widerlegen Sowas kann man sich auch einreden ;-) Du meintest doch kein "gefestigtes" C-Code Beispiel? Natürlich nicht irgend ein Brocken, sondern ein vollständiges, wirklich vergleichbares Programm? WO ist es ???
Moby A. schrieb: > P. M. schrieb: >> Moby scheint weder fähig noch willens zu sein, unsere gefestigte >> Position zu widerlegen > > Sowas kann man sich auch einreden ;-) > Du meintest doch kein "gefestigtes" C-Code Beispiel? > Natürlich nicht irgend ein Brocken, sondern ein vollständiges, wirklich > vergleichbares Programm? WO ist es ??? Na hier: Beitrag "Re: C versus Assembler->Performance"
Moby A. schrieb: > Du meintest doch kein "gefestigtes" C-Code Beispiel? > Natürlich nicht irgend ein Brocken, sondern ein vollständiges, wirklich > vergleichbares Programm? WO ist es ??? Hier ist es:
1 | void main(){ |
2 | |
3 | uint8_t threshold = 89; |
4 | |
5 | uint8_t value_ptr = 0; |
6 | uint8_t last_values[8] = {0, 0, 0, 0, 0, 0, 0, 0}; |
7 | |
8 | ADC_CONFIG |= (1 << ADC_ON); |
9 | UART_CONFIG = ...; // set some bits here |
10 | |
11 | |
12 | while(true){ |
13 | if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){ |
14 | |
15 | // save value into ringbuffer
|
16 | last_values[value_ptr] = ADC_VALUE; |
17 | |
18 | // increase ringbuffer pointer
|
19 | value_ptr ++; |
20 | value_ptr %= 8; |
21 | |
22 | // sum up values in ringbuffer
|
23 | uint16_t sum = 0; |
24 | for(uint8_t i = 0; i < 8; i ++){ |
25 | sum += last_values[i]; |
26 | }
|
27 | |
28 | // check if average in ringbuffer exceeds threshold
|
29 | // if yes, send over uart
|
30 | if(sum / 8 > threshold){ |
31 | UART_DATA = sum / 8; |
32 | UART_CONFIG |= (1 << UART_DO_SEND); |
33 | }
|
34 | |
35 | }
|
36 | }
|
37 | }
|
Ich brauchte in kryptischem, kompliziertem C etwa 5 Minuten, um das Beispiel aufzusetzen. Sollte in Assembler ja auch recht schnell gehen. Also zeig doch mal. Du kannst mit deinen Ansichten noch so recht haben, aber wenn du nichts zeigen kannst, dann wird dir niemand glauben.
Stefan K. schrieb: > Moby A. schrieb: >>> Er ist Hobbyprogrammierer und hat den ASM-Befehl EOR vor etwa 4 Jehren >>> kennengelernt: >> >> Erstmalig benötigt. Tatsächlich ist eben eine Teilmenge der >> AVR-Instruktionen zumeist ausreichend. Wußtest Du natürlich vorher. > > Natürlich kann man auch mit dem halben Befehlssatz funktionierende > Programme schreiben. Mit Effizienz hat das aber nichts mehr zu tun. Man kann sogar C-Programme schreiben, ohne Konstrukte zu verwenden, die man nicht versteht. So Regelsätze wie MISRA, wie auch immer man dazu steht, sind dazu da, Fehlerquellen durch Verbot zu eliminieren. Aber wenn ich z.B. in C++ Templates nicht verstehe, darf ich trotzdem die Vorzüge von überladenen Funktionen benutzen. (Aber nicht in dem Zusammenhang "überladen" absichtlich falsch verstehen wollen!)
Carl D. schrieb: > Man kann sogar C-Programme schreiben, ohne Konstrukte zu verwenden, die > man nicht versteht. So Regelsätze wie MISRA, wie auch immer man dazu > steht, sind dazu da, Fehlerquellen durch Verbot zu eliminieren. > Aber wenn ich z.B. in C++ Templates nicht verstehe, darf ich trotzdem > die Vorzüge von überladenen Funktionen benutzen. Ist IMHO genau der richtige Ansatz, wenn man sich einer Sprache noch nicht mächtig fühlt. Gerade C ist zu 90% "Assembler strukturiert in Syntax". Für die meisten Konstrukte kann man sich die Assembler-Umsetzung eins zu eins denken. C ist auch frei von jeglichen "Black-Box" Konzepten, deren Funktionsweise man erstmal kennen muss, wie z.B. virtuelle Vererbung oder Template Deduction und ihre ganzen Regeln in C++.
Zustimmung. Ich habs vor paar hunderten Beiträgen ja auch schon geschrieben: C ist so nah an der Hardware/ASM wie sonst keine Hochsprache (böse Zungen bezeichnen es nicht umsonst als Makroassembler). Deswegen versteh ich auch nicht wieso er sich C als Feindbild gesucht hat und nicht z.B. Java oder Python, wo man wirklich nicht mehr weiß was die Library/VM/Interpreter genau macht. Naja außer natürlich dass er mit Java und Python wahrscheinlich noch weniger Kontakt hatte als mit C, nämlich 0. Alles, aber wirklich alles spricht dafür, dass er sich das eigene Scheitern schönreden muss.
Carl D. schrieb: > Man kann sogar C-Programme schreiben, ohne Konstrukte zu verwenden, die > man nicht versteht. Den halben Befehlssatz nicht zu kennen ist aber was anderes als ihn nicht zu benutzen.
le x. schrieb: > Alles, aber wirklich alles spricht dafür, dass er sich das eigene > Scheitern schönreden muss. Das dürfte es wohl sein. Leider beobachtet man solche Threads im Forum immer wieder, des öfteren auch in "Ausbildung und Beruf", nicht nur von Moby.
Gu. F. schrieb: > Carl D. schrieb: >> Man kann sogar C-Programme schreiben, ohne Konstrukte zu verwenden, die >> man nicht versteht. > > Den halben Befehlssatz nicht zu kennen ist aber was anderes als ihn > nicht zu benutzen. Hatte ich auch nicht behauptet, oder? Ich wollte vielmehr die Diskrepanz zwischen M.'s Aussagen kommentieren, daß man nicht alle Befehle kennen muß, aber unbenutzte C-Konstrukte schwer auf des Programmieres Seele lasten.
:
Bearbeitet durch User
P. M. schrieb: > Hier ist es: Also wieder nix. Spar Dir diese Art Mühen. Warum scheuen bloß alle die Umsetzung meines bischen Funktionalität, einen schnellen reellen Vergleich, ein schnelles Ende jeglicher Diskussion hier wie der Teufel das Weihwasser ? P. M. schrieb: > Gerade C ist zu 90% "Assembler strukturiert in > Syntax". Für die meisten Konstrukte kann man sich die > Assembler-Umsetzung eins zu eins denken. C mag Asm zwar näher kommen als andere Hochsprachen, aber es ist eben nicht dasselbe ;-) le x. schrieb: > er sich C als Feindbild gesucht Blödsinn. C wurde mir aber hier zu oft als allumfassend überlegene Sprache angepriesen die es definitiv nicht ist. Ein Effizienz-Gegenbeispiel von mir steht zur Begutachtung bereit! le x. schrieb: > Alles, aber wirklich alles spricht dafür, dass er sich das eigene > Scheitern schönreden muss. Da kann ich ja nur lachen. Wirklich. Dafür arbeitet in meiner Umgebung schon zuvieles mit easy Asm... Geschmeidig, smart, effizient. Carl D. schrieb: > Ich wollte vielmehr die Diskrepanz zwischen M.'s Aussagen kommentieren, > daß man nicht alle Befehle kennen muß, aber unbenutzte C-Konstrukte > schwer auf des Programmieres Seele lasten. Kennen sollte man schon alle MC-Instruktionen, auch wenn längst nicht immer alle benötigt werden. Das ist kein Problem, denn der eigentliche Funktionsumfang einer Asm-Instruktion ist simpel. Auf der Seele des C-Programmierers lasten hingegen schon ein paar mehr beachtenswerter Dinge ;-)
:
Bearbeitet durch User
le x. schrieb: > Woher bringt dich denn eigentlich immer zu dieser Annahme, C-Code sei > fett? Mehr Bürokratie. Mehr Schreibbedarf. Mehr Ressourcenverbrauch. Code-Intransparenz, die zu noch mehr Ressourcenverbrauch führen kann. Entgegensteuern lässt sich wieder nur mit erhöhtem Lernaufwand... > Ich dachte deine einzige C-Erfahrung war ein mehr oder weniger > gescheitertes DOS-Programm (also x86). Da ist nichts gescheitert. Aber da ist mir ein Licht aufgegangen ;-) > Hast du dir davon das Assembler-Listing angeschaut und > Verbesserungspotential entdeckt? Nö. Ich hab zwar auch mal ein natives Asm-Programm für'n 486er geschrieben, mich aber in x86er Asm nicht sonderlich vertieft. Wir reden hier von AVR-Asm ! > Deine These mag sich auf Beiträgen von solch Gestalten wie unsren > c-hater, W.S. etc. stützen. Du bist mir auch so ne Gestalt. Wer bist Du, daß Du so über andere redest? Gerade die beiden leisten hier sehr fachlich fundierte Beiträge. Man muß nicht mit allem einer Meinung sein. Bin ich auch nicht. > Weils ins eigene Weltbild passt? Reden wir doch nicht gleich über Weltbilder! Es langt, ein C-Gegenbeispiel zu einer einfachen, fertigen Asm-Vorlage zu liefern!
Moby A. schrieb: > Also wieder nix. Spar Dir diese Art Mühen. > Warum scheuen bloß alle die Umsetzung meines bischen Funktionalität, > einen schnellen reellen Vergleich, ein schnelles Ende jeglicher > Diskussion hier wie der Teufel das Weihwasser ? Das ist doch schon geschehen: Beitrag "Re: C versus Assembler->Performance" > C wurde mir aber hier zu oft als allumfassend überlegene > Sprache angepriesen die es definitiv nicht ist. Du argumentierst gegen etwas, das außer Dir selbst nie jemand behauptet hat. Das nennt man ein Strohmann-Argument, Du kämpfst gegen Windmühlen. > Ein Effizienz-Gegenbeispiel von mir steht zur Begutachtung bereit! Für andere Menschen sind der von ihnen selbst zu betreibende Aufwand und vor allem die selbst aufzuwendende Lebens- und Arbeitszeit wesentlicher, wenn nicht sogar der wichtigste Faktor bei der Beurteilung von Effizienz. Du hingegen beschränkst diesen Begriff auf einen winzig kleinen, ja, den unwichtigsten Teil dessen, und beanspruchst damit eine Definitionshoheit, die Dir nicht zusteht -- und das alles nur, um zu dem Ergebnis zu kommen, welches Dir gerade in den Kram paßt. Da kann ich nur Arnold Vaatz zitieren: "Man vergewissere sich in dem Klassiker "Don Quichote" des 1616 gestorbenen spanischen Schriftstellers Miguel Cervantes der Unwiderlegbarkeit ideologischer Fixierungen durch gegenteilige empirische Erfahrung." In Verbindung mit Deinem Strohmann-Argument und Deinen fiesen Tricks ist diese Beanspruchung der Definitionshoheit zwar von einer bemerkenswerten Dreistigkeit, aber so offensichtlich und lächerlich, daß es schon wieder lustig ist. :-)
Robert L. schrieb: > hier könnte man übrigens gut belegen dass ein C-Compilter besser im > Routinen aussuchen ist als du, aber das willst ja eh nicht wissen.. Viele mathematische Asm- Funktionen, sollten sie wirklich mal gebraucht werden, hab ich aus verschiedenen Quellen im Netz bzw. Büchern und ich denke schon, aus der reichen Auswahl das beste ausgewählt zu haben. Das passt man für ein (m)ein einheitliches Registerschema an und gut ist. A. K. schrieb: > Moby A. schrieb: > Die lassen Deinen fetten C-Code einfach zu schlecht aussehen ;-) > > Diese Wahrnehmungsstörung ... Hey, hier gehts nicht um Wahrnehmung! Hier gehts um Fakten! Michael K. schrieb: > aber da könnte ich ein klein wenig besser > verstehen warum Du C kryptisch findest. Das kannst Du gut verstehen wenn Du Asm- Zeilen mit typischen C-Ausdrücken vergleichst ;-) > Andererseits sollte dann auch das AVR Datasheet eine echte Hürde für > Dich sein. Siehst Du. Ist es aber nicht. Ganz anders gehts mir übrigens mit ARM-Datenblättern, aber das hat einen anderen Hintergrund ;-) > Ja genau, und da war für mich nach dem ersten erfolgreich kompiliertem > 'HELLO WORLD' Program klar das ich mich mit C ganz wohlfühle. Tät mir zur Bestätigung nicht langen. Deshalb wars gleich ein Beispiel aus der Praxis mit echten Aufgaben. > Ja, Asche auf mein Haupt, ohne Informatik Studium bin ich natürlich > tatsächlich nicht in der Lage manche Konstruktionen zu verstehen die ein > Informatiker völlig selbstverständlich dahinzaubert. Genau. C-Ausdrücke können sogar ein Informatik-Studium voraussetzen. Asm nicht. Hast Du gut gesagt. > Klar, es gab eine gewisse Frustration bis ich das Zusammenspiel der C > toolchain verinnerlicht hatte. Konnte ich mir sparen ;-) > zum anderen muß ich > mich ohne C viel tiefer in die Internas der jeweiligen MCU einarbeiten > was im Endeffekt viel mehr Zeit kostet. Leute, die genaue Kenntnis der Interna ist aber gerade das was den Asm-Programmierer zu mehr Effizienz verhilft! Als Bastler der bei seiner Architektur bleiben kann ist das bei simplyAVR kein großes Hindernis. > Einer Lösung ist es aber egal ob noch 10 Bytes mehr frei sind im Ram > oder 100Bytes mehr im Flash. Das summiert sich bei größeren Sachen und kann dann schon den Controller eine Nummer größer erfordern. Und eine Lösung weiß auch nichts von jenen Erweiterungen, die zu ihrer Korrektur oder funktionellen Ergänzungen vielleicht einmal zukünftig erforderlich sind. Da möchte man nicht gleich die Hardware austauschen! > C war die erste Sprache die mich weit von der Hardware löst wenn ich das > will, mir aber wirklich alle Freiheiten läßt wenn ich es darauf anlege. Ja ok, Freiheiten in der Hardware-Auswahl. Die Hochsprache sorgt mit ihrer Ressourcen-Sorglosigkeit aber auch für die Notwendigkeit dieser Auswahl- sprich permanenter Aufrüstung. Schließlich läuft der Umstieg bei hardwarenahem C auch selten unproblematisch. > Für eine frisch entwickelte Hardware brauche ich ein steuerndes PC ... > Unter Windows und unter Linux. > Wie geil ist das denn ? Da freu ich mich für Dich aber wir reden hier von Asm vs. C bei MSR auf 8-Bittern. > Das motiviert mich weiterzumachen und mich in diese merkwürdige Sprache > hineinzuarbeiten die die Dinge auf eine mir völlig unverständliche Art > löst. Irgendwann wird der Groschen fallen Darauf hoffe ich nicht. Ich brauche Gewissheit. Schreibt man mal was in C und kennt Asm zum Vergleich, bekommt man die schnell. > Die Flinte ins Korn zu werfen und das alles blöd zu finden Finde ich nicht. Jeder Zweck hat seine geeigneten Mittel. > verurteilt mich dazu auf dem Level zu bleiben auf dem ich heute bin. Ich sehe mich nicht verurteilt. Ich sehe, daß ich mit Asm auf AVR die effiziente Programmiersprache schlechthin zur einfachsten Problemlösung habe. > Ich habe mich mal bei einem studiertem Informatiker darüber ausgeheult > das ich Python nicht verstehe. Die Antwort war: 'Niemand versteht > Python' > Das hat mir echt geholfen. Freut mich. Danke für den gutgemeinten psychologischen Beistand. Darauf war ich allerdings hier gar nicht aus ;-)
:
Bearbeitet durch User
Sheeva P. schrieb: > Für andere Menschen sind der von ihnen selbst zu betreibende Aufwand und > vor allem die selbst aufzuwendende Lebens- und Arbeitszeit wesentlicher, > wenn nicht sogar der wichtigste Faktor bei der Beurteilung von > Effizienz. Immerhin langte Deine Zeit um als einziger einen Gegenversuch in meinem dafür konzipierten Projekt zu wagen, der dann aber leider leider... na ja lassen wir das. Und sie langt für viele ellenlange Beiträge hier. In der Zeit wär Dein Gegenversuch längst fertig. Wenn auch nicht am Ziel ;-) Karl H. schrieb: > Du hast so viel von dir gegeben, dass ich schon längst den Überblick > verloren habe, was du gesagt hast und was nicht. Da kannst Du mal sehen. Das ist Einsatz. Zuweilen sollte man für eigene Beiträge wissen was schon zur Sprache kam. Das kann ich Dir freilich nicht vorwerfen wenn ich Dein Vollzeit-Engagement im Forum betrachte. Stefan K. schrieb: > Natürlich kann man auch mit dem halben Befehlssatz funktionierende > Programme schreiben. Mit Effizienz hat das aber nichts mehr zu tun. Unfug. Man sollte aber alle Instruktionen im Hinterkopf behalten um ggf. nicht auf Effizienz zu verzichten. Yalu X. schrieb: > Mal angenommen, es gelänge tatsächlich niemandem, dein Programm in C > kürzer (auf den Binärcode bezogen) zu schreiben. Was hättest du damit > bewiesen? > > Dass ein ca. 200 Byte großes Programm in Assembler möglicherweise kürzer > ist, wenn man in stundenlanger Kleinarbeit jeden einzelnen Befehl so > lange dreht und wendet, bis man auch das letzte überflüssige Byte > wegoptimiert hat. Das trieft wieder nur so von Unterstellungen. Das Prinzip, welches diesem Programm zugrundeliegt ist ein universell verwendbares. Da war nicht viel dabei. > Wie ich aber früher schon geschrieben habe, interessiert das außer dir > kein Huhn auch nur im Allergeringsten, da der ATtiny13 die fünffache > Menge Flash-Speicher hat. Deswegen (und wegen deiner ziemlich volatilen > Anforderungen an den Programmcode) ist kaum jemand sonderlich motiviert, > Arbeit in die Umsetzung in ein C-Programm zu inverstieren. Viele "Hühner" interessiert aber hier mir "Einzugackern", daß C alles soviel einfacher und effizienter macht. Bei soviel Expertentum hier sollte die Umsetzung der Funktionalität ein Leichtes sein. Die Anforderungen sind ja nun weitgehend simplifiziert. > Dein Argument, dass der Code ja vielleicht irgendwann erweitert werden > soll, zieht überhaupt nicht. Denn sobald die Code in Richtung 1 KB geht, > wirst auch du ihn nicht mehr mit der gleichen Intensität handoptimieren, > da der Aufwand dafür mindestens quadratisch mit der Codergröße steigt. Was redest Du da. Übung, Vorbereitung, System sag ich da nur! > Hier wird i.Allg. ein C-Programm größenmäßig gleich gut oder besser, bei > der Entwicklungszeit sogar sehr viel besser abschneiden. Das passt dann womöglich nicht mehr hinein. Dann sind wir gleich wieder bei der Notwendigkeit der Hardware-Aufrüstung. Wenn aber die I/O Ausstattung der Platine sonst langt ist das (wahrscheinlich nur für mich ;-) schwer einzusehen. > "Bei Programmen bis ca. 200 Bytes hat die Assembler-Programmierung > keine großen Nachteile, aber auch kaum Vorteile." > > stimme ich (und sicher auch viele andere Diskutanten) dir auch ohne > Wettbewerb zu, und wir können die Diskussion beenden. So lautet sie aber nicht. > Wenn du aber behauptest: > "Assembler bringt auch bei größeren Programmen Vorteile, solange > darin keine Arithmetik mit mehr als 8 Bit stattfindet." Quatsch. Mal doch nicht so schwarz/weiß. Da darf ohne weiteres auch mal 16-Bit (und selten höhere Arithmetik) vorkommen. Aber nochmal: Viele Berechnungen sind eine Kontraindikation für Asm und möglicherweise auch für AVR Verwendung. > steht die Aussage eines > einzelnen Assembler-Only-Programmierers gegen diejenige von zig Leuten, > die Erfahrung in Assembler und C haben. Die bloße Betonung von "Erfahrung" zieht bei mir nicht. P. M. schrieb: > Kurz: Du bist wirklich nicht qualifiziert, in diesem Thread > mitzudiskutieren. Das wirst Du mir nicht verbieten, zumal Dir das > richtig Fakten zu liefern mangels C-Gegenbeispiel nicht gelingt ;-) Michael K. schrieb: > Ohne Frust und eine gewisse Verbissenheit lernt man nunmal nichts neues. Da mag was dran sein. Allerdings ist gerade die absolute Einsteigerphase sehr empfindlich für die Intuition, ob etwas konstruktiv vereinfacht oder unnötig verkompliziert, wenn man Wissen um andere Methoden zuvor schon aufgebaut hat. Da sollte man dann schon ein gewisses Feuer fangen... Mein erstes C-Programm hab ich jedenfalls mit Frust und Verbissenheit zu Ende und Funktion gebracht: Mit der bekannten Erkenntnis.
Hatte eigentlich hier schon jemand eine Erklärung für den Asm-Aufwärtstrend lt. Tiobe-Studie? Ich meine natürlich ohne das Ergebnis selbst in Frage zu stellen !
Moby A. schrieb: > Hatte eigentlich hier schon jemand eine Erklärung für den > Asm-Aufwärtstrend lt. Tiobe-Studie? Wenn man C mal kann muss man eben nicht mehr rumsuchen. Bei Assembler ist das anders, daher fallen die Suchanfragen nach C etc., was zu einem relativen Anstieg für Assembler führt.
Johann L. schrieb: > Wenn man C mal kann muss man eben nicht mehr rumsuchen. Schon mal einen Blick in diverse C-Hilfethreads geworfen ? Wie schauts mit den Suchen nach der passenden Funktion mit der richtigen Aufruf-Syntax in/und einer verwendbaren Library aus? Das allein sollte doch die Suchanfragen schon kräftig treiben. Der ASMler schreibt sich das passende ja meist selbst. Insofern würde ich das schon als steigendes Interesse an Asm deuten. Bei Tiobe heißt es auch ausdrücklich "The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors."
:
Bearbeitet durch User
Moby A. schrieb: > Hatte eigentlich hier schon jemand eine Erklärung für den > Asm-Aufwärtstrend lt. Tiobe-Studie? Ich meine natürlich ohne das > Ergebnis selbst in Frage zu stellen ! Ja ganz am Anfang des Threads hatte ich ja eine Möglichkeit beschrieben: Ein gesteigertes Interesse am Reverse-Engineering und Modifizieren/Häcken von Binärcode. Besonders mit dem ganzen IoT Zeugs wird das ja immer interessanter. Also auch im Zusammenhang von Pentesting usw. Das KÖNNTE einer von MEHREREN Gründen sein. Fallen die noch weitere Möglichkeiten ein?
Moby A. schrieb: > Das summiert sich bei größeren Sachen und kann dann schon den Controller > eine Nummer größer erfordern. Eben nicht, das ist ja der Witz dran. Je größer das Projekt desto mehr kann der Compiler den Hand-Assemblierer übertreffen. Und bei kleinen Projekten ists wurscht.
Moby A. schrieb: > Ich meine natürlich ohne das Ergebnis selbst in Frage zu stellen ! Warum willst du den nicht in Frage stellen? Weil dir's dann nicht mehr in den Kram passt? Es gibt noch zwei, drei andere Beliebtheits-Indizes, die völlig andere Ergebnisse bringen als Tiobe (u. a. taucht dann Assembler gleich gar nicth auf …). Aber selbst für Tiobe, was sollen Schwankungen schon aussagen, wenn der Gesamtwert im unteren einstelligen Prozentbereich liegt? „auf dem Weg nach vorn“ ganz sicher nicht. Das ist doch eher der berühmte Sack Reis, der in China umgefallen ist.
Mit dem Aufwand, dem Einsatz und der Zeit, die für diesen sinnfreien Thread augewändet wurde, hatte man ein richtig gutes Projekt in Hard und Software, Asssembler und/oder C auf die Beine stellen können... Es wäre eine Bereicherung für dieses Forum geworden.
Moby A. schrieb: > Bei Tiobe heißt es auch ausdrücklich > > "The TIOBE Programming Community index is an indicator of the popularity > of programming languages. The index is updated once a month. The ratings > are based on the number of skilled engineers world-wide, courses and > third party vendors." Schon mal daran gedacht von was die wohl leben? Die Bräuchen Clicks! Und wenn sie ein anderes Verfahren benutzen würden, z.B. Umfragen in echten Projekten, dann wäre das extra Arbeit. Mit echtem Personal! So graßen sie Suchmaschinen-API's ab und kommen zu verblüffen blödsinnigen Erkenntnissen. Und ihre Interpretatöre sind kaum besser: C hat viele Anfragen, weil C so kompliziert ist. ASM hat wenig Anfragen, weil ASM-Programmierer allles selber können. Ach! Auch wenn man manchmal den Eindruck hat, daß M. alle nur verarschen will, in Summe hat er vermutlich schlicht nicht alle Kaffeebecher aufgeräumt.
Moby A. schrieb: > Yalu X. schrieb: >> Mal angenommen, es gelänge tatsächlich niemandem, dein Programm in C >> kürzer (auf den Binärcode bezogen) zu schreiben. Was hättest du damit >> bewiesen? >> >> Dass ein ca. 200 Byte großes Programm in Assembler möglicherweise kürzer >> ist, wenn man in stundenlanger Kleinarbeit jeden einzelnen Befehl so >> lange dreht und wendet, bis man auch das letzte überflüssige Byte >> wegoptimiert hat. > > Das trieft wieder nur so von Unterstellungen. Wo habe ich dir da was unterstellt? Moby A. schrieb: >> "Bei Programmen bis ca. 200 Bytes hat die Assembler-Programmierung >> keine großen Nachteile, aber auch kaum Vorteile." >> >> stimme ich (und sicher auch viele andere Diskutanten) dir auch ohne >> Wettbewerb zu, und wir können die Diskussion beenden. > > So lautet sie aber nicht. > >> Wenn du aber behauptest: >> "Assembler bringt auch bei größeren Programmen Vorteile, solange >> darin keine Arithmetik mit mehr als 8 Bit stattfindet." > > Quatsch. > Mal doch nicht so schwarz/weiß. Da darf ohne weiteres auch mal > 16-Bit (und selten höhere Arithmetik) vorkommen. Die Einschränkung auf 8-Bit-Arithmetik habe ich zu deinen Gunsten angehängt. Ohne diese wäre die Aussage erst recht falsch. Aber mach doch mal, um solche Missverständnisse auszuschalten, eine klare Aussage darüber, für welche Sorte von Programmen du Assembler im Vorteil siehst. Dann nehmen wir einfach ein Beispiel eines solchen Programms und diskutieren darüber weiter. Bis jetzt steht als Beispiel – und damit als Diskussionsgrundlage – ein 200-Byte-Programm im Raum, einer Codegröße, bei der es einfach überflüssig ist, über die Vor- und Nachteile von Assembler und C zu diskutieren. Wenn es um größere Programme geht: Einmal behauptest du, dass auch dort Assembler bessr sei. Ein anderes Mal gibst du zu, dass für größere Programme C die richtige Sprache ist. Wieder ein anderes Mal ist Assembler auch für größere Programme gut, aber mit der Einschränkung, dass keine komplizierte Arithmetik erforderlich ist (die natürlich in C überhaupt nicht kompliziert wäre). Ja, was denn nun? Mach doch mal klare Aussagen, dann brauchst du dich hinterher nicht zu beschweren, wenn wir dich falsch verstanden haben. Moby A. schrieb: >> Dein Argument, dass der Code ja vielleicht irgendwann erweitert werden >> soll, zieht überhaupt nicht. Denn sobald die Code in Richtung 1 KB geht, >> wirst auch du ihn nicht mehr mit der gleichen Intensität handoptimieren, >> da der Aufwand dafür mindestens quadratisch mit der Codergröße steigt. > > Was redest Du da. Übung, Vorbereitung, System sag ich da nur! Und nur, weil du in C keine Übung hast, ist C auch für alle anderen schlecht? Komische Logik. Moby A. schrieb: >> Hier wird i.Allg. ein C-Programm größenmäßig gleich gut oder besser, bei >> der Entwicklungszeit sogar sehr viel besser abschneiden. > > Das passt dann womöglich nicht mehr hinein. Dann sind wir gleich wieder > bei der Notwendigkeit der Hardware-Aufrüstung. Wenn aber die I/O > Ausstattung der Platine sonst langt ist das (wahrscheinlich nur für mich > ;-) schwer einzusehen. Naja, also zwischen den 200 Bytes deines Programms und den 1024 Bytes eines ATtiny13 ist ja ein so großer Unterschied, dass da auch ohne Hardwareaufrüstung noch einiges geht. Wenn das trotzdem nicht reicht, gibt es ja auch noch den ATtiny85, den man ohne Änderung der Platine als Ersatz für den ATtiny13 einsetzen kann. Darin hat ein Programm sogar 40mal Platz. Moby A. schrieb: > Hatte eigentlich hier schon jemand eine Erklärung für den > Asm-Aufwärtstrend lt. Tiobe-Studie? Ja, ich habe inzwischen herausgefunden, woher der Sprung kommt. Die Erklärung kommt demnächst. Nur so viel vorab: Mit IoT hat das nichts zu tun, auch nicht mit Mikrocontrollern. Ich hoffe, du wirst nicht zu sehr enttäuscht sein :) Es gibt jetzt übrigens den Index für Dezember, allerdings gehen die Tiobe-Leute in ihrem Kommentar wieder nicht auf das Thema Assembler ein. Wundert dich das nicht?
Carl D. schrieb: > C hat viele Anfragen, weil C so kompliziert ist. > ASM hat wenig Anfragen, weil ASM-Programmierer allles selber können. > > Ach! Wenn man das überträgt, kann man sich in diesem Forum umsehen und sagen: AVRs haben viele Anfragen, weil die Dinger so kompliziert sind. STM32er haben wenig Anfragen, weil es ein Genuss ist, sie zu programmieren. Wobei die STM32er auch langsam komplizierter zu werden scheinen, weil es immer mehr Anfragen diesbezüglich gibt. Was macht ST da bloß? ;-)
Moby A. schrieb: > Also wieder nix. Spar Dir diese Art Mühen. > Warum scheuen bloß alle die Umsetzung meines bischen Funktionalität, > einen schnellen reellen Vergleich, ein schnelles Ende jeglicher > Diskussion hier wie der Teufel das Weihwasser ? Du verdrehst Tatsachen: Die anderen haben geliefert. Du nicht. Du bist jetzt der, der an der Reihe ist, C-Code effizient in Assembler umzusetzen. Dein Herumdrücken sehe ich aber als Eingeständnis, dass du es nicht kannst ;-) Denn Zeit für den Thread hast du ja offensichtlich genügend. Moby A. schrieb: > Mehr Bürokratie. > Mehr Schreibbedarf. > Mehr Ressourcenverbrauch. > Code-Intransparenz, die zu noch mehr Ressourcenverbrauch führen kann. > Entgegensteuern lässt sich wieder nur mit erhöhtem Lernaufwand... Du behauptest, behauptest, behauptest. Jeder dieser Punkte wurde bereits besprochen und widerlegt. Zeig bitte mal für jede deiner Behauptungen ein Beispiel.
P. M. schrieb: > Dein Herumdrücken sehe ich aber als Eingeständnis, dass du es nicht > kannst ;-) Denn Zeit für den Thread hast du ja offensichtlich genügend. Las ihn einfach. Meinst Du, Du kannst ihn zu einem Einlenken bewegen? Mehr als ein ;-) am Satzende wirst Du nicht bekommen. Narzisstische Soziopathen sind so.
Yalu X. schrieb: > Bis jetzt steht als Beispiel – und damit als Diskussionsgrundlage – ein > 200-Byte-Programm im Raum, einer Codegröße, bei der es einfach > überflüssig ist, über die Vor- und Nachteile von Assembler und C zu > diskutieren. Eben. Und deshalb mache ich folgenden Vorschlag: Wir geben Moby Recht, dass ASM bei 200 Byte Codegröße unschlagbar ist. Damit hat dann Moby in seinem Mikrokosmos Recht und der Wahnsinn hört hier auf. Gleichzeitig stellen wir die These auf: Ab 1KB Codegröße ist ASM mit C IMMER schlagbar Wenn Moby mit dieser Regelung nicht einverstanden ist, soll er den Gegenbeweis erbringen. Ich schlage daher einen Programmierwettbewerb für eine typische 8-Bit-Anwendung vor, die dann in der Praxis auch mehr als 1KB Codegröße braucht. Daran können sich ASM- und C-Programmierer beteiligen. Es gewinnt dasjenige Programm, welches in der Summe Flash + Static-Ram-Data den wenigsten Speicherplatz verbraucht. Wie können hier demokratisch abstimmen: Wer dafür ist, gibt diesem Beitrag ein + Wer dagegen ist, gibt diesem Beitrag ein - Ich wünsche schon jetzt allen Beteiligten viel Spaß!
Eddy C. schrieb: > Las ihn einfach. Meinst Du, Du kannst ihn zu einem Einlenken bewegen? Ich denke nicht, nein. Immerhin soll so seine Strategie nicht aufgehen, unangenehme Fragen einfach auszusitzen und mit immer neuen Behauptungen abzulenken.
Frank M. schrieb: > Wer dafür ist, gibt diesem Beitrag ein + Von mir ein +. Allerdings bin ich mit dem Bewertungskriterium: Frank M. schrieb: > Es > gewinnt dasjenige Programm, welches in der Summe Flash + Static-Ram-Data > den wenigsten Speicherplatz verbraucht. ... nicht ganz einverstanden. Es gibt wohl kaum ein Projekt, wo plus minus 30% Flash/RAM eine Rolle spielt. Pro Entwicklerstunde kriegt man locker 100 8-Bitter mit verdoppeltem Speicher. Und das spielt auch nur dann eine Rolle, wenn wir im Bereich von 99%-130% des Speicherverbrauchs des kleineren Controllers sind. Also die einzigen Projekte, wo man jemals "quetschen" würde, sind sehr grosse Stückzahlen, wo das Programm genau eine kritische Grösse erreicht.
:
Bearbeitet durch User
P. M. schrieb: > ... nicht ganz einverstanden. Prinzipiell hast Du natürlich Recht. Aber ich bin bereit, wenigstens auf dieses Moby'sche Argument, was natürlich nicht realitätsnah ist, einzugehen. Oder mache bitte einen anderen Vorschlag für ein objektiv bewertbares Kriterium. Ich finde als Kriterium den Speicherplatz nicht schlecht. Nimm einfach für diesen Wettbewerb an, es würden 100 Millionen der Anwendung verkauft werden und es gäbe dafür die Möglichkeit, einen speziellen AVR herzustellen, der genau auf die Codegröße her optimiert wäre - wobei jede weitere Speicherzelle in der Summe viele hunderttausend Euro (für diese 100 Mio Chips) kosten würde. Dann tritt die Entwicklerzeit in den Hintergrund.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Oder mache bitte einen anderen Vorschlag für ein objektiv bewertbares > Kriterium. Die Erweiterbarkeit sollte IMHO noch gemessen werden. Sobald die Programme fertig sind, kommt noch eine kleine/mittlere Zusatzaufgabe dazu. Beim C-Beispiel wird ja der ADC-Wert gelesen, geglättet und ab einem Schwellenwert per UART gesendet. Das könnte z.B. eine Überwachungsschaltung für ein Gerät sein, die zunächst einfach nur kritische Werte protokolliert. Als nächstes könnte es nun wünscheswert sein, diesen kritischen Wert auch per UART setzen zu können. Als weitere Entwicklungsstufe könnte man dann verlangen, dass ein "kritischer" und ein "gefährlicher" Schwellenwert verwendet werden, wobei beim gefährlichen Schwellenwert eine Schutzschaltung/Sirene/LED aktiviert werden soll, die für eine bestimmte Zeitdauer aktiv ist.
Frank M. schrieb: > Wie willst Du die "messen"? Eben - mit einer Erweiterung, die erst nach Abgabe des ersten Codes beschlossen wird. Kann man z.B. daran messen, wie viel der Code dann wächst oder um wie viele Prozent der alte Code geändert werden musste. Ganz präzise messen kann man es natürlich nicht, aber es dürfte schon eine Hausnummer dabei rauskommen.
Frank M. schrieb: > Aber ich bin bereit, wenigstens auf dieses Moby'sche Argument, > was natürlich nicht realitätsnah ist, einzugehen. Wieso geht überhaupt noch jemand auf Moby ein? Hört Ihr nicht, wie er sich ins Fäustchen lacht, wie er Euch weiter in den Bann zieht und kontrolliert mit seiner theoretisch möglichen Meinung? Gelassenheit ist die Devise und einfach - räusper - nichts mehr schreiben. P. M. schrieb: > Eben - mit einer Erweiterung, die erst nach Abgabe des ersten Codes > beschlossen wird. Kann man z.B. daran messen, wie viel der Code dann > wächst oder um wie viele Prozent der alte Code geändert werden musste. > Ganz präzise messen kann man es natürlich nicht, aber es dürfte schon > eine Hausnummer dabei rauskommen. Lächerlich.
Eddy C. schrieb: > P. M. schrieb: >> Eben - mit einer Erweiterung, die erst nach Abgabe des ersten Codes >> beschlossen wird. Kann man z.B. daran messen, wie viel der Code dann >> wächst oder um wie viele Prozent der alte Code geändert werden musste. >> Ganz präzise messen kann man es natürlich nicht, aber es dürfte schon >> eine Hausnummer dabei rauskommen. > > Lächerlich. Soso. Aber ein konkreter Kritikpunkt oder ein anderer Vorschlag kommt natürlich nicht. Wenn du nicht mitdiskutieren willst, dann lass es, ansonsten sei konstruktiv und bringe Inhalt. Solche Umgangsformen deinerseits sind "lächerlich".
P. M. schrieb: > Aber ein konkreter Kritikpunkt oder ein anderer Vorschlag kommt > natürlich nicht. Das ist doch gerade der Witz! Wobei ich auch schon erfolglos meinen Senf beigesteuert habe .-)
Eddy C. schrieb: > Gelassenheit ist die Devise und einfach - räusper - nichts mehr > schreiben. 100% Ack. War auch die einzig richtige Antwort auf KB
:
Bearbeitet durch User
Johannes O. schrieb: > Das KÖNNTE einer von MEHREREN Gründen sein. Mehr Bedeutung von Asm zum Hacken, Reengineering, Produktnachbau? Richtig. Für sowas ist Asm ja auch sehr nützlich ;-) Jörg W. schrieb: > was sollen Schwankungen schon aussagen, wenn der > Gesamtwert im unteren einstelligen Prozentbereich liegt? „auf dem Weg > nach vorn“ ganz sicher nicht. Das ist doch eher der berühmte Sack Reis, > der in China umgefallen ist. Immerhin ist dieser Trend neu ... Auf Geringfügigkeit hin wegzudiskutieren ist sowas meiner Meinung nach nicht. Wolfgang R. schrieb: > Mit dem Aufwand, dem Einsatz und der Zeit, die für diesen > sinnfreien Thread augewändet wurde "Sinnfrei" ist blanke Überheblichkeit gegenüber allen Diskussionsteilnehmern. Auch ich lerne was, wenn auch weniger über C vs. Asm, als vielmehr über die tausend Wege, seinen Diskussionspartner zu diskreditieren und tausend andere windige Argumente. Das muß aber jetzt nicht überraschen, wenn man so wie ich gegen den Trend bürstet. Vielleicht regt es aber zum Nachdenken an ;-)
Eddy C. schrieb: > Gelassenheit ist die Devise und einfach - räusper - nichts mehr > schreiben. Die Diskussion war streckenweise sehr unterhaltsam. Aber es ist dabei wie beim Boxen. Der Sandsack ist zwar ein miserabler Boxer, hält aber stets länger durch.
:
Bearbeitet durch User
Carl D. schrieb: > Schon mal daran gedacht von was die wohl leben? Die Bräuchen Clicks! Ach. Es sollte denen doch egal sein, welche konkrete Sprachen vorne bzw. auf steigender Trendlinie liegen! Du meinst doch nicht etwa, Tiobe ist ein geheimer Asm-Förderverein? ;-) Yalu X. schrieb: > Wo habe ich dir da was unterstellt? Was ich da in stundenlanger Kleinarbeit täte natürlich. Wenn etwas in stundenlanger Arbeit ausarten kann dann ist das einen PAP oder einen Algorithmus zu erstellen, oder es ist Fehlersuche. Beides nix typisches für Asm... > klare Aussage darüber, für welche Sorte von Programmen du Assembler im > Vorteil siehst. Oft genug geschehen. Aber für Dich nochmal: MSR auf 8-Bit Controllern ohne große Berechnungen und ohne große Datenmengen. Also Millionen Anwendungen. > Dann nehmen wir einfach ein Beispiel eines solchen > Programms und diskutieren darüber weiter. Dann darf ich gleich wieder zur Lektüre meines fix und fertigen Programmbeispiels bitten. Ein hardwareoptimierter Asm-Leckerbissen ;-) > bei der es einfach > überflüssig ist, über die Vor- und Nachteile von Assembler und C zu > diskutieren. Ganz und gar nicht denn es ist just gerade ein von Dir gefordertes Beispiel für MSR-Anwendungen obiger Definition. > Wenn es um größere Programme geht: Einmal behauptest du, dass auch dort > Assembler bessr sei. Ein anderes Mal gibst du zu, dass für größere > Programme C die richtige Sprache ist. Wieder ein anderes Mal ist > Assembler auch für größere Programme gut, aber mit der Einschränkung, > dass keine komplizierte Arithmetik erforderlich ist (die natürlich in C > überhaupt nicht kompliziert wäre). > > Ja, was denn nun? Ja was denn nun! Das hängt von Fall zu Fall ab. Überrascht Dich das? Es wäre vielleicht sinnvoll, Du würdest den vorteilhaften Asm-Einsatzfall nach obiger tausendfach wiederholter Definition schlicht mal zur Kenntnis nehmen. > Und nur, weil du in C keine Übung hast, ist C auch für alle anderen > schlecht? Komische Logik. Du legst mir schon wieder Dinge in den Mund die ich nie behauptet habe. Komische Logik. Nein, eher unredliche Logik. C ist nicht schlecht, aber für viele Situationen (siehe Definition oben) die schlechtere Lösung da sprachtechnisch unnötiger Aufwand. Was ist daran bloß so schwer zu kapieren??? > Naja, also zwischen den 200 Bytes deines Programms und den 1024 Bytes > eines ATtiny13 ist ja ein so großer Unterschied, dass da auch ohne > Hardwareaufrüstung noch einiges geht. Wenn das trotzdem nicht reicht, > gibt es ja auch noch den ATtiny85 Tja siehst Du, darin unterscheiden wir uns. Ich schreie nicht hochsprachenverschwendertypisch gleich nach größerer Hardware, sondern möchte erstmal das vorhandene bestmöglich nutzen. > Ja, ich habe inzwischen herausgefunden, woher der Sprung kommt. Die > Erklärung kommt demnächst. Nur so viel vorab: Mit IoT hat das nichts zu > tun, auch nicht mit Mikrocontrollern. Ich hoffe, du wirst nicht zu sehr > enttäuscht sein :) Da bin ich aber gespannt. Und nein, ich werde keinesfalls enttäuscht sein da sich damit die mir offenkundigen Vorteile von Asm sicher nicht in Luft auflösen ;-)
Chris D. schrieb: > AVRs haben viele Anfragen, weil die Dinger so kompliziert sind. > STM32er haben wenig Anfragen, weil es ein Genuss ist, sie zu > programmieren. Klasse! Es würde mich bald nicht mehr überraschen wenn das hier auch noch mit dem Brustton der Überzeugung verkündet würde ;-) P. M. schrieb: > Du verdrehst Tatsachen: Die anderen haben geliefert. Du nicht. Du bist > jetzt der, der an der Reihe ist, C-Code effizient in Assembler > umzusetzen. Wie war doch gleich nochmal das Stichwort? Tatsachen verdrehen? :-) > Du behauptest, behauptest, behauptest. Was ich behaupte habe ich mit einem Asm Beispiel belegt. Du bist (als C-Profi?) nicht in der Lage, es kürzer und für mich nachprüfbar in C umzusetzen ;-)
Frank M. schrieb: > Ab 1KB Codegröße ist ASM mit C IMMER schlagbar Das halte ich für falsch. Und wir wollen gleich nochmal klarstellen, daß nichts als der Ressourcen-Verbrauch gemeint ist. Bei größeren Sachen fällt dann gerne noch mehr Speed durch Asm an- sprich, man kann mit der Taktfrequenz weiter runtergehen. Mal so am Rande. > Wenn Moby mit dieser Regelung nicht einverstanden ist, soll er den > Gegenbeweis erbringen. Wenn ich mal ein forumtauglichen Code dieser Länge erstelle gerne. Was die wieder zu erwartende Diskussionszerredung dann ergibt kann ich allerdings schon ahnen ;-) > Ich schlage daher einen Programmierwettbewerb ...vor Leider ist dieses schöne Forum jetzt kein Fulltime-Job und Programmierung kein blanker Zeitvertreib für mich. Es muß dann schon eine Lösung sein die viele und auch ich gebrauchen können. Dürfte schwierig werden.
P. M. schrieb: > Frank M. schrieb: > Oder mache bitte einen anderen Vorschlag für ein objektiv bewertbares > Kriterium. > > Die Erweiterbarkeit sollte IMHO noch gemessen werden. Sobald die > Programme fertig sind, kommt noch eine kleine/mittlere Zusatzaufgabe > dazu. Das wirst Du doch nicht etwa als objektiv bewertbares Kriterium betrachten? Meine Herren, ich möchte hier nochmal die Selbstverständlichkeit betonen, daß man auch in Asm sehr hardwareflexibel (I/O Erweiterungsfähigkeit, im Rahmen der bestehenden Architektur natürlich) programmieren kann. Allerdings ist das dann etwas anderes als hochoptimierter Code und man gäbe damit einen zentralen Asm-Vorteil aus der Hand!
Moby A. schrieb: > P. M. schrieb: >> Die Erweiterbarkeit sollte IMHO noch gemessen werden. Sobald die >> Programme fertig sind, kommt noch eine kleine/mittlere Zusatzaufgabe >> dazu. > > Das wirst Du doch nicht etwa als objektiv bewertbares Kriterium > betrachten? Hier muss ich Moby zustimmen. Dass eine Partei in so einem "Wettbewerb" die Aufgabe stellt macht den Wettbewerb fur Farce — unabhängig davon ob es um C vs. ASM geht oder was anderes. Mal abgesehen davon sind die Parteien noch nichtmal über die Bewertungskriterien einig.
Angehängte Dateien:
-
assembler1.png
39 KB -
assembler2.png
23 KB
Hier ist der meiner Meinung nach hautsächliche Grund für den Sprung des Tiobe-Index für Assembler zwischen Juni (0,754%) und Juli 2015 (1,535%): http://board.flatassembler.net/topic.php?t=18023 Dort schlug John vor, als Suchbegriff für die Ermittlung des Index
1 | +"assembly language programming" |
anstelle von
1 | +"assembly programming" |
zu verwenden, weil "assembly" in Verbindung mit "language" mehr Treffer liefert. John sandte eine diesbezüglich eine E-Mail-Anfrage an Tiobe. Diese wurde von Paul beantwortet mit der Zusicherung, er werde den vorgeschlagenen neuen Suchbegriff mit Wirkung ab Mai 2015 zum bestehenden hinzuzufügen. Diesen Information habe ich schon vor ca. einem Monat gefunden, als Moby den "Assembler wieder auf dem Weg nach vorn"-Thread startete. Ich hielt sie damals aber nicht für relevant, da der Sprung ja nicht im Mai, sondern erst zwei Monate Später im Juli stattfand. Als ich heute auf die erneute Anfrage Mobys hin noch einmal etwas rumgegoogelt habe, bin ich auf eine Erklärung dieser Diskrepanz gestoßen. Sie liegt in diesem Spreadsheet auf Google-Docs: https://docs.google.com/spreadsheets/d/1xleffl2fzvcwLFafDaNN0SvqYQ8OiIBu4_-AFThw4Zo/pubhtml?gid=370149219&single=true Da hat jemand sämtliche Tiobe-Daten ab September 2014 zusammengetragen. Die Einträge für Assembler heißen bis einschließlich Mai 2015 "Assembly" und ab Juni 2015 "Assembly language". Johns Vorschlag ist also von Paul nicht wie angekündigt im Mai, sondern erst im Juni umgesetzt worden. Vermutlich hat er die Änderung zwar vor der Veröffentlichung des Juni-Index vorgenommen, aber erst, nachdem die automatische Suchmaschinenabfrage für Juni bereits durchgelaufen war, aber. Das bedeutet, dass die Zahlenwerte für Juni noch nach dem alten System ermittelt wurden, bei der Veröffentlichung auf der Tiobe-Webseite aber bereits der neue Name verwendet wurde. Erst im Juli-Index wurde der neue Suchbegriff auch zahlenmäßig wirksam. Da +"assembly language programming" deutlich mehr Treffer liefert als +"assembly programming", ist der Index für Assembler entsprechend nach oben geschossen. Der Sprung im Juli von 0,754% auf 1,535% entspricht einem Faktor von 2,04. Um zu ermitteln, wieviel von diesem Anstieg durch die Änderung der Suchbegriffe verursacht wurde, müsste man für sämtliche von Tiobe genutzten Suchmaschinen die jeweiligen Trefferzahlen vom Juli kennen, was im Nachhinein natürlich nicht mehr möglich ist. Im Moment liegen die Trefferzahlen für die beiden Suchbegriffe bei google.com, google.de und google.co.in bei 216000 (alt) und 379000 (neu), was einem Faktor von 1,75 entspricht und recht nahe bei den 2,04 liegt. Allerdings sind die von Google angezeigten Trefferzahlen nur grobe Schätzungen, zudem ändern sie sich manchmal innerhalb von ein paar Stunden sehr stark. So lagen bspw. heute Nachmittag die Trefferzahlen bei google.co.in bei 216000 (alt) und 518000 (neu). Das ist ein Faktor von 2,40. Der Mittelwert von 1,75 und 2,40 ist 2,08 und würde den Sprung vollständig erklären. Wenn man jetzt einmal als grobe Schätzung (für eine bessere Schätzung fehlen einfach die Informationen) annimmt, dass die Erweiterung der Suchbegriffe tatsächlich einen Faktor vom 2,08 im Ergebnis bewirken, kann man die Werte im Tiobe-Index von vor Juli 2015 rückwirkend mit diesem Faktor multiplizieren und erhält dann eine Schätzung dafür, wie die Werte ausgefallen wären, wenn diese Suchbegriffe von Anfang an verwendet worden wären. Das Ergebnis ist in assembler1.png zu sehen. Man könnte aber genauso die Werte ab dem Juli 2015 durch 2,08 dividieren und erhält damit den geschätzten Kurvenverlauf für den Fall, dass keine Änderung der Suchbegriffe vorgenommen worden wäre (assembler2.png). In beiden Fällen ist aber der Sprung, auf den Moby so sehr abgefahren ist, verschwunden. Es bleibt ein leichter Anstieg der Kurve seit März 2015, aber der bewegt sich in derselben Größenordnung wie die sonstigen Schwankungen. Vielleicht ist dieser leichte Anstieg auf die Befehlssatzerweiterungen der neuen PC-Prozessoren zurückzuführen, denn jedesmal, wenn eine solche Erweiterung angekündigt wird, entsteht eine Diskussion darüber, ob sie vom Compiler XY bereits unterstützt wird, oder ob sie nur bei der Assemblerprogrammierung nutzbar sind. Dieser durchaus plausible Gedanke stammt von hier (zweiter Beitrag): http://www.0x10cforum.com/forum/post/last/m/4932880/viewthread/4782416-assembly-language-has-risen-into-first-20-languages-tiobe-index Es gibt sicher noch jede Menge weiterer Erklärungen für den leichten Anstieg. Nur der plötzliche Sprung um den Faktor 2 innerhalb eines Monats können sie nicht erklären, weswegen die Gründe woanders gesucht werden mussten. Fazit: Der Sprung hat weder etwas mit IoT noch mit Mobys explodierendem Eifer bei der Assemblerprogrammierung seines ATtiny13 zu tun, sondern ist im Tiobe-eigenen "Messverfahren" begründet. Für diese These spricht auch, dass von Tiobe seit nunmehr 6 Ausgaben des Index kein Kommentar zu dieser Anomalie abgegeben wurde. Leider sind wir damit in der Frage, ob Assembler oder C, wieder exakt so weit wie am Ende des früheren Moby-Threads Beitrag "Kleines Tiny13 Sensorboard" vor zwei Monaten. Der neue, inzwischen über 1100 Beiträge umfassende Thread hier ist also größtenteils für die Katz. Bei der Blockadehaltung von Moby glaube ich auch nicht, dass die Diskussion in den nächsten zwei Monaten (oder auch Jahren ;-)) auch nur einen Millimeter voranschreitet. Vielleicht sollten wir stattdessen unsere Zeit wieder verstärkt dazu nutzen, gute C- und Assemblerprogramme (jeder wie ihm beliebt) zu schreiben :)
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Vielleicht sollten wir stattdessen unsere Zeit wieder verstärkt dazu > nutzen, gute C- und Assemblerprogramme (jeder wie ihm beliebt) zu > schreiben :) Auch wenn's Dich überrascht: Das sehe ich fazitär prinzipiell genauso. Was wohin millimeterweise voranschreitet werden wir ja sehen, spätestens mit der nächsten Asm-Pressemeldung ;-) Danke für die Recherche zu Deiner These.
Moby A. schrieb: > Wie war doch gleich nochmal das Stichwort? > Tatsachen verdrehen? :-) > >> Du behauptest, behauptest, behauptest. > > Was ich behaupte habe ich mit einem Asm Beispiel belegt. Du bist (als > C-Profi?) nicht in der Lage, es kürzer und für mich nachprüfbar in C > umzusetzen ;-) Ja genau, Tatsachen verdrehen: Du verlangst plötzlich, dass ein Assembler-Beispiel kürzer in C umgesetzt wird. Dabei hat nie jemand behauptet, mit C würde man auch kleinste Assembler-Projekte speichermässig schlagen. Die These war schon immer, dass man mit Assembler keine Chance hat gegen höhere Programmiersprachen, sobald die Projekte auch nur etwas grösser werden. Und dass man selbst bei Kleinst-Projekten mit C nie merklich schlechter fährt. Das ist Konsens und das wurde auch mit C-Umsetzungen deiner Projekte belegt. DU hast dann behauptet, das stimme nicht, aber du kannst es nicht belegen.
Moby A. schrieb: > Frank M. schrieb: >> Ab 1KB Codegröße ist ASM mit C IMMER schlagbar > > Das halte ich für falsch. Und wir wollen gleich nochmal klarstellen, > daß nichts als der Ressourcen-Verbrauch gemeint ist. Genau dafür hast Du keinen Beleg. > Bei größeren Sachen > fällt dann gerne noch mehr Speed durch Asm an- sprich, man kann mit der > Taktfrequenz weiter runtergehen. Mal so am Rande. Dafür hast Du ebenso keinen Beleg. Nix als Schwafeln... Du hast nur ein 200-Byte-Programm und willst damit die Welt erklären. Aber so läuft das nicht.
Frank M. schrieb: > Moby A. schrieb: >> Bei größeren Sachen >> fällt dann gerne noch mehr Speed durch Asm an- sprich, man kann mit der >> Taktfrequenz weiter runtergehen. Mal so am Rande. > > Dafür hast Du ebenso keinen Beleg. Nix als Schwafeln... > > Du hast nur ein 200-Byte-Programm und willst damit die Welt erklären. > Aber so läuft das nicht. Zumal laut Datenblatt sich bei halber Taktfrequenz nicht etwa der halbe Stromverbrauch ergibt, sondern etwas mehr. Nur die Rechengeschwindigkeit wird halbiert. Der Energieverbrauch je Befehl steigt aber an. Es ist also besser, schnell etwas auszurechnen und dann schlafen zu gehen, als gemütlich vor sich hin zu bummeln. Oder man benutzt diesen Mehrverbrauch der Moby-Lösung um die "großen Schwächen" des Compilers auszugleichen. Man kommt also den gleichen Stromverbrauch mit weniger Programmierzeit. Wenn man C mental gewachsen ist. (mal sehen, wie der M. hier wieder Zitatfragmente rauspickt. Manche kenn ich jetzt schon)
Moby A. schrieb: > Bei größeren Sachen > fällt dann gerne noch mehr Speed durch Asm an- sprich, man kann mit der > Taktfrequenz weiter runtergehen. Mal so am Rande. Das ist ja genau falsch. Bei grösseren Sachen kann der Compiler über Bereiche hinweg optimieren, wo ein Mensch niemals mehr den Überblick behalten kann. Beispiel: Registerallokation (https://de.wikipedia.org/wiki/Registerzuteilung). Ist NP-vollständig. Sobald also dutzende oder hunderte Variablen in deinem Programm existieren, hast du als Mensch keine Chance mehr, eine bessere Zuweisung zu finden als es der Compiler kann. Sinngemäss gilt das dann auch für Caches. Und bei modernen Rechnern spielt die Musik nunmal im Bereich der Speicherbandbreite und nicht beim Abzählen von Taktzyklen.
:
Bearbeitet durch User
Moby A. schrieb: > Mehr Bürokratie. Das kann ich nur bestätigen. Ich hatte vor 5 Wochen einen Antrag auf Genehmigung zur Erstellung eines C-Programms zum Blinken einer LED gestellt. Dieser wurde vor 3 Wochen wegen zu hohem RAM-Verbrauch abgelehnt. Gleich am nächsten Tag habe ich einen neuen Antrag gestellt, in dem ich diesen Mangel abgestellt habe. Jetzt warte ich schon wieder seit 2 Wochen. Moby A. schrieb: > Mehr Schreibbedarf. Volle Zustimmung. Siehe oben. Moby A. schrieb: > Mehr Ressourcenverbrauch. Daran scheitern auchdie meisten C-Projekte. Das wird statistisch nur nicht erfasst, da sie schon im Vorwege wegen nicht erteilter Genehmigungen scheitern und somit noch nicht als Projekte gelten. Moby A. schrieb: > Code-Intransparenz, die zu noch mehr Ressourcenverbrauch führen kann. Da sprichst du genau den neuralgischen Punkt an. Die Genehmigungsverfahren dauern auch deswegen so lange, da die Sachbearbeiter den kryptischen Code einfach nicht verstehen. Das wird dann wieder versucht durch Vereinfachungen, die mehr Resourcen verschwenden, auszugleichen. Moby A. schrieb: > Entgegensteuern lässt sich wieder nur mit erhöhtem Lernaufwand... Das wird leider nur teilweise getan. Es gibt jede Menge Schulungen für die Sachbearbeiter in den Genehmigungsstellen. Diese werden allerdings zumeist von den Abteilungsleitern belegt, die das erlernte Wissen schon auf dem Weg nach Hause wieder vergessen und es somit nicht an die Sachbearbeiter weitergeben können. C-Programmierung ist, unter allen diesen Aspekten betrachtet, vollkommen sinnlos. Der ganze Hype um diese vollkommen nutzlose Programmiersprache lässt sich meines Erachtens nur dadurch erklären, dass diese Sprache irgendwann einmal in Mode gekommen ist und fast alle Programmierer dieser Mode einfach nur, ohne darüber nachzudenken, hinterher laufen. Da aber eine ganze Industrie mit ihren Lobbyisten dahinter steht, wird sich daran leider nichts ändern. Diese beschäftigen auch Heerscharen von Leuten, die immer wieder Begründungen für den Sinn und die Überlegenheit von Hochsprachen im Allgemeinen und C im Besonderen an den Haaren herbeiziehen. Insbesondere in China ist dabei eine völlig neue Industrie entstanden: Es gab massenhaft Chinesen, die sich alte chinesische Sprichwörter ausdachten, um sich damit ihren kargen Lebensunterhalt zu verdienen. Diese Leute haben den Begründungsbedarf erkannt und arbeiten jetzt alle als Erfinder von fadenscheinigen Begründungen für die Überlegenheit von sinnlosen Hochsprachen. Mit diesen Billigargumenten überschwemmen sie die Märkte in Westeuropa, Japan und den USA. Das ist natürlich etwas, wo die EU einschreiten muss. Hohe Zölle für die fadenscheinigen Begründungen aus China wären das Mindeste. Ein Verbot sämtlicher Hochsprachen, womit man dieser chinesischen Invasion gänzlich das Wasser abdrehen würde, aber das Erstrebenswerte. Leider steht aber eine mächtige Lobby dieser Vernunft entgegen. Ebenso haben die Franzosen schon Widerspruch angekündigt, da sie ihre Sprache auch als Hochsprache unter allen anderen Sprachen empfinden, befürchten sie, dass Französich gleich mit verboten wird. Schliesslich macht die EU, wenn sie schon etwas macht, es ohne Ausnahme gründlich. Daher werden wir uns leider diesem Diktat weiter beugen müssen, mit billigen Chinaimportargumenten alles schön reden und Freischärlern wie Mobin Hood neidvoll hinterher blicken. mfg.
P. M. schrieb: > Ja genau, Tatsachen verdrehen: Du verlangst plötzlich, dass ein > Assembler-Beispiel kürzer in C umgesetzt wird. Ich verlange nichts und schon gar nichts plötzlich. Wer freilich die bessere Effizienz von Asm anzweifelt soll das doch an meinem kleinen Beispiel belegen, für welches ich in Vorleistung gegangen bin. Wenn Du das nun nicht behauptest dann ist ja gut. Frank M. schrieb: > Genau dafür hast Du keinen Beleg. Dafür argumentiere ich aber, ausgehend von meinem Beispiel. Außer verschiedensten Gegenaussagen gab es auch keinen Gegenbeleg. Hattest Du nicht deshalb einen realen Vergleich angeregt ? > Du hast nur ein 200-Byte-Programm und willst damit die Welt erklären. Ich erkläre nicht die Welt, sondern die Verhältnisse bei 8-Bit MSR ohne große Berechnungen und Datenmengen.
Carl D. schrieb: > Zumal laut Datenblatt sich bei halber Taktfrequenz nicht etwa der halbe > Stromverbrauch ergibt, sondern etwas mehr. Nur die Rechengeschwindigkeit > wird halbiert. Der Energieverbrauch je Befehl steigt aber an. Es ist > also besser, schnell etwas auszurechnen und dann schlafen zu gehen, als > gemütlich vor sich hin zu bummeln. Die Reduzierung der Taktfrequenz spart in jedem Fall. Die Nutzung der Sleep-Modi ist unabhängig davon anzuraten. Deshalb lasse ich gern das Hauptprogramm im Sleep-Modus und überlasse die Funktionalität den Interrupts. P. M. schrieb: > Bei grösseren Sachen kann der Compiler über > Bereiche hinweg optimieren, wo ein Mensch niemals mehr den Überblick > behalten kann. Bei größere Berechnungen und Datenmengen. Mein überlegtes, fixes Registerzuordnungssystem ersetzt irgendwelche zu optimierenden Zuordnungen. Übung, Vorbereitung und System hebeln praktisch bis zu einem gewissen Grad irgendwelche Compiler Zuweisungsoptimierungs- Notwendigkeiten aus. > Sinngemäss gilt das dann auch für > Caches. > Und bei modernen Rechnern spielt die Musik nunmal im Bereich der > Speicherbandbreite und nicht beim Abzählen von Taktzyklen. Um die gehts hier aber nicht. @Thomas Eckmann Nette Story. Leider am Thema vorbei.
:
Bearbeitet durch User
Moby A. schrieb: > Die Reduzierung der Taktfrequenz spart in jedem Fall. Nein, nicht in jedem Fall. Da der Stromverbrauch von Mobilgeräten längst ein entscheidendes Thema ist, gibt es auch entsprechende Untersuchungen. Die je nach Randbedingungen(!) zum Ergebnis kommen, dass es effizienter sein kann, kurz aber heftig zu verbrauchen als langsam kriechend wenig. Oder irgendwas zwischendrin. Das liegt auch daran, dass in Chiptechnik jenseits der AVRs nicht nur Umschaltvorgänge zum Verbrauch beitragen, sondern ebenso Leckströme. Und die lassen sich am einfachsten durch partielle Totalabschaltung der Versorgung reduzieren. > Mein überlegtes, fixes Registerzuordnungssystem ersetzt irgendwelche zu > optimierenden Zuordnungen. Eben. Mit dynamische Zuweisungen je nach lokalem Bedarf tun sich Compiler leichter als Programmierer. Wenn die Anzahl Register für statische Zuweisung ausreicht spielt das keine Rolle. Jenseits davon jedoch schon.
:
Bearbeitet durch User
A. K. schrieb: > Das liegt auch daran, dass in Chiptechnik jenseits der AVRs nicht nur > Umschaltvorgänge zum Verbrauch beitragen, sondern ebenso Leckströme. Siehst du auch schon bei den AVRs mit kleineren Strukturen, insbesondere bei etwas höheren Spannungen. Die 3,3-V-Verbrauchskurve eines XmegaA3 kommt ohne Takt schon auf fast 100 µA raus statt nahe 0.
Jörg W. schrieb: > A. K. schrieb: >> Das liegt auch daran, dass in Chiptechnik jenseits der AVRs nicht nur >> Umschaltvorgänge zum Verbrauch beitragen, sondern ebenso Leckströme. > > Siehst du auch schon bei den AVRs mit kleineren Strukturen, insbesondere > bei etwas höheren Spannungen. Die 3,3-V-Verbrauchskurve eines XmegaA3 > kommt ohne Takt schon auf fast 100 µA raus statt nahe 0. Das mit dem Takt/Stromaufnahme war nur ein kleiner Trick von mir, M. ein weiteres Mal zu entlocken, wie weit seine Kenntnisse tatsächlich reichen. Dabei steht das alles in seinem Geliebten Datenblatt. Man muß die Diagramme nur lesen können. Falls es daran Zweifel gibt: Ich hab kein Problem damit, daß jemand was nicht weiß, denn das kann jedem passieren. Nur darf man sich dann nicht als Guru präsentieren.
:
Bearbeitet durch User
A. K. schrieb: > Wenn die Anzahl Register für > statische Zuweisung ausreicht spielt das keine Rolle. Genau so ist es! > Moby A. schrieb: > Die Reduzierung der Taktfrequenz spart in jedem Fall. > > Nein, nicht in jedem Fall. Bei einem gegebenen Controller spart die Reduzierung der Frequenz immer. Carl D. schrieb: > Das mit dem Takt/Stromaufnahme war nur ein kleiner Trick von mir, M. ein > weiteres Mal zu entlocken Du hast mir gar nichts entlockt. Von Dir aber hätte ich fast angenommen, Du empfielst den 4 Ghz Pentium4 als besonderen Stromsparer ;-)
:
Bearbeitet durch User
P. M. schrieb: > Ja genau, Tatsachen verdrehen: Du verlangst plötzlich, dass ein > Assembler-Beispiel kürzer in C umgesetzt wird. Dabei hat nie jemand > behauptet, mit C würde man auch kleinste Assembler-Projekte > speichermässig schlagen. Zumal er sich, wenn man sein "Projekt" mal etwas genauer ansieht, die größtmögliche Mühe gegeben hat, es dem C-Compiler so schwer wie irgend möglich zu machen. Das beweist, daß es ihm nicht gar um einen fairen Vergleich, sondern stattdessen nur um eine Bestätigung seiner kruden Behauptungen geht. Das wird auch durch sein penetrantes Insistieren in diesem Thread einmal mehr bewiesen. Daß mit seinen mühsam Gestrickten ohnehin keine Aussagen über C, sondern allenfalls über den Optimizer des Compilers getroffen werden könnten, ist ihm deswegen auch egal -- und aus demselben Grund hat er, als mein Code kleiner aussah, urplötzlich hektisch neue Anforderungen erfunden. Obwohl er sich vorher ja tagelang zu fein war, sich auf Anforderungen festzulegen und diese sauber auszuformulieren: als er die Möglichkeit dazu hatte, hat er lieber den Schwanz eingekniffen. War aber auch schon doof: da hat er sich extra was zusammengebastelt, nur um seine Überlegenheit zu zeigen, und dann kommt so ein Dahergelaufener und liefert etwas ab, das auf den ersten Blick kleiner aussieht als sein Assembler-Code. Dabei hatte der Arme sich doch so viel Mühe gegeben und anstelle eines üblichen Standardprotokolls eigens ein selbstgefrickeltes 24-Bit-Gerümpel mit kaputter Checksumme abgeliefert. Allein das beweist, daß sein Code im Gegensatz zu seinen Behauptungen noch niemals produktiv genutzt worden sein kann, denn dabei hätte der Fehler auffallen müssen. Dabei war die Sache eigentlich schon gelaufen. Moby hatte seinen Versuch bereits gehabt und ihn grandios vergeigt. Yalu hat in C etwas präsentiert das in jeder nur denkbaren Hinsicht besser war als Mobys Code, vor allem nach Mobys eigenen Kriterien: Beitrag "Re: C versus Assembler->Performance" Es ist daher jeder Versuch überflüssig, über Mobys neues Stöckchen mit seinem "Kleinen Tiny13 Sensorboard" zu springen: selbst wenn sich jemand die Mühe machen und eine bessere C-Implementierung abliefern würde, dann würde er nur dasselbe tun wie gehabt: neue Anforderungen oder ein neues "Projekt" mit nochmals elaborierteren Stolpersteinchen für den Compiler erfinden. Aber nachdem er ja bereits gegen Yalus Code verloren hat, ist jetzt ohnehin erstmal er an der Reihe, seine wirren und inkonsistenten Behauptungen zu belegen -- etwa gegen Deinen Code. Das wird er aber leider gar nicht erst versuchen, denn dabei würde sehr wahrscheinlich herauskommen, daß er es nicht schafft. ;-)
Moby A. schrieb: > Wer freilich die bessere Effizienz von Asm anzweifelt soll das doch an > meinem kleinen Beispiel belegen, für welches ich in Vorleistung > gegangen bin. Das hat Yalu bereits getan: Beitrag "Re: C versus Assembler->Performance" Jetzt bist Du an der Reihe, den Gegenbeweis zu erbringen und Deine Behauptungen zu belegen.
@ Sheeva P. Das hast Du Dir wie immer alles schön zusammenkonstruiert. Da gibts für mich nichts mehr zu kommentieren. Ich weiß ja, daß Du irgendwie von Deiner gescheiterten Nachbildung meines Codes ablenken mußt. Scheinbar hast Du auch nach vielen solchen sich wiederholenden Beiträgen immer noch das Gefühl, daß es nicht langt ;-) Besonders amüsant fand ich dann aber doch > nochmals elaborierteren Stolpersteinchen für den Compiler > erfinden Mensch Junge, wann wirst Du endlich begreifen, daß man da nix erfinden muß?
Moby A. schrieb: > Bei einem gegebenen Controller spart die Reduzierung der Frequenz immer. Nicht, wenn man zwischen „dauernd mit geringem Takt durchwerkeln“ und „mit schnellem Takt alles abklappern, dann schlafen legen“ entscheiden kann. Dann ist letzteres oft (aber eben auch nicht immer) effektiver.
Jörg W. schrieb: > Moby A. schrieb: > Bei einem gegebenen Controller spart die Reduzierung der Frequenz immer. > > Nicht, wenn man zwischen „dauernd mit geringem Takt durchwerkeln“ und > „mit schnellem Takt alles abklappern, dann schlafen legen“ entscheiden > kann. Dann ist letzteres oft (aber eben auch nicht immer) effektiver. Na logo! Wenn man Sleep-Modi einsetzen kann tut man das natürlich und spart noch mehr! Das ändert aber nichts dran daß man mit reduzierter Frequenz defacto immer Energie spart- solange natürlich die Erfüllung der gestellten Aufgabe gewährleistet ist.
Moby A. schrieb: > >> Moby A. schrieb: >> Die Reduzierung der Taktfrequenz spart in jedem Fall. >> >> Nein, nicht in jedem Fall. > > Bei einem gegebenen Controller spart die Reduzierung der Frequenz > immer. > wieder etwas das du einfach so behauptest, und ja, wir wissen es, jemand anderer soll es widerlegen?? wie kommst du auf das? wer schneller rechnet kann länger schlafen.. du senkst den Takt aber soweit ab, dass überhaupt (fast) nie geschlafen wird trotzdem: >Die Nutzung der Sleep-Modi ist unabhängig davon anzuraten. Deshalb lasse >ich gern das Hauptprogramm im Sleep-Modus und überlasse die >Funktionalität den Interrupts. das passt doch sowieso nicht zusammen..
:
Bearbeitet durch User
Moby A. schrieb: > Das ändert aber nichts dran daß man mit reduzierter Frequenz defacto > immer Energie spart Nein, tut es nicht. Aber du begreifst es nicht (oder willst es nicht begreifen), also lassen wir's einfach. Endlosschleifen hatten wir schon genug.
Robert L. schrieb: > wieder etwas das du einfach so behauptest, und ja, wir wissen es, jemand > anderer soll es widerlegen?? Doch, das ist schon richtig. Aber es ist wie bei seinem Assemblerzeugs: er dreht es so hin, wie er es braucht. Ein x-beliebiger Controller mit niedrigerer Taktfrequenz braucht weniger Strom als mit hoher Frequenz. Dem kann man nicht widersprechen. Wir sind nur schon einen Schritt weiter. wir wissen, dass das nicht linear runtergeht. Wir wissen, dass es effektivere Möglichkeiten gibt. Ginge er darauf ein, würde er eingestehen, dass sein optimales Projektchen nicht nur, sondern auch an dieser Stelle nicht optimal ist. Das wird er natürlich weder sich eingestehen, noch wird er es gar zugeben. Deshalb wird er es natürlich jemand anderes widerlegen müssen. Und nach 1000 Beiträgen sind wir keinen Schritt weiter gekommen. mfg.
:
Bearbeitet durch User
Wir sind hier zwar beim Thema Assembler, aber Robert L. schrieb: > Bei einem gegebenen Controller spart die Reduzierung der Frequenz immer. > wieder etwas das du einfach so behauptest, und ja, wir wissen es, jemand > anderer soll es widerlegen?? Das muß niemand widerlegen, denn es stimmt. > wer schneller rechnet kann länger schlafen.. 1. sofern dieses "ereignisgesteuerte" Modell in der konkreten App überhaupt anwendbar ist und 2. die möglichen Sleep-Phasen relativ lang sind und 3. die spezifischen Controller-Hardware Eigenschaften das unterstützen kann das ein Spezial-Fall sein, Ok. Aber das ist von irgend einer Regelhaftigkeit entfernt, wie auch Jörg W.s > Dann ist letzteres oft (aber eben auch nicht immer) effektiver. nahelegt.
Thomas E. schrieb: > Deshalb wird er es natürlich jemand anderes widerlegen müssen. Und nach > 1000 Beiträgen sind wir keinen Schritt weiter gekommen. Das kann ja viele Gründe haben ;-) > Ginge er darauf ein, würde er eingestehen, dass sein optimales > Projektchen nicht nur, sondern auch an dieser Stelle nicht optimal ist. Natürlich ließe sich das leicht bewerkstelligen: Im Hauptprogramm noch ein Sleep und gut ist. Nur zielte mein Projekt jetzt nicht speziell aufs Stromsparen, auch wenn es mit nur 128kHz intern gut darauf vorbereitet ist. Das Hauptprogramm sollte zunächst mal übersichtlicher Ansatzpunkt für Erweiterungen sein.
Wie oft wollt ihr dem Troll noch Futter vor die Füße werfen? Lasst diesen Wal verhungern und gut ist's ....
Gu. F. schrieb: > Wie oft wollt ihr dem Troll noch Futter vor die Füße werfen? > Lasst diesen Wal verhungern und gut ist's .... ja. Moby A. schrieb: > Deshalb lasse ich gern das Hauptprogramm im Sleep-Modus und überlasse die > Funktionalität den Interrupts. Moby A. schrieb: > sofern dieses "ereignisgesteuerte" Modell in der konkreten App > überhaupt anwendbar ist [...] kann das ein Spezial-Fall sein, Ok. Aber das > ist von irgend einer Regelhaftigkeit entfernt Rolle rückwärts und voll auf die Fresse geflogen! mfg.
Ralf G. schrieb: > Thomas E. schrieb: > Seht ihr. > > Ja! Ich tät ja gern endlich endlich mal Beweise für die allumfassende C-Überlegenheit sehen ;-)
Thomas E. schrieb: > voll auf die Fresse geflogen ... ist viel eher die Aussage: Dreht die Taktfrequenz nur genügend auf, umso schneller kann geschlafen werden und umso mehr Energie wird gespart. So ein Mist, warum bringen meine Tinys nur 20 MHz ;-)
Moby A. schrieb: > Natürlich ließe sich das leicht bewerkstelligen: Im Hauptprogramm noch > ein Sleep und gut ist. Nur zielte mein Projekt jetzt nicht speziell aufs > Stromsparen, auch wenn es mit nur 128kHz intern gut darauf vorbereitet > ist. Das Hauptprogramm sollte zunächst mal übersichtlicher Ansatzpunkt > für Erweiterungen sein. Sehr geehrter Herr Moby, in ihrem Beispielprojekt, welches hier als Referenz für ihre Argumentation herangezogen wird, befindet sich allerdings ein Sleep. Sollten sie etwa den Überblick über ihre Kommunikationsstrategie, die mich sehr an das erinnert, was man in Forenbeiträgen allgemein Trollbeiträge nennt? Das ist natürlich nur meine persönliche, subjektive Wahrnehmung und soll keinesfalls einen persönlichen Angriff ihnen gegenüber darstellen, noch soll es die Meinung anderer Forumsteilnehmer widergeben. mfg.
Ralf G. schrieb: > Wenn schon, dann Herr AVR Ich dachte das wäre sein akademischer Grad. Auf die amerikanische Weise dem Namen nachgestellt und er nur resourcensparend, wo immer es geht, das Komma weggelassen hat. mfg.
Thomas E. schrieb: > befindet sich allerdings ein Sleep. Schön, daß das nochmal klargestellt wurde. Da bin ich aber jetzt echt froh ;-) Allerdings ändert Dein Kampf auf dem Nebenkriegsschauplatz "Energiesparen" jetzt nichts an der Überlegenheit von Asm im beschriebenen Einsatzgebiet. Was Kommunikationsstrategien anbetrifft, nun, da ist die Welt hier recht bunt und auch ich habe da eine gewisse persönliche, subjektive Wahrnehmung, die ich aber keinesfalls über andere stellen würde! Konnte ich Deinen Beitrag adäquat beantworten?
Thomas E. schrieb: > Sehr geehrter Herr Moby, Na also, geht doch. ;-) > Sollten sie etwa den Überblick über ihre Kommunikationsstrategie, die > mich sehr an das erinnert, was man in Forenbeiträgen allgemein > Trollbeiträge nennt? Hier allerdings hast zunächst du den Überblick über die Kommunikation verloren, nämlich den über die Grammatik. ;-)
:
Bearbeitet durch User
Thomas E. schrieb: > Sollten sie etwa den Überblick über ihre Kommunikationsstrategie, die > mich sehr an das erinnert, was man in Forenbeiträgen allgemein > Trollbeiträge nennt? Ohje. Da habe ich doch tatsächlich in meinem mimosenkonformen Satz ein "verloren haben" vergessen. Richtig heissen muss es natürlich: Sollten sie etwa den Überblick über ihre Kommunikationsstrategie, die mich sehr an das erinnert, was man in Forenbeiträgen allgemein Trollbeiträge nennt, verloren haben? Ich bitte, diese Nachlässigkeit zu entschuldigen. mfg.
Thomas E. schrieb: > Ohje. Da habe ich doch tatsächlich in meinem mimosenkonformen Satz ein > "verloren haben" vergessen. Yep, und das in ein paar Zeilen. Und da wirfst du Moby vor, den Überblick in den weit über 1000 Beiträgen des Threads verloren zu haben, wovon wohl eine dreistellige Zahl von ihm sind? Sein AVR hat nur 32 Register. Dann ist Schluss. Mehr lässt sich nur aufwändig speichern. Soviel Gedächtnis ist also jenseits seines Zielgebiets. ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Allerdings ändert Dein Kampf auf dem Nebenkriegsschauplatz > "Energiesparen" jetzt nichts an der Überlegenheit von Asm im > beschriebenen Einsatzgebiet. Sehr geehrter Herr Moby AVR, wenn ich die letzten 1149 Beträge Revue passieren lasse, wird in nahezu allen Beträgen nicht das eigentliche Thema dieses Threads behandelt. Nämlich, die von ihnen in der Überschrift triumphal angekündigte Renaissance der Assemblerprogrammierung. Ich lese von ihnen fast ausschliesslich Fakten zur Überlegenheit von Assembler und die Versuche der Mitforisten sie und ihre Ausführungen zu diskreditieren. Da dieser Thread somit ohnehin schon lange, mit einer kurzen Unterbrechung, nicht mehr das Ursprungsthema behandelt, sehe ich durchaus die Möglichkeit auf die anderen Aspekte, der von ihnen häufig genannten Effizienz von Controller-Anwendungen, einzugehen. mfg.
:
Bearbeitet durch User
Thomas E. schrieb: > in der Überschrift triumphal angekündigte, > Renaissance der Assemblerprogrammierung Die Überschrift stammt nicht aus meiner Feder. > sehe ich > durchaus die Möglichkeit auf die anderen Aspekte, der von ihnen häufig > genannten Effizienz von Controller-Anwendungen, einzugehen. Das Recht auf Sichtung verschiedenster Aspekte von was auch immer möchte ich hier niemand absprechen. Mich interessiert hier nur der Aspekt der Effizienz einer Sprache speziell im Vergleich Asm vs. C. Ich bitte das zu entschuldigen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Die Überschrift stammt nicht aus meiner Feder. Sehr geehrter Herr Moby AVR, da sie diese Überschrift aber benutzten und diese nicht als Zitat kennzeichneten, musste ich sehr wohl davon ausgehen, dass diese ihre Meinung darstellt und sie eine, in diese Richtung gehende Diskussion anregen wollten. Moby A. schrieb: > Mich interessiert hier nur der Aspekt der > Effizienz einer Sprache speziell im Vergleich Asm vs. C Dieses geht aber aus der Überschrift nicht hervor. Wenn es von vornherein ihre Absicht war, innerhalb der Forengemeinde ausschliesslich diesen einen, von ihnen genannten Aspekt, zu diskutieren, hätten sie dieses durchaus durch eine eindeutigere Wahl der Überschrift erkennbar machen können. Damit wären ihnen und mir sowie auch anderen Forumsteilnehmern sicherlich einige Missverständnisse erspart geblieben. mfg.
:
Bearbeitet durch User
Thomas E. schrieb: > Damit wären ihnen und mir sowie auch anderen > Forumsteilnehmern sicherlich einige Missverständnisse erspart geblieben. Wenn eine solche Meldung auftaucht und ich als TO sofort die Meinung vertrete, daß die Verlautbarung ob der Asm-Effizienz bei hardwarenahem IOT/MSR ebendiesen plausiblen Hintergrund hat, dann wird bzw. wurde das mangels anderer diskutierter Erklärungen zur klaren Thread Leitlinie, bei der keine Missverständnisse mehr auftreten sollten, aufgetreten sind, jetzt nur vorgetäuscht werden ;-) Als Mod Yalu nun nach >1000 Beiträgen mit (von mir ungeprüfter) Recherche zu einer (mich) überzeugenden Erklärung der Tiobe-Meldung kam, hatte ich mich damit eigentlich abgefunden...
:
Bearbeitet durch User
P. M. schrieb: > Du beziehst dich wohl auf mich und ein, zwei meiner Posts. Auch, aber zu einem sehr viel kleineren Teil als Du vermutest. Die überwiegende Zahl Deiner Aussagen finde ich nicht zu beanstanden. >Auf einer sachlichen Ebene ist der Thread schon längst erledigt. Aber sowas von ... > Es geht nun wirklich nur noch darum, Moby > klarzumachen, wie absurd (und teilweise unsportlich) er sich in dieser > Diskussion verhält. Nein, Dir mag es darum gehen, ich beziehe meinen 'Lustgewinn' hier zu einen großen Teil daraus wie mühelos Moby jeden Versuch abwehrt sich durch so etwas banales wie Fakten beeinflussen zu lassen. Jeder der nur 20% von diesen Thread gelesen hat hätte vollkommen mühelos zu der Einschätzung kommen können das es nichts zwischen Himmel und Erde gibt was Mobys Überzeugung ändern wird. Ich amüsiere mich köstlich darüber das dieser völlig offensichtliche Umstand wirlich so schwer zu verstehen ist. Zum anderen sind es manchmal gerade diejenigen die Moby gute Manieren beibringen wollen die sich am heftigsten danebenbenehmen. (Bezogen auf das was in hitzigen Diskussionen noch als gutes Benehmen durchgeht)
Michael K. schrieb: > Jeder der nur 20% von diesen Thread gelesen hat hätte vollkommen mühelos > zu der Einschätzung kommen können das es nichts zwischen Himmel und Erde > gibt was Mobys Überzeugung ändern wird. Irrtum. Ein kürzeres, funktionierendes C-Gegenbeispiel. Und zwar schon vor den hunderten hiesiger und hunderten Beiträgen meines Projektthreads. Solange das nicht kommt nenne ich meine Überzeugung voller Überzeugung Wissen um Fakten ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Das hast Du Dir wie immer alles schön zusammenkonstruiert. Da gibts für > mich nichts mehr zu kommentieren. Ich weiß ja, daß Du irgendwie von > Deiner gescheiterten Nachbildung meines Codes ablenken mußt. Soso, wahrscheinlich weise ich deswegen so gerne darauf hin. Nachdem Du erst tagelang zu feige warst, die Anforderungen zu formulieren, hast Du als Reaktion auf meinen Code plötzlich feige eine neue Anforderung aus dem Hut gezaubert, die mit C kaum zu erfüllen ist. :-)) Damit hat Deine Reaktion doch schon alles gezeigt, was zu zeigen war. Und zum Glück kann das jeder selbst nachlesen. :-) > Mensch Junge, wann wirst Du endlich begreifen, daß man da nix erfinden > muß? Das hat Yalus Code ja gezeigt. :-) Soll ich Dir den Link nochmal schicken? Du scheinst ja zu einer überaus selektiven Vergeßlichkeit zu neigen.
Moby A. schrieb: > Ich tät ja gern endlich endlich mal Beweise für die allumfassende > C-Überlegenheit sehen ;-) Sowas hat außer Dir doch niemand gesagt, im Gegenteil. Das ist nur eine Strohpuppe von Dir. Warum sollte jemand etwas beweisen, das er nie gesagt hat? Warum sollte jemand etwas beweisen, das Du behauptet hast?
Moby A. schrieb: > Irrtum. Ein kürzeres, funktionierendes C-Gegenbeispiel. Das hast Du längst bekommen: Beitrag "Re: C versus Assembler->Performance"
Sheeva P. schrieb: > neue Anforderung aus dem Hut gezaubert, die mit C kaum zu erfüllen ist. Sorry, zaubern kann ich nicht. Was Du "neue Anforderung" nennst war als essentielles Ressourcenverbrauchs-Merkmal meines Codes längst gegeben. Worin sollten die Codes verglichen werden? Daß etwas mit C nicht zu erfüllen ist war die ganze Zeit meine These, merkst Du das nicht? > Das hat Yalus Code ja gezeigt. :-) Soll ich Dir den Link nochmal > schicken? Du scheinst ja zu einer überaus selektiven Vergeßlichkeit zu > neigen. Um Dir ein letztes Mal den Gefallen zu tun geh ich nochmal drauf ein: 1. War sein Code nicht 1:1 kompatibel zu meinem 2. War sein Code nicht auf Funktion geprüft 3. Gab es das Angebot auf Gleichstand zu werten, welches ich 4. nicht angenommen und angekündigt habe, die vorgestellte Funktionalität zum Thema eines eigenen Projekts zu machen 5. schließlich habe ich erst mein Tiny13 Projekt zum offiziellen Streitvehikel hier und im eigentlichen Projektthread erkoren, mein Entprellbeispiel fand ich auch nicht hinreichend optimiert, es sollte in einem C++ Thread zuvor etwas ganz anderes verdeutlichen. So, nun kannst Du darüber weiter zetern bis Du schwarz wirst und Links ohne Ende anbringen. Ich rate Dir aber eher, Deine Projektruine bewohnbar zu machen und wenigstens zu einem guten Ende zu bringen. Das macht mehr Eindruck.
Gibt es hier sowas wie GOTO 1 ? Dann müsste nicht jeder hier sich die Arbeit machen, immer wieder dasselbe zu schreiben, sondern das Forum würde von selbst wieder von anfangen. Oder ist das vielleicht sogar schon eingebaut?
Ja, eigentlich liegt der Schwarze Ritter entbeint und entarmt (klar bei einem AVR-only-Fan ;-) am Boden und versucht weiter allen Angst einzujagen. Wir sollten es wie im Film machen. Ihn einfach liegen lassen und zum nächsten Abenteuer weiterziehen.
:
Bearbeitet durch User
Carl D. schrieb: > Ja, eigentlich liegt der Schwarze Ritter entbeint und entarmt > (klar bei einem AVR-only-Fan ;-) am Boden und versucht weiter allen > Angst einzujagen. Wir sollten es wie im Film machen. Ihn einfach liegen > lassen und zum nächsten Abenteuer weiterziehen. Wunschfantasien sind schon was Schönes... Meine verrate ich aber nicht ;-) Carl D., gerade Du solltest nicht von Weiterziehen reden... Dafür klebst Du seit langem viel zu sehr an meinen Beiträgen! Zieh ruhig weiter, wenn Du es schaffst ;-)
Michael K. schrieb: >> Es geht nun wirklich nur noch darum, Moby >> klarzumachen, wie absurd (und teilweise unsportlich) er sich in dieser >> Diskussion verhält. > Nein, Dir mag es darum gehen, ich beziehe meinen 'Lustgewinn' hier zu > einen großen Teil daraus wie mühelos Moby jeden Versuch abwehrt sich > durch so etwas banales wie Fakten beeinflussen zu lassen. Die wahre grosse Frage des Threads ist ja eigentlich: Wer ist dieser Moby, und warum lässt er sich wochenlang und in weit über tausend Beiträgen dermassen vorführen?
P. M. schrieb: > Die wahre grosse Frage des Threads ist ... wer hier wen vorführt ;-) Der Gedanke, daß sich Mühelosigkeit aus 'im Recht sein' ergeben könnte scheint für manchen unerreichbar zu sein.
:
Bearbeitet durch User
Moby A. schrieb: > Was Du "neue Anforderung" nennst war als essentielles > Ressourcenverbrauchs-Merkmal meines Codes längst gegeben. Von wegen, Du hast den RAM ja sogar für die Benutzung initialisiert. Und dann soll man ihn nicht benutzen dürfen? Wie lächerlich. > Um Dir ein letztes Mal den Gefallen zu tun geh ich nochmal drauf ein: > > 1. War sein Code nicht 1:1 kompatibel zu meinem > 2. War sein Code nicht auf Funktion geprüft > 3. Gab es das Angebot auf Gleichstand zu werten, welches ich > 4. nicht angenommen und angekündigt habe, die vorgestellte > Funktionalität zum Thema eines eigenen Projekts zu machen > 5. schließlich habe ich erst mein Tiny13 Projekt zum offiziellen > Streitvehikel hier und im eigentlichen Projektthread erkoren, mein > Entprellbeispiel fand ich auch nicht hinreichend optimiert, es sollte in > einem C++ Thread zuvor etwas ganz anderes verdeutlichen. Billige Ausreden, hohles Geschwätz. Aber wenig überraschend. > Ich rate Dir aber eher, Deine Projektruine bewohnbar zu machen Wozu? Dann erfindest Du doch nur wieder neue "Anforderungen". Und daß Dir an einem objektiven Vergleich nichts liegt, habe ich schon bewiesen. :-)
Sheeva P. schrieb: > Billige Ausreden, hohles Geschwätz. Aber wenig überraschend. Ist das jetzt plötzlich alles was Du dazu noch sagen kannst? Mich überrascht das schon. Reichlich billig find ich... Ich bitte daher um Verständnis wenn ich keine weitere Energie mehr in die Beantwortung Sheeva'scher Klagelieder investieren mag ;-(
:
Bearbeitet durch User
>Reichlich billig find ich...
Amüsant ist dein Sturheit zu verstehen, das unter "Effizient" jeder
ausser dir hauptsächlich die nötige Entwicklungszeit betrachtet und
einige Bytes an RAM/Flash mehr oder weniger egal sind.
Du bist der einzige, der nur auf RAM/Flash Verbrauch schielt und dafür
weit längere Entwicklungszeiten in Kauf nimmt.
Moby A. schrieb: > Ich bitte daher um Verständnis wenn ich keine weitere Energie mehr in > die Beantwortung Sheeva'scher Klagelieder investieren mag ;-( Mach das doch mit jedem hier! ;-) Ich wiederhole mich aber gern auch nochmal: Du kannst Deine Aussagen für ein 200-Byte-Programm nicht hochskalieren. Bei 1KB ist schon Ende der Fahnenstange mit ASM. Du hast da auch keinen Gegenbeweis. Ende aus, Micky Maus.
:
Bearbeitet durch Moderator
Das lustige an diesem Tiobe-Index ist ja, dass er, wenn ich mal meine Suchanfragen so betrachte, wohl schlussfolgern müsste, dass C++ und Python sehr beliebte Programmiersprachen seien, während C nur unter „ferner liefen“ rangiert. C++ benutze ich zu selten und muss daher häufiger mal nach was Gugeln, bei Python sind es vor allem die vielen Module im Netz, bei denen sich wohl kaum jemand an alle gut genug erinnern kann, da muss man auch häufiger mal eine Anfrage starten. Das relativ kleine C dagegen, welches ich tagtäglich benutze, kenne ich in- und auswendig, und eine Kopie des C-Standards hat man ja ohnehin auf der Platte rumliegen. Vermutlich wird es vielen anderen ähnlich gehen (und wenn Moby ehrlich ist, wird auch er wohl für seine AVRs kaum in einer Suchmaschine nach “assembly language” nachfragen). Das führt doch das ganze Ding aber komplett ad absurdum in seinem Aussagewert.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Ich bitte daher um Verständnis wenn ich keine weitere Energie mehr in > die Beantwortung Sheeva'scher Klagelieder investieren mag ;-( Wie lustig, da kann einer seine Niederlage und sein eigenes mieses Verhalten nicht ertragen und exkommuniziert mich. :-)
Carl D. schrieb: > Ja, eigentlich liegt der Schwarze Ritter entbeint und entarmt (klar bei > einem AVR-only-Fan ;-) am Boden und versucht weiter allen Angst > einzujagen. Wir sollten es wie im Film machen. Ihn einfach liegen lassen > und zum nächsten Abenteuer weiterziehen. Aus seiner Sicht ist er immer noch Artus ;-)
Gu. F. schrieb: > Carl D. schrieb: >> Ja, eigentlich liegt der Schwarze Ritter entbeint und entarmt (klar bei >> einem AVR-only-Fan ;-) am Boden und versucht weiter allen Angst >> einzujagen. Wir sollten es wie im Film machen. Ihn einfach liegen lassen >> und zum nächsten Abenteuer weiterziehen. > > Aus seiner Sicht ist er immer noch Artus ;-) Aber Artus hatte eine Tafelrunde, nur der Schwarze Ritter war allein ;-)
Sheeva P. schrieb: > Wie lustig, da kann einer seine Niederlage und sein eigenes mieses > Verhalten nicht ertragen und exkommuniziert mich. Das ist nicht seine Niederlage, sondern deine. Der einzige, der sein mieses Verhalten nicht ertragen kann, bis du selbst. Exkommuniziert hast du dich ebenfalls selber. Und lustig ist das auch nicht. Wetten? mfg.
Moby A. schrieb: > Sheeva P. schrieb: >> Billige Ausreden, hohles Geschwätz. Aber wenig überraschend. > > Ist das jetzt plötzlich alles was Du dazu noch sagen kannst? > Mich überrascht das schon. Reichlich billig find ich... Überhaupt nicht billig. Sheeva ist einer derjenigen Personen, die am meisten Inhalt und Argumente zum Thread beigesteuert haben. Inhaltlich konntest du rein gar nichts entgegensetzen, aber du bringst deine (widerlegten) Behauptungen trotzdem immer und immer wieder. Wer den Thread gelesen hat, der weiss, dass die Bezeichnung "billige Ausreden, hohles Geschwätz" für deine Beiträge nicht im geringsten übertrieben ist.
Weil's mich die ganze Zeit schon interessiert, ein bisschen Statistik: Moby hat bis jetzt 261 Beiträge in diesem Faden geschrieben. Alle (!) wurden negativ bewertet. In Summe sind's 1209 downvotes geworden. Am schlechtesten hat der erste Beitrag mit -19 abgeschnitten, die beste Bewertung war eine -1. Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten.
Thomas E. schrieb: > Sheeva P. schrieb: >> Wie lustig, da kann einer seine Niederlage und sein eigenes mieses >> Verhalten nicht ertragen und exkommuniziert mich. > > Das ist nicht seine Niederlage, sondern deine. Der einzige, der sein > mieses Verhalten nicht ertragen kann, bis du selbst. Exkommuniziert hast > du dich ebenfalls selber. Und lustig ist das auch nicht. > > Wetten? Warum sollte ich gegen meine eigenen Erwartung wetten? :-)
Thomas E. schrieb: > Das ist nicht seine Niederlage, sondern deine. Was soll er denn noch tun? Moby ist nicht fähig oder nicht willens, sachlich zu diskutieren. Da darf man irgendwann auch mal persönlich werden und sagen, was man von der Person hält. Wer hier immer noch sachliche Argumente fordert, der ist schon länger fehl am Platz.
Ironiedetektor schon wieder kaputt? Das hält ja keiner aus... mfg. Nein, ich hänge da nicht so ein albernes Strich-Doppelpunkt-Klammer hinter.
:
Bearbeitet durch User
P. M. schrieb: > Sheeva ist einer derjenigen Personen, die am > meisten Inhalt und Argumente zum Thread beigesteuert haben. Danke, aber bitte mach' mich nicht größer, als ich bin. Viele Leute haben hier viel größere Beiträge beigesteuert als ich. P. M. schrieb: > Thomas E. schrieb: >> Das ist nicht seine Niederlage, sondern deine. > > Was soll er denn noch tun? Moby ist nicht fähig oder nicht willens, > sachlich zu diskutieren. Da darf man irgendwann auch mal persönlich > werden und sagen, was man von der Person hält. Wer hier immer noch > sachliche Argumente fordert, der ist schon länger fehl am Platz. Entschuldige, aber ich fürchte, Du hast die Ironietags an Thomas' Beitrag übersehen. :-)
Sheeva P. schrieb: > Entschuldige, aber ich fürchte, Du hast die Ironietags an Thomas' > Beitrag übersehen. :-) Wärs nicht einfacher, den ganzen Thread damit zu versehen, als jeden Beitrag einzeln? Das entspräche auch ganz Mobys Sinn für Sparsamkeit.
:
Bearbeitet durch User
A. K. schrieb: > Das entspräche auch ganz Mobys Sinn für Sparsamkeit. ... zumal jeder extra Beitrag zusätzliches RAM in seinem Rechner belegt.
:
Bearbeitet durch User
Gu. F. schrieb: > Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten. Das Arithmetische Mittel ist gerne mal ungeeignet, den ein einziger Ausreisser kann den ganzen Schnitt versauen oder schönen. Da braucht nur eine einzigen Multimillionär in die Stadt zu ziehen und auf wundersame Weise steigen Durchschmittsvermögen und -einkommen aller. Stabiler sind da z.B. Quantile wie Median (50% Quantil).
Johann L. schrieb: >> Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten. > > Da braucht nur eine einzigen Multimillionär in die Stadt zu ziehen und > auf wundersame Weise steigen Durchschmittsvermögen und -einkommen aller. Auch der Median hat wundersame Effekte. Wenn man der Mittelschicht etwas wegnimmt und es dem Millonär gibt, dann reduziert man die Armut. ;-)
P. M. schrieb: > Die wahre grosse Frage des Threads ist ja eigentlich: Wer ist dieser > Moby, und warum lässt er sich wochenlang und in weit über tausend > Beiträgen dermassen vorführen? Ist er es denn der vorgeführt wird ? Moby hat eine Behauptung aufgestellt die von vornherein Quatsch war. Die Diskussion zu gewinnen war niemals sein Ziel. Sein Ziel ist es uns dazu zu bringen immer verbisserner um den Knochen zu kämpfen den er uns hingeworfen hat. Man KANN Moby nicht umstimmen, weil das überhaut nie vorgesehen war. Jeden der das versucht treibt er wie ein Schaf zur Schlachtbank, d,h, solange bis man aufgibt oder auf den Level persönlicher Beleidigungen herabsteigt. Das ist ein simples kleines Psychospiel. Er bricht von sich aus den Kontakt nicht ab und signalisiert immer wieder das es doch klappen könnte ihn zu besiegen wenn man nur noch etwas am Ball bleibt. Das kann noch Monate so weitergehen. Ich find das ja ganz lustig als Zeitvertreib während ich meinen Cappuccino schlürfe. Ihr könnt nicht gewinnen weil ihr Euch weitestgehend an Diskussionsregeln haltet. Argumentationsketten, Indizien, Fakten, Erfahrungsberichte, verweis auf persönliche Qualifikationen, der ganze Kram. Moby tut das nicht. Er benutzt Worte einfach so wie er sie gerade braucht. Er stellt so schnell neue Behauptungen auf, verdreht so schnell Eure Worte und ignoriert dabei alles was ihm nicht passt, das man so gegen ihn einfach nicht gewinnen kann. Gewinnen kann man das nur auf einer ganz persönlichen Basis, indem man einfach kopfschüttelnd weiterzieht.
Michael K. schrieb: > Ihr könnt nicht gewinnen Michael K. schrieb: > Gewinnen kann man das nur... Doch, ich (und viele andere hier) gewinnen regelmäßig. Ich seh das hier genauso wie den Kurt B. Thread, der momentan leider mit Inaktivität glänzt. Ich beziehe hieraus einen kurzen, wenn auch vergnüglichen Lustgewinn wenn in der Arbeit gerade a weng Luft ist, z.B. weil der Compiler wieder länger braucht oder man auf irgendne Rückmeldung wartet. Ich denke, so gut wie alle die hier schon länger dabei sind wissen genauso wie du, dass der "Gewinn" niemals darin bestehen wird, den Diskussionsgegner von der eigenen Meinung zu überzeugen.
A. K. schrieb: > Johann L. schrieb: >>> Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten. >> >> Da braucht nur eine einzigen Multimillionär in die Stadt zu ziehen und >> auf wundersame Weise steigen Durchschmittsvermögen und -einkommen aller. > > Auch der Median hat wundersame Effekte. Wenn man der Mittelschicht etwas > wegnimmt und es dem Millonär gibt, dann reduziert man die Armut. ;-) Will-Rogers? https://de.wikipedia.org/wiki/Will-Rogers-Phänomen
Michael K. schrieb: > Ihr könnt nicht gewinnen Michael K. schrieb: > Gewinnen kann man das nur... Für einen, der nur andere vorführen will, läßt sich M. aber leicht auf's Glatteis locken und bricht aus regelmäßig ein. Auch wenn er das selber nicht merkt: die anderen stehen im Trockenen! Und als Gegner spielt er einfach einige Gewichtsklassen zu tief.
trotz >Übung, Vorbereitung, System . und der allumfassenden Überlegenheit von ASM kommt dann trotzdem sowas raus: > mein > Entprellbeispiel fand ich auch nicht hinreichend optimiert, .. wie kann denn sowas passieren? (ich dachte mir das ATtiny13 "Projekt" hat neben den 2 analogen Werten, auch 2 digitale??? sind die jetz nicht entprellt ?)
Robert L. schrieb: > (ich dachte mir das ATtiny13 "Projekt" hat neben den 2 analogen Werten, > auch 2 digitale??? sind die jetz nicht entprellt ?) Ja, sind sie nicht. Darf man vermutlich keine mechanischen Taster anschließen. Das steht doch aber alles klar und deutlich lesbar in der Spezif^H^H^H^H^H^H^H^Hm Sourcecode drin.
Johann L. schrieb: > Will-Rogers? Kannte ich bisher nicht, aber grob ähnlich. Aus der Mittelschicht zu nehmen senkt das Medianeinkommen. Dies den Reichen zu geben ist hingegen neutral. Wenn die Armutsgrenze als 50% vom Media definiert ist (relative Armut), dann migrieren durch den sinkenden Median einige aus der Armut in die Mittelschicht, obwohl sie nachher soviel haben wie vorher. Der Grenzfall ist die Marx'sche Prognose von der entfallenden Mittelschicht. Dann liegt der Medien nur knapp über dem Boden und Armut existiert nicht mehr.
:
Bearbeitet durch User
Angehängte Dateien:
-
moby_histo.png
1,6 KB
Johann L. schrieb: > Gu. F. schrieb: >> Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten. > > Das Arithmetische Mittel ist gerne mal ungeeignet, den ein einziger > Ausreisser kann den ganzen Schnitt versauen oder schönen. > > Da braucht nur eine einzigen Multimillionär in die Stadt zu ziehen und > auf wundersame Weise steigen Durchschmittsvermögen und -einkommen aller. > > Stabiler sind da z.B. Quantile wie Median (50% Quantil). Na ja, passt schon ganz gut. Hier noch das Histogram :-)
Jörg W. schrieb: > Das steht doch aber alles klar und deutlich lesbar in > der Spezif^H^H^H^H^H^H^H^Hm Sourcecode drin. *ROFL* Einfach köstlich!
Gu. F. schrieb: > Na ja, passt schon ganz gut. Sagt halt nur nicht viel mehr aus, als dass es ein paar hier gibt, die ihm schätzungsweise aufgrund seines Namens immer eine negative Bewertung geben. Selbst für sowas bekommt er einen Haufen Minuspunkte: Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Ich verstehe Moby so: 1. Er hat ein winziges simples Programm erstellt, dass keine Daten im RAM ablegen muss, weil seine 32 Universalregister dafür ausreichend sind. Nun behauptet er, dass er in ASM für sein Programm keinen RAM benötigt, und definiert diesen Umstand (oder Zustand) als "resourcensparend. Damit hat er für sich Recht. 2. Er behauptet, dass die gleiche Funktionalität - in C geschrieben - RAM benötigen wird. Damit hat er auch Recht, denn jeder C Compiler ist so programmiert und konfiguriert, dass er den RAM verwendet, wenn er im Controller vorhanden ist. Auch damit hat er Recht. 3. Er definiert für diese erwünschte Funktionalität den Umstand "keine Belegung des RAM" als resourcensparend, den Umstand "Benutzung von RAM" als resoucenverschwendend. Damit hat er nach der Subsumption seiner selbst erschaffenen Tatsachen unter seine selbst definierten Begriffe Recht. Ob das aber jemals einen echten Programmierer interessiert ist Moby egal. In seiner Welt ist das eben so. Moby ist begeistert von ASM. Es überkommt ihn ein Hochgefühl, wenn der kleine Tiny genau das macht, was Moby sich wünscht und Moby dabei über jeden Takt, jedes Register und jeden Prozessschritt die absolute Kontrolle behält. Moby ist froh, dass es so eine einfache Sprache wie ASM gibt, weil er für Hochsprachen unzugänglich und unfähig ist, sie zu erlernen. Es ist kaum auszumalen, welchen Hochgefühl den Moby ereilen würde, wenn er mal in C ein richtiges Programm erstellen würde, sehen würde, was der Prozessor wirklich drauf hat, und wie einfach es ist, ihn zu unglaublich komplexen Dingen zu bewegen. Dafür müsste er nur mal seine Fesseln ablegen und überhaupt mal programmieren lernen. Naja, vielleicht in seinem nächsten Leben.
Jörg W. schrieb: > Robert L. schrieb: >> (ich dachte mir das ATtiny13 "Projekt" hat neben den 2 analogen Werten, >> auch 2 digitale??? sind die jetz nicht entprellt ?) > > Ja, sind sie nicht. Darf man vermutlich keine mechanischen Taster > anschließen. Das steht doch aber alles klar und deutlich lesbar in > der Spezif^H^H^H^H^H^H^H^Hm Sourcecode drin. Die Taster müssen natürlich über ein Cortex M0 Shield entprellt werden. so komplizierte Dinge sollte man immer in Spezial-Hardware auslagern.
Carl D. schrieb: > so komplizierte Dinge sollte man immer in Spezial-Hardware auslagern. „keine typische 8-Bit-MSR-Anwendung“
Jörg W. schrieb: > Gu. F. schrieb: >> Na ja, passt schon ganz gut. > > Sagt halt nur nicht viel mehr aus, als dass es ein paar hier gibt, > die ihm schätzungsweise aufgrund seines Namens immer eine negative > Bewertung geben. Selbst für sowas bekommt er einen Haufen Minuspunkte: > > Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Es sagt nicht viel aus wenn einer 260 Beiträgen über 1200 Miese kassiert????
Gu. F. schrieb: > Es sagt nicht viel aus wenn einer 260 Beiträgen über 1200 Miese > kassiert? Es sagt über seine konkreten Beiträge hier gar nichts aus, sondern nur was darüber, dass er sich hinreichend unmöglich gemacht hat mit seinem Auftreten, als dass er eben selbst für eher moderate Beiträge, für die sonst kein Mensch auch nur ansatzweise auf die Idee käme, positive oder negative Bewertungen zu vergeben, Minuspunkte kassiert. Damit ist deine Statistik aber für die Katz', denn sie besagt weiter nichts als dass Moby, egal was er schreibt, niemand hier leiden kann. Das wiederum brauchst du nicht erst mit Zahlenakrobatik zu belegen, das war vermutlich selbst Moby auch so schon klar (er interpretiert das Ergebnis nur als Überlegenheit denn als Niederlage). p.s.: Kauf' dir mal 'ne neue Tastatur, deine Fragezeichentaste prellt.
:
Bearbeitet durch Moderator
Also eins muß man dem Moby wirklich lassen. Er hat dem Forum massig Redewendungen für künftige Threads geliefert. Ich seh schon folgendes Szenario... Anfänger stellt ne Fragen, liefert aber keinerlei Hintergrundinfos (Schaltbilder, Code, Prozessor, usw.) Frage: "Warum geht denn die LED nicht an wenn ich den Taster drücke?" Antwort: "Na das ist halt keine typ. 8-bit MSR Anwendung"* * (Früher stand hier 42 o.s.ä.)
Jörg W. schrieb: > p.s.: Kauf' dir mal 'ne neue Tastatur, deine Fragezeichentaste prellt. "????" ist das international gebräuchliche Zeichen für "Häääää?" ;-)
Jörg W. schrieb: > p.s.: Kauf' dir mal 'ne neue Tastatur, deine Fragezeichentaste prellt. Geht auch per Software: Entprellung: Softwareentprellung ;-)
:
Bearbeitet durch Moderator
Markus M. schrieb: > Dafür müsste er [Moby] nur mal seine Fesseln ablegen und überhaupt > mal programmieren lernen. Naja, vielleicht in seinem nächsten Leben. hehe, in seinem nächsten Leben wird er zu einem eingesparten Nibble.
Jörg W. schrieb: > Carl D. schrieb: >> so komplizierte Dinge sollte man immer in Spezial-Hardware auslagern. > > „keine typische 8-Bit-MSR-Anwendung“ Das besagte Attiny Projektchen ist m.E. keine typische MSR-Anwendung, sondern vielmehr ein simpler Fernwirksender. Bei 3Hz Abtastung kann man sich die Entprellung sparen.
Witkatz :. schrieb: > Bei 3Hz Abtastung kann man sich die Entprellung sparen. Da kommt er nicht drum herum. Denn eine vernünftige Entprellung eliminiert nicht nur das Prellen eines Tasters an sich, sondern filtert auch sehr effektiv Störimpulse aus. Ohne Entprellung würde ein Störimpuls, der zufällig im Abtastmoment auftritt, eine Fehlfunktion auslösen. mfg.
Thomas E. schrieb: > filtert auch sehr effektiv Störimpulse aus. Achso, ich dachte das wäre bei der ausgeklügelten Schaltung in Hardware gelöst. Leider kenne ich nicht den Schaltplan. War da nicht der "Kondensator rechts unten" im Layout für Entstörung, Glättung und EMV Schutz zuständig?
Matthias L. schrieb: > Du bist der einzige, der nur auf RAM/Flash Verbrauch schielt und dafür > weit längere Entwicklungszeiten in Kauf nimmt. Ressourcen- Nachteile sind das, was C mitbringt und das um was es mir hier allein geht. Entwicklungszeiten sind im 8-Bit MSR Bereich eine Sache von Übung, Vorbereitung, System ;-) Frank M. schrieb: > Bei 1KB ist schon Ende der Fahnenstange mit ASM. > Du hast da auch keinen Gegenbeweis. Ende aus, Micky Maus. Da ist noch laaaange kein Ende ;-) Asm-Code selbst jenseits 10K gibts genug. Jörg W. schrieb: > Das relativ kleine C dagegen, welches ich tagtäglich benutze, kenne ich > in- und auswendig, und eine Kopie des C-Standards hat man ja ohnehin > auf der Platte rumliegen. Simply Asm ist noch vieeel kleiner. Da braucht man keinen XYZ-Standard auf der Platte ;-)
Moby A. schrieb: > Da ist noch laaaange kein Ende ;-) Nur eine Behauptung. > Asm-Code selbst jenseits 10K gibts genug. C-Code jenseits 10K gibts noch viel mehr. Soviele Masochisten kann es auch nicht geben.
Sheeva P. schrieb: > Wie lustig, da kann einer seine Niederlage und sein eigenes mieses > Verhalten nicht ertragen und exkommuniziert mich. :-) Du weißt glaub ich auch nicht, zwischen welcher Stimmungslage Du Dich entscheiden sollst: Künstlich belustigt oder empört... Deine langatmigen Rechtfertigungstiraden werden von Deinem Versagen bei einem einfachen C-Programm jedenfalls kaum ablenken. Du solltest Dich mit Deiner Geschichte in einem eigenen Thread über den bösen Moby und seine schlimmen Machenschaften auskotzen ;-) P. M. schrieb: > Wer hier immer noch > sachliche Argumente fordert, der ist schon länger fehl am Platz. Ja, die vermisse ich... Und sie kommen einfach nicht ;-) Erwartet hab ich sie ehrlicherweise nach den Erfahrungen meines Projektthreads aber auch nicht. Robert L. schrieb: > wie kann denn sowas passieren? Tja sowas aber auch... Software ist schon was eigenartiges. Nun ja, daß die Verwendung von Asm vor weniger effektiver Programmierung schützt hat auch niemand behauptet. Ist halt auch keine in den Mund fliegende gebratene Taube. Aber Asm macht den saftigen effizienten Braten erst möglich ;-) Jörg W. schrieb: > Sagt halt nur nicht viel mehr aus, als dass es ein paar hier gibt, > die ihm schätzungsweise aufgrund seines Namens immer eine negative > Bewertung geben. Selbst für sowas bekommt er einen Haufen Minuspunkte: Leute, wer hier Minuspunkte ernst nimmt dem ist nicht mehr zu helfen. Minuspunkte sind das was man vergibt wenn einem keine sachlichen Argumente mehr einfallen. Die sind dann quasi zu einem Mittel unlauterer Kriegsführung verkommen ;-)
Markus M. schrieb: > Moby ist froh, dass es so eine einfache Sprache wie ASM gibt, weil er > für Hochsprachen unzugänglich und unfähig ist, sie zu erlernen. Nö, bin ich nicht. Aber im Hinterkopf ist da so ein lästiger Gedanke: Muß das jetzt wirklich so umständlich und ineffizient programmiert werden oder gehts doch einfacher? > welchen Hochgefühl den Moby ereilen würde Das hab ich schon, wenn ich sehe was selbst so ein kleiner Tiny in Asm zu leisten imstande ist! > sehen würde, was der > Prozessor wirklich drauf hat Glaub mir, daß seh ich mit meinem direkten Blick auf die Hardware am allerbesten ;-) > ihn zu unglaublich > komplexen Dingen zu bewegen Ich weiß nicht was Du Dir darunter so vorstellst aber ich vermute, dafür langt dann kein AVR mehr.
:
Bearbeitet durch User
Carl D. schrieb: > Für einen, der nur andere vorführen will, läßt sich M. aber leicht auf's > Glatteis locken und bricht aus regelmäßig ein. Einbildung ist auch 'ne Bildung, Carl D. Jörg W. schrieb: > Das wiederum brauchst du nicht erst mit Zahlenakrobatik zu belegen, > das war vermutlich selbst Moby auch so schon klar (er interpretiert > das Ergebnis nur als Überlegenheit denn als Niederlage). Hier gehts nicht um Sieg oder Niederlage oder wie was zu interpretieren ist. Mein Projektbeispiel belegt die Effizienz von Asm. Bis heute kam kein Gegenbeweis und er wird auch nicht kommen. Viel einfacher ist es doch, wenn sich die großen Experten hier in Hohn und Spott flüchten und sich darin gegenseitig bestärken. Eine eindrucksvolle Show soll das wohl sein- nur bin ich eher selber belustigt denn beeindruckt ;-)
Moby A. schrieb: > Mein Projektbeispiel belegt die Effizienz von Asm. Bis heute kam > kein Gegenbeweis und er wird auch nicht kommen. Das ist zweimal gelogen. Es wurde nämlich gezeigt, dass man dein Zeug auch effizient in C umsetzen kann. Dass du kaum von deinem Standpunkt abzubringen bist und ihn gleichzeitig kaum belegen kannst, das ist die eine Sache. Dass du jetzt aber noch direkt zum Lügen übergehst, das ist eine andere.
Moby A. schrieb: > Frank M. schrieb: >> Bei 1KB ist schon Ende der Fahnenstange mit ASM. > > Da ist noch laaaange kein Ende ;-) > Asm-Code selbst jenseits 10K gibts genug. Im Gegensatz zu Dir habe ich und einige andere hier bereits Asm-Programme > 10k geschrieben. Und wir wissen auch noch sehr genau, welche Probleme dann bei der Handoptimierung auftreten. Und im Gegensatz zu Dir beherrschen wir zusätzlich zum vollständigen Asm-Instructionset auch C/C++ und können die Vorteile bei Ressourcenverbrauch/Performance und Entwicklungszeit bei größeren Programmen sehr gut einschätzen. Und zu guter letzt kennen viele hier nicht nur AVR, sondern haben schon viele andere Architekturen programmiert und wissen es zu schätzen, wenn beim Umstieg z.B. von einem 68HC11 auf einen AVR nicht der komplette Code neugeschrieben werden muß. Stefan
P. M. schrieb: > Das ist zweimal gelogen. Es wurde nämlich gezeigt, dass man dein Zeug > auch effizient in C umsetzen kann. Unwahrheiten kannte ich bislang nur von der Gegenseite. Auch Du machst mit dieser Behauptung gerade keine Ausnahme. Es sei denn, Du zeigst mir gleich den funktionskompatiblen C-Code zu meinem Tiny13 Projekt... > Dass du kaum von deinem Standpunkt abzubringen bist Die Hoffnung hab ich doch umgekehrt auch nicht. Zuweilen lernt und erfährt man aber was Neues- und sei es nur über die vielfältigsten Psychospielchen hier ;-)
Moby A. schrieb: > Zuweilen lernt und erfährt man aber was Neues- und sei es nur über die > vielfältigsten Psychospielchen hier ;-) Bzgl. "Psychospielchen" kann dir hier eh niemend das Wasser reichen.
P. M. schrieb: > Das ist zweimal gelogen. Also ich kann ja verstehen, daß manche Leute hier mangels anderer Argumente nun alle Register ziehen. Von Lügen zu sprechen ist aber eine ziemlich freche, dreiste, verlogene Veranstaltung- passt aber ins Bild manch anderer Unterstellungen. Was solls. An den Effizienz-Vorteilen, die der Asm-Programmierer ohne große Bürokratie genießen kann ändert das auch nix ;-)
Moby A. schrieb: > P. M. schrieb: >> Das ist zweimal gelogen. > > Also ich kann ja verstehen, daß manche Leute hier mangels anderer > Argumente nun alle Register ziehen. > Von Lügen zu sprechen ist aber eine ziemlich freche, dreiste, verlogene > Veranstaltung- passt aber ins Bild manch anderer Unterstellungen. Also: - Deine Beiträge kriegen durchs Band mindestens 3-5 Downvotes. - Niemand unterstützt deine Behautungen. Moby, wie kannst du da weiterhin so tun, als hätten wir mehr oder weniger eine Aussage-gegen-Aussage-Situation?
Moby A. schrieb: > Also ich kann ja verstehen, daß manche Leute hier mangels anderer > Argumente nun alle Register ziehen. Du hast bis heute nicht zeigen können, dass ein 1KB-Assembler-Programm ressourcen-schonender und effizienter als ein C-Programm ist. Für 200 Byte Mini-Progrämmchen gestehe ich Dir das ja zu. Aber dann ist Ende. Wo sind Deine Projekte, die größer als lächerliche 200 Byte sind? Es gibt sie nicht. Über das Dreirad-Alter sind die meisten hier hinaus. Du hast Dich wahrscheinlich auf einem Dreirädchen festgeklebt.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Es gibt sie nicht. Das würde ich ihm nicht unterstellen. Er will sie uns aber nicht zeigen. Er wird schon wissen, warum.
Jörg W. schrieb: > Er will sie uns aber nicht zeigen. Tja, warum nur? > Er wird schon wissen, warum. Eben. Und ich weiß auch, warum.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Aber im Hinterkopf ist da so ein lästiger Gedanke: > Muß das jetzt wirklich so umständlich und ineffizient programmiert > werden oder gehts doch einfacher? Ja, deswegen mach ich das ja in C und nicht ASM > Das hab ich schon, wenn ich sehe was selbst so ein kleiner Tiny in Asm > zu leisten imstande ist! Du wärst nicht minder erstaunt was der leisten kann wenn Du die gleiche Krücke in C programmierst. Z80 mit 2,5Mhz ist lange her, komm mal drüber weg. https://de.wikipedia.org/wiki/Atmel_AVR >>Durch das auf Hochsprachen wie C ausgelegte Hardware-Design können >>auch Compiler sehr effizienten Code erzeugen Anstatt die Bemühungen von Atmel entsprechend zu würdigen setzt Du den AVR nicht bestimungsgemäß ein und wurstelst da weiterhin mit ASM drin rum. Solltest Du jemals Deine Hemmungen überwinden und C eine echte Chance geben würdest Du wahrscheinlich nie wieder ASM coden wollen. Deine Argumentation wäre dann wohl 'C ist viel besser als [alles andere}' Genauso kompromisslos, genauso engstirnig und genauso falsch. Wir hätten nichts gewonnen, nur das Thread Thema würde sich geringfügig verändern. So, Kaffee ist alle.
P. M. schrieb: > - Deine Beiträge kriegen durchs Band mindestens 3-5 Downvotes. Oh, welch Kriterium ... BIG DISLIKE, sach ich mal.
Stefan K. schrieb: > Im Gegensatz zu Dir habe ich und einige andere hier bereits > Asm-Programme > 10k geschrieben. Wie sich manche Leute gewisser Gegensätze so sicher sein können ;-) Also solltest Du nicht täglich in Asm programmieren behaupte ich jetzt einfach mal, daß Du meinen Codeumfang übers letzte Jahrzehnt so schnell nicht toppst. > Und wir wissen auch noch sehr genau, > welche Probleme dann bei der Handoptimierung auftreten. Wir wissen ganz genau, daß die handoptimierte Anpassung gerade die Effizienz von Asm begründet. So man seine Bausteine entsprechend optimiert zur Verfügung hat = Vorbereitung läuft es oft, über spezifizierte Register-Schnittstellen = System nur aufs gekonnte Zusammenstöpseln = Übung dieser Bausteine hinaus- deshalb ist es auch Unsinn, daß die Komplexität über die Codesize über alle Maßen anwachsen muß. Wenn Du z.B. einen Baustein für UART-Empfangen und Senden hast, ist die Anzahl der genutzten UART-Schnittstellen letztlich wurscht. > Und im Gegensatz > zu Dir beherrschen wir zusätzlich zum vollständigen Asm-Instructionset > auch C/C++ und können die Vorteile bei Ressourcenverbrauch/Performance > und Entwicklungszeit bei größeren Programmen sehr gut einschätzen. Ja ja, bla bla. Den Asm-Vorteil kann ich gut einschätzen- da brauchts auch keine tägliche C/C++ Praxis. Das warum hab ich weiter oben schon mal begründet > Und zu guter letzt kennen viele hier nicht nur AVR, sondern haben schon > viele andere Architekturen programmiert und wissen es zu schätzen, wenn > beim Umstieg z.B. von einem 68HC11 auf einen AVR nicht der komplette > Code neugeschrieben werden muß. Zu guter Letzt benötigt die Beherrschung von Asm auf AVR für typische 8-Bit MSR Aufgaben kein Umherspringen zwischen verschiedenen Architekturen. Mein bescheidenes Hobbyisten-Beileid all jenen, die das aus unterschiedlichsten beruflichen Gründen doch tun müssen.
Also ich hab mal meine AVR-Projekte durchgeblättert und würd gerne von Moby lernen, warum ich mit C eine falsche Entscheidung getroffen habe und warum Assembler hier "ganz klar überlegen" ist. Alle meine AVR-Projekte sind Hobby; ich verwende AVRs von 2KiB bis 16KiB Flash (z.B. ATtiny25, ATtiny2313, ATmega168). Fast keines der Projekte erfüllt die Moby-Bedingung "8-Bit MSR ohne viele Daten und ohne viel Arithmetik"... Nur 2 der Projekte kommen überhaupt in den Dunstkreis des Moby-kriteriums: Projekt 1: PWM-Steller für Ohm'sche Last (ATtiny25) Die Heizung einer Scope-Röhre (6.3V~, 85mA) soll betrieben werden an 9V= ungeregelt, und zwar so, dass die aufgenommene Leistung genauso groß ist wie im Datenblatt der Röhre angegeben, nämlich 6.3*85 mW. Nach dem Einschalten soll die Heizleistung innerhalb mehrerer Sekunden langsam angefahren werden. Ein nicht unwesentlicher Teil des Codes besteht aus der Initialisierung der Hardware wie dem Schreiben von Werte in SFRs. Beispiel
1 | // Initialize Timer0 to make PWM @ F_CPU/256 i.e. ~ 1kHz
|
2 | // Initialize Timer1 to make IRQs @ 125Hz i.e. every 8ms
|
3 | void timers_init (void) |
4 | {
|
5 | // Timer1 in CTC-Mode and prescaled 8
|
6 | TCCR1 = (1 << CTC1) | (1 << CS12); |
7 | |
8 | // PoutputCompare for desired Timer1 frequency
|
9 | OCR1C = (uint8_t) ((uint32_t) F_CPU / IRQS_PER_SECOND / PRESCALE -1); |
10 | OCR1B = 0; |
11 | ...
|
Hier ginge natürlich auch Assembler, aber der Vorteil von
1 | ;; Timer1 in CTC-Mode and prescaled 8 |
2 | LDI r18, (1 << CTC1) | (1 << CS12) |
3 | OUT TCCR1, r18 |
will mit nicht einleuchten. Daher lasse ich im folgenden solche Initialisierungen zur Kürze weg. Der eigentliche Code sieht so aus:
1 | // Ramp up PWM duty cycle
|
2 | bool startup = true; |
3 | |
4 | // Run CPU @ 250kHz (8MHz / 32)
|
5 | CLKPR = (1 << CLKPCE); |
6 | CLKPR = (1 << CLKPS2) | (1 << CLKPS0); |
7 | |
8 | // Initialize hardware
|
9 | ioinit (); |
10 | |
11 | // IRQs are welcome
|
12 | sei(); |
13 | |
14 | // main loop
|
15 | while (1) |
16 | {
|
17 | // Arithmetic mean over 2**PP ADC values
|
18 | const uint8_t PP = 4; |
19 | uint16_t adc = 0; |
20 | |
21 | for (uint8_t i = 0; i < (1 << PP); i++) |
22 | {
|
23 | // Start ADC single shot conversion
|
24 | ADCSRA = (1 << ADSC) | ADC_VAL; |
25 | |
26 | // Wait for ADC to complete
|
27 | while (!(ADCSRA & (1 << ADIF))) |
28 | ;
|
29 | |
30 | // Add the ADC value to adc totals
|
31 | adc += ADC; |
32 | }
|
33 | |
34 | // Divide adc totals by 2**PP to get arithmetik mean
|
35 | adc >>= PP; |
36 | |
37 | // The target's nominal voltage: this is why we are here...
|
38 | #define U_SOLL 6.3 // V
|
39 | |
40 | // These values describe the components on the PCB
|
41 | #define R_HI 35.7 // kOhm // high side resistor R1
|
42 | #define R_LO 9.9 // kOhm // low side resistor R4
|
43 | #define U_REF 5.0 // V // U_REF is Vcc and comes from IC2, an LM2936Z-5
|
44 | #define U_CE 0.75 // V // emitter-collector dropout of transistor T1
|
45 | |
46 | #define ADC_RESOLUTION 1024.0
|
47 | #define PWM_RESOLUTION 256.0
|
48 | |
49 | const int32_t K1 = PWM_RESOLUTION * ADC_RESOLUTION * U_SOLL; |
50 | const int32_t K2 = (R_HI+R_LO)/R_LO * U_REF; |
51 | const int32_t K3 = ADC_RESOLUTION * U_CE; |
52 | const uint32_t K4 = PWM_RESOLUTION; |
53 | |
54 | // Compute value for OCR as 32-bit value from adc
|
55 | int32_t ocr_32; |
56 | |
57 | // Be careful with such computations,
|
58 | // do not shorten out `PWM_RESOLUTION' etc and mind the conditioning!
|
59 | ocr_32 = K1 / (K2 * adc - K3); |
60 | ocr_32 = ocr_32 * ocr_32; |
61 | ocr_32 /= K4; |
62 | |
63 | // Trunk 32-bit ocr value to an 8-bit saturated value
|
64 | uint8_t ocr_8 = ocr_32; |
65 | |
66 | if (ocr_32 >= 256) ocr_8 = 255; |
67 | if (ocr_32 < 0) ocr_8 = 0; |
68 | |
69 | // Read actual OCR value
|
70 | uint8_t ocr = OCR0A; |
71 | |
72 | // Soft start the voltage: rise PWM duty slowly,
|
73 | // i.e. increment it just every 4*8 ms.
|
74 | // In startup *and* countdown timer run dry?
|
75 | if (startup && 0 == count_8ms) |
76 | {
|
77 | // Yes:
|
78 | if (ocr < ocr_8) |
79 | {
|
80 | // OCR did not yet reach desired level of `ocr_8':
|
81 | // increment OCR and refuel the 8 ms countdown timer
|
82 | count_8ms = 4; |
83 | ocr++; |
84 | }
|
85 | else
|
86 | // OCR reached the desired level: startup is over
|
87 | startup = 0; |
88 | }
|
89 | |
90 | // After startup?
|
91 | if (!startup) |
92 | {
|
93 | // Yes:
|
94 | // We react faster to a changing input voltage
|
95 | // Note: changing OCR is still slowed down by the ADC
|
96 | if (ocr > ocr_8) ocr--; |
97 | if (ocr < ocr_8) ocr++; |
98 | }
|
99 | |
100 | // Write the new OCR value
|
101 | // OCR will change by -1, 0 or 1
|
102 | OCR0A = ocr; |
103 | |
104 | // Done
|
105 | wdt_reset(); |
106 | } // main loop |
Das zu schreibende SFR ist OCR0A, und obwohl es nur ein 8-Bit Register
ist, wird zur Berechnung 32-Bit-Multiplikation und -Division benötigt.
Auch hier leuchtet mir nicht ein, warum Assembler überlegen sein soll.
Ausser dem Rumwuchten von 32-Bit Werten und Aufrufen der
Arithmetik-Routinen ist nicht viel zu tun.
@Moby: Warum wäre hier Assembler überlegen? Falls dir ein C-Konstrukt
unklar ist, wird es gerne erklärt.
Projekt 2: SMPS-Controller für einen Voltage-boosted Boost Converter
9V= zu -700V= (ATtiny25).
Im Gegensatz zu Projekt 1 implementiert dieses einfache Progamm einen
Regler (bang-bang). Nach der Initialisierung verweilt das Programm in
einer Endlosschleife; die Arbeit geschieht in einer ISR:1 | ...
|
2 | sleep_enable(); |
3 | set_sleep_mode (SLEEP_MODE_IDLE); |
4 | |
5 | sei(); |
6 | |
7 | while (1) |
8 | sleep_cpu(); |
9 | |
10 | SIGNAL (SIG_OVERFLOW1) |
11 | {
|
12 | if (ACSR & (1 << ACO)) |
13 | {
|
14 | // V_sense < V_BG: Output voltage < -600
|
15 | // Stop PWM, disconnect PortPWM from Timer1, PortPWM = LOW
|
16 | PORT_PWM &= ~(1 << BIT_PWM); |
17 | GTCCR = (1 << PWM1B); |
18 | PORT_LED &= ~(1 << BIT_LED); |
19 | }
|
20 | else
|
21 | {
|
22 | // V too low, i.e. V > -600:
|
23 | // Activate PWM, connect PortPWM to Timer1
|
24 | GTCCR = (1 << PWM1B) | (1 << COM1B0); |
25 | PORT_LED |= (1 << BIT_LED); |
26 | }
|
27 | |
28 | // Reset Watchdog-Timer
|
29 | wdt_reset(); |
30 | }
|
@Moby: Wo wäre in diesem Projekt der Vorteil von Assembler zu suchen? Anmerken möchte ich noch, dass ich des AVR-Assemblers durchaus mächtig bin, was z.B. unabdingbar ist um zu avr-gcc beizutragen.
Moby A. schrieb: > Den Asm-Vorteil kann ich gut einschätzen- da brauchts auch keine > tägliche C/C++ Praxis. „Ich kenne zwar nur eine Seite der Medaille, aber ich kann gut einschätzen, was auf der anderen drauf ist.“ Ja ja, bla bla – um deine Worte zu zitieren. Was machst du eigentlich, wenn Atmel den letzten AVR mal irgendwann abkündigt? Angeln gehen? Rennrad fahren?
:
Bearbeitet durch Moderator
P. M. schrieb: > Also: > - Deine Beiträge kriegen durchs Band mindestens 3-5 Downvotes. > - Niemand unterstützt deine Behautungen. Das wird doch nicht etwa die Begründung für Deine unwahren Behauptungen sein? Frank M. schrieb: > Über das Dreirad-Alter sind die meisten hier hinaus. Du hast Dich > wahrscheinlich auf einem Dreirädchen festgeklebt. Putzig, aber stimmt. Viele Problemstellungen sind schneller und gezielter mit dem Asm-Dreirad als dem großen C-Porsche erreicht ;-) Jörg W. schrieb: > Er will sie uns aber nicht zeigen. Er wird schon wissen, warum. Sicher weiß ich das. Freilich aus anderen Gründen als Du jetzt annimmst ;-) Michael K. schrieb: > Du wärst nicht minder erstaunt was der leisten kann wenn Du die gleiche > Krücke in C programmierst. Jedenfalls weniger als mit Asm. Mit C fehlts schneller an Flash, RAM und Speed. > Anstatt die Bemühungen von Atmel entsprechend zu würdigen setzt Du den > AVR nicht bestimungsgemäß ein Wird das jetzt verfolgt? ;-) > Solltest Du jemals Deine Hemmungen überwinden und C eine echte Chance > geben würdest Du wahrscheinlich nie wieder ASM coden wollen. Wahrscheinlich müsste ich mir das vorhalten lassen wenn ich tatsächlich noch nichts mit C programmiert hätte. Hätte, wohlgemerkt. > Genauso kompromisslos, genauso engstirnig und genauso falsch. Kompromisslos Asm. Richtig. Blick aufs Wesentliche: Nämlich das was zur Erfüllung einer Aufgabe im einfachsten Fall nötig ist. > So, Kaffee ist alle. So, schönen Tag noch allen redlichen und unredlichen Diskutanten.
>Hier ginge natürlich auch Assembler, aber der Vorteil von1 | ;; Timer1 in CTC-Mode and prescaled 8 |
2 | LDI r18, (1 << CTC1) | (1 << CS12) |
3 | OUT TCCR1, r18 |
>will mit nicht einleuchten.
Natürlich nicht. Der leuchtet erst ein, wenn Du alle Überlegenheiten von
ASM nutzt:
1 | ;; Timer1 in CTC-Mode and prescaled 8 |
2 | LDI r18, 41 ;; dezimal zur besseren Übersicht der Bits ;-) |
3 | OUT TCCR1, r18 |
Werner P. schrieb: > kann man das TCCR1 nicht auch irgendwie weg optimieren? Klar. Zum Editieren wars nur schon zuspät:
1 | ;; 41 in $39 schreiben |
2 | LDI r18, 41 |
3 | OUT $39, r18 |
Eindeutig überlegen. EDIT: Ich habe die Kommentare noch optimiert.
Werner P. schrieb: > jetzt stört eigentlich nur noch r18 Das ist doch alles viel zu kompliziert.
1 | 11100010001010011011111100101001
|
mfg.
Moby A. schrieb: >> Im Gegensatz zu Dir habe ich und einige andere hier bereits >> Asm-Programme > 10k geschrieben. > > Wie sich manche Leute gewisser Gegensätze so sicher sein können ;-) > Also solltest Du nicht täglich in Asm programmieren behaupte ich jetzt > einfach mal, daß Du meinen Codeumfang übers letzte Jahrzehnt so schnell > nicht toppst. Da darf ich Dir endlich mal aus vollem Herzen Recht geben. Ich bin unendlich glücklich, daß ich in den letzten 10 Jahren Asm fast ausschliesslich als Compiler-Output gesehen habe. Allerdings darfst Du auch sicher sein, daß mein geschriebener Asm-Codeumfang der letzten 3 Jahrzehnte um ein Vielfaches größer ist als Deiner. >> Und wir wissen auch noch sehr genau, >> welche Probleme dann bei der Handoptimierung auftreten. > > Wir wissen ganz genau, daß die handoptimierte Anpassung gerade die > Effizienz von Asm begründet. So man seine Bausteine entsprechend > optimiert zur Verfügung hat = Vorbereitung läuft es oft, über > spezifizierte Register-Schnittstellen = System nur aufs gekonnte > Zusammenstöpseln Und genau dieses System bringt bei großen Programmen gravierende Nachteile bzgl. Codesize und Effizienz. > Wenn Du z.B. einen Baustein für UART-Empfangen und Senden hast, ist > die Anzahl der genutzten UART-Schnittstellen letztlich wurscht. ... weil Du sie für jeden UART mit neuen Registeradressen kopierst. In C schreibst Du die Funktion einmal und übergibst bei Bedarf den Ptr auf die UART-Register. Wenn Du 5 UARTs im System brauchst, dann ist in C die Funktion nur 1* im Flash, und nicht 5 fast identische Asm-Kopien. >> Und im Gegensatz >> zu Dir beherrschen wir zusätzlich zum vollständigen Asm-Instructionset >> auch C/C++ und können die Vorteile bei Ressourcenverbrauch/Performance >> und Entwicklungszeit bei größeren Programmen sehr gut einschätzen. > > Ja ja, bla bla. Den Asm-Vorteil kann ich gut einschätzen- da brauchts > auch keine tägliche C/C++ Praxis. Das warum hab ich weiter oben schon > mal begründet Das blabla kannst Du Dir gerne im Spiegel sagen. Eben den kannst Du nicht einschätzen, da Du weder C/C++ kennst und zumindest bis vor Kurzem noch nicht einmal den kompletten AVR-Befehssatz benutzen konntest. >> Und zu guter letzt kennen viele hier nicht nur AVR, sondern haben schon >> viele andere Architekturen programmiert und wissen es zu schätzen, wenn >> beim Umstieg z.B. von einem 68HC11 auf einen AVR nicht der komplette >> Code neugeschrieben werden muß. > > Zu guter Letzt benötigt die Beherrschung von Asm auf AVR für typische > 8-Bit MSR Aufgaben kein Umherspringen zwischen verschiedenen > Architekturen. Mein bescheidenes Hobbyisten-Beileid all jenen, die das > aus unterschiedlichsten beruflichen Gründen doch tun müssen. ATmega ist in der End-of-live-Phase, der Preis geht eher wieder hoch, es sind mittlerweile viel performantere 32-Bitter für deutlich weniger Geld zu bekommen. Von den Chips, die ich (in Asm) programmiert habe, ist die Mehrzahl nicht mehr erhältlich. Ich nehme mal an, daß dieses Schicksal Dich beim Atmega in den nächsten 10 Jahren nicht ereilt. Trotzdem hat es wenig mit Effizienz und Sparsamkeit zu tun, für einen Uralt-Chip mehr zu zahlen als für die performantere Nachfolger-Generation. Stefan
Moby A. schrieb: >> Über das Dreirad-Alter sind die meisten hier hinaus. Du hast Dich >> wahrscheinlich auf einem Dreirädchen festgeklebt. > > Putzig, aber stimmt. Viele Problemstellungen sind schneller und > gezielter mit dem Asm-Dreirad als dem großen C-Porsche erreicht ;-) Klar, wenn die Aufgabe nur darin besteht, im Kindergarten einmal um die große Linde zu kurbeln, dann fragt man sich schon, warum man sich die Mühe mit dem Auto fahren lernen machen soll. >> Solltest Du jemals Deine Hemmungen überwinden und C eine echte Chance >> geben würdest Du wahrscheinlich nie wieder ASM coden wollen. > > Wahrscheinlich müsste ich mir das vorhalten lassen wenn ich tatsächlich > noch nichts mit C programmiert hätte. Hätte, wohlgemerkt. Nicht einsteigen. Motor starten. Motor abwürgen. "So ein Scheiss, ich will mein Dreirad wieder". Das ist kein Lernen, das ist Vorurteile festigen.
:
Bearbeitet durch User
Werner P. schrieb: > Matthias L. schrieb: >> LDI r18, 41 > > jetzt stört eigentlich nur noch r18 Das haben wir gleich ;-)
1 | LDI $12, 41 |
2 | OUT $39, $12 |
Absolut Mobyoptimal, klar, selbsterklärend, und nicht durch den globigen C-Compiler völig aufgebläht und langsam. Das sind eindeutig Vorteile von ASM!
:
Bearbeitet durch User
Moby A. schrieb: > Sheeva P. schrieb: >> Wie lustig, da kann einer seine Niederlage und sein eigenes mieses >> Verhalten nicht ertragen und exkommuniziert mich. :-) > > Du weißt glaub ich auch nicht, zwischen welcher Stimmungslage Du Dich > entscheiden sollst: Künstlich belustigt oder empört... > > Deine langatmigen Rechtfertigungstiraden werden von Deinem Versagen bei > einem einfachen C-Programm jedenfalls kaum ablenken. > > Du solltest Dich mit Deiner Geschichte in einem eigenen Thread über den > bösen Moby und seine schlimmen Machenschaften auskotzen ;-) Und schwupps, bin ich wieder ex-exkommuniziert. Und zwar haargenau so, wie es Thomas weise vorhergesagt hatte. Herrlich! :-))
Moby A. schrieb: > Wir wissen ganz genau, daß die handoptimierte Anpassung gerade die > Effizienz von Asm begründet. So man seine Bausteine entsprechend > optimiert zur Verfügung hat = Vorbereitung läuft es oft, über > spezifizierte Register-Schnittstellen = System nur aufs gekonnte > Zusammenstöpseln = Übung dieser Bausteine hinaus- deshalb ist es auch > Unsinn, daß die Komplexität über die Codesize über alle Maßen anwachsen > muß. Wenn Du z.B. einen Baustein für UART-Empfangen und Senden hast, ist > die Anzahl der genutzten UART-Schnittstellen letztlich wurscht. Zusammengefasst: Du schreibst einen ASM Block und kopierst den so oft wie Du den brauchst. Der C Compiler würde jetzt erkennen ob er was wieder benutzen kann oder alles inline macht. Er würde auch je nach Optimierungseinstellung auf Speed oder auf Größe optimieren und zwar innerhalb von Sekunden je nachdem was du gerade möchtest. Kannst Du das unabhängig von der Codegröße auch ? Du sagst zum einen das ASM viel schneller zu lernen ist als C, was m.E. nicht stimmt, und zum anderen sagst Du das ASM nur bei jahrelanger Vorbereitung, also dem Vorhandensein handoptimierter Codeblöcke für unterschiedlichste Aufgaben, seinen Geschwindigeitsvorteil ausspielen kann. Den wiederum willst Du ausspielen indem Du stumpf Blöcke zusammenstöpselst, also etwas tust das Du C vorwirfst. Hab ich das in etwa richtig verstanden ? Moby A. schrieb: > Zu guter Letzt benötigt die Beherrschung von Asm auf AVR für typische > 8-Bit MSR Aufgaben kein Umherspringen zwischen verschiedenen > Architekturen. Genau, solange man bei AVR bleibt muß man nicht zwischen den Architekturen herumspringen. Ja, und Nachts ist es kälter als draussen. > Mein bescheidenes Hobbyisten-Beileid all jenen, die das > aus unterschiedlichsten beruflichen Gründen doch tun müssen. Nicht doch, ist dank C ja kein Problem. Würde mich viel mehr nerven wenn ich bei der immer gleichen beschränkten Krücke bleiben müsste nur weil ich alles neu lernen müsste bei einem Wechsel. > typische 8-Bit MSR Aufgaben Bedeutungen für 'typisch': [1a] einen bestimmten allgemeinen Typ verkörpernd [1b] für einen bestimmten Typ charakteristisch [2] veraltet: als Muster/Vorbild geltend Wenn Du von typischen 8bit MSR Aufgaben sprichst, aber alles was der Rest der Welt als typisch erachtet nicht gelten läßt, welche neue Definition des Wortes 'typisch' setzt Du dann an ? Interessanterweise wird es immer da 'untypisch' wo C gegenüber ASM klare Vorteile hat, auch auf 8bit.
Moby A. schrieb: > Ja ja, bla bla. Den Asm-Vorteil kann ich gut einschätzen- da brauchts > auch keine tägliche C/C++ Praxis. Bla bla. Um die Vor- und Nachteile von zwei oder mehr verschiedenen Optionen einschätzen zu können, muß man sie ausreichend gut kennen um sich ein Urteil bilden zu können. Genau das ist bei Dir aber nicht der Fall, und deswegen kaprizierst Du Dich auf einen winzigen Ausschnitt der Realität, der für die meisten anderen hier vollkommen unerheblich ist, aber leider übersteigt das Deinen Horizont genauso wie C und Assembler. :-)
Moby A. schrieb: > Markus M. schrieb: >> Moby ist froh, dass es so eine einfache Sprache wie ASM gibt, weil er >> für Hochsprachen unzugänglich und unfähig ist, sie zu erlernen. > > Nö, bin ich nicht. Aber im Hinterkopf ist da so ein lästiger Gedanke: > Muß das jetzt wirklich so umständlich und ineffizient programmiert > werden oder gehts doch einfacher? Genau das hatte ich auch im Hinterkopf, als ich von ASM kommend C zu lernen begonnen habe und inzwischen froh bin, meinen eigenen Schweinehund überwunden zu haben. Moby, du kannst hier gar nicht mitreden. Schau dir mal ASM Projekte von Bernhard S. an (ja, der mit den UKW-RDS Gedöns;-) Dieser Mann beherrscht ASM, liefert komplexe Sachen ab, bereichtert die Gemeinde mit guten Projekten. DU prahlst mit deinen 200Byte Gefrickel was von Überlegenheit. Was sollte der Bernhard dann sagen? Nein, er macht sich nicht lächerlich, weil er programmieren kann. Moby A. schrieb: > Zu guter Letzt benötigt die Beherrschung von Asm auf AVR für typische > 8-Bit MSR Aufgaben kein Umherspringen zwischen verschiedenen > Architekturen. Verstehe diese Wortanhäufung nicht. Moby A. schrieb: > Ja ja, bla bla. Den Asm-Vorteil kann ich gut einschätzen- da brauchts > auch keine tägliche C/C++ Praxis. Das warum hab ich weiter oben schon > mal begründet Als Programmierer sollte man doch eigentlich logisch denken können... Moby A. schrieb: > Michael K. schrieb: >> Du wärst nicht minder erstaunt was der leisten kann wenn Du die gleiche >> Krücke in C programmierst. > > Jedenfalls weniger als mit Asm. Mit C fehlts schneller an Flash, RAM und > Speed. Das sagt einer, der noch nie eine Zeile C geschrieben hat. Aussagewert = ??? Lächerlich, einfach nur lächerlich. Und ich behaupte jetzt, dass auch alle deine 200Byte Projektchen in C effektiver zu programmieren sind.
:
Bearbeitet durch User
Michael K. schrieb: > Zusammengefasst: > Du schreibst einen ASM Block und kopierst den so oft wie Du den > brauchst. > Der C Compiler würde jetzt erkennen ob er was wieder benutzen kann oder > alles inline macht. Er würde auch je nach Optimierungseinstellung auf > Speed oder auf Größe optimieren und zwar innerhalb von Sekunden je > nachdem was du gerade möchtest. > Kannst Du das unabhängig von der Codegröße auch ? Das kann er nicht, das versteht er nicht, das will er nicht. Moby hat seine eigene Definition von 'optimal'.
Jörg W. schrieb: > Moby A. schrieb: >> Den Asm-Vorteil kann ich gut einschätzen- da brauchts auch keine >> tägliche C/C++ Praxis. > > „Ich kenne zwar nur eine Seite der Medaille, aber ich kann gut > einschätzen, was auf der anderen drauf ist.“ > > Ja ja, bla bla – um deine Worte zu zitieren. ;-) > Was machst du eigentlich, wenn Atmel den letzten AVR mal irgendwann > abkündigt? Angeln gehen? Rennrad fahren? Den armen Anglern erzählt er dann, wie verschwenderisch das Angeln mit Rute und Rolle ist, wo doch -- mit "Übung, Vorbereitung, System", was außer ihm natürlich niemand hat -- Stock und Zwirn reichen. Und die armen Radfahrer müssen sich dann anhören, wie blöd diese Fahrräder mit Gangschaltung sind, weil er damit mal auf die Nase gefallen ist! ;-)
Markus M. schrieb: > Und ich behaupte jetzt, dass auch alle deine 200Byte Projektchen in C > effektiver zu programmieren sind. Das ist leicht. Gibt ja nur eins. Oh, halt ... leider ohne Spec. also nix wert.
Ralf G. schrieb: > Moby hat seine eigene Definition von 'optimal'. Nicht nur das. Die ist vor allem sehr dynamisch. mfg.
Moby A. schrieb: > Den Asm-Vorteil kann ich gut einschätzen- da brauchts auch keine > tägliche C/C++ Praxis. CP Rn,Rn BRNE $-2 > Moby hat seine eigene Definition von 'optimal'. Das ist nur die böse, in C++ geschriebene Rechtschreibhilfe. Eigentlich sollte es mobtimal heißen.
:
Bearbeitet durch User
Johann L. schrieb: > Ein nicht unwesentlicher Teil des Codes besteht aus der Initialisierung Darin könnte ein Grund liegen, warum in diesem Fall Asm nicht viel rausholt. Auch das zweite Progrämmchen ist viel zu kurz dafür. Das sind allerdings nur grobe Vermutungen. Genauso wie ich glaube: Das eine oder andere Byte'chen wird man dennoch aus dem Flash und dem SRAM (!) erübrigen können. Nutz doch die Zeit besser, um das bischen Funktionalität meines Projekts zu codieren. Das kann ich sofort vergleichen... Frank M. schrieb: > Moby A. schrieb: >> Da ist noch laaaange kein Ende ;-) > > Nur eine Behauptung. Du meine Güte, sitze gerade an einem Projektchen welches wieder mal die 1K Grenze gesprengt hat- was ist das bloß für ein Unsinn, die sinnvolle Möglichkeit dessen in Frage zu stellen ;-( Wenn hier schon niemand fähig ist, einen 200 Byte Code ein für alle Mal vergleichbar und Diskussions-beendend in C zu schreiben, was werde ich dann erst bei einem fünfmal so großen Projekt erwarten dürfen? Da werden dann schlußendlich wieder nur "Experten" sein, die ihr Expertentum in erster Linie mit Lächerlichmachen, Hohn und Spott beweisen ;-)
Markus M. schrieb: > DU prahlst mit deinen 200Byte Gefrickel was von > Überlegenheit. Hier prahlt niemand, sondern da zeigt jemand die Schwächen von C auf. ;-) > Verstehe diese Wortanhäufung nicht. Ich verstehe die Notwendigkeit häufiger Architekturwechsel auch nicht ;-) > Und ich behaupte jetzt, dass auch alle deine 200Byte Projektchen in C > effektiver zu programmieren sind. Na ja, ich kann warten. Hoffentlich warte ich nicht umsonst ;-)
Was genau willst du eigentlich? Die Frage ist Ernst gemeint (also kein ;-) )! Ich persönlich mag C ja auch nicht (überhaupt nicht). Schreibe normalerweise in Pascal. (hab C64, Amiga500 und 80x86 in ASM Programmiert.. aber nur "Kinderkram",..) Grundsätzlich wäre ich der ERSTE der lieber nicht in C schreiben würde.. Aber man nimmt dann eben das geringste übel.. Mich konntest bisher noch nicht davon überzeugen dass ich irgend eine Vorteil durch ASM am AVR hätte. Vorallem nicht ASM-Only.. Du bist also zumindest mal ein schlechter "Lehrer"/Verkäufer.. Ich Persönlich glaub aber auch, dass es hier garnicht um ASM vs. C oder ASM vs. Hochsprache. geht. Sondern um "Code von anderen Wiederverwenden" vs. alles "Selber schreiben wollen"..
:
Bearbeitet durch User
Moby A. schrieb: > Du meine Güte, sitze gerade an einem Projektchen welches wieder mal die > 1K Grenze gesprengt hat- was ist das bloß für ein Unsinn, die sinnvolle > Möglichkeit dessen in Frage zu stellen ;-( Natürlich glaube ich, dass Du ASM-Code von 1KB Größe zusammentackern kannst. Aber wie kommst Du auf den abstrusen Gedanken, ein adäquates C-Programm wäre hier schlechter? Du hast weder ein entsprechendes C-Programm vorzuweisen noch kannst Du in C programmieren. Ich nenne das anmaßend. Nur Behauptungen, nichts dahinter.
Frank M. schrieb: > Nur Behauptungen, nichts dahinter. Das war schon vor 1248 Posts vorher der Fall. PS: Ist mir klar, dass dieser Post sinnlos ist, ich wollte nur unbedingt den 1250. Post hier schreiben. Zum Glück hat sich dadurch das Niveau nicht nenneswert geändert...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ist mir klar, dass dieser Post sinnlos ist, ich wollte nur unbedingt > den 1250. Post hier schreiben. Sieh lieber zu das du die Kiddis wieder zum schlafen bekommst, die haben schon wieder die Verdunkelungsvorhänge runter gerissen und politisieren laut nebendrann. Namaste
Lothar M. schrieb: > Zum Glück hat sich dadurch das Niveau > nicht nenneswert geändert... Nun ja, den Beitrag würde ich als vergleichsweise hoch einordnen.
Moby A. schrieb: > Hier prahlt niemand, sondern da zeigt jemand die Schwächen von C auf. Und baut genau diese oft kritisierten Schwächen in seinen Asm-Code ein. Diesen nennt er dann auch noch einen Leckerbissen. Da würde nicht einmal der Hund rangehen. Moby A. schrieb: > Na ja, ich kann warten. Hoffentlich warte ich nicht umsonst Du hast doch schon lange ein C-Programm bekommen. Auf ein weiteres wirst du ewig warten. mfg.
Moby A. schrieb: >> DU prahlst mit deinen 200Byte Gefrickel was von >> Überlegenheit. > Hier prahlt niemand, sondern da zeigt jemand die Schwächen von C auf. Die Schwäche von C ist also kein 200Byte ASM Programm toppen zu können das ganz ohne RAM auskommt ? (Lassen wir das mal als Hypothese so stehen) Also ist die Schwäche von C bei einer MCU die extra für Hochsprachen optimiert wurde diese dafür vorgesehenen Ressourcen auch tatsächlich zu benutzen ? Moby A. schrieb: >> Und ich behaupte jetzt, dass auch alle deine 200Byte Projektchen in C >> effektiver zu programmieren sind. > Na ja, ich kann warten. Hoffentlich warte ich nicht umsonst ;-) Ich denke schon. Sobald das C Konstrukt nur ein byte braucht das Dein ASM nicht braucht wirst Du das als Niederlage werten. Selbst wenn das C Programm in 50% der Zeit geschrieben ist und nichts und niemand je diese Ressourcen nutzen wird die Du frei lässt. Dann wirst Du behaupten das diese 'klare Überlegenheit' von ASM natürlich auch für Programme gilt die 1000 mal so groß sind. Selbst wenn das C Konstrukt in allen Belangen kleiner, schneller und sparsamer ist als Dein ASM wirst Du eine Argumentation finden das dieses ein 'untypischer' Sonderfall ist oder sinnloserweise irgendwelche Verrenkungen unternommen werden müssen nur weil Du das in ASM auch so machst, der C Compiler aber keinen Sinn darin sieht. Z.B. wirst Du argumentieren das ein hochoptimierender Keil / IAR o.ä. im Gegensatz zu ASM viel Geld kostet. Entweder das oder Du ignorierst einfach alles was da an Beweisen rüberkommt und machst an irgendeinem Nebenschauplatz weiter als wäre nichts gewesen. Mal nebenbei: Mir ist aus Deinen Threads klar geworden das Du eine Zermürbetaktik fährst. Es kommen so lange die gleichen Plattitüden bis endlich alle aufgegeben haben mit jemanden diskutieren zu wollen dem es vollauf reicht das letze Wort zu haben und dem nichts zu platt ist dafür. Es würde mich diebisch freuen wenn wir diesmal den längeren Atem beweisen und Du irgendwann einfach keine Lust mehr hast. Ehrlich gesagt reche ich uns da keine großen Chancen aus denn Du bist was das angeht wirklich so eine Art Gesamtkunstwerk. Einen Versuch ist es allemal wert. So, nur um den Wertbewerb 'meiste Smileys pro Thread' aufzunehmen: ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) Dir auch noch einen schönen Tag. Michael
Moby A. schrieb: > Du meine Güte, sitze gerade an einem Projektchen welches wieder mal die > 1K Grenze gesprengt hat- was ist das bloß für ein Unsinn, die sinnvolle > Möglichkeit dessen in Frage zu stellen ;-( Wow, welchen mc benutzt Du? Je nachdem sind also schon wertvolle 25% / 12% ... 3% Flash belegt. Höchste Zeit, sich dringend Gedanken um den nächsten Optimierungslevel zu machen. Wo ist überhaupt die Sammelstelle für all das unbenutzte Flash? Ich hätte auch noch ne ganze Menge davon abzugeben.
Glaubt eig. irgend jemand an diese ominösen "Projektchen"? Geschrieben von jemand, dessen einziges "Projektchen" das die Welt kennt aus 20 Zeilen Micky Maus besteht?
Stefan K. schrieb: > Wo ist überhaupt die Sammelstelle für all das unbenutzte Flash? Da werden ein paar Ready-To-Use Ethernetmodule angeflanscht. Dann kann er das als Home-Cloud benutzen, um weniger Resourcen auf der Festplatte in seinem PC zu verschwenden. mfg.
Gu. F. schrieb: > Glaubt eig. irgend jemand an diese ominösen "Projektchen"? Warum nicht? Er hat uns doch weiter oben erklärt, wie das abläuft: sowie irgendwas seine Möglichkeiten übersteigt (wie eben eine IP-Anbindung), wird das dazugekauft. Ansonsten muss man doch nur hinreichend viel Masochismus mitbringen, um größere Mengen Assemblercode zusammenzuhacken. Dass dieser dann noch „optimal“ ist, das glaubt allerdings wirklich nur Moby selbst.
Jörg W. schrieb: > Warum nicht? Er hat uns doch weiter oben erklärt, wie das abläuft: > sowie irgendwas seine Möglichkeiten übersteigt (wie eben eine > IP-Anbindung), wird das dazugekauft. Auch diese hat noch keiner gesehen. Nur Behauptungen.
Gu. F. schrieb: > Auch diese hat noch keiner gesehen. Dich hat hier auch noch keiner gesehen, trotzdem existierst du offensichtlich.
Jörg W. schrieb: > Gu. F. schrieb: >> Auch diese hat noch keiner gesehen. > > Dich hat hier auch noch keiner gesehen, trotzdem existierst du > offensichtlich. Was willst du mir denn damit sagen? Ich reise hier nicht die Klappe auf und gebe seit 1200 Beiträgen mit meinen tollen >10k ASM Projektchen an. Das tut nur Moby. Also ist er in der Pflicht das auch zu belegen sonst ist er unglaubwürdig. Ich muss nix beweisen.
:
Bearbeitet durch User
Gu. F. schrieb: > Was willst du mir denn damit sagen? Dass du nicht jedes seiner Worte anzweifeln musst. „in dubio pro reo“ darfst du auch gelten lassen, wenn du dein Gegenüber nicht sonderlich leiden kannst.
Moby A. schrieb: > Manches ist jedenfalls trivialer als man denkt ;-) Ich weiss sowieso nicht, wie man auf den absurden Gedanken kommen kann, der (sehr repetitive) Prozess der Compilierung/Assemblierung auf unterster Ebene könne von einem Menschen effizienter durchgeführt werden als von einem Computerprogramm. Vermutlich liegt es daran, dass Moby mit seinem beschränkten Horizont diese Aufgabe als kreativ ansieht, während wir wissen, dass es rein mechanistisch ist.
P. M. schrieb: > Ich weiss sowieso nicht, wie man auf den absurden Gedanken kommen kann, > der (sehr repetitive) Prozess der Compilierung/Assemblierung auf > unterster Ebene könne von einem Menschen effizienter durchgeführt werden > als von einem Computerprogramm. Den Output seiner Werkzeuge zu hinterfragen ist prinzipiell ja kein schlechter Gedanke. Ich kann mich erinnern, wie ich das erste Mal das Compiler-Ergebnis für den externen Speicherzugriff eines 8051 gesehen habe. Das war unendlich umständlich und hat sich vor allem für jedes externe Byte wiederholt. Der gcc für AVR ist aber mittlerweile eine ganz andere Liga, dem macht man händisch kaum noch was vor, vor allem bei komplexeren Strukturen. Was nicht zuletzt an dem für C optimierten Hardwaredesign liegt. Gruß, Stefan
P. M. schrieb: > Vermutlich liegt es daran, dass Moby mit seinem beschränkten Horizont > diese Aufgabe als kreativ ansieht, während wir wissen, dass es rein > mechanistisch ist. Vielleicht ist ja mit Deinem Horizont ja was nicht in Ordnung ;-) Frank M. schrieb: > Aber wie kommst Du auf den abstrusen Gedanken, ein adäquates > C-Programm wäre hier schlechter? Du hast weder ein entsprechendes > C-Programm vorzuweisen Wie kommst Du auf den abstrusen Gedanken daß ich ein C-Programm vorweisen müsste? Wenn, dann kommt hier mal von mir ein optimiertes 1K Asm Programm... Doch wofür? Was dann von C-Seite folgt würde wieder nur gähnende Leere sein. Die Reaktionen kann ich hier schon jetzt wunderbar studieren.
Stefan K. schrieb: > Der gcc für AVR ist aber mittlerweile eine ganz andere Liga, dem macht > man händisch kaum noch was vor Köstlich. Das küre ich schon jetzt zum Witz des Tages und empfehle Dir, mal ein paar Problemthreads zum gcc durchzugehen und Dich an dessen Beschränktheiten zu laben. Besser soll ja der IAR sein- für ne Stange Geld natürlich.
Moby A. schrieb: > Vielleicht ist ja mit Deinem Horizont ja was nicht in Ordnung ;-) Erfahrung in 10 Jahren Hobby/Studium/Beruf: Sehr viel C, viel C++, AVR-Assembler, MIPS-Assembler, VHDL, Softwareentwicklung für Supercomputer, Skriptsprachen fürs Web. Und du? Ein paar Hobby-Projekte in Assembler, Ende der Fahnenstange. Moby A. schrieb: > Wie kommst Du auf den abstrusen Gedanken daß ich ein C-Programm > vorweisen müsste? Weil DU derjenige bist, der eine Minderheiten-Meinung vertritt. Wer etwas behauptet, das vom grössten Teil der Diskussionsteilnehmer abgelehnt wird, der hat nunmal die Beweislast, ob er will oder nicht. Wenn du auch nur ein kleines Interesse daran hättest, die Diskussion für dich zu entscheiden, dann hättest du den Beweis schon lange angetreten.
>optimiertes 1K Asm Programm hat du aber keines.. beantworte doch mal die Frage: Beitrag "Re: Assembler wieder auf dem Weg nach vorn" anstelle immer wieder das selbe zu wiederholen..
:
Bearbeitet durch User
P. M. schrieb: > Und du? Ein paar Hobby-Projekte > in Assembler, Ende der Fahnenstange. Die muß nicht da zu Ende sein wo Du meinst. Deine Auflistung von Erfahrungen interessiert hier & mich wenig. Deine Mittel mich zu "überzeugen" waren bislang ziemlich arg auf diverse unredliche Psychospielchen begrenzt. Du hättest besser Psychologe werden sollen, wobei es mir dann um die armen Patienten leid täte ;-)
Moby A. schrieb: > Deine Auflistung von Erfahrungen interessiert hier & mich wenig. Siehst Du. Und Deine Definition von Effizienz (Ram/Flash-Verbrauch) interessiert ausser Dir eben "hier & alle wenig" bis garnicht. Auch wenn Du es weiter ignorierst: Wir verstehen unter Effizienz zu grossen Teilen die Entwicklungszeit. Danach kommt RAM und Flash.
Moby A. schrieb: > Wie kommst Du auf den abstrusen Gedanken daß ich ein C-Programm > vorweisen müsste? Wie kommst du auf den abstrusen Gedanken, dass hier irgendjemand anders ein C-Programm vorweisen müsste? Du stellst eine Behauptung auf, dann wäre es an dir, den Beweis dafür zu liefern. Bis zu irgendeinem Beweis bleibt es einfach nur eine Behauptung.
Jörg W. schrieb: > Bis zu irgendeinem Beweis bleibt es einfach nur eine > Behauptung. Ach ... Schön das von dir zu hören. Könnte er doch im Geheimen alle seine Projektchen wirklich realisiert haben :-)
P. M. schrieb: > Ich weiss sowieso nicht, wie man auf den absurden Gedanken kommen kann, > der (sehr repetitive) Prozess der Compilierung/Assemblierung auf > unterster Ebene könne von einem Menschen effizienter durchgeführt werden > als von einem Computerprogramm. Auf das ging er natürlich wieder garned ein... Aber hier hat P.M. natürlich recht. Das Groß der Entwicklungszeit bei ASM geht ja nicht für Kreatives Arbeiten (welchen Algorithmus muss ich anwenden? Welche Rechenoperation muss ich durchführen?) drauf sondern für stumpfe Fleissarbeit (welche der mit der gegebenen Architektur verfügbaren Instruktionen muss ich auf welche Weise kombinieren, um eine 16-Bit-Signed Multiplikation durchzuführen. Da kann man noch so viel ÜVS (Übung/Vorbereitung/System) haben, das ÜVS des Comlilers wird immer besser sein, in einem Bruchteil der Zeit. Und mit jeder Codezeile die das Projekt wächst wird das ÜVS des Compilers übermächtiger, bis unser menschlicher Assembler irgendwann nur noch staunen kann, was da abgeht. Spätestens mit Features wie LTO wird der Mensch sowas von abgehängt. Technologische Singularität im kleinen Rahmen, sozusagen ;-) Der BreakEven wird aber schon viel eher erreicht. Ich würde, je nach Problemstellung, eine niedrihe 3-stellige Zahl als Codegröße (Flash) schätzen. Ohne massive Handoptimierung und Tricksereien seitens des Menschen denk ich aber dass bei ~100 Byte der Compiler auch in 95% der Fälle gewinnt.
le x. schrieb: > um eine 16-Bit-Signed Multiplikation Das ist doch aber keine typische 8bit MSR Anwendung.
Matthias L. schrieb: > Siehst Du. Und Deine Definition von Effizienz (Ram/Flash-Verbrauch) > interessiert ausser Dir eben "hier & alle wenig" bis garnicht. Genau, deswegen diskutieren wir darüber seit >1200 Beiträgen. Weil uns das überhaupt nicht kümmert ! Streng genommen hat Moby bereits ein 200Byte Programm 'geliefert' Wenn es Dir sooo wichtig ist dann analysiere den Kram, mach eine Softwarespezifikation daraus und schreibe etwas in C das das gleiche tut. Dann vergleichen wir den ASM Code und Moby lacht sich krumm weil bei 200Byte wohl tatsächlich ASM gewinnen wird. Nicht das das ein Kriterium gegen C wäre, aber nach Mobys Maßstäben kann ASM bei dieser Größe fast nur gewinnen. Damit hast Du Dich dann auf genau das Glatteis begeben von dem behauptet wurde das Moby regelmäßig darauf einbricht. Sieh es ein, er ist Dir überlegen wenn es darum geht ein Falle auszulegen und dann geduldig darauf zu warten das jemand reintappt. Um aus dieser Endlosschleife herauszukommen müsste man eine Aufgabe definieren die eine gegebene Hardware knackig ausnutzt. Ringbuffer, gleitender Mittelwert, Berechnungen >8bit, sowas in der Art. Es darf dann nur nicht die Begründung kommen das das ja keine typische Anwendung wäre. Beide Parteien (oder mehr, wenn noch jemand Fortran, Cobol, Pascal, LUA etc. beisteuern will) setzen das dann um und vergleichen wie schnell sie fertig sind und was an Ressourcen verbraucht wird. Wird keiner machen, weil, weil, weil .... Damit bleibt das hier ein rein theoretischer Schlagabtausch von einigem Unterhaltungswert.
le x. schrieb: > Spätestens mit Features wie LTO wird der Mensch sowas von abgehängt. Moby braucht keine LTO, da er keinen Linker verwendet und immer alles zusammen übersetzt. Und da seine Programme klein genug sind hat er den vollen Durchblick und macht ETO.
:
Bearbeitet durch User
Michael K. schrieb: > Wenn es Dir sooo wichtig ist dann analysiere den Kram, mach eine > Softwarespezifikation daraus und schreibe etwas in C das das gleiche > tut. Haben wir doch schon versucht: sowie du etwas findest, was man besser machen könnte, verstößt es doch sofort automatisch gegen seine Bedingungen, denn die Bedingungen sind einfach so gestaltet, dass sie nur von exakt seiner Assembler-Implementierung erfüllt werden. Jegliche Abweichung davon ist nicht etwa dann der „Gewinner“, sondern wird zum Fehler deklariert. Aus genau diesem Grunde gibt es auch niemanden, der dieses Spiel jetzt noch mitspielen würde.
Michael K. schrieb: > Streng genommen hat Moby bereits ein 200Byte Programm 'geliefert' > Wenn es Dir sooo wichtig ist dann analysiere den Kram, mach eine > Softwarespezifikation daraus und schreibe etwas in C das das gleiche > tut. jo, das ist richtig. Aber da erwarte ich die Spec von Moby. Es soll ja sein ASM Programm in C geschrieben werden. Also Moby; schreib doch mal. Aber jetzt bitte keine Verweise auf irgendwelche, nicht zusammenhängende, Thread Beiträge. Hier und jetzt. Kann ja nicht so schwer sein.
ja, man müsste eine neue Aufgabe definieren eine die auch moby "braucht" wenn er jetzt zufällig in nächster Zeit ein größeres Projekt vor hat (so in die richtug 1kByte) könnte das doch Vorstellen (also die geplante hardware und die Ziele des "Projektes" ;-)
Jörg W. schrieb: > Aus genau diesem Grunde gibt es auch niemanden, der dieses Spiel jetzt > noch mitspielen würde. Finde ich aber ganz schön clever für jemanden der ständig für blöd gehalten wird. Ich kann mich nur wiederholen (wie wir alle): Moby hat nicht vor sich schlagen zu lassen und deswegen sind die Rahmenbedingungen so definiert das das auch nicht passiert. Trotzdem könnte 'man mal' seine 200 Byte in C nachstellen so das man tatsächlich über beide ASM Codes vergleichen kann. Klar, das wird garnichts ändern, das wissen wir beide. Es wäre aber unterhaltsam und darum geht es doch hier eigentlich, oder ?
Werner P. schrieb: > jo, das ist richtig. Aber da erwarte ich die Spec von Moby. Es soll ja > sein ASM Programm in C geschrieben werden. Hatten wir auch schon mehrfach. Lehnt er ab mit der Begründung die paar Zeilen solten doch für einen gestandenen Programmierer kein Thema sein.
Michael K. schrieb: > Moby hat nicht vor sich schlagen zu lassen und deswegen sind die > Rahmenbedingungen so definiert das das auch nicht passiert. So ist es.
Moby A. schrieb: > Deine Auflistung von Erfahrungen interessiert hier & mich wenig. Fakt ist einfach, dass ich und die meisten anderen Diskussionsteilnehmer ihre Aussagen auf jahrelange Erfahrung mit verschiedensten Sprachen und Plattformen stützen, während du gerademal hobbymässig etwas Assembler betreibst. Versetz dich mal von aussen in die Situation: Zehn Profis sind sich einig, bloss ein Hobbyist hat eine andere Meinung, wer hat da in den allermeisten Fällen wohl recht? P. M. schrieb: > Moby A. schrieb: >> Manches ist jedenfalls trivialer als man denkt ;-) > > Ich weiss sowieso nicht, wie man auf den absurden Gedanken kommen kann, > der (sehr repetitive) Prozess der Compilierung/Assemblierung auf > unterster Ebene könne von einem Menschen effizienter durchgeführt werden > als von einem Computerprogramm. ...aber nimm doch dazu mal Stellung, anstatt zu persönlichen Angriffen überzugehen.
Moby A. schrieb: >> Der gcc für AVR ist aber mittlerweile eine ganz andere Liga, dem macht >> man händisch kaum noch was vor > > Köstlich. Das küre ich schon jetzt zum Witz des Tages und empfehle Dir, > mal ein paar Problemthreads zum gcc durchzugehen und Dich an dessen > Beschränktheiten zu laben. Besser soll ja der IAR sein- für ne Stange > Geld natürlich. Ja, mach das. Machen ja alle anderen mit jedem Deiner Beiträge auch so. Welche Probleme meinst Du bitte konkret? Kannst Du auch nur eines davon nachvollziehen? Hast Du dafür das nötige C-Wissen? Gerade beim Programmieren ist es eine gute Idee, die Beschränktheit zuallererst bei sich selbst zu suchen. Stefan
:
Bearbeitet durch User
Michael K. schrieb: > Genau, deswegen diskutieren wir darüber seit >1200 Beiträgen. > Weil uns das überhaupt nicht kümmert ! Du hattest doch schon ganz richtig geschrieben, worum es geht: Michael K. schrieb: > Es kommen so lange die gleichen Plattitüden bis endlich alle aufgegeben > haben mit jemanden diskutieren zu wollen dem es vollauf reicht das letze > Wort zu haben und dem nichts zu platt ist dafür. > Es würde mich diebisch freuen wenn wir diesmal den längeren Atem > beweisen und Du irgendwann einfach keine Lust mehr hast. > Ehrlich gesagt reche ich uns da keine großen Chancen aus denn Du bist > was das angeht wirklich so eine Art Gesamtkunstwerk. > Einen Versuch ist es allemal wert. Und natürlich auch darum: Michael K. schrieb: > So, nur um den Wertbewerb 'meiste Smileys pro Thread' aufzunehmen: > ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) Ich nehme jetzt mal den Wettbewerb "meiste 'nicht lesenswert' pro Beitrag" auf und bitte für diesen Beitrag um freundliche Unterstützung. mfg.
Michael K. schrieb: > Trotzdem könnte 'man mal' seine 200 Byte in C nachstellen so das man > tatsächlich über beide ASM Codes vergleichen kann. nönö, zu einfach darf das Programm auch nicht sein, damit Assembler vorteilhaft sein könnte, wie uns Moby unlängst gelehrt hat (es geht um 2 knokrete Mini-Projekte in C, die bereits lange vor dieser Diskussion fertig waren): Moby A. schrieb: > Johann L. schrieb: >> Ein nicht unwesentlicher Teil des Codes besteht aus der Initialisierung > > Darin könnte ein Grund liegen, warum in diesem Fall Asm nicht viel > rausholt. > Auch das zweite Progrämmchen ist viel zu kurz dafür. Das sind allerdings > nur grobe Vermutungen. Genauso wie ich glaube: Das eine oder andere > Byte'chen wird man dennoch aus dem Flash und dem SRAM (!) erübrigen > können. Warum um alles in der Welt sollt es einen VORTEIL bringen, da ein "Bytechen" einzusparen? Bereits vor der Implementierung hätte ich dir sagen könne, dass mit Assembler einige "Bytechen" hätten gespart werden können. Aber was ist der MEHRWERT davon? Ne handvoll Byte einsparen und dafür irgende blöde Registernummer falsch zu schreiben, weil die Division inline auszuführen 12 Byte Flash spart? Und dann die Röhrenheizung durchzuschmoren und der Röhre auf den Grabstein meisseln "Aber der mobysierte Code war 12 Bytes kürzer!"?
Johann L. schrieb: > nönö, zu einfach darf das Programm auch nicht sein, damit Assembler > vorteilhaft sein könnte, wie uns Moby unlängst gelehrt hat Nein, nicht unlängst. Das Thema hatten wir schon mal. Da ging es ausgehend von einer Instruktion um die Entwicklung des Einsparpotentials mit zunehmender Codesize... Johann L. schrieb: > Warum um alles in der Welt sollt es einen VORTEIL bringen, da ein > "Bytechen" einzusparen? Bereits vor der Implementierung hätte ich dir > sagen könne, dass mit Assembler einige "Bytechen" hätten gespart werden > können. Aber was ist der MEHRWERT davon? Bei den beiden Mickymaus Programmen von Dir? Wenig Einsparung bedeutet resourcenmäßig wenig Vorteile. Da könnte ich nur noch die allgemeine Bürokratie von C-.Programmierung ins Feld führen. Schau Dir aber Art und Größenklasse meines 200er Codes an. Da sieht die Welt schon anders aus. Und meine Prognose bis mal bis mindestens 10K wäre, daß diese für C nicht besser wird ;-) Johann L. schrieb: > dafür irgende blöde Registernummer falsch > zu schreiben, Was bitte? Eine Registernummer bei einem gegebenen, durchdachten Registersystem falsch schreiben? Lächerlich. Da sind Fehler in C-Ausdrücken ja tausendmal wahrscheinlicher ;-)
Moby A. schrieb: > Wenig Einsparung bedeutet resourcenmäßig wenig Vorteile. Und was bringt Dir die Einsparung des restlichen 80% Flashs Deines Tiny13? Meinst Du, der verbraucht dadurch jetzt nur noch 20% des Stroms? Du hast den Tiny für 100% eingekauft und Du zahlst auch 100% davon - egal, wie groß oder wie klein Dein Programm ist. Du tust auch nix für die Umwelt, wenn Du ein Byte einsparst... also warum geilst Du Dich daran so auf? > Da könnte ich nur noch die allgemeine Bürokratie von C-.Programmierung > ins Feld führen. Schau Dir aber Art und Größenklasse meines 200er Codes > an. Dein 200er Code hat keine Klasse, sondern ist und bleibt ein Micky-Maus-Programm, welches andere in einer ruhigen Minute mal so nebenbei zusammenhacken - wenn sie es denn brauchen. Aber sie brauchen es nicht. Du bist der einzige. > Da sieht die Welt schon anders aus. Und meine Prognose bis mal bis > mindestens 10K wäre, daß diese für C nicht besser wird ;-) Deine Prognose ist und bleibt falsch.
:
Bearbeitet durch Moderator
P. M. schrieb: > ...aber nimm doch dazu mal Stellung, anstatt zu persönlichen Angriffen > überzugehen. Da beschwert sich genau der Richtige. Stefan K. schrieb: > Allerdings darfst Du > auch sicher sein, daß mein geschriebener Asm-Codeumfang der letzten 3 > Jahrzehnte um ein Vielfaches größer ist als Deiner. w.z.b.w. > Und genau dieses System bringt bei großen Programmen gravierende > Nachteile bzgl. Codesize und Effizienz. Reden wir mal nicht von "großen" Programmen. Nämlich solchen, die Codegrößen von 1-100K nur vom Hörensagen kennen. Die sind mal auf jeden Fall Domäne von Asm. Ich meine für den, der entsprechend Übung, Vorbereitung, System mitbringt. Die allermeiste Sensor/Aktor-Knoten Software benötigt (in Asm) gar noch weniger! > ... weil Du sie für jeden UART mit neuen Registeradressen kopierst. In C > schreibst Du die Funktion einmal und übergibst bei Bedarf den Ptr auf > die UART-Register. Wenn Du 5 UARTs im System brauchst, dann ist in C die > Funktion nur 1* im Flash, und nicht 5 fast identische Asm-Kopien. Papperlapapp. Vielleicht soll ja die UART-Funktion mehr und spezifischeres tun als nur einen Standardbuffer einlesen. Da ist C Null im Vorteil, bringt statt dessen aber seine Ressourcen-Nachteile mit. > ATmega ist in der End-of-live-Phase, der Preis geht eher wieder hoch, es > sind mittlerweile viel performantere 32-Bitter für deutlich weniger Geld > zu bekommen. Mit dem Thema hast Du jetzt den Richtigen erwischt. Ich predige seit Jahren das ewige Leben der einfachen 8-Bitter. Die sollten nach den Prognosen gewisser Künstler hier längst verschwunden sein. Deine 32-Bit Performance kannst Du Dir sonstwohin schmieren, wenn der 8-Bitter die konkrete App locker mit seiner 8-Bit Power viel einfacher löst. Sollte der AVR nicht mehr erhältlich und die Vorräte aufgebraucht sein gehts halt mit einem anderen einfachen 8-Bitter weiter. Angeln kommt für mich nicht in Frage, vor allem nicht im kompliziert-dickflüssigen 32-Bit Teich ;-)
:
Bearbeitet durch User
So, jetzt ist es raus: Moby ist in Wirklichkeit Frauke Petry: http://www.spiegel.de/netzwelt/web/soziale-medien-demokratie-knalleffekt-ersetzt-erkenntnis-kolumne-a-1066848.html
Moby A. schrieb: > 1-100K mal sind es 1K mal 10K und jetzt 100K Moby A. schrieb: > Übung, Vorbereitung, System ich kanns nicht mehr hören! ich habe hier z.B. ein Programm (eines von vielen) für einen Atmega328. UART, RFM22B, ADC und ein paar Taster sowie Leds, Relais und OLED Display. Locker unter 32K. Komplett in C. Das möchte ich mal in ASM sehen.
Moby A. schrieb: > Reden wir mal nicht von "großen" Programmen. Nämlich solchen, die > Codegrößen von 1-100K nur vom Hörensagen kennen. Die sind mal auf jeden > Fall Domäne von Asm. Prust .... Mist alles voller Bier.
Robert L. schrieb: > Was genau willst du eigentlich? Daß mich jemand von den C-Vorteilen überzeugt ;-) > Du bist also zumindest mal ein schlechter "Lehrer"/Verkäufer.. Um Himmels Willen. Den Anspruch hab ich sicher nicht. Schau Dir den Tiobe-Index und die Position von Hochsprachen wie C darin an. Allerdings, hier gehen sämtliche Rechnerklassen ein. Für 8-Bit MSR behaupte ich aber aus eigener Erfahrung, daß direktes Asm hier sinnvoller ist als irgendwelche abstrakten Träumereien wie etwa C++. C selber steht auf diesem unheilvollen Weg weg vom Hardware-Verständnis und damit der Chance auf hochoptimierten Code irgendwo in der Mitte... > Sondern um "Code von anderen Wiederverwenden" vs. alles "Selber > schreiben wollen".. Klar. Das Library-Konzept von C insbesondere mit der Riesen-Code Auswahl könnte neidisch machen, vor allem wenn eine Lib komplexe Funktionalität mitbringt die man just gerade selber braucht. Der Vorteil wird allerdings erkauft mit oft langwieriger Suche nach dem Richtigen, der Inkaufnahme evt. enthaltener Fehler und sowieso der ganzen C-Bürokratie. Bei Asm könnte ich aber genauso (zumindest beim AVR) Massen fertigen Asm-Codes nutzen. Wenn der ASM'ler das Meiste dennoch selber schreibt dann wegen der Code-Effizienz und der bestmöglichen Anpassbarkeit an die Situation. SimplyAVR machts möglich. Oft gilt auch: Ehe ich den Fremdcode verstehe mach ichs lieber gleich selber.
Werner P. schrieb: > Moby A. schrieb: >> 1-100K > mal sind es 1K mal 10K und jetzt 100K Wenn mir nicht bald jemand beweist warum effizientes Asm in den genannten Größenordnungen schlechter als C abschneiden muß sinds bald 1M ;-) > ich kanns nicht mehr hören! Das ist aber der Schlüssel für die Asm-Effizienz in diesen Programmgrößen. > ich habe hier z.B. ein Programm (eines von vielen) für einen Atmega328. > UART, RFM22B, ADC und ein paar Taster sowie Leds, Relais und OLED > Display. > > Locker unter 32K. Komplett in C. Das möchte ich mal in ASM sehen. Locker unter 32K? Da muß ich schon schmunzeln, obwohl ich jetzt nur die genannten Stichworte kenne...
Matthias L. schrieb: > Selten soviel Blödsinn am Stück gelesen Ist auch selten, daß solche Sätze viel Überzeugungskraft mitbringen ;-) Frank M. schrieb: > Und was bringt Dir die Einsparung des restlichen 80% Flashs Deines > Tiny13? Meinst Du, der verbraucht dadurch jetzt nur noch 20% des Stroms? > Du hast den Tiny für 100% eingekauft und Du zahlst auch 100% davon - > egal, wie groß oder wie klein Dein Programm ist. Du tust auch nix für > die Umwelt, wenn Du ein Byte einsparst... also warum geilst Du Dich > daran so auf? Unterschlägst Du gerade wieder mein Erweiterbarkeits-Argument oder kommt mir das nur so vor? Achso, Du meinst ja der Code/ das Projekt wär mit nichts und garnichts erweiterbar und für niemand brauchbar ;-) Jörg W. schrieb: > Wie kommst du auf den abstrusen Gedanken, dass hier irgendjemand > anders ein C-Programm vorweisen müsste? Wer behauptet, daß C soviel effizienter wäre kann das anhand meiner fertigen Projekt Vorlage nachweisen- so einfach ist das.
:
Bearbeitet durch User
Moby A. schrieb: > Wenn mir nicht bald jemand beweist warum effizientes Asm in den > genannten Größenordnungen schlechter als C abschneiden muß sinds bald > 1M ;-) Du stellst doch Behauptungen auf, also musst du das schon beweisen, was du da erzählst. >> Locker unter 32K. Komplett in C. Das möchte ich mal in ASM sehen. > > Locker unter 32K? Da muß ich schon schmunzeln, obwohl ich jetzt nur die > genannten Stichworte kenne... Weil nicht sein kann, was nicht sein darf?
Moby A. schrieb: > Jörg W. schrieb: >> Wie kommst du auf den abstrusen Gedanken, dass hier irgendjemand >> anders ein C-Programm vorweisen müsste? > > Wer behauptet, daß C soviel effizienter wäre kann das anhand meiner > fertigen Projekt Vorlage nachweisen- so einfach ist das. Moment mal: du behauptest hier die ganze Zeit alles Mögliche und glaubst nun, irgendjemand wäre dir einen Gegenbeweis schuldig.
Moby A. schrieb: > Unterschlägst Du gerade wieder mein Erweiterbarkeits-Argument oder kommt > mir das nur so vor? Achso, Du meinst ja der Code/ das Projekt wär mit > nichts und garnichts erweiterbar und für niemand brauchbar ;-) Ich unterschlage gar nichts. Du hast noch keine Erweiterung gezeigt. Also gibt es auch keine.
Angehängte Dateien:
-
images.jpg
6,3 KB
Moby A. schrieb: > Wer behauptet, daß C soviel effizienter wäre kann das anhand meiner > fertigen Projekt Vorlage nachweisen- so einfach ist das. Jörg W. schrieb: > Du stellst doch Behauptungen auf, also musst du das schon beweisen, > was du da erzählst.
Angehängte Dateien:
-
assembly_1_.jpg
170 KB
Stefan K. schrieb: > Hast Du dafür das nötige C-Wissen? Nö. Zuweilen kann man sich aber durchaus auf die Kompetenz anderer Forums-Teilnehmer verlassen. Wenn sich deren Erfahrung manchmal noch mit der eigenen deckt umso mehr. Jörg W. schrieb: > Er will sie uns aber nicht zeigen. Er wird schon wissen, warum. Hatte gerade das Vergnügen kurz was im Code meines drittgrößten Asm-Projekts zu ändern und häng mal ein Bild vom Assembliervorgang an, um redlichen Zweiflern an 10K Asm-Codesize zumindest etwas Wind aus den Segeln zu nehmen. Ich gebe aber zu bedenken, die Grafik könnte vom betrügerischen Moby manipuliert sein ;-) Frank M. schrieb: > Ich unterschlage gar nichts. Du hast noch keine Erweiterung gezeigt. > Also gibt es auch keine. Nun mal Klartext Frank: Du hast auch behauptet, das Projekt wäre nicht und für niemand erweiterungsfähig. Was natürlich blanker Unsinn ist. Ein paar Anregungen hatte ich schon gegeben. Die Logik "es gibt keine Erweiterung, also ist es nicht erweiterbar" ist schon selten dämlich und eigentlich keiner Erwiederung wert.
Moby A. schrieb: > und häng mal ein Bild vom Assembliervorgang an, um redlichen Zweiflern > an 10K Asm-Codesize zumindest etwas Wind aus den Segeln zu nehmen. Bildformate nicht gelesen? Dass du 10 K Code zusammenbekommst, hatte ich nicht angezweifelt. Was wir allerdings anzweifeln ist, dass dieser noch die gleiche Codedichte aufweist wie dein Mini-Beispiel.
Moby A. schrieb: > Nun mal Klartext Frank: Du hast auch behauptet, das Projekt wäre nicht > und für niemand erweiterungsfähig. Was natürlich blanker Unsinn ist. Karl Heinz hat es Dir im anderen Thread bewiesen, dass Du keinen weiteren Sensor anhängen kannst, ohne den Code komplett neu zu schreiben. Das reicht mir vollkommen: Der Code ist nicht erweiterbar. Jörg W. schrieb: > Was wir allerdings anzweifeln ist, dass dieser noch die gleiche > Codedichte aufweist wie dein Mini-Beispiel. Eben. Wie oft muss man das noch wiederholen? Moby stellt sich hier offenbar bewusst dämlich.
Moby A. schrieb: > Johann L. schrieb: >> Warum um alles in der Welt sollt es einen VORTEIL bringen, da ein >> "Bytechen" einzusparen? Bereits vor der Implementierung hätte ich dir >> sagen könne, dass mit Assembler einige "Bytechen" hätten gespart werden >> können. Aber was ist der MEHRWERT davon? > > Bei den beiden Mickymaus Programmen von Dir? Jetzt muss ich doch wieder grinsen: Nachdem du dich bei deinem 200-Byte-Progrämmchen vehement gegen die Aussage gewehrt hast, es sei ein Mickymausprogramm, bezeichnest du jetzt deinerseits die Programme von Johann so. Im ersten von Johanns Programmen steckt aber mindestens doppelt so viel Funktionalität wie in deinem Programm. Wenn Johanns Programm eine Mickymaus ist, dann ist dein Programm ein Mickymäuschen. Es wird dir auch nie und nimmer gelingen, Johanns Programm mit nur 200 Byte in Assembler umzuschreiben. Offensichtlich hast du dich von dem kompakten, übersichtlichen Quellcode des C-Programms täuschen lassen, der natürlich deutlich kürzer und einfacher als dein langatmiger, unstrukturierter Assemblerrattenschwanz ist. Was du hier endlich einmal selber erfahren durftest: In höheren Programmiersprachen lassen sich im Gegensatz zu Assembler auch komplexere Berechnungen und Abläufe einfach und übersichtlich darstellen.
Frank M. schrieb: > dass Du keinen weiteren Sensor anhängen kannst, ohne den Code komplett > neu zu schreiben Auch mit anderen Erweiterungen sieht es dürftig aus: es ist gerade mal noch ein freier Pin da, über den man vielleicht einen Aktor bedienen könnte. Und für diese ominösen Erweiterungen muss dann extra der komplette RAM (abzüglich Stack) frei gehalten werden? Eigentlich wäre ein AT90S1200 für Moby das geeignetste Bauteil gewesen. Wo kein RAM ist, kann man auch keinen verschwenden. :-)
Frank M. schrieb: > Karl Heinz hat es Dir im anderen Thread bewiesen, dass Du keinen > weiteren Sensor anhängen kannst, ohne den Code komplett neu zu > schreiben. Das reicht mir vollkommen: Der Code ist nicht erweiterbar. Es hätte keines Beweises bedurft daß die Hardware nur für die entsprechende Sensorbestückung ausgelegt ist. Entsprechend ist der Code ausgelegt und entsprechend wurde er optimiert. Hör doch auf mit dem Quatsch. Erweiterbarkeit umfasst doch nicht nur die Anzahl der Sensoren ;-( Jörg W. schrieb: > Und für diese ominösen Erweiterungen muss dann extra der > komplette RAM (abzüglich Stack) frei gehalten werden? Unsinn. Diese Effizienz soll C mal nachmachen. Ansonsten bietet der RAM noch genügend Einsatzmöglichkeiten die von zusätzlicher Funktionalität genutzt werden können. Du stellst Dich ja jetzt fast genauso dumm wie Frank M. ;-( Jörg W. schrieb: > Was wir allerdings anzweifeln ist, dass dieser noch die gleiche > Codedichte aufweist wie dein Mini-Beispiel. Daran ist jetzt leider nichts zu ändern. Ich denke, die Codedichte läßt bei größeren Programmen auf jeden Fall etwas nach. Ich hatte ja schon vom Zusammenstöpseln verschiedener fertiger Funktionsbausteine gesprochen. Das geht, auch im Interesse zu wahrender Übersicht, nur mit gewissen Verlusten. Die Bausteine selber sind in ihrer Vielzahl aber sehr kompakt- in Summe dürfte das trotzdem die C-Effizienz in den Schatten stellen, da bin ich sicher. Egal was ich hier aber veröffentlichen würde- wenn auf C-Seite keiner in der Lage und willens ist, selbst einen 200-Byte Code nachzuprogrammieren fehlt ein C-Äquivalent zum Vergleich. Das letzte (natürlich wohlbehütete!) Schlupfloch für die C-Protagonisten, weil es dann tatsächlich bei Aussage gegen Aussage bleibt ;-) Das ist mir aber wurscht und wird mich nicht davon abbringen, meine Überzeugung solange zu vertreten, solange ein Gegenbeweis von C-Seite (wohlweislich) ausbleibt- es könnte ja zum Desaster ausarten (siehe Sheeva Plug). Ok, morgen kanns weiter gehen wenn immer noch Klärungsbedarf besteht ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Die Bausteine selber > sind in ihrer Vielzahl aber sehr kompakt- in Summe dürfte das trotzdem > die C-Effizienz in den Schatten stellen, da bin ich sicher. Eben nicht. Du kannst per Hand/Kopf maximal über diesen Baustein optimieren. Der Compiler kann immer über das gesamte Programm optimieren. Da kommt keiner per Hand/Kopf mehr mit. >Egal was ich > hier aber veröffentlichen würde- wenn auf C-Seite keiner in der Lage und > willens ist, selbst einen 200-Byte Code nachzuprogrammieren fehlt ein > C-Äquivalent zum Vergleich. Du hast ein paar Zeilen ASM veröffentlich. Aber keine Beschreibung was getan werden soll. Wir werden das ASM nicht ausnanderfriemeln um zu sehen, welches Bit wohin geschubst wird. Das sollte vorher feststehen. Aber diese Beschreibung deines Programmes, was es aus Sicht des Anwenders tut, lieferst Du nicht. => Einzige Erklärung, Du hast Angst, das es dann besser geht. Bisher ist ja nur die von Dir gepostete ASM-COde-Reihenfolge "optimal". Alternative neue Aufgaben, wo sich einige beteiligen würden, scheitert ja bei Dir an der Annahme/Mitdiskussion zu einer in Text beschriebenen Aufgabenstellung.. Auch davon gab es viele. Die nimmst Du nicht an, weil: - es angeblich kein "typsches 8bit MSR" ist - Du Angst hast, das C besser wird - Du nicht soviel Zeit hast/willst, während in C einfach for/while/.. hingeschrieben wird
Moby A. schrieb: > Hatte gerade das Vergnügen kurz was im Code meines drittgrößten > Asm-Projekts zu ändern und häng mal ein Bild vom Assembliervorgang an, Hmm, du hast für das Projekt einen ATxmega128A4U genommen, weil der nächstkleinere ATxmega64A4U zu wenig RAM hat. Von der Flash-Größe hätte sogar ein ATxmega16A4U locker gereicht (sogar mit etlichen freien KB für Erweiterungen ;-)). Vom dem riesigen Flash-Speicher des ATxmega128A4U sind laut Screenshot gerade einmal 7,8% belegt. Da will es mir irgendwie nicht so richtig einleuchten, warum du auf Teufel-komm-raus versuchst, Flash-Bytes einzusparen. Moby A. schrieb: > Ich denke, die Codedichte läßt bei größeren Programmen auf jeden Fall > etwas nach. Siehst du, und bei C bleibt die Codedichte auch bei größeren Programmen konstant. Moby A. schrieb: > in Summe dürfte das trotzdem die C-Effizienz in den Schatten stellen, > da bin ich sicher. Ich nicht. Da du aber einen öffentlichen Vergleich strikt ablehnst, muss das wohl jeder für sich selbst heraus finden. Ich für meinen Teil habe es schon getan, mit dem Ergebnis, dass bei Programmen dieser Größenordnung C ganz klar im Vorteil ist.
Werner P. schrieb: > Locker unter 32K. Komplett in C. Das möchte ich mal in ASM sehen. Kein Problem. Musst nur gcc -Os -S laufen lassen. ;-)
:
Bearbeitet durch User
> Ich denke, die Codedichte läßt bei größeren Programmen auf jeden Fall > etwas nach. Ich hatte ja schon vom Zusammenstöpseln verschiedener > fertiger Funktionsbausteine gesprochen. Das geht, auch im Interesse zu > wahrender Übersicht, nur mit gewissen Verlusten. Genau so ein stupides Zusammenstöpsel kann man auch bei so Compilern wie BASCOM, LunaXYZ, ... beobachten. Wenn da eine Variable nicht zweimal hintereinander in ein Register geladen wird, dann nennt sich das "Optimizer". (BTW, deshalb haben die auch kein "volatile") Man mag sich das nicht vorstellen können, aber man darf es doch mal ausprobieren, aber ein moderner Compiler ist von einer solchen "Macro-Textverarbeitung" meilenweit weg. Nur man muß eben anschauen. Bei M.'s Assembler-Code hatten wir ja schon das Vergnügen und das war weder lesbar noch hochoptimiert. Und vom geprießenen "Baukastensystem" war auch nichts zu sehen. Ist aber eh egal, denn die Anforderung des Miniprogramms war ja, den exakten Bytestream der ASM-Lösung per gcc zu erzeugen. Entsprechende PROGMEM Konstanten sowie ein adaptiertes Linkerscript sollten das möglich machen.
Moby A. schrieb: > Es hätte keines Beweises bedurft daß die Hardware nur für die > entsprechende Sensorbestückung ausgelegt ist. Entsprechend ist der Code > ausgelegt und entsprechend wurde er optimiert. Ah ja, aber dafür muss der komplette RAM dann freigehalten werden (und sogar noch ausgenullt, was nichtmal ein C-Compiler fabrizieren würde – der initialisiert nämlich nur das, was gebraucht wird)? > Quatsch. > Unsinn. > Du stellst Dich ja jetzt fast genauso dumm Aha. Lassen wir's.
A. K. schrieb: > Kein Problem. Musst nur gcc -Os -S laufen lassen. ;-) ich war zu faul nachzusehen. Der Atmega328 hat 32K Flash. Von daher meine Aussage "locker unter 32K" Es sind ca. 12K Grüße
Moby A. schrieb: > Für 8-Bit MSR > behaupte ich aber aus eigener Erfahrung, daß direktes Asm hier > sinnvoller ist als irgendwelche abstrakten Träumereien wie etwa C++. Jaja, das behauptest du gerne, das wissen wir. Aber aufgrund welcher Erfahrung? Ein paar Hobby-Projekte in Assembler, aber noch nie C/C++ programmiert? Und du konntest bisher auch noch nie zeigen, wie Assembler effizienter oder einfacher sein soll, du behauptest es einfach. Ich habe dich vor einigen Beiträgen gefragt, wie du auf die Idee kommst, der Mensch könne die mechanistische Arbeit des Assemblierens/Compilierens besser ausführen, als ein Computerprogramm. Leider kriegt man von dir auf solche fachlichen Fragen prinzipiell keine Antworten.
Werner P. schrieb: > Es sind ca. 12K ;-) Ich habe gerade mal bei mir das größte zufällig noch herumliegende ELF-File in meinen AVR-Projekten gesucht. Ist ein BASIC-Interpreter für einen ATmega128 (plus externen RAM, schließlich soll der Nutzer ja auch ein bisschen BASIC eingeben können), den ich vor 8 Jahren mal als Fingerübung gezimmert habe. In erster Linie war die Motivation, die Portierungen von byacc und flex auf den AVR auf diese Weise zu testen, d. h. die komplette lexikalische Analyse ist als lex-Code geschrieben, der Parser als yacc-Code. Gleitkomma-Arithmetik ist auch mit dabei. Das ELF-File bringt es auf weniger als 30 K Flash und 730 Byte statischen RAM-Verbrauch. Beruflich habe ich durchaus auch deutlich größeres gebaut, aber ich denke, dass ist schon ein nettes Beispiel von Hobby-Programmierung.
:
Bearbeitet durch Moderator
Naja, haarscharf die Kante des Mega32 kratzend kann ich schon bieten. Mehr als 32K gab es damals nur in Form des Mega128er und wenn ich zu viel Debugging einschaltete passte es nicht mehr. Eigentlich eine typische Moby-Aufgabe, weil Heizungssteuerung. In C++ programmiert, mit einem kleine RTOS mit drin, einem RS485 Master, etlichen Sensoren verschiedenen Typs, Tastatur, LCD-Anzeige, RTC, DCF77, I2C-EEPROM, ... Und eher auf Struktur und Flexibilität als auf Platz geschrieben. Was Moby freuen wird: Das RTOS ist komplett in Assembler (nicht von mir) und der RS485-Slave ein Tiny2313 auch in Asm (von mir).
:
Bearbeitet durch User
A. K. schrieb: > Mehr als 32K gab es .... > ... in C++ programmiert Hättest Du statt dem bürokratischem C++ das einfach mit Übung/System/Vorbereitung (TM) komplett in ASM gemacht, hätte ein Tiny gereicht. Allerdings wärst Du wohl eher in Rente, als das es fertig wäre.
Matthias L. schrieb: > Allerdings wärst Du wohl eher in Rente, als das es fertig wäre. Nö, das wär schon gegangen. Nicht so schnell und weniger leicht adaptierbar, aber ich habe auch ganz gut Übung in Assembler, wenngleich damals nicht AVR. Klar, länger gedauert hätte es schon und es wäre nicht in gleicher Weise aufgebaut gewesen. Aber so war es mein erstes AVR Projekt und neben dem eigentlichen Zweck auch Experimentierfeld, um zu sehen, was damit geht, und wie. Ist seither aber durchaus produktiv. Mit IoT-Erweiterung. Ist halt schön, wenn das Interface eines Temperatursensors davon unabhängig ist, ob es sich um einen DS18x20 oder einen LM335 handelt. In C++ trivial. Und wenn man in 0.1° Schritten rechnen oder 32-Bit Date/Time-Werte vergleichen kann ohne sich einen abzubrechen. ;-) Wo ich schon ein RTOS drin hatte, hatte ich da auch mit Software-Strukturen experimentiert. So gibt es eine Task, die nur dazu da ist, die Konsistenz des Zustands zu überprüfen, also ob die Werte und Zustände zueinander passen, Sensorwerte nicht zu alt sind etc.
:
Bearbeitet durch User
A. K. schrieb: > RS485-Slave ein Tiny2313 auch in Asm (von mir Super. Und wieviel RAM und Flash hast du gespart? mfg.
Thomas E. schrieb: > Super. Und wieviel RAM und Flash hast du gespart? Keine Ahnung, weil es beim Slave nie eine C Version gab. Das war, wie schon geschrieben, mein erstes AVR Projekt und ich wollte beides ausprobieren. High-Level im Master und Asm im Slave. Dieser Teil des Projekts wäre in C vermutlich nicht so sehr viel schneller fertig gewesen, wenn man davon absieht, dass es dann gemeinsamen Code mit dem Master gegeben hätte. Alles recht einfach aufgebaut und geradeaus. Das Programm vom Slave: ATtiny2313 memory use summary [bytes]: Segment Begin End Code Data Used Size Use% --------------------------------------------------------------- [.cseg] 0x000000 0x00053c 1258 82 1340 2048 65.4% [.dseg] 0x000060 0x0000c0 0 96 96 128 75.0% [.eseg] 0x000000 0x000000 0 0 0 128 0.0% Wenns interessiert siehe Anhang. Drin ist der RS485-Slave, ein DS18x20, ein serielles Interface zu einer damals schon alten Conrad Funkuhr, ein LCD-Display, paar Schalter. Das RAM dient nur als UART-Puffer und Stackspace.
:
Bearbeitet durch User
A. K. schrieb: > Keine Ahnung, weil es beim Slave nie eine C Version gab. Was? Das erkennt man doch auch so. Das ist Effizienz, wie sie nur mit Assembler möglich ist. Ich denke, mit dem dicken C-Compiler mit seiner ganzen Resourcenverschwendung wäre die Küche kalt, weil du immer noch auf den 8313 warten würdest. mfg.
Moby A. schrieb: > Werner P. schrieb: >> Moby A. schrieb: >>> 1-100K >> mal sind es 1K mal 10K und jetzt 100K > > Wenn mir nicht bald jemand beweist warum effizientes Asm in den > genannten Größenordnungen schlechter als C abschneiden muß sinds bald > 1M ;-) Das würden wir sogar gerne. Alleine es scheitert an dir, weil du dich standhaft weigerst, einmal ein etwas größeres Programm in Assembler zu formulieren, während wir dir hier die C Version auf die Schnelle zusammenkloppen. Angebote gabs genug. Einzig und alleine du weigerst dich, den Beweis anzutreten, dass du auch das noch kürzer und vor allen Dingen mit weniger Fehlern hinkriegst.
Thomas E. schrieb: > Was? Das erkennt man doch auch so. Das ist Effizienz, wie sie nur mit > Assembler möglich ist. Wäre in C mit Sicherheit grösser gewesen, allzumal im RAM. Aber ob im RAM nun 96 Bytes UART-Puffer liegen weil halt genug da ist, oder 64 Bytes, das wäre egal gewesen. Ich hätte mich damals aber nicht getraut, von vorneherein davon auszugehen, dass der Code in C in 2KB passt. Dass er deutlich länger wäre ist sicher, denn die Beschränkung auf Register als Speicher ist dem Compiler nicht gegeben, und das kostet recht viel.
:
Bearbeitet durch User
Moby A. schrieb: > etwas nach. Ich hatte ja schon vom Zusammenstöpseln verschiedener > fertiger Funktionsbausteine gesprochen. Das geht, auch im Interesse zu > wahrender Übersicht, nur mit gewissen Verlusten. Die Bausteine selber > sind in ihrer Vielzahl aber sehr kompakt- Nichts anderes macht der Compiler. NUr dass er sich dann den ganzen Abschnitt noch einmal vornimmt und eine entsprechende Optimierung drüber laufen lässt. Und das schneller und zuverlässiger und mit weniger logischen Fehlern, als du als Mensch das jemals könntest. > in Summe dürfte das trotzdem > die C-Effizienz in den Schatten stellen, da bin ich sicher. Deine Sicherheit trügt. Die Praxis sagt nämlich etwas anderes. Sie sagt unter anderem auch, dass die Diskrepanz immer größer wird, je größer der Code wird. Bei winzigsten Programmen hat man mit Assembler je nach konkreter Aufgabenstellung einen Vorteil. Aber das relativiert sich sehr schnell und die Hochsprachen setzen zum Überholvorgang an. Ab da wird dann der Abstand rasch immer größer und ist selbst von geübtem Assembler Programmierern nicht mehr zu schliessen.
Karl H. schrieb: > Die Praxis sagt nämlich etwas anderes. Sie sagt > unter anderem auch, dass die Diskrepanz immer größer wird, je größer der > Code wird. Bei winzigsten Programmen hat man mit Assembler je nach > konkreter Aufgabenstellung einen Vorteil. Aber das relativiert sich sehr > schnell und die Hochsprachen setzen zum Überholvorgang an. Ich hab echt Respekt vor eurer Engelsgedult, aber ist euch wirklich nicht klar dass das schon gefühlte 300 mal angeführt wurde? Glaubt ihr wirklich eine echte Diskussion zu führen?
@A.K.
Du Ast ja auch richtig viel gespart, denn nach der Befehlsstatistik am
Ende des Listings werden viele Befehle garnicht benutzt. Die zu ihrer
Ausführung notwendigen Schaltelemente werden somit für eine spätere
Verwendung in einen Programm mit komplementärem Befehlspektrum geschont.
Dank ASM hat man volle Kontrolle darüber, welch Befehle benutzt werden.
Auch werden die Register R20..23 als Notfallreserve aufgespart.
Vorbildlich! Dafür gibt es den goldenen Wal am Bande!
Leider suggeriert aber die Verwendung von 5x! EOR, daß es sich hier um
keine typische MSR-Anwendung handelt.
Nein, MSR hat nichts mit Messen oder Steuern oder Regeln zu tun. Das
bedeutet Moby-Spart-Register. Damit ist auch klar, warum kein anderer zu
etwas Kompatiblem imstande wäre.
{$Scherz.off}
Wenn man erst sieht mit welchen fiesen ASM-Tricks ein Compiler die
Mehrfachnutzung von Code machen kann, z.B. bei -mcall-prologues. Sowas
get auch per Hand, aber wer kann da schon den Überblick behalten.
> Glaubt ihr wirklich eine echte Diskussion zu führen?
Nö, aber solange es Spaß macht. Wenn's mich anödet, dann lass ich's
sein, aber solange der Herausforderer immer wieder zappelt ...
:
Bearbeitet durch User
Yalu X. schrieb: > Moby A. schrieb: >> Johann L. schrieb: >>> Warum um alles in der Welt sollt es einen VORTEIL bringen, da ein >>> "Bytechen" einzusparen? Bereits vor der Implementierung hätte ich dir >>> sagen könne, dass mit Assembler einige "Bytechen" hätten gespart werden >>> können. Aber was ist der MEHRWERT davon? >> >> Bei den beiden Mickymaus Programmen von Dir? > > Jetzt muss ich doch wieder grinsen: > > Nachdem du dich bei deinem 200-Byte-Progrämmchen vehement gegen die > Aussage gewehrt hast, es sei ein Mickymausprogramm, bezeichnest du jetzt > deinerseits die Programme von Johann so. Na diese beiden Programme sind ja auch vom MiMo-Typ — eben weil sie die einzigen sind, die (annähernd) das Moby-Kriterium erfüllen. Alle anderen meiner Programme für 2KiB AVR (und drüber eh) wollte ich echt nicht in Assembler tippseln weils eben NIX bringt. > Im ersten von Johanns Programmen steckt aber mindestens doppelt so viel > Funktionalität wie in deinem Programm. Wenn Johanns Programm eine > Mickymaus ist, dann ist dein Programm ein Mickymäuschen. Es wird dir > auch nie und nimmer gelingen, Johanns Programm mit nur 200 Byte in > Assembler umzuschreiben. Das erste Programm erzeugt ca. 500 Bytes Binärcode (bei netto 100 LOC), ist eben viel SFR-Geraffel und auch 32-Bit Arithmetik. Und ja, das ginge in Assembler kleiner, aber keinesfalls in 200 Bytes. Und die 32-Bit Division inline zu kopieren, um ein paar grottige Bytes Code zu sparen, das macht Moby bestimmt Spaß... > Offensichtlich hast du dich von dem kompakten, übersichtlichen Quellcode > des C-Programms täuschen lassen, der natürlich deutlich kürzer und > einfacher als dein langatmiger, unstrukturierter Assemblerrattenschwanz > ist. > > Was du hier endlich einmal selber erfahren durftest: > > In höheren Programmiersprachen lassen sich im Gegensatz zu Assembler > auch komplexere Berechnungen und Abläufe einfach und übersichtlich > darstellen.
A. K. schrieb: > Thomas E. schrieb: >> Super. Und wieviel RAM und Flash hast du gespart? > > Wenns interessiert siehe Anhang. Drin ist der RS485-Slave, ein DS18x20, > ein serielles Interface zu einer damals schon alten Conrad Funkuhr, ein > LCD-Display, paar Schalter. Das RAM dient nur als UART-Puffer und > Stackspace. Du meine Güte, was hast du alleine mit deinen überflüssigen Kommentaren an Resourcen verschwendet. Weist du nicht dass man für evtl. Erweiterungen die Tastatur schonen muß?
Michael K. schrieb: > Streng genommen hat Moby bereits ein 200Byte Programm 'geliefert' Bitte entschuldige, aber welches der beidem "Programme" meinst Du denn? Jenes, das Yalu nach Mobys eigenen Kriterien so viel besser gelöst hat? Oder meinst Du seine offensichtlich böswillig konstruierte Falle? Ist aber auch wirklich blöd für den armen Moby. Erst bricht er sich einen ab um eine Falle zu konstruieren, die den Compiler möglichst alt aussehen läßt. Dann scheint einer hinein zu tappen, und dessen Kompilat sieht viel kleiner aus als seine ausgeklügelte Falle... sapperlot! >>Und er kommt zu dem Ergebnis: "Nur ein Traum war das Erlebnis. Weil", so schließt er messerscharf, "nicht sein kann, was nicht sein darf.<< (Christian Morgenstern, "Die unmögliche Tatsache") Also gerät der arme Moby in Panik und erfindet neue Anforderungen, von denen er nun aber ganz sicher ist, daß sie vom Compiler nicht erfüllt werden können. Menno! Nun reitet er bis zum Wundbrand auf seiner Falle herum -- aber was bleibt ihm auch anderes übrig? Und gleichzeitig versucht er sich an meinem Code abzuarbeiten, weil er trotz meiner ausdrücklichen Hinweise offensichtlich immer noch nicht kapiert hat, daß er nur ein Honigtöpfchen war, in das er mit großer Geste hineingefallen ist. Menno!! Die Moral von der Geschicht': je mehr Aufwand man treibt, um anderen eine Falle zu stellen, desto blöder ist es, selbst hinein zu fallen. Menno!!1! Gehuldigt sei dem Gewinner des Smileywettbewerbs: *ROFLMAO!*
Moby A. schrieb: > Reden wir mal nicht von "großen" Programmen. Nämlich solchen, die > Codegrößen von 1-100K nur vom Hörensagen kennen. Die sind mal auf jeden > Fall Domäne von Asm. Ich meine für den, der entsprechend Übung, > Vorbereitung, System mitbringt. Sind "Übung" und "Vorbereitung" nicht genau jener ressourcenverschwendende Overhead, den Du C immer vorwirfst? Für winzige Miniaturprogrämmchens, von denen Du hier faselst, brauch ich in C weder Übung, noch Vorbereitung. Das hack' ich einfach 'runter und hab' dann mehr Zeit zum Knutschen.
Gu. F. schrieb: > Glaubt ihr wirklich eine echte Diskussion zu führen? Nein, aber hast du mal versucht die Zeugen Jehovas an der Haustür zu überzeugten Satanisten zu bequatschen ? Das muß man als sportlichen Wettkampf sehen. Natürlich macht das überhaupt keinen Sinn, das ist so eine Art Brainjogging. Sheeva P. schrieb: > Also gerät der arme > Moby in Panik und erfindet neue Anforderungen Ich denke Du täuscht Dich. Moby hat vor langer Zeit jegliche Diskussions-Konventionen über Board geworfen. Er muß nicht in Panik geraten, er muß nichts beweisen, er behauptet einfach was er will, wann er will und ignoriert alles was seine Kreise stört. Ob er das wirklich alles glaubt, uns nur veräppelt, im realen Leben Bankensoftware in Cobol programmiert oder eine übergewichtige Friseuse aus Castrop Rauxel mit einem Hang zu Kreuzworträtseln und ASM ist werden wir wohl nie herausfinden. Ich finde das alles hochgradig lustig. Tschuldigung, aber auch Deine / Eure Verbissenheit finde ich recht erheiternd. Es macht wirklich keinen Sinn mit ihm zu diskutieren, nicht bei diesem Thema. Da kann man jetzt vor Wut die Tapeten von der Wand kratzen oder in sich hineinlächeln wie viele bunte Vögel diese Welt doch zu bieten hat. Stellenweise hat dieser Thread wirklich lehrreiche Dinge zu Tage gefördert, wozu ich unter anderem auch teilweise Deine Beiträge zähle. Die ganze Aufregung das er das einfach nicht einsieht ist aber verschwendete Energie. Diese Wut führt nur dazu das man sich selbst zu Äusserungen hinreissen läßt die nicht ganz sauber sind. Vor allem glaube ich eines. Wenn man mit einem Typen wie Moby beim Bier zusammensitzen würde währe man wahrscheinlich baff erstaunt wie vielschichtig und reflektiert der über unterscheidlichste Dinge reden kann. Die Forenfigur Moby ist eine Kreation des Menschen der dahinter verborgen bleibt. Dazu dient diese Figur und sie folgt einem Drehbuch. Sich darüber aufzuregen ist als würde ich Gerd Fröbe persönlich übelnehmen das er als Goldfinger 007 töten wollte.
Michael K. schrieb: > Wenn man mit einem Typen wie Moby beim Bier zusammensitzen würde währe > man wahrscheinlich baff erstaunt wie vielschichtig und reflektiert der > über unterscheidlichste Dinge reden kann. Das könnte ich mir auch gut vorstellen.
Michael K. schrieb: > Sheeva P. schrieb: >> Also gerät der arme >> Moby in Panik und erfindet neue Anforderungen > > Ich denke Du täuscht Dich. > Moby hat vor langer Zeit jegliche Diskussions-Konventionen über Board > geworfen. Er muß nicht in Panik geraten, er muß nichts beweisen, er > behauptet einfach was er will, wann er will und ignoriert alles was > seine Kreise stört. Diese These hast Du wiederholt geäußert, und einerseits bin ich durchaus geneigt, Dir darin zuzustimmen. Andererseits paßt es aber nicht ganz ins Bild, daß er so reagiert hat wie geschehen. Er hätte meinen Code zuerst testen und dann danach reagieren können. Dann wäre ihm sofort aufgefallen, daß der Code nicht funktionierte. Das hat er aber nicht getan, sondern sich stattdessen die Blöße gegeben, sofort und zuerst die neue Anforderung aus dem Hütchen zu zaubern und danach erst auszuprobieren, ob mein Code wirklich tut, was er denn tun sollte. Sicher hätte er das auch getan, wenn mein Honigtöpfchen im Vergleich nicht gar so klein gewesen wäre, oder wenn er gleich hätte sehen können, daß es nicht funktioniert. Daß mein Code so unlesbar ist und so viele ungebräuchliche Konstrukte nutzt, ist ja nun kein Zufall. g Obendrein scheint mir die Tatsache, daß er manchmal ziemlich wild um sich beißt, wenn er sich in die Enge getrieben sieht, darauf hinzuweisen, daß ihm durchaus etwas an der Sache liegt. Jedoch vermute ich, daß er C ganz passabel beherrscht und recht gut weiß, was so ein C-Compiler kann, denn sonst hätte er seine Falle nicht so ausgefeilt konstruiert. Insofern bin ich hinsichtlich Deiner These etwas unschlüssig -- aber das gehört ja zu dem, was die Geschichte so unterhaltsam macht. g > Stellenweise hat dieser Thread wirklich lehrreiche Dinge zu Tage > gefördert, wozu ich unter anderem auch teilweise Deine Beiträge zähle. Danke -- ich hoffe, nicht nur als Sozialstudie! g
Hmm, so einmal am Tag über die neuen Posts in diesem Thread gehen ist schon amüsant. Auf der einen Seite Moby, der davon überzeugt ist, das man mit Lochkarten näher an der Maschine ist und deswegen immer effizienter arbeiten kann gegen den Rest, der weiß, daß man mit mit Tastatur und Bildschirm praktisch immer im Vorteil ist....
:
Bearbeitet durch User
Michael K. schrieb: > Vor allem glaube ich eines. > Wenn man mit einem Typen wie Moby beim Bier zusammensitzen würde währe > man wahrscheinlich baff erstaunt wie vielschichtig und reflektiert der > über unterscheidlichste Dinge reden kann. Brrr die Vorstelltung find ich grad gruselig. Der wird sicher nicht auf Knopfdruck zum besten Kumpel. Wer sich mit Lügen und derart arrogant (wenn auch sehr unterschwellig) solche Garbenkämpfe liefert ist am Abend in der Kneipe immer noch der selbe Typ Mensch.
A. K. schrieb: > ein DS18x20, > ein serielles Interface zu einer damals schon alten Conrad Funkuhr, ein > LCD-Display, lol alles was du nicht selber kannst, hast du also in externe Hardware ausgelagert... ;-) ps. warum braucht C eigentlich (per se?) mehr speicher? sollte es nicht (durch "lokale variablen", bessere ausnützen der register usw) für C viel einfacher sein, speicher mehrfach (stack usw.) zu verwenden.. (und eben nur so kurz wie möglich zu reservieren)
Robert L. schrieb: > ps. warum braucht C eigentlich (per se?) mehr speicher? Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu suchen, für die man komplett und ausschlieslich mit den Registern der CPU durchkommt. Speicher braucht er dann nur für den Returnstack. Das ist in C ein bisschen schwer zu realisieren. Man könnte zwar mittels 'register' den Compiler auffordern, bestimmte Variablen in bestimmte Register zu legen, aber das ist ein 2-schneidiges Schwert, sobald irgendwelche System Library Aufrufe dazukommen, die von dieser Reservierung nichts wissen.
Robert L. schrieb: > alles was du nicht selber kannst, hast du also in externe Hardware > ausgelagert... Stimmt. ;-) > ps. warum braucht C eigentlich (per se?) mehr speicher? Tut es nicht. Nur zeigt grad das Beispiel meines gestern geposteten Asm-Codes die Grenzen der üblichen Compiler. Der Compiler wird Variablen nicht über die Grenzen von Funktionen hinaus in Registern platzieren. Grad bei Prozessoren mit vielen Registern, wie AVR, kann das einen erheblichen Unterschied ausmachen. Da aber die Anzahl Register begrenzt ist, ist es auch die Anzahl darin platzierbarer Variablen. Bei kleinen Programmen ist das kein Problem. Bei grossen und bei oft signifikant veränderten Programmen eignet sich diese Programmiertechnik weniger. Man könnte natürlich auch einen optimierenden Compiler bauen, der globale Registerplatzierung effizient nutzt, wenn ihm das sinnvoll erscheint. Ein solcher Compiler könnte auch bei kleinen Programmen locker mithalten. Nur müsste man dann immer alles zusammen übersetzen, sämtliche Libraries eingeschlossen. Das ist bei kleinen Programmen nur problemlos möglich, wenn der Quellcode der Libraries vorliegt, und bei grossen Programmen nicht praktikabel.
:
Bearbeitet durch User
A. K. schrieb: > Der Compiler wird Variablen > nicht über die Grenzen von Funktionen hinaus in Registern platzieren. ok, ich dachte mir es gibt vielleicht sowas wie "fastcall" https://de.wikipedia.org/wiki/Aufrufkonvention#Register_.28FastCall.29 gerade bei einer CPU mit so viel (pseudo-?) Registern wäre es doch hilfreich..
Robert L. schrieb: > ich dachte mir es gibt vielleicht sowas wie "fastcall" Bei Architekturen mit ausreichender Anzahl Register werden Parameter üblicherweise in Registern übergeben, soweit möglich. Bei AVR ebenfalls. Diese fastcall Methode ist also Stand der Technik. Das x86 ABI, aus dem man fastcall kennt, geht allerdings auf Zeiten vor ANSI-C zurück, und ohne Parameterdeklaration gibts bei der routinemässigen Übergabe in Registern kleine Probleme. Bei dem was ich grad schrieb geht es aber nicht um die Übergabe von Parametern, sondern um statische/globale Variablen.
:
Bearbeitet durch User
Karl H. schrieb: > Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu > suchen, für die man komplett und ausschlieslich mit den Registern der > CPU durchkommt. Speicher braucht er dann nur für den Returnstack. Ja. Und andere Aufgaben sind keine typischen 8bit MSR Anwendungen und werden per externem IC beigefügt.
Bernhard M. schrieb: > Hmm, so einmal am Tag über die neuen Posts in diesem Thread gehen ist > schon amüsant. Ja, es sind ein paar gute Kolumnisten dabei.
Karl H. schrieb: > Robert L. schrieb: > >> ps. warum braucht C eigentlich (per se?) mehr speicher? > > Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu > suchen, für die man komplett und ausschlieslich mit den Registern der > CPU durchkommt. Speicher braucht er dann nur für den Returnstack. So ist es, weswegen er ja auch nur solche Mickymausanwendungen für einem Vergleich zur Verfügung stellt. Wenn man sich nämlich einmal die etwas größere Applikation von Moby anschaut (für deren Programmierung Assembler seiner Ansicht nach ja ebenfalls nur Vorteile bringen soll), stellt man fest, diese sehr wohl RAM benutzt und davon nicht einmal wenig, nämlich 5415 Byte, s. dieser Beitrag: Moby A. schrieb: > 10K Asm-Codesize Eine solch intensive Speichernutzung entsteht meist dadurch, dass man größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler keine Vorteile bietet. Anders als in Assembler hat man aber in C die Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von 8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder 12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden. Wenn man wie Moby darauf erpicht ist, immer den jeweils kleinstmöglichen Controller einzusetzen, sehe ich hier gute Chancen, mit der Verwendung von C-Bitfields den ATxmega128A4U durch einen ATxmega64A4U mit halb soviel Speicher (4096 Byte RAM) zu ersetzen. Dadurch wird das Binary des Programms zwar etwas länger und langsamer, aber Flash-Speicher steht bei diesen Controllern sowieso im Überfluss zur Verfügung, und auch die Laufzeiteffizienz dürfte bei dieser Anwendung nicht die entscheidende Rolle spielen. Natürlich könnte man dasselbe auch in Assembler tun, allerdings erfordert das viel zusätzlichen Programmieraufwand, zudem wird das Programm durch die komplizierteren Elementzugriffe unübersichtlich und schlecht wartbar. In C hingegen hat man durch die Verwendung von Bitfields praktisch überhaupt keinen zusätzlichen Entwicklungsaufwand, da man im Wesentlichen nur die Datenstruktur(en) etwas anders deklarieren muss. Die Zugriffe auf Elemente mit "krummen" Bitzahlen werden vom Compiler automatisch erzeugt und unterscheiden sich im Quellcode überhaupt nicht von gewöhnlichen Elementzugriffen. Deswegen würde ich sagen, dass bei datenintensiven Anwendungen wie Mobys Haussteuerung C nicht nur bzgl. der Entwicklungszeit sondern auch des RAM-Verbrauchs klare Vorteile bietet.
Naja, prinzipiell geht das alles in ASM ja auch, insofern kann man nicht sagen daß C weniger Speicher braucht. Nur ist der Programmieraufwand inklusive Fehleranfälligkeit in ASM natürlich drastisch höher, wenn man so geizig programmiert. Per Definition ist es dann aber keine typische Anwendung mehr :-)
Yalu X. schrieb: > Hmm, du hast für das Projekt einen ATxmega128A4U genommen, weil der > nächstkleinere ATxmega64A4U zu wenig RAM hat. Von der Flash-Größe hätte > sogar ein ATxmega16A4U locker gereicht (sogar mit etlichen freien KB für > Erweiterungen ;-)). Was ist denn das für ein altkluger Vorwurf... Da handelt es sich um Code für meine SmartHome-Zentrale. Da wird ständig erweitert, die ist niemals fertig. Wie dumm, bei solch absehbarer Zukunft am falschen Ende zu sparen. Ganz anders sieht das z.B. bei Sensor-Aktor Knoten und kleinen dezentralen Steuerungen aus. Halt weiteren Millionen 8-Bit MSR Anwendungen. Yalu X. schrieb: > Siehst du, und bei C bleibt die Codedichte auch bei größeren Programmen > konstant. Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter bleibt. Die etwas nachlassende Codedichte geht im Wesentlichen auf die notwendige Gliederung des Codes zurück, um bei größeren Projekten den Überblick zu behalten. In einem finalen Schritt könnte man das freilich vieles zusammenlegen. Frank M. schrieb: > Moby A. schrieb: >> Frank M. schrieb: >>> Ab 1KB Codegröße ist ASM mit C IMMER schlagbar >> >> Das halte ich für falsch. Und wir wollen gleich nochmal klarstellen, >> daß nichts als der Ressourcen-Verbrauch gemeint ist. > > Genau dafür hast Du keinen Beleg. Hast Du denn einen Beleg für Deine Behauptung ? Wie man schön sieht handelt es sich bei mangelnden Vergleichsmöglichkeiten hier um ein Totschlagargument, mit dem kein Blumentopf zu gewinnen ist. Um da weiterzukommen und mal einen Anfang zu machen habe ich mich für meine Behauptung um eine simple, aber vollständige Asm-App zum Vergleich bemüht: Beitrag "Kleines Tiny13 Sensorboard" Wie zu erwarten kam natürlich nichts besseres. Die meisten werden hier trotz anderslautender Heuchelei wissen, daß man sich mit dem Versuch nur in die Nesseln setzen kann. Denn wenn manche Profis hier nur halb so viel C-Experte sind wie sie tun wär das längst fertig ;-) @Mod: Die Beantwortung von Beiträgen wird ohne funktionierende Aufteilung bei langen Threads immer zäher. Ist das Absicht? ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Die Beantwortung von Beiträgen wird ohne funktionierende > Aufteilung bei langen Threads immer zäher. Nach welchen Kriterien willst du aufteilen? "Sinnvoll" und "nicht sinnvoll"?
:
Bearbeitet durch User
Klaus W. schrieb: > Nach welchen Kriterien willst du aufteilen? > "Sinnvoll" und "nicht sinnvoll"? Du meinst "Sinnvoll" so wie Dein Beitrag gerade? Immer wieder beeindruckend, was manche "Profis" hier so draufhaben ;-(
:
Bearbeitet durch User
Moby A. schrieb: > Hast Du denn einen Beleg für Deine Behauptung ? > Wie man schön sieht handelt es sich bei mangelnden > Vergleichsmöglichkeiten hier um ein Totschlagargument, mit dem kein > Blumentopf zu gewinnen ist. Moby FALSCH!!! Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich zurück mit Falschaussagen Beitrag "Re: C versus Assembler->Performance"
also wenn man als ASM Programmierer etwas lernt, dann offensichtlich c&p
Moby A. schrieb: > Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter > bleibt. Die etwas nachlassende Codedichte geht im Wesentlichen auf die > notwendige Gliederung des Codes zurück, um bei größeren Projekten den > Überblick zu behalten. Und eben deswegen ist die Code auch nicht dichter als in C. Ganz im Gegenteil: Der vom C-Compiler erzeugte Assemblercode braucht nicht übersichtlich zu sein, deswegen darf der Compiler gerne etwas mehr optimieren (und tut das auch) als du es mit Rücksicht auf die Übersichtlichkeit tun würdest. > In einem finalen Schritt könnte man das freilich vieles zusammenlegen. Was aber rein hypothetisch ist, da der finale Schritt nie stattfinden wird, wie du ja selbst schreibst: Moby A. schrieb: > Da handelt es sich um Code für meine SmartHome-Zentrale. > Da wird ständig erweitert, die ist niemals fertig. In C muss man für so etwas nicht bis zum finalen Schritt warten, weil mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit verbunden ist.
>>>> Ab 1KB Codegröße ist ASM mit C IMMER schlagbar >>> Das halte ich für falsch. >> Genau dafür hast Du keinen Beleg. > Hast Du denn einen Beleg für Deine Behauptung ? > ... > Beitrag "Kleines Tiny13 Sensorboard" Zurück auf los! Yalu X. schrieb: > In C muss man Dafür muss man erst C lernen. Oder als Workaround sich ASM schön reden.
:
Bearbeitet durch User
Yalu X. schrieb: > größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal > in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler > keine Vorteile bietet. Anders als in Assembler hat man aber in C die > Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger > zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von > 8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder > 12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden. Nicht nur das. Ich habe auch die Möglichkeit, schnell und einfach die komplette Datenorganisation zu ändern, wenn sich im Laufe der Zeit die Anforderungen ändern oder erweitert werden muss. In Assembler artet so ein Unterfangen regelmässig in einen mittleren Albtraum aus. Und ja, ich weiss durchaus wovon ich da spreche, hab ich schon gemacht - würde ich nie wieder tun.
Karl H. schrieb: > wenn sich im Laufe der Zeit die > Anforderungen ändern oder erweitert werden Du hast vorher nur nicht genügend Vorbereitung Planung und Übung gemacht.
Moby A. schrieb: > Egal was ich > hier aber veröffentlichen würde- wenn auf C-Seite keiner in der Lage und > willens ist, selbst einen 200-Byte Code nachzuprogrammieren fehlt ein > C-Äquivalent zum Vergleich. Ich werde Dir jetzt mal vorführen, warum Deine Argumentation Schwachsinn ist. Situation A =========== - Moby legt ein 200Byte-Programm vor - Moby sagt: "Solange kein C-Programmierer ein äquivalentes C-Programm vorlegt, ist mein Programm in ASM das optimalste Programm der Welt!" - Keiner hat Lust, Mobys Programm in allen Einzelheiten zu verstehen (weils Zeit kostet) und alle verlieren auch sämtliche Lust, weil Moby plötzlich nachschiebt, als er seine Felle schwimmen sieht: "Das Programm darf KEIN RAM nutzen!". Auch hat keiner Lust, da Arbeit reinzustecken, weil keiner es braucht - Moby schreit: "Aha, ihr könnt es nicht! ASM ist also BESSER!" Soweit so gut. Jetzt drehe ich den Spieß rum: Situation B =========== - N.N. legt ein C-Programm vor mit 1KB Binärgröße - N.N. sagt: "Solange kein ASM-Programmierer ein äquivalentes ASM-Programm vorlegt, ist mein Programm in C das optimalste Programm der Welt!" - Moby sagt: "Nee, habe ich keine Lust, weil ichs nicht brauche". - N.N. schreit: "Aha, Du kannst es nicht! C ist also BESSER!" Würdest du so einen Scheiß akzeptieren? Ich kann Dir hunderte von C-Programmen hier präsentieren, wo Du überhaupt nicht in der Lage wärest, diese in ASM nachzugrogrammieren. Aber nur um zu sagen: "C ist besser als ASM"? Bestimmt nicht. Weil diese Argumentation Schwachsinn ist.
:
Bearbeitet durch Moderator
Frank M. schrieb: > - Keiner hat Lust, Mobys Programm in allen Einzelheiten zu verstehen > (weils Zeit kostet) Eigentlich nicht. Yalu hat mich da wieder auf ein paar Ideen gebracht, wie man den Compiler für seine Sensorboard Aufgabenstellung mit dem kruden Übertragungformat zu seinem Nutzen einspannen könnte. Und auch die Sache mit den Register-Variablen würde man IMHO in den Griff kriegen (avr-gcc unterstützt ja noch das 'register' Schlüsselwort und Library Aufrufe sind nicht notwendig) Nur hab ich deswegen keine Lust dazu, weil sich Moby konsequent in der umgekehrten Richtung weigert, aus einer etwas umfangreicheren Vorgabe in absehbarer Zeit ein entsprechendes ASM-Programm zu schreiben. Also genau dein Szenario B, nur das ich etwas größer angesetzt hätte als lediglich 1K, damit die Diskrepanz so richtig schön zum tragen kommt :-) Ich versteh natürlich, dass er da nicht 3 Wochen jeden Tag 3 bis 4 Stunden über dem Code brüten will, um den Flash Verbrauch wieder um 3 Bytes zu drücken. Aber auf der anderen Seite ist genau das die Lektion, um die es geht: Erstens interessiert das keinen, ob das Programm 3 Bytes kürzer ist oder nicht, solange es in den Flash passt und zweitens ist genau das Argument, das Moby immer wieder bringt ("Ich hab mit meiner Zeit besseres zu tun") genau eines der Argumente, warum Hochsprachen meistens die bessere Wahl sind - eben weil wir mit unserer Zeit besseres zu tun haben, als 3 Bytes im Flash nachzujagen.
:
Bearbeitet durch User
Moby A. schrieb: > Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter > bleibt. Hör jetzt bitte mal auf mit dem Unsinn, das ist wirklich nur noch lächerlich und keiner Diskussion mehr würdig. Sollte man nach dermassen viel Widerspruch von deutlich erfahreneren Leuten ja irgendwann kapieren, findest du nicht? Markus M. schrieb: > Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich > zurück mit Falschaussagen Am Anfang war Moby einfach stur und uneinsichtig, dann begann er, Argumente und Fakten ganz zu ignorieren und mittlerweile ist er sogar zu Lügen und Falschaussagen übergegangen.
Markus M. schrieb: > Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich > zurück mit Falschaussagen Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt gezeigt wurde nicht geschlagen und ist nicht zu schlagen. Höchstens in gewissen Wunschfantasien ;-) Speziell Dein Beitrag dazu war bislang überschaubar und fachlich: nicht vorhanden. Yalu X. schrieb: > In C muss man für so etwas nicht bis zum finalen Schritt warten, weil > mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher > Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit > verbunden ist. Auch ohne "finale Schritte" bleibt Asm Code effizienter. Wenn großartige Datenstrukturen zu optimieren, also mit umfangreichen, verschiedenen Datenmengen umzugehen wäre dann mag die Welt anders ausschauen. Karl H. schrieb: > Yalu X. schrieb: > > größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal > in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler > keine Vorteile bietet. Anders als in Assembler hat man aber in C die > Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger > zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von > 8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder > 12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden. > > Nicht nur das. Ich habe auch die Möglichkeit, schnell und einfach die > komplette Datenorganisation zu ändern, wenn sich im Laufe der Zeit die > Anforderungen ändern oder erweitert werden muss. In Assembler artet so > ein Unterfangen regelmässig in einen mittleren Albtraum aus. Und ja, ich > weiss durchaus wovon ich da spreche, hab ich schon gemacht - würde ich > nie wieder tun. Diese Möglichkeiten sind ja schön und gut- aber s.o.
Moby A. schrieb: > Markus M. schrieb: >> Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich >> zurück mit Falschaussagen > > Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt > gezeigt wurde nicht geschlagen und ist nicht zu schlagen. Das ist wieder eine glatte Lüge/Falschaussage:
1 | Mobys Asm-Code Yalus C-Code |
2 | ————————————————————————————————————————————————— |
3 | Flash-Verbrauch 266 256 |
4 | RAM-Verbrauch¹ 6 + 1 GPIOR 9 |
5 | Stack-Verbrauch 2 4 |
6 | Quellcodezeilen² 143 91 |
7 | Quellcodezeichen³ 1614 1707 |
8 | ————————————————————————————————————————————————— |
9 | ¹) ohne Stack |
10 | ²) ohne Leer- und Kommentarzeilen |
11 | ³) ohne Kommentare, Leerraum und Zeilenvorschübe |
12 | |
13 | Compiler: GCC 4.7.4 |
14 | Assembler/Linker: Binutils 2.25.1 |
15 | C-Standardbibliothek: AVR-Libc 1.8.1 |
Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code braucht weniger RAM und weniger Codezeichen.
Matthias L. schrieb: > Karl H. schrieb: > wenn sich im Laufe der Zeit die > Anforderungen ändern oder erweitert werden > > Du hast vorher nur nicht genügend Vorbereitung Planung und Übung > gemacht. Da ist was dran. Zumindest bei Projekten < 10K ;-) Frank M. schrieb: > - Moby sagt: "Nee, habe ich keine Lust, weil ichs nicht brauche". Genau da liegt der Fehler in Deinem Szenario: Wenn Moby wie die C-Sturköpfe hier darauf besteht, daß sein Code sparender wär und für sich ein KnowHow wie manche hier in Anspruch nimmt wird er sich gefälligst auf den Hosenboden setzen und es beweisen. Ansonsten sieht er seine Thesen selbstverständlich nicht für bewiesen an. Genauso schauts hier aus: Aussage gegen Aussage. Frank M. schrieb: > Ich kann Dir hunderte von C-Programmen hier präsentieren, wo Du > überhaupt nicht in der Lage wärest, diese in ASM nachzugrogrammieren. Programme aus dem hinlänglich umrissenen Einsatzbereich lassen sich jederzeit besser in Asm coden. Umgekehrt könnte ich Dir viele Asm-Programme präsentieren. Aber Du scheiterst ja mit Deinem Anspruch auch schon an meinen kleinsten "Projektchen" ;-) > Aber nur um zu sagen: "C ist besser als ASM"? Bestimmt nicht. Weil diese > Argumentation Schwachsinn ist. Stimmt. Allgemein "C ist besser als Asm" wäre Schwachsinn. Bei 8-Bit MSR (ohne große Berechnungen und Datenmengen) ist Asm besser. Dabei bleibt es. Wer anderes behauptet darf das tun, wer mich aber wiederlegen will kommt an der C-Codierung meiner entsprechend optimierten Beispiele nicht vorbei!
P. M. schrieb: > Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code > braucht weniger RAM und weniger Codezeichen. Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu halten ist hatte ich weiter oben bereits das Nötige gesagt. Karl H. schrieb: > Eigentlich nicht. Yalu hat mich da wieder auf ein paar Ideen gebracht, > wie man den Compiler für seine Sensorboard Aufgabenstellung mit dem > kruden Übertragungformat zu seinem Nutzen einspannen könnte. Na dann mal los. Mal sehen was für ein leichtverständlicher Code dabei rauskommt ;-) > Nur hab ich deswegen keine Lust dazu Ach sooo... Wird nun wohl doch nix ;-( Na ja so ein Vollzeit-Forumsmensch hat auch wenig Zeit. Verstehe ich. Dann sollte man sich mit kruden Thesen zur C-Überlegenheit aber zumindest etwas zurückhalten bzw. sie nicht für bewiesen erklären.
:
Bearbeitet durch User
Moby A. schrieb: > Genau da liegt der Fehler in Deinem Szenario: Wenn Moby wie die > C-Sturköpfe hier darauf besteht, daß sein Code sparender wär und für > sich ein KnowHow wie manche hier in Anspruch nimmt wird er sich > gefälligst auf den Hosenboden setzen und es beweisen. Ansonsten sieht > er seine Thesen selbstverständlich nicht für bewiesen an. Genauso > schauts hier aus: Aussage gegen Aussage. Ich brauche also hier nur ein C-Programm zu posten mit 1KB Binärcode und dann darf ich behaupten, dass C besser ist als ASM und Du würdest dann versuchen, es in ASM besser zu schaffen? Habe ich das richtig verstanden? Klasse!
Moby A. schrieb: > Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu > halten ist hatte ich weiter oben bereits das Nötige gesagt. Genau: du hast im Anschluss die von Yalu vorgelegte Lösung mal wieder als irrelevant wegdiskutiert und irgendwelche Details deiner Implementierung nachträglich zum unbedingt vorhanden sein müssenden Feature erklärt. Damit kannst du dir deine Welt natürlich irgendwie schönreden, nur glaubt dir das mittlerweile keiner mehr. Yalus Code war nun für genau die Klasse Mickymausprogramme, in denen du sonst noch deine Domäne siehst (die du gleich mal großzügig auf 10 K und mehr an Code ausdehnst), und selbst dort hat er dich in weiten Teilen (wenn auch nicht in allen) nach deinen Maßstäben schlagen können (weniger Flash, mehr RAM). Lass mal, ist ein unterhaltsamer Thread, wir wissen, dass du von deiner Meinung nicht abzubringen bist, nicht einmal durch Beweise.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Bei 8-Bit MSR > (ohne große Berechnungen und Datenmengen) ist Asm besser. Dabei bleibt > es. Nein, das ist schon für sich falsch, wie Yalu gezeigt hat - nochmals, weils so schön ist:
1 | Mobys Asm-Code Yalus C-Code |
2 | ————————————————————————————————————————————————— |
3 | Flash-Verbrauch 266 256 |
4 | RAM-Verbrauch¹ 6 + 1 GPIOR 9 |
5 | Stack-Verbrauch 2 4 |
6 | Quellcodezeilen² 143 91 |
7 | Quellcodezeichen³ 1614 1707 |
8 | ————————————————————————————————————————————————— |
9 | ¹) ohne Stack |
10 | ²) ohne Leer- und Kommentarzeilen |
11 | ³) ohne Kommentare, Leerraum und Zeilenvorschübe |
12 | |
13 | Compiler: GCC 4.7.4 |
14 | Assembler/Linker: Binutils 2.25.1 |
15 | C-Standardbibliothek: AVR-Libc 1.8.1 |
Moby A. schrieb: > P. M. schrieb: >> Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code >> braucht weniger RAM und weniger Codezeichen. > > Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu > halten ist hatte ich weiter oben bereits das Nötige gesagt. Ja, du hast viel dazu gesagt und zeigst damit gleich selbst, dass Assembler nur unter vielen, vielen Bedingungen besser ist als C. Selbst im 8-Bit-MSR-Bereich.
Moby A. schrieb: > Da handelt es sich um Code für meine SmartHome-Zentrale. > Da wird ständig erweitert, die ist niemals fertig. Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU leider nicht Codekompatibel ist. Als Workaround kann man dann auch was richtig großes nehmen und den AVR darauf komplett emulieren. Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C ?
P. M. schrieb: > Nein, das ist schon für sich falsch, wie Yalu gezeigt hat - nochmals, > weils so schön ist: Bitte jeden Tag neu posten, vielleicht liest es Moby ja mal :-)
Moby A. schrieb: > Yalu X. schrieb: >> In C muss man für so etwas nicht bis zum finalen Schritt warten, weil >> mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher >> Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit >> verbunden ist. > > Auch ohne "finale Schritte" bleibt Asm Code effizienter. Nein. Vielleicht bei einigen von dir ausgewählten Mickymausprogrammen mit speziell dafür von dir hin"optimierten" Anforderungen. Aber definitiv nicht bei deinem 10K-Programm, auf das ich mich bezog. Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler- als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat (und davon gibt es hier im Forum viele), wird dies bestätigen. Da du selbst aber nicht zu dieser Personengruppe gehörst, bleibt deine Behauptung einfach nur eine Behauptung, die du ohne jegliche Grundlage in die Welt hinausposaunst. Die Vehemenz und die Ausdauer, mit der du dies tust, ändert an dieser Tatsache nicht das geringste.
Michael K. schrieb: > Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome > Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU > leider nicht Codekompatibel ist. Ja eben. Absolute Sackgasse. Ich persönlich freue mich dass es noch etwas anderes als AVR gibt und es macht mir außerordentlichen Spaß, zu sehen, wie einfach doch (portabel geschriebene) C-Programme auf komplett andere Prozessorfamilien angepasst werden können. Mobys ASM Smarthome-Projekt ist dann einfach nur noch für die Tonne. > Als Workaround kann man dann auch was richtig großes nehmen und den AVR > darauf komplett emulieren. Ja klar, schon heutzutage kann man komplette Sinclair Spectrum Computer von 1982 mittlerweile auf einem STM32F429 Discovery für ein paar Euro emulieren. Sogar die Spiele laufen 1:1. :-) Aber da Moby ja für jedes kleine MickyMaus-Problem auch einen eigenen µC einsetzt, muss er wahrscheinlich erst Tausende von ATTinys emulieren, bis er das Licht im Wohnzimmer anschalten kann ;-) > Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C > ? Den kann sich Moby dann verkneifen.
Michael K. schrieb: > Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome > Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU > leider nicht Codekompatibel ist. Ist doch kein Problem. Aus dem Thread "CP/M auf AVR" machen wir "AVR auf ARM" oder "AVR auf JS" und die Assenbler-Sause kann weiter gehen. Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen lassen: - M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander pappen kann. - -> das ist doch der Vorwurf an Compiler. - M.: man muß am Ende eben optimieren. - M.:(2 Posts später) auch ohne Optimierung ist ASM schneller Wie er's braucht und ohne jede Scham beim Lügen. Jeman mit dem man eben nicht ein Bier trinken gehen will.
Carl D. schrieb: > Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen > lassen: > - M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander > pappen kann. > - -> das ist doch der Vorwurf an Compiler. > - M.: man muß am Ende eben optimieren. > - M.:(2 Posts später) auch ohne Optimierung ist ASM schneller Japp, genau das macht er schon den ganzen Thread hindurch. Er wechselt ständig von einem (Schein-)Argument zum nächsten. Dass diese in keinster Weise zusammen passen, hat er entweder nicht gemerkt, oder es ist ihm egal.
Yalu X. schrieb: > Vielleicht bei einigen von dir ausgewählten Mickymausprogrammen Ich schlage vor nutzlose Programme die kein RAM benutzen, keiner braucht und max. 200 bytes groß sind zu Ehren unseres AVR Spar Königs künftig MobyMausProgramme zu nennen.
Jetzt ist Schluss mit diesem unsäglichen hin und her. Jetzt kommt der Beweis: Damit nicht nur ausgwiesene Assembler-Koryphäen und C-Experten diese Codes verstehen, sondern auch Anfänger etwas mitnehmen können, habe ich ein sehr einfaches <10K-Beispiel gewählt: Eine blinkende LED, Blinkfrequenz ca. 2Hz. Die vorgegebene Hardware: Atmega88 LED sowie das übliche Vogelfutter Das C-Programm: Takt: 1MHz, intern
1 | #ifndef F_CPU
|
2 | #error F_CPU not defined.
|
3 | #endif
|
4 | |
5 | #include <avr/io.h> |
6 | #include <avr/interrupt.h> |
7 | |
8 | volatile char jobflag; |
9 | |
10 | int main(void) |
11 | {
|
12 | char count = 0; |
13 | TCCR0A = (1 << WGM01); |
14 | TCCR0B = (1 << CS02) | (1 << CS00); |
15 | TIMSK0 = (1 << OCIE0A); |
16 | OCR0A = 60; |
17 | DDRB = (1 << 1); |
18 | sei(); |
19 | while(1) |
20 | {
|
21 | if(jobflag) |
22 | {
|
23 | jobflag = 0; |
24 | count++; |
25 | count %= 4; |
26 | if(!count) PINB |= (1 << 1); |
27 | }
|
28 | }
|
29 | }
|
30 | |
31 | ISR(TIMER0_COMPA_vect) |
32 | {
|
33 | jobflag = 1; |
34 | }
|
Statistik: Resourcenverbrauch: Flash: 164 Bytes RAM: 1 Byte + Stack E²PROM 0 Register: einige Fortgeschrittene oder besser: Entwicklungszeit: <= 10 Min. Frustfaktor: keiner Kenntnisvoraussetzungen: hoch Anfänger: Entwicklungszeit: Mit Karl-Heinz' geduldiger Hilfe in einem Thread mit 93 Beiträgen(davon 17 gelöscht) und hilfreichen Tips wie "Kauf dir ein C-Buch" oder Hinweisen in Form rhetorischer Fragen wie " Hast du kein Google", dreimal der Antwort "42", einem deftigen Anschiss von c-hater und einem aufmunternden Gedicht von Paul: 1 Woche Frustfaktor zu Anfang keiner, voller Elan Freundin: stinksauer Frustfaktor: hoch Freundin: Schluss gemacht Frustfaktor: noch höher Frustfaktor: nach dem Anschiss von c-hater stark suizidgefährdet Frustfaktor: nach dem Gedicht von Paul ging das dann wieder Lernnotwendigkeit: sehr hoch Das Assembler-Programm: Takt: 16KHz, ja Kilohertz! Taktflankenschonende und stromsparende 16KHz 128KHz intern, Clockprescaler 8
1 | sbi $04,1 |
2 | sbi $03,1 |
Statistik: Resourcenverbrauch: Flash: 4 Bytes RAM: 0, kein Stack E²PROM 0 Register: 0 Fortgeschrittene: Entwicklungszeit < 1 Min. Frustfaktor keiner Kenntnisvoraussetzungen: egal Anfänger: Entwicklungszeit <= 1 Min. Frustfaktor: keiner Freundin: hat sie gar nicht mitgekriegt Frustfaktor: 0 Lernnotwendigkeit: sehr gering, da aus dem Instruction Set nur eine einzige Anweisung verwendet wird. Alle anderen Anweisungen des Atmega88 werden geschont und können später gelernt werden. Also dann, wenn man sie braucht. Resultat: Resourcenverbrauch, also das einzige, was wirklich zählt: Flash: 164 Bytes / 4 Bytes = Faktor 41 oder 4100% RAM und Register werden vom Assembler-Programm gar nicht verwendet. Das einzige, wo der C-Compiler mithalten kann, ist der E²PROM-Verbrauch. Im C-Programm steckt sicher noch Optimierungspotenzial. Das Assembler-Programm dagegen ist unoptimierbar. Das C-Programm muss für jeden anderen Controller neu kompiliert werden. Der Opcode des Asm-Programms kann auf alle Atmega und Attiny einfach so draufgeflasht werden. Einzige Voraussetzung ist, dass sie Pin-Toggle mit den PIN-Registern können. Manchmal blinken sie etwas schneller oder langsamer. Aber das läst sich hervorragend als RAM-Größen-Indikator verwenden. Das sind die Fakten. mfg.
Frank M. schrieb: > Habe ich das richtig verstanden? Klasse! Das hast Du natürlich so verstanden wie Du es brauchst. Hab ich aber nicht anders erwartet ;-) Jörg W. schrieb: > Genau: du hast im Anschluss die von Yalu vorgelegte Lösung mal wieder > als irrelevant wegdiskutiert und irgendwelche Details deiner > Implementierung nachträglich zum unbedingt vorhanden sein müssenden > Feature erklärt. Nimm einfach das zur Kenntnis was ich dazu weiter oben schon gesagt habe. Ansonsten: Warte auf den entsprechenden Projektthread. Das Thema ist nicht abgeschlossen. > Lass mal, ist ein unterhaltsamer Thread, wir wissen, dass du von deiner > Meinung nicht abzubringen bist, nicht einmal durch Beweise. Doch: Mit einer besseren Lösung als mein entsprechend optimiertes Asm-Projekt. Michael K. schrieb: > Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome > Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU > leider nicht Codekompatibel ist. Meinst Du? Das bestreite ich. Mein älteres, immer noch in Betrieb befindliches Home-Control System läuft ja schon mit einem Mega128, in verschiedenen Ausbauphasen seit 10 Jahren. Von den AVRs hab ich genügend auf Lager. Und, schonmal in den ersten 2016er Reichelt Katalog geschaut? Da gibts noch den Z80 ;-) > Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C > ? Blöd. Aber der Fall wird nicht eintreten. Yalu X. schrieb: > Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler- > als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat > (und davon gibt es hier im Forum viele), wird dies bestätigen. Wer den gleichen Funktionsumfang tatsächlich zweimal kodiert (wer würde das tun?) und den Asm-Code mit Übung, Vorbereitung und System zu optimieren weiß würde das nicht bestätigen. Die meisten aber programmieren ohnehin nur in C. Frank M. schrieb: > muss er wahrscheinlich erst Tausende von ATTinys emulieren, > bis er das Licht im Wohnzimmer anschalten kann ;-) Tatsächlich sind es drei Controller: Die M128 Hauptsteuerung kontrolliert die Stromzuführung, ein alter Xmega32 schaltet vorort zwischen Licht/Beamer Betrieb um und in der eigentlichen Lampe steckt noch ein helligkeitsgesteuerter Tiny ;-)
Moby A. schrieb: > Yalu X. schrieb: >> Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler- >> als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat >> (und davon gibt es hier im Forum viele), wird dies bestätigen. > > Wer den gleichen Funktionsumfang tatsächlich zweimal kodiert (wer > würde das tun?) und den Asm-Code mit Übung, Vorbereitung und System zu > optimieren weiß würde das nicht bestätigen. Doch.
Thomas E. schrieb: > Jetzt ist Schluss mit diesem unsäglichen hin und her. > > Jetzt kommt der Beweis: > .... Mist. Ausgerechnet heute ist die weiße Fahne in der Wäsche.
Thomas E. schrieb: > Jetzt kommt der Beweis: > ... > Das sind die Fakten. Ja ganz nett wie Du Dich den Vorteilen von Asm annäherst, wenn auch ein ganz klein wenig übertrieben ;-) Carl D. schrieb: > Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen > lassen: Was Du unfair nennst ist in Wirklichkeit nur Dein Mangel an Argumenten. Im übrigen, warum lässt Du die Diskussion nicht einfach? > - M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander > pappen kann. - -> das ist doch der Vorwurf an Compiler. Quatsch. > - M.: man muß am Ende eben optimieren. Hat niemand behauptet. > Wie er's braucht und ohne jede Scham beim Lügen. Die fehlt mir zum Beispiel bei Dir. Du wirst mich aber selbst damit nicht beirren. Kein Wunder, daß Du so keine Punkte machst und rumjammerst.
Yalu X. schrieb: > Doch. Nö. So ein Mist: Wieder Aussage gegen Aussage. Probiers nochmal mit dem überlegenen Erfahrungsschatz, einer Portion Lächerlichmachen oder auf die harte Tour: Der Vorwurf der Lüge kommt immer gut ;-(
@Moby: Mist, weil du deine letzten zwei Beiträge so schnell hintereinander gepostet hast, habe ich dein Jubiläum verpasst. Trotzdem nachträglich herzlichen Glückwunsch zu deinem
1 | 333 000 000 |
2 | 3 3 0 0 0 0 |
3 | 3 0 0 0 0 |
4 | 33 0 0 0 0 |
5 | 3 0 0 0 0 |
6 | 3 3 0 0 0 0 |
7 | 333 000 000 -sten Beitrag |
in diesem Thread :) Das muss dir erst mal jemand nachmachen. (Inzwischen sind es sogar schon 301). Spätestens bei 500 hast du ganz sicher alle hier von ASM überzeugt.
Yalu X. schrieb: > Trotzdem nachträglich herzlichen Glückwunsch. Du überrascht mich. Mit einem Glückwunsch zu irgendwelchen Beitragszahlen hab ich nicht gerechnet. Mir tuts bloß um die armen Minuspunktbewerter leid die hier soviel zu tun haben :-) Ich will Dich aber auch mal überraschen: Nämlich damit daß mir Beitragszahlen relativ schnuppe sind. Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an Effizienz gewinne... Ich geb die Hoffnung aber nicht auf ;-)
Moby A. schrieb: > wenn auch ein ganz klein wenig übertrieben Was ist denn daran übertrieben? Willst du etwa von der mangelnden Effienz in deinem Code ablenken? Ich benutze nicht einmal die Register! Und schummele auch nicht beim RAM! Und ich habe den C-Code zum Vergleich zum beigefügt! Das sind Fakten, denen nicht widersprochen werden kann. mfg.
Moby A. schrieb: > daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an > Effizienz gewinne. Das könntest du, wenn du es nur wölltest – allerdings wahrscheinlich nicht so sehr in deinem Sinne. Du würdest deine Entwicklungszeit nämlich schätzungsweise zehnteln können, und dennoch passt das alles noch ins gleiche Device rein. Davon abgesehen, mit nur wenigen Cent mehr (ATtiny25 oder 45 statt 13) bekämst du eine in vielerlei Hinsicht schönere Hardware zusätzlich zu mehr Platz geboten (wir hatten gerade erst das Thema Messung der Batteriespannung mit dem ADC ohne zusätzliche äußere Beschaltung, das geht mit dem 13 nicht, mit dem 25 schon). Da du ja dann massig Zeit gewonnen hättest, könntest du den nun gewonnenen Platz sogar mit weiteren Features beleben. :-) Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz gewiss die letzten, die dir bei entsprechenden Fragen dann nicht genauso zur Seite stehen würden, wie wir das mit jedem anderen tun. Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der gewillt ist, was zu lernen, die Sachen erklärt.
Moby A. schrieb: > ein helligkeitsgesteuerter Tiny Du hast einen helligkeitsgesteuerten Tiny? Wow! Meine sind überhaupt nicht beleuchtet. mfg.
Ich kenne nur diese „helligkeitsgesteurten“ alten sowjetischen ICs. :)
Kinder, streitet Euch doch nimmer... Mir kommt das vor wie der Streit um den Bart des Kaisers. Wie man zum Ziel kommt kann an sich ganz interessant sein, aber, mir ist es ehrlich gesagt bei normalen, im Ablauf nicht superkritischen Kriterien konformen Applikationen eigentlich ziemlich wurscht wieviel Resourcen innerhalb eines vernünftigen Rahmens verbraucht werden solange allen Erfordernissen Geltung gegeben wurde und das uC Programm die gestellten Anforderungen einwandfrei erfüllt. Bei den modernen uC braucht man doch mit den Resourcen wirklich nicht mehr soo knausrig sein. Die Computersprache wurde ja nur für den Menschen erfunden und für den Mikroprozessor sind alles was über Maschinensprache hinaus geht, sowieso nur Hieroglyphen. Es ist ja beeindruckend wenn man alles mit den internen Register erledigen kann. Aber, does anybody really care very much? Ohne Moby hier auf die Füße steigen zu wollen. Wenn dem uC von seinem Erzeuger RAM gegeben worden ist, dann soll man es ruhig verwenden. Da ich oft nur wenig Zeit habe möchte ich möglichst schnell ans Ziel kommen. In C kann ich das viel besser wie in ASM, weil ich dort eben erschreckend rostig bin und es nur in Extremfällen in inline einsetze. Um ganz ehrlich zu sein, mir liegt ASM überhaupt nicht. Abgesehen davon ist für mich die Wiederverwendung von funktionierenden Funktionen in C einfacher und die Portierung von funktionierenden Code auf andere uC viel einfacher. Trotz aller (zu Tode diskutierten) nachgesagten Mängel der Sprache kommt man doch in C praktisch meist trotzdem ganz gut zurecht. Was ist schon perfekt in dieser Welt? In C fühlt man sich immer nahe genug an der Hardware und das reicht mir. Für wirklich komplizierte Anwendungen (Stacks) müssen natürlich andere Maßstäbe angelegt werden und ist der Domain für wirkliche Experten. Letzten Endes zählt nur die Erfüllung aller gesetzten Aufgaben mit vernünftigen Aufwand. Ehrlich gesagt finde ich man sollte diesen Thread hier ganz sanft und leise einschlafen lassen. Aber wie bei uns das Sprichwort sagt: "Opinions are like as...les, everybody's got one". So belassen wir es besser bei dem gesagten... Grüße aus dem verschneiten Alberta, Gerhard
M.: > Hat niemand behauptet. Das werden aber die gefùhlt 50 Zeugen ganz anders sehen, Herr Miemand! M.: > Mich interessiert doch tatsächlich das Thema Und von der Sorte gibt's hier viele. Nur wenn man sich ernsthaft für den Vergleich interessiert, dann braucht man zwei Dinge zum vergleichen. Wer sich nur über das Funktionieren der ASM-Version freut, dem fehlt die Vergleichsgrundlage. In C ist das einfacher. Da hat man nämlich auch die ASM-Version vorliegen (ja, oh Wunder, der Compiler erzeugt ASM-Code, den dann ein Assembler verlautbar für den kleinen AVR macht) und kann schnell feststellen, ob man da händisch noch viel rausholen kann. Setzt aber Mehrsprachigkeit voraus.
Jörg W. schrieb: > Ich kenne nur diese „helligkeitsgesteurten“ alten sowjetischen ICs. Wenn man ein EPROM falsch herum in den Programmiersockel steckt und das Programmiergerät genügend Puste hat, leuchten die auch. Erst weiss, dann rot, dann schwarz. Aber ein Tiny hat ja ga kein EPROM und beheizt wird er auch nicht. mfg.
Jörg W. schrieb: > Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz > gewiss die letzten, die dir bei entsprechenden Fragen dann nicht > genauso zur Seite stehen würden, wie wir das mit jedem anderen tun. > Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der > gewillt ist, was zu lernen, die Sachen erklärt. Zumal man ihm ja eigentlich gar nicht mehr so viel erklären müsste. Die AVR Hardware kennt er ja in und auswendig. Und Hand aufs Herz. So schwer ist ein
1 | DDRD = 0xFF |
dann auch wieder nicht zu verstehen. Links steht das Ziel, rechts was in dieses Ziel hinein soll. Was rechts stehen muss, weiss er ja. Das kennt er zur Genüge. Welches Register links stehen muss, die kennt er auch alle. Nur sollte man sich von der direkten Angabe von Hex-werten gerade bei der Konfiguration von Registern trennen, auch wenn man das in C selbstverständlich genausogut machen kann. Und trennen sollte man sich auch davon, die genau Kontrolle über diese Operation auf Registerebene zu verlangen. 0xFF landet im Register DDRD. Punkt. Wie das genau funktioniert ist Sache des Compilers. Will ich gar nicht wissen. Genausowenig wie ich wissen will, ob ich dafür einen OUT oder einen STS brauche. Das der Compiler da nicht übertreibt, und aus dem ein Monster macht, sondern genau dasselbe erzeugt, was auch Assembler Programmierer benutzen würde, davon kann man sich natürlich im Listing überzeugen. Aber nach dem 20 mal überzeugen, gibt man das einfach auf. weil der Compiler immer die vernünftigste Lösung generiert hat.
:
Bearbeitet durch User
Jörg W. schrieb: > Das ist ja aber das Gegenteil von „helligkeitsgesteuert“. Ja sicher. Das ist das Steuerelement. mfg.
Thomas E. schrieb: > Das ist das Steuerelement. Nur schade, dass man es nach jedem Steuervorgang ersetzen muss. :-)
Jörg W. schrieb: > Thomas E. schrieb: >> Das ist das Steuerelement. > > Nur schade, dass man es nach jedem Steuervorgang ersetzen muss. :-) Oh, und ich dachte schon, man stellt so OTP Speicher her...
Jörg W. schrieb: > Nur schade, dass man es nach jedem Steuervorgang ersetzen muss. Ja, das ist richtig. Das hat man aber hauptsächlich als Bombenzünder benutzt. Da relativiert sich der Nachteil. mfg.
:
Bearbeitet durch User
Gerhard O. schrieb: > Oh, und ich dachte schon, man stellt so OTP Speicher her... Nein. Aber auf diese Weise kann man OTPs löschen: OTE. mfg.
Thomas E. schrieb: > Das hat man aber hauptsächlich als Bombenzünder benutzt. Mensch, jetzt hast du diesen friedlichen Thread bei allein Drei-Buchstaben-Agenturen auftauchen lassen!
Thomas, War die Geschichte von Dir mit dem EPROM vielleicht nur ein Ablenkungsmanöver?
Jörg W. schrieb: > Mensch, jetzt hast du diesen friedlichen Thread bei allein > Drei-Buchstaben-Agenturen auftauchen lassen! Ich meinte Arschbomben. mfg. Hoffentlich kam das jetzt noch rechtzeitig.
Thomas E. schrieb: > Moby A. schrieb: >> ein helligkeitsgesteuerter Tiny > > Du hast einen helligkeitsgesteuerten Tiny? Da hab' ich doch glatt was vom "heiligkeitsgesteuerten Shiny" gelesen.
Moby A. schrieb: >> Wie er's braucht und ohne jede Scham beim Lügen. > > Die fehlt mir zum Beispiel bei Dir. Hör jetzt einfach mal auf mit dem Blödsinn. Du hast keine Argumente, du gehst nicht auf Gegenargumente ein, du verdrehst Aussagen, du tischst Lügen auf. Du bist zwar mittlerweile dazu über gegangen, deinen Gegnern das selbe zu unterstellen, aber das ist einfach Quatsch. Oder hast du das Gefühl, die Diskussionsteilnehmer würden sich das gegenseitig einfach so durchgehen lassen? Warum ist hier wohl alle-gegen-einen? Weil die Sache umstritten ist? Oder doch eher, weil wir aus welchen Gründen auch immer einfach Spass an einem Fast-Troll wie dir haben?
Langsam frage ich mich wie viele flames notwendig sind diesen war den politischen gleichzusetzen und ihn zu sperren sowie Fortsetzungen zu untersagen. an Sinnlosigkeit stellt und Resuorcenverschwendung sowie Beleidigungen hält er locker mit jedem Politthread mit. Namamste
:
Bearbeitet durch User
Wir brauchen einen Ersatz für den gesperrten Witz Thread ;-)
Thomas E. schrieb: > Das sind Fakten, denen nicht widersprochen werden kann Sagen wir mal so: Dein Asm Code wirkt etwas unflexibel ;-) Jörg W. schrieb: > Du würdest deine Entwicklungszeit > nämlich schätzungsweise zehnteln können, und dennoch passt das > alles noch ins gleiche Device rein. Sicher. Siichchcher. Sagte schon Hausmeister Krause! > Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz > gewiss die letzten, die dir bei entsprechenden Fragen dann nicht > genauso zur Seite stehen würden, wie wir das mit jedem anderen tun. > Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der > gewillt ist, was zu lernen, die Sachen erklärt. Ganz hervorragend! Bitte weiter so! Kann man nicht hoch genug einschätzen! Ich selbst bin allerdings mit dem AVR, programmiert in Asm rundumst zufrieden und muß Problemstellungen nicht unbedingt komplizierter lösen als nötig. Gerhard O. schrieb: > Letzten Endes zählt nur die Erfüllung aller gesetzten Aufgaben mit > vernünftigen Aufwand. Das sehe ich auch so (mit AVR/ASM gegeben). Carl D. schrieb: > Nur wenn man sich ernsthaft für den Vergleich interessiert, dann > braucht man zwei Dinge zum vergleichen. Tatsächlich? Waren wir nicht schon soweit? Warum reite ich dann so auf der Notwendigkeit entsprechenden Vergleichsmaterials für meinen Projektcode herum? Der nicht kommt? Von den vielen großen C Experten hier für die das ein Leichtes sein könnte? > Wer sich nur über das > Funktionieren der ASM-Version freut, dem fehlt die Vergleichsgrundlage. Manchmal hat man, hab ich, auch Tomaten auf den Augen. Das betrifft aber weniger die Asm-Implementierung als vielmehr die grundsätzliche Herangehensweise an ein Problem, da wär kein Unterschied zu C. > In C ist das einfacher. Da hat man nämlich auch die ASM-Version > vorliegen (ja, oh Wunder, der Compiler erzeugt ASM-Code, den dann ein > Assembler verlautbar für den kleinen AVR macht) und kann schnell > feststellen, ob man da händisch noch viel rausholen kann. Setzt aber > Mehrsprachigkeit voraus. Wieviel Prozent der C-Programmierer dem resultierenden Asm-Code wohl noch Beachtung schenken?
Thomas E. schrieb: > Wenn man ein EPROM falsch herum in den Programmiersockel steckt und das > Programmiergerät genügend Puste hat, leuchten die auch. Erst weiss, dann > rot, dann schwarz. Aber ein Tiny hat ja ga kein EPROM und beheizt wird > er auch nicht. Logischer Fehler. Setzen. Sechs. Von Selbst-Leuchten war ja hier schon mal gar nicht die Rede ;-) Karl H. schrieb: > Und Hand aufs Herz. So schwer ist ein DDRD = 0xFF > dann auch wieder nicht zu verstehen. Das ist ja zuckersüß... Jo mei, wenn die C-Zeilen Welt immer so schön simpel wär ;-) > Genausowenig wie ich wissen will, ob ich dafür einen OUT > oder einen STS brauche. DAS will ich auch nicht. Entweder (meistens) weiß ich das sowieso und wenn nicht probiert man einfach erstmal OUT. Der Assembler meckert schon... Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr helfen... Winfried J. schrieb: > an ... Beleidigungen > hält er locker mit jedem Politthread mit. Meintest Du die Tausend Beleidigungen mir gegenüber oder meine Beleidigung der C-Fraktion, daß Asm-Code manchmal besser wär? Erstere sollte man nicht so in die Goldwaage legen. Die sind immer ein Ausdruck des 'Nicht mehr weiter Wissens' ;-) Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht ja nicht. Ich hoffe das bessert sich wieder!
Moby A. schrieb: > Wieviel Prozent der C-Programmierer dem resultierenden Asm-Code wohl > noch Beachtung schenken? Oh, den schau ich mir immer an wenn die Performance zu wünschen übrig lässt, mir die Ressourcen ausgehen oder trotz korrektem C das Kompilat einen Fehler enthält. Also eigentlich nie.
Moby A. schrieb: > Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den > Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir > mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr > helfen... "Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn helfen? Hilfst Du irgend jemandem im Forum, wenn er ein ASM-Problem hat? Ich lese hier nur selbstdarstellende Beiträge von Dir. P.S. Dir ist sowieso nicht zu helfen.
@ Moby wir beide haben zumindest gemein die Verachtung Anderer auf uns zu ziehen weil wir unseren jeweiligen Standpunkt konsequent vertreten. Deinen Standpunkt volle Programmablaufkontrolle auch die zeitliche durch direkte ASM Programmierung zu erreiche teile ich im übrigen auch. dies hat jedoch seinen Preis: Maschinennahe Programmierung erschwert die Übersichtlichkeit. Das lässt sich mit Macros zwar verbessern. Trotzdem bleibt es aufwendig. Die Effizienz des erzeugten Codes hängt im hohen Maße vom komplex logischen vermögen des Programmierers mit gleichzeitig hohem Abstraktionsvermögen ab. Hier bieten Hochsprachen Arbeitserleichterungen für den Programmierer. Zum Preis des Verstehens des vom Compiler erzeugten ASM durch den Hochsprachen Programmierer. Die Codeeffizienz eines lausigen Hochsprachenprogrammierers ist sicher noch größer als die eines mittelmäßigen ASM Fetischisten Nachdem HW heute billiger als SW-Entwicklungszeit (Programmiererlohn) ist ist ausgereizte ASM Programmierung schlicht zu teuer. Im Übrigen empfinde ich Hochsprachen bequemer und nutze sie im Bewusstsein, dass ich nicht jedes Byte kenne, welches der Compiler daraus bastelt, oder den genauen Ablauf einer Interpreterfunktion nicht kenne. Einen Blick in den erzeugten Compiler-Code oder eine Interpreterroutine ist allemal lehrreich. Namaste
Moby A. schrieb: > Ich selbst bin allerdings mit dem AVR, programmiert in Asm rundumst > zufrieden Moby A. schrieb: > Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, > daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an > Effizienz gewinne... Aha.
Moby A. schrieb: > Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, > daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an > Effizienz gewinne... Moby, da hilft nur Übung, Vorbereitung, System.
Moby A. schrieb: > Sagen wir mal so: Dein Asm Code wirkt etwas unflexibel Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken? Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich aus diesem nur einen einzigen Befehl verwende. Von der Kompaktheit des Codes und dem flankenschonenden und stromsparenden Takt ganz zu schweigen. Das Programm ist in jeder erdenklicher Weise höchstoptimiert und stellt somit Krone der Programmierkunst dar. Das ist die ideale Effizienz. Das sind die unwidersprochenen Fakten! mfg.
Und Moby macht einfach weiter, als wäre nichts gewesen. Obwohl Yalu in einem Beispiel nun wirklich UNZWEIFELHAFT nachgewiesen hat, dass man Assembler sogar bei Mini-Programmen mit C schlagen kann. Einfach nochmals, für die Nachwelt, damit nie jemand auf die Idee kommen wird, Moby's Theorien hätten auch nur ein Quäntchen Bedeutung:
1 | Mobys Asm-Code Yalus C-Code |
2 | ————————————————————————————————————————————————— |
3 | Flash-Verbrauch 266 256 |
4 | RAM-Verbrauch¹ 6 + 1 GPIOR 9 |
5 | Stack-Verbrauch 2 4 |
6 | Quellcodezeilen² 143 91 |
7 | Quellcodezeichen³ 1614 1707 |
8 | ————————————————————————————————————————————————— |
9 | ¹) ohne Stack |
10 | ²) ohne Leer- und Kommentarzeilen |
11 | ³) ohne Kommentare, Leerraum und Zeilenvorschübe |
12 | |
13 | Compiler: GCC 4.7.4 |
14 | Assembler/Linker: Binutils 2.25.1 |
15 | C-Standardbibliothek: AVR-Libc 1.8.1 |
Moby A. schrieb: > Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht > ja nicht. Wozu Gegenargumente? Haben wir hier in den letzten Tagen ein einziges Argument von Dir gesehen?
Moby A. schrieb: > Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht > ja nicht. Ich hoffe das bessert sich wieder! - Obwohl du als Hobbyist gegen eine ganze Horde an erfahrenen Profis antrittst, - obwohl ein halbes Forum deiner Einzelmeinung geschlossen widerspricht, - obwohl du keine deiner Behauptungen belegen konntest, - obwohl klare Gegenbeweise gegen deine Thesen bestehen, - obwohl du einen Teil des Diskussionsgegenstands (Programmiersprache C) nicht mal kennst, => benimmst du dich immer noch so, als wärst du im Recht und die anderen auf dem Holzweg.
P. M. schrieb: ————————————————————————————————————————————————— > Flash-Verbrauch 266 256 > RAM-Verbrauch¹ 6 + 1 GPIOR 9 > Stack-Verbrauch 2 4 > Quellcodezeilen² 143 91 > Quellcodezeichen³ 1614 1707 > ————————————————————————————————————————————————— > ¹) ohne Stack > ²) ohne Leer- und Kommentarzeilen > ³) ohne Kommentare, Leerraum und Zeilenvorschübe > > Compiler: GCC 4.7.4 > Assembler/Linker: Binutils 2.25.1 > C-Standardbibliothek: AVR-Libc 1.8.1 Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert.
le x. schrieb: > Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features > bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert. Ein echter Nachteil von C. Durch die bessere Lesbarkeit können auch untalentierte Programmierer nun guten Code schreiben was langfristig zu schlechteren Programmierern führt. (Im Sinne von ASM Verständniss) Zudem werden die Produktzyken kürzer weil gute Produkte schneller entwickelt sind. Die Menschen gewöhnen sich daran das fette Features schnell und zahlreich zu etabieren sind und schrauben ihre Erwartungshaltung ständig höher. Das wiederum ist ein echtes Ressourcen / Umweltproblem. Nur durch kurzlebige Modeerscheinungen wie Hochsprachen ist es überhaupt möglich geworden ständig neue MCUs auf den Markt zu werfen. Hardcore ASM Götter würden freiwillig nicht so schnell wechseln. Dadurch das nun viele etwas können was vorher wenigen vorbehalten war wird auch die Bezahlung schlechter. Hochsprachen sind ausserdem eine Bedrohung für Frieden und Freiheit. Weder flächendeckende Kommunikationsüberwachung, noch Gesichtserkennung, Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät wäre in der Form denkbar. Hochsprachenprogrammierer sind Diener des Bösen. Zwangsläufig wird die Gesellschaft sich davon befreien müssen indem selbige nach nordkoreanischem Vorbild umerzogen werden. Innovative deutsche Unternehmen haben das bereits erkannt und gerade noch rechtzeitig ihren Betrieb eingestellt (Addison Wessley, Data Becker) [Die heutige Bücherverbrennung wird Ihnen präsentiert von: O'Reilly)
Michael K. schrieb: > le x. schrieb: > Ein echter Nachteil von C. > Durch die bessere Lesbarkeit können auch untalentierte Programmierer nun > guten Code schreiben was langfristig zu schlechteren Programmierern > führt. > [...] > Das wiederum ist ein echtes Ressourcen / Umweltproblem. > [...] > Hochsprachen sind ausserdem eine Bedrohung für Frieden und Freiheit. > Weder flächendeckende Kommunikationsüberwachung, noch Gesichtserkennung, > Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät > wäre in der Form denkbar. > [...] Rettet die Welt, Programmiert ASM :^)
Michael K. schrieb: > Dadurch das nun viele etwas können was vorher wenigen vorbehalten war > wird auch die Bezahlung schlechter. Zum Glück trifft das nicht auf die echten ASM-only-Programmierer zu. Diese Helden, die sich ihren Fokus nicht durch die Verlockungen der Hochsprachen-Sirenen haben verwässern lassen, sind heute in der Industrie gefragte Experten, die locker mit dem Doppelten eines Durchschnittsgehalts rechnen dürfen. Gruß, Stefan
Michael K. schrieb: > Zudem werden die Produktzyken kürzer weil gute Produkte schneller > entwickelt sind. Eben. In Assembler programmiert würde Microsoft nicht immer wieder die Benutzeroberfläche auf den Kopf stellen und die Hälfte aller Knöpfe neu verteilen. Es wäre eine Wohltat für viele Anwender. ;-)
:
Bearbeitet durch User
Stefan K. schrieb: > sind heute in der > Industrie gefragte Experten, die locker mit dem Doppelten eines > Durchschnittsgehalts rechnen dürfen. Dafür aber die 10-fache Entwicklungszeit benötigen und somit locker das zwanzigfache pro Programm verdienen. Asm-Effizienz in höchster Vollendung. mfg.
A. K. schrieb: > Eben. In Assembler programmiert würde Microsoft nicht immer wieder die > Benutzeroberfläche auf den Kopf stellen und die Hälfte aller Knöpfe neu > verteilen. Es wäre eine Wohltat für viele Anwender. ;-) Womit wir uns auch mal um den Blödsinn der hochauflösenden Farbmonitore kümmern sollten. Eingabefelder und Schieberegler sind seit Win 10 bei meinem billigst Notebook fast nicht zu erkennen. So ein Problem hatte ich auf meinem C64 mit dem Bernsteinmonitor nie. Dieser ganze neumodische Schnickschnack hat doch mit diesem Tesla angefangen und seiner Schnapsidee alle Haushalte zu bestromen. Seit dem nur noch Hektik, Zeitdruck und arbeiten bis spät in die Nacht. Probleme lösen die wir ohne Computer garnicht hätten. Vorher: Rentervorsorge? Ich bitte Dich, bei der Lebenserwartung ? Schlafen wenn die Sonne untergeht, aufstehn wenn der Hahn kräht. Moby hat das zugrunde liegende Problem gut erkannt, er setzt nur viel zu spät an. Die Kontrolle hätten wir behalten wenn wir nie von den Bäumen runtergekommen wären. Ach was sage ich da, der Molch war doch in unserer Evolution die glücklichste aller Daseinsformen. Kein Stress und zu blöd sich Sorgen darum zu machen das man gefressen werden könnte. Ressourcenverbrauch ? Da schneidet der Molch aber um Welten besser ab. Wenn ich sehe was wir mit unserm ach so tollen Gehirn anstellen das weit überdurchschnittlich viel Energie verbraucht, so ist dieser Thread das beste Beispiel dafür das der Molch uns da klar überlegen ist.
Frank M. schrieb: > Moby A. schrieb: >> Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den >> Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir >> mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr >> helfen... > > "Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn > helfen? Hilfst Du irgend jemandem im Forum, wenn er ein ASM-Problem > hat? Das wiederrum ist interessanterweise eine Eigenschaft, die er mit den restlichen Assembler-über-alles Verfechtern teilt. Wenn es um ein Assembler Problem geht, glänzen sie so gut wie fast immer .... durch Abwesenheit.
le x. schrieb: > Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features > bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert. @P.M.: Kannst du das bitte in das täglich zu wiederholende Posting (Murmeltier) mit aufnehmen? Danke.
Michael K. schrieb: > Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät > wäre in der Form denkbar. Der erste Marschflugkörper kam völlig ohne Programm aus. Der hatte keinen einzigen Transistor drin, vielleicht nicht einmal Röhren.
:
Bearbeitet durch User
A. K. schrieb: > vielleicht nicht einmal Röhren. oh doch der wurde über einen Funkleitstrahl analog auf Kurs gehalten https://de.wikipedia.org/wiki/Präzisionsgelenkte_Munition#Flugbahnlenkung besser noch hier https://de.wikipedia.org/wiki/Fieseler_Fi_103#Zielf.C3.BChrung auch interessant in diesem zusammenhang https://de.wikipedia.org/wiki/Fritz_X Namaste
:
Bearbeitet durch User
Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden. A.K. ist vom Glauben abgefallen: Beitrag "Re: Eigenes Dev. Board für vintage CPU bauen" A. K. schrieb: > Ausserdem kann man beim 1802 leichter als irgendwo sonst auf total > überflüssige Hochsprachen wie Makro-Assembler verzichten und direkt in > Hex programmieren. Liest sich in kurzer Zeit fast genauso gut wie > normaler Assembler. A.K. es ist noch nicht zu spät. Kehre zurück auf den Pfad der Tugend und schwöre ab den falschen Propheten.
Michael K. schrieb: > Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden. > A.K. ist vom Glauben abgefallen: Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-)
Frank M. schrieb: > Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der > Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht > flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-) Ging mir ähnlich beim 6502: Der Apple hatte in seinem Monitor-ROM zwar einen einfachen Disassembler, aber keinen Assembler. Bei typischen 8-Bit-Anwendungen tippte man deswegen das Programm einfach als Hexcodes ein und überprüfte anschließend deren Richtigkeit mit dem Disassembler. Innerhalb kurzer Zeit kannte ich die Hexcodes für 90% der Befehle auswendig, den selten genutzten Rest¹ musste ich halt nachschlagen. Da ich irgendwann aber auch nichttypische 8-Bit-Anwendungen (d.h. mit mehr als 200 Bytes) programmieren wollte, kaufte mir dann aber doch einen Assembler. Selbst die komplizierteren 16-Bit-Opcodes des 68000 konnte man sich gut merken, da sie größtenteils nach einem einheitlichen Schema aufgebaut sind. Da die Quell- und Zieladdressierungsart und -register von rechts her jeweils als 3-Bit-Gruppen kodiert sind, nutzte man statt der hexadezimalen die oktale Schreibweise. Auch damit hatte ich einige Progrämmchen geschrieben, die ich aber nicht als "typische 16-Bit- Anwendungen" bezeichnen würde ;-) ———————————— ¹) Nein, Moby, der EOR-Befehl zählte nicht zu diesem Rest, der war unter den 90% häufig genutzten Befehlen ;-)
Frank M. schrieb: > Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der > Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht > flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-) Ist aber bei 8080-Code einfacher als bei optimiertem Z80-Code. Die Rechnerei der relativen Sprünge ist ziemlich umständlich. Das ist das schöne am 1802, der hat zwar kurze Sprünge, aber ohne umständliche Rechnung. Da wird bloss das untere Byte der Programmadresse ersetzt. Gegenüber der Oktalcodierung von 8080 besteht zudem der Vorteil, dass etliche Befehle hexcodiert aufgebaut sind. Also 4-Bit Opcode und 4-Bit Registernummer. Einfacher gehts nicht.
:
Bearbeitet durch User
A. K. schrieb: > Die Rechnerei der relativen Sprünge ist ziemlich umständlich. Das stimmt, aber die absoluten des 8080 gab's ja trotzdem noch, insofern erstmal kein Nachteil. Habe aber inzwischen fast alle vergessen. Kann mich nur noch an AF und 21 xx xx erinnern. ;)
Einen kleinen Nachteil der Hex-Programmierung des 1802 muss ich aber noch erwähnen: Nirgends hat man so viel Sex wie in 1802 Assembler Programmierung. In Hex verschwindet der völlig aus den Augen. http://www.atarimagazines.com/computeii/issue3/page52.php
:
Bearbeitet durch User
Karl H. schrieb: > Und Hand aufs Herz. So schwer ist ein DDRD = 0xFF > dann auch wieder nicht zu verstehen. Hmmm lass mal überlegen... Moby A. schrieb: > Das ist kryptischer Kauderwelsch für Eingeweihte. > Dessen Studium ist für 8-Bit MSR überflüssig ;-)
le x. schrieb: > P. M. schrieb: > ————————————————————————————————————————————————— >> Flash-Verbrauch 266 256 >> RAM-Verbrauch¹ 6 + 1 GPIOR 9 >> Stack-Verbrauch 2 4 >> Quellcodezeilen² 143 91 >> Quellcodezeichen³ 1614 1707 >> ————————————————————————————————————————————————— > > Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features > bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert. Schon erstaunlich was man aus -10 Bytes alles herausholen kann ;-)
Frank M. schrieb: > Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der > Opcodes als Hex-Zahlen erstellt. Na gut, dann muß ich beichten das ich das beim 8085 ebenso gemacht habe. Man hatte ja keinen Vergleich und hat sich deswegen über jeden Befehl gefreut der ausgeführt wurde. Aus heutiger Sicht so spannend wie Lack beim trocknen zuzusehen. Der 8031 war dagegen wie Balsam auf meine wunde Seele. Timer, Ram, Uart alles in einem Chip. Nur noch Eprom und A/D Latch ran und es lief (naja + ein paar Bauteile) Das war so schön, ich hätte weinen können. Der 8751 war mein größter Schatz und sein Gewicht in Gold wert. 4K on Chip ! Der brutale Wahnsinn. Der 8085 endete quasi sofort als Türstopper. Heute empfinde ich das als Zumutung wenn ich mehr als 30Cent ausgeben muß für so eine kleine Gurke und dann auch noch mehr brauche als zwei Kerkos um damit was zu machen. Flash, ISP, OCD sind so selbstverständlich das ich erst solche Threads brauche um mich an all die Klimmzüge und Leiden zu erinnern die damals selbstverständlich waren. Warum man die Hardwaresegnungen der 'neuen Zeit' mitnimmt aber sich softwaremäßig (ASM) nicht weiterentwickelt kann ich persönlich nicht nachvollziehen.
Frank M. schrieb: > Michael K. schrieb: >> Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden. >> A.K. ist vom Glauben abgefallen: > > Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der > Opcodes als Hex-Zahlen erstellt. Was seid ihr denn für Wappler? :-) Mein erster Z80 Eigenbau bekam sein erstes Programm
1 | 0xxxxx 0x76 HALT |
indem ich mit Drahtbrücken im EEPROM Sockel den Befehl direkt am Datenbus gesteckt habe. Der Chip Select Adressdecoder war noch nicht fertig :-) Ich war stolz wie nachbars Lumpi, als das (geschenkte) Phillips Voltmeter am Halt Pin den Zeiger nicht bewegte, während es bei einem gesteckten
1 | 0xxxxx 0x00 NOP |
brav mit einem Ausschlag die 5V vermeldete. > Mit ein wenig Übung geht das recht > flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-) Ja doch das ging schon. Das einzige bei dem ich am Anfang immer Probleme hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie?
:
Bearbeitet durch User
Michael K. schrieb: > Heute empfinde ich das als Zumutung wenn ich mehr als 30Cent ausgeben > muß für so eine kleine Gurke und dann auch noch mehr brauche als zwei > Kerkos um damit was zu machen. Vor allen Dingen kein potentes Netzteil mehr :-) Mit einem nackten Z80, bisschen Kleinkram rundum und eben das übliche (EPROM, RAM, 8255, 8251), war man mit einem 1A Netzteil auf der 5V Schiene nicht wirklich krass überdimensioniert. :-)
:
Bearbeitet durch User
Karl H. schrieb: > 0x0000 0x76 HALT Muss das nicht
1 | 0000H 076H HALT |
heißen? ;-) Nein, einen EPROM hatte ich schon zu Anfang. Allerdings natürlich keinen LA, mit dem man die Verdrahtungsfehler hätte suchen können, nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und Adressbus). Zum schrittweisen Durchschalten hab' ich mir dann eine kleine Hardwaremimik gezimmert, die nach je einem Befehl immer wieder /WAIT gezogen hat. Nach ein oder zwei Stunden war dann der Kurzschluss auf einem der Busse gefunden. Das Lösen des Henne-und-Ei-Problems für die ersten EPROMs benötigte allerdings einen in Hardware gezimmerten Eprommer. Wehe dem, man hatte sich bei einem der Bytes beim Eingeben vertan, dann musste man von vorn anfangen. Computergesteuerten Eprommer habe ich dann erst später gebaut. Passend zum Thema des Threads: dessen Bediensoftware wurde in Turbo-Pascal geschrieben. Dadurch ließ sich doch einiges an Bedien-Komfort mit vertretbarem Aufwand erreichen, was ich mir hätte bei reiner Assemblerprogrammierung nicht antun wollen. Nur die innerste Schleife habe ich nach dem initialen Funktionstest dann in Inline-Assembler nachprogrammiert, damit er schnell genug wurde.
Karl H. schrieb: > Was seid ihr denn für Wappler? :-) Moment ..... https://de.wiktionary.org/wiki/Wappler Aha ! Karl H. schrieb: > Das einzige bei dem ich am Anfang immer Probleme > hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie? Da hilft nur: Übung, Vorbereitung, System
Jörg W. schrieb: > Karl H. schrieb: >> 0x0000 0x76 HALT > > Muss das nicht > >
1 | 0000H 076H HALT |
> > heißen? ;-) Mea Culpa. Da hat wohl die C-Bürokratie die Oberhand gewonnen. > Nein, einen EPROM hatte ich schon zu Anfang. Allerdings natürlich > keinen LA, War ja auch unbezahlbar für einen Studenten. Die 100 Mark wurden lieber in ein paar kB Speicher investiert. > mit dem man die Verdrahtungsfehler hätte suchen können, > nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und > Adressbus). Nobel. Ich hatte Glück. Meinen Z80 konnte ich mit einer LED (und einem Durchgangsprüfer, gebaut aus einem alten Texas Instruments Akkufach + LED + 220 Ohm + Draht) in Betrieb nehmen und verifizieren, dass er funktioniert. > Das Lösen des Henne-und-Ei-Problems für die ersten EPROMs benötigte > allerdings einen in Hardware gezimmerten Eprommer. :-) Das war ein echtes Problem. In der mc gab es einen Eprommer, der im Prinzip nur ein Schieberegister war. An sich super. Nur, wie ansteuern, wenn der Rechner noch nicht läuft. Ein Kumpel mit einem TRS80 hat mir dann aus der Patsche geholfen. > erst später gebaut. Passend zum Thema des Threads: dessen > Bediensoftware wurde in Turbo-Pascal geschrieben. Das hatte wohl jeder. D.h. sofern er sich ein Floppy Laufwerk leisten konnte und unter der Hand ein CP/M irgendwo herbekam :-)
Karl H. schrieb: > D.h. sofern er sich ein Floppy Laufwerk leisten konnte Welch ein Luxus. Dump über die serielle Schnittstelle auf ein 1200er Modem und die frequenzmodulierten Daten mit einem Kassettenrekorder aufgezeichnet. Das war cool. mfg.
:
Bearbeitet durch User
Karl H. schrieb: > Mea Culpa. Da hat wohl die C-Bürokratie die Oberhand gewonnen. Ja, da kannst du sehen, wohin diese Bürokratie noch führt! >> nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und >> Adressbus). > > Nobel. Die Anzeigebaugruppe wurde auch am Primitiv-Eprommer genutzt. Sie bestand aus einer VQD30: http://www.pollin.de/shop/dt/MDY3OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LED_Display_VQD30.html einem BCD-7-Segment-Decoder (U40511, der hat auch die Hex-Zahlen korrekt angezeigt) und Multiplexern, mit denen reihum die Busse abgefragt wurden. >> erst später gebaut. Passend zum Thema des Threads: dessen >> Bediensoftware wurde in Turbo-Pascal geschrieben. > > Das hatte wohl jeder. D.h. sofern er sich ein Floppy Laufwerk leisten > konnte und unter der Hand ein CP/M irgendwo herbekam :-) Naja, Software war in der DDR kein Problem :), die wurde ja auch ganz offiziell von robotron als Clone vertrieben. Beliebt war die CP/A genannte Version des Instituts für Informatik an der Akademie der Wissenschaften. Irgendwoher bekam man da auch ein Turbo-Pasal, auf welchen Wegen die genau von Diskette zu Diskette gefunden haben, hat damals hier keinen interessiert … Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB), sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte.
Jörg W. schrieb: > Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB), > sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte. Krösus :-) Ich hatte mir als Österreicher in München 2 Floppy Laufwerke erstanden. Haben ein Schweine-Geld gekostet. Da kriegst heute einen ganzen PC drum, und dann bleibt noch was übrig. Mann war ich sauer, als mir beim Basteln das Krokoklemmenkabel abgeschnippt ist. Blöderweise war es die GND-Leitung und das freie Ende fiel auf die 230V Phase. Und vorbei wars mit den Laufwerken ... und dem VT100 ... und überhaupt dem meisten in der als Gehäuse benutzen Holzkiste. Eines der Laufwerke konnte ich noch retten, in dem ich auf einem defekten IC (war irgendeine Gatter-Sache) einen weiteren IC huckepack aufgeklebt und mit Fädeldraht angeschlossen habe. Aber das 2.te machte keinen Mucks mehr. :-) Und ich brings trotzdem nicht übers Herz, den 30 Jahre alten Krempel zu entsorgen. :-)
:
Bearbeitet durch User
Karl H. schrieb: > Und ich brings trotzdem nicht übers Herz, den 30 Jahre alten Krempel zu > entsorgen. Moby auch nicht ;-)
Thomas E. schrieb: > Karl H. schrieb: >> D.h. sofern er sich ein Floppy Laufwerk leisten konnte > > Welch ein Luxus. > > Dump über die serielle Schnittstelle auf ein 1200er Modem und die > frequenzmodulierten Daten mit einem Kassettenrekorder aufgezeichnet. > Das war cool. Das war auch schon so ziemlich das einzige, was ich nie gemacht habe. Hätte mit meinem 300 Baud Eigenbau Akustikkoppler auch nicht so wahnsinnig toll funktioniert. Obwohl - wieso hab ich das eigentlich nie ausprobiert?
Karl H. schrieb: >> Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB), >> sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte. > > Krösus :-) Zusammengestoppelt. Schließlich kamen die Dinger initial aus dem ZMD in Dresden ;), es sind noch welche dabei, die nicht mit dem später offiziellen Etikett „U2164“ versehen sind, sondern „U264“. Es sind aber auch auf der zweiten Platine offizielle Erfurter ICs drauf, die es dann später preiswert als so genannte Bastlerware (2. Wahl) gab. Aufgrund der vielen völlig verschiedenen Bauteile funktionierten allerdings die „gängigen“ RAS-CAS-Ansteuerschaltungen auf der Basis irgendwelcher Gatterlaufzeiten nicht bei diesem Mix. Ich bin erst glücklich geworden, als ich einen definierten RAS-CAS-Versatz mit dem vierfachen CPU-Takt (der zugleich Videotakt war) und einem Schieberegister eingebaut hatte. Danach liefen die dRAMs stabil. Das Desaster mit dem runtergefallen Kabel ist natürlich tragisch. In solch trauriger Dimension ist es mir zum Glück erspart geblieben.
Thomas E. schrieb: > Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken? > > Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich > aus diesem nur einen einzigen Befehl verwende. Von der Kompaktheit des > Codes und dem flankenschonenden und stromsparenden Takt ganz zu > schweigen. > > Das Programm ist in jeder erdenklicher Weise höchstoptimiert und stellt > somit Krone der Programmierkunst dar. > > Das ist die ideale Effizienz. Das sind die unwidersprochenen Fakten! Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können. Damit hättest Du sogar den Mikrocontroller gespart!
Sheeva P. schrieb: > Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier > Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können. > Damit hättest Du sogar den Mikrocontroller gespart! ist aber nicht 8Bit MSR konform.
Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch kaum möglich...?
P. M. schrieb: > Was hat man denn damals mit den Computern gemacht? Programmierung. Turbo-Pascal wurde ja schon genannt, da gab's dann auch schon Dinge wie Knotenspannungsanalyse (hab' ich aber nie bis zu Ende getippt). Datenbanken (dBase). Textverarbeitung (WordStar, damit habe ich bspw. meine Diplomarbeit geschrieben, natürlich nur den Text, Bilder musste man einkleben). Spiele (die berühmte Mondlandung, Ladder ist auch berühmt, wir hatten hier noch UFO, weiß aber nicht mehr, wer das programmiert hatte). Also eigentlich nichts anderes als heute auch. :-)
Sheeva P. schrieb: > Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier > Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können. > Damit hättest Du sogar den Mikrocontroller gespart! Dann könnte man auch konsequenterweise eine blinkende LED nehmen. Aber es geht hier schliesslich um Controller-Programmierung. mfg.
Privat habe ich mit einem Atari 64XL begonnen nach dem ich hinreichend mit Ataribasic und 6502 Assembler vertraut war programmierte ich eine Minitextverarbeitung (64 zeichen pro zeile) mit 4 DIN A4 Seiten Textspeicher den ich wahlweise über den Matrixdrucker oder die S3004 Ausgeben konnte. Das war das Werkzeug für mein EX Frau um in Heimarbeit für den Funkbummi Handgeschreibene Manuskripte für den Lektor lesbar zu gestalten. Für mich war es Fingerübung und Lernobjekt das ich bis heute nicht missen möchte. zuvor gab es fürmich nur Schwimmalle aka Lehrcomputer und Tischrechner sowie den Specki meines Schwagers zum Trainingsschwimmen und verstehen. Die 6502 Atarikiste kenne ich heute innen in HW auswendig in SW benötige ich immer wieder einen Blick in die Bibel des ROMS. Hatte für mich den Vorteil, dass ich früh verschieden HW und Prozessor- Rechnerkonzepte kennelernte. Und ich konnte sofort loslegen. Von so etwas trennt man sich nicht freiwillig. ;) Namaste
Gibts die blinkende LED nicht auch als Bausatz bei Conrad oder so was? Dann braucht man mit dem AVR nur die Masseleitung verbinden, gar nichts programmieren und hat maximal darauf Resourcen gespart. Flash: 0 RAM: 0 Ist ja nicht schlimm, kompliziertes extern zuzukaufen...
Jörg W. schrieb: > Also eigentlich nichts anderes als heute auch. :-) Du hast Tetris und Meniacs vergessen. Die sehen heute anders aus, folgen aber immer noch dem gleichen Konzept. Namaste
P. M. schrieb: > Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den > Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch > kaum möglich...? Natürlich war damit auch damals schon das möglich, was auch heute noch die Kerndinge auf einem PC sein dürften. Textverarbeitung, Tabellenkalkulation, ein paar Spiele. nur war das ganze halt nicht grafisch so aufgepeppt wie das heute ist. Ein Text war einfach nur ein Text. ASCII. Fonts brauchte keiner. Wenn der Drucker (Nadeldrucker) ein paar Fonts hatte, schön. Wenn nicht, dann eben nicht. Zum Unterstreichen reicht auch eine Reihe '=' in der nächsten Zeile, etc. etc.
:
Bearbeitet durch User
Klaus W. schrieb: > Ist ja nicht schlimm, kompliziertes extern zuzukaufen... Mache ich normalerweise auch so. Aber ich hatte bei diesem Projekt die ultimative Herausforderung gesucht. mfg.
Jörg W. schrieb: > Spiele (die berühmte Mondlandung, Ladder ist auch berühmt, wir hatten > hier noch UFO, weiß aber nicht mehr, wer das programmiert hatte). Da sag ich nur Moriaaaaaaa Und dann natürlich das Adventure (The Hall of the Mountain King, obwohl das hies nicht wirklich so)
Karl H. schrieb: > Und dann natürlich das Adventure (The Hall of the Mountain King, obwohl > das hies nicht wirklich so) Das hies offiziell 'Colosal Cave' und so sah das aus: https://de.wikipedia.org/wiki/Adventure_(1976)#/media/File:Colossal_Cave_Adventure_on_VT100_terminal.jpg (oder was glaubst du, warum wir plötzlich einen Wahnsinnsschub in unseren Englisch Kentnissen hatten :-)
:
Bearbeitet durch User
Jörg W. schrieb: > Also eigentlich nichts anderes als heute auch. :-) Also eigentlich alles das wofür es heute ein Raspi mit Linux und 512MB sein muß. In 20 Jahren wird man Dich Fragen was man mit diesen Dinosauriern mit weniger als 12TB Ram und ohne 1024 Kerne überhaupt machen konnte. Schau Dir mal an was auf einem MOS6510 mit 64K und ein paar Spezialchips für Sachen liefen (C64). Das ist es was Moby immer wieder den Auftrieb gibt weil ein paar von Euch denken das IT erst mit den jungen Göttern der heutigen Hochschulausbildung angefangen hat. Die ersten die Computer, Programmiersprachen und Algorithmen erfunden haben und den Grundstein heutiger Hochschulausbildung gelegt haben waren allesamt keine studierten Informatiker. Die haben sich aus dem nichts all das überlegt, nur mit Bleistift, Papier und ihrem Gehirn. Du arbeitest mit dem was du hast. Klar das heute ein Raspi mit Python vieles einfach erschlagen kann. Ein 8085 mit 7seg. Anzeige hätte das aber meist auch gekonnt, nur nicht so bunt. Der 8085 hatte auch garkein Problem ms genaues Timing zu machen, der Raspi braucht dafür einen Arduino angeflanscht. Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung und die Housekeeping Aufgaben des OS und wieviel davon harte Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir vorstellen was möglich ist wenn man low level nur noch Kernfunktionalität programmiert. Nur weil es heute kompfortabler geht bedeutet das nicht das wir damals geduldig LEDs haben blinken lassen bis die 'richtigen' Computer kamen. Nein, es kamen Leute wie Wozniak und haben mit dem 'Spielkram' Geräte gebaut die ein Firmenimperium begründet haben.
Ich geb dir vollinhaltlich recht. Und trotzdem fahre ich doch lieber mit einem heutigen Auto als mit einem Ford Model T. Auch wenn man mit dem genauso von A nach B kommt. Das Problem hast du überall. Die Weiterentwicklung bleibt nicht stehen. Als die ersten graphischen Aufsätze aufkamen, GEM und dann natürlich der Vater aller graphischen Computer - der originale Macintosh - haben auch viele die Nase gerümpft und gesagt "was brauch ich den Scheiss". Und Hand aufs Herz: wenn jemand mit einer Command Line umgehen konnte, war er damit um Größenordnugen schneller als die ersten Mausschubser. Trotzdem haben diese graphischen Systeme den Weg zur Massenverbreitung geebnet, welche wiederrum Voraussetzung für den massiven Preissturz waren. Du weisst nie, wohin eine Entwicklung eines Tages hinführen wird.
:
Bearbeitet durch User
Karl H. schrieb: > Du weisst nie, wohin eine Entwicklung eines Tages hinführen wird. Doch das ist sicher es führt ins Nichts wenn es nicht zu Gott führt. Namaste
P. M. schrieb: > Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den > Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch > kaum möglich...? Beispielsweise den Gang von Uhren gemessen. Je nach Typ mit Mikrofon oder Lichtschranke als Sensor. Auf BASIC-Rechnern vergleichbar Apple II hatten 2 Jungs um 1981 herum in der Schule ein Programm für Zeugnisauswertung und -druck geschrieben. Und ja, darunter auch das eigene. ;-)
:
Bearbeitet durch User
Für Leute die sich extrem schwer mit C tun, hier ein kleiner Einstieg... Hier sind alle C Befehle und deren Syntax wie man die verwendet aufgeschrieben und in deutsch leicht verständlich beschrieben: http://www.utd.hs-rm.de/prof/hoch/download/cQuick.pdf Nur Seite 7: "4. Ein- und Ausgabe" gibt es für den µC nicht, bzw. wird dort nicht benötigt/verwendet. Sollte mehr Interesse vorhanden sein, so liefert Google zu jedem Befehl mehr Details und Beispiele.
:
Bearbeitet durch User
Michael K. schrieb: > Also eigentlich nie. Sag ich ja. Vorab wird natürlich für jedes Projekt hardwaremäßig großzügig dimensioniert ;-) Frank M. schrieb: > "Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn > helfen? Wieder typisch Frank M. Versteht wie er's gerade braucht. Mensch ich werd doch nicht nach Hilfe suchen für etwas, von dessen Unmöglichkeit ich überzeugt bin... Doch wär es immer noch sinnvoller, mich mit einer C-Version meines Projekts überzeugen zu "helfen" als mich wochenlang mit allem möglichen, mehr oder weniger großen Unsinn zu traktieren. Doch traut sich das niemand. Aus gutem Grund natürlich. Jörg W. schrieb: > Moby A. schrieb: >> Ich selbst bin allerdings mit dem AVR, programmiert in Asm rundumst >> zufrieden > > Moby A. schrieb: >> Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, >> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an >> Effizienz gewinne... > > Aha. Ja- ich kann auch auf die ironische Art ;-)
Michael K. schrieb: > Moby A. schrieb: >> Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, >> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an >> Effizienz gewinne... > > Moby, da hilft nur Übung, Vorbereitung, System. Absolut. Nur ändert das nichts an den Nachteilen von C gegenüber Asm! Thomas E. schrieb: > Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken? > > Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich > aus diesem nur einen einzigen Befehl verwende. Spar Dir den Blödsinn. Im Fall des Falles kommt ein 555er zum Einsatz oder die schon genannte fertige blinkende Leuchtdiode: Keep it simple! Winfried J. schrieb: > wir beide haben zumindest gemein die Verachtung Anderer auf uns zu > ziehen weil wir unseren jeweiligen Standpunkt konsequent vertreten. "Verachtung" hin oder her- ich weiß was ich an Asm habe. > Maschinennahe Programmierung erschwert die Übersichtlichkeit. Das lässt > sich mit Macros zwar verbessern. Trotzdem bleibt es aufwendig. Die Einschätzung teile ich ganz und gar nicht. C-Codes, sobald sie über kleinste Anweisungen hinausgehen sind wirklich alles andere als übersichtlich. Da lob ich mir die Asm Sequenzen einfachster Instruktionen, die sich genauso hübsch funktionell gliedern lassen. > Die Effizienz des erzeugten Codes hängt im hohen Maße vom komplex > logischen vermögen des Programmierers mit gleichzeitig hohem > Abstraktionsvermögen ab. Der Asm-Programmierer benötigt nur ersteres ;-) > Die Codeeffizienz eines lausigen Hochsprachenprogrammierers ist sicher > noch größer als die eines mittelmäßigen ASM Fetischisten Das bestreite ich, als nur "mittelmäßiger" ASMler. > Nachdem HW heute billiger als SW-Entwicklungszeit (Programmiererlohn) > ist > ist ausgereizte ASM Programmierung schlicht zu teuer. Asm-Programmierung ist durchschnittlich aufwendiger, aber je nach Übung, Vorbereitung und System. Dafür kommt mehr Effizienz bei raus. Allein um diesen Punkt geht es mir aber- und zwar bis hoch zu 1M ;-) > Im Übrigen empfinde ich Hochsprachen bequemer und nutze sie im > Bewusstsein, > dass ich nicht jedes Byte kenne, welches der Compiler daraus bastelt, > oder den genauen Ablauf einer Interpreterfunktion nicht kenne. Das will ich Dir nicht ausreden. Interessant ist aber nicht "jedes Byte, welches der Compiler daraus bastelt" sondern die Kenntnis der konkreten Hardware und die bestmögliche Anpassung daran für eine konkrete App. > Einen Blick in den erzeugten Compiler-Code oder eine Interpreterroutine > ist allemal lehrreich. Bestimmt. Angewiesen war ich bislang darauf nicht ;-)
Moby A. schrieb: > Doch wär es immer noch sinnvoller, > mich mit einer C-Version meines Projekts überzeugen zu "helfen" Hat Yalu doch gemacht: Sein C-Programm ist kleiner und kann mehr als Deins. Dir wurde doch schon geholfen. Nur willst Du nicht lesen, was alle schon wissen.
P. M. schrieb: > Und Moby macht einfach weiter, als wäre nichts gewesen. Obwohl Yalu in > einem Beispiel nun wirklich UNZWEIFELHAFT nachgewiesen hat, dass man > Assembler sogar bei Mini-Programmen mit C schlagen kann. Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur Kenntnis nimmst ;-) P. M. schrieb: > - Obwohl du als Hobbyist gegen eine ganze Horde an erfahrenen Profis > antrittst, Eine ganze Horde C-Ideologen ;-) > - obwohl ein halbes Forum deiner Einzelmeinung geschlossen widerspricht, Du solltest nicht mal für 1 Zehntausendstel des Forums sprechen ;-) > - obwohl du keine deiner Behauptungen belegen konntest, Mein Tiny13 Projekt steht für die von mir behauptetete Asm-Effizienz. Bessere C-Tatsachen: Nicht in Sichtweite ;-) > - obwohl klare Gegenbeweise gegen deine Thesen bestehen, Meinst Du etwa Deine Unterstellungen, Unwahrheiten, Ablenkungsmanöver, dummen Scherze, Beleidigungen usw usf? Eine etwas dünne Beweislage ;-) > - obwohl du einen Teil des Diskussionsgegenstands (Programmiersprache C) > nicht mal kennst, Was ich dazu kennen muß kenne ich schon aus eigener Erfahrung. Noch besser aber ist ein regelmäßiger Blick in die vielen C-Problemthreads. Besser als durch die Erfahrenen dort kann die umständliche C-Bürokratie gar nicht zur Geltung kommen ;-) > => benimmst du dich immer noch so, als wärst du im Recht und die anderen > auf dem Holzweg. Tja, der Schluß ist eben alles andere als logisch. Nicht sehr ehrenhaft für einen Programmierer ;-)
Karl H. schrieb: > Wenn es um ein > Assembler Problem geht, glänzen sie so gut wie fast immer .... durch > Abwesenheit. Es kann halt nicht jeder einen Vollzeitjob hier machen. Michael K. schrieb: > Karl H. schrieb: >> Und ich brings trotzdem nicht übers Herz, den 30 Jahre alten Krempel zu >> entsorgen. > > Moby auch nicht ;-) Was Problemstellungen am einfachsten löst kann gern auch 300 Jahre alt sein ;-) Frank M. schrieb: > Moby A. schrieb: >> Doch wär es immer noch sinnvoller, >> mich mit einer C-Version meines Projekts überzeugen zu "helfen" > > Hat Yalu doch gemacht: Sein C-Programm ist kleiner und kann mehr als > Deins. Lies nochmal genau was ich schrieb. Schaffst Du das überhaupt? Michael K. schrieb: > Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung > und die Housekeeping Aufgaben des OS und wieviel davon harte > Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir > vorstellen was möglich ist wenn man low level nur noch > Kernfunktionalität programmiert. Na also. Zuweilen mischt sich unter die Ideologen noch ein klar Denkender ;-)
:
Bearbeitet durch User
@ moby Mein weg durch die Programmiersprachen auf verschiedenen Plattformen U808 ASM U880 ASM 6502 ASM Basic verschiedene Dialekte Pascal ASM Forth Turbobasic 60386 ..... Basic verschiedene Dialekte ASM PDSBasic + inline ASM Pascal C(C++ versuchsweise) Java versuchsweise Purebasic AVR***** ASM C + inline ASM Bei allen größeren Projekten war ich mit Hochsprachen am Ziel noch bevor ich in ASM den speicher organisierthabe und ein gerüst im PAP erzeugt hatte. Bei den AVR ist es eigentlich in C am einfachsten. Ich benutze CVAVR. das zauberwort heiststrukturierte Programierung und ausagekräftige Bezeichner. Namaste
:
Bearbeitet durch User
Winfried J. schrieb im Beitrag #4385607:
> Bei allen größeren Projekten
Das wird's wohl sein.
Nix für ungut.
Gute Nacht.
Moby A. schrieb: > Michael K. schrieb: >> Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung >> und die Housekeeping Aufgaben des OS und wieviel davon harte >> Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir >> vorstellen was möglich ist wenn man low level nur noch >> Kernfunktionalität programmiert. > > Na also. Zuweilen mischt sich unter die Ideologen noch ein klar > Denkender ;-) Nun, ich mag eine gut gestaltete GUI auch wenn sie Ressourcen frisst. Auch wenn das jetzt ein wenig aus dem Zusammenhang gerissen war, ist ein grundlegender Konflikt ganz gut zu erkennen. Die ungläubige Frage was denn bitteschön mit dem alten Kram anzufangen gewesen wäre ausser ein wenig Heimgebastel lässt mich schon schmunzeln. Das waren unsere Produktivsysteme meine Herren ! (Nein, ich bin noch ganz lange nicht in Rente, die Entwicklung war nur sehr schnell) Ein wenig Technikhistorie würde unseren 'jungen Wilden' ganz gut tun. Du bist ja nicht im Unrecht das 'bare metal' und verzicht auf alles was über blanke Funktionalität hinaus geht auf den alten MCU Dinge möglicht macht die die neue Programmiererelite auf 8bit für unmöglich hält. Deine Schlussfolgerung das das in ASM geschehen muß teile ich nicht. Ja, das war mal so vor langen Jahren, aber die Compiler sind wirklich gut geworden und die MCUs geben sich auch alle Mühe es ihnen leicht zu machen. Deine Aussagen sind ja bewusst provokativ. Das wirst Du gleich verneinen aber das nehme ich Dir trotzdem nicht ab. Ich finde das Software heute auch gut aussehen darf. Das darf auch Rechenleistung kosten und man darf es sich auch durch geeignete Hochsprachen einfacher machen. Wir müssen zum Glück nicht mehr mit den argen Becshränkungen der grauen Vorzeit leben und das darf man auch mal annehmen. Du mach was Dir spaß macht. Machst Du ja ohnehin.
Moby A. schrieb: > Karl H. schrieb: >> Wenn es um ein >> Assembler Problem geht, glänzen sie so gut wie fast immer .... durch >> Abwesenheit. > > Es kann halt nicht jeder einen Vollzeitjob hier machen. Wenn du die Hälfte der Zeit, die du in diesen Thread hier versenkst, stattdessen in die Beantwortung von Fragen zu Assembler in anderen Threads stecken würdest, wäre dort viel gewonnen und hier nichts verloren.
Michael K. schrieb: > Karl H. schrieb: >> Das einzige bei dem ich am Anfang immer Probleme >> hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie? > Da hilft nur: Übung, Vorbereitung, System Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry. http://www.mikrocontroller.net/articles/8bit-CPU:_bo8
Josef G. schrieb: > Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry. Perfekt, jetzt ist die Stimmung im Arsch. Moby, Josef... wo steckt eigentlich Kurt? Ich denke, hier sind noch einige Sachen reichlich undefiniert. Kein Wunder, dass bisher kein Konsens zustande kommen konnte.
Moby A. schrieb: > Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur > Kenntnis nimmst ;-) Zitier mal bitte was du genau meinst. "Weiter oben" umfasst mittlerweile eine Spanne von einigrn hundert Beiträgen. Moby, hast du eigentlich immer noch nicht kapiert gegen welche geballte Kompetenz du da anstinken willst? Gerade der gestrige Nachmittag war für mich wieder sehr interessant. Da waren einige neue Infos dabei, über die Anfänge der Heimelektronik und was manche hier schon vor > 30 Jahren alles implementiert haben. Dagegen willst du dich echt aufmandln? Um beim Bayerischen zu bleiben: du bist echt a Kasperl...
le x. schrieb: > Um beim Bayerischen zu bleiben: du bist echt a Kasperl... Der Kasperl der Bist Du, weil Du immer noch versuchst, dem Mann mit Argumenten beizukommen. Dabei hat er doch mehr als einmal durchleuchten lassen, dass es bei seinem "Asm" immer nur um kleine Anwendungen geht. Ich verstehe nicht, warum hier immer noch verbissen ("Hnnngggg!") Recht behalten werden muss.
Alle haben Recht .... im Bereich bis zu ihrem Tellerrand.
Josef G. schrieb: > Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry. Sieh an, hätte ich nicht gedacht: Noch ein Fan vom 1802. ;-) Aber warum nicht konsequent, also auch ohne Carry-Flag? (MIPS) Da hast du ausnahmsweise mal ins Schwarze getroffen, wenn auch möglicherweise eher zufällig. Technisch betrachtet gibts es tatsächlich gute Gründe, auf klassische Flags zu verzichten, aber wenns irgend geht auch auf Carry. Bei OOO Implementierung sind Flags "a pain in the ass", viel Aufwand mit wenig Ertrag. Der Ansatz von MIPS ist dann tatsächlich effizienter.
:
Bearbeitet durch User
Yalu X. schrieb: > Wenn du die Hälfte der Zeit, die du in diesen Thread hier versenkst, > stattdessen in die Beantwortung von Fragen zu Assembler in anderen > Threads stecken würdest, wäre dort viel gewonnen und hier nichts > verloren. Jeder hat so seine Prioritäten. Es ist auch nicht so daß ich noch nicht woanders geholfen hätte. Die Vorstellung effizienter Asm-Programme könnte allerdings auch eine effiziente Hilfe und Orientierung für manchen sein ;-) Eddy C. schrieb: > Ich denke, hier sind noch einige Sachen reichlich undefiniert. Genau. Wie riesig der Effizienzabstand Asm vs. C idealerweise wirklich sein könnte ;-) le x. schrieb: > Da > waren einige neue Infos dabei, über die Anfänge der Heimelektronik und > was manche hier schon vor > 30 Jahren alles implementiert haben. Dagegen > willst du dich echt aufmandln? Wieso dagegen? Mich interessiert die Effizienz von Asm beim Ressourcenverbrauch. Dafür hab ich hier ein extra Projekt gezeigt. Dagegen kam noch nix ;-) Markus M. schrieb: > Alle haben Recht .... im Bereich bis zu ihrem Tellerrand. Das kann man immer unterschreiben ;-)
Moby A. schrieb: > Genau. Wie riesig der Effizienzabstand Asm vs. C idealerweise wirklich > sein könnte ;-) Ja, volle Zustimmung ;-)
Eddy C. schrieb: > Der Kasperl der Bist Du, weil Du immer noch versuchst, dem Mann mit > Argumenten beizukommen Na ja, Argumente... Aber die grundlegende Einsicht: Bravo! Nun fehlt nur noch das Warum. Warum ist Asm im umrissenen Einsatzgebiet überlegen! Bevor aber die Chance bestünde, das nach >10000 Beiträgen endlich akzeptiert herauszukristallisieren hat ein Mod längst entnervt den Hahn zugedreht ;-)
Moby A. schrieb: > Spar Dir den Blödsinn. Im Fall des Falles kommt ein 555er zum Einsatz > oder die schon genannte fertige blinkende Leuchtdiode: Keep it simple! Netter Versuch, um weiter von deinen eigenen Unzulänglichkeiten und denen deines "Projektchens" abzulenken. Ich gestehe dir aber zu, dass du aus deiner laienhaften Sicht als Hobbybastler das wahre Potential dieses Programms natürlich nicht erkennen kannst. Den Atmega88 habe ich natürlich mit Bedacht ausgewählt, da sich dieses Projekt auch an Anfänger richtet. Diese benutzen zumeist den Atmega8. Da dieser Controller aber veraltet ist, führe ich sie mit meinem Projekt an dessen Nachfolger heran. Wie ich aber schon in meinem Beitrag, in dem ich das Projekt vorstellte, schrieb, lässt sich das Programm ohne Änderungen auch auf anderen Controllern ausführen. Z.B. auf einem Attiny85. Dieser Controller unterscheidet sich in Bauform und Grösse nicht vom NE555. Bietet jedoch den Vorteil, dass er mit wesentlich weniger externer Beschaltung auskommt. Eine selbstblinkende LED bietet nur auf den ersten Blick einen Vorteil. Das Controller-Projekt ist über einen weiten Spannungsbereich einsetzbar, während die selbstblinkende LED nur innerhalb geringer Toleranzen benutzt werden kann. Ausserdem bietet das Controller-Projekt die geniale Möglichkeit, mit einer zweiten LED einen Wechselblinker aufzubauen. Die beiden LEDs blinken dann mit absoluter Präzision im Wechseltakt. Das Besondere dabei ist, dass es dazu keiner Änderung der Software bedarf. Das Programm erkennt selbstständig, dass eine zweite LED vorhanden ist. Eine Tatsache, die ganz klar in Richtung künstliche Intelligenz tendiert. Ein Wechselblinker ist mit zwei selbstblinkenden LEDs unmöglich zu realisieren. Weiterhin besteht die Möglichkeit, mehrere, mit diesem Projekt aufgebaute Schaltungen, taktgenau zu synchronisieren. Natürlich ohne jegliche Änderungen an der Software durchzuführen. Dabei lassen sich sogar verschiedene Controller einsetzen. Damit wird also eine heterogene Struktur erreicht. Mit NE555 oder selbstblinkenden LEDs ist dies ausgeschlossen. Und das alles mit den schon genannten Vorteilen. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten. mfg.
Thomas E. schrieb: > Netter Versuch, um weiter von deinen eigenen Unzulänglichkeiten und > denen deines "Projektchens" abzulenken. Ich lenke nicht ab sondern sage nur: Keep it simple. Das gilt für Anwendungen wo ein MC sinnvoll wird ganz genauso. Du aber könntest ruhig zugeben, daß Deine Asm Blinker App oben Quatsch war. > Den Atmega88 habe ich natürlich mit Bedacht ausgewählt, da sich dieses > Projekt auch an Anfänger richtet. Diese benutzen zumeist den Atmega8. Da > dieser Controller aber veraltet ist, führe ich sie mit meinem Projekt an > dessen Nachfolger heran. Großartig. Was für ein Upgrade ;-) > während die selbstblinkende LED nur innerhalb geringer > Toleranzen benutzt werden kann. Die sind mit einem einfachen, entsprechend dimensionierten Vorwiderstand ja viiiel größer ;-) > Eine > Tatsache, die ganz klar in Richtung künstliche Intelligenz tendiert. Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit ;-) > Das sind die unwidersprochenen Fakten.
Moby A. schrieb: > daß Deine Asm Blinker App oben Quatsch war. Das typische Verhalten, wenn einem die Argumente ausgehen und man von seinen eigenen Unzulänglichkeiten ablenken will. Moby A. schrieb: > Großartig. Was für ein Upgrade Wieso Upgrade? Ich habe von vornherein betont, dass sich dieses Projekt auch an Anfänger richtet. Moby A. schrieb: > Die sind mit einem einfachen, entsprechend dimensionierten Vorwiderstand > ja viiiel größer Sicher. Man kann die Schaltung sowohl für eine frei wählbare Spannung dimensionieren, als auch durch den Einsatz einer KSQ universell gestalten. Das kannst du als Hobbybastler natürlich nicht wissen. Aber jetzt weisst du das auch. Hast also schon wieder etwas gelernt. Moby A. schrieb: > Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit So ist das mit den Argumenten. Siehe oben. Moby A. schrieb: >> Das sind die unwidersprochenen Fakten. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! mfg. PS: Ich habe ein C-Programm geliefert, um diese Fakten zu belegen! Du dagegen, klopfst weiterhin nur Sprüche.
Thomas E. schrieb: > Ausserdem bietet das Controller-Projekt die geniale Möglichkeit, > mit einer zweiten LED einen Wechselblinker aufzubauen. Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und eine zweite z.B. mit 1.01 Hz. Ein Blinky mit einer LED entspricht einem "Hallo Welt", d.h. der Einsteiger muss sich erst mal mit Geraffel wie Editor, Programmer, Spannungsversorgung, Beschaltung etc. herumschlagen. Wenn das allles absolviert ist, wird i.d.R. das einfache Testprogramm erweitert zu einer "richtigen" Anwendung, die aber alsbald über das Übel der Verzögerung per delay stolpert. Die 2 asynchron blinkenden LEDs zeigen schön den Weg zu delay-freier Software.
Moby A. schrieb: > Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit > ;-) Moby, wir wissen nicht aus welchem Motiv du in diesem Thread noch unterwegs bist. Aber falls die gesamte Diskussion von deiner Seite wirklich ernst gemeint war, dann muss man dir von der besagten Dummheit doch so einiges unterstellen, und zwar nicht "künstliche", sondern "natürliche" Dummheit. Deine Beiträge bestehen eigentlich nur noch aus satzweise zitierten Postings, wo du Satz für Satz mit einem dummen Spruch konterst. Ganz ehrlich: Sowas lese ich nicht mehr durch.
Johann L. schrieb: > Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und > eine zweite z.B. mit 1.01 Hz. Hab' ich mal gemacht als Blaulicht-Rundumleuchten-Imitiation für ein kleines Spielzeugauto. Dort waren's 501 und 499 ms Periodendauer für die beiden LEDs. Ach, Mist, ist off-topic hier. War kein Assemblerprogramm.
Jörg, poste doch mal das C Progrämmchen, vielleicht macht das Moby als ASM ;-) Schreib aber nicht im Vorfeld den RAM/Flash verbrauch, damit er auch noch dieses Jahr fertig wird mit optimieren g
Johann L. schrieb: > Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und > eine zweite z.B. mit 1.01 Hz. Das ist keine typische 8-Bit-SLB*-Anwendung. mfg. * S y n c h r o n e s L e u c h t d i o d e n B l i n k e n
:
Bearbeitet durch User
P. M. schrieb: > Moby, wir wissen nicht aus welchem Motiv du in diesem Thread noch > unterwegs bist. Ich fürchte, Du weißt gar nichts. Und ich fürchte, Du stehst hinter Thomas Eckmanns Jux-Beispiel ;-( > Ganz > ehrlich: Sowas lese ich nicht mehr durch. Daß Du Dinge nicht zur Kenntnis nimmst die Dir nicht in den Kram passen weiß ich doch.
quatsch! Das ist eine typische ASM Anwendung 1 hw timer 2 sw zähler oder wenn vorhanden 2 hw timer welche in in der IRS die nur die port bits toggeln da gibt es nichts zu optimieren da ist schon das öffnen der compiler IDE oversice Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > da gibt es nichts zu optimieren Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser Code-Overhead hinzukommen und mehr Schreibaufwand allemal ;-)
Moby A. schrieb: > Ich fürchte, Du weißt gar nichts. > Und ich fürchte, Du stehst hinter Thomas Eckmanns Jux-Beispiel Was heisst denn hier Jux? Eine weitere unqualifizierte Äusserung, um von den eigenen Unzulänglichkeiten abzulenken. Nochmal: Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! mfg.
Moby A. schrieb: > Daß Du Dinge nicht zur Kenntnis nimmst die Dir nicht in den Kram passen > weiß ich doch. Kein Kommentar. mfg.
Moby A. schrieb: > Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser > Code-Overhead hinzukommen und mehr Schreibaufwand allemal Na, dann mach doch mal. 1Hz, 1,01Hz. Attiny13. Wir wollen ja niemand mit Timern verwöhnen. mfg.
Thomas E. schrieb: > Was heisst denn hier Jux? > > Eine weitere unqualifizierte Äusserung Du wirst doch nicht ernsthaft erwarten daß ich diese Asm-Anwendung ernst nehme und weiter darauf eingehe. Obwohl, eine Chance geb ich Dir noch: Wenn Dir ein Mod und 5 weitere der 50 C-Granden, die hier auf den armen Moby einhacken bestätigen, daß es sich bei Deiner Blink-App um eine ernstzunehmende Assembler-Anwendung handelt ;-) Davon mach ich mir dann einen Ausdruck, weil sowas kann man in zukünftigen Diskussionen immer mal brauchen ;-) > Na, dann mach doch mal. > > 1Hz, 1,01Hz. Attiny13. Wir wollen ja niemand mit Timern verwöhnen. Verwöhn mich mal mit der C-Variante. Dann sehen wir weiter.
:
Bearbeitet durch User
Moby A. schrieb: > Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit > ;-) Die Moby'schen Beiträge hingegen tendieren eindeutig Richtung natürliche Dummheit ;-)
Moby A. schrieb: > Du wirst doch nicht ernsthaft erwarten daß ich diese Asm-Anwendung ernst > nehme und weiter darauf eingehe. Nichts weiter als die Bestätigung deiner vorherigen Aussagen. Dir sind die Argumente ausgegangen und jetzt benimmst du dich wie ein Kleinkind, dass sich an der Supermarktkasse schreiend auf dem Boden wälzt, weil es keinen Lolli bekommt. Du kanst dem, von mir gezeigten Optimum, einfach nichts entgegensetzen. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Moby A. schrieb: > Wenn Dir ein Mod und 5 weitere der 50 C-Granden, die hier auf den armen > Moby einhacken bestätigen, daß es sich bei Deiner Blink-App um eine > ernstzunehmende Assembler-Anwendung handelt Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist rein rhetorischer Art. Du hast es nötig. Moby A. schrieb: > Verwöhn mich mal mit der C-Variante. > Dann sehen wir weiter. Das war natürlich nicht anders zu erwarten. Erst die grossen Sprüche: Moby A. schrieb: > Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser > Code-Overhead hinzukommen und mehr Schreibaufwand allemal Dann natürlich nichts dahinter und andere sollen wieder in Vorlage treten. mfg.
Moby A. schrieb: > Daß Du Dinge nicht zur Kenntnis nimmst die Dir nicht in den Kram passen > weiß ich doch. LOL, das nächste Eigentor.
Moby A. schrieb: > Verwöhn mich mal mit der C-Variante. > Dann sehen wir weiter. Wozu, du könntest ja die vielen Sonderzeichen gar nicht lesen.
Thomas E. schrieb: > Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist > rein rhetorischer Art. Du hast es nötig. Was heißt hier rhetorisch? Das war voll mein Ernst. > Dann natürlich nichts dahinter und andere sollen wieder in Vorlage > treten. War doch Dein Beispiel... Dann zeig mal was. Ich zeig Dir dann, wie's kürzer geht. Hast bis morgen Zeit. An meinem freien Sonntag würde ich dafür etwas Zeit erübrigen ;-)
Moby A. schrieb: > Thomas E. schrieb: >> Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist >> rein rhetorischer Art. Du hast es nötig. > > Was heißt hier rhetorisch? > Das war voll mein Ernst. Grandioses Textverständnis!
Markus M. schrieb: > Jörg, poste doch mal das C Progrämmchen, vielleicht macht das Moby als > ASM ;-) Da steht eine Beerware license drüber, insofern vermute ich, dass ich das hier schon mal gepostet habe. Nö, ich würde höchstens die Specs posten, nicht das Programm selbst. Aber Moby hat doch sowieso keine Zeit für sowas.
Carl D. schrieb: > Wozu, du könntest ja die vielen Sonderzeichen gar nicht lesen Ja genau. Die vielen vielen C-Sonderzeichen. Ein besonderer Aufwand: Samt und sonders überflüssig wie ein Kropf ;-) Carl D. schrieb: > Grandioses Textverständnis! Du solltest Dich bemühen, nicht endgültig auf das Niveau von Gu.F(orentroll) abzusacken ;-(
Moby A. schrieb: > Das war voll mein Ernst. Ja sicher. Ich bezweifle auch nicht, dass du das nötig hast, weil du meinen Fakten nichts entgegensetzen kannst. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Moby A. schrieb: > War doch Dein Beispiel... Das war nicht mein Beispiel. Ich habe nur die Anforderungen zusammengefasst. Du kannst gerne auch einen anderen Controller nehmen. Von dir kam aber die grosskotzige Ankündigung: Moby A. schrieb: > Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser > Code-Overhead hinzukommen und mehr Schreibaufwand allemal mfg.
Moby A. schrieb: > Ja genau. Die vielen vielen C-Sonderzeichen. Ein besonderer Aufwand: > Samt und sonders überflüssig wie ein Kropf ;-) Zumindest beherrscht du schon diese 3 Sonderzeichen ;-)
Moby A. schrieb: > Carl D. schrieb: >> Grandioses Textverständnis! > > Du solltest Dich bemühen, nicht endgültig auf das Niveau von > Gu.F(orentroll) abzusacken ;-( noch mal für dich in "ausführlich": Du hast eine Antwort gegeben, aus der man leicht erkennen kann, daß du den Text! auf den du antwortest, nicht verstanden hast. Oder war das jetzt wieder zu kompliziert?
:
Bearbeitet durch User
Morgen üben wir dann diese Sonderzeichen "("
Zusammen mit deinen schon bekannten kannst du dann schon eine C Funktion
formulieren.
Gu. F. schrieb: > Morgen üben wir dann diese Sonderzeichen "(" > Zusammen mit deinen schon bekannten kannst du dann schon eine C Funktion > formulieren. Mit dem "^" können wird ja noch etwas warten ;-)
Thomas E. schrieb: > weil du > meinen Fakten nichts entgegensetzen kannst. Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner Asm Blink-App, dann können wir Deine "Fakten" neu bewerten ;-)
Carl D. schrieb: > Oder war das > jetzt wieder zu kompliziert? Nö. Aber unwichtig. Bevor wir uns weiter in diesem seichten, nichtssagenden Sumpf verlieren les ich jetzt mal meine frische c't. Manchmal gibts da ganz nette Meldungen (siehe z.B. Ausgangsposting). ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Bevor wir uns weiter in diesem seichten, nichtssagenden Sumpf verlieren > les ich jetzt mal meine frische c't. Oder liest doch mal hier: http://www.cprogramming.com/tutorial/c-tutorial.html Dann könntest du irgendwann auf Augenhöhe mit uns diskutieren :-)
:
Bearbeitet durch User
Moby A. schrieb: > Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner > Asm Blink-App, dann können wir Deine "Fakten" neu bewerten Die Leier hatten wir doch schon. Fällt dir nie etwas Neues ein? mfg.
Thomas E. schrieb: > Die Leier hatten wir doch schon. Seh ich als gutes Zeichen, wenn Dir nur noch die Abqualifizierung als "Leier" einfällt ;-) Ich sags auch gern ein drittes, viertes, fünftes Mal wenn Dir an Deiner Blöd-App soviel liegt... P. M. schrieb: > Oder liest doch mal hier: > http://www.cprogramming.com/tutorial/c-tutorial.html Wozu sollte ich mich damit unnütz mehr als nötig belasten? Wozu ein Riesen-Faß mit Bergen von Regeln und Vorschriften, Operatoren, Typen, Deklarationen, Konstruktionen und Lib-Funktionen aller Art aufmachen wenn eine geeignete App auch mit ein paar simplen Asm-Instruktionen und auch noch kürzer + ggf. mit mehr Speed zu realisieren ist? > Dann könntest du > irgendwann auf Augenhöhe mit uns diskutieren :-) Ach so? Wo hier welche Augenhöhen sind ist noch lange nicht ausgemacht. Von Deiner hab ich noch nicht viel gespürt. Zumindest beim Thema Asm vs. C ;-)
:
Bearbeitet durch User
P. M. schrieb: > irgendwann auf Augenhöhe mit uns diskutieren :-) So tief wird sich keiner freiwillig bücken wollen.
Gu. F. schrieb: > So tief wird sich keiner freiwillig bücken wollen. Bei Deiner wird man dann schon abtauchen müssen ;-)
Moby A. schrieb: > Ach so? Wo hier welche Augenhöhen sind ist noch lange nicht ausgemacht. > Von Deiner hab ich noch nicht viel gespürt. Zumindest beim Thema Asm vs. > C ;-) Du bist Hobbyist, der gerade mal etwas Assembler kann. Die meisten anderen Diskussionsteilnehmer (und ich) haben Ausbildung, Studium und insbesondere jahre- bis jahrzehntelange Berufserfahrung im Bereich der hardwarenahen Software-Entwicklung. Keine Ahnung, wie man da ein Moby noch auf die Idee kommen könnte, er wisse es besser...
Na Mobily, warum so dünnhäutig? Beist du dir an "(" grad die Zähne aus?
LOL
:
Bearbeitet durch User
OT
1 | #include "stm32f4xx.h" |
2 | #include "core_cm4.h" |
3 | |
4 | int main(void); |
5 | void SysTickHandler(void); |
6 | |
7 | // ISR Vector Table
|
8 | const uint32_t AppVectors[] __attribute__ ((section(".isr_vector"))) = |
9 | {
|
10 | 0x20010000, // stack pointer |
11 | (uint32_t)&main, |
12 | 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
13 | (uint32_t)&SysTickHandler |
14 | };
|
15 | |
16 | volatile uint16_t i, k; |
17 | |
18 | void SysTickHandler(void) // Systick (1ms) |
19 | {
|
20 | i++; |
21 | k++; |
22 | }
|
23 | |
24 | int main(void) |
25 | {
|
26 | // Init
|
27 | RCC->AHB1ENR |= RCC_AHB1Periph_GPIOD; // Modul aktivieren |
28 | GPIOD->MODER |= 0x55000000; // LED Pins als Output |
29 | SysTick->CTRL |= SysTick_CLKSource_HCLK; // Systick Timer einstellen |
30 | SysTick_Config(16000); // 1ms Takt aus 16MHz Systemtakt |
31 | |
32 | GPIOD->ODR = GPIO_Pin_13 | GPIO_Pin_12; // LED gn/or |
33 | |
34 | while(1) |
35 | {
|
36 | if (i >= 499) |
37 | {
|
38 | i = 0; |
39 | GPIOD->ODR = (GPIOD->IDR ^ GPIO_Pin_15); // Toggle LED bl |
40 | }
|
41 | if (k >= 501) |
42 | {
|
43 | k = 0; |
44 | GPIOD->ODR = (GPIOD->IDR ^ GPIO_Pin_14); // Toggle LED rt |
45 | }
|
46 | }
|
47 | }
|
für ein STM32F4DISCOVERY, ganz ohne overhead im Hintergrund und ohne Startup-Code Der einzige Funktionsaufruf aus der Lib ist "SysTick_Config()"
:
Bearbeitet durch User
P. M. schrieb: > Keine Ahnung, wie man da ein Moby > noch auf die Idee kommen könnte, er wisse es besser... Du solltest nicht so schablonenhaft denken. Vor allem aber nicht bloße (behauptete) Erfahrung als Argument verwenden. Damit kannst Du vielleicht andere beeindrucken aber nicht mich. Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-)
Markus M. schrieb: > für ein STM32F4DISCOVERY, ganz ohne overhead im Hintergrund und ohne > Startup-Code Sorry, wir reden hier von 8-Bit AVR Code. Das Discovery ist schon von der Hardware her totaler Overkill für typisches 8-Bit MSR, für die Assembler sowieso nicht mehr infrage kommt ;-(
Ich hab kein AVR mehr, den hab ich schon vor 10 Jahren wegen mangelnder Funktionalität und Speicher entsorgt. Aber Du hast doch ein STM32 Board zu Hause liegen, zumindest hast Du das mal geschrieben. Doch weil Du das nie zum laufen bekommen hast liegt es nun in der Ecke.
Moby A. schrieb: > Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf > dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-) Hier, bitte:
1 | Mobys Asm-Code Yalus C-Code |
2 | ————————————————————————————————————————————————— |
3 | Flash-Verbrauch 266 256 |
4 | RAM-Verbrauch¹ 6 + 1 GPIOR 9 |
5 | Stack-Verbrauch 2 4 |
6 | Quellcodezeilen² 143 91 |
7 | Quellcodezeichen³ 1614 1707 |
8 | ————————————————————————————————————————————————— |
9 | ¹) ohne Stack |
10 | ²) ohne Leer- und Kommentarzeilen |
11 | ³) ohne Kommentare, Leerraum und Zeilenvorschübe |
12 | |
13 | Compiler: GCC 4.7.4 |
14 | Assembler/Linker: Binutils 2.25.1 |
15 | C-Standardbibliothek: AVR-Libc 1.8.1 |
Markus M. schrieb: > Aber Du hast doch ein STM32 Board zu Hause liegen, zumindest hast Du das > mal geschrieben. Doch weil Du das nie zum laufen bekommen hast liegt es > nun in der Ecke. Stimmt. Wollte es später in Markt verschenken aber nicht mal geschenkt wollte es damals jemand ;-) Es mag sicher auch seine Einsatzmöglichkeiten haben, (gepeinigt mit daten/rechenintensiven Anwendungen oder hochabstraktem C++ ;-), die liegen aber hinter meinem Tellerrand und den Notwendigkeiten von (fürs SmartHome ausreichenden) 8-Bit MSR Problemlösungen. P. M. schrieb: > Hier, bitte: Ich befürchte bei Dir schon wieder was: Daß Du was Entscheidendes überlesen hast ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Ich befürchte bei Dir schon wieder was: > Daß Du was Entscheidendes überlesen hast ;-) Ja, ich weiss, dass du alles als ungültig erklärst, das nicht eine exakte Nachprogrammierung deines Krams ist. Und selbst dann erfindest du immer neue, absurde Nebenbedingungen. Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei widerlegt.
P. M. schrieb: > Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als > Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei > widerlegt. Deine Zweifelsfreiheit in allen Ehren, aber das ist die These nicht. Das Warum werde ich hier nicht tausendmal wiederholen. Du hast die Gelegenheit des Nachweises aber nach wie vor bei meinem optimierten Projekt. Dazu aber wird von Dir genau soviel kommen: Nichts. Lieber versteckst Du Dich hinter Yalus Rücken bei einem Code und einem Vergleich, bei dessen genauen Kontext Du nur durch Ahnungslosigkeit glänzt ;-)
P. M. schrieb: > Ja, ich weiss, dass du alles als ungültig erklärst, das nicht eine > exakte Nachprogrammierung deines Krams ist. Funktion ist Funktion. Da wollen wir schon genau bleiben und nicht streitträchtig herumhudeln ;-) > Und selbst dann erfindest du > immer neue, absurde Nebenbedingungen. Falls das wieder auf den RAM-Verbrauch gemünzt war: Ja, der gehört zu jedem vernünftigen Resourcenverbrauchs- Vergleich! Da ist rein gar nichts absurd dran.
Moby A. schrieb: > Falls das wieder auf den RAM-Verbrauch gemünzt war: Ja, der gehört zu > jedem vernünftigen Resourcenverbrauchs- Vergleich! Da ist rein gar > nichts absurd dran. Genau. Aber das ist natürlich nur ein Teil der einzusparenden Resourcen. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Von denen du natürlich noch weit entfernt bist. mfg.
Hier noch die Variante mit "Sleep" und LED Toggle im Interrupt, der Vollständigkeit halber diese Abwandlung.
1 | #include "stm32f4xx.h" |
2 | #include "core_cm4.h" |
3 | |
4 | int main(void); |
5 | void SysTickHandler(void); |
6 | |
7 | // ISR Vector Table
|
8 | const uint32_t AppVectors[] __attribute__ ((section(".isr_vector"))) = |
9 | {
|
10 | 0x20010000, // stack pointer im CCM RAM |
11 | (uint32_t)&main, |
12 | 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
13 | (uint32_t)&SysTickHandler |
14 | };
|
15 | |
16 | void SysTickHandler(void) // Systick (1ms) |
17 | {
|
18 | static uint16_t i, k; |
19 | if (++i >= 499) |
20 | {
|
21 | i = 0; |
22 | GPIOD->ODR = GPIOD->IDR ^ GPIO_Pin_15; // Toggle LED bl |
23 | }
|
24 | if (++k >= 501) |
25 | {
|
26 | k = 0; |
27 | GPIOD->ODR = GPIOD->IDR ^ GPIO_Pin_14; // Toggle LED rt |
28 | }
|
29 | }
|
30 | |
31 | int main(void) |
32 | {
|
33 | // Init
|
34 | RCC->AHB1ENR |= RCC_AHB1Periph_GPIOD; // Modul aktivieren |
35 | GPIOD->MODER |= 0x55000000; // LED Pins als Output |
36 | SysTick->CTRL |= SysTick_CLKSource_HCLK; // Systick Timer einstellen |
37 | SysTick_Config(16000); // 1ms Takt aus 16MHz Systemtakt |
38 | |
39 | GPIOD->ODR = GPIO_Pin_13 | GPIO_Pin_12; // LED gn/or |
40 | |
41 | while(1) __WFI(); // Aktivieren Sleep-Mode |
42 | }
|
Thomas E. schrieb: > Von denen du natürlich noch weit entfernt bist. Gäääähn. Natürlich, Thomas, so un-end-lich weit daß es schon fast an Wahnsinn grenzt. Ich hoffe, ich konnte Dich jetzt zufriedenstellen! Ich seh schon es kommt nichts Handfestes mehr... Dann mach ich mal Feierabend, hier und heute!
Moby A. schrieb: > Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner > Asm Blink-App, dann können wir Deine "Fakten" neu bewerten ;-) Ertmal Entschuldigung! Ich bin kein prominenter C-Zeuge. Aber trotzdem versuch' ich's mal: Du bezeichnest deine paar aneinandergereite ASM-Befehle als hochoptimiertes, einfach zu erweiterndes, ...(*) Programm. Thomas hat mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die Funktionsweise der Hardware verstanden hat! Und: Ich verrate dir mal was (es liest ja keiner mit): Ich schätze, er würde trotzdem für seine Anwendung die kilo(byte)schwere C-Version verwenden. :-) (*) 'hocheffizient' und den anderen Schwachsinn lass ich mal weg, das sprengt den Rahmen Moby A. schrieb: > Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf > dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-) ???
>(fürs SmartHome ausreichenden) 8-Bit MSR Problemlösungen.
genauso wie bei ASM sind das aber DEINE "Ansprüche" ..
die, wie du vielleicht doch irgendwann gemerkt hast, den Ansprüchen
aller anderen diametral engegengesetzt sind
otto-normalbürger stellt sich unter "SmartHome" wohl doch was anderes
vor, als dass was deine Hardware hergibt..
Ralf G. schrieb: > (*) 'hocheffizient' und den anderen Schwachsinn lass ich mal weg, das > sprengt den Rahmen Dann solltest du "hochoptimiert" und "einfach zu erweitern" ebenfalls weg lassen.
Ich grins mir immer einen ab, wenn ich mal wieder so eine Codezeile schreibe:
1 | printf("Mein super wichtiger Debugwert: %i, %i, %f", nVal1, nVal2, fVal1); |
Der mir mal schnell per JTAG Debugger in der Debug Console irgend welche Zustände schreibt. Ach wie toll dass ich kein Assembler gefrickel nehmen muss.
:
Bearbeitet durch User
Ralf G. schrieb: > Thomas hat > mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die > Funktionsweise der Hardware verstanden hat! Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines Programms, welches wohldefiniert wirklich etwas bewegt? Soll mich das jetzt ärgern oder was bezweckst Du damit? Ralf G. schrieb: > Ich verrate dir mal was > (es liest ja keiner mit): ... den Oszi-Output meines Projekts hab ich nur mit Paint gezeichnet ;-) Robert L. schrieb: > genauso wie bei ASM sind das aber DEINE "Ansprüche" .. > die, wie du vielleicht doch irgendwann gemerkt hast, den Ansprüchen > aller anderen diametral engegengesetzt sind > > otto-normalbürger stellt sich unter "SmartHome" wohl doch was anderes > vor, als dass was deine Hardware hergibt.. Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im Gegenteil eher unsicher und schwach. > ... stellt sich unter "SmartHome" wohl doch was anderes > vor, als dass was deine Hardware hergibt.. Hast Du dafür irgendwelche Anhaltspunkte? Oder vertraust Du hierfür nur Deiner angenommenen Mehrheitsmeinung bzw. der Stimmungslage mir gegenüber in diesem Thread?
Wer etwas kann und Übung, Vorbereitung, System hat, braucht keinen Debugger.
Moby A. schrieb: > Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der > Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle > anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe > nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im > Gegenteil eher unsicher und schwach. Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und alle anderen nicht mehr brauchen als du?
Klaus W. schrieb: > Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und > alle anderen nicht mehr brauchen als du? Genau dafür wurde ja der Begriff "MobyMaus Projektchen" erfunden ;-)
Klaus W. schrieb: > Wer etwas kann und Übung, Vorbereitung, System hat, braucht keinen > Debugger. Wenn man Code mit 5 anderen Programmieren zusammen bearbeiten darf, der auf Bibliotheken stützt, den wiederum X unterschiedliche Programmierer im Laufe der Jahre erstellt haben und zwischendurch es Upgrades von µC gab, und man auch noch fremde Komponenten per irgend welchen Schnittstellen einbinden darf, dann hilft ein Debugger sowie Debug-Ausgaben ungemein. Ich rede jetzt mal nicht von so einem Moby-Mini Dinges, sonder vom täglichen Brot eines SW-Entwicklers einer Firma mit vielen Entwicklern und Projekten.
Markus M. schrieb: > Ach wie toll dass ich kein Assembler gefrickel nehmen muss. Das Wohl-Gefühl und der Spaß an der Sache ist das was zählt! So eine Print-Funktion hat natürlich was. Aber ist natürlich klar, daß jetzt nur mit den Rosinen aus dem großen, trockenen C-Kuchen geworben wird! So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit vorab Variablen-initialisierten Registern kosten, wenn eine entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine fette C-Zeile ;-)
Moby A. schrieb: > So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit > vorab Variablen-initialisierten Registern kosten, wenn eine > entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine > Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine > fette C-Zeile ;-) Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16. Plus extra Kommentarzeilen damit man das versteht. Plus irgend ein Datenblock für den String. Es ist in einem Projekt schließlich nicht die einzige Debug-Ausgabe.
Klaus W. schrieb: > Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und > alle anderen nicht mehr brauchen als du? Den Mehrverbrauch im SmartHome wirst Du mir sicher gleich erläutern. Insbesondere interessieren mich die Stellen, wo man mit Asm undoder 8-Bit nicht mehr weiter kommt ;-) Markus M. schrieb: > Ich rede jetzt mal nicht von so einem Moby-Mini Dinges, sonder vom > täglichen Brot eines SW-Entwicklers einer Firma mit vielen Entwicklern > und Projekten. Gut daß Du diese Unterscheidung triffst. Denn für den Firmen-Bereich rede ich hier nicht. Nichtsdestotrotz sind auch viele Firmen-Anwendungen auf 8-Bit MSR Niveau.
Moby A. schrieb: > Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der > Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle > anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe > nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im > Gegenteil eher unsicher und schwach. Millionen fliegen irren nicht! "Scheiße ist lecker." Das Problem ist doch "Die Apfellogik" hinter Allem. Es will und soll niemand wissen warum etwas funktioniert solange es funktioniert. Und es ist auch gar nicht mehr erwünscht das zu wissen, denn was jeder kann besitzt keinen Wert! Wissen teilen ist in der Informationsgesellschaft ein Loyalitätsbruch am Kapital (siehe Snowden). Um das wie etwas sollen sich bitte jene, welche man genau dafür bezahlt, kümmern und das bitte auch für sich behalten damit das geschäft nicht leidet. Und wenn "es" nicht funktioniert wie es soll, dann sind "die" halt schuldig und haben den Schaden. Siehe VW Ingeneure. Das hat System und ist die Basis der Wirtschaft, Schmalspurwissen und dumme Konsumenten. Universalgelehrte und eine hohe Allgemeinbildung sind da nur hinderlich und wurden auf beiden Seiten nur im "Kalten Krieg" gebraucht aus Angst vor dem Potential des Gegners. Namaste
:
Bearbeitet durch User
Markus M. schrieb: > Klaus W. schrieb: >> Wer etwas kann und Übung, Vorbereitung, System hat, braucht keinen >> Debugger. > > ... > Schnittstellen einbinden darf, dann hilft ein Debugger sowie > Debug-Ausgaben ungemein. sorry, muß wohl noch was nachreichen: :-)
Markus M. schrieb: > Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür > reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16. Das ist wie bei Menschen. Fett zeigt sich in der Breite, nicht in der Länge, 16 schmale unkommentierte Zeilen Asm sind viel weniger fett als eine Zeile C, die quer den ganzen Bildschirm füllt. ;-) > Plus irgend ein Datenblock für den String. Nicht wenn man es richtig macht: rcall ptext db 'Hallo Welt!',13,10,0 Mach das mal in C. Und float brauchen seine Anwendungen sowieso nicht. Schon mal ein 8-Bit Fliesskommaformat gesehen?
:
Bearbeitet durch User
A. K. schrieb: > Schon mal ein 8-Bit Fliesskommaformat > gesehen? was nicht bedeutet, dass das auf 8-Bittern nicht einzusetzen wäre in meinem 8 Bit Atarie waren 8 K Mathematik routinen drinnen auf welches der Basicrom ger zugegriffen hat. leider habe ich dafür keine doku aber so etwas ließe sich ach in einem Atmega sinnvoll einsetzen nicht nur von Hochsprachen aus auch aus ASM Calls wäe es sinnvol ansprechbar. Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > was nicht bedeutet, dass das auf 8-Bittern nicht einzusetzen wäre Aber bei Moby passte bislang alles, was des Programmierens wert wäre, in 8 Bits. Den Umgang mit grösseren Datentypen hatte ihm erst unlängst ein C Compiler beigebracht.
Markus M. schrieb: > Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür > reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16. Plus > extra Kommentarzeilen damit man das versteht. Plus irgend ein Datenblock > für den String. > Es ist in einem Projekt schließlich nicht die einzige Debug-Ausgabe. Du bist mit der Print-Ausgabe zweifellos flexibler, auch vom Variablenformat her. Dem will ich mal Rosinen-Status zugestehen. Bei meiner vorbereiteten Asm-Funktion müsste ich aber auch nur händisch den schon enthaltenen Text ändern, Variablen sind höchstens 16-bittig. Davon abgesehen läuft es in meiner Praxis sowieso gaaaanz anders. Die Netzknoten an denen ich arbeite geben ihre Daten in einem festgelegten Protokollstring drahtlos an mein PC Terminal-Programm weiter. In deren Ausgabe-Puffer schreib ich einfach rein was ich wissen will, der Rest geht eh automatisch. Winfried J. schrieb: > Das Problem ist doch "Die Apfellogik" hinter Allem. Es will und soll > niemand wissen warum etwas funktioniert solange es funktioniert. Oh je... Mit C und seiner ganzen Bürokratie und Entwicklungsumgebung muß man aber mehr wissen und beachten als mit Asm und der intimen Kenntnis eines AVR-Controllers. Davon abgesehen ist die Apfel-Logik absolut richtig und anzustreben. Ich sage nicht, das Asm mit direktem Hardware-Zugriff der "Keep it simple"-Weisheit letzter Schluß ist. Ich sage aber, daß mit C in typischen 8-Bit MSR Anwendungen unter dem Strich nichts einfacher und (für den geübten ASM'ler) effizienter wird. Für eine tatsächliche Vereinfachung der Programmierung müsste man meiner Meinung nach ganz grundlegend an der Hardware ansetzen und nicht auf Kosten von Ressourcenverbrauch, Schreibaufwand und Übersicht allein die Software immer flexibler = immer abstrakter = immer komplizierter gestalten und so nur fortlaufend die Hardware-Anforderungen erhöhen. Hardware auch, die mit immer mehr zu beherrschenden da ach so flexiblen Features überladen wird statt einfacher und intelligenter zu werden. Möge der Schöpfer sicherstellen, daß einfache 8-Bit Hardware noch lange für einfache 8-Bit MSR zur Verfügung steht ;-)
A. K. schrieb: > Aber bei Moby passte bislang alles, was des Programmierens wert wäre, in > 8 Bits. Variablen sind i.a.R. nicht größer als 16 Bit- damit läßt sich mit 8-Bit AVR prima hantieren!
Mal ein 8-Bit Float erfinden: Bit 7: Vorzeichen Bit 6..5: Exponent Bit 4..0: Mantisse Damit Moby auch mal seine Projekte mit Mini-Float ausstatten kann. Wo ein Wille ist ist auch ein Weg GRINS
Moby A. schrieb: > Variablen sind i.a.R. nicht größer als 16 Bit- damit läßt sich mit > 8-Bit AVR prima hantieren! Manche müssen sich dazu aber erst vom C Compiler zeigen lassen, wie man das überhaupt macht. So wie ein gewisser Moby. ;-)
Markus M. schrieb: > Damit Moby auch mal seine Projekte mit Mini-Float ausstatten kann. Wofür? Für Vorzeichen und Kommastellen brauch ich jedenfalls kein C. Und kannst Du mir mal sagen, wo in 8-Bit MSR Exponenten auftauchen? A. K. schrieb: > Manche müssen sich dazu aber erst vom C Compiler zeigen lassen, wie man > das überhaupt macht. So wie ein gewisser Moby. ;-) Na was denn? Klartext bitte. Den Asm-Output eines Compilers kenn ich nur vom Hörensagen.
dann doch lieber 16 bit obgleich man sicher auch mit 8bit float was anfangen kann 1-3-12 ist glaube ich schon mal da gewesen. Namaste
Moby A. schrieb: > Den Asm-Output eines Compilers kenn ich nur vom Hörensagen. Ich habe nicht behauptet, dass du ihn selbst aufgerufen hast. Obwohl es in dem Fall weniger peinlich gewesen wäre, es vorher zu tun. ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Davon abgesehen ist die Apfel-Logik absolut richtig und anzustreben. Na Mahlzeit mit der Einstellung fährt D.(EU) wirtschaftlich entgültig gegen die Wand. Wissen und Innovation ensteht durch Produktion und nicht im Elfenbeinturm. Schon heute rennt uns Asien, ehemals als verlängerte Werkbank von gierig agierenden BWLern erfunden, inovativ den Rang ab. Und die Polemik der Politik zu diesem Thema steht "Erichs Sprüchen" in nichts mehr nach. Selbst Nachrichten erreichen DDR-Niveau. Das könne "wir in der DDR-sozialisierten" sehr schön mitverfolgen weil wir es unabhängig welche Schlüsse wir daraus ziehen wiedererkennen. Das sehen es viele, wenn nicht die meisten, von uns mit großem Unbehagen. Namaste
DDR 2.0 gibts hier nicht: Assembler-Programme lügen nicht. C Compiler schon, wenngleich recht selten. Bin ja mal gespannt, wann der erste Prozessor rauskommt, dessen Assembler-Sprache nur chinesische Schriftzeichen verwendet. Und dann stell ich mir Moby bei dessen Programmierung vor.
:
Bearbeitet durch User
A. K. schrieb: > Ich habe nicht behauptet, dass du ihn selbst aufgerufen hast. Obwohl es > in dem Fall weniger peinlich gewesen wäre, es vorher zu tun. ;-) Ich sagte Klartext bitte ;-) Wenn es irgend ein Fehlerchen war ist mir das nicht peinlich. Die sind menschlich und sehr produktiv... Winfried J. schrieb: > Na Mahlzeit mit der Einstellung fährt D.(EU) wirtschaftlich entgültig > gegen die Wand. Wieso? Die Dinge einfacher und einfacher benutzbar zu machen ist ein legitimes Anliegen. Noch dazu in einer Zeit, wo immer mehr immer komplizierter wird. Es ist auch erfolgreich, wie die Apfel-Verkaufszahlen trotz astronomischer Preise zeigen. Nur so gehts wieder von der "Wand" weg! Konfiguritis bis ins letzte Detail? Nein danke.
:
Bearbeitet durch User
Moby A. schrieb: > Ich sagte Klartext bitte ;-) Der Klartext wurde hier im Thread bereits verlinkt und auch ausführlich kommentiert. Also ganz leicht zu finden und kein Grund, das zu wiederholen.
:
Bearbeitet durch User
Davor kommt der erste Chip mit HW Interpreter und Chinesischer Sprachein/ausgabe in Mandarin mit 8Kanal 128bit paralel ADU im Eingabekreis und Hardware-FFT. Allerdings wird der mehr als 8 oder auch 64 Bit parallel verarbeiten. Und die Amis werden fünf Jahre benötigen, bevor die den ins Englische kopiert haben. D. braucht dann noch einmal zehn Jahre. Namaste
A. K. schrieb: > Auf den Klartext wurde hier im Thread bereits verlinkt. > Also ganz leicht zu finden. Na meinetwegen. Die Vorteile von Asm wird's trotzdem nicht tangieren. A. K. schrieb: > Assembler-Programme lügen nicht. So ist es. Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar, die Gestaltungsfreiheiten unbegrenzt. Die Freiheit, das Bestmögliche zu erreichen. Aber man weiß ja, daß mit mehr Freiheit immer auch mehr Verantwortung einhergeht.
Moby A. schrieb: > Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen > Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines > Programms, welches wohldefiniert wirklich etwas bewegt? Soll mich das > jetzt ärgern oder was bezweckst Du damit? Was heisst "Soll mich das ärgern"? Es ärgert dich! Dieses Programm geht weit über die Grenzen deiner Erkenntnis und deines Verstandes hinaus. Denn du hast dieser genialen Funktionaltät nichts entgegenzusetzen. In diesem Programm ist die von dir vielbeschworene Effizienz realisiert, während deine Programme noch meilenweit davon entfernt sind: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! mfg.
Moby A. schrieb: > P. M. schrieb: >> Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als >> Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei >> widerlegt. > > Deine Zweifelsfreiheit in allen Ehren, aber das ist die These nicht. Anstatt mit dummen Sprüchen zu kontern, hättest du hier auch einfach deine These klarstellen können. Vermutlich willst du das aber nicht, obwohl eine klare These, ein klarer Standpunkt eigentlich Ausgangslage jeder Diskussion sein sollte.
Thomas E. schrieb: > 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM > Flankenschonender und stromsparender Takt > Maximal mögliche Schonung des Befehlssatzes Der Moby hat endgültig seinen Meister gefunden! Die Reaktion fällt natürlich aus wie zu erwarten... Rausreden, Fakten verdrehen und wegdefinieren (Stichwort 8 bit MSR)
Johann L. schrieb: > eine LED mit 1 Hz blinken zu lassen und > eine zweite z.B. mit 1.01 Hz. Moby A. schrieb: > Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser > Code-Overhead hinzukommen und mehr Schreibaufwand allemal Moby A. schrieb: > An meinem freien Sonntag würde ich dafür etwas Zeit erübrigen Moby, hast du das woanders gepostet? Ich finde das hier nicht. Dieser Aus-Dem-Ärmel-Schüttler müsste doch längst fertig sein. mfg.
Moby A. schrieb: > A. K. schrieb: >> Assembler-Programme lügen nicht. > > So ist es. > Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede > Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar, > die Gestaltungsfreiheiten unbegrenzt. Die Freiheit, das Bestmögliche zu > erreichen. Aber man weiß ja, daß mit mehr Freiheit immer auch mehr > Verantwortung einhergeht. Liest sich so als hättest du eine symbiotische Beziehung zu AVR Assembler.
Moby A. schrieb: > Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede > Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar, > die Gestaltungsfreiheiten unbegrenzt. Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz konkretes Beispiel.
P. M. schrieb: > Was kannst du in Assembler, das du in C nicht kannst? Die Frage hast du unglücklich formuliert. Sie impliziert, dass er etwas in C könne. Das ist aber nicht der Fall. Die Frage könnte er so, wie sei gestellt ist, mit "Alles" beantworten. Das wäre selbst dann vollkommen richtig, wenn er nur den nop-Befehl beherrschte. Richtig müsste es also heisen: Was kannst du in Assembler, was man in C nicht kann? mfg.
Moby A. schrieb: > So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit > vorab Variablen-initialisierten Registern kosten, wenn eine > entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine > Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine > fette C-Zeile ;-) Nö, eine Debugausgabe kostet mich nicht eine einzige Zeile Code und es ist vollkommen egal was ich mir dabei anschauen will. a.) Ich trage meine zu beobachtenden Variablen im Watch Window ein und sehe live was passiert. b.) Ich gehe auf HALT und schaue mir einfach jedes Register und jede Speicherstelle in der MCU an die mich gerade interessiert. c.) Ich lasse mir Kurven schreiben von Variablen die mich gerade interessieren. d.) Ich setze einen Breakpoint und schaue mir an ob das Programm bis dahin läuft und schaue mir an was in den Variablen / Registern steht. Alles das mir einer 30Cent MCU und einem kostenlosen Compiler + IDE + einem 5€ Programmer / Debugger (STM8S003 + IAR Kickstart) Der Compiler wird da schon irgendwas im Hintergrund machen damit ich bekomme was ich will. Ist mir aber total schnuppe solange ich bekomme was ich will. Ich habe wirklich keine Ahnung wann Du das letzte mal mit einer vernünftigen IDE + C Compiler gearbeitet hast, aber es muß irgendwann in den 80ern gewesen sein. Im Normalfall klicke ich gerade mal ein paar Haken in den Projektsettings an und bekomme das Make File nie zu Gesicht. Ich könnte, aber warum sollte ich? > fette C-Zeile ;-) Wirklich, Du verwechselst da was. Fett und kryptisch ist es erst alle Register freischaufeln zu müssen die man für eine Debugausgabe braucht anstatt einfach den Wert anzuschauen ohne sich vorher um irgendwas kümmern zu müssen.
Thomas E. schrieb: > Richtig müsste es also heisen: > Was kannst du in Assembler, was man in C nicht kann? dem wäre nur zu entgegnen Was kannst du in C, was man prinzipiell in Assembler nicht kann? nichts da C grundsätzlich auf ASM Aufsetzt und nicht umgekehrt. das Compilat ist stehts ein ASM file. also etwas das prinzipell auch direkt in ASM gescchrieben werden kann Du hast den Vorteil mehr vordefinierte Funktionen, was nicht heist, dass man Selbige in ASM nicht generieren kann. das erspart Arbeit insofern diese bereits zuvor von anderen erledigt wurde. Nachteil: Du weist nicht per se wie der compiler das in ASM umsetzt. Der einzige Vorteil von C und allen übrigen Hochsprachen ist, das sie teilweise plattformübergreifend anwendbar sind, bei mehr oder weniger definierter Syntax undman so nicht zufuß über stock und stein muß. das aber ist für den hobbisten das ziel (der Weg) Strukturierte Programmierung ist in jeder Programmiersprache die Regel, welche der durchbrechen darf der sie beherrscht. Das ist für ASM noch wichtiger als für jede Hochsprache. niemand hindert im Übrigen den C Programmierer mittels Inline asm ASM Code wie SBI /CBI für die es keine entsprechung in C gibt einzubinden. umgekehrt kann man aus dem ASM code vorkompilierte C-Fuktionen aufrufen warum nicht Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze entscheide ich danach wie groß und tief das Loch in der Wand werden soll Das Werkzeug an der Wand ist immer ein Meißel, das am Prozessor ist immer das Hexfile. Den Weg dorthin sieht man dem fertigen hexfile in aller regel nicht mehr an. aber in C++ ist es schneller zusammen geklickt. Ob der Programmierer noch weis was mit welchen Nebeneffekten damit im Prozessor passiert, hängt von dem Wissensdurst des Programmierers ab. Namaste
Johann L. schrieb: > Liest sich so als hättest du eine symbiotische Beziehung zu AVR > Assembler. Hmm. Was hat der Assembler für einen Vorteil?
Winfried J. schrieb: > Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze > entscheide ich danach wie groß und tief das Loch in der Wand werden soll Das ist die gängige Meinung. Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel mit Hammer und Meisel aus dem Fels zu hauen. Einen Tunnelbohrer zu benutzen ist totaler bürokratischer Quatsch. Den Beleg dazu kann auch keiner bringen.
:
Bearbeitet durch User
Gu.F. schrieb: > Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel > mit Hammer und Meisel aus dem Fels zu hauen. mit "Übung, Vorbereitung, System" macht der Moby das Rucki Zucki.
Werner P. schrieb: > mit "Übung, Vorbereitung, System" macht der Moby das Rucki Zucki Nein. Der Tunnel ist keine typsische 8bit MSR Anwendung. Das wird in eine TBM ausgelagert und dazugekauft.
Gu. F. schrieb: > Winfried J. schrieb: >> Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze >> entscheide ich danach wie groß und tief das Loch in der Wand werden soll > > Das ist die gängige Meinung. > Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel > mit Hammer und Meisel aus dem Fels zu hauen. Einen Tunnelbohrer zu > benutzen ist totaler bürokratischer Quatsch. Den Beleg dazu kann auch > keiner bringen. Leider viel schlimmer. Er will daß jeder davon überzeugt ist, daß die Benutzung einer Tunnelbohrmaschine große Verschwendung ist. Dabei ist doch auch Hammer und Meißel Verschwendung, denn beim Tunnelbau fallen massenweise Faustkeile an, die ein noch direkteres Gefühl für's Gestein rüber bringen.
Moby A. schrieb: > Den Asm-Output eines Compilers kenn ich nur vom Hörensagen. Bitte ? Aber Du predigst doch schon die ganze Zeit das ASM so viel geiler ist. Woher willst Du das wissen wenn Du noch niemals überprüft hast welch eleganten Konstruktionen ein C Compiler zustande bekommt ? Moby A. schrieb: > Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede > Unaufmerksamkeit. Moment, aber Dein Argument was doch das C fett und kryptisch ist und ein ASMler schon lange fertig bevor ein Cler überhaupt mit dem lesen und verstehen seines Sprachschatzes durch ist. Nun ist es ein Nachteil von C den gröbsten Blödsinn von mir abzufangen und ein Vorteil von ASM jedes Nachlassen der Konzentration sofort und unmittelbar aufs härteste zu bestrafen ? Moby A. schrieb: > Die Vorteile von Asm wird's trotzdem nicht tangieren. Nun bin ich etwas verwirrt welche das noch sein sollen. Wenn ich Deine Aussagen mal zusammenfasse und dabei auch beachte welchen Aussagen Du vehement nicht widersprochen hast ergibt sich folgendes Bild: Dank Yalus Code wissen wir das C besser optimiert, selbts bei kleinsten Programmen. C fängt meine Fehler ab, ASM lässt mich voll reinrauschen. C kann ich jederzeit und überall in jede Richtung erweitern, umbauen, eindampfen und der Compiler regelt das schon hinter den Kulissen. ASM braucht Übung, Vorbereitung, System und wenn ich da Mist mache dann bin ich fällig und kann nicht mehr vor und nicht zurück ohne alles neu zu schreiben. Bei C+IDE ist debuggen so schwer wie in der Nase bohren, bei ASM muss ich erst einen Batzen Routinen für dieses und jedes fertig haben und dann auch jeweils ganz genau wissen was ich in diesem Programteil machen darf und was nicht. Große C Programme schreibe ich so wie kleine und die Codedichte ist immer gleich. Size oder Speed opt. ist nur ein Häkchen anders setzen in der IDE. Kleine ASM Programme optimiere ich bis aufs Blut für jedes Bit für große macht man copy paste und verschenkt viel Optimierungspotential weil man den Überblick sonst nicht behalten kann. Habe ich auf Speed optimiert und muß das jetzt auf Size machen weil mir der Platz ausgeht dann schreibe ich alles neu dafür. In C kann ich jederzeit ohne großen Aufwand die MCU Familie wechseln in ASM muß ich alles neu schreiben. Das sind im wesentlichen Dinge die Du selber so gesagt hast. Nur nie alle auf einmal sondern nur in homöopatischen Dosen. Das alles ist auch nicht aus den Fingern gesogen, sondern das waren im wesentlichen genau die Gründe weswegen ich ASM vor langer Zeit den Rücken gekehrt habe.
Micheal, du hast nicht die Größe und den Überblick eines wahren Mobys. Dank Übung, Vorbereitung, System ist der "echte Programmierer" in der Lage selbst gewaltige 200 Byte große MSR Projekte ohne kryptische, bürokratische Hochsprachenkonstrukte aus dem FF zu beherrschen. Jeder der da widerspricht hat einfach nicht die Vorraussetzung die Dimensionen eines "MobyMaus Projektchen" wie das Tiny13 Sensorboard's zu verstehen.
Gu. F. schrieb: > gewaltige 200 Byte große MSR Projekte Auch solche mit 10 oder 100 KB, schließlich hat ihm ja nie jemand (anhand seines 200-Byte-Beispiels) das Gegenteil demonstrieren können.
Manche mögen mich für übergeschnappt halten, aber ich biete eine Wette an: Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch die 2000er Hürde schafft. Wer hält dagegen? (*) ganz nutzlos ist er dank des "Leimruteneffekts" doch nicht.... ;-)
Thomas E. schrieb: > Dieser Aus-Dem-Ärmel-Schüttler müsste doch längst fertig sein. Moby, was machst du denn den ganzen Tag? Ist das noch nicht fertig? Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal um diese Funktion erweitert. Die Frequenzen werden wie folgt ausgegeben: PB0: 2Hz PB1: 1.01Hz PB2: 1Hz PB3: 1Hz PB4: 1.01Hz (genau genommen sind es hier 1.01010101Hz = 100/99 Hz) Die Ausgaben an PB0, PB3 und PB4 werden per Softwarezähler, getriggert von Timer0, per PIN-Toggle ausgegeben. Die Ausgaben an PB1 und PB2 werden mit Timer1 erzeugt. Die Ausgabe erfolgt durch den Timer, also OC1A und OC1B. Softwarezähler werden nicht benutzt. Lediglich ein Einzeiler in der passenden Timer1-ISR. Clock ist 1,8432MHz. Mit internen 1MHz liefe es also etwas mehr als halb so schnell. Ich habe das Hexfile zum Testen drangehängt. Den C-Quellcode zeige ich dir, wenn du dein Asm-Programm gepostet hast. Ich will dich ja nicht in die Versuchung bringen, abzuschreiben. mfg.
Lothar M. schrieb: > Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch > die 2000er Hürde schafft. Wer hält dagegen? Was ist dein Einsatz? Ich hoffe, er ist für alle und insbesondere Moby attraktiv genug. Denn dann wünsche ich dir jetzt schon viel Spaß beim Schreiben von 419 nutzlosen Beiträgen :D
Yalu X. schrieb: > Denn dann wünsche ich dir jetzt schon viel Spaß beim Schreiben von 419 > nutzlosen Beiträgen :D Das wird Moby problemlos schaffen: Und zwar durch System, Übu.. äh durch Wiederholung seiner Floskeln
Lothar M. schrieb: > (*) ganz nutzlos ist er dank des "Leimruteneffekts" doch nicht.... ;-) An der auch Moderatoren rudelweise dran kleben bleiben. Aber verschmerzbar, sonst scheint grad kaum was los zu sein. ;-)
:
Bearbeitet durch User
Yalu X. schrieb: >> Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch >> die 2000er Hürde schafft. Wer hält dagegen? > > Was ist dein Einsatz? Ich biete einen AT90S1200. Ist doch ideal für Moby: wo kein RAM ist, kann auch keiner verschwendet werden. :-)
Jörg W. schrieb: > kann auch keiner verschwendet werden. Aber auch nicht gespart werden. Das wird ihm nicht gefallen. mfg.
Damals ... vor vieeelen Jahren hatte ich mein erstes EPROM von Hand programmiert. Als armer Schüler gingt jede Mark für Bauteile drauf. Das Handprogrammiergerät: - 8er Dip Schalter für die Daten - 7493 mit Monoflop als Adresszähler - "Brennen" Taste, der die VPP und den Adresszähler ansteuert. Computeruntergestütz habe ich das ASM Listing ausgedruckt und die Opcodes ran geschrieben und dann die DIP's nacheinander eingestellt. Nach 4h war das Programm dann drin. Das habe ich genau 2x gemacht. (beim ersten mal hab ich mich einmal nach 3h beim Dip Einstellen vertan) Danach habe ich mir ein EPROMer gebastelt samt Programm für einen Schneider CPC6128. An deren Erweiterungs-Datenbus. Das war dann schon deutlich angenehmer. So richtig nostalgisch. Leider ist das schon 25 Jahre her und ich sammle so zeug nicht, daher keine Bilder davon - schade. PS: hier präsentiere ich nun die nutzlose Information Nr 1586
:
Bearbeitet durch User
Markus M. schrieb: > So richtig nostalgisch. Leider ist das schon 25 Jahre her und ich sammle > so zeug nicht, daher keine Bilder davon - schade. Meinen alten Hardware-Eprommer habe ich auch verschrottet, ohne noch ein Foto davon zu machen. Da er auch noch 2708 (U555) programmieren können sollte, war (neben der Spannungsversorgung mit -5, +5, +12 V) noch das Problem, dass man den 2708 mit 50 Programmierimpulsen von je 1 ms programmieren musste, statt eines mit 50 ms. Normalerweise hatte man zwischendrin einfach alle 1024 Speicherstellen mit je 1 ms weiter programmiert, aber bei einem Programmer, der nur den Inhalt einer Stelle kennt, musste man diese mit hinreichenden Pausen dann 50mal programmieren. Zusätzlich musste die Hardware es beherrschen, den Vpp-Impuls selbst mit seinen 25 V zu schalten. Bei den späteren ROMs konnte man dann Vpp direkt anlegen, und nur noch 50 ms lang einen TTL-Impuls schalten. Aber ist natürlich alles kein Vergleich zu 1702-EPROMs, bei denen man an allen Pins irgendwas um -45 V zum Programmieren schalten musste.
Moby A. schrieb: > Ralf G. schrieb: >> Thomas hat >> mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die >> Funktionsweise der Hardware verstanden hat! > > Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen > Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines > Programms, welches wohldefiniert wirklich etwas bewegt? Ja! Und du hast dir die Antwort doch schon selber gegeben: Moby A. schrieb: > Andersrum. Der hat die richtigen Antworten wenn es darum geht, > performanten Code auf engstem Raum zu verpacken,
Ich hatte mich damals auf den 27C256 Typ beschränkt, der 32K Typ. Andere gingen damit nicht. Das war Preislich und von der Größe her akzeptabel und die liefen auch gut mit dem Z80 zusammen (Zugriffzeiten von 150ns).
Markus M. schrieb: > Ich hatte mich damals auf den 27C256 Typ beschränkt, der 32K Typ. Als ich die Kiste hier entworfen hab, gab's nichts anderes als 2708. Alles andere kam später mit dem computerisierten Programmer und war natürlich (vergleichsweise) viel einfacher.
Mein erster Brenner, !burnit, war ein Bit-Banger am LPT-Port. Der konnte 8748/49 und 2716-27256. Den hab' ich irgendwann zerlegt und daraus einen 8051-Flasher, !burnit2, gebaut. Der existiert und funktioniert auch noch. Theoretisch, also wenn der LPT-Port vom PC mitspielt. mfg.
Ralf G. schrieb: > Ja! Und du hast dir die Antwort doch schon selber gegeben: > Moby A. schrieb: >> Andersrum. Der hat die richtigen Antworten wenn es darum geht, >> performanten Code auf engstem Raum zu verpacken, Man sollte schon mehr von sehr wenig bis minimalster Funktionalität unterscheiden können. Sinnvolles von sinnlosem. Und auch wohl definiertes von weniger definiertem Programm-Verhalten. Jeweils letzteres sind für einen guten Programmierer nicht unbedingt schmeichelhaft ;-)
:
Bearbeitet durch User
Jörg W. schrieb: > Ich biete einen AT90S1200. Ist doch ideal für Moby: wo kein RAM ist, > kann auch keiner verschwendet werden. :-) Da kann aber auch niemand etwas erweitern. Oder gar in C programmieren ;-) Lothar M. schrieb: > Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch > die 2000er Hürde schafft. Wer hält dagegen? Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott versandet während ich mangels besserer C-Version immer noch auf den konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-)
:
Bearbeitet durch User
Matthias L. schrieb: > Und zwar durch System, Übu.. äh durch Wiederholung seiner Floskeln Naja, die Textbausteine hat er schon fertig. Bei größeren Threads ist das nur noch Copy Paste. Bei kleineren wird da noch mehr handoptimiert. Daher auch keine Antwort auf viele unangenehme Argumente. Die Textbausteine dafür sind noch nicht fertig und die zu schreiben dauert einfach seine Zeit. Alles analog zu ASM.
Moby A. schrieb: > Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in > die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott > versandet während ich mangels besserer C-Version immer noch auf den > konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-) Jetzt habe ich den Sinn des Threads und die Ausdauer des TO verstanden! Die Aussagen ohne neue Informationen solange wiederholen, bis auch der letzte eingesehen hat, dass es sinnlos ist, darauf zu antworten. Dann kann der Thread als "Sieg" gewertet werden! Danke für die Klarstellung!
Moby A. schrieb: > Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in > die Asm-Vorteile nicht durch. Ein Geisterfahrer? Zehntausende!
Moby A. schrieb: > Ralf G. schrieb: >> Ja! Und du hast dir die Antwort doch schon selber gegeben: >> Moby A. schrieb: >>> Andersrum. Der hat die richtigen Antworten wenn es darum geht, >>> performanten Code auf engstem Raum zu verpacken, > > Man sollte schon mehr von sehr wenig bis minimalster Funktionalität > unterscheiden können. Sinnvolles von sinnlosem. Und auch wohl > definiertes von weniger definiertem Programm-Verhalten. Jeweils > letzteres sind für einen guten Programmierer nicht unbedingt > schmeichelhaft ;-) Guten Morgen mein lieber Rosinenpicker, seit gestern sind ein paar interessante Beiträge angefallen, nimmst du dazu bitte auch Stellung? Moment, ich such dir einen davon raus: Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Außerdem steht meine Frage noch unbeantwortet im Raum. Dabei ging es darum, wieso Yalu's Code dir nicht als Beweis gereicht. le x. schrieb: > Moby A. schrieb: >> Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur >> Kenntnis nimmst ;-) > Zitier mal bitte was du genau meinst. "Weiter oben" umfasst mittlerweile > eine Spanne von einigrn hundert Beiträgen. Die Frage ist wirklich ernst gemeint. Mich interessiert deine Aussage dazu, ich konnte sie aber nirgends mehr finden...
@ Bernhard M. ja, das ist das Grundkonzept jedes Troll-Threads.. das schwierige ist, dass man immer nur sosehr unterschwellig Beleidigt und Aufstachelt ;-) , dass nicht vorzeitig alle aufgeben oder man überhaupt gesperrt wird das war im 4000+ thread wo es um "modulation" ging sicher auch so,.. (wo ist der überhaupt hin??) zum Thema: ASM hat Vor- UND Nachteile, C hat auch Vor- UND Nachteile (das hab Moby AVR auch nie bestritten) ob bei 8-bit MSR jetzt die Vor- oder die Nachteile überwiegen, ist mir immer noch egal.. (auch nach 2000 Posts wir es sich nicht ändern..) Auch wenn jetzt 90% der/meine Projekt(chen) in die Kategorie (8-bit MSR) fallen WÜRDEN, wäre es mir egal..
:
Bearbeitet durch User
Moby A. schrieb: > Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in > die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott > versandet während ich mangels besserer C-Version immer noch auf den > konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-) Ich möchte echt mal wissen, wer hinter diesem Moby steckt. Ein Troll? Ein besserwisserischer Gymnasiast? Ein bornierter Rentner? Ein selbstherrlicher so-läuft-das-hier-Machertyp? Ein grenzautistischer Nerd? Ein Narzist, der sein "Gesicht" verteidigt bis ins Verderben?
P. M. schrieb: > Ich möchte echt mal wissen, wer hinter diesem Moby steckt. Ein Troll? > Ein besserwisserischer Gymnasiast? Ein bornierter Rentner? Ein > selbstherrlicher so-läuft-das-hier-Machertyp? Ein grenzautistischer > Nerd? Ein Narzist, der sein "Gesicht" verteidigt bis ins Verderben? Darüber wurde schon einmal spekuliert: Michael K. schrieb: > Ob er das wirklich alles glaubt, uns nur veräppelt, im realen Leben > Bankensoftware in Cobol programmiert oder eine übergewichtige Friseuse > aus Castrop Rauxel mit einem Hang zu Kreuzworträtseln und ASM ist werden > wir wohl nie herausfinden. Eine von den beiden gefällt mir besonders gut. mfg.
le x. schrieb: > Guten Morgen mein lieber Rosinenpicker, Gemeint waren aber die wenigen C-Rosinen. Die langen bei weitem nicht zu einem genussvollen Verzehr des trockenen C-Kuchens aus ;-) > seit gestern sind ein paar interessante Beiträge angefallen, nimmst du > dazu bitte auch Stellung? Gerne. Meistens. Leider kann ich den Thread nicht in Vollzeit bearbeiten, aber ich bemühe mich (schon mit vielen Hundert Beiträgen). > Die Frage ist wirklich ernst gemeint. Mich interessiert deine Aussage > dazu, ich konnte sie aber nirgends mehr finden... Dann solltest Du Dir auch mehr Mühe geben. Das war weiter oben in ein paar Stichpunkten zusammengefasst. Bernhard M. schrieb: > Dann kann der Thread als "Sieg" gewertet werden! Lasst doch diese Kategorien aus der Steinzeit. Mit einer besseren C-Version meines Projekts hätte es sich schnell ausdiskutiert- jedenfalls von meiner Seite! Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt werden ;-) P. M. schrieb: > Ich möchte echt mal wissen, wer hinter diesem Moby steckt. Das ist einer Deiner Fehler: Du stellst die falschen Fragen. Mach Dir lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau gestellten Assembler-Überlegenheit zu begegnen ist ;-)
Moby A. schrieb: > Mit einer besseren C-Version meines Projekts hätte es sich schnell > ausdiskutiert- jedenfalls von meiner Seite! Yalu hat es schon geliefert: kleiner, effizienter und besser! > Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt > werden ;-) Willst Du doch gar nicht. Du lügst. ;-)
Robert L. schrieb: > @ Bernhard M. > > ja, das ist das Grundkonzept jedes Troll-Threads.. > das schwierige ist, dass man immer nur sosehr unterschwellig Beleidigt > und Aufstachelt ;-) , dass nicht vorzeitig alle aufgeben oder man > überhaupt gesperrt wird Im Großen und Ganzen bleibt Moby höflich und das hier wurde ja von ihm aufgemacht, also darf er auch diskutieren. Wegen Unbelehrbarkeit wird hier niemand gesperrt (gilt für beide Seiten) :-) > das war im 4000+ thread wo es um "modulation" ging sicher auch so,.. (wo > ist der überhaupt hin??) Den gibt es weiterhin: Beitrag "Frage zum Frequenzmultiplex bei Modulation" Das hat den Vorteil, dass Schreiber mit - sagen wir "eigenwilligen Ansichten" nicht alle Threads kapern sondern so ihrer Meinung Ausdruck verleihen können, ohne den sonstigen Ablauf im Forum zu stören. Ist also eine Win-Win-Situation. Daher bleiben diese Threads auch offen. Was wir deswegen in Zukunft freundlich aber bestimmt unterbinden werden ist eine Verlagerung in weitere Threads. > zum Thema: ASM hat Vor- UND Nachteile, C hat auch Vor- UND Nachteile > (das hab Moby AVR auch nie bestritten) > ob bei 8-bit MSR jetzt die Vor- oder die Nachteile überwiegen, ist mir > immer noch egal.. (auch nach 2000 Posts wir es sich nicht ändern..) > > Auch wenn jetzt 90% der/meine Projekt(chen) in die Kategorie (8-bit MSR) > fallen WÜRDEN, wäre es mir egal.. Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch antworten. Er hat seine Meinung, die anderen die ihre. Ich halte Mobys Ansicht auch für falsch, aber: was soll's? Ich muss ja nicht für ihn in Assembler programmieren sondern kann das nehmen, was meiner Erfahrung nach am schnellsten zum Ziel führt. Die Zeiten, wo ich Bytes sparen musste, sind gottseidank lange vorbei. Und Moby kann weiterhin seine Dinge in Assembler ausführen. Das schadet hier wohl niemandem :-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > Das hat den Vorteil, dass Schreiber mit - sagen wir "eigenwilligen > Ansichten" nicht alle Threads kapern sondern so ihrer Meinung Ausdruck > verleihen können, ohne den sonstigen Ablauf im Forum zu stören. Genial: Honeypot für Moby. :-)
>Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch >antworten. also ich weiß schon warum ich hier antworte, weißt du das bei dir nicht ;-) ich werde aber (so wie du) Moby nicht mehr direkt Antworten und auch nicht zum Thema (was jetzt blöderweise einem "Threads kapern" gleichkommt.. ) ;-)
:
Bearbeitet durch User
Robert L. schrieb: > also ich weiß schon warum ich hier antworte, weißt du das bei dir nicht > ;-) Kannst Du bitte so zitieren, dass man auch sieht, auf welches Posting Du Dich beziehst. Danke.
Moby A. schrieb: > Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt > werden ;-) Hm, Du möchtest also vom schinken/käse Geschmack der Erdbeertorte überzeugt werden ? Das könnte schwer werden. Ebensowenig kann ich Dir die Quadratur des Kreises liefern. Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist. Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf das sowas zutrifft. Ich kann Dir nicht den Vorteil eines Nachteiles beweisen der einfach nicht existiert. Du verlangst das unmögliche. Die Nachteile von ASM hingegen hast Du uns nun wirklich sehr schlüssig bewiesen bzw bestätigt. ASM schein auch einen sehr negativen Einfluss darauf zu haben wie aufgeschlossen man noch übergeordneten Problemlösungsstrategien ist. Die Fähigkeit also das klein, klein zu verlassen und die begrenze Ressource 'Brainpower' dazu zu verwenden größere Konzepte zu entwerfen. Chris D. schrieb: > Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch > antworten. Weil sich hier mehr Moderatoren aktiv beteiligen als in jedem anderen Thread. Die ASM Leier ist natürlich immer dieselbe, aber sieh doch was sich hier schon für überaus unterhaltsame Nebendiskussionen ergeben haben. So ein wenig in der eigenen und fremden Historie zu graben finde ich sehr erfrischend.
Michael K. schrieb: > Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist. > Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf > das sowas zutrifft. Kryptisch trifft zu. Der Rest nicht. Paradebeispiel einer bürokratischen Sprache ist COBOL:
1 | 000100 IDENTIFICATION DIVISION. |
2 | 000200 PROGRAM-ID. HELLOWORLD. |
3 | 000300 |
4 | 000400* |
5 | 000500 ENVIRONMENT DIVISION. |
6 | 000600 CONFIGURATION SECTION. |
7 | 000700 SOURCE-COMPUTER. RM-COBOL. |
8 | 000800 OBJECT-COMPUTER. RM-COBOL. |
9 | 000900 |
10 | 001000 DATA DIVISION. |
11 | 001100 FILE SECTION. |
12 | 001200 |
13 | 100000 PROCEDURE DIVISION. |
14 | 100100 |
15 | 100200 MAIN-LOGIC SECTION. |
16 | 100300 BEGIN. |
17 | 100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS. |
18 | 100500 DISPLAY "Hello world!" LINE 15 POSITION 10. |
19 | 100600 STOP RUN. |
20 | 100700 MAIN-LOGIC-EXIT. |
21 | 100800 EXIT. |
Gut, wahrscheinlich gehts auch kürzer.
:
Bearbeitet durch User
Michael K. schrieb: > aber sieh doch was sich hier > schon für überaus unterhaltsame Nebendiskussionen ergeben haben. > So ein wenig in der eigenen und fremden Historie zu graben finde ich > sehr erfrischend. Da hast Du Recht - die Beiträge dazu sind wirklich interessant. Irgendwo müsste ich auch noch zwei (nagelneue) 8749 rumfliegen haben. Dafür wollte ich mir immer ein Programmiergerät gebaut haben und sie als "Coprozessoren" an meinem Plus/4 einsetzen - aber dann rauchte der ab, weil Optokoppler noch ein Fremdwort für mich waren. Man lernt durch (finanziellen) Schmerz aber schnell und gründlich ;-) Edit: gerade nachgeschaut - ich hab die tatsächlich noch :-) Ja, das waren noch Gehäuse: Keramik, Quarzglas, wunderbar!
:
Bearbeitet durch Moderator
A. K. schrieb: > Kryptisch trifft zu. wobei es einen ASM Programmieren, mit der "ich mach mir alles selber" Einstellung, erstmals überhaupt nicht tangieren würde.. seinen EIGENEN Code, muss man ja nicht absichtlich kryptisch schreiben.. ein paar Anregungen was man in C zwar kann, aber nicht unbedingt machen sollte gibts ja z.b. hier: https://de.wikipedia.org/wiki/MISRA-C
Robert L. schrieb: > seinen EIGENEN Code, muss man ja nicht absichtlich kryptisch schreiben.. In C schon. Die Sprache selbst ist kryptisch, mit ihrer Nutzung von allerlei Sonderzeichen und seltsamer Deklarationssyntax. Ist schon ein Unterschied, ob da char (*ptr1)[10] char *ptr2[10] oder sowas wie dcl ptr1 as pointer to array [0..9] of char dcl ptr2 as array [0..9] of pointer to char steht.
:
Bearbeitet durch User
Chris D. schrieb: > Dafür wollte ich mir immer ein Programmiergerät gebaut haben und sie als > "Coprozessoren" an meinem Plus/4 einsetzen Sowas ähnliches wollte ich mal mit einem Z8 UPC machen, von dem ich ein paar Exemplare rumliegen hatte. Ein µC, den man an als Slave einen normalen 8-Bit Bus hängen kann und dessen Programm darüber in ein Huckpack-SRAM geladen wird. Sieht optisch ähnlich eindrucksvoll aus. Könnte man prima an ein FT2232 im Bus-Modus dranhängen. Hatte nur einen Haken: Das Mistvieh legt per /WAIT den Bus für 5-10µs lahm, wenn man drauf zugreift. Ist wohl eine Art Interrupt für den µC nötig, damit der den internen Bus freigibt. Da geht der Sinn eines Koporzessors ziemlich tief den Bach runter.
:
Bearbeitet durch User
@ A. K. ja, stimmt schon >char (*ptr1)[10] >char *ptr2[10] könnte man aber schon auch verständlicher schreiben?: const int MaxLengthFileName = 10; typedef char uCharArray_FileName[MaxLengthFileName]; uCharArray_FileName* ptr1 char* array2[irgendEineAndereKonstante]
Robert L. schrieb: > könnte man aber schon auch verständlicher schreiben?: Nun hast du schon fast die Bürokratie von Cobol erreicht. :)
Robert L. schrieb: > const int MaxLengthFileName = 10; > typedef char uCharArray_FileName[MaxLengthFileName]; Klappt in C nicht. "const" definiert keine Konstante, sondern eine invariable Variable. ;-) Ausserdem ist das nur ein Bisschen Zucker auf einer verbockten Syntax. Die Deklarationen liessen sich ungefähr so einigermassen retten: typedef char arrayOfChar[10]; arrayOfChar *ptr1; typedef char *ptrToChar; ptrToChar ptr2[10]; damit man nicht selbst recursive descent parser spielen muss, um diese beiden Fälle korrekt zu unterscheiden und einzutüten.
:
Bearbeitet durch User
A. K. schrieb: > In C schon. Die Sprache selbst ist kryptisch Ich habe einen Narren am Fragezeichen-Operator gefressen, der ist einfach cool... ;-) Ich habe den Link wieder gefunden: Beitrag "Re: VHDL: 4Bit Hex -> ASCII"
>Klappt in C nicht. "const" definiert keine Konstante, sondern eine >invariable Variable. ;-) ja, gemeint war "natürlich" #define MaxLengthFileName 10
Moby A. schrieb: > P. M. schrieb: >> Ich möchte echt mal wissen, wer hinter diesem Moby steckt. > > Das ist einer Deiner Fehler: Du stellst die falschen Fragen. Mach Dir > lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau > gestellten Assembler-Überlegenheit zu begegnen ist ;-) Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich weitgehend einig, nur eine Person hält noch dagegen - diese Person bringt aber weder Argumente noch kann sie auf einschlägige Erfahrung verweisen. Sondern sie postuliert einfach, recht zu haben, so lange der Standpunkt nicht widerlegt ist. Wobei sie natürlich definiert, was widerlegt heisst.
P. M. schrieb: > Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst > erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich > weitgehend einig ... daß sich Assembler im umrissenen Einsatzgebiet nicht schlagen lässt, meinst Du? Die C-Koryphäen schleichen wie Katzen um den heißen Brei meines Projekts und keiner traut sich. Woran es allerdings nicht fehlt ist allerlei Smalltalk und Ausreden so wie diese hier: > kann sie auf einschlägige Erfahrung > verweisen > Wobei sie natürlich definiert, was > widerlegt heisst Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar: Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität. Am Ende siegt aber dann doch die Angst ;-)
Frank M. schrieb: >> Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt >> werden ;-) > > Willst Du doch gar nicht. Du lügst. ;-) Das tät ich schon gerne. Die Unwahrheit würd ich aber sagen, wenn ich es hier offiziell für möglich halten würde, an besagten Nutzen zu glauben ;-) Chris D. schrieb: > Was wir deswegen in Zukunft freundlich aber bestimmt unterbinden werden > ist eine Verlagerung in weitere Threads. Dabei wärs so sinnvoll, gerade am praktischen Beispiel irgend einer C-Unzulänglichkeit die Asm-Vorteile zu demonstrieren und nicht in einem einzelnen Thread ein wenig ins Blaue hinein, da das vorhandene, konkrete Demo-Projekt ja wie der Teufel das Weihwasser gemieden wird ;-) P. M. schrieb: > Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz > konkretes Beispiel. Beitrag "Kleines Tiny13 Sensorboard" ;Segment Begin End Code Data Used Size Use% ; --------------------------------------------------------------- ; [.cseg] 0x000000 0x0000d8 216 0 216 1024 21.1% ; [.dseg] 0x000060 0x000060 0 0 0 64 0.0% ; [.eseg] 0x000000 0x000000 0 0 0 64 0.0% ; Assembly complete, 0 errors. 0 warnings
Moby A. schrieb: > P. M. schrieb: >> Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz >> konkretes Beispiel. > > Beitrag "Kleines Tiny13 Sensorboard" Stimmt. Das kannst du in C nicht. Weil du kein C kannst. Und daraus extrapolierst du, dass es alle anderen auch nicht gut hinkriegen würden. Moby A. schrieb: > Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar: > Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität. Dann erklär mir jetzt bitte mal, warum man das mit exakt deinem Beispiel nachweisen kann, während der erbrachte (!!!) Beweis von Yalu völlig ungültig sein soll.
Michael K. schrieb: > Hm, Du möchtest also vom schinken/käse Geschmack der Erdbeertorte > überzeugt werden ? Das könnte schwer werden. > Ebensowenig kann ich Dir die Quadratur des Kreises liefern. So ist es. Die Vorteile von Asm sind wie in Stein gemeißelt, da beißt man sich nur die Zähne dran aus! > Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist. > Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf > das sowas zutrifft. Dafür kenne ich Asm ;-) > Die Nachteile von ASM hingegen hast Du uns nun wirklich sehr schlüssig > bewiesen bzw bestätigt. In meinem noch nicht geschlagenen Projekt, meinst Du? > ASM schein auch einen sehr negativen Einfluss darauf zu haben wie > aufgeschlossen man noch übergeordneten Problemlösungsstrategien ist. > Die Fähigkeit also das klein, klein zu verlassen und die begrenze > Ressource 'Brainpower' dazu zu verwenden größere Konzepte zu entwerfen. "Größere Konzepte" bitte dahin wo sie hingehören. Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und Datenmengen überzustülpen bringt nur eins: O v e r h e a d ! Klaus W. schrieb: > sorry, muß wohl noch was nachreichen: :-) Genau. Das hier: Moby A. schrieb: > Klaus W. schrieb: >> Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und >> alle anderen nicht mehr brauchen als du? > > Den Mehrverbrauch im SmartHome wirst Du mir sicher gleich erläutern. > Insbesondere interessieren mich die Stellen, wo man mit Asm undoder > 8-Bit nicht mehr weiter kommt ;-)
Moby A. schrieb: > Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und > Datenmengen überzustülpen bringt nur eins: O v e r h e a d ! Dann zeig doch mal eine R-Anwendung in Assembler... :-D
P. M. schrieb: > Dann erklär mir jetzt bitte mal, warum man das mit exakt deinem > Beispiel nachweisen kann, während der erbrachte (!!!) Beweis von Yalu > völlig ungültig sein soll. Warum soll ich Dir hier was erklären wenn ich das bereits ausführlich getan habe? Kleine Vorab-Info: Erbracht ist gar nichts. So Du Dir die Mühe machst die entsprechend stichpunkt-artige Begründung herauszusuchen und darauf im Einzelnen einzugehen mach ich mir die Mühe das (nochmal) mit einer Antwort zu würdigen ;-) P. M. schrieb: > Und daraus > extrapolierst du, Ich extrapoliere gar nichts sondern stelle nur fest. Chris D. schrieb: > Die Zeiten, wo ich Bytes sparen > musste, sind gottseidank lange vorbei. Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen Win-PC, die nur noch GHz Prozessoren stemmen. Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist bei Controllern in vollem Gange. Also, bedient Euch ;-)
Moby A. schrieb: > Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und > Datenmengen überzustülpen bringt nur eins: O v e r h e a d ! Wir drehen uns im Kreis. Das was du unter 'typisch' verstehst, ist es eben für die meisten anderen nicht. und bei den Dingen, die du bisher als 'typisch' vorgebracht hast, war es völlig egal, ob das Programm im Flash 18 oder doch 21% belegt oder nicht.
Moby A. schrieb: > Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen > Win-PC, die nur noch GHz Prozessoren stemmen. Das was ein heutiger PC im Hintergrund noch alles mit erledigt, kannst du dir doch gar nicht vorstellen.
Moby A. schrieb: > P. M. schrieb: >> Und daraus >> extrapolierst du, > > Ich extrapoliere gar nichts sondern stelle nur fest. Nö. Stimmt schon. Du extrapolierst. Du extrapolierst aus einer simplen Aufgabe, die du mit ein paar Anweisungen erledigen kannst auf das Verhalten von größeren Programmen. Und genau das ist nicht zulässig. Denn die zu bearbeitende Komplexität steigt nicht linear sondern mindestens exponentiell. Genau deshalb sind grosse Systeme auch so schwer zu schreiben, weil es mit jedem zusätzlichen Subsystem immer schwieriger wird, die Querverbinden und Verflechtungen im Auge zu behalten. Genau das predigen wir hier die ganze Zeit.
> Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist > bei Controllern in vollem Gange. Also, bedient Euch ;-) hi, was verstehst du eigentlich unter MSR? Eine typische MSR-Anwendung wäre in meinen Augen zum Beispiel die Implementierung eines Kalmannfilters + PID Regler. Das ist aber unter Umständen eine reichlich Rechenintensive Geschichte... Ich glaube du unterschätzt den Begriff "MSR" erheblich. Jedenfalls ist die Reglungstechnik eine Wissenschaft für sich und der Komplexitätsgrad kann bei weitem "kleine Tiny-Sachen" übersteigen. Durchaus auch im Hobbybereich. Ich denke du stellst dir unter MSR immer etwas Simples vor. Das mag hie und da zutreffen, aber es gibt viele Anwendungen, da ist ein Cortex sinnig.
:
Bearbeitet durch User
Moby A. schrieb: > So Du Dir die Mühe machst die entsprechend stichpunkt-artige Begründung > herauszusuchen und darauf im Einzelnen einzugehen mach ich mir die Mühe > das (nochmal) mit einer Antwort zu würdigen ;-) Wenn du auch nur auf etwas eingehen würdest, dann hättest du vor rund 1000 Beiträgen eingesehen: Ja, ihr habt recht, Assembler ist nur für sehr wenige Spezialfälle die erste Wahl, im grossen und ganzen ist die Programmierung in C aber weit überlegen. Dann hättest du etwas gelernt, und wir hätten weniger von unserer Zeit verschwendet. (Zugegeben, so ein bisschen Spass macht es schon - wie früher wenn man den Klassendepp mit seinen absurden Ansichten noch ein bisschen aufgezogen hat.)
P. M. schrieb: > Dann zeig doch mal eine R-Anwendung in Assembler... :-D Da gibts nix zum Lachen, sonst würd ich jetzt im Kalten sitzen ;-) An eine Regelung zur Raumtemperatur müssen keine hohen Anforderungen gestellt werden- wenn man's denn richtig macht. Überhaupt ist MSR fürs SmartHome eine gemächliche Angelegenheit: Messwerte für Temperatur, Feuchte, Druck, Helligkeit, CO2 usw. fallen nicht im Tausendstel-Sekundentakt an, digitale Ein/Ausgaben z.B. einer Tür-Geöffnet Anzeige oder eines Fensteröffners oder Lampe nicht im kHz Bereich usw. usf. 8-Bit MSR ohne große Berechnungen und Datenmengen im Reinformat. Das ist es immer woran ich denken muß, wenn mir selbsternannte Koryphäen hier die Verwendung von bürokratischem C- am besten auf 32-Bit Technik- raten ;-) Thomas E. schrieb: > Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal > um diese Funktion erweitert. Das ist aber schön für Dich. Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen werde. Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die bloße Register-Initialisierung noch nicht die großen Unterschiede bringt. Eher ist da der bürokratische Aufwand, veranschaulicht im Quelltext interessant. Immerhin hast Du den in Deinem Nonsens-Beispiel gut herausgearbeitet ;-)
Moby A. schrieb: > Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist > bei Controllern in vollem Gange. Also, bedient Euch ;-) Das tun wir gerne - es ist schön zu sehen, dass mein vor zehn Jahren für AVRs geschriebener C-Code ohne große Probleme auf den neuen Architekturen läuft und dank der Leistungsfähigkeit Aufgaben wie Grafikausgabe oder Bildverarbeitung, die früher in (teuren) eigenen Modulen laufen mussten, vom Controller selbst übernommern werden. Also: weniger Zeitaufwand, weniger Hardwareaufwand = mehr Geld für mich :-)
P. M. schrieb: > Wenn du auch nur auf etwas eingehen würdest, dann hättest du vor rund > 1000 Beiträgen eingesehen: Ja, ihr habt recht, Assembler ist nur für > sehr wenige Spezialfälle die erste Wahl, im grossen und ganzen ist die > Programmierung in C aber weit überlegen. Dann hättest du etwas > gelernt, und wir hätten weniger von unserer Zeit verschwendet. Ich seh schon, es ist Dir die Mühe gar nicht wert. Soooo hab ich das erwartet ;-) Auf die (gefühlte) Zeitverschwendung von irgend jemandem hab ich keinen Einfluß. Eher tuts mir manchmal um die eigene leid. Niemand ist gezwungen, hier seinen Senf hinzuzugeben. Wenn dennoch soviele Beiträge zusammenkommen liegts aber vielleicht´a) an meiner Ernsthaftigkeit und b) daran, daß die meisten wohl die Vorteilen von Asm anerkennen, dies aber gegenüber einem dahergelaufenen Bastler partout nicht zugegeben werden kann. Immerhin stellt das auch eine Teilmenge persönlicher Investitionen, Lernzeit oder gar Studienzeit in Frage ;-) Denk mal darüber nach!
>So ist es. Die Vorteile von Asm sind wie in Stein gemeißelt, da beißt >man sich nur die Zähne dran aus! Dann präsentiere doch mal Leute, für die das nicht nur Hobby ist. Wen kennst DU, der beruflich ASM programmiert?? >Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen >werde. Warum sollen wir das dann tun? Die faire Aufgabe, eine ANforderung in Klartext zu schreiben und durch dich in ASM und andere in C umzusetzen, hast du abgeleht.
Chris D. schrieb: > Das tun wir gerne - es ist schön zu sehen, dass mein vor zehn Jahren für > AVRs geschriebener C-Code ohne große Probleme auf den neuen > Architekturen läuft und dank der Leistungsfähigkeit Aufgaben wie > Grafikausgabe oder Bildverarbeitung, die früher in (teuren) eigenen > Modulen laufen mussten, vom Controller selbst übernommern werden. Prima. Wenn man Grafik-Ausgaben und Bildverarbeitung hat und haben will. Fürs SmartHome brauchst Du das aber nicht unbedingt. Entweder, weil mans günstig kaufen kann oder aber weil man Text + grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-)
Moby A. schrieb: > Thomas E. schrieb: >> Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal >> um diese Funktion erweitert. > > Das ist aber schön für Dich. > Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen > werde. Verstehe ich. Fakten würden ja stören, denn sie sind nunmal nicht mit deiner Meinung kompatibel.
Matthias L. schrieb: > Warum sollen wir das dann tun? Die faire Aufgabe, eine ANforderung in > Klartext zu schreiben und durch dich in ASM und andere in C umzusetzen, > hast du abgeleht. Die Anforderungen und die simple Funktion sind längst ausreichendst dokumentiert. Eine Ausrede, die fauler nicht sein kann. Matthias L. schrieb: > Dann präsentiere doch mal Leute, für die das nicht nur Hobby ist. Wen > kennst DU, der beruflich ASM programmiert?? Ich rede fürs Hobby, klar. Was aber nicht bedeutet, daß die gleiche Vorgehensweise nicht auch zahlreichen Firmen-MSR-Projekten auf ähnlichem Niveau gut täte! Aber mir ist klar, daß beruflich noch weitere Prioritäten eine Rolle spielen. Nur- um die gehts mir gar nicht. Mir gehts nur um den Vergleich von Asm vs. C. Im Ressourcen-Bedarf, im bürokratischen Aufwand, im Lernaufwand. Immer schön gemessen an den Bedürfnissen eines konkreten Projekts aus dem hinlänglich umrissenen Einsatzbereich.
Moby A. schrieb: > Entweder, weil mans günstig kaufen kann oder aber weil man Text + > grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-) Da hast Du dich nun aber mächtig ins Zeug gelegt. Einen Webserver in ASM mit grafischer Ausgabe zu programmieren. Wäre doch toll wenn Du das unter Code&Projekt veröffentlichen würdest. Dann wärst du wirklich der ASM Gott
:
Bearbeitet durch User
P. M. schrieb: > Verstehe ich. Fakten würden ja stören, denn sie sind nunmal nicht mit > deiner Meinung kompatibel. Nö. Mit meiner Zeit. Eingebracht hab ich zur Demonstration der Asm-Vorteile immerhin ein größeres Projekt was wirklich was Sinnvolles tut (und bei mir schon im Einsatz ist). "Größeres" sag ich deshalb weil es für die Allermeisten hier tatsächlich schon "zu groß" zur Analyse und zum Nachbau ist ;-)
Moby A. schrieb: > Fürs SmartHome brauchst Du das aber nicht unbedingt. > Entweder, weil mans günstig kaufen kann oder aber weil man Text + > grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-) Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren und tonnenweise ineffiziente Software ;-) Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf erledigt das hier alles ein einziger, preiswerter, schneller, hocheffizienter und stromsparender Chip ;-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > tonnenweise ineffiziente Software ;-) Das sind aber keine (m)hobbytypischen 8-bit MSR-Anwendungen... :-D
Ist doch merkwürdig, Moby ist so gegen C. Eigentlich sollte er konsequenterweise jegliche Software und Module ablehnen und nicht benutzen, die mit/in C geschrieben geschrieben wurden. Also es sollte weder Windows, noch Linux, oder auch kein Mac benutzen. Er sollte auch niemals einen Router für Internet einsetzen oder andere Geräte mit µC kaufen, denn die könnten alle mit dem verpönten C belastet sein. Genau so wie ein Veganer auch niemals ein Ei essen wird. Er ist einfach nicht konsequent.
Markus M. schrieb: > Da hast Du dich nun aber mächtig ins Zeug gelegt. Einen Webserver in ASM > mit grafischer Ausgabe zu programmieren. Den brauchts dazu aber nicht. Weißt Du vermutlich... Und Asm-Gott wollte ich allen Unterstellungen zum Trotz nie werden ;-) Michael K. schrieb: > Woher willst Du das wissen wenn Du noch niemals überprüft hast welch > eleganten Konstruktionen ein C Compiler zustande bekommt ? Deine Eleganz in allen Ehren, mein Projekt ist trotzdem seit Monaten ungeschlagen ;-) > Nun ist es ein Nachteil von C den gröbsten Blödsinn von mir abzufangen > und ein Vorteil von ASM jedes Nachlassen der Konzentration sofort und > unmittelbar aufs härteste zu bestrafen ? Gebratene Tauben fliegen einem nirgendwo in den offenen Mund. 99% meiner Fehler gehen auf Fehler im PAP bzw. auf in der Praxis auftretende, seltene Messwert-Konstellationen oder Protokoll-Konflikte zurück- die man nicht im Fokus hatte. Das wäre alles 1:1 bei C dasselbe Problem. Löse Dich von der Vorstellung, es ginge bei Asm vorrangig darum, einen großen Instruktions Flag-Zirkus oder die Register-Verwendung zu beherrschen. > Dank Yalus Code wissen wir das C besser optimiert, selbts bei kleinsten > Programmen. > C fängt meine Fehler ab, ASM lässt mich voll reinrauschen. Siehe weiter oben und das, was ich gerade sagte! > C kann ich jederzeit und überall in jede Richtung erweitern, umbauen, > eindampfen und der Compiler regelt das schon hinter den Kulissen. > ASM braucht Übung, Vorbereitung, System und wenn ich da Mist mache dann > bin ich fällig und kann nicht mehr vor und nicht zurück ohne alles neu > zu schreiben. Unfug. Übung, Vorbereitung und System vorausgesetzt- was kein zusätzliches Studium eines ganzen Hochsprachen-Universums erfordert! > Bei C+IDE ist debuggen so schwer wie in der Nase bohren, bei ASM muss > ich erst einen Batzen Routinen für dieses und jedes fertig haben und > dann auch jeweils ganz genau wissen was ich in diesem Programteil machen > darf und was nicht. Richtig. Die hat man. Das ist die Vorbereitung. Mit System wird dann verknüpft. Indem ich (durch Asm) bei 8 Bit AVR bleiben kann ist das nur eine einmalige Investition. Hinzu kommt: Die AVR-Hardware ist überschaubar. > Große C Programme schreibe ich so wie kleine und die Codedichte ist > immer gleich ... aber kleiner als bei Asm-Programmen für bis mittelgroße Projekte. > Kleine ASM Programme optimiere ich bis aufs Blut für jedes Bit für große > macht man copy paste und verschenkt viel Optimierungspotential weil man > den Überblick sonst nicht behalten kann. Du optimierst? In Asm? Na bravo- genau das mach ich ja auch! Bei größeren Programmen verschenkt man weniger Potential als Du hier vorgibst- wenn man nämlich vorhandenes, effizientes Codematerial nur miteinander verknüpft. Meine Verschwendung bei größeren Programmen für mehr Übersicht besteht im wesentlichen nur darin, daß ich die enthaltenen sequentiell abzuarbeitenden Bausteine in Form einer Call-Liste aufrufe, die sich auch leicht abändern lässt. In einem finalen Schritt könnte man die Funktionalität zusammenfassen, darunter leidet aber die Übersicht mehr als daß es der gesparte Flashspeicher wert ist. > In C kann ich jederzeit ohne großen Aufwand die MCU Familie wechseln in > ASM muß ich alles neu schreiben. Und ich brauch gar nicht erst wechseln- das ist gerade der gradiosen Asm-Effizienz geschuldet ;-)
Chris D. schrieb: > Moby A. schrieb: > >> Fürs SmartHome brauchst Du das aber nicht unbedingt. >> Entweder, weil mans günstig kaufen kann oder aber weil man Text + >> grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-) > > Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen > Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren > und tonnenweise ineffiziente Software ;-) > > Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf > erledigt das hier alles ein einziger, preiswerter, schneller, > hocheffizienter und stromsparender Chip ;-) Wenn ich jetzt verraten würde, daß ich für MSR-Anwendungen im Hausbereiche gerade JavaScript und Lua evaluiere, dann würde ich auf den ASM-Scheiterhaufen geführt werden. Aber so hab ich Web und Logging und graphische Verknüpfung (node-red) und das alles Dank V8-Engine in Compiler-Speed. Ging natürlich auch in ASM, aber in meinem Alter muß es unter Jahren fertig werden.
Chris D. schrieb: > Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen > Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren > und tonnenweise ineffiziente Software ;-) Aber woher denn. Das schickt mein XPort ins Netz ;-) > Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf > erledigt das hier alles ein einziger, preiswerter, schneller, > hocheffizienter und stromsparender Chip ; Super. Ja doch. Wär von der Hardware-Seite her effizienter auch wenn Du mit "irrsinnig" jetzt maßlos übertreibst. In der Praxis ist man Hardware-modular aber wesentlich flexibler. Warum schließlich soll ich mich mit Grafik-Ausgaben und Bildverarbeitung abrackern wenn das alles fertig zu haben ist? Markus M. schrieb: > Also es sollte weder Windows, noch Linux, oder auch kein Mac benutzen. > Er sollte auch niemals einen Router für Internet einsetzen oder andere > Geräte mit µC kaufen, denn die könnten alle mit dem verpönten C belastet > sein. Was für ein Gelaber... Ich hoffe und nehme aber an mit Augenzwinkern ;-) In diesem Sinne bis morgen. Moby muß früh raus ;-(
Moby A. schrieb: > Ich rede fürs Hobby, klar. Was aber nicht bedeutet, daß die gleiche > Vorgehensweise nicht auch zahlreichen Firmen-MSR-Projekten auf ähnlichem > Niveau gut täte! Aber mir ist klar, daß beruflich noch weitere > Prioritäten eine Rolle spielen. Nur- um die gehts mir gar nicht. Mir > gehts nur um den Vergleich von Asm vs. C. Im Ressourcen-Bedarf, im > bürokratischen Aufwand, im Lernaufwand. Immer schön gemessen an den > Bedürfnissen eines konkreten Projekts aus dem hinlänglich umrissenen > Einsatzbereich. Ich identifiziere mindestens 5 Punkte in diesem Satz, die lang und breit widerlegt wurden. Wo in der Fachwelt nun wirklich keine Zweifel mehr bestehen. Was du mit einer sehr kurzen Recherche oder ein paar eigenen C Experimenten problemlos nachvollziehen könntest. Das ist ungefähr das, was interessierte/intelligente Leute machen, wenn sie in einer Diskussion auf Gegenrede stossen. Du hingegen erfindest ein absurdes Netz an Bedingungen, die erfüllt sein müssen, damit du allenfalls bereit wärst, dich von der Gegenposition überzeugen zu lassen. Merkst du eigentlich nicht, wie dumm und hinderlich das für dich selbst ist?
Moby A. schrieb: > Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die > bloße Register-Initialisierung noch nicht die großen Unterschiede > bringt. Eher ist da der bürokratische Aufwand, veranschaulicht im > Quelltext interessant. Jein. Es stimmt wohl, dass eine handelsübliche Zeile C-Code länger ist als eine Zeile Assembler. Allerdings ist die C-Zeile aber auch vielfach mächtiger. Kleines Beispiel: Über ein Array von ADC-Messwerten (10 Bit) iterieren und den kleinsten Wert heraussuchen. In C kriegt man das in 2 Zeilen, vielleicht 4-5 wenns besser lesbar sein soll. In ASM schätze ich wirds länger. Wie bewertest du also "Bürokratie"? Anzahl der Zeilen? Anzahl der Spalten? Anzahl der Zeichen? Oder war "Bürokratie" bei dir das Angeben-müssen von Datentypen? Nun, dieses "Argument" hab ich dir ja schon mal demontiert. Und, das Format heutiger Bildschirme im Hinterkopf, was machst du eigentlich mit dem ganzen Platz links und rechts vom Listing?!
le x. schrieb: > Über ein Array von ADC-Messwerten (10 Bit) iterieren und den kleinsten > Wert heraussuchen. Das ist doch kein 8bit MSR. Ausserdem kann man sowas als externes Modul dazukaufen.
Moby A. schrieb: > Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen > werde. Das hat niemand erwartet. Von nichts kommt einfach nichts. Das ist jedem hier klar. > Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die > bloße Register-Initialisierung noch nicht die großen Unterschiede > bringt. Nur geht es nicht nur um die blosse Registerinitialisierung. Aber das kannst du ja auch nicht wissen. > Eher ist da der bürokratische Aufwand, veranschaulicht im > Quelltext interessant. Den Quelltext wirst du nicht zu sehen bekommen. Wozu auch? Verstehst es ja ohnehin nicht. > Immerhin hast Du den in Deinem Nonsens-Beispiel gut herausgearbeitet Nonsens nennst du das jetzt. Mal sehen, was als nächstes kommt, um von deinen Unzulänglichkeiten, effizienten Asm-Code zu produzieren, abzulenken. Dieser Code funktioniert. Er macht exakt das, was er soll. Und das mit absoluter Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Da kommst du mit deinem Dödelprogramm nur nicht im entferntesten heran. Das ärgert dich natürlich. [deletia] mfg.
:
Bearbeitet durch Moderator
Moby A. schrieb: > P. M. schrieb: > >> Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst >> erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich >> weitgehend einig > > ... daß sich Assembler im umrissenen Einsatzgebiet nicht schlagen lässt, > meinst Du? Die C-Koryphäen schleichen wie Katzen um den heißen Brei > meines Projekts und keiner traut sich. Woran es allerdings nicht fehlt > ist allerlei Smalltalk und Ausreden so wie diese hier: > >> kann sie auf einschlägige Erfahrung >> verweisen > >> Wobei sie natürlich definiert, was >> widerlegt heisst > > Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar: > Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität. > Am Ende siegt aber dann doch die Angst ;-) Ja Moby. Die C-Koryphäen sind mit ihrem Latein nun am Ende. Dafür sind aber wissenschaftliche Einrichtungen an deutschen Hochschulen und Universitäten auf dein geniales Schaffen aufmerksam geworden und widmen nun ihre Forschungen in deine Richtung. Außerdem munkelt man in Fachkreisen, dass dein genialer Code verfilmt werden soll. Bekannte Kurzfilmkoryphäen schlagen sich um das Drehbuch, welches nur 5 Seiten hat! Die Filmmusik wird der geniale A.S. Melchior komponieren. Er kommt mit nur 5 Tönen und 2 Instrumenten aus. Koreographen arbeiten mit Hochdruck an einem Ballett, in dem nur dein Code Einbeinigen getanzt von wird. Eine ganz große C-Koryphäe wird sich deinen Code sogar auf sein bestes Stück tätowieren lassen. Von der Länge passt er zum Glück! Alter, du bist mein Held. Mit so einer wahnsinns Portion Selbstüberschätzung lebt es sich doch einfach prima. Nur leider interessiert dein Code hier niemand mehr. Warum wohl? Denk mal darüber nach.
:
Bearbeitet durch User
Moby A. schrieb: > Mir > gehts nur um den Vergleich von Asm vs. C. Warum? Bist du nicht mehr glücklich mit Asm? Für dich und deine Anwendungen ist doch ASM genau das Richtige. Du beherrscht es, dein Programm läuft und der Hochsprachenlernaufwand lohnt dafür wirklich nicht. Ähm, worum geht es in dem Thread noch mal?
Witkatz :. schrieb: > Ähm, worum geht es in dem Thread noch mal? „Assembler auf dem Weg nach vorn“ – auch wenn es halt nur durch eine andere Wortwahl bei den Suchbegriffen ist. ;-)
Jörg W. schrieb: >> Ähm, worum geht es in dem Thread noch mal? > > „Assembler auf dem Weg nach vorn“ – auch wenn es halt nur durch eine > andere Wortwahl bei den Suchbegriffen ist. ;-) Ach ja, danke. Assembler, ach was waren das für entschleunigte Zeiten... ;-) Ich glaube, heute ist das was für Puristen und man muss es einfach lieben, so wie Naked Bikes und Oldtimer. Vielleicht ist an der Statistik wirklich was dran und es deutet sich ein nostalgischer Modetrend für Assembler und vergessene CPU's an?
:
Bearbeitet durch User
Angehängte Dateien:
-
asMusical.jpg
61 KB
Markus M. schrieb: > Koreographen arbeiten mit Hochdruck an einem Ballett, in dem nur dein > Code Einbeinigen getanzt von wird. Hamburg ist bereit. mfg.
Witkatz :. schrieb: > Warum? Bist du nicht mehr glücklich mit Asm? Für dich und deine > Anwendungen ist doch ASM genau das Richtige. Du beherrscht es, dein > Programm läuft und der Hochsprachenlernaufwand lohnt dafür wirklich > nicht. > > Ähm, worum geht es in dem Thread noch mal? Warum sollte bloß ich damit glücklich werden? Warum sollte ich meine Aussage nicht mit Code beweisen dürfen? Thomas E. schrieb: > Da kommst du mit deinem Dödelprogramm nur nicht im entferntesten heran. > Das ärgert dich natürlich. Warum denn? Das würde ja zumindest mal den gleichen Funktionsumfang voraussetzen. Da bist Du weit entfernt von ;-) Markus M. schrieb: > Nur leider interessiert dein Code hier niemand mehr. > Warum wohl? Denk mal darüber nach. Weil er sich mit C nicht toppen läßt vielleicht? Thomas E. schrieb: > Hamburg ist bereit. Klasse! Witkatz :. schrieb: > Vielleicht ist an der Statistik wirklich was dran und es deutet sich ein > nostalgischer Modetrend für Assembler und vergessene CPU's an? Dafür wurde eine halbwegs plausible Erklärung längst geliefert! Markus M. schrieb: > Ja Moby. Die C-Koryphäen sind mit ihrem Latein nun am Ende. Dafür sind > aber wissenschaftliche Einrichtungen an deutschen Hochschulen und > Universitäten auf dein geniales Schaffen aufmerksam geworden und widmen > nun ihre Forschungen in deine Richtung. Du übertreibst meine Ambitionen. So wie Übertreibung hier eines der beliebtesten Stilmittel gedemütigter C-Koryphäen ist ;-) Wieder mal nur Lächerlich-Machen statt harter Fakten. Der oft frequentierte Notausgang aus der Manege ;-)
le x. schrieb: > Allerdings ist die C-Zeile aber auch vielfach mächtiger. Aber die Komplexität der Ausdrücke! Aber die Kryptizität der Ausdrücke! > Wie bewertest du also "Bürokratie"? Anzahl der Zeilen? Anzahl der > Spalten? Anzahl der Zeichen? Bürokratie= Gesamtheit des Sprachumfangs, Regeln, Vorschriften, Typen, Operatoren, Deklarationen usw. > Oder war "Bürokratie" bei dir das Angeben-müssen von Datentypen? > Nun, dieses "Argument" hab ich dir ja schon mal demontiert. Demontage? Was für ein großes Wort für dieses überflüssigste aller überflüssigen Konstrukte! Mein absoluter Liebling: Der Cast-Operator! Von der Abbildung konkreter Projekt-Notwendigkeiten soweit entfernt wie eine Galaxie im Dark Field. > Und, das Format heutiger Bildschirme im Hinterkopf, was machst du > eigentlich mit dem ganzen Platz links und rechts vom Listing?! Vermutlich fühlst Du Dich schlecht wenn da nix mehr zu lesen ist. Ist das eine unangenehme Leere? In Asm passen ggf. noch schöne Kommentare hin!
Moby deine Kommentare über C hören sich so ähnlich an wie: Feuer zu machen mit einem Feuerzeug ist so Komplexität und Kryptisch da kann man an einem Regler die Flammengröße einstellen und man muss noch auf einen Knopf drücken und kann sich sooo schnell verbrennen. Ich bleibe bei meinem Feuerstein, da hab ich die Funkenbildung noch selbst im Griff.
P. M. schrieb: > Ich identifiziere mindestens 5 Punkte in diesem Satz, die lang und breit > widerlegt wurden. Wo in der Fachwelt nun wirklich keine Zweifel mehr > bestehen. Cool, wie Du für die Fachwelt sprichst. Cool, wie Du mir die Fachwelt um die Ohren haust. Leider seh ich für den umrissenen Einsatzbereich rein gar nichts widerlegt! > Du hingegen erfindest ein absurdes Netz an Bedingungen, die erfüllt sein > müssen Erfüllt sein muß gar nichts außer von 100% Funktion. Schon mal gar nicht im Hobby. Darum gehts hier aber nicht. > Merkst du eigentlich nicht, wie dumm und > hinderlich das für dich selbst ist? Ganz und gar nicht. Die Arbeit und das praktische Ergebnis meiner Projekte beweisen mir jeden Tag das Gegenteil ;-)
Markus M. schrieb: > Ich bleibe bei meinem Feuerstein, da hab ich die Funkenbildung noch > selbst im Griff. Ich bleibe bei dem was für die konkrete Aufgabenstellung am einfachsten ist. Das kann ggf. auch eine Blink-LED sein ;-) > M oby's > S imply > R esults
Carl D. schrieb: > Wenn ich jetzt verraten würde, daß ich für MSR-Anwendungen im > Hausbereiche gerade JavaScript und Lua evaluiere, dann würde ich auf den > ASM-Scheiterhaufen geführt werden. Aber so hab ich Web und Logging und > graphische Verknüpfung (node-red) und das alles Dank V8-Engine in > Compiler-Speed. Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt bist? Für MSR-Anwendungen im Hausbereich? Wenn aber etwas schnell fertig werden soll und Du mit Lua vertraut bist- warum nicht. Das berührt die Diskussion Asm vs. Hochsprache in punkto Ressourceneinsparung und Effizienz aber in keinster Weise. Jonny O. schrieb: > Ich glaube du unterschätzt den Begriff "MSR" erheblich. Nein. Ich rede hier von 8-Bit MSR für datenarme und weniger rechenintensive Anwendungen. Das es da viel mehr + anspruchsvolleres und auch die Berechtigung für Hochspracheneinsatz (ggf. auf höherbittigen MCs) gibt streitet doch niemand ab ! > Jedenfalls ist > die Reglungstechnik eine Wissenschaft für sich und der Komplexitätsgrad > kann bei weitem "kleine Tiny-Sachen" übersteigen. Durchaus auch im > Hobbybereich. Im Hobbybereich? Aber sicher. Fürs SmartHome reicht 8-Bit MSR aber locker aus. Wenn in Zukunft mehr Intelligenz in die If/Then Abläufe reinkommt möglicherweise nicht mehr. Aber die IOT Auswertung soll sich ja dann längst auf Servern im Netz abspielen. MSR in Sensor/Aktorknoten wird sich nicht wesentlich ändern. > Ich denke du stellst dir unter MSR immer etwas Simples vor. Das mag hie > aber es gibt viele Anwendungen, da ist ein Cortex > sinnig. Kein Thema.
Moby A. schrieb: > Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt > bist? ... Moby A. schrieb: > Aber die IOT Auswertung soll sich ja dann längst auf Servern im Netz > abspielen. Jaja, die noch mehr Stromschluckende Hardware GRINS Moby A. schrieb: > Ich rede hier von 8-Bit MSR für datenarme und weniger > rechenintensive Anwendungen. Und wieso sollte man für solche Anwendungen überhaupt sich die Mühe machen das in Assembler mit maximaler Effizienz zu gestalten? KOPFSCHÜTTEL Ich habe immer noch nicht verstanden wieso ich Assembler lernen sollte, wo ich doch schon C kann.
Moby A. schrieb: > Warum sollte bloß ich damit glücklich werden? > Warum sollte ich meine Aussage nicht mit Code beweisen dürfen? Deine Aussage ist einzig und allein, dass man für eine simple Steuerungsaufgabe keine Hochsprache lernen muss. Dein Code funktioniert und du hast es bewiesen. Warum reicht dir das nicht?
Markus M. schrieb: > Moby A. schrieb: >> Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt >> bist? Jaja, schönes Argument den Stromverbrauch anzuführen aber im gleichen Zuge auf Gedeih und Verderb bei einer uralten Architektur zu bleiben. Auf eine Hardware festgelegt bist auch nur Du mit Deinem ASM Gefriggel. Moby A. schrieb: > Mein absoluter Liebling: Der Cast-Operator! Von der Abbildung konkreter > Projekt-Notwendigkeiten soweit entfernt wie eine Galaxie im Dark Field. [Zitat] Castings dienen dazu, die Bedeutung von Daten anders zu interpretieren, bzw. der Programmiersprache zu sagen, dass man sich bewusst ist, was man da eigentlich tut. https://www.proggen.org/doku.php?id=c:cast [Zitat Ende] Wäre vieleicht doch mal ganz gut für Dich ein C Anfänger Tutorial durchzuarbeiten. Du würdest dann erkennen können das in genau solchen Dingen die großen Vorteile einer dich unterstützenden Hochsprache bestehen. Vergiss das, DU würdest das in 100 Jahren nicht erkennen können. Moby A. schrieb: > Nein. Ich rede hier von 8-Bit MSR für datenarme und weniger > rechenintensive Anwendungen. Das es da viel mehr + anspruchsvolleres und > auch die Berechtigung für Hochspracheneinsatz (ggf. auf höherbittigen > MCs) gibt streitet doch niemand ab ! Also besteht die Effizienz von ASM darin das die Erweiterbarkeit da aufhört wo ich auf Grund einer veränderten Problemstellung einen Messwert direkt im Knoten verarbeiten müsste. Die Effizient von ASM ist also dadurch gegeben das ich popelige Messwerte an einen Server übermitteln muss damit der mir die Berechnungen ausführt und zurückschickt. Meine Güte ist das armseelig. Welche verschrobenen Ansichten Du doch hast was unter MSR zu verstehen ist. MÜR (Messen, Übermitteln, Steuern) würde es wohl mehr treffen. Deine Effizienz besteht doch nur darin die Finger von allem zu lassen was einen gewissen Komplexitätsgrad überschreitet. Das nennst Du dann Übung, Vorbereitung, System, frei nach dem Motto: Sei Schlau, bleib Dumm. Damit bist die die Katzenberger der MCU Programmierung. Bravo!
>Übung, Vorbereitung, System,
der Satz ist sowas von Inhaltslos..
kennt jemand irgenwas, wo man das nicht braucht?
sogar für den Gang aufs Klo braucht man Übung, Vorbereitung, und System
..
:
Bearbeitet durch User
Markus M. schrieb: > Jaja, die noch mehr Stromschluckende Hardware GRINS Serverhardware in irgend einem Rechenzentrum muß mich doch zu Hause nicht interessieren! Davon abgesehen, von zukünftiger Datenauswertung war die Rede. > Moby A. schrieb: > Ich rede hier von 8-Bit MSR für datenarme und weniger > rechenintensive Anwendungen. > > Und wieso sollte man für solche Anwendungen überhaupt sich die Mühe > machen das in Assembler mit maximaler Effizienz zu gestalten? > KOPFSCHÜTTEL Gleichfalls Kopfschüttel. Wozu sollte man sich dazu die C-Bürokratie aufbürden? Daß Asm mehr Effizienz liefert ist da nur ein Zusatz-Bonus ;-) > Ich habe immer noch nicht verstanden wieso ich Assembler lernen sollte, > wo ich doch schon C kann. Nun, in diesem Fall bleib doch bei C. Ist ja auch nicht alles schlecht dran ;-)
Robert L. schrieb: > Übung, Vorbereitung, System, > > der Satz ist sowas von Inhaltslos.. Was damit in Zusammenhang mit Asm gemeint ist hab ich hinreichend erläutert. Das trieft nur so vor Inhalt ;-) Witkatz :. schrieb: > Deine Aussage ist einzig und allein, dass man für eine simple > Steuerungsaufgabe keine Hochsprache lernen muss. Dein Code funktioniert > und du hast es bewiesen. Prima. Und gaaanz so simpel braucht die MSR Aufgabe nicht zu sein ;-) Michael K. schrieb: > Also besteht die Effizienz von ASM darin das die Erweiterbarkeit da > aufhört wo ich auf Grund einer veränderten Problemstellung einen > Messwert direkt im Knoten verarbeiten müsste. Asm begrenzt Erweiterbarkeit in keinster Weise, kann sich auf eine gegebene Hardware aber auch optimal einstellen. > Die Effizient von ASM ist also dadurch gegeben das ich popelige > Messwerte an einen Server übermitteln muss damit der mir die > Berechnungen ausführt und zurückschickt. Da hab ich von der Zukunft des IOT geredet. Aktor/Sensor Hard/Software und einfache MSR Steuerungen nehmen sich sonst nichts. > Meine Güte ist das armseelig. Wie Du meine Aussagen zur Kenntnis nimmst, ja. > Deine Effizienz besteht doch nur darin die Finger von allem zu lassen > was einen gewissen Komplexitätsgrad überschreitet. Richtig. Z.B. bürokratisches C und 32-Bit Controller- beides unnötig, übertrieben und umständlich für typische 8-Bit MSR Anwendungen! > Sei Schlau, bleib Dumm. Falsch. Sei schlau, machs simpel :-)
:
Bearbeitet durch User
Karl H. schrieb: > Das was du unter 'typisch' verstehst, ist es eben für die meisten > anderen nicht. Nochmal: Typische 8-Bit MSR Anwendungen verarbeiten ein paar Dutzend max. 16 bittiger Messwerte und benötigen mit Asm keine 32 Bit Power, weil sie nicht rechen- und datenintensiv sind. Fürs SmartHome als einem typischen Einsatzort hab ich hier noch keine typischen Gegenbeispiele gehört ;-) > völlig egal, ob das Programm im Flash 18 oder doch 21% belegt oder > nicht. Ob das im konkreten Fall egal ist weiß ich nicht. Je mehr Reserven für Erweiterungen desto besser. Mit Effizienz und Ressourcensparung beginnt man besser immer bei Null und nicht irgendwo im Projekt!
:
Bearbeitet durch User
Moby A. schrieb: > P. M. schrieb: >> Dann zeig doch mal eine R-Anwendung in Assembler... :-D > > Da gibts nix zum Lachen, sonst würd ich jetzt im Kalten sitzen ;-) > An eine Regelung zur Raumtemperatur müssen keine hohen Anforderungen > gestellt werden- wenn man's denn richtig macht. Haha...auch hier sieht man wieder dein begrenztes Weltbild: Hat der Moby eine einfache 2-Punkt-Regelung für seine Heizung gebastelt und das genügt bereits als Beweis, dass Assembler für R völlig ausreicht. Moby A. schrieb: >> Deine Effizienz besteht doch nur darin die Finger von allem zu lassen >> was einen gewissen Komplexitätsgrad überschreitet. > > Richtig. Z.B. bürokratisches C und 32-Bit Controller- beides unnötig, > übertrieben und umständlich für typische 8-Bit MSR Anwendungen! Zu umständlich für dich, weil du es nicht kannst. Alle anderen profitieren von massiv effizienterer Entwicklung. Der ganze Thread dient dir doch eigentlich nur dazu, deinen begrenzten Fähigkeiten- und Wissensstand schönzureden. Moby A. schrieb: > Cool, wie Du für die Fachwelt sprichst. > Cool, wie Du mir die Fachwelt um die Ohren haust. > Leider seh ich für den umrissenen Einsatzbereich rein gar nichts > widerlegt! Fakt ist, dass ich mit Software (in C/C++) Geld verdiene und du nicht. Dass ich eine komplette Ausbildung darin habe und du nicht. Dass dies auch für die anderen Leute gilt, die dir widersprechen. Ich mag dieses Argument normalerweise nicht so, aber hier muss man einfach mal feststellen: Der hat keine Ahnung, der versteht noch nicht mal die Grundlagen des besprochenen Themas.
Moby A. schrieb: > Du optimierst? In Asm? Na bravo- genau das mach ich ja auch! Ach so? > Bei größeren Programmen verschenkt man weniger Potential als Du hier > vorgibst- wenn man nämlich vorhandenes, effizientes Codematerial nur > miteinander verknüpft. Meine Verschwendung bei größeren Programmen für > mehr Übersicht besteht im wesentlichen nur darin, daß ich die > enthaltenen sequentiell abzuarbeitenden Bausteine in Form einer > Call-Liste aufrufe, die sich auch leicht abändern lässt. Das ist doch keine Optimierung! Das ist Speicher- und Rechenzeitverschwendung! Ich versuch mal ein Beispiel: Man möchte einen Mittelwert bilden, z.B. aus verschiedenen Messungen vom ADC. Nehmen wir mal für den Anfang zwei Messungen. Da steht dann ziemlich am Anfang in einer C-Datei:
1 | #define ANZAHL 2
|
Dann kommt eine Funktion die irgendwas Interessantes macht und am Ende steht dort:
1 | return wert / ANZAHL; |
Zur Erklärung des kryptischen C-Codes: 'define' gibt's in Assembler auch. Hat die gleiche Bedeutung. Dort heißt es allerdings (kürzer und hochoptimiert) nur 'def'. Die andere Zeile ins Deutsche übersetzt: Kehre mit dem Ergebnis der Berechnung 'wert' geteilt durch 'ANZAHL' zurück. Für 'return' gilt das gleiche wie oben. Heißt in Assembler stromsparend 'ret'. Nur: Wo ist jetzt das Ergebnis? Natüüürlich: Dazu gibt es einen Hinweis als Kommentar am Anfang der Funktion, wo alle verwendeten Register dokumentiert sind und welche für Datenüber- und -rückgabe verwendet werden. (Eventuell auch noch der Hinweis auf die Verwendung des Stacks.) Was für ein Schreibaufwand ;-) Die Assembler-Zeile vor dem 'ret' ist ganz einfach. Einmal nach rechts schieben - fertig! (Ich verrate dir mal was: Das kennt der Compiler. Das macht der genauso!) Nun stellt sich im Laborversuch heraus: Nur zwei Werte sind zur Mittelwertberechnung zu wenig, man müsste es mal mit vier probieren (Okay, kein Problem, eine Zeile dazu). Mist. Besser wären drei! Noch geiler wäre es vielleicht, nur Differenzen zu messen. Oops, da werden die Zahlen ja negativ ... Zumindest wird das niemals eine Funktion für die Codesammlung! [ Geht jetzt weit am Thema vorbei: Das wäre ein Fall für C++ :-) ] Gleichzeitig kann die Definition 'ANZAHL' hervorragend beim Einlesen der Messwerte verwendet werden :) Wie von Zauberhand erstellt der Compiler daraus den optimalen Assembler-Code. > In einem > finalen Schritt könnte man die Funktionalität zusammenfassen, darunter > leidet aber die Übersicht mehr als daß es der gesparte Flashspeicher > wert ist. Siehst Du, dass ist Optimierung! So macht das der Compiler! ----- Ich weiß, ist gegen eine Wand geredet. Ich hab' das aber mal gebraucht ;-)
Moby A. schrieb: > Cool, wie Du für die Fachwelt sprichst. Das steht ihm als Fachmann auch zu. > Cool, wie Du mir die Fachwelt um die Ohren haust. Das steht ihm als Fachmann auch zu. Moby A. schrieb: > Nochmal: Typische 8-Bit MSR Anwendungen verarbeiten ein paar Dutzend > max. 16 bittiger Messwerte In deinem Piffelprojekt werden doch gar keine Daten verarbeitet, sondern nur aufgenommen und weitergereicht. Von Dutzenden ganz zu schweigen. Messen beinhaltet nicht nur das Auslesen eines Wertes, sondern auch eine Verarbeitung. Die findet dort aber nicht statt. Eine Steuerung findet an der Stelle auch nicht statt. Das Thema Regelung hatten wir ja schon. Dein Projektchen ist also überhaupt keine "MSR"-Anwendung, sondern eine " "-Anwendung. Im Grunde nichts anderes als ein popeliger Datenlogger. Du trägst nur dick auf und wirfst mit Begriffen um dich, von denen du nicht das geringste verstehst. Wie ein Esoteriker. Es werden einfach Dinge behauptet und wenn es um den Nachweis geht, wird gekniffen. mfg.
P. M. schrieb: > Ich mag dieses > Argument normalerweise nicht so, aber hier muss man einfach mal > feststellen: Der hat keine Ahnung, der versteht noch nicht mal die > Grundlagen des besprochenen Themas. Da muss ich P.M. zustimmen. Das Problem ist doch, wer wenig weiß der weiß in der Regel nicht DASS er wenig weiß. Erst mit größerem Wissen über ein Fachgebiet kann man oft erst beurteilen wie es sich mit dem eigenen Wissensstand verhält, wo man Defizite hat. Außerdem erkennt man Probleme wo der Ungebildete sich denkt "Ist doch alles kein Problem!". Sehr schön ist das in diesem Thread zu beobachten: Beitrag "LED-Matrix | Einfachste methode für animationen?" Der TO hat dort augenscheinlich so wenig Ahnung von der Materie dass er garnicht weiß was er sich da vorgenommen hat. Deswegen immer wieder der Wunsch nach einer "einfachen Lösung ohne Programmieren". In der PRaxis führt dass dann dazu (im Beruf oft erlebt) dass die Wenig-Wisser kräftig auf den Putz hauen und die Fachmänner eher ruhig im Hintergrund über die Machbarkeit nachdenken. Ich habe gelernt: wenn mir jemand kommt mit "Ist doch ganz einfach..." oder "da muss man doch nur..." ist Vorsicht geboten! Auf diesen Thread bezogen: du Moby, lebst in so einer kleinen Welt dass du nicht ansatzweise erkennen kannst wie wenig du eigentlich weißt. Vielleicht nicht ganz unpassend: https://de.wikipedia.org/wiki/H%C3%B6hlengleichnis
P. M. schrieb: > Ich mag dieses > Argument normalerweise nicht so, aber hier muss man einfach mal > feststellen: Der hat keine Ahnung, der versteht noch nicht mal die > Grundlagen des besprochenen Themas. Hehe.. Ja der Ton wird etwas rauher. Aber es war zu erwarten. Es stimmt auch. Moby "Projekt" liest ein ADC und sendet in irgendwohin. Das kann man als "Messen" durchgehen lassen. Von MSR ist das weit entfernt. Ebenso ein 2/3-Punktregler. Ein richtiger Regler ist was völlig anderes. Und eine Datenverarbeitung findet auch nicht statt... Aber natürlich irrt nicht der eine Geisterfahrer, sondern die Entgegenkommenden...
Matthias L. schrieb: > Von MSR ist das weit entfernt. Nicht nur das: Es ist auch nur in dieser speziellen Konstellation nutzbar und daher für alle anderen User außer Moby selbst wertlos.
Karl H. schrieb: > Moby A. schrieb: > > Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen > Win-PC, die nur noch GHz Prozessoren stemmen. > > Das was ein heutiger PC im Hintergrund noch alles mit erledigt, kannst > du dir doch gar nicht vorstellen. Du auch nicht. Und mit der Gültigkeit meiner Aussage hat das auch wenig zu tun.
Moby A. schrieb: > Und mit der Gültigkeit meiner Aussage hat das auch wenig zu tun. Gültigkeit welcher Aussage? Wie gesagt: Du extrapolierst von 200 Byte auf 10KB. Das ist kompletter Unsinn. Nein: Dein Dreirad fährt NICHT 200 km/h - auch wenn Moby draufsitzt und Prrrmmmm Prrrrmmm macht.
Frank M. schrieb: > Dein Dreirad fährt NICHT 200 km/h Insbesondere wird es eben auch nicht in die Lage versetzt, 200 km/h zu fahren, indem man einfach das Treten beherrscht und dann „nur noch“ ausreichend schnell treten muss.
Moby A. schrieb: > Du auch nicht. Doch. Das kann er. Und ich kann das auch. Genauso wie das auch viele andere hier können. mfg.
le x. schrieb: > Ich habe gelernt: wenn mir jemand kommt mit "Ist doch ganz einfach..." > oder "da muss man doch nur..." ist Vorsicht geboten! Woher kennst du meinen Ex-Chef?
Matthias L. schrieb: > Hehe.. Ja der Ton wird etwas rauher. Man muss einfach mal. Ich mag es eigentlich nicht, in einer Diskussion laut oder unfreundlich zu werden. Aber es muss einfach mal gezeigt werden, dass wir hier nicht mehr ein Fachgespräch führen, sondern uns mit einem quengelnden Kind herumschlagen. Und da werden die Eltern ja auch mal etwas lauter :-) Und Moby, ich bin jederzeit dir zu verraten, auf welche Erfahrungen sich meine Aussagen stützen und ich bin auch jederzeit bereit, dir ein paar Tipps betreffend der Effizienz von C zu geben. Schreib einfach ne PN.
:
Bearbeitet durch User
Karl H. schrieb: "Du extrapolierst aus einer simplen Aufgabe, die du mit ein paar Anweisungen erledigen kannst auf das Verhalten von größeren Programmen. Und genau das ist nicht zulässig. Denn die zu bearbeitende Komplexität steigt nicht linear sondern mindestens exponentiell" Nein. Das lässt sich pauschal unabhängig jedweder konkreter Anwendung so nicht sagen. "Genau deshalb sind grosse Systeme auch so schwer zu schreiben, weil es mit jedem zusätzlichen Subsystem immer schwieriger wird, die Querverbinden und Verflechtungen im Auge zu behalten." Das ist solange richtig wie zusätzliche Subsysteme mehr Querverbindungen, Verflechtungen, Nebenwirkungen mitbringen. Allerdings gibt es wirksame Gegenmittel: Kapselung, funktionelle Gliederung, einheitliche Interfaces. Kurzum: System beim System-Aufbau. Die Notwendigkeit strukturierter Hochsprachen lässt sich so weit hinauszögern, weit noch aus dem 8-Bit MSR Bereich hinaus.
:
Bearbeitet durch User
Moby A. schrieb: > hinauszögern Hinauszögern trifft es gut. Ja, man kommt lange darum herum, aber es wird extrem mühsam und ineffizient. Moby A. schrieb: > Nein. Das lässt sich pauschal unabhängig jedweder konkreter Anwendung so > nicht sagen. Sagt wer? Sagt jemand, der gerade mal ein paar kleine 8-Bit-Projektchen durchgezogen und noch nie einen Code mit mehr als ein paar hundert Zeilen gesehen hat.
Moby A. schrieb: > Das ist solange richtig wie zusätzliche Subsysteme mehr > Querverbindungen, Verflechtungen, Nebenwirkungen mitbringen. Allerdings > gibt es wirksame Gegenmittel: Kapselung, funktionelle Gliederung, > einheitliche Interfaces. Kurzum: System beim System-Aufbau. Du solltest dich in Berlin bei BER bewerben. Jemanden wie dich können sie dort brauchen. Also jemanden mit System.
Frank M. schrieb: > Nein: Dein Dreirad fährt NICHT 200 km/h - auch wenn Moby draufsitzt und > Prrrmmmm Prrrrmmm macht. Das muß es auch nicht, das ist ja der Witz ;-) P. M. schrieb: > Aber es muss einfach mal gezeigt > werden, dass wir hier nicht mehr ein Fachgespräch führen, sondern uns > mit einem quengelnden Kind herumschlagen. Und da werden die Eltern ja > auch mal etwas lauter :-) Solange Diskussionen so herablassend in Überlegenheitsmanier geführt werden hab ich es besonders leicht ;-) Anders wäre der Fall wenn die angeblichen "Eltern" ihre Elternschaft mal mit besserer C-Codierung meines Projekts unter Beweis stellen würden! > Und Moby, ich bin jederzeit dir zu verraten, auf welche Erfahrungen sich > meine Aussagen stützen und ich bin auch jederzeit bereit, dir ein paar > Tipps betreffend der Effizienz von C zu geben. Gib Dir selber mal ein paar Tipps, wie sich mein Projekt in C doch noch sparender umsetzen lässt ;-)
Moby A. schrieb: > Solange Diskussionen so herablassend in Überlegenheitsmanier geführt > werden hab ich es besonders leicht ;-) Naja, wenn ein Hobbyist, der kein C kann, gegenüber 5-10 professionellen Entwicklern so überzeugt die Überlegenheit von Assembler gegenüber Hochsprachen predigt und gegen jegliche Argumente resistent ist, dann muss man einfach mal die Autoritätskeule auspacken. Und wie jetzt, du hast es leicht? Konntest du bisher irgend jemand von deinem Standpunkt überzeugen?
Moby A. schrieb: > Bürokratie= Gesamtheit des Sprachumfangs, Regeln, Vorschriften, Typen, > Operatoren, Deklarationen usw. Im Prinzip also alles was Moby nicht versteht. Komisch nur dass es genau (alle - 1) sonst verstehen.
P. M. schrieb: > Naja, wenn ein Hobbyist, der kein C kann, gegenüber 5-10 professionellen > Entwicklern so überzeugt die Überlegenheit von Assembler gegenüber > Hochsprachen predigt und gegen jegliche Argumente resistent ist, dann > muss man einfach mal die Autoritätskeule auspacken. Pack aus was Du willst... Wenn Du meinst, es könnte als "Argument" gebraucht werden. Eine Predigt ist für mich übrigens etwas, was nicht mit Code belegt ist ;-)
Moby A. schrieb: > Eine Predigt ist für mich übrigens etwas, was nicht mit Code belegt ist > ;-) Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber C, aber du kannst es nicht durch Code belegen.
Um mal wieder bisl produktiv zu werden: Im Sensorboard-Thread wurde ja mal versucht, die Anforderungen an die Software zusammenzufassen. Du hast dich damals sehr unkooperativ gezeigt, trotzdem bitte ich dich nochmal, die dortige Lsite kurz durchzusehen und falsche Anforderungen aufzuzeigen oder sogar zu korrigieren. Hier der anscheinend letzte Stand dieser Anforderungsliste:
1 | - Der Prozessor soll den internen 128kHz Takt verwenden |
2 | - es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4) |
3 | und AINP-CHANNEL2 (entspricht PB3) eingelesen werden (1) |
4 | - die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen werden |
5 | - das Einlesen soll im free-running Modus des ADC stattfinden, jeder |
6 | Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2) |
7 | - es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1) |
8 | und DINP2-LOW (entspricht PB5) eingelesen werden |
9 | - das Einlesen soll unmittelbar vor der Datenübertragung erfolgen |
10 | - es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte, versandt werden |
11 | - das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden |
12 | - ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK |
13 | (entspricht PB2) ausgegeben werden |
14 | - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden |
15 | durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden) |
16 | - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits |
17 | - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits |
18 | - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits |
19 | - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits |
20 | - Bit 20: DINP1-LOW |
21 | - Bit 21: DINP2-LOW |
22 | - Bits 22-23: Checksumme über das Datentelegram |
23 | - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in |
24 | einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird |
25 | - das Telegram soll alle 320 ms wiederholt werden; der genaue Wert |
26 | ist unkritisch |
27 | - Das Telegram soll eine Bit-Zykluszeit von ca. 10 ms haben, also 80 ms |
28 | pro Byte |
29 | - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen |
30 | - das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben |
31 | - es ist nur 1 Timerinterrupt zu verweden, andere Interrupts sind für |
32 | Erweiterungszecke reserviert |
Ich hab hierzu 2 Fragen, die ich oben gekennzeichnet habe: 1) Soll 8 mal AINP-CHANNEL1 und dann 8 mal AINP-CHANNEL2 eingelesen werden oder soll dies im Wechsel geschehen? 2) Soll zwischen den 8 Messpunkten gewartet werden (z.B. im nächsten Timer-Interrupt) oder soll eine Messung gestartet werden, sobald der ADC wieder frei ist? Kannst du dazu bitte was sagen?
sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen von Moby eh schon verloren.
P. M. schrieb: > Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler > sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber > C, aber du kannst es nicht durch Code belegen. Das behaupte ich, ja. Ausgehend von meinem existenten Code. Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen. Soweit waren wir schon ;-) le x. schrieb: > Um mal wieder bisl produktiv zu werden: Prima. > Kannst du dazu bitte was sagen? Gerne. Heute abend. Auch wenn es sinnlos ist. Obwohl längst alles dazu gesagt wurde ;-(
Werner P. schrieb: > sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen > von Moby eh schon verloren. SO IST ES !
Moby A. schrieb: > P. M. schrieb: >> Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler >> sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber >> C, aber du kannst es nicht durch Code belegen. > > Das behaupte ich, ja. Ausgehend von meinem existenten Code. Wie gross ist er denn, der Code? > Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen. Soweit > waren wir schon ;-) Eine ganze Industrie, die für schwachbrüstige Mikrocontroller wie auch für High-Performance-Anwendungen weitestgehend C und nicht Assembler verwendet, ist wohl Beweis genug, dass C gegenüber Assembler keine nennenswerten Effizienznachteile hat.
Moby A. schrieb: > Werner P. schrieb: >> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen >> von Moby eh schon verloren. > > SO IST ES ! Was für eine schwachsinnige Aussage.
Robert L. schrieb: > der Satz ist sowas von Inhaltslos.. > kennt jemand irgenwas, wo man das nicht braucht? > > sogar für den Gang aufs Klo braucht man Übung, Vorbereitung, und System > .. Das beschreibt Mobys Horizont schon sehr gut ;-)
Werner P. schrieb: > sobald Du auch nur ein Byte SRAM "verschwendest" Wobei natürlich das Abarbeiten von Interrupts (die Stack belegen) keine Verschwendung ist, auch wenn man die Aufgabe selbstverständlich ganz ohne solche genauso lösen könnte. Merke: Moby legt fest, welcher Verbrauch „Verschwendung“ ist und welcher nicht. Flash, der für das Initialisieren nicht benutzten RAMs verplempert wird, ist beispielsweise keine, aber SRAM statt Registern zu belegen, ist per definitionem eine solche (obwohl doppelt so viel SRAM da ist wie Register, letztere als teurer sind). Vielleicht sollte er ja mal bei Atmel nachfragen, ob er den nicht benutzten RAM auch zurückgeben darf gegen ein wenig Rabatt. :) Moby A. schrieb: > Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen. Nur deshalb, weil du dich ja nicht auf einen solchen Vergleich einlässt. Vorgeschlagen hatte Karl Heinz dir einen, und nein, der war ohne irgendeinen „Heimvorteil“, sprich eine bereits existierende Implementierung in C. Oder meinst du etwa, wir müssten dann auch noch das zugehörige Assemblerprogramm schreiben? Wie stellst du dir dieses „belegen“ denn sonst vor? (OK, jetzt geh' ich mal wieder Ressourcen verplempern, dafür werde ich ja schließlich bezahlt.)
:
Bearbeitet durch Moderator
mal den moby fragen ob er mir kann sagen wenn wir etwas SRAM verwenden es das selbe ist wie verschwenden ;-)
Moby A. schrieb: > Werner P. schrieb: >> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen >> von Moby eh schon verloren. > > SO IST ES ! Definiere genauer RAM-Verbrauch. Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen. Gruß, Stefan
Matthias L. schrieb: > Was für eine schwachsinnige Aussage. ... besonders für den, der diese Aufgabe nicht lösen kann ;-) Es geht hier ja nicht darum, Ressourcen da wo nötig nicht in Anspruch zu nehmen. Aber es geht darum, ob C im Bedarf an Asm herabkommt. Wird der Code des durchschnittlichen Asm-Programmierers Moby gar unterboten, wird sich hier kein Moby der Welt mehr hinstellen und C prinzipiell mangelnde Effizienz vorwerfen!
Moby A. schrieb: > Es geht hier ja nicht darum, Ressourcen da wo nötig nicht in Anspruch zu > nehmen. also darf jetzt SRAM verwendet werden oder nicht? Bitte ein Ja oder ein Nein.
Stefan K. schrieb: > Definiere genauer RAM-Verbrauch. > Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen. Weiter oben stand schon mal das Ergebnis der Assemblierung. Das ist auch in meinem Code zu besichtigen. So, weiter gehts am Abend!
Jörg W. schrieb: >> sobald Du auch nur ein Byte SRAM "verschwendest" > > Wobei natürlich das Abarbeiten von Interrupts (die Stack belegen) Wie der oben aufgeführte AT90S1200 zeigt, kann man auch ohne RAM mit Interrupts arbeiten.
:
Bearbeitet durch User
A. K. schrieb: > Wie der oben aufgeführte AT90S1200 zeigt, kann man auch ohne RAM mit > Interrupts arbeiten. Aber nur, wenn man einen separaten Stack hat. Sein ATtiny13 braucht dagegen schon RAM dafür. ;-) (War's nicht der i8008, der auch nur einen Hardwarestack hatte? Der ist evolutionsmäßig an mir vorbeigegangen.)
A. K. schrieb: > Wie der oben aufgeführte AT89S1200 zeigt, kann man auch ohne RAM mit > Interrupts arbeiten. und? dann kommt Moby und sagt: Es muss ein Attiny13 sein.
Moby A. schrieb: >> Definiere genauer RAM-Verbrauch. >> Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen. > > Weiter oben stand schon mal das Ergebnis der Assemblierung. Das ist auch > in meinem Code zu besichtigen. Den Begriff Definition kannst Du im Duden nachschlagen.
Stefan K. schrieb: > > Definiere genauer RAM-Verbrauch. > Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen. > > Gruß, Stefan Doch, natürlich geht das und dazu braucht an keinen μC mit Hardwarestack. Man muß lediglich auf Interrupts verzichten, was bei den oben zu findenden Specs kein Problem ist. Einen Timer kann man auch pollen, ADC genauso -> Stack ist unnötig, Register sichern ist unnötig, RAM initialisieren ist unnötig, ... Nur können muß man halt und damit meine ich nicht die Maschinenbefehlsketten, sonder das darüber liegende Schema. "Problemorientiert" nennt sich diese Ebene auch und damit sind nicht 8-Bit-Register-Beschränktheits-Probleme gemeint. PS: mal sehen in welchen Schipsel der Text von M. wieder "freundlich" herabgelassen wird.
Carl D. schrieb: > Doch, natürlich geht das und dazu braucht an keinen μC mit > Hardwarestack. Man muß lediglich auf Interrupts verzichten Klar geht das, verletzt aber die Spezifikation: le x. schrieb: > - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen Das erinnert mich an mein Betriebspraktikum (schon eine Weile her), wo die Forderung die genau umgekehrte war: keinen Timer-ISR und auch keinen Timerwert verwenden. Der Entwicklungsleiter hatte wohl mal schlechte Erfahrungen mit Interrupts gemacht und meinte, der Timer wird durch Störungen fehlgetriggert. Die Folge war, daß alle if-else-Zweige einer sehr komplexen Regelung mit nop-Schleifen auf gleiche Länge getrimmt wurden. Diese Steuerungen wurden dann später übrigens in Planierraupen eingebaut ... Gruß, Stefan
Stefan K. schrieb: > Diese Steuerungen wurden dann später übrigens in Planierraupen eingebaut > ... Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten gegeben. ;-)
Moby A. schrieb: > Werner P. schrieb: >> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen >> von Moby eh schon verloren. > > SO IST ES ! Dann skalieren wir das mal hoch, wie Moby es gern macht: Ein 200Byte-Programm darf KEIN RAM verbrauchen. Daraus folgt zwingend nach Mobys Skalierungsregeln: Ein 10KB-Programm darf KEIN RAM verbrauchen. Dein angeblich existententes Haus-und-Hof-10-KB-Programm, braucht das eigentlich RAM? Ich bin mir sicher, dass es RAM braucht. Du bist also ein Lügner. Achja: Damit ein Interrupt einen RETI machen kann, muss es die Rücksprungadresse vom Stack aus dem RAM holen. Also: Dein 200Byte-Programm verbraucht RAM! Und schon wieder eine Lüge.
Carl D. schrieb: > Man muß lediglich auf Interrupts verzichten[...] > [...]Nur können muß man halt und damit meine ich nicht die > Maschinenbefehlsketten, sonder das darüber liegende Schema. Das hatten wir ja schon. Für das, was er nicht kann, hat er dann wieder irgendeine Ausrede. mfg.
Thomas E. schrieb: > Für das, was er nicht kann, hat er dann wieder irgendeine Ausrede. Oder es wird zugekauft. :)
Jörg W. schrieb: > Thomas E. schrieb: >> Für das, was er nicht kann, hat er dann wieder irgendeine Ausrede. > > Oder es wird zugekauft. :) für Moby kein Problem. Bei so viel "Übung, Vorbereitung, und System"
Frank M. schrieb: > Und schon wieder eine Lüge. Moby operiert recht systematisch mit verdrehter Wahrheit, das ist so.
Thomas E. schrieb: > Das hatten wir ja schon. Für das, was er nicht kann, hat er dann wieder > irgendeine Ausrede. So ist es. Die Forderung "Kein RAM!" kam ja auch erst später hinzu, als Yalu ihm schon vorgeführt hatte, dass es effizienter und kleiner in C geht. Da hat er einfach mal so die Spielregeln geändert. Und genau deshalb will das hier auch keiner nachprogrammieren. Er wird sofort die wieder die Spielregeln ändern, zum Beispiel so: "Das C-Programm muss in ASM geschrieben sein!" Er ist einfach ein schlechter Verlierer - nichts weiter.
Jörg W. schrieb: > Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten > gegeben. ;-) Ja, das hatte mich damals sehr "beeindruckt" ... Was ich damals gelernt habe: die alten Hasen haben zwar viel Wissen, oft aber auch viele (Vor-)Urteile, die vor ein paar Jahren sicher sinnvoll waren, mittlerweile aber so nicht mehr stimmen. Gruß, Stefan
Frank M. schrieb: > So ist es. Die Forderung "Kein RAM!" kam ja auch erst später hinzu, als > Yalu ihm schon vorgeführt hatte, dass es effizienter und kleiner in C > geht. Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da, um gebraucht zu werden, das hat nichts aber auch gar nichts mit Ineffizienz zu tun.
P. M. schrieb: > Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da, > um gebraucht zu werden, das hat nichts aber auch gar nichts mit > Ineffizienz zu tun. Erstens das und zweitens ist es ja nur Zufall, dass er kein RAM braucht. Das Micky-Maus-Programm ist halt so lächerlich klein, dass alles in Register passt. Bei einem etwas größeren Programm klappt das schon nicht mehr. An 0 Byte RAM festzumachen, dass ASM C überlegen ist, ist einfach nur lächerlich. Aber hier wiederholen sich nur noch die Argumente und man kann nur noch den Kopf schütteln. Ich klinke mich daher nun aus diesem Thread aus und kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys Provokationen zu reagieren. Soll der Troll sich doch mit sich selbst hier unterhalten. Selbst ein Kleinkind ist vernünftiger als dieses Balg.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Soll der Troll sich doch mit sich selbst hier unterhalten. Selbst ein > Kleinkind ist vernünftiger als dieses Balg. Das ist schon länger klar, ja. Mich interessiert eigentlich einzig und alleine noch, wer hinter dieser Person steckt. Meint er das wirklich ernst oder ist er doch irgendwie ein Troll?
P. M. schrieb: > Meint er das wirklich ernst Na klar. Als Hobbyprogrammierer kann er das ja auch. ;-)
P. M. schrieb: > Meint er das wirklich ernst oder ist er doch irgendwie ein Troll? Das ist mir scheissegal. Es ist auch schnurz, denn überzeugen kann ihn sowieso niemand. Da ist mir eine Betonwand, der ich gut zurede, lieber. Und daher jetzt für mich EOD.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Ich klinke mich daher nun aus diesem Thread aus und > kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys > Provokationen zu reagieren. Das widerum seh ich anders. Ich habe hier viele vergnügliche Stunden verbracht und hoffe das geht noch eine Weile so, wenigstens bis zu meinem Urlaub ;-) Ich schäme mich zwar ein wenig für meine niederen Instinkte, aber das hier trifft es doch recht anschaulich: P. M. schrieb: > (Zugegeben, so ein bisschen Spass macht es schon - wie früher wenn man > den Klassendepp mit seinen absurden Ansichten noch ein bisschen > aufgezogen hat.) Aber mal abwarten ob ich heute Abend irgendwelche Bestätigungen in Punkto Anforderungsliste kriege. Ich glaub zwar nicht so recht dran, denn daran ist ja schon der Sensorboard-Thread gescheitert. Aber wenn was kommt probier ich vielleicht ein bischen rum, was mit Compiler/Linkerflags so alles drin ist. Und wenn es nur dazu dient die nächste Ausrede zu hören ;-)
Stefan K. schrieb: > Jörg W. schrieb: >> Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten >> gegeben. ;-) > > Ja, das hatte mich damals sehr "beeindruckt" ... > > Was ich damals gelernt habe: die alten Hasen haben zwar viel Wissen, oft > aber auch viele (Vor-)Urteile, die vor ein paar Jahren sicher sinnvoll > waren, mittlerweile aber so nicht mehr stimmen. Ein alter Hund lernt keine neuen Tricks mehr. :-) Stimmt schon was du da sagst. Da muss ich mich auch an der Nase nehmen. Viele Dinge mach ich heute so, weil ich sie 'schon immer' so gemacht habe, weil ich die Technik dazu gut kenne und oft erfolgreich angewendet habe. Was man eben im Schlaf beherrscht, kommt immer wieder gerne zum Einsatz. Oft entscheidet auch das Bauchgefühl anhand von Analogien.
le x. schrieb: > Ich habe hier viele vergnügliche Stunden verbracht Ein schönes vorweihnachtliches Thema. Erinnert an den Buch-Thread. Einer weiss und kann alles und alle anderen sind zu doof. mfg.
Frank M. schrieb: > P. M. schrieb: >> Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da, >> um gebraucht zu werden, das hat nichts aber auch gar nichts mit >> Ineffizienz zu tun. > > Erstens das und zweitens ist es ja nur Zufall, dass er kein RAM > braucht. Das Micky-Maus-Programm ist halt so lächerlich klein, dass > alles in Register passt. Bei einem etwas größeren Programm klappt das > schon nicht mehr. Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern, so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist auch nicht mehr gross rum rechnen. Was machst du mit dem übrig gebliebenem RAM? Öhmmmmm. > An 0 Byte RAM festzumachen, dass ASM C überlegen ist, ist einfach nur > lächerlich. Wenn man den Compiler anweist, die Variablen in Register zu legen, würde man wahrscheinlich auch das noch wegkriegen. Aber ich hab jetzt ehrlich gesagt Yalus Programm noch gar nicht gesehen, was er da eigentlich alles gemacht hat.
:
Bearbeitet durch User
Karl H. schrieb: > Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern, > so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die > Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist > auch nicht mehr gross rum rechnen. Was machst du mit dem übrig > gebliebenem RAM? Öhmmmmm. jo, es wird auch langweilig hier. Moby bringt nichts Neues. Wiederholt sich nur und beharrt auf seiner Meinung. Den SRAM hat er eh voll verschwendet. Er schreibt ihn ja am Anfang seines Programms mit Nullen voll. Warum auch immer. Jeder findet seinen Meister. Ich bin mir sicher dass es genügend C-Profis gibt die das ASM-Programm von Moby toppen. Auch wenn er das nicht glauben mag. Was solls. Wenns ihn freut ;-)
Er lernt das kryptische Zeichen "^" auswendig. Kann also noch dauern. ..
:
Bearbeitet durch User
Karl H. schrieb: > Aber ich hab jetzt ehrlich > gesagt Yalus Programm noch gar nicht gesehen, was er da eigentlich alles > gemacht hat. Bitteschön: Beitrag "Re: C versus Assembler->Performance"
Hier bricht ja jetzt die nackte Panik aus ;-) Frank M. schrieb: > Ich bin mir sicher, dass es RAM braucht. Du bist also ein Lügner. > Achja: Damit ein Interrupt einen RETI machen kann, muss es die > Rücksprungadresse vom Stack aus dem RAM holen. > Dein 200Byte-Programm verbraucht RAM! > > Und schon wieder eine Lüge. Oh, da schlägt ja einer wild um sich ;-) Daß mein Projekt RAM in Gestalt des Stackbedarfs eines Interrupt-Calls benötigt erschließt sich natürlich aus dem Programmcode. Aber nur für Kenner ;-) Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur Verfügung = 1 Unterprogramm-Ebene. Frank M. schrieb: > Ich klinke mich daher nun aus diesem Thread aus und > kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys > Provokationen zu reagieren. Gut so Frank. Du machst das einzig Richtige. Deine Provokationen sind ja auch weitgehend verpufft ;-)
Ne der missioniert gerade: Beitrag "Re: Heim Automatisierungswahn" Wobei er ein BLE-Module entdeckt hat, auf dem ein M0 mit 128k Flash und 16k RAM werkelt, auf dem ein sicher nicht in ASM geschriebener BASIC-Interperter läuft. Wichtig ist eben eins: keine irgendwie erkennbare C-Bürokratie. Aber noch besser sind kleine AVR Boards, die per proprietären Drahtprotokoll plaudern. Sagt er.
Werner P. schrieb: > Ich bin mir sicher dass es genügend > C-Profis gibt die das ASM-Programm von Moby toppen. Auch wenn er das > nicht glauben mag. Ob Du's glaubst oder nicht- mich würde das freuen. Aber Du hast Recht, dran glauben mag ich nicht. Jörg W. schrieb: > Merke: Moby legt fest, welcher > Verbrauch „Verschwendung“ ist und welcher nicht. Nein. Moby legt nur fest, daß zu einem sinnvollen Ressourcen-Vergleich natürlich das SRAM gehört. ;-) le x. schrieb: > Ich schäme mich zwar ein wenig für meine niederen Instinkte Das ehrt Dich. Wenigstens einer der's mal ehrlich zugibt ;-) le x. schrieb: > Aber mal abwarten ob ich heute Abend irgendwelche Bestätigungen in > Punkto Anforderungsliste kriege. Selbstverständlich. Setz mich gleich nochmal dran. > Ich glaub zwar nicht so recht dran, denn daran ist ja schon der > Sensorboard-Thread gescheitert. Aber wenn was kommt probier ich > vielleicht ein bischen rum, was mit Compiler/Linkerflags so alles drin > ist. Ja, das fürchte ich auch: Mehr als ein bischen Rumprobieren kommt nicht bei raus. Ich denke, das haben in der Zwischenzeit schon ganz andere gemacht ;-) > Und wenn es nur dazu dient die nächste Ausrede zu hören ;-) Wenn Du es nicht schaffst ist meiner Meinung nach Streit vorprogrammiert. Ich bin schon gespannt worüber. Denn eines wird auf Biegen und Brechen erstmal nicht passieren: Daß die C-Seite die unbestreitbaren Vorteile von Asm eingesteht ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Daß mein Projekt RAM in Gestalt des Stackbedarfs eines Interrupt-Calls > benötigt erschließt sich natürlich aus dem Programmcode. Aber nur für > Kenner ;-) > > Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem > C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den > Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur > Verfügung = 1 Unterprogramm-Ebene. D.h. es kann möglich sein, ein dem Assemblerprogramm gleichwertiges Programm in C zu schreiben, wenn der Compiler den identischen Assembler output erzeugt, bzw. exact die gleichen Bytes ins Flash gebrannt werden. Alles andere ist eine Verletzung der Spezifikation. Damit geht ein besseres Programm per Definition nicht. Der Thread ist somit beendet. Bitte schliessen.
Moby A. schrieb: > Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem > C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den > Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur > Verfügung = 1 Unterprogramm-Ebene. Was ist das für ein unsinniger Mikrocontroller? Selbst lausigste kleinste PIC hat 2 Stack-Ebenen. Und warum etwas "sparen", was man schon gekauft und bezahlt hat? Man kann sich auch selber geißeln. Es ist so schön, wenn der Schmerz wieder nachlässt... Bernhard M. schrieb: > Der Thread ist somit beendet. > Bitte schliessen. Neineinein! Dann verliere ich die 2000er-Wette. Auch wenns nur ums "Recht haben" geht... ;-)
:
Bearbeitet durch Moderator
Moby A. schrieb: > Daß die C-Seite die unbestreitbaren Vorteile von Asm eingesteht Dazu musst du aber ein Programm zeigen, dass die Vorteile auch nutzt. So, wie ich das in meinem genialen Programm gemacht habe. Es macht exakt das, was es soll. Nicht mehr und nicht weniger. Und das mit absoluter Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran. mfg.
:
Bearbeitet durch User
Bernhard M. schrieb: > Alles andere ist eine Verletzung der Spezifikation. So ist es. Ist es schlechter, hat Moby gewonnen, ist es besser, dann fehlt ihm irgendein Feature, welches nachträglich als wesentlich erklärt wird. Da die „Spezifikation“ ja nur im „selbsterklärenden Assemblerprogramm“ besteht, ist das doch auch völlig logisch, oder? > Der Thread ist somit beendet. Nein, schließlich ist Assembler ja „auf dem Weg nach vorn“. :-) Ich habe gestern ein Buch über Assembler-Programmierung geschenkt bekommen. In seinem Vorwort enthält es den Absatz:
1 | When writing a book on the assembly language of a processor, we know in |
2 | advance that it will not register in posterity. By its very nature, an assembly |
3 | language has the same life expectancy as the processor it supports perhaps 20 |
4 | years at best. What's more, this type of programming is obviously not used for the |
5 | development of software projects and so is of little consequence. (*) |
Man würde sich wünschen, Moby würde den gleichen Realismus an den Tag legen wie der Autor dieses Buches. ;-) (*) Für die, die des Englischen nicht ganz so mächtig sind: Wenn man ein Buch über Assembler-Programmierung eines bestimmten Prozessors schreibt, ist von vornherein klar, dass es nicht für die Ewigkeit bestimmt ist. Prinzipbedingt hat die Assemblersprache die gleiche Lebenserwartung wie der durch sie unterstützte Prozessor, vielleicht maximal 20 Jahre. Jedoch wird diese Art von Programmierung nicht für die Entwicklung von Softwareprojekten genutzt, sodass das keine großartigen Konsequenzen nach sich zieht.
:
Bearbeitet durch Moderator
Carl D. schrieb: > Ne der missioniert gerade: Irrtum Carl D. Ich bin mit ganzem Einsatz wieder hier bei meinem Lieblingsthema. Lass mal das BLE-Modul. Das interessiert hier nicht! Karl H. schrieb: > Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern, > so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die > Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist > auch nicht mehr gross rum rechnen. Was machst du mit dem übrig > gebliebenem RAM? Öhmmmmm. Du warst beim Lesen meines Projekt-Threads eben auch nicht aufmerksam. Das will ich Dir aber keinesfalls vorwerfen, da Dein Zeiteinsatz bei den vielen Hilfe-Threads in jedem Falle höher zu bewerten ist. Ja, was macht man mit zusätzlichem Platz? Warum bist Du da jetzt plötzlich so einsilbig einfallslos? Stell Dir eine Messwert-Vorabauswertung vor, bevor die Daten auf die Reise gehen. Garniert vielleicht mit einen kleinen History. Da kann man u.U. jedes Bytchen gebrauchen. Die Main ist noch frei. Idealer Erweiterungspunkt, um Funktionalität wunderbar unabhängig von der periodischen Datenausgabe mit vielleicht ein paar Unterprogrammebenen einzuziehen. Du weißt natürlich selbst, daß es mir nicht darum geht, vorhandene Ressourcen ungenutzt zu lassen. Natürlich. Natürlich weißt Du, daß es nur um den prinzipiellen Ressourcenvergleich C vs. Asm geht bei bitteschön gleich(st)er Vergleichs-Funktionalität geht... Natürlich K.H. Gibs halt mal zu ;-) Ist halt für einen überforderten C-Profi schwierig, bei diesen Schwierigkeiten nicht in konstruierte Nebenkriegs- Schauplätze und Plänkeleien abzugleiten. Immerhin bleibst Du im zweiten KnowHow Vergleich unter den steil emporragenden C-Koryphäen, der hier so hintergründig mitläuft überzeugend- da Du der Versuchung widerstehst, das zwar tröstende, erheiternde, ablenkende- aber eigentlich doch so dumme und entlarvende Hohn/ Spott/ Beileidigungs/ Betrugsvorwurf- Spielchen mitzuspielen. Respekt. > Wenn man den Compiler anweist, die Variablen in Register zu legen, würde > man wahrscheinlich auch das noch wegkriegen. Ich bin doch eigentlich sooo gutmütig und großzügig: Die Möglichkeit massierten Registereinsatzes hab ich für C doch offengelassen. Auch wenns im Vergleich zu den meinigen 11 von 32 Registern dann natürlich nicht schön ausschaut und, wenn nicht den faktischen, so aber zumindest den moralischen Sieg kostet ;-)
Jörg W. schrieb: > hat Moby gewonnen, Ja. Dann hat er aber nur eine Schlacht gewonnen. Den Krieg hab längst ich gewonnen. Mit meinem absolut genialen Programm. Es macht exakt das, was es soll. Nicht mehr und nicht weniger. Und das mit absoluter Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Da kommt er mit seinem Dödelprogramm nicht im entferntesten heran. mfg.
Lothar M. schrieb: > Was ist das für ein unsinniger Mikrocontroller? Selbst lausigste > kleinste PIC hat 2 Stack-Ebenen. Aber nicht im RAM. ;-)
Thomas E. schrieb: > Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran. Und Du mit Deiner Rumpffunktionalität nicht im Entferntesten an die Arbeitsresultate meines Projekts. Hattest Du das noch nicht bemerkt? Es spricht momentan nicht gerade für Dich, daß Du so unterschiedliche Funktionalität unbedingt im Ressourcenverbrauch vergleichen willst. Also mir wär das peinlich ;-) Bernhard M. schrieb: > D.h. es kann möglich sein, ein dem Assemblerprogramm gleichwertiges > Programm in C zu schreiben, wenn der Compiler den identischen Assembler > output erzeugt, bzw. exact die gleichen Bytes ins Flash gebrannt werden. > Alles andere ist eine Verletzung der Spezifikation. So eine Aussage wär mir auch peinlich... > Der Thread ist somit beendet. (*) > Bitte schliessen. (*) Wegen Überforderung des C-Compilers. Schnell weg damit. Aus dem Auge, aus dem Sinn.
So liebe Leute, auch wenns gerade so einen Spaß macht mich an dem hilflosen Herumrudern mancher Akteure hier zu laben- ich schau nochmal auf mein Programm wegen der -hochtrabend so genannten - "Spezifikation" ... Fortsetzung folgt.
Moby A. schrieb: > Und Du mit Deiner Rumpffunktionalität nicht im Entferntesten an die > Arbeitsresultate meines Projekts. Hattest Du das noch nicht bemerkt? > Es spricht momentan nicht gerade für Dich, daß Du so unterschiedliche > Funktionalität unbedingt im Ressourcenverbrauch vergleichen willst. Welch ein Ausbruch, um von der eigenen Unzulänglichkeit abzulenken. Ich will gar nichts vergleichen. Mein geniales Programm lässt sich mit nichts vergleichen. Das Beste gewinnt jeden Vergleich. Und dieses Programm ist sogar das absolut Beste. Es macht exakt das, was es soll. Nicht mehr und nicht weniger. Und das mit absoluter Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran. mfg.
Moby A. schrieb: > So eine Aussage wär mir auch peinlich.. Ich habe nur alle Deine Aussagen knapp zusammengefasst.
Angehängte Dateien:
-
T13OUT.jpg
150 KB
So, also nochmal: le x. schrieb: > Hier der anscheinend letzte Stand dieser Anforderungsliste: > - Der Prozessor soll den internen 128kHz Takt verwenden OK. > - es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4) > und AINP-CHANNEL2 (entspricht PB3) eingelesen werden (1) OK. Die zu verwendende Referenzspannung wird für jeden Kanal einzeln in Form einer Konstante vorgegeben! > - die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen > werden Natürlich. Wir wollen doch nix "verschwenden" ;-) > - das Einlesen soll im free-running Modus des ADC stattfinden Im Interesse der Interrupt-Einsparung wärs gut. Kann man aber auch manuell starten/im ADC-Int auslesen. Aber Stackbeschränkung (s.u.) beachten! > jeder Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2) Richtig. > - es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1) > und DINP2-LOW (entspricht PB5) eingelesen werden Richtig. > - das Einlesen soll unmittelbar vor der Datenübertragung erfolgen Ja. Wär echt sinnvoll, daß die nächste Datenausgabe aktuelle Werte enthält... > - es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte, > versandt werden > - das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden > - ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK > (entspricht PB2) ausgegeben werden OK. > - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden > durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden) > - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits > - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits > - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits > - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits > - Bit 20: DINP1-LOW > - Bit 21: DINP2-LOW Ok. > - Bits 22-23: Checksumme über das Datentelegram > - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in > einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird Bit22= Bit 0 der Summe, Bit23= Bit 1 der Summe > - das Telegram soll alle 320 ms wiederholt werden; der genaue Wert > ist unkritisch > - Das Telegram soll eine Bit-Zykluszeit von ca. 10 ms haben, also 80 ms > pro Byte Genau. 80ms Pause zwischendurch dienen der Synchronisierung. Siehe Diagramm! Dort ist dann auch zu sehen, daß das letzte Datenbit auf PB0 in der Pause stehenbleibt. > - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen > - das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben Die letzten 2 Punkte hatte ich schon zum Abschuß freigegeben. Wär natürlich schön, der Anwender könnte auf dieser Architektur aufbauend einfachst erweitern, ohne daß die unabhängige Ausgabe-Funktionalität gestört würde (dann mit entsprechender TimerInt-Registersicherung). > - es ist nur 1 Timerinterrupt zu verwenden, andere Interrupts sind für > Erweiterungszecke reserviert Siehe auch Stack-Beschränkung! > 1) Soll 8 mal AINP-CHANNEL1 und dann 8 mal AINP-CHANNEL2 eingelesen > werden oder soll dies im Wechsel geschehen? Ist doch wurscht. > 2) Soll zwischen den 8 Messpunkten gewartet werden (z.B. im nächsten > Timer-Interrupt) oder soll eine Messung gestartet werden, sobald der ADC > wieder frei ist? Was willst Du da starten? Der ADC läuft doch Free Running... Wenn Du den schön regelmäßig ausliest hast Du immer aktuelle Werte. Mit einer anderen Lösung muss in jedem Fall eines sichergestellt sein: Die Datenausgabe enthält den Durchschnitt von 8 aktuellen Messungen! Und zum Abschluß das Wichtigste: Für den faktischen Sieg soll a) die Datenausgabe stimmen (was ich sehr schnell mit der .hex prüfen kann) b) kein Byte Flash mehr verbraucht werden c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt werden. Alles klar? Wenn nicht, bitte fragen. Anbei auch nochmal das aktuelle Programm.
Moby A. schrieb: > a) die Datenausgabe stimmen (was ich sehr schnell mit der .hex prüfen > kann) > b) kein Byte Flash mehr verbraucht werden > c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt > werden. Ich dachte, wir sprechen von Programmen jeglicher Grösse, aber ich sehe bei dir nur ein Mickymausprogramm... Bevor wir darüber sprechen, sollten wir uns über sinnvolle Vorgaben und daraus folgend eine sinnvolle Architektur unterhalten. Denn die beinhaltet dein Programm nicht. Und: Die obige Anforderungsliste ist alleine schon kryptischer als das zugehörige C-Programm.
P. M. schrieb: > Ich dachte, wir sprechen von Programmen jeglicher Grösse, aber ich sehe > bei dir nur ein Mickymausprogramm... > > Bevor wir darüber sprechen, sollten wir uns über sinnvolle Vorgaben > und daraus folgend eine sinnvolle Architektur unterhalten. Denn die > beinhaltet dein Programm nicht. > > Und: Die obige Anforderungsliste ist alleine schon kryptischer als das > zugehörige C-Programm. Schon klar. Die Ausreden gehen gleich wieder los- und woher wußte ich nur, daß ausgerechnet Du den Anfang machst ;-) Deine Vorstellungen von "sinnvoller Architektur" kannst Du woanders einbringen. Hier gehts nur darum, die beschriebene, sehr einfache Funktionalität kürzestmöglich umzusetzen. Toi toi toi...
Gerhard O. schrieb: > http://www.zoe-online.org/dateien/Einblick_02_11.jpg > > Seufz... Ja, die Aufgabe ist für C nicht einfach ;-( Dieses verdammt sperrige Sprachinstrumentatium !
:
Bearbeitet durch User
Moby A. schrieb: > Schon klar. > Die Ausreden gehen gleich wieder los- und woher wußte ich nur, daß > ausgerechnet Du den Anfang machst ;-) > > Deine Vorstellungen von "sinnvoller Architektur" kannst Du woanders > einbringen. Hier gehts nur darum, die beschriebene, sehr einfache > Funktionalität kürzestmöglich umzusetzen. Die Kernaussage der meisten Diskussionsteilnehmer ist: "C verbraucht selbst bei kleinsten Programm in der Regel (wenn überhaupt) nicht wesentlich mehr Resourcen als ein hochoptimiertes Assembler-Programm UND ab mittelgrossen Programmen ist es durch Assembler nicht mehr zu schlagen." Und du kommst her, und verlangst, diese Behauptung zu beweisen, indem eine C-Umsetzung deines Mickymausprogramms kein Byte mehr brauchen darf als deine Assembler-Version? Absurd.
... es ist unglaublich mit welcher Geduld mit Moby diskutiert wird... Jetzt habe ich mir fast den ganzen Abend lang die Texte gelesen, manchmal amüsiert, dann wieder gelangweilt und dann wieder hoch erstaunt ob einer extremen Ignoranz (von Seiten Moby). Ich habe lange Jahre programmiert, den C64 in Assembler, einen Schneider CPC, mein erster ganzer Stolz, einen Commodore PC1 (mit einem wahnwitzig schnellen 8088 CPU 4,7MHZ ... langsamer ging es auf PC Basis nie). Die habe ich der Effizienz wegen noch in Maschinensprache programmiert, wobei beim Schneider CPC und dem PC1 schon auch Turbo Pascal eingesetzt wurde (und auch zu diesen Zeiten gab es schon die Glaubenskriege um die Sprache). Zunehmend (mit leistungsfähigeren Teilen) wurde Maschinensprache immer seltener (und mein letztes großes Projekt - irgendwann Anfang der 80er - war ein Texteditor der den maximalen Speicher Segementgrenzen hinweg verwenden konnte. DA war auf den damals langsamen Kisten Pascal und C zu langsam dafür). Ich hatte DOS gleichzeitig gehasst und geliebt. Mein erster Controller war ein 8048 und den musste ich mangels vorhandenem Compiler in Maschinensprache programmieren. Auf Controllerebene das letzte große Projekt in (reiner) Maschinensprache war ein Logger, der über Temperatureinwirkung über der Zeit ein bestimme Qualitätsaussage zu einem Produkt machen mußte. Was für ein Grauen !!!! Das Gerätchen mußte über serielle Schnittstelle eine klare Aussage in Gleitkommadarstellung machen. Bei der Verrechnung der Daten mußte ein Logartihmus programmiert werden. !!!! Sowas ... in Maschinensprache ... will ich nie mehr machen müssen! Vllt. war ich "besser" als ein Compiler (aber ich wage das mal zu bezweifeln). Jeder hier (außer wohl Moby) weiß, wann er welche Sprache einsetzt und wann er (wenn es halt nicht mehr anderst geht) wirklich Maschinensprache einsetzt. Bei den heutigen Controllern, bei denen nicht mehr die Leistungsfähigkeit des Controllers den Preis desselbigen bestimmt, sondern die Absatzzahlen, müssen - glücklichweise - nicht mit jedem Byte gegeizt werden damit etwas läuft. Wie hier schon oft erwähnt: Entwicklungszeiten sind mit ganz großers Sicherheit in Assembler länger (wenn es nicht gerade Trivialprogramme sind). Hier schreiben Koryphäen ihres Fachs wie Jörg Wunsch (um einen einzigen mal zu nennen), dem ich ungesehen fast jedes Wort glaube was er schreibt und ich wundere mich sehr, woher sie die Geduld und die Motivation genommen haben sich mit Moby auseinander zu setzen. Ich gebe zu, dass mich Maschinensprache auch heute noch reitzt und ich das auch immer wieder mal zum Spaß anpacke und ich mich drüber freue mit wie wenig Code man etwas anstellen kann. Auch zum Lehren wie das Ding das man da programmiert denn eigentlich wirklch funktioniert, zum Zeigen, dass man eine Subtraktion durch eine Addition mit mit dem Komplement bewerkstelligt werden kann ist es super. Fürs Schreiben von kompletten Appliationen jedoch nicht. Meine Hochachtung gilt hier all denjenigen Experten, die sich mit Moby auseinandergesetzt haben und es wohl auch weiter tun werden (allerdings müssten sie wissen, dass es aus cli(); while(1); sei(); kein Entrinnen gibt, das Wiedereinschalten der Interrupts nie stattfindet und sich in der while-Schleife die "Diskussion" (es ist keine) mit Moby wiederfindet. Gute Nacht allen, die vllt. noch lesen !
P. M. schrieb: > ab mittelgrossen Programmen An die Vorstellung eines 1-10K Asm Programms und die Annahme, jemand würde das in C neu formulieren wage ich gar nicht erst zu denken, wenn sich schon bei 200 Bytes jeder C'ler hier die Zähne ausbeißt. Damit bleibts bei Aussage gegen Aussage. P. M. schrieb: > Und du kommst her, und verlangst, diese Behauptung zu beweisen, indem > eine C-Umsetzung deines Mickymausprogramms kein Byte mehr brauchen darf > als deine Assembler-Version? Absurd. Absurd wäre wohl die Annahme, daß Du das schaffst. Mit Übung, Vorbereitung und System lassen auch noch viel größere Asm-Programme C im Ressourcenverbrauch im Regen stehen, da summieren sich die Einspareffekte noch. Irgendwann setzt dann mal die Übersicht sinnvolle Grenzen- aber weit über dem hinaus, was Experten wie Du vielleicht für möglich halten.
Angehängte Dateien:
-
image.jpeg
61 KB
Ralph S. schrieb: > (allerdings > müssten sie wissen, dass es aus > > cli(); > while(1); > sei(); >kein entrinnen gibt... Was seid ihr doch für Nachteulen;-) P.S. Den Arduino Watchdog müßt Ihr entschuldigen, konnte keinen für den AVR finden...
:
Bearbeitet durch User
... lach, ich geb mich geschlagen .... mit dem Wachhund... (ob ich jetzt fieberhaft nach einem AVR OHNE WDT suchen soll? Vllt. findet sich ja noch irgendwo ein altes Exemplar bei dem das nicht implementiert ist.... bevor jetzt jemand kommt: Reset-Taste zählt nicht)
Ralph S. schrieb: > ... lach, ich geb mich geschlagen .... mit dem Wachhund... > > (ob ich jetzt fieberhaft nach einem AVR OHNE WDT suchen soll? Vllt. > findet sich ja noch irgendwo ein altes Exemplar bei dem das nicht > implementiert ist.... bevor jetzt jemand kommt: Reset-Taste zählt nicht) Ganz so war das doch nicht gemeint.;-)
Ralph S. schrieb: > ... es ist unglaublich mit welcher Geduld mit Moby diskutiert > wird... Diese Energie wird nun wohlweislich nicht in eine C-Version meines simplen Projekts gesteckt- und damit in den einzig möglichen, reellen Vergleich. Das gibt doch zu denken... Interessant auch, was Du alles als Diskussion bezeichnest ;-) > Fürs Schreiben von kompletten Appliationen jedoch nicht. Für so einen kleinen AVR ist das bei 8-Bit MSR kein Problem. Nur keinen Elefanten aus ner kleinen Maus machen ... > in der while-Schleife die "Diskussion" (es ist > keine) mit Moby wiederfindet. Die While-Schleife läuft so ab: - Moby beschreibt und zeigt die Effizienz von Asm. - die Cler erkennen diese (manchmal nur versteckt an) - da aber nicht sein kann was nicht sein darf: Attacke! (alle Mittel sind recht) Goto 1 ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Die While-Schleife läuft so ab: > - Moby beschreibt und zeigt die Effizienz von Asm. Guten Morgen Moby, wann schnallst due endlich, dass Effizienz nicht nur Flash- und SRAM Verbrauch bedeuten, sondern die hier bereits in aller Länge und Breite dargelegten anderen Faktoren beinhaltet!!! > - die Cler erkennen diese (manchmal nur versteckt an) Die "Cler" hier kennen sich meist alle viel besser und tiefer mit ASM aus als du. Und jeder weiß, wann und warum die eine oder die andere Art des Programmierens für ihn sinnvoller und effektiver ist. Dein "sehr spezieller" Datenlogger loggt zumindest keinen hinter dem kalten OPfen hervor. Bei einem Projekt, f+r dass das Gehirn wenigstens warmläuft sähe das sicher anders aus. > - da aber nicht sein kann was nicht sein darf: Attacke! > (alle Mittel sind recht) Das stimmt allerdings. Besser wäre es, das Thema von nun an zu ignorieren, weil es so sinnlos ist. Es ist scheißegal, ob das Programm 3 Byte größer oder kleiner ist, 4 Byte SRAM belegt oder nicht. Und DAS ist der Punkt, den du beharrlich verteidigst. Leider für den Restderwelt grundsätzlich bedeutungslos. Vlt. erschlägt ja auch jemand den ganzen Müll hier mit einem C Programm das tatsächlich kürzer ist, und dich damit mit deinen eigenen Waffen -nein, Dogmen.
Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu haben ist Moby irgendwie wirklich verzweifelt.... Nicht dass du anscheinend wirklich ausgeblendet hast, dass dein erstes ultimatives Programm verloren hast, du predigst von Planung, Ordnung, Blabla und hast immer fehlerhaften Code gepostet (Wie auch immer das passieren kann) Du ignorierst Gegenfragen. Das Argument der potentiellen Erweiterbarkeit deiner Projekte ist inzwischen kaum noch zu hören. DAS war ja dein Argument manisch Ram und Flash zu sparen - als Karl Heinz mal fragte, was genau an 1 kB Flash an Erweiterungen im Raum stehen könnten hat man natürlich nix gehört. Wenn dein Sensor eine Kennlinie bekommen muss, passt die nicht rein. Wenn du die Kennlinie berechnen könntest, wäre es keine typische 8 bit Anwendung... sic. Inzwischen ist das aber auch im Hintergrund. Jetzt ist deine neue Sau ein Stack der keiner ist.... Wie wäre es mit einem Remi? Deinen Code als inline asm in einem C Programm? Dass du nur ein einziges, künstlich konstruiertes Eisen im Feuer hast (was ja trotz Planung verbuggt war) und dieses Eisen wirklich nur seiner selbst willen von dir hochgehalten wird blendest du wirklich aus? Selbst um eine Aussage zu untermauern wie 'bis 1kB ist händischer asm Code einem c Code in puncto Flash/Ram Verbrauch bzw Geschwindigkeit überlegen' wäre etwas mehr als eine statistische Ausnahme angesagt. Mach doch mal bei einem angebotenen Vergleich mit. Gerade diejenigen die es dir angeboten haben sind faire Leute, die dich nicht wegen etwaiger Fehler zerreißen werden. Es lesen viele mit, die sich bestimmt auch als Hobbyisten zu Assembler bekehren lassen würden. Du würdest dir einen Namen machen. Also jetzt nicht nur als Witzfigur.
Moby A. schrieb: > Also mir wär das peinlich ;-) Ich habe nicht das Gefühl das Dir noch irgendwas peinlich ist.
Frage (an die Allgemeinheit) zu dem ADC und Durchschnitt.. moby macht ja aus den 8 Werten einen Durchschnitt, der dann aber auch wieder nur 10 bit hat.. ich hab es bei meinem Helligkeitssensor so gemacht, dass ich einfach 10 Werte addiere. in der Hoffnug dadurch einen höhere genauigkeit zu erhalten (vorallem bei dämmerung) (also ungefähr 13Bit) ist das unrealistisch? sind die (nur) 10Bit schon unrealistisch? warum moby hier einen durchschnitt rechnet, verstehe ich nicht, gehts hier um Falschmessungen die dann nur 1/8 ins ergebnis einfließen sollen? muss man das machen? konnte bei mir jetzt nicht feststellen dass da auch mal was falsch gemessen wird.. würde man dann nicht 10 Werte messen und min und max weglassen? einen Durchschnittüber die Zeit (300ms) will moby eh nicht (bzw ist es ihm egal? die doku ist hier sehr "mager")
:
Bearbeitet durch User
Markus M. schrieb: > Es ist scheißegal, ob das Programm 3 > Byte größer oder kleiner ist, 4 Byte SRAM belegt oder nicht. Für Moby eben nicht. diese 3 Byte Flash und 4 Byte RAM sind sein Notnagel, sein letzter Strohhalm. C ist ausgelegt für die Benutzung eines Stacks und der AVR ist ausgelegt für C. Trotzdem führt er immer wieder den Stackverbrauch als DAS Kriterium, als die härteste aller Anforderungen an. Weil er weiß dass er damit jedem Compiler massive Knüppel zwischen die Beine wirft. Da könnte das Programm tausendmal schneller implementiert, tausendmal besser lesbar und tausendmal besser erweiterbar sein. 1 Byte Stack (ne sorry, 3 - denn Moby braucht ja auch 2) und du hast verloren. Das ist so wie wenn du gegen Usain Bolt im Sprint antrittst, ihm aber Arme und Beine zusammenbindest. Du kannst dich nachher vielleicht gut fühlen, aber die Aussagekraft so eines Experimentes kann man wohl bestreiten... Ich zitier mich mal selbst: le x. schrieb: > Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein > ganz anderer: > Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung > eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man > keinen Krüppel-Code schreiben will), dieser befindet sich traditionell > ebenfalls im RAM. > > Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne > Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu > gewinnen...
Moby A. schrieb: > Diese Energie wird nun wohlweislich nicht in eine C-Version meines > simplen Projekts gesteckt- und damit in den einzig möglichen, reellen > Vergleich. Das gibt doch zu denken... Warum auch. Braucht man 20B weniger Flash aber 1Byte mehr SRAM -> Verloren Braucht man kein SRAM aber 1Byte mehr Flash -> Verloren Braucht man weniger Flash UND weniger SRAM -> Verloren Für den dritten Fall wirst Du Dir dann irgendwas ausdenken was jetzt ganz plötzlich ein unglaublich wichtiges Kriterium ist. Nutzloses RAM zu initialisieren oder auf einem Bein zu hüpfen und dabei wie ein Huhn zu gackern oder sonst was. Zur Not muß die Zeichenlänge des Quellcodes herhalten oder der RAM Verbrauch des Compiler auf dem Entwicklungssystem oder wie viele Mausclicks man braucht um die IDE zu starten. Dir wird schon was einfallen was man als völlig hirnrissiges Argument mißbrauchen kann. le x. schrieb: > Hier der anscheinend letzte Stand dieser Anforderungsliste: Super. Eine Checksumme die so schwach ist das ich würfeln kann ob die Werte wirklich stimmen. Völlig ineinander verwurstelte Daten die ich am Zielsystem erst wieder auseinandernehmen muß um was damit machen zu können. Eine synchrone unidirektionale Punkt zu Punkt Verbindung bei der im Zeitlupentempo Daten übermittelt werde statt ein vernünftiger Feldbuss mit Master / Slave Protokoll und starker CRC. RS485, Lin, Can, DALI, herje es gibt so viel Busse die alle mehr können als dieser Unfug. Wenigstens eine Manchester Codierung für Gleichspannungsfreie Datenübertragung mit Impulsübertragern und Taktrückgewinnung aus den Daten hätte man doch machen können um irgendwas sinnvolles bei einem proprietären Bus zu machen. Den Teil wo die Entprellung der digitalen IOs stattfindet oder die Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden können. Mit Verlaub. Das ist vollkommener Müll. Warum sollte man sich die Mühe geben so einen sinnlosen Kram zu programmieren der unzuverlässige Daten erhebt und auf eine unflexible und unzuverlässige Art übermittelt. Die unterste Schmerzgrenze für Sensor / Aktor Knoten sehe ich bei adressierbaren Master / Slave Feldbussen mit min. 16 Teilnehmern.
Michael K. schrieb: > Den Teil wo die Entprellung der digitalen IOs stattfindet oder die > Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden > können. Das ist keine typische 8bit MSR Anwendung. >Master / Slave Protokoll und starker CRC. >RS485, Lin, Can, DALI Das verbraucht alles RAM und Flash. => Wird ausgelagert.
Matthias L. schrieb: > Michael K. schrieb: >> Den Teil wo die Entprellung der digitalen IOs stattfindet oder die >> Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden >> können. > > Das ist keine typische 8bit MSR Anwendung. Damit treibt Moby die ganzen Anfänger ins 32bit Lager. Die lesen was für Moby typische 8bit Anwendungen sind nehmen lieber gleich einen STM32. Matthias L. schrieb: >>Master / Slave Protokoll und starker CRC. >>RS485, Lin, Can, DALI > Das verbraucht alles RAM und Flash. => Wird ausgelagert. Das was wirklich völlig sinnloser Flash und Ram Verbrauch ist nennt Moby eine typische 8bit MSR Anwendung. Nach meinem Empfinden das nicht mehr als ein 8bit MSR 'Hello World' Das primitivste Grundgerüst eines Programmes das nicht mehr kann als zu zeigen das man prinzipiell ein Programm zum laufen bekommt.
Moby A. schrieb: > Die While-Schleife läuft so ab: > - Moby beschreibt und zeigt die Effizienz von Asm. > - die Cler erkennen diese (manchmal nur versteckt an) > - da aber nicht sein kann was nicht sein darf: Attacke! > (alle Mittel sind recht) > > Goto 1 ;-) Falsch.
1 | #define PHRASENDRESCHERMODUS 0
|
2 | #define IMMER_AN 0
|
3 | |
4 | while(PHRASENDRESCHERMODUS==IMMER_AN)printf("Mit Uebung, Vorbereitung und System..."); |
mfg.
:
Bearbeitet durch User
Moby A. schrieb: > b) kein Byte Flash mehr verbraucht werden Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und komplett versagt?
Moby A. schrieb: > An die Vorstellung eines 1-10K Asm Programms und die Annahme, jemand > würde das in C neu formulieren wage ich gar nicht erst zu denken, wenn > sich schon bei 200 Bytes jeder C'ler hier die Zähne ausbeißt. > Damit bleibts bei Aussage gegen Aussage. Andersrum: Du weisst haargenau, dass du nur bei so einem Miniprogramm eine Chance hast. Kein Mensch schreibt in nützlicher Frist ein 10kB+ Assembler-Programm, das einen guten C-Compiler schlägt. Und nur beim Mini-Programm kann man darauf hoffen, dass ein kleiner (fixer) C-Overhead den Speicher-Verbrauch doch noch um die entscheidenden* paar Bytes hin die Höhe treibt. * "Entscheidend" im Mobyschen Sinn, nicht nach sinnvollen Designkriterien.
>in nützlicher Frist
Hier fehlt auch das (*). Denn das ist bei jedem (ausser Moby) eine
wichtige Ressource.
Moby A. schrieb: > Also mir wär das peinlich ;-) > > > So eine Aussage wär mir auch peinlich... Also da muß ich mich schon wundern. Bis jetzt war dir doch echt nix zu peinlich. Z.B. das hier Moby A. schrieb: > Mach Dir > lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau > gestellten Assembler-Überlegenheit zu begegnen ist ;-)
>> in der Hoffnug dadurch einen höhere genauigkeit zu erhalten (vorallem >> bei dämmerung) (also ungefähr 13Bit) >> ist das unrealistisch? Ja Schaust du letzten Beitrag unter 2 (Seitenaufteilung). Da bin ich darauf eingegangen und habe Fotos beigefügt von dem was geht. Ist aber keine typische Anwendung für kleine AVRs :-) braucht zu viele Resourcen :-) 12 BIT bei 256 Werten kannst du in der Praxis erwarten, mehr ist nicht drin.
>12 BIT bei 256 Werten
12bit ist grösser 8bit. Und 256 ist auch grösser 8bit
=> keine typische 8bit Anwendung.
@Bernd Noll danke es ist zwar Seite 5 und nicht 2 und man kann sowas auf verlinken Beitrag "Re: Assembler wieder auf dem Weg nach vorn" aber hat mir schonmal sehr geholfen.
:
Bearbeitet durch User
Johann L. schrieb: > Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm > findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und > komplett versagt? Nein, keinesfalls. Wurde ja schon gemacht. Das, was die dann kürzere Lösung notwendigerweise weggelassen hat, wird zum zwingend notwendigen Feature der anderen Implementierung erklärt. Das ist ja in seinem Sinne durchaus folgerichtig, denn es gibt ja keinerlei „offizielle“ Spec außer der bestehenden Implementierung. Damit ist es völlig klar, dass jegliche alternative Implementierung bei ihm keine Chance hat. Selbst eine Implementierung in C müsste notwendigerweise exakt den gleichen Assemblercode liefern, um akzeptiert zu werden.
Jörg W. schrieb: > Das ist ja > in seinem Sinne durchaus folgerichtig, denn es gibt ja keinerlei > „offizielle“ Spec außer der bestehenden Implementierung. Wobei es mittlerweile ja eine vom ihm gereviewede und kommentierte Spec gibt. Von dem her müsste das jetzt als "offiziell" gelten.
Moby hat doch geschrieben
> c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt
Damit dürfte klar sein dass das C Programm keinen SRAM verwenden darf.
Ausser 2 Bytes vom Stack.
Ergo: Wenn das C-Programm kleiner ist (Flash) und keinen SRAM verbraucht
hast gewonnen.
Ausser Moby fällt dann wieder was ein ;-)
Matthias L. schrieb: >>12 BIT bei 256 Werten > > 12bit ist grösser 8bit. Und 256 ist auch grösser 8bit 256 Werte passen in 8 Bits. Nicht aber der Wert 256. ;-)
Moby A. schrieb: > Gerhard O. schrieb: >> http://www.zoe-online.org/dateien/Einblick_02_11.jpg >> >> Seufz... > > Ja, die Aufgabe ist für C nicht einfach ;-( > Dieses verdammt sperrige Sprachinstrumentatium ! Mit Verlaub, Du hast Dich verlaufen. Und daß Du mit einigem rhetorischen Geschick die Horden, die Dir hier ausführlichst widersprachen, zunehmend aufs Glatteis geführt hast*), macht es nicht besser. Vergiss den TIOBE-Index. Man muß nicht dieses alte Goebbels-Zitat (->http://www.statistik.baden-wuerttemberg.de/Veroeffentl/Monatshefte/PDF/Beitrag04_11_11.pdf) bemühen ("Glaube keiner Statistik ..."), um zu begreifen, daß bloße Popularität auch im Bereich der Programmiersprachen kein vernünftiges Kriterium für irgendwas ist. Abgesehen davon erkennten diejenigen, die diesen schlechten Spruch klopfen, erfahrungsgemäß eine gefälschte Statistik nicht mal dann, wenn sie sie in die Nase bisse. Wenn ich anfangs noch eine gewisse Sympathie den Ansatz und das Motiv betreffend hatte, das ich bzgl. Deines Anliegens zu erkennen glaubte, nämlich den Ansatz, gegen den Trend mit modernen Mitteln minimalistische Lösungen zu erkunden, so sehe ich inzwischen, daß dafür offenbar entweder die Kenntnisse oder das Interesse fehlen, oder beides. Was Du und nicht nur Du nämlich übersiehst und was in den beiden obigen Bemerkungen herauskommt ist der Glaube, daß mit ASM hier und C dort sich gewissermaßen komplementäre Ansätze gegenüberstünden, deren Vorzüge es auszufechten gelte. Wenn man sich aber die Entwicklung der Programmiersprachen der letzten rund fünfzig Jahre betrachtet, beginnend mit Autocoder https://en.wikipedia.org/wiki/Autocoder (ca 1950), Fortran (ca 1957), Algol (1958), Lisp (1958), Snobol (1962), PL/I (1964), APL (1965), Simula (1967), Prolog (1972), ML (1972), C (1973), Haskell (1990), Rust (2010), usw. so sieht man, daß C keineswegs die abstrakte, abgehobene, sperrige Programmiersprache darstellt, die Du darin zu sehen glaubst, sondern eine späte Regression, eine Rückkehr (fast) zu der Sprachebene des Assembler, wenn man aber auf die Erfahrung mit Sprachdesign, Compilerbau und Codegenerierung für Sprachen wie PL/I, Algol, Algol68, Lisp oder Fortran zurückblicken kann. Was man halt macht, wenn man eine PDP11 geschenkt bekommt und damit ein kleines OS portieren (i.e. reimplementieren) möchte, ohne auf den Komfort einer vernünftigen Programmiersprache verzichten zu müssen. Money quote aus http://www.bell-labs.com/usr/dmr/www/chist.html "...and we regretted losing the advantages of writing programs in a language above the level of assembler, such as ease of writing and clarity of understanding". Mein Hauptkritikpunkt an C ist der unterbelichtete Preprocessor. Ein Assembler, mit dem ich vor 'zig Jahren in einem größeren Projekt gearbeitet habe, konnte in der Makrophase erheblich mehr als der C preprocessor heute, so daß sich auf Basis dessen durchaus Kontrollstrukturen oder kleinere DSL bauen ließen. Mein Ansatz, hätte ich auf dem Gebiet irgendwelche Aktien, wäre zu untersuchen, ob sich z.B. ein runtimelibfreies Rust soweit abspecken läßt, daß sich damit auch Plattformen unterhalb des üblichen 32+-Bit-Geraffels als Targent verwenden lassen. Das wäre aber Dickbrettbohren, weil auch das im Moment gegen den allgemeinen Trend geht und mit einer Menge Arbeit verbunden. *) Rhetorisches 101: ignoriere eisern alle guten Gegenargumente, dann werden Deine Widersacher im weiteren Verlauf zunehmend auch die schlechten Argumente durchprobieren. Du hattest aber in dem Moment verloren, als Du Dich geweigert hast, eine abstrakte, vernünftige und abschließende Spezifikation einer Aufgabenstellung zu formulieren, anhand deren man verschiedene Implementationsansätze vergleichen könnte. Der Rest ist nur noch davon ablenkendes Geplänkel.
>vernünftige und >abschließende Spezifikation einer Aufgabenstellung diese müsste aber alle Behauptungen von Moby beinhalten, also auch z.b. vorallem die angebliche einfache Erweiterbarkeit, müsste irgendwie "getestet" werden (ohne konkretes Beispiel wird das nicht gehen..) die "Einfachheit" ansich von ASM (es müsste also definiert werden, was "Einfach" ist..) welche Resourcen wie wichtig sind: also wer "gewonnen" hat wenn die (dann erweiterte) Version 1 Byte mehr RAM, die andere dafür 1 Byte mehr Flash braucht.. und man müsste definieren, was denn mit dieser "Aufgabenstellung" bezweickt werden soll, und ob das mit der "Aufgabenstellung" überhaupt möglich ist..
:
Bearbeitet durch User
Jörg W. schrieb: > Ich habe gestern ein Buch über Assembler-Programmierung geschenkt > bekommen. Gratuliere. > In seinem Vorwort enthält es den Absatz: > ... By its very nature, an assembly language has the same life > expectancy as the processor it supports perhaps 20 years at best. An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig. Eine Lebensdauer über ein halbes Menschenleben dürfte es eher treffen. Mit gut gelagerten Reserven allemal. Ansonsten ist die Feststellung unter einem weiteren Gesichtspunkt irrelevant: Egal ob mit Asm oder Hochsprache- ob viele kommerzielle Produkte (heutzutage und vor allem zukünftig bei beschleunigter IT-Entwicklung) auch noch in >20 Jahre unverändert Verwendung finden werden ist doch seeeehr zweifelhaft.
Moby A. schrieb: > An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig. Deine Selbstüberschätzung ist einfach unübertroffen. :-)
ich glaube der denkt nicht wenn er schreibt. Das sind nur Reflexe.
Wolfgang S. schrieb: > so sieht man, daß C keineswegs die abstrakte, abgehobene, sperrige > Programmiersprache darstellt, die Du darin zu sehen glaubst, sondern > eine späte Regression, eine Rückkehr (fast) zu der Sprachebene des > Assembler, wenn man aber auf die Erfahrung mit Sprachdesign, Compilerbau > und Codegenerierung für Sprachen wie PL/I, Algol, Algol68, Lisp oder > Fortran Na ja gemessen an den anderen heißen Kandidaten (für andere, z.T. viel größere Systeme) schon. Das interessiert aber hier jetzt herzlich wenig. > Du hattest aber in dem Moment > verloren, als Du Dich geweigert hast, eine abstrakte, vernünftige und > abschließende Spezifikation einer Aufgabenstellung zu formulieren, > anhand deren man verschiedene Implementationsansätze vergleichen könnte. Und ich sage Dir: Ich könnte noch 100 abstrakte, vernünftige und abschließende Spezifikationen der Aufgabenstellung formulieren und es würde an einem nichts ändern: Ein erfolgreicher C-Nachbauer findet sich nicht. Kann sich nicht finden. Asm bleibt C gegenüber bei 8-Bit MSR eben für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit Übung, Vorbereitung und System drangeht ;-) An der Ausrede für ein derart kleines, höchstdokumentiertes Projektchen, der C-Nachbau würde an einer Spezifikation scheitern, kann ich mich nur regelmäßig belustigen. So, gerade keine Zeit, in der Nacht dann wieder. Vielen Dank für die weiter zahlreichenden Rückmeldungen.
Werner P. schrieb: > ich glaube der denkt nicht wenn er schreibt. Das sind nur Reflexe. Hab auch schon an ELIZA gedacht.
Moby A. schrieb: > Asm bleibt C gegenüber bei 8-Bit MSR eben > für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit > Übung, Vorbereitung und System drangeht ;-) Ich folgere mal daraus: "Wenn man NICHT mit ÜVS rangeht ist ASM gegenüber C NICHT überlegen." Der selbe Satz, aber ohne die beiden Negierungen: "Ohne ÜVS ist ASM gegenüber C unterlegen." Jetzt bringen wir mal ÜVS auf beide Seiten ins Spiel, d.h. der ASM-Programmierer und der C-Programmierer benützen jetzt ÜVS. Dann wird daraus: "Mit ÜVS ist ASM gegenüber C mit ÜVS unterlegen." Oder, salopp ausgedrückt: Der ASM-Programmierer muss sich ganz schön ins Zeug legen (ÜVS) um mit einem systemlosen C-Programmierer mitzuhalten. Gibt sich der C-ler aber auch ein wenig Mühe (also jetzt auch ÜVS) kann der ASM-ler einpacken, denn dieser ist ja schon am Limit. Nichts anderes predigen wir dir ja auch schon die ganze Zeit. Find ich Prima dass der Thread doch noch zu einem Ergebnis gekommen ist das beide Seiten so unterschreiben können!
Moby A. schrieb: > An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig. Deine Meinung? Also dieses wackelige Ding, dessen gesamtes Fundament aus ein bisschen Assemblerprogrammierung besteht? Dieses Machwerk, in das du kein Wissen von erfahrenen Leuten einfliessen lässt? Ja, diese Meinung muss ja Gewicht haben.
le x. schrieb: >> für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit >> Übung, Vorbereitung und System drangeht ;-) > > Ich folgere mal daraus: > "Wenn man NICHT mit ÜVS rangeht ist ASM gegenüber C NICHT überlegen." Diese Schlussfolgerung ist unzulässig.
A. K. schrieb: > Diese Schlussfolgerung ist unzulässig. Wo liegt mein Denkfehler? Pseudocode:
1 | WENN (ÜVS == TRUE) |
2 | DANN (ASM > C) |
Darf ich für den (nicht explizit vorhandenen) SONST-Pfad nicht (ASM < C) annehmen? (OK, eigentlich ASM <= C)
le x. schrieb: > Wo liegt mein Denkfehler? Dass die abstrakte Maschine namens „Moby AVR“ nicht nach den Regeln der Logik arbeitet.
Du hast die Zeile 42 überlesen.
if (das_passt_mir_nicht_in_den_kram) printf("verloren");
EDIT: Damit Moby das versteht. Kann das jemand nach ASM übersetzen?
le x. schrieb: > - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden > durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden) > - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits > - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits > - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits > - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits > - Bit 20: DINP1-LOW > - Bit 21: DINP2-LOW > - Bits 22-23: Checksumme über das Datentelegram > - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in > einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird Das ist in C auch nur eine einfache Zuweisung, bei dem man sich einfach den passenden Datentyp anlegt:
1 | typedef union { |
2 | uint32_t u32Val; |
3 | uint8_t u8Val[4]; |
4 | struct { |
5 | uint8_t uAdc1; |
6 | uint8_t uAdc2; |
7 | uint8_t uAdc12:2; |
8 | uint8_t uAdc22:2; |
9 | uint8_t bPin1:1; |
10 | uint8_t bPin2:1; |
11 | uint8_t uCRC:2; |
12 | };
|
13 | } tVal; |
14 | |
15 | // Das Demo mit 2 Arten der CRC Berechnung:
|
16 | void SetVal(tVal* aVal, uint16_t uAdc1, uint16_t uAdc2, uint8_t bP1, uint8_t bP2) |
17 | {
|
18 | // die Werte bestücken
|
19 | aVal->uAdc1 = uAdc1 & 0xFF; |
20 | aVal->uAdc2 = uAdc2 & 0xFF; |
21 | aVal->uAdc12 = (uAdc1 >> 8) & 0x03; |
22 | aVal->uAdc22 = (uAdc2 >> 8) & 0x03; |
23 | aVal->bPin1 = bP1 ? 1 : 0; |
24 | aVal->bPin2 = bP2 ? 1 : 0; |
25 | uint16_t iCRC = 0; |
26 | // CRC Berechnen anhand Tabelle:
|
27 | const uint8_t CRCTAB[] = {0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4}; |
28 | iCRC = CRCTAB[aVal->u8Val[0] & 0x0F]; |
29 | iCRC += CRCTAB[(aVal->u8Val[0] >> 4) & 0x0F]; |
30 | iCRC += CRCTAB[aVal->u8Val[1] & 0x0F]; |
31 | iCRC += CRCTAB[(aVal->u8Val[1] >> 4) & 0x0F]; |
32 | iCRC += CRCTAB[aVal->u8Val[2] & 0x0F]; |
33 | iCRC += CRCTAB[(aVal->u8Val[2] >> 4) & 0x03]; |
34 | aVal->uCRC = iCRC % 4; |
35 | // CRC Berechnen mit einer Schleife:
|
36 | iCRC = 0; |
37 | for (uint16_t i = 0; i <= 21; i++) { |
38 | if ((aVal->u32Val >> i) & 1) |
39 | iCRC++; |
40 | }
|
41 | aVal->uCRC = iCRC % 4; |
42 | }
|
Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle Schnittstelle. PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.
:
Bearbeitet durch User
le x. schrieb: > A. K. schrieb: >> Diese Schlussfolgerung ist unzulässig. > > Wo liegt mein Denkfehler? https://de.wikipedia.org/wiki/Kontraposition
Operator S. schrieb: > le x. schrieb: >> A. K. schrieb: >>> Diese Schlussfolgerung ist unzulässig. >> >> Wo liegt mein Denkfehler? > > https://de.wikipedia.org/wiki/Kontraposition Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird wohl nix...
le x. schrieb: > Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird > wohl nix... In C würde man ja zum Beenden der Endlosschleife einfach ein
1 | break; |
schreiben. ;-)
le x. schrieb: > Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird > wohl nix... Beenden? Aber... was soll ich dann mit meiner ganzen frei werdenden Zeit machen? Und Moby erst!
Markus M. schrieb: > PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. VERLOREN! Der Code DARF nicht auf einem mc ausserhalb von Mobys Universum laufen! Gruß, Stefan
Werner P. schrieb: > EDIT: Damit Moby das versteht. Kann das jemand nach ASM übersetzen?
1 | db MSG 'verloren' |
2 | |
3 | Loop: |
4 | LDI Z, MSG |
5 | CALL Sende_String_in_Z |
6 | JMP Loop |
>PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.
Wie ineffizient ist das denn
Matthias L. schrieb: > Wie ineffizient ist das denn Das ist egal. Auf einem STM32 laufen keine typischen 8-Bit-MSR-Anwendungen. mfg.
Operator S. schrieb: > Beenden? Aber... was soll ich dann mit meiner ganzen frei werdenden Zeit > machen? Und Moby erst! Endlich C lernen.
le x. schrieb: > Darf ich für den (nicht explizit vorhandenen) SONST-Pfad nicht (ASM < C) > annehmen? Aus einer falschen Prämisse folgt nichts. Bei WENN a DANN b: a:true dann b:true a:false dann b:any
Matthias L. schrieb: > Werner P. schrieb: >> EDIT: Damit Moby das versteht. Kann das jemand nach ASM übersetzen? > >
1 | > db MSG 'verloren' |
2 | > |
3 | > Loop: |
4 | > LDI Z, MSG |
5 | > CALL Sende_String_in_Z |
6 | > JMP Loop |
7 | > |
> > > > >>PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. > > Wie ineffizient ist das denn Falsch, muß auf Tiny13 laufen und der braucht kein CALL, weil RCALL +-2k abdeckt und hat es deshalb auch nicht. Ob Moby es kennt? Bei entsprechender ÜVS (oder war es ÜSV?) kann man auch auf xMega ohne CALL auskommen. Man muß ja nur Caller und Callee richtig positionieren. Zudem: CALL braucht 4 Bytes statt den zweien des RCALL's. Damit werden der Nachwelt wertvolle unbenutzte Flash-Zellen vorenthalten. Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung" untersucht, dann kommen unbenützte Speicherbereiche schlecht weg.
:
Bearbeitet durch User
Gu. F. schrieb: > Endlich C lernen. Das würde er gerne. Hat er auch schon probiert. Aber C lässt sich von ihm nicht lernen. Programmiersprachen haben auch ihren Stolz. mfg.
Carl D. schrieb: > Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung" > untersucht, dann kommen unbenützte Speicherbereiche schlecht weg. Hihi genau. Und dank diesem Thread hier steht das auch ganz oben.
Matthias L. schrieb: > Carl D. schrieb: >> Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung" >> untersucht, dann kommen unbenützte Speicherbereiche schlecht weg. > > Hihi genau. Und dank diesem Thread hier steht das auch ganz oben. War ja nicht extrem ernst gemeint. Aber etwas nutzlos zu produzieren, damit einer sich daran aufgeilt es nicht zu benutzen, ist doch leicht schräg, oder?
le x. schrieb: > Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird > wohl nix.. Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott. Ob mich daß bei Deinem Logik-Verständnis weiter oben überraschen sollte? Na dann wenigstens Dankeschön für die (letzte) Live-Demo der Sinnlosigkeit jeglicher wiederholter "Spezifikation". Oder? Markus M. schrieb: > Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle > Schnittstelle. > > PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige Bruchwerk aber noch nirgendwo. Von konkreten Ressourcenverbrauchs-Fakten ganz zu schweigen. Eine klassische serielle Schnittstelle wird von meinem Code auch nicht bedient. P. M. schrieb: > Also dieses wackelige Ding Langsam machst Du mit Deinen kompetenten Beobachtungen Carl D. Konkurrenz... Mein Code steht bombenfest, bewährt sich längst in der Praxis- aber Du machst mir nicht den Eindruck, daß Du Dich damit jemals befasst hast undoder ihn überhaupt verstehst. :-( > kein Wissen von erfahrenen Leuten einfliessen lässt Lass das mal in Deine C-Fassung einfließen. Da werd ich aber lange warten. Dann dann zeigt sich schnell wer hier wen belehren müsste ;-)
Moby A. schrieb: > Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott. Unglaublich! :-) Da hängt er schon seit einer Ewigkeit in den Seilen und trotzdem kommt immer sowas wie 'Hat ja gar nicht weh getan!'. Da wird der Kampf sicherlich über 2000 Runden gehen. Wobei...: Der Ringrichter wettet auf den Verlauf des Kampfes?! ;-/
Clemens M. schrieb: > Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu > haben ist Moby irgendwie wirklich verzweifelt.... Du solltest besser am RAM-Bedarf eines C-Compilers verzweifeln. Scheint ja ein fetter Pferdefuß des fetten C zu sein. Beim ganzen Rest Deiner konstruierten Jammerei erinnerst Du mich an einen gewissen Sheeva ;-) Michael K. schrieb: > Nutzloses RAM zu initialisieren Kein Problem Michael. Das und die Sleep Geschichte wird noch rausgestrichen! Für den Vergleich hier ist das überflüssig. Da wird der Volkszorn der Trolle, Stänkerer und verkrachten C-Existenzen zwar hier wieder hochkochen, jeder einigermaßen neutrale und rationale Beobachter wird mir aber zugestehen, daß nur gleiche mit gleicher Funktionalität verglichen werden sollte und eine Ram- bzw. Sleep Initialisierung nicht auf der Agenda äh "Spezifikation" steht. Macht dann nach Adam Riese weniger als 200 Bytes verbrauchter Flash ;-) > Mit Verlaub. > Das ist vollkommener Müll. Du meinst weil klar ist, daß man es in C nicht kürzer gebacken bekommt? > Die unterste Schmerzgrenze für Sensor Aktor Knoten sehe ich bei > adressierbaren Master Slave Feldbussen mit min. 16 Teilnehmern. Bist Du von der Industrie? Dann wär mir alles klar. So einer muß die überteuerten Preise dort irgendwie rechtfertigen. Schenk Dir das. Geht alles viel simpler, viel billiger ;-)
Ralf G. schrieb: > Unglaublich! ... sind meistens Dinge, deren Zustandekommen man falsch einschätzt ;-)
A. K. schrieb: > Hab auch schon an ELIZA gedacht. Da ist was dran ;-) So wie ein großer Teil der C-Überzeugungstäter hier konstant weg von den unangenehmen Fakten meines Projekts driftet müssen diese Leute konstant auch wieder zurück zu den wunden Punkten (=Ressourcenverbrauch) geführt werden. Da brauchts Eliza-gleiche Geduld ;-) Johann L. schrieb: > Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm > findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und > komplett versagt? Wer wird denn hier von Versagen reden? Der Vorteil simpler Codierung ohne viel Bürokratie bleibt Asm dann immer noch. Nur die Ressourcen-Geschichte hätte sich dann (für mich) erledigt. Du redest da aber von Wunschträumen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > le x. schrieb: >> Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird >> wohl nix.. > > Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott. > Ob mich daß bei Deinem Logik-Verständnis weiter oben überraschen sollte? > Na dann wenigstens Dankeschön für die (letzte) Live-Demo der > Sinnlosigkeit jeglicher wiederholter "Spezifikation". Oder? > > Markus M. schrieb: >> >> PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. > > Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige > Bruchwerk aber noch nirgendwo. Von konkreten Ressourcenverbrauchs-Fakten > ganz zu schweigen. Eine klassische serielle Schnittstelle wird von > meinem Code auch nicht bedient. > > P. M. schrieb: >> Also dieses wackelige Ding > > Langsam machst Du mit Deinen kompetenten Beobachtungen Carl D. > Konkurrenz... > Mein Code steht bombenfest, bewährt sich längst in der Praxis- aber Du > machst mir nicht den Eindruck, daß Du Dich damit jemals befasst hast > undoder ihn überhaupt verstehst. :-( > >> kein Wissen von erfahrenen Leuten einfliessen lässt > > Lass das mal in Deine C-Fassung einfließen. Da werd ich aber lange > warten. Dann dann zeigt sich schnell wer hier wen belehren müsste ;-) Moby, falls du das Theater hier selber ernst nehmen solltest.: Du bist der Einzige! Ja, DER EINZIGE. Welche Motivation sollte ein Leser hier haben, in seiner Freizeit ein Programm zu schreiben, welches er niemals für irgend etwas einsetzen wird? Ja, warum sollte er das wohl tun? Nur um über deine Stöckchen zu springen? Deinen Ego Trip weiter anzuheizen? Du bietest weder eine spannende Herausforderung noch sinnvolle Regeln. Dein beabsichtigter Ram-und-Flash Kontest ist wenig Anspruchsvoll, um nicht zu sagen einfach nur lächerlich. Du scheinst das nicht zu merken - als Einziger. Ich und auch kein anderer möchten dir den Erfolg deines privates Projektes und seine Funktion in Abrede stellen. Es ist und bleibt ein tolles Gefühl, selbst etwas auf die Beine gestellt und zum Laufen gebracht zu haben. Doch stellt sich dann niemand hin und schwört auf die Überlegenheit seiner Programmiermethode. Wenn du Interesse an einer vergleichenden Betrachtung gehabt hättest, wärest du den Bitten nach den Specs deines Projektes mit mehr Eifer nachgekommen und hättest nicht auf deinen ASM Code verwiesen. Wissen wir denn, ob der deine Specs überhaupt erfüllt? In der Schule haben wir gelernt, dass jede Aufgabe über die Aufgabenstellung formuliert wird. Je klarer die ist, umso weniger Streit gibt es bei der Interpretation der Ergebnisse. Lange Rede.. Wenn du wirklich Interesse hast, dann komm mit etwas vernünftigen, etwas worüber sich die sach- und fachliche Auseinandersetzung für alle Seiten hier lohnt. Deinen Kinderspielchen sind hier alle schon längst erwachsen. Mir scheint es, als ob selbst die fachliche Beurteilung der hier schon gebotenen Lösungen oder Teillösungen deinen Horizont meilenweit überschreitet. Zu keinem Ansatz hast du jemals Stellung bezogen. Warum sollte also jemand etwas liefern? Wozu? Du erwartest nur die nackte Programmgröße. Ich habe den Eindruck, dass du damit im falschen Forum gelandet bist. Wenn du das gleich wieder als Resignation vor der Aufgabe, Versagen der C-Fraktion, Üblegenheit deiner Progammierkunst oder dergleichen interpretieren wirst,.. es ist alles nur in deinem Kopf so.. ..und ich programmiere auch fast alles in ASM - noch, weil ich mehr und mehr von der Überlegenheit von C überzeugt bin und es deshalb lerne.
Nachdem ich die Antwort auf alle möglichen Fragen gefunden habe, hat man einfach die Fragen geändert... Nachdem ich alle Lösungen zu einem Problem gefunden habe, hat man das Problem geändert. Nachdem es keine Probleme mehr gab ... bin ich wieder zur Maschinensprache zurück gekehrt ( smile nein, bin ich nicht grundsätzlich ). Das wäre jetzt so, als würde man mir sagen: Hey, schreibe absichtlich wieder schier unwartbare Programme. Witzig ist schlicht: alte Programmteile (egal ob in Pascal, Delphi oder C) wie bspw. Interpolationsfunktionen, "Linearisierungen" von NTC Widerständen, Funktionsparser konnte ich von meinen uralten zum Teil aus C/PM Zeiten stammende Routinen relativ gut nach C portieren. Die meisten Assemblerfunktionen nicht (okay, in Wirklichkeit war mir der Aufwand zu groß und ich habs lieber neu geschrieben). Es ist für mich sowas von unglaublich, dass man sich auf das Niveau von Herrn M. herunterziehen lässt und seine "Anforderungsliste" übernimmt wo es doch hunderttausende Vorzüge einer höheren Sprache (egal welche) gegenüber ASM gibt. Wie kann man nur so verbohrt sein, seine "Lieblingssprache" auf so extrem wenige (und sorry, wirklich relativ triviale) Anwendungen zu begrenzen? Die Welt... besteht nicht nur aus (von Herrn M. definierten) 8 Bit Anwendungen. Ein bestes Beispiel: ich bin hoch fasziniert von einem Mitglied hier, der einen Softwaresynthesizer auf einem ATmega (und das in meiner Meinung nach guten Qualität) hinbekommen hat (ehrliche Hochachtung hierfür). Viele Teile des Syntesizers sind in C geschrieben und nur die wirklich zeitkritischen in Assembler. Ich war/bin wirklich davon fasziniert. Dieses Teil Lehrlingen gezeigt können diese meine Faszination (eigentlich zu Recht) nicht verstehen: "Herr xyz, das ist ja schön und gut, aber auf unseren STM Nucleoboards benötigt es hierfür keine Maschinensprache). Was erwiedert man einer solchen Aussage? Nichts, denn sie haben schlicht recht. Würde ich ein Spielzeug entwerfen, dass ich was weiß wieviele 1000 mal verkaufen würde, würde der Preis vllt. eine Rolle spielen und deshalb wohl hierfür ein AVR eingesetzt werden, aber selbst in diesem Falle ist der Hauptanteil in C geschrieben. Ich würde gerne mal einen Softwaresynthesizer von Herrn M. sehen, der komplett in ASM gemacht ist !!! Hier wird extrem viel ohne Beweise behauptet und jetzt lasse ich mich auf das gleiche ein: Ich erkenne an, dass ASM so viel flexibler und einfacher ist, wenn Herr M. einen Syntesizer schreibt (das sind jetzt Specs) die: - min. 4 stimmige unterschiedliche Instrumente spielen können - eine Mididatei die auf einem PC in ein beliebiges proprietäres Format gewandelt werden dürfen und einem AVR über ein Nachladen von einer SD Karte zugeführt werden - der Rauschabstand nicht kleiner als 50 dB betragen darf (ich hoffe dass Herr M. weiß was das ist) Ich (und das nehme ich mir heraus weil ICH und nicht Herr M. die Specs bestimmt) äußere: das ist eine 8 Bit Anwendung weil es auf einer 8 Bit MCU läuft ! ASM hat gewonnen, wenn er dieses in 3 Wochen zum Laufen gebracht hat ! Ich verschärfe jetzt nicht in dem ich verlange, dass er den Code den er erstellt hat nun auf einer anderen Plattform zum Laufen bringt (denn ich will den auf AVR funktionierenden Code nicht nach STM32 portieren, glaube aber, dass ich wohl doch in der Lage wäre das auch auf einem Nucleo hin zu bekommen). ( ich glaube ich kann jetzt schon ein höhnisches Gelächter von Herrn M. hören und ich glaube ich kann auch schon die Gebetsmühlenartig vorgetragenen unsinnigen "Argumente" und "Forderungen" hören ). Was ich wirklich nicht glauben kann ist, dass ich mich hinreisen lasse und hier einen Kommentar schreibe. Aber irgendwie ist das wie mit der Maschinensprache: Manche Dinge faszinieren ohne wirklich erkennbaren Grund ... und hier ist es die Ignoranz). Wenn Herr M. kein "Projekt" (ich sage mal, dass eine Minisensorplatine einfach kein "Projekt" ist) veröffentlichen will (weil uns das ja angeblich nicht "interessiert"), dann soll er doch mal wenigstens erzählen, welches seiner Projekte, die er ja schon erarbeitet hat, 10 KByte groß sind (Hex-File) und was die jetzt alles in allem können ! Was .... wurde denn in so großer Menge schon realisiert und in welcher Zeit? Warum richten sich die "Diskutanten" nach den Anforderungen von Herrn M., warum stellen sie nicht ihre eigenen Specs ? Hier im Forum wimmelt es nur so von wirklichen Schätzen bei denen sich manche Programmierer in C das Hirn verrenkt haben (smile, "nur" um etwas in den nächstkleineren Controller zu bekommen)... Ich will sehen wie Herr M. das schafft. Immer dann, wenn gerechnet werden muß, immer dann wenn floating point ins Spiel kommt, spätestens dann wird es mit ASM kritisch. Gute Nacht
Markus M. schrieb: > ..und ich programmiere auch fast alles in ASM - noch, weil ich mehr und > mehr von der Überlegenheit von C überzeugt bin und es deshalb lerne. ... es geht nicht darum, was "überlegen" ist, es geht darum, mit welchem Aufwand ein Problem bewältigt werden kann. Entwicklerzeit = Aufwand. Eliminiert ein geringerer Hardwarepreis einen höheren Entwickleraufwand, wird eine preiswertere Hardware verwendet, ansonsten eben nicht ! Preis Reichelt (okay, nicht WIRKLICH zwingend Bezugsquelle Nr. 1): ATtiny13 SOIC (1k Byte Flash / 64 Byte RAM) => 0,86 Euro ATtiny85 SOIC (8k Byte Flash / 512 Byte RAM) => 1,30 Euro Um wieviel länger darf ich da entwickeln, dass da noch etwas in den Tiny13 passt ?
Also ehrlich, wäre es nicht mal an der Zeit mal an die frische Luft zu gehen und einzuatmen und die schöne Natur zu bewundern. Mal Schifahren zu gehen oder Eislaufen, oder sonst irgendetwas, aber nur nicht mit der Elektronik verbunden. Da bekommt dann gleich eine andere Einstellung. Wenn man den ganzen Tag vor dem Monitor sitzt, verblödet man doch fast und frisst sich leicht in einer Furche fest. Gut gemeint, Gerhard
Moby A. schrieb: > Der Vorteil simpler Codierung > ohne viel Bürokratie bleibt Asm dann immer noch. Nur die > Ressourcen-Geschichte hätte sich dann (für mich) erledigt. Du redest da > aber von Wunschträumen ;-) Der Vorteil der simplen Codierung ist für dich, dass du deine simplen Programme auch ohne eine Hochsprache zu lernen gebacken bekommst. Moby A. schrieb: > So wie ein großer Teil der C-Überzeugungstäter hier konstant weg von den > unangenehmen Fakten meines Projekts driftet müssen diese Leute konstant > auch wieder zurück zu den wunden Punkten (=Ressourcenverbrauch) geführt > werden. Unangenehm ist lediglich dein infantiles Getue, weil nun nienamd mehr mit dir spielen will. Der Resourcenverbrauch in C ist in erster Line von dem abhängig, der vor dem Rechner sitzt. Das ist in ASM nicht anders. Falls du dir den Gefallen tust, und mal bischen C lernen würdest, wäre das deine erste Erkenntnis. Ich habe übrigens mal ähnlich verbockt auf C geschimpft. Grund war mein Frust über die "kryptische Syntax". Ja, sicher wäre es einfacher gewesen, ich hätte vor 30 Jahren damit begonnen. Stattdessen gab es da auch für mich Z80 in ASM und OP-Code. Das erste, was ich nach dem Kompilieren meiner C-Versuche mache, ist das Untersuchen der ASM Ausgabe des Compilers. Und ehrlich, ich war überrascht wie kurz und elegant der Compiler übersetzt. Tut er es mal nicht, dann hat das seinen Grund im Quellcode. Er sieht dann etwas, was ich übersehen, oder zumindest anders gemeint habe. Aber mit ÜVS wird das ASM Listing immer kürzer und knackiger.
Gerhard O. schrieb: > Mal Schifahren zu gehen oder Eislaufen Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf gefallen dabei. :o/ Ich bevorzuge doch lieber Fortbewegungsmittel mit ordentlichen Bremsen. :) Viele Grüße nach Kanada, ist vermutlich kühler dort als hier.
Ralph S. schrieb: > Die Welt... besteht nicht nur aus (von Herrn M. definierten) 8 Bit > Anwendungen. Da hast Du doch Recht! Nur für diese rede ich aber hier. Es sind aber immer noch Millionen... Z.B. im großen Feld Smart Home. Markus M. schrieb: > Du bist der Einzige! > Ja, DER EINZIGE. Und Du meinst, eine solche Feststellung hätte irgend einen Wert als fachliches Argument? Mich beeindruckt das nicht, das Ablenkungs-Theater von der von mir demonstrierten Asm-Effizienz hat aber einen gewissen Unterhaltungswert ;-) > Welche Motivation sollte ein Leser hier haben, in seiner Freizeit ein > Programm zu schreiben, welches er niemals für irgend etwas einsetzen > wird? Ja, warum sollte er das wohl tun? "Programm" ist erstens schonmal arg übertrieben. Zweitens muß das niemand tun. Wer aber meinen Aussagen zu den Ressourcenvorteilen von Asm überzeugend wiedersprechen will wird nicht umhinkommen, dies an meinem bereits fertigen Projektchen durch die Fakten einer C-Fassung zu belegen. So ein 200 Byte-Kaliber sollte für die behauptet hochexpertiösen Protagonisten hochproduktiven C's wirklich kein Problem sein ;-)
Jörg W. schrieb: > Gerhard O. schrieb: >> Mal Schifahren zu gehen oder Eislaufen > > Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf > gefallen dabei. :o/ Eislaufen ist heimtückischer wie Schifahren. Beim Schifahren hat man viel mehr Möglichkeiten zur Korrektur. > > Ich bevorzuge doch lieber Fortbewegungsmittel mit ordentlichen Bremsen. Da hast Du auch wieder recht. > :) > > Viele Grüße nach Kanada, ist vermutlich kühler dort als hier. Nicht zu schlimm. Nur -6 Grad im Augenblick obwohl es in ein paar Tagen sehr viel kühler werden soll(-20). Mit dem ganzen Schnee ist einer weihnachtlichen Stimmung nichts im Wege gelegt. Schnee in den Bergen ist reichlich und die Schifahrer sind Happy. Viele Grüße nach D, Gerhard
Markus M. schrieb: > Der Vorteil der simplen Codierung ist für dich, dass du deine simplen > Programme auch ohne eine Hochsprache zu lernen gebacken bekommst. So simpel sind offensichtlich selbst 200 Byte Asm Programme nicht, sonst hätten wir längst eine reelle C-Vergleichsmöglichkeit auf dem Tisch ;-) Und ja doch, Asm ist simpel! Da gibts bei 8-Bit MSR keinerlei Veranlassung auf Umständlicheres und Bürokratischeres und Komplexeres zu wechseln! Das spricht für Asm! > Unangenehm ist lediglich dein infantiles Getue, weil nun nienamd mehr > mit dir spielen will. Asm ist vergleichsweise infantil im Vergleich zu C. Man kann auch sagen simpler ;-) > Der Resourcenverbrauch in C ist in erster Line von dem abhängig, der vor > dem Rechner sitzt. Das ist in ASM nicht anders. Klar gibts auch diese Abhängikeit. Die interessiert hier aber nicht. Hier gehts um objektive Mängel von Hochsprache. Dokumentiert in sovielen C-Problemthreads. Um mal einen aktuellen aufzugreifen: Beitrag "Einstieg in C - komische Fragen" > Falls du dir den Gefallen tust, und mal bischen C lernen würdest, wäre > das deine erste Erkenntnis. Die ersten "Erkenntnisse" sind in obigem Thread wunderschön beschrieben. Ich komm geradezu ins Schwärmen ;-) > Das erste, was ich nach dem Kompilieren meiner C-Versuche mache, ist das > Untersuchen der ASM Ausgabe des Compilers. Das brauch ich nicht. Das hab ich zum Glück selber in der Hand. > Und ehrlich, ich war > überrascht wie kurz und elegant der Compiler übersetzt. Tut er es mal > nicht, dann hat das seinen Grund im Quellcode. Eleganz käme frühestens dann zum Tragen, wenn die Anzahl der Register nicht mehr ausreicht. Das ist mit Übung, Vorbereitung und System noch für viele viele KB AVR Code bei 8-Bit MSR kein Thema! > Aber mit ÜVS wird das > ASM Listing immer kürzer und knackiger. Nur leider nicht so knackig wie mit pure Asm ;-) Von den vielen richtig zu bedienenden Stell- und Optimierschrauben in C ganz abgesehen.
Moby A. schrieb: > So ein 200 Byte-Kaliber sollte für > die behauptet hochexpertiösen Protagonisten hochproduktiven C's wirklich > kein Problem sein ;-) Ist es auch nicht. Aber die beschäftigen sich lieber mit ernsthafteren Sachen. Und "Resourcenverbrauch" verstehen die/wir nicht als Flashverbrauch. Denn Flash verbraucht nicht. Er ist nach wie vor vorhanden. Und je besser er genutzt wird, um so besser ist die Resourcennutzung. Und um die geht es. Die Resourcen "Flash" und "SRAM" durch maximale Kastration der Programme nur unzureichend zu nutzen, stellt eine reine Resourcenverschwendung da. Warum möchtest du einen professionellen Softwareersteller dazu bewegen? Das Ergebnis wird weder besser noch schlechter, wenn es 2 Byte mehr oder weniger Speicher belegt. Das ist der Punkt!
Markus M. schrieb: > Die Resourcen "Flash" und "SRAM" durch maximale Kastration der Programme > nur unzureichend zu nutzen, stellt eine reine Resourcenverschwendung da. Du hast nicht verstanden, daß es mir um die prinzipiellen Vorteile von Asm geht. Was konkret wie in der Praxis genutzt werden kann steht auf einem anderen Blatt. Wenn Asm aber weniger Ressourcen erfordert (mit ÜVS) ist das doch nur gut. Wenn die Programmierung mit der bloßen Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC geschehen kann umso besser. > Warum möchtest du einen professionellen Softwareersteller dazu bewegen? Irrtum. Ich möchte eigentlich selber überzeugt werden. Das ist hier aber momentan auf einem ganz ganz schlechten Weg ;-)
Moby A. schrieb: > Asm ist vergleichsweise infantil im Vergleich zu C. > Man kann auch sagen simpler ;-) Das darf und kann nur jemand beurteilen, das beide Sprachen beherrscht. Schon aus meiner Sicht ist deine Aussage falsch.
Moby A. schrieb: > Wenn die Programmierung mit der bloßen > Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC > geschehen kann umso besser. Und genau das macht der C-Kompiler. Je nach Optimierungsstufe mal mit Schwerpunkt Codelänge oder Ausführungsgeschwindigkeit. Moby A. schrieb: >> Warum möchtest du einen professionellen Softwareersteller dazu bewegen? > > Irrtum. Ich möchte eigentlich selber überzeugt werden. Das ist hier > aber momentan auf einem ganz ganz schlechten Weg ;-) Daran ist dein bisherriges Verhalten nicht ganz unursächlich. Mein Rat: lerne ein bischen C und überzeug dich selbst. Dass du hier professionelle Hilfe bekommen kanst, weißt du sicherlich auch. Du wirst sehen, welch wunderbar kurzen und knackigen Code der Compiler produziert bzw produzieren kann. Damit kannst du deine ASM Kenntnisse sogar noch weiter ausbauen. Und der Aufwand, das Programm nach deinen Wünschen umzugestalten ist weitaus geringer als auf ASM Ebene. Das ist für mich ein entscheidender Vorteil. Diesen bezahlst du aber keineswegs mit mehr Overhead oder ähnlichem. Vlt bringst du ja auch C nur in irgend einer Hinsicht mit Bascom in Verbindung und beziehst daraus deine Vorurteile(?)
Markus M. schrieb: > Das darf und kann nur jemand beurteilen, das beide Sprachen beherrscht. Das kannst Du gern so festlegen. Mit C durfte ich durchaus schon intensiv Bekanntschaft schließen. Viel aussagekräftiger sind aber entsprechende Problemthreads hier, wo mit viel Erfahrung noch jeder Haken der Hochsprache zum Vorschein kam. Du mußt doch nicht glauben, daß die Vorteile von C (z.B.beim Rechnen, beim Handling größerer Datenmengen) mit Nix erkauft werden... Die allerbeste Beurteilung der C-"Vorzüge" aber ist, daß sich hier bislang keiner der sonst so sprachgewaltigen Experten imstande sieht, ein kleinwenig Funktionalität in C zu coden. Natürlich weiß ich warum ;-) Mit "lerne ein bischen C" hast Du bei mir keine Chance. Da will ich schon mehr sehen!
:
Bearbeitet durch User
Jörg W. schrieb: > Moby A. schrieb: > An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig. > > Deine Selbstüberschätzung ist einfach unübertroffen. :-) Sollte mich das jetzt von irgendwas überzeugen? Warum gehst Du nicht darauf ein was ich sagte? Vielleicht, weils richtig war ? ;-)
Moby A. schrieb: > Wenn die Programmierung mit der bloßen > Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC > geschehen kann umso besser. Noch was.. Geht es um das initialisieren der Peripherie, das setzen von Registern, das Hin- und Herschieben von Registerinhalten, um Bitmanipulationen, dann nehmen sich C und Hand-ASM nichts. Wenn dem Controller aber eswas "Grips" eingehaucht werden soll, wenn Berechnungen, die über einfachste Additionen hinausgehen implementiert werden sollen, wenn skalierbare Datenstrukturen angelegt werden müssen, Statemaschinen her müssen, oder das Programm einfach nur sehr umfangreich wird, dann ist der Compiler in jeder Beziehung besser. Ihn zu schlagen würde - wenn es überhaupt möglich wäre - einen enormen Zeitaufwand verursachen. Ich sehe in ASM mittlerweile keinerlei Vorteile mehr. Vertrau dem Kompiler, kontrolliere seinen Output. Du wirst sehen, der verarscht dich nicht und macht auch nicht heimlich Dinge die du nicht willst.
Jörg W. schrieb: > Selbst eine Implementierung in C müsste > notwendigerweise exakt den gleichen Assemblercode liefern, um akzeptiert > zu werden. Wie kommst Du auf diesen ausgemachten Blödsinn? Hinter solchen Aussagen scheint doch die nackte Angst durch: Wenn wir unseren C-Compiler nicht zum gleichen Asm-Output bewegen können haben wir verloren!!! ;-)
Moby A. schrieb: > Natürlich weiß ich warum > ;-) > > Mit "lerne ein bischen C" hast Du bei mir keine Chance. > Da will ich schon mehr sehen! Mit dieser Einstellung wirtst du das niemals sehen. Moby A. schrieb: > Du > mußt doch nicht glauben, daß die Vorteile von C (z.B.beim Rechnen, beim > Handling größerer Datenmengen) mit Nix erkauft werden... Geglaubt wird in der Kirche ;-) Die Vorteile werden nicht "erkauft". Sie resultieren aus der Fähigkeit des Compilers, den "Überblick" auch bei noch-so-großen Datenmengen nicht zu verlieren und jederzeit in wenigen Sekunden ein optimales Ergebnis zu liefern. Moby A. schrieb: > Die allerbeste Beurteilung der C-"Vorzüge" aber ist, daß sich hier > bislang keiner der sonst so sprachgewaltigen Experten imstande sieht, > ein kleinwenig Funktionalität in C zu coden. Natürlich weiß ich warum > ;-) Nein, du glaubst es nur zu wissen. Warum das so ist, habe ich oben dargestellt, und viele andere versuchen dir das auch klar zu machen. N8
Markus M. schrieb: > Geht es um das initialisieren der Peripherie, das setzen von Registern, > das Hin- und Herschieben von Registerinhalten, um Bitmanipulationen, > dann nehmen sich C und Hand-ASM nichts. Das ist richtig. Das hatte ich ein paar Hundert Beiträge weiter oben auch schon festgestellt. > Wenn dem Controller aber eswas "Grips" eingehaucht werden soll, wenn > Berechnungen, die über einfachste Additionen hinausgehen implementiert > werden sollen, wenn skalierbare Datenstrukturen angelegt werden müssen, > Statemaschinen her müssen, oder das Programm einfach nur sehr > umfangreich wird, dann ist der Compiler in jeder Beziehung besser Das ist ebenfalls richtig. Das hatte ich ein paar Hundert Beiträge weiter oben ebenfalls schon festgestellt. > Ich sehe in ASM mittlerweile keinerlei Vorteile > mehr. Das ist falsch. Denn Du unterschlägst mal eben Millionen MSR-Anwendungen, die eben keine aufwendigen Berechnungen und Datenstrukturen enthalten. > Vertrau dem Kompiler, kontrolliere seinen Output. Du wirst sehen, > der verarscht dich nicht und macht auch nicht heimlich Dinge die du > nicht willst. Dazu gilt es aber eine Bürokratie und Ineffizienz in Kauf zu nehmen, die für obige Anwendungen nicht zwingend sind.
Moby A. schrieb: > Klar gibts auch diese Abhängikeit. > Die interessiert hier aber nicht. > Hier gehts um objektive Mängel von Hochsprache. > Dokumentiert in sovielen C-Problemthreads. > Um mal einen aktuellen aufzugreifen: Ach Moby.. Diese Abhängigkeit ist _das Entscheidende!_ Und sie ist der Grund für die sog. "Problemthreads"!! Sie resultieren nicht aus Unzulänglichkeiten des Compilers oder der Sprache C! Na klar hat man als Anfänger noch nicht den Überblick über alles!! Ja, das ist in ASM alles einfacher, weil da kein Compiler zwischengeschaltet ist. Mit zunehmenden Lernerfolg wird man aber auf genau diese "Probleme" sensibilisiert. Das Denken nimmt einem der Compiler nicht auch noch ab! Und so weit, dass der Compiler weiß was der Mensch davor gemeint hat, oder gar Kommentare liest, soweit sind wir noch nicht! Was erwartest du eigentlich?
Moby A. schrieb: > Dazu gilt es aber eine Bürokratie und Ineffizienz in Kauf zu nehmen, die > für obige Anwendungen nicht zwingend sind. Beweise das an konkreten Beispielen und stelle die Nachteile in jeglicher Hinsicht nachvollziehbar dar. Definiere den Begriff Nachteil, bewerte ihn in jeglicher Hinsicht. Beweise, dass C überflüssigen Code produziert. Belege die "Bürokratie" entsprechend mit Codebeispielen. ..oder schweige zu diesem Thema für immer.
Moby A. schrieb: > Das ist falsch. > Denn Du unterschlägst mal eben Millionen MSR-Anwendungen, die eben keine > aufwendigen Berechnungen und Datenstrukturen enthalten. Millionen... Nenn uns doch bitte mal zehn.
Markus M. schrieb: > Beweise das an konkreten Beispielen und stelle die Nachteile in > jeglicher Hinsicht nachvollziehbar dar. Du kannst gerne an meinem fertigen Beispiel Deine besseren C-Verbrauchsfakten demonstrieren ;-) > Beweise, dass C überflüssigen Code produziert. Obiges gelingt 1000 C-Experten nicht ;-) > Belege die "Bürokratie" entsprechend mit Codebeispielen. Dafür brauchts nichtmal Beispiele. Dafür langt schon ein Blick ins dicke C-Buch ;-) > ..oder schweige zu diesem Thema für immer. Das könnte Dir so passen ;-) Nichtsdestotrotz wünsch ich Dir maximalen Erfolg mit Deinem C. So, jetzt kannst Du guten Gewissens schlafen gehen. Du hast alles versucht ;-)
Kinder, Kinder! Wenn ihr so weitermacht, dann schafft Ihr es bald ins Guiness Book of Records zu kommen... https://en.m.wikipedia.org/wiki/Guinness_World_Records
Moby A. schrieb: > Jörg W. schrieb: >> Selbst eine Implementierung in C müsste >> notwendigerweise exakt den gleichen Assemblercode liefern, um akzeptiert >> zu werden. > > Wie kommst Du auf diesen ausgemachten Blödsinn? > Hinter solchen Aussagen scheint doch die nackte Angst durch: Wenn wir > unseren C-Compiler nicht zum gleichen Asm-Output bewegen können haben > wir verloren!!! ;-) Nö, ein gewisser Moby hat es genau so geschrieben. Das ist der Nachteil schriftlicher Statements. Sie können jederzeit zu 100% rekonstruiert werden. Das mit der nackten Angst (vor was auch immer) trifft eher dich. > Obiges gelingt 1000 C-Experten nicht ;-) Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu korrigieren. Das ist nämlich dein eigentliches Problem: ein zementiertes Weltbild, zumindest beim Thema "Programmieren von MobySpartRam-Anwendungen". Andere machen das nur, wenn es knapp wird.
:
Bearbeitet durch User
Wie schafft ihr es eigentlich hier im Forum nächtelang Tinte zu verspritzen und dann am nächsten Morgen algorithmische Höchstleistungen zu leisten? Ich könnte das nicht.
Ralph S. schrieb: > Das wäre jetzt so, als würde man mir sagen: Hey, schreibe absichtlich > wieder schier unwartbare Programme. Da fehlt Dir einfach ÜVS ;-) > Wie kann man nur so verbohrt sein, seine > "Lieblingssprache" auf so extrem wenige (und sorry, wirklich relativ > triviale) Anwendungen zu begrenzen? Mein Beispiel ist zwar trivial, aber offensichtlich immer noch zu kompliziert. Größere Asm-Programme aus meiner Feder hätten erst recht keine Chance auf Vergleich- als einzig möglicher Beweismöglichkeit. > Ich würde gerne mal einen Softwaresynthesizer von Herrn M. sehen, der > komplett in ASM gemacht ist !!! Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und rechenintensiv ist. Damit ziemlich ungeeignet für Asm. > Ich verschärfe jetzt nicht in dem ich verlange, dass er den Code den er > erstellt hat nun auf einer anderen Plattform zum Laufen bringt (denn ich > will den auf AVR funktionierenden Code nicht nach STM32 portieren, > glaube aber, dass ich wohl doch in der Lage wäre das auch auf einem > Nucleo hin zu bekommen). Ich brauch meine Anwendungen nicht portieren. Da langt ein AVR auf ewig. Vor allem wegen Asm ;-) > ( ich glaube ich kann jetzt schon ein höhnisches Gelächter von Herrn M. > hören und ich glaube ich kann auch schon die Gebetsmühlenartig > vorgetragenen unsinnigen "Argumente" und "Forderungen" hören ). Was Du so alles hörst. Für Beiträge wie den Deinigen sollte ich mir wirklich mal ein Eliza-Programm zulegen, welches die Rahmenbedingungen meiner Aussagen für alle Neuankömmlinge permanent wiederholt. > Immer dann, wenn gerechnet werden muß, immer dann wenn floating point > ins Spiel kommt, spätestens dann wird es mit ASM kritisch. Ja ja, das Rechnen wieder... Hatte ich schon gesagt, daß mich bislang Floating Point und ähnliche schlimme mathematische Dinge verschont haben? Daß mir mein Smart Home automatisch zu Diensten ist muß irgend einen anderen Hintergrund haben ;-)
Moby A. schrieb: > Da fehlt Dir einfach ÜVS ;-) Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen! Wie soll man da am anderen Ende der Welt noch mitkommen...
Carl D. schrieb: > Nö, ein gewisser Moby hat es genau so geschrieben. Na das zeig mir mal! Da bin ich aber jetzt gespannt! Ich glaub ja Du willst mir irgendeine Deiner Aussagen oder Interpretationen unterschieben ;-) > Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu > korrigieren. Ach so? Für viele windelweich faktenlose Beiträge hier langts aber? Dabei hab ich doch gehört, daß C so hochproduktiv sein soll... Ach stimmt ja: Ich bin ja der Einzige und die Gegenseite hat diese große Erfahrung. Oh, daraufhin muß ich wohl umdenken... Was glaubst Du eigentlich korrigieren zu müssen? Ein funktions-äquivalenter C-Entwurf ist verlangt. Du wärst freilich der Letzte von dem ich das erwarten könnte. Stimmts?
Gerhard O. schrieb: > Moby A. schrieb: > Da fehlt Dir einfach ÜVS ;-) > > Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen! Übung. Vorbereitung. System. > Wie soll man da am anderen Ende der Welt noch mitkommen... Da wird das Diskussionsthema auch nicht so relevant sein. Hier gehts um deutsche Gründlichkeit ;-) Wo bitte lauscht Du denn gerade?
Moby A. schrieb: > Gerhard O. schrieb: >> Moby A. schrieb: >> Da fehlt Dir einfach ÜVS ;-) >> >> Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen! > > Übung. Vorbereitung. System. > >> Wie soll man da am anderen Ende der Welt noch mitkommen... > > Da wird das Diskussionsthema auch nicht so relevant sein. Hier gehts um > deutsche Gründlichkeit ;-) > Wo bitte lauscht Du denn gerade? Hallo Moby, Danke für die Erklärung. Ich lausche ganz aus der Ferne im Land der Holzfäller und Maple Syrup. Edmonton, Alberta, Canada Gruß, Gerhard P.S. Wer behauptet, daß wir in Kanada nicht gründlich sind?
:
Bearbeitet durch User
Gerhard O. schrieb: > Edmonton, Alberta, Canada Interessant. Lohnt sich denn die Reise dorthin ? (frage ich mal als potentieller Tourist). Was interessiert Dich denn am Thema Asm vs. C ?
Moby A. schrieb: > Gerhard O. schrieb: >> Edmonton, Alberta, Canada > > Interessant. > Lohnt sich denn die Reise dorthin ? (frage ich mal als potentieller > Tourist). > > Was interessiert Dich denn am Thema Asm vs. C ? Ganz ohne Frage. Wenn Du die Natur liebst, vor den Bären keine Angst hast(;-))und Dir die Abwesenheit von vielen Menschenansammlungen nichts ausmacht, kannst Du bei uns viel erleben. Ich verbringe meine Ferien meistens in den Rockys an der Westküste mit Bergwandern und finde es immer sehr erholsam. An sich findet man auch in kanadischen Städten Sehenswerten, nur kann ich Edmonton zur Zeit nicht empfehlen weil bei uns zur Zeit zu viel gebaut wird. British Columbia gefällt mir sehr gut. Die Gegend um Vancouver ist recht toll. Man kann viel unternehmen. Die Berggegend dort ist sehr beeindruckend. Die Nachbarschaft zwischen Pazifischem Gewässer und den vollbewaldeten Küsten schafft viele photogenische Momente. Was interessiert mich am Thema? Ich liebe die embedded uC Technik und bin beruflich und Hobbymäßig erwas damit vorbelastet. ASM mag ich weniger und verwende es nur in kleinen homöopathischen Dosen und nur wenn unbedingt notwendig. Abgesehen davon befasse ich mich mehr mit PICs und nur ganz wenig mit AVRs. Bin also in Deinen Augen ein hoffnungsloser C Programmierer;-) Was soll ich zum Thread sagen? Ich finde es ist halt schon viel digitale Tinte verbraucht worden... Naja, wenn Du mich jetzt in die Ecke drängst, muß ich Eure Standhaftigkeit und Gelassenheit bewundern. Mir persönlich ist es innerhalb vernünftiger Grenzen eigentlich Wurscht wieviel Resourcen ein Programm vebraucht solange die Vorgaben einwandfrei erfüllt werden. Auf der Ebene des Mikroprozessors ist jedes Programm ganz gleich wie es erstellt worden ist, nur Maschinensprache und das arme Würstchen muß den Stuss den wir alle irgendwann schreiben, stur und sklavenhaft abarbeiten. Wenn Mikros nur sprechen könnten... In dem Sinne, noch eine gute Nacht, Gerhard
:
Bearbeitet durch User
Besten Dank Gerhard für den touristischen Einblick in Deine Gegend. Die kann es glaub ich mit meinem Bayern aufnehmen ;-) Gute Nacht aus D
Moby A. schrieb: > Besten Dank Gerhard für den touristischen Einblick in Deine Gegend. Die > kann es glaub ich mit meinem Bayern aufnehmen ;-) > > Gute Nacht aus D Du bist aus Bayern? Von wo ungefähr? Die Chiemseegegend kenne ich noch gut von früher her und auch Rosenheim mit dem großen K dort. Ich bin von über der Grenze her, die Stadt mit der alten Festung und seiner Heldenorgel die man auch gut über der Grenze in Bayern hört. Guten Abend aus C
:
Bearbeitet durch User
Jörg W. schrieb: >> Mal Schifahren zu gehen oder Eislaufen > > Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf > gefallen dabei. :o/ Da hat es wohl an Übung, Vorbereitung und System gefehlt...
:
Bearbeitet durch User
A. K. schrieb: (Eislaufen) > Da hat es wohl an Übung, Vorbereitung und System gefehlt... Ja, ganz sicher. :-)
Moby A. schrieb: >> Belege die "Bürokratie" entsprechend mit Codebeispielen. > > Dafür brauchts nichtmal Beispiele. Dafür langt schon ein Blick ins dicke > C-Buch ;-) Hmm, die Assembler Handbücher sind meist dicker als der C-Standard, und man braucht für jede Prozessorfamilie ein neues... D.h. also Assembler ist viel bürokratischer als C - stimmt aus meiner Erfahrung.
Moby A. schrieb: > Größere Asm-Programme aus meiner Feder hätten erst recht > keine Chance auf Vergleich- als einzig möglicher Beweismöglichkeit. Oh man, hätten, könnten, würden, ... alles klar ;-)
Moby A. schrieb: > Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig > kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und > rechenintensiv ist. Damit ziemlich ungeeignet für Asm. (Ironie an) Wenn ASM doch ach so überlegen ist, dann kann es doch für gar nichts ungeeignet sein (Ironie wieder aus)
Moby A. schrieb: > Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig > kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und > rechenintensiv ist. Damit ziemlich ungeeignet für Asm. Okay, Moby sagt uns also ganz offiziell: Jede Software die man kaufen kann (unabhängig vom Preis ?) ist einem selbst programmieren mit ASM vorzuziehen. Muß daran liegen das kein Preis der Welt es rechtfertigt sich das in ASM anzutun. Man kann alles in ASM schreiben solange es nicht komplex (Definition ?), datenintensiv (Definition ?) und rechenintensiv (Definition ?) ist. Für jeden anderen Fall muß man dann eine zweite Programmiersprache lernen und alles wegwerfen was man bisher in ASM dazu geschrieben hat. Ja, lieber Moby, das ist so ungefähr die Einschätzung der großen Mehrheit hier. Dann liegen wir doch garnicht so weit auseinander. Was wir nur einfach nicht verstehen können ist warum man die Beherrschung eines Werkzeuges bis ins Detail perfektionieren soll das versagt sobald die Aufgabe größer wird, wenn man statt dessen die gleiche Arbeit in ein Werkzeg stecken kann das auch große Aufgaben stemmt. In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen läßt. Laß uns diesen Müll doch mal entsorgen und ein tiny Sensorboard mit einem vernünftigen Feldbuss definieren und einer Meßwertaufbereitung die diesen Namen auch verdient. Einer wirklich tyischen 8bit MSR Aufgabe eben. Das setzt eine jede Fraktion in Ihrer bevorzugten Programmierspache um und wir schauen mal wie dann das Ergebniss aussieht. Jaja, ich weiß, kein Argument kann die Vorteile von ASM tangieren. Deswegen wird auf gefährliche Argumente ja von Dir auch prinzipiell nicht geantwortet. Leider ist der einzige Vorteil von ASM nur noch das Du nichts anderes kannst. Das ist aber etwas was nur Du ändern kannst.
Wie sagte schon Karl Valentin: "Es ist schon alles gesagt, nur noch nicht von allen." Leute, durchhalten! Zusammen wir schaffen das! ;-) Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Gerhard O. schrieb: > Wenn Mikros nur sprechen könnten... Gottlob (darf ich als Atheist sagen!) quasseln die eben nicht soviel Unsinn wie ihre Programmierer. Bin froh, daß wenigstens die µC die Klappe halten.
Moby A. schrieb: >> - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden >> durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden) >> - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits >> - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits >> - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits >> - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits >> - Bit 20: DINP1-LOW >> - Bit 21: DINP2-LOW > > Ok. > >> - Bits 22-23: Checksumme über das Datentelegram >> - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in >> einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird > > Bit22= Bit 0 der Summe, Bit23= Bit 1 der Summe Moby A. schrieb: > Markus M. schrieb: >> Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle >> Schnittstelle. >> >> PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. > > Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige > Bruchwerk aber noch nirgendwo. Mich würde brennend interessieren, wie Du diese 2 Punkte von Dir verifizierte Anforderung in dem Kryptischen und Komplexen Assembler umsetzen würdest. Ich habe bereits dies in C umgesetzt, also darf ich doch auch von Dir erwarten dass Du mit einer konkreten Lösung diese Teilaufgabe auch als Gegenpart in Assembler zur Schau darstellst. Schließlich bist du ja einverstanden gewesen mit den Spezifikationen. Hier mein Code: Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Wenn Du mal hier den Teil erstellst, dann können wir auch gerne den Rest der Anforderung auch umsetzen (in C / ASM). Da Du ein Meister von Ausreden bist kann ich wohl nichts erwarten, schade :-(
Lothar M. schrieb: > Leute, durchhalten! Zusammen wir schaffen das! ;-) > Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Eben deswegen hängen wir uns doch richtig rein. Lothar, das machen wir nur für Dich. Ich gönne Moby außerdem nicht das letzte Wort.
Michael K. schrieb: > Ich gönne Moby außerdem nicht das letzte Wort. Geht es hier noch um irgendetwas anderes? mfg.
Lothar M. schrieb: > Leute, durchhalten! Klar, Lothar, sonst müssten wir uns doch eine andere Pausengymnastik suchen. :)
Ach Jungs, ihr könnt machen was ihr wollt. Dem Moby interessiert das alles nicht. Zusammenfassung: Moby hat ein ASM Programm auf einem Tiny13. Die Anforderungen stehen mittlerweile fest. Nur sein Programm zählt. Nix mit Ausgabe an serieller Schnittstelle, Fedlbus, anderer MC usw. Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus der ISR. Nicht mehr und nicht weniger. Ihr könnt schreiben was ihr wollt. Er wird sich immer auf sein ASM Programm beziehen.
>Gewonnen habt ihr ...
ja, wenn jemand ein C-Programm schreiben würde, dass ... usw. usw.
erfüllt, hätte man Gewonnen
wie weiter oben schon festgestellt wurde,
heißt das im Umkehrschluss nicht dass wenn keiner mitmacht, Moby
gewinnt..
Werner P. schrieb: > Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein > SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus > der ISR. Ich lache mich immer schlapp wenn ich "SRAM" lese. Beim STM32 habe ich 64KB CCM RAM und nach einiges an BACKUP-RAM. Also brauche ich da den SRAM niemals belegen GRINS
Lothar M. schrieb: > Leute, durchhalten! Zusammen wir schaffen das! ;-) > Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Ralf G. schrieb: > Wobei...: Der Ringrichter wettet auf den Verlauf des Kampfes?! ;-/
Robert L. schrieb: > Moby > gewinnt.. ehrlich gesagt ist mir das Sch...egal ob Moby gewinnt oder nicht. Der Typ hat sowas von einen beschränkten Horizont. Labert laufend von ÜVS und wie toll ASM ist. Kreischt wie ein kleines Kind: "Du darfst kein SRAM verwenden!". usw. usw. Kindergarten halt. Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer sein Programm locker in 30 Minuten programmiert. Klar wird dann SRAM verwendet und eventuell mehr Flash. ABER WEM INTERESSIERT DAS? EDIT: Aber irgendwie lustig ist der Thread schon ;-)
Werner P. schrieb: > Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer > sein Programm locker in 30 Minuten programmiert. Klar wird dann SRAM > verwendet und eventuell mehr Flash. Meine Rede. Ich behaupte sogar, dass 10-15min realistischer sind. Den größten Aufwand drüfte das Heraussuchen der ADC- und Timer-Register aus dem Datenblatt sein und das aufpriemeln der Bits. Allerdings wird im ersten Schuss zwangsläufig RAM benutzt, ja mei, ist halt so, und eventuell ein paar Bytes mehr Flash. Könnte man alles trotzdem irgendwie hinpfuschen. Der gcc gibt einem ja viele Möglichkeiten: - Den StartUp-Code könnte man weglassen oder anpassen, RAM muss ja keiner initialisiert werden, denn SP kann man zur Not selbst initialisieren. - die main() deklariert man als "os_main" - die ISR deklariert man "naked" - dann gibts noch den "register"-qualifier - und wenn man mal die Doku durcharbeitet findet man bestimmt noch mehr Ansatzpunkte um den Compiler in die gewünschte Richtung zu zwingen Aber das hat dann halt wirklich nur noch sportlichen Wert, Aussagekraft über Vor- oder Nachteile hätte so ein Programm dann nicht mehr. Man hätte dann wirklich nur gezeigt dass die Erfinder von C und die Entwickler des gcc genug Flexibilität vorgesehen haben um jede noch so abstruse Forderung erfüllen zu können. Wenn ich aber die geforderte Funktion in 10min umsetzen kann, jeder den Code sofort versteht und dafür nur 5% mehr Flash/RAM verbraucht werden als bei der hochoptimierten, alle Kniffe nutzenden , nicht mehr erweiterbaren ASM-Lösung wär das für mich schon ein Punkt für die C-Lösung. Und ich vermute mal, für 99% der Anwesenden hier auch.
:
Bearbeitet durch User
>ehrlich gesagt ist mir das Sch...egal ob Moby gewinnt oder nicht.
also mir nicht
ich fände das Super wenn er Gewinnen würde und allen hier aufzeigen
würde wie es Richtig geht..
wenn er sein git/svn repository von seiner SmartHome Zentrale (read
only) zur Verfügung stellen würde..
wo man sieht wie er Schritt für Schritt, mit System um Eleganz und Top
dokumentiert das Programm erweitert hat..
Wie einfach und übersichtlich dort alles ist, wie jedes Byte Flash 3 mal
umgedreht wurde und jedes byte RAM soweit möglich eingespart wurde..
Moby A. schrieb: >> Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu >> korrigieren. > > Ach so? Für viele windelweich faktenlose Beiträge hier langts aber? Faktenlose Beiträge? Ich denke wir haben dir aus allen denkbaren Perspektiven erklärt und belegt, was Sache ist. Du überliest es aber geflissentlich, oder erfindest neue Argumente, warum es nicht gelten soll. Neue Fakten braucht es da nicht mehr, es geht einzig und alleine noch darum, dir zu zeigen, wie absurd deine Haltung ist. Und ja, den Klassendepp mit seinen Ideen noch ein wenig aufziehen ist halt unterhaltsam :-)
le x. schrieb: > Und ich vermute mal, für 99% der Anwesenden hier auch. genau so ist es. Nur einer rafft das halt nicht. Eigentlich war ja der Thread: Assembler wieder auf dem Weg nach vorn von mir aus ist Assembler auf dem Weg nach vorn. Kann mir nur nicht vorstellen dass im professionellen Bereich von C hin zu ASM gegangen wird. Und selbst im Hobbybereich kann ich es mir nur schwer vorstellen. Aber das ist jetzt meine Meinung. Einen AVR und fast jeden anderen MC kann ich in C und oft auch in anderen Hochsprachen programmieren. Ist doch toll. Jeder sucht sich seine Sprache aus. Früher hat mich C auch abgeschreckt. Aber mittlerweile finde ich C einfach nur gut. Aber jedem das womit er glücklich wird.
Moby A. schrieb: > Für viele windelweich faktenlose Beiträge hier langts aber? > Dabei hab ich doch gehört, daß C so hochproduktiv sein soll... Deine Behauptung vom fetten C ist und bleibt deine private, vorgefertigte Meinung, möge ÜVS mit dir sein. Wie viele C Umsetzungen brauchst du, um sie zu überdenken? Ich hänge noch mal mein PIC12F675 XC8 FREE Projektchen an. Ich habe es an deine allerneueste Anforderungsliste angepasst mit dem Ergebnis: das Compilat hat 198 Maschinenbefehle - auf einer archaischen MCU, die: nach allgemeiner Lehrmeinung für C ungeeignet ist, nur ein Arbeitsregister, 35 Instruktionen, zerkluftete Achitektur und noch nichtmal freilaufende ADC hat. Also müsste es mit deiner ÜVS ein klacks sein, das Projekt auf einer modernen AVR MCU in <100 Befehlen zu implementieren. Sonst schicke ich dein Projekt an die Mythbuster ;-)
>Ich hänge noch mal mein ... Projektchen an >main.c (3,39 KB) Mehr 3390Bytea >>>>> 200Bytes => Verloren
Matthias L. schrieb: >>> 200Bytes => Verloren Je nee ist klar. Gegen einen so meilenhoch überlegenen Gegner zu verlieren ist doch keine Schande. Jetzt gibt doch bitte endlich dem Moby seinen verdienten ÜVS-Orden!
Witkatz :. schrieb: > Jetzt gibt doch bitte endlich dem Moby seinen verdienten > ÜVS-Orden! Nicht bevor Lothar seine Wette gewonnen hat. Bis dahin zählt jeder Beitrag, auch Mobys. Geht ja zum Glück schon lange nicht mehr um Inhalte. Zur Not Verteile ich etwas Katzenfutter auf der Tastatur um die letzten Beiträge voll zu bekommen. Inhaltsärmer als ÜVS kann das auch nicht mehr sein.
Michael K. schrieb: > Geht ja zum Glück schon lange nicht mehr um Inhalte. Ja siicher! Es geht immer nur um "Assembler wieder auf dem Weg nach vorn" Ausserdem ist das Wachstum dieses inhaltslosen Threads ein unwiderlegbarer Beweis für die Expansion des Universum. Also in dem Sinne. Möge ÜVS mit Dir sein!
:
Bearbeitet durch User
Moby A. schrieb: > Clemens M. schrieb: >> Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu >> haben ist Moby irgendwie wirklich verzweifelt.... > > Du solltest besser am RAM-Bedarf eines C-Compilers verzweifeln. Scheint > ja ein fetter Pferdefuß des fetten C zu sein. Beziehst du dich bei deinen fetten Behauptungen auf die fette SPRACHE C im fetten Allgemeinen oder auf eine bestimmte fette C-Implementation vulgo: fetter C-Compiler? Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code, d.h. dass es fett UNMÖGLICH ist, mit einem hypotetischen fetten C-Compiler besser als mit fettem Assembler zu sein? Falls du dich auf eine fette KONKRETE IMPLEMENTATION beziehst wie fett-gcc, so liefert ein damit fett compiliertes fettes Programm nur eine fette UNTERGRENZE für die fette Effizient von C, aber KEINE OBERGRENZE derselben — und das auch nur für den fetten Fall eines bestimmten fetten C-Programms, das mit einer bestimmten fetten Version eines bestimmten fetten Compilers mit bestimmten fetten Optionen übersetzt wurde. Gehts dir also um fettes fette Compiler-Bashing? Oder um fettes Bashing einer fetten Sprache und dem fetten Nachweis, dass die fette Effizienz NIEMALS über einer bestimmten fetten Grenze liegen kann? Musst fett entschuldigen, wenn ich fett ein paar fetts vergessen hab...
Johann L. schrieb: > Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE > Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code, > d.h. dass es fett UNMÖGLICH ist, mit einem hypotetischen fetten > C-Compiler besser als mit fettem Assembler zu sein? Um die Diskussion zu gewinnen, müsste Moby genau das tun. Er müsste nachweisen, dass compiliertes C nicht effizienter sein kann als direkt in Assembler geschriebener Code. Oder dass es zumindest für eine gewisse Klasse an Problemen keine solchen gibt.
Ich 'jammer' noch mal. Obwohl es wahrscheinlich nur Moby schafft in meinem post unfassbar weit oben auf gejammer zu schließen. Du bist ja extrem stolz auf dein Programm. Geschenkt. Ist ein schönes Programm - per inline asm auch in c portierbar. Glückwünsch. Angenommen es würde wirklich jemand den von dir gewünschten Wettkampf, genau DIESES Ding in c "besser" zu programmieren, was genau sollte da raus kommen? Du hast EINEN Pfeil im Köcher. Dein sagenumwobenes Programm. Um damit auf eine generelle Aussage wie "....die allgemeinen Vorteile von asm...." zu kommen, musst du wenigstens noch einen zweiten Treffer landen. Karl Heinz hat die ein Angebot unterbreitet, was dir augenscheinlich Angst gemacht hat. Weil das fast jeder versteht und dein Programm so unbedeutend für die Sache ist, kannst du dir deine Tastatur kaputt hacken in dem Thread. Wenn es dir ein gutes Gefühl gibt und irgendwie terapeutischen Nutzen hat sei es dir gegönnt. Aber ich -hoffe- du bist dir selber im klaren, dass du nicht auf der Gewinnerstrasse bist. Weder mit deinen Resultaten, noch mit deiner Argumentation (wenn ich deine posts mal so nennen mag) Folgendes zu sagen würde bestimmt jeder akzeptieren: -Einen Mini Code bis maximal 1 kB kann man händisch in asm noch besser optimieren als in c. Wenn man viel Erfahrung hat wohlgemerkt. Wenn viel Interrupt Last dazu kommt vielleicht noch besser. Das Resultat in c ist dafür recht problemlos portierbar. -Es macht zugegeben aber auch Spaß als Hobby solange Bits zu schubsen bis man selber zufrieden ist und mit Papier und Bleistift Computer zu spielen. Es macht aber auch Spaß als Hobby eine abstraktere Codierung zu wählen und sich stattdessen um Algorithmen und Mathematik zu kümmern. -Von einem minimalistischen Code auf eine allgemeine Aussage zu kommen asm sei c überlegen ist Schwachsinn. -Ich kann mit meiner asm Codebasis auch größere Projekte zusammendübeln. Ich muss aber auch eingestehen, dass eine Maschine dabei den Überblick besser waren kann und eine Maschine dabei die Planung und Vorbereitung variabel halten kann...was schnell zum Vorteil gereicht. Ich glaube aber auch, dass ich nach Monaten oder Jahren der Benutzung von c auch DORT eine gewisse Codebasis anhäufe auf die ich dann zurückgreifen kann....... Kannste dir doch bestimmt irgendwie vortellen oder? -Die verschwenderische Programmierung auf dem PC, die z.B. Adobe hinbekommt ist lästig nervig und steht auf einem ganz anderen Blatt und hat gar nix mit dem diskutierten Problem uc zu tun. Die ist bescheuert und nervt wohl fast jeden. Auch wenn die Programmierer in den Branchen bestimmt erklären können dass das modern und zudem egal ist. Das Visual Studio was du zum asm Programmieren benutzt ist z.B. auch so ein Software gau. -(...) Ich hoffe du nimmst dich in Wahrheit nicht so ernst wie du tust und glaubst dein krudes Geschreibe wirklich. Dann hast du irgendwie ein Logik Problem. Oder sonst irgendein Problem. Was spricht dagegen deine Windmühlen mal rational zu betrachten wie oben skizziert?
Habe noch mal quer gelesen und möchte dir zugestehen, dass du tatsächlich unter irgendwas pathologischem leidest. Selektive Wahrnehmung wäre so was. Lies noch mal nach: viele warten sicher noch auf Antworten auf gechriebene Punkte.
Johann L. schrieb: > Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE > Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code Was interessiert mich hier jede denkbare C-Umsetzung? Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Vom Ressourcen-Bedarf her und mit der fetten C-Bürokratie, die ja wohl immer zur Anwendung kommen muß erst recht. Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage wiederspricht und ich mich reuevoll korrigieren muß. Drehe nur ein bischen an den tausend kleinen optimierenden C-Stellschrauben, dann sollte daß doch fett klappen, oder? Fett eingeschüchtert in der Ecke kauernd hast Du mich schon ;-) > Musst fett entschuldigen, wenn ich fett ein paar fetts vergessen hab Kein Problem. C hat sicher noch andere fette Pferdefüße, die mir gerade nicht in den Sinn kommen oder noch gar nicht bekannt sind ;-) Mit fetten Grüßen!
Clemens M. schrieb: > Habe noch mal quer gelesen und möchte dir zugestehen, dass du > tatsächlich unter irgendwas pathologischem leidest. Kenn ich schon. Läuft wieder der Beleidigungsschiene. Da bin ich aber inzwischen dermaßen von was abgehärtet... ;-) > Selektive Wahrnehmung wäre so was. Wenn Du das pathologisch nennst ist es ein Massenphänomen. Dich natürlich ausgeschlossen ;-) > Lies noch mal nach: viele warten > sicher noch auf Antworten auf gechriebene Punkte. Natürlich Clemens. In der Nacht hab ich wieder Zeit zur netten Unterhaltung. Also bis bald!
Moby A. schrieb: > Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Na jetzt spinnt er endgültig.
Moby A. schrieb: > Johann L. schrieb: >> Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE >> Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code > > Was interessiert mich hier jede denkbare C-Umsetzung? > Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE C-Umsetzung. > Vom Ressourcen-Bedarf her und mit der fetten C-Bürokratie, > die ja wohl immer zur Anwendung kommen muß erst recht. Nein, C als Sprache kennt weder Flash noch Register noch Stack oder Schalter. > Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage > wiederspricht und ich mich reuevoll korrigieren muß. Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine C-Implementation, und die darf ich wählen wie ich will? Oder geht's dir nur um Compiler-Bashing? D.h. du hast mal — ohen C zu können — irgend nen Text von einen C-Compiler übersetzt bekommen, und dann nen Blutsturz bekommen weil der 2 Bytes mehr verbraucht hat? > Drehe nur ein bischen an den tausend kleinen optimierenden > C-Stellschrauben, C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler. Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln?
Nee eine Beleidigungsschiene ist das nicht. Soll es jedenfalls nicht.
Da du aber ganz offensichtlich fast 2000 Posts gar nicht wirklich
Argumente oder Programm(e!) austauschen willst dachte ich, dass du etwas
Galgenhumor bei deinen Kollegen in diesem Thread erwartest.
Und, ja, du hast eine mir fast unangenehme Ader, taub und blind zu sein
wenns dem Vorteil gereicht.
Du bist aber schon technisch interessiert? Also nicht dass du irgendwie
deine Bachelor Arbeit in Psychologie schreibst während wir hier
Serverplatz verbrauchen.
>Dich natürlich ausgeschlossen ;-)
Erklär mir doch mal wo ich dir Unrecht tue oder einfach Aussagen
ignoriere. Was sagst du zu meinen Konsens-Stichpunkten?
Moby A. schrieb: > Was interessiert mich hier jede denkbare C-Umsetzung? > Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Also, hopp, beweis es! Komm! Beweis es! Beweis es oder höre auf mit solche Behauptungen!
Ach Leute, hört halt auf diesen asm Troll mit unendlich Futter zu versorgen. Seit 2000 Seiten hat unser Moby - gerade mal ein Projektchen mit gut 20 Zeilen gezeigt. Der Rest ist Angeberei. - offensichtlich keine Ahnung von C und einem C compiler. - rudimentäre bis wenig Kenntnisse in Asm (Stichwort EOR ;-) ) - alle chancen was zu lernen verpasst - alle Angebote zu einem fairen Vergleich aus Angst zu verlieren abgeblockt - sich mit bescheuerten Argumenten lächerlich gemacht (Stichwort ÜVS) - keine Ahnung wie lächerlich er sich bisher gemacht hat (das ist wohl das komischste am Thread) - sich hundert mal selber widersprochen - immer wieder jemand gefunden der ihn offensichtlich ernst nimmt (warum auch immer) - die mit Abstand meisten downvotes in diesem Forum kassiert ;-)
Gu. F. schrieb: > Seit 2000 Seiten Nein, noch nicht ganz.... ;-) > Seit 2000 Seiten hat unser Moby > ... grausig lange Aufzählung ... Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist keinen müden Cent billiger. Und der braucht auch nicht weniger Strom. Und er ist auch nicht leichter. Das Einzige, was passiert, ist dass die hocheffiziente und RAM-sparende Appliktation ein halbes Jahr zu spät an den Markt kommt und sie dann keiner mehr will. > - immer wieder jemand gefunden der ihn offensichtlich ernst nimmt > (warum auch immer) Ist ja klar: keiner kann die 1886 Posts alle lesen und so erkennen, dass Alles, schlicht Alles schon einmal gesagt wurde...
Moby A. schrieb: > Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage > wiederspricht. Hab ich doch längst, s.o. Mein Fazit: Mit ÜVS bleibt C bei kleinen 8bit Aufgaben genauso schlank wie ASM! So! Das schreibst du jetzt 100 mal reuevoll ab - und zwar mit printf!
:
Bearbeitet durch User
Wenn mit ÜVS sowas raus kommt : > Eine Checksumme die so schwach ist das ich würfeln kann ob die Werte > wirklich stimmen. > Völlig ineinander verwurstelte Daten die ich am Zielsystem erst wieder > auseinandernehmen muß um was damit machen zu können. > Eine synchrone unidirektionale Punkt zu Punkt Verbindung bei der im > Zeitlupentempo Daten übermittelt werde statt ein vernünftiger Feldbuss > mit Master / Slave Protokoll und starker CRC. > Den Teil wo die Entprellung der digitalen IOs stattfindet oder die > Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden > können. dann möchte ich bitte sofort gegen ÜVS geimpft werden. Scheint den kognitiven Fähigkeiten ziemlich übel mitzuspielen. Lothar M. schrieb: > Ist ja klar: keiner kann die 1886 Posts alle lesen und so erkennen, dass > Alles, schlicht Alles schon einmal gesagt wurde... ... nur noch nicht von jedem. Ja, auch das wurde schon gesagt :-)
Lothar M. schrieb: > Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist > keinen müden Cent billiger. Und der braucht auch nicht weniger Strom. > Und er ist auch nicht leichter. Vielleicht liegt es Moby ja da dran: In einem bekannten ASM seine Frickelprogrämmchen stur nach ÜVS schreiben, händisch durchorgeln, "optimieren", eindampfen etc. Nach dieser Optmierung wird dann Atmel angeschrieben und ein Tiny 9,85 bestellt. Die Codegrösse ist dann ja bekannt. Bei echter Stückzahl gehen die bei Atmel bestimmt drauf ein ;)
>Bei echter Stückzahl gehen die bei Atmel bestimmt drauf ein ;)
Ja. Sie verkaufen im einen Tiny13 mit anderer ID, wo im Atmel-Studio
jeder Zugriff auf auf FLASH-Zellen über Adresse 9,85k geblockt wird mit
er Info:
"Zugriff nicht möglich, da gespart mit ÜVS"
Matthias L. schrieb: > "Zugriff nicht möglich, da gespart mit ÜVS" Oder: "Sonderbestellungen sind nicht C- kompatibel"
Oder mit reduziertem ASM Befehlssatz die mittels ÜVS ermittelt wurden.
Markus M. schrieb: > Oder mit reduziertem ASM Befehlssatz die mittels ÜVS ermittelt wurden. Gerade der Verzicht auf EOR könnte einige Gatter in der ALU einsparen.
:
Bearbeitet durch User
Carl D. schrieb: > Gerade der Verzicht auf EOR könnte einige Gatter in der ALU einsparen. Aber nicht viele. Weil identisch mit Addition ohne Übertrag. Beim Multiplier lohnt es eher, aber den hat sein geliebter 13er ohnehin nicht. Oder den halben Registersatz indem etwas mehr billiges RAM genutzt und teure Register einspart werden.
:
Bearbeitet durch User
Matthias L. schrieb: > im Atmel-Studio > jeder Zugriff auf auf FLASH-Zellen über Adresse 9,85k geblockt wird Kann man das nicht mit einem ÜVS Fuse regeln? Beim Abschalten des ÜVS Fuse müssen aber unbedingt Schockbilder vor der fetten Bürokratie warnen.
Witkatz :. schrieb: > Kann man das nicht mit einem ÜVS Fuse regeln? Schlecht. Beim Umlaut geht sofort die HCF Schaltung hoch.
A. K. schrieb: > Aber nicht viele. Weil identisch mit Addition ohne Übertrag. Die braucht man ja auch nicht für typische 8-Bit-MSR-Anwendungen.
Warum Übung, Vorbereitung und System Assembler so stark machen können und ihn viele C-Programme vom Ressourcenbedarf her schlagen lassen wird wohl manchem Comedian im Thread über mir auf ewig verschlossen bleiben. Da wird lieber weiter mit C auf den Controller eingeprügelt bis wieder mal dessen Schuhgröße oder gar gleich die ganze Architektur gewechselt werden muß. Das ist natürlich insofern komfortabel als C angeblich so schön portabel ist... um sich dann mit kleinen Hardwareänderungen und dem Neulernen einer Architektur, dem Anpassen der Entwicklungsumgebung und den Tausend Optimieroptionen die Nächte um die Ohren zu schlagen ;-) Gerhard O. schrieb: > Du bist aus Bayern? Von wo ungefähr? Von dort wo der Inn wieder Deine alte Heimat berührt ;-)
Moby A. schrieb: > Da wird lieber weiter mit C auf den Controller eingeprügelt bis wieder > mal dessen Schuhgröße oder gar gleich die ganze Architektur gewechselt > werden muß. Das ist natürlich insofern komfortabel als C angeblich so > schön portabel ist... um sich dann mit kleinen Hardwareänderungen und > dem Neulernen einer Architektur, dem Anpassen der Entwicklungsumgebung > und den Tausend Optimieroptionen die Nächte um die Ohren zu schlagen ;-) Wo hast du das denn her? Aus der Bildzeitung? Das zeigt nur, daß Du allen Unsinn nachplapperst und keine Ahnung hast.... Im übrigen wunderts mich, daß jemand, der von Assembler so überzeugt ist, eine IDE zum Entwickeln benutzt...
:
Bearbeitet durch User
Bernhard M. schrieb: > Hmm, die Assembler Handbücher sind meist dicker als der C-Standard, und > man braucht für jede Prozessorfamilie ein neues... Die Auflistung aller Instruktionen ist schnell erledigt, deren Verständnis auch. Kein Vergleich mit C. Wenn man dann bei 8-Bit MSR Apps bei seiner Architektur bleiben kann dann auch wegen Asm. Michael K. schrieb: > Jede Software die man kaufen kann (unabhängig vom Preis ?) ist einem > selbst programmieren mit ASM vorzuziehen. Das Selbstprogrammieren mit Asm macht zunächst mal auf kleinen 8-Bit Controllern Sinn! Dort gibts auch wenig zu kaufen. > Was wir nur einfach nicht verstehen können ist warum man die > Beherrschung eines Werkzeuges bis ins Detail perfektionieren soll das > versagt sobald die Aufgabe größer wird Mit ÜVS versagt Asm bei 8-Bit MSR Aufgaben so schnell nicht. > In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten > möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen > läßt. So edel optimiert muß Software auf einem kleinen Controller aber ausschauen! Sparsamer Verbrauch, Kapselung der Funktionalität, einfache Erweiterbarkeit. > Laß uns diesen Müll doch mal entsorgen Müll ist, was Du statt dessen für die Aufgabe, die mein kleines Sensorboard erfüllen soll vorschlägst: > tiny Sensorboard > mit einem vernünftigen Feldbuss definieren und einer Meßwertaufbereitung > die diesen Namen auch verdient. Völlig unnützer Aufwand. So überdimensioniert bürokratisch wie bücherfüllendes C gegenüber Asm ;-)
Markus M. schrieb: > Mich würde brennend interessieren > Wenn Du mal hier den Teil erstellst Ist ja nett. Ich habe für meinen Teil und für diesen Thread genug erstellt. Weitere Mühen lohnen eher nicht, wenn ich das Ergebnis des Threads so betrachte. Nun will ich für meine Vorlage kürzeren C-Code sehen den ich kompilieren und testen kann. > Da Du ein Meister von Ausreden bist Ja ja, die lieben Ausreden. Ich komm mir wie ein Kämpfer gegen einen übermächtigen C- Drachen vor, dessen Köpfe voller Ausreden ständig nachwachsen. Mein scharfes Laserschwert in Form fertigen, für jeden nachvollziehbaren Codes kann ich gar nicht so schnell schwingen ;-)
:
Bearbeitet durch User
Werner P. schrieb: > Ach Jungs, > > ihr könnt machen was ihr wollt. Dem Moby interessiert das alles nicht. > > Zusammenfassung: > > Moby hat ein ASM Programm auf einem Tiny13. > Die Anforderungen stehen mittlerweile fest. > > Nur sein Programm zählt. Nix mit Ausgabe an serieller Schnittstelle, > Fedlbus, anderer MC usw. > > Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein > SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus > der ISR. > > Nicht mehr und nicht weniger. Ihr könnt schreiben was ihr wollt. Er wird > sich immer auf sein ASM Programm beziehen. Hey, da hat einer die Situation ja seeehr klar erkannt! Genau. Ich beziehe mich auf harte Fakten! Die gilt es jetzt zu schlagen und nicht darum, irgendwelchen Fantasien nachzuhängen ;-)
Moby A. schrieb: > Die Auflistung aller Instruktionen ist schnell erledigt, deren > Verständnis auch. Kein Vergleich mit C. Die Auflistung der C Schlüsselworte und Operatoren ist dreimal so schnell erledigt. Moby A. schrieb: > Ich beziehe mich auf harte Fakten! Auch Fakten, die dir nicht in den Kram passen? Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Moby A. schrieb: > Ich komm mir wie ein Kämpfer gegen einen übermächtigen C- Drachen vor, > dessen Köpfe voller Ausreden ständig nachwachsen. Mein scharfes > Laserschwert... Moby A. schrieb: > Die gilt es jetzt zu schlagen > und nicht darum, irgendwelchen Fantasien nachzuhängen Also was denn jetzt. Erst fantasierst du dir was über C zusammen und dann willst du doch nicht Fantasien nachhängen...
:
Bearbeitet durch User
So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR kann da zu klein sein, selbst wenn ich C-Anfänger bin. Es gibt also schlichtweg keinen Grund die Architektur zu wechseln, egal ob Assembler oder C (bei 8-bit MSR mit SÜV). Damit fällt doch auch dieser pathologische Sparzwang weg. Ich programmiere schon mein ganzes Leben lang Assember (ESER-Rechner, Z80, 8086, 68000) und auch C (+ diverse andere schöne Hochsprachen). Bei Robotron haben wir in den 80ern mal versucht einen "16 auf 8 bit" Crossassembler zu entwickeln, weil die Ressourcen beschränkt waren. Aber so ein Gewese wie Moby hier veranstaltet... kopfschüttel
:
Bearbeitet durch User
Markus M. schrieb: > Ich lache mich immer schlapp wenn ich "SRAM" lese. > > Beim STM32 habe ich 64KB CCM RAM und nach einiges an BACKUP-RAM. Also > brauche ich da den SRAM niemals belegen GRINS Ich muß auch grinsen: Wenn ich für (alle) Apps den einfachen, unkomplizierten AVR nehmen kann! Werner P. schrieb: > Der Typ hat sowas von einen beschränkten Horizont. Beschränkt sind eher die Möglichkeiten, mit C effizientem Asm-Code bei 8-Bit MSR Konkurrenz zu machen ;-) > "Du darfst kein > SRAM verwenden!". usw. usw. Zu dumm daß es zu den zu vergleichenden Ressourcen gehört! Ich versteh Deinen Frust. > Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer > sein Programm locker in 30 Minuten programmiert. Na dann mal los. Viel Funktionalität ist ja nicht (zu vergleichen). > ABER WEM INTERESSIERT DAS? Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher abgeneigt ;-) > EDIT: Aber irgendwie lustig ist der Thread schon ;-) Na das ist doch auch schon was. Ein bischen Schmiermittel braucht jedes ernste Leben.
:
Bearbeitet durch User
Moby A. schrieb: > Wenn man dann bei 8-Bit MSR Apps bei seiner Architektur bleiben kann > dann auch wegen Asm. Da hast Du wohl "kann" und "muss" verwechselt ;-) Moby A. schrieb: > Kapselung der Funktionalität bedeutet bei Dir: für jeden Hühnerschiss einen anderen mc. Das definiert der Rest der Welt irgendwie anders!
Moby A. schrieb: > Markus M. schrieb: >> Mich würde brennend interessieren >> Wenn Du mal hier den Teil erstellst > > Ist ja nett. Ich habe für meinen Teil und für diesen Thread genug > erstellt. Weitere Mühen lohnen eher nicht, wenn ich das Ergebnis des > Threads so betrachte. > Nun will ich für meine Vorlage kürzeren C-Code sehen den ich kompilieren > und testen kann. > Mein Code lässt sich kompilieren, also nutze den.
:
Bearbeitet durch User
Moby A. schrieb: > Ich muß auch grinsen: Wenn ich für (alle) Apps den einfachen, > unkomplizierten AVR nehmen kann! (Alle) Apps, die es in Deinem Weltbild gibt, meintest Du wohl? So wie Du hier über C und neue Architekturen redest, so haben die Leute im Mittelalter übers Lesen und Schreiben geredet ... völlig überflüssiger neumodischer Kram ;-)
Jay W. schrieb: > So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer > noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR > kann da zu klein sein Hast Du eine Ahnung! > Damit fällt doch auch dieser > pathologische Sparzwang weg. Hier gehts nicht um Sparzwang oder Verschwendungssucht. > Bei > Robotron haben wir in den 80ern mal versucht einen "16 auf 8 bit" > Crossassembler zu entwickeln, weil die Ressourcen beschränkt waren. Interessant. Ich hab mit dem KC87 angefangen ;-) > Aber > so ein Gewese wie Moby hier veranstaltet... Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was mich persönlich sehr interessiert. Danke für Deinen Beitrag, der dieses Thema aber leider verfehlt ;-(
Moby A. schrieb: > Gerhard O. schrieb: >> Du bist aus Bayern? Von wo ungefähr? > > Von dort wo der Inn wieder Deine alte Heimat berührt ;-) Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein Österreicher... Gerhard
Moby A. schrieb: > Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, Das "C vs." lass bitte weg. Solange du in Hochsprachen keinen Fuß auf den Boden kriegst, sind es nichts als deine Fantasiewelten. Es geht immer noch um "Assembler wieder auf dem Weg nach vorn" und nichts anderes.
Moby A. schrieb: > Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was > mich persönlich sehr interessiert. Das stimmt nicht. Du versucht aus einem eingeschränkten Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist, mit Verlaub, blödsinnig.
Moby A. schrieb: > Beschränkt sind eher die Möglichkeiten, mit C.. Für dich auf jeden Fall. Es ist eine andere Welt.
Stefan K. schrieb: > völlig > überflüssiger neumodischer Kram ;-) ... im Bereich 8-Bit MSR allemal. Das schlimmste ist die unnötige Bürokratie. Dieser hochgradig umständliche Aufwand. Das würde ich von der Priorität her fast noch über den gesteigerten Ressourcenbedarf setzen ;-) le x. schrieb: > Meine Rede. > Ich behaupte Schwing mal keine großen Reden sondern mach Dich an die Arbeit, wenn > 10-15min realistischer sind. ... > Allerdings wird im ersten Schuss zwangsläufig RAM benutzt, ja mei, ist > halt so, und eventuell ein paar Bytes mehr Flash. Also. Vergleich verloren. > Könnte man alles trotzdem irgendwie hinpfuschen. Du sagst es. Mit C eine einzige Rumpfuscherei > jede noch so > abstruse Forderung erfüllen Logo. Beim Vergleich des Ressourcenbedarfs ist der Vergleich der Ressourcen eine abstruse Forderung. > nicht mehr > erweiterbaren ASM-Lösung Erzähl keinen Müll. Die ist mit zusätzlicher Funktionalität wunderbar erweiterbar und auch schon entsprechend vorbereitet. > Und ich vermute mal, für 99% der Anwesenden hier auch Sprich mal nicht für ein Publikum was Du im Rücken wähnst sondern allein für Dich.
Lothar M. schrieb: > Gu. F. schrieb: >> Seit 2000 Seiten > Nein, noch nicht ganz.... ;-) Wie viele müssen wir denn noch?
Sheeva P. schrieb: > Wie viele müssen wir denn noch? Bis 2015 natürlich, pünktlich am 31. Danach geht nur noch eine pro Jahr.
P. M. schrieb: > Faktenlose Beiträge? Ich denke wir haben dir aus allen denkbaren > Perspektiven erklärt Du solltest Deine Perspektiven nicht mit Fakten verwechseln. > belegt, was Sache ist Belege geschehen mit Fakten und nix anderem, schon gar nicht mit Perspektiven. > es geht einzig und alleine > noch darum, dir zu zeigen, wie absurd deine Haltung ist Schon klar. Die Mühe von harten Fakten wär jetzt auch zuviel verlangt. Da könntest Du mal "zeigen". Mit Deinem behaupteten Wissensstand ein Klacks ;-) > Klassendepp Ohne Beleidigung gehts nicht mehr. Ein Beleg für Dein Scheitern ;-)
Moby A. schrieb: > Werner P. schrieb: >> Der Typ hat sowas von einen beschränkten Horizont. > > Beschränkt sind eher die Möglichkeiten, mit C effizientem Asm-Code bei > 8-Bit MSR Konkurrenz zu machen ;-) was ist da beschränkt? Nur weil Du in ASM ein paar Bytes weniger verbrauchst. Wenn es Dir was bringt, gerne. ich spare lieber Zeit und kann mich wichtigeren Dingen widmen während du noch mit ÜSV beschäftigt bist. > >> "Du darfst kein >> SRAM verwenden!". usw. usw. > > Zu dumm daß es zu den zu vergleichenden Ressourcen gehört! Ich versteh > Deinen Frust. > Ich bin nicht frustriert. Warum auch. >> Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer >> sein Programm locker in 30 Minuten programmiert. > > Na dann mal los. Viel Funktionalität ist ja nicht (zu vergleichen). > Nix dann mal los. Wozu? >> ABER WEM INTERESSIERT DAS? > > Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher > abgeneigt ;-) > ich verliere/verschwende nur ungern Zeit. Von daher verwende ich Hochsprachen.
Gerhard O. schrieb: > Dann bist Du ja schon fast ein > Österreicher... Ich hab's irgendwie geahnt ;-)
Moby A. schrieb: > Beim Vergleich des Ressourcenbedarfs ist der Vergleich der > Ressourcen eine abstruse Forderung. Seit fast 2000 Beträgen versuchen wir dir das klarzumachen. Schön, dass du das endlich eingesehen hast. Dafür bekommst du jetzt auch mal ein "lebenswert". mfg.
Ich kann mir nicht helfen, aber ich sehe nur dieses eine Bild vor mir: http://image.slidesharecdn.com/politiktage2011sturmimwasserglas-111015100601-phpapp02/95/sturm-im-wasserglas-bedeutung-sozialer-netzwerke-im-internet-fr-die-meinungsbildung-chemnitzer-politiktage-2011-40-728.jpg?cb=1318673438 Mfg, Gerhard
Witkatz :. schrieb: > Gerhard O. schrieb: >> Dann bist Du ja schon fast ein >> Österreicher... > > Ich hab's irgendwie geahnt ;-) Das war aber nicht sehr nett;-)
Werner P. schrieb: > Nur weil Du in ASM ein paar Bytes weniger > verbrauchst. Oder auch mehr, je nach ÜVS. Aber wer keine Wahl hat, hat keine Qual.
Moby A. schrieb: > Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was > mich persönlich sehr interessiert. Nen Scheißdreck tust du. Am Anfang des Threads konnte man noch den Eindruck haben dass du dir die Beiträge wirklich durchliest. Da bist du noch mehr oder weniger drauf eingegangen. Aber ab den letzten ca. 1000 Beiträgen kommen von dir nur noch inhaltslose Phrasen. Da machen sich Leute die Mühe und Verfassen technisch fundierte Beiträge, versuchen die Vor- und Nachteile von Sprachkonstrukten (z.B. Datentypen) zu erleutern oder dir die Funktionsweise eines Compilers zu erklären, stecken echt viel Zeit rein und du - du gehst entweder garnicht drauf ein, oder holst entweder die Bürokratie- die ÜSV- oder die Verschwender-Keule raus. Völlig egal um was es geht. Man hat nicht mehr das Gefühl dass du dir die Beiträge durchliest. Du bist nur noch am Phrasendreschen, inhaltsloses Geschwurbel, zufällig aneinandergereiht. Gib also nicht den Interessierten. Es geht nur noch ums letzte Wort. Irgendwer erwähnte ELIZA: wenns nicht so traurig wär, man könnts echt meinen...
Witkatz :. schrieb: > Ich hänge noch mal mein PIC12F675 XC8 FREE Projektchen an. Ich habe es > an deine allerneueste Anforderungsliste angepasst Nett von Dir, aber Dein PIC Code hilft gerade nicht weiter. Hatte ich dazu nicht schon ausführlich Stellung genommen? Nochmal im Klartext: Spart Euch weitere Codebrocken. So viel Funktionalität hat enthalten meine <200 Bytes Flash nicht. Michael K. schrieb: > Geht ja zum Glück schon lange nicht mehr um Inhalte. Du meinst, bei Dir? Ja, der Eindruck drängt sich auf. Aber kein Wunder wenns mit C nicht zu stemmen ist ;-) Ich habe Verständnis.
Moby A. schrieb: > Nett von Dir, aber Dein PIC Code hilft gerade nicht weiter. Hatte ich > dazu nicht schon ausführlich Stellung genommen? > > So viel Funktionalität hat enthalten meine <200 Bytes Flash nicht. Doch, mein Code hat volle Funktionalität bei 198 PIC Maschinenbefehlen. Ich kann doch nichts dafür, dass du über C nur schwafeln kannst, aber noch nicht mal in der Lage bist C zu buchstabieren. > Nochmal im Klartext: Spart Euch weitere Codebrocken. Ja wie denn jetzt, wirfst du schon die Flinte in den Korn?
Gerhard O. schrieb: > Das war aber nicht sehr nett;-) Das war auch eines der ernstzunehmenden Argumente hier ;-) le x. schrieb: > Da machen sich Leute die Mühe und Verfassen technisch fundierte > Beiträge, versuchen die Vor- und Nachteile von Sprachkonstrukten (z.B. > Datentypen) zu erleutern oder dir die Funktionsweise eines Compilers zu > erklären, stecken echt viel Zeit rein und du - du gehst entweder > garnicht drauf ein, oder holst entweder die Bürokratie- die ÜSV- oder > die Verschwender-Keule raus. Du begreifst es nicht. Ich möchte nichts erklärt haben, ich möchte überzeugt werden. Mit Fakten. Dafür hab ich ein fix und fertiges Projekt eingebracht. Also bitte, kein > inhaltsloses Geschwurbel, zufällig aneinandergereiht. sondern eine bessere C-Fassung meines Projekts bitte! Das müsstest Du in 10-15 min noch vor dem Schlafengehen schaffen ;-)
Moby A. schrieb: > Jay W. schrieb: >> So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer >> noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR >> kann da zu klein sein > > Hast Du eine Ahnung! > Welches deiner Programme hat den bis jetzt nicht in einen 8-bit AVR gepasst? Die "C"-Kompilate passen dann auch rein. >> Damit fällt doch auch dieser >> pathologische Sparzwang weg. > > Hier gehts nicht um Sparzwang oder Verschwendungssucht. > "Wer mehr als 2 Byte SRAM oder 1 Byte mehr an Flash verbraucht, hat verloren." Wie würdest du das bezeichnen? Redest du nicht immer von "fettem C" ? Die wichtigste Ressource im Leben eines Menschen ist die "Zeit". Da du dein Tinysensorboardprogramm immer noch optimierst, würde ich glattweg behaupten, dass du deine Lebenszeit verschwendest. Schade. Assembler zu beherrschen und zu wissen, wann man ihn am besten einsetzt, sind die Tugenden eines Programmierers, nicht das sture Beharren auf der Sprache. > Danke für Deinen Beitrag, der dieses Thema aber leider verfehlt ;-( Ich bin zerknirscht. :-( Manche Tellerränder scheinen ziemlich hoch zu sein.
Wißt Ihr wieviele tolle Projekte man in der Zeitspanne, die dieser Thread schon konsumiert hat, hätte durchziehen können? Durchschnittliche Beitragsschreib- und Denkdauer ca 5 min. Macht also 10Kh oder 400 Mannstunden. Was hätte man also in dieser Zeitspanne alles schaffen können... Schade! Zieht die Bremsen an, bevor der Zug unanhaltbar wird. Gruß, Gerhard
Gerhard O. schrieb: > Zieht die Bremsen an, bevor der Zug unanhaltbar wird. Wir sind gerade bei 1933, es dauert nicht mehr lang.
Witkatz :. schrieb: > Gerhard O. schrieb: >> Zieht die Bremsen an, bevor der Zug unanhaltbar wird. > > Wir sind gerade bei 1933, es dauert nicht mehr lang. Und was passiert dann?
Jay W. schrieb: > Manche Tellerränder scheinen ziemlich hoch zu sein. Tellerrand? Der sitzt im Fass und der Deckel ist drauf ;-)
Gerhard O. schrieb: >> Wir sind gerade bei 1933, es dauert nicht mehr lang. > > Und was passiert dann? Nichts ist eindeutiger als eine Zweideutigkeit? ;-) Nö, es geht um Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Witkatz :. schrieb: > Gerhard O. schrieb: >>> Wir sind gerade bei 1933, es dauert nicht mehr lang. >> >> Und was passiert dann? > > Nichts ist eindeutiger als eine Zweideutigkeit? ;-) > Nö, es geht um Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Ja, fast hätte ich es vergessen. Ich dachte schon er meinte Wiley Coyote aus Braunau...
Gerhard O. schrieb: > Witkatz :. schrieb: >> >> Wir sind gerade bei 1933, es dauert nicht mehr lang. > > Und was passiert dann? Nach Stanislaw Lem in seinen "Sterntagebüchern" hat die Information dann die kritische Masse erreicht und wird zu Materie, sich dabei selbst auslöschend. Chaos!
Gerhard O. schrieb: > Was hätte man also in dieser Zeitspanne alles > schaffen können... ein etwas komplexeres ASM Programm ;-) bald 1945. dann ist Schluss mit lustig
Moby A. schrieb: > Ich möchte nichts erklärt haben, ich möchte überzeugt werden. ... das ist schlichtweg eines: G E L O G E N ... egal wie oft Sie das wiederholen ! Sie möchten hier nur eines: Sich unglaublich darüber amüsieren, wieviele Menschen Ihnen ob ihren absoluten zensiert Beiträgen auf den Leim gehen. Jemand, der überzeugt werden mag, macht sich Gedanken. Sie ... haben das Denken schon seit längerer Zeit schlicht eingestellt !
Gerhard O. schrieb: > Moby A. schrieb: >> Gerhard O. schrieb: >>> Du bist aus Bayern? Von wo ungefähr? >> >> Von dort wo der Inn wieder Deine alte Heimat berührt ;-) > > Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein > Österreicher... > > Gerhard Ein Bayer, der nach eigenen Angaben als ersten Computer einen "Heimcomputer" der frühen 80er der Firma Robotron bediente. Klingt ja völlig ungelogen.
Clemens M. schrieb: > Nee eine Beleidigungsschiene ist das nicht. > Erklär mir doch mal wo ich dir Unrecht tue Ich weiß gar nicht, wie ich Dir bei soviel zur Schau gestellten Hilflosigkeit noch helfen kann. ;-( Überhaupt bitte ich um Verständnis, daß ich mich lieber mit dem eigentlichen Thema beschäftige: Johann L. schrieb: > Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE > C-Umsetzung. Falsch. Nur 1. Mit Übung, Vorbereitung, System. 2. Für den 8-Bit MC Bereich. 3. Bei wenig Rechnerei und nicht allzuviel Daten! 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache. > Nein, C als Sprache kennt weder Flash noch Register noch Stack oder > Schalter. Was man für effizienten Code aber kennen sollte! C selbst liefert ein Vielfaches an Begrifflichkeiten (hatte ich alles schon hundert Mal aufgezählt) > Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine > C-Implementation, und die darf ich wählen wie ich will? Du sollst von meiner Funktionsbeschreibung auf ein C-Programm kommen > Oder geht's dir nur um Compiler-Bashing? Nein. Ich weiß in Compilern steckt einiges KnowHow und viel Arbeit. Es gibt viele Einsatzgebiete wo C eingesetzt werden kann. Mal sinnvollere, mal weniger sinnvolle. Zu letzteren zählt 8-Bit MSR. > dann nen Blutsturz bekommen weil der > 2 Bytes mehr verbraucht hat? Spar Dir die Poesie. Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels nach ;-) > C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler. Nun stellst Du Dich auch noch dumm. Du weißt natürlich, daß der resultierende Code hier im Fokus steht. > Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln? Keinen.
:
Bearbeitet durch User
Moby A. schrieb: > Falsch. Nur > 1. Mit Übung, Vorbereitung, System. > 2. Für den 8-Bit MC Bereich. > 3. Bei wenig Rechnerei und nicht allzuviel Daten! > 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache. Irgendwas fehlt hier doch. Ach ja: MSR Bitte, gern geschehen.
P. M. schrieb: > Moby A. schrieb: > Was interessiert mich hier jede denkbare C-Umsetzung? > Asm ist in jedem Fall deutlich magerer > Also, hopp, beweis es! Komm! Beweis es! Mein Code liegt vor. Beweise Du jetzt weniger Aufwand mit C. Laß Dich nicht von den übergroß drohenden Zielen unnötig Angst machen: 197 Bytes Flash und 2 Bytes auf dem Stack ;-) Schaffst Du das nicht sag ich trotzdem Dankeschön. Lothar M. schrieb: > Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist > keinen müden Cent billiger. Und der braucht auch nicht weniger Strom. > Und er ist auch nicht leichter. Du hast ein "Und" vergessen: - Und um das alles gehts hier gar nicht! > Das Einzige, was passiert, ist dass die hocheffiziente und RAM-sparende > Appliktation ein halbes Jahr zu spät an den Markt kommt und sie dann > keiner mehr will. Ein Argument in einer Firma- bei einem weniger Asm- geeigneten Projekt! Witkatz :. schrieb: > Die Auflistung der C Schlüsselworte und Operatoren ... wird wohl kaum für prsktische C-Programmierung ausreichen ;-) > Also was denn jetzt. Erst fantasierst du dir was über C zusammen Ach woher denn. Da kommt mir z.B. gleich wieder Beitrag "Einstieg in C - komische Fragen" in den Sinn. Hilfe! Hilfe!
Klaus W. schrieb: > Irgendwas fehlt hier doch. > > Ach ja: MSR > > Bitte, gern geschehen. Ist ja eh das meiste. Wolltest Du mir nicht noch was nachliefern? Wo überall im SmartHome Asm und 8Bit nicht reichen?
Stefan K. schrieb: > Moby A. schrieb: > Kapselung der Funktionalität > > bedeutet bei Dir: > für jeden Hühnerschiss einen anderen mc. Das definiert der Rest der Welt > irgendwie anders! Vermutlich beherrscht Du Asm nicht insoweit als daß Du die Funktionskapselung in meinem Code erkennen konntest ;-) Was die vielen MC's angeht: Der MC muß sich dort befinden wo er im SmartHome für Sensor/Aktorknoten auch gebraucht wird. Mit der allumfassenden 32 Bit Zentral-CPU gewinnst Du da keinen Blumentopf. Markus M. schrieb: > Mein Code lässt sich kompilieren ... ist aber keine vollständige 1:1 Umsetzung meines Projekts. Merke: Die .hex soll dann gleich in meine Tiny13-Zielhardware ;-)
Gerhard O. schrieb: > Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein > Österreicher... > > Gerhard Aber nur fast :-) Das aber doppelt: Von der Grenznähe und vom "östlichen" her ;-) Jay W. schrieb: > Das stimmt nicht. Du versucht aus einem eingeschränkten > Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist, > mit Verlaub, blödsinnig. Der eingeschränkte Anwendungsbereich der einen lässt Platz frei für die andere. Was ist daran blödsinnig? Witkatz :. schrieb: > Moby A. schrieb: > Beschränkt sind eher die Möglichkeiten, mit C.. > > Für dich auf jeden Fall. Es ist eine andere Welt. Und eine Welt ohne jeden Reiz im 8-Bit MSR Bereich!
Gerhard O. schrieb: > Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein > Österreicher... > > Gerhard Aber nur fast :-) Das aber doppelt: Von der Grenznähe und vom "östlichen" her ;-) Jay W. schrieb: > Das stimmt nicht. Du versucht aus einem eingeschränkten > Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist, > mit Verlaub, blödsinnig. Der eingeschränkte Anwendungsbereich der einen lässt Platz frei für die andere. Was ist daran blödsinnig? Witkatz :. schrieb: > Moby A. schrieb: > Beschränkt sind eher die Möglichkeiten, mit C.. > > Für dich auf jeden Fall. Es ist eine andere Welt. Und eine Welt ohne jeden Reiz im 8-Bit MSR Bereich! Thomas E. schrieb: > Dafür bekommst du jetzt auch mal ein "lebenswert". Kannst Du behalten. Lese/zitiere lieber richtig. Jay W. schrieb: > Welches deiner Programme hat den bis jetzt nicht in einen 8-bit AVR > gepasst? Die "C"-Kompilate passen dann auch rein. > Damit fällt doch auch dieser > pathologische Sparzwang weg. Möglicherweise. Hier und da. Was in jedem Fall weg fällt ist die C-Bürokratie. > "Wer mehr als 2 Byte SRAM oder 1 Byte mehr an Flash verbraucht, hat > verloren." Wie würdest du das bezeichnen? Redest du nicht immer von > "fettem C" ? Tja Du darfst nicht vergessen, daß wir hier nur von einem <200 Byte Projektchen reden und noch lange nicht ausgemacht ist wieviel ein C-Projekt mehr verbraten würde! Hat ja keiner den Mumm, die angeblichen "15" Minuten zu erübrigen ;-) > Die wichtigste Ressource im Leben eines Menschen ist die "Zeit". Da du > dein Tinysensorboardprogramm immer noch optimierst, würde ich glattweg > behaupten, dass du deine Lebenszeit verschwendest. Da optimier ich gar nix. Nur für den Vergleich hier streiche ich hier und da noch zusammen ;-) > Assembler zu beherrschen und zu wissen, wann man ihn am besten einsetzt, > sind die Tugenden eines Programmierers, nicht das sture Beharren auf der > Sprache. Die Tugend besteht immer darin, welche Lösung den geringsten Aufwand macht. Dazu zählt auch das zu beherrschende Sprachinstrumentarium. > Ich bin zerknirscht. :-( Manche Tellerränder scheinen ziemlich hoch zu > sein. Hab auch den Eindruck ;-)
:
Bearbeitet durch User
Gerhard O. schrieb: > Zieht die Bremsen an, bevor der Zug unanhaltbar wird. Gerhard, was fachlich nicht klärt geht fließend ins Entertainment über. Mach Dir keine Sorgen. Ich hab Spaß dran. Sheeva P. schrieb: > Moby A. schrieb: > Ich habe Verständnis. > > Wie das? Dazu bedürfte es schließlich eines Verstandes. Zu Bedeutenderem reichts bei Dir wohl nicht mehr? Genügend Verstand hätte auch Umsetzung meines Projekts durch einen C-Programmierer benötigt ;-) Ralph S. schrieb: > Moby A. schrieb: > Ich möchte nichts erklärt haben, ich möchte überzeugt werden. > > ... das ist schlichtweg eines: G E L O G E N > > ... egal wie oft Sie das wiederholen ! > > Sie möchten hier nur eines: Sich unglaublich darüber amüsieren, wieviele > Menschen Ihnen ob ihren absoluten zensiert Beiträgen auf den Leim gehen. > > Jemand, der überzeugt werden mag, macht sich Gedanken. Sie ... haben das > Denken schon seit längerer Zeit schlicht eingestellt ! Für meinen Geschmack schreist Du hier recht wirr durch die Gegend. Ein untrügliches Anzeichen,wenn sich einer nicht mehr unter Kontrolle hat. Wenn Du meinst, mir auf den "Leim" zu gehen dann mach das Naheliegende: Bleib fern. Ein gutgemeinter Ratschlag.
Carl D. schrieb: > Ein Bayer, der nach eigenen Angaben als ersten Computer einen > "Heimcomputer" der frühen 80er der Firma Robotron bediente. Klingt ja > völlig ungelogen. Tja Carl D. Deine kombinatorischen Fähigkeiten sind wohl auch nicht mehr das was sie mal waren... Meine Person ist hier aber nicht das Thema, sie gestaltet es höchstens mit. So, damit sollten alle wichtigen Beiträge des Tages passend quittiert sein. Hab die nächsten Tage nicht mehr ganz soviel Zeit. Harte C Fakten zu meinem Projekt sind vermutlich ohnehin nicht mehr zu erwarten und wenn, dann bitte ich um Fortsetzung in meinem Projekt-Thread: Beitrag "Kleines Tiny13 Sensorboard" Gute Nacht und Danke für die rege Beteiligung ;-)
>Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher >abgeneigt ;-) Muhaha! Das ist doch mal ein nettes Zitat. Suche mal oben nach Karl Heinz Vorschlag und ergötze dich wie du dich da rauswindest.
Moby A. schrieb: > Die Auflistung aller Instruktionen ist schnell erledigt, deren > Verständnis auch. Kein Vergleich mit C. Richtig heist der Satz: "Die Auflistung aller mir bekannten Instruktionen ist schnell erledigt, deren Verständnis auch. Kein Vergleich mit C."
Moby A. schrieb: > Das schlimmste ist die unnötige Bürokratie. > Dieser hochgradig umständliche Aufwand. Gibts eig. einen Grund warum du ständig deine persönlichen Defizite herausstellst? Wenn du das bischen C Syntax wirklich nicht verstehst dann sollte dir das eher peinlich sein.
Gu. F. schrieb: > dann sollte dir das eher peinlich sein. Wem nichts peinlich ist, der ist strategisch im Vorteil. ;-)
fällte sowas noch unter 8-bit MSR: Heizkurve berechnen PI(D) Regler Dimmkurve für led berechnen RMS (Strom/Spannung/(Blind-)Leistung usw.) Sonnenstand berechnen NTC/PTC Kennlinien ?
Für die allermeisten: JA, Für Herrn M. definitiv: NEIN. grins so schön digital einfach.
Das schickt man als Rohdaten an den PC und rechnet in Excel. So bleibt die Reinheit des 8-Bit Glaubens bewahrt und man muss sich nicht mit fetter Bürokratie rumärgern.
:
Bearbeitet durch User
Moby A. schrieb: >> In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten >> möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen >> läßt. > > So edel optimiert muß Software auf einem kleinen Controller aber > ausschauen! Sparsamer Verbrauch, Kapselung der Funktionalität, einfache > Erweiterbarkeit. Edel Optimiert ? Das ist dilletantisches Gemurkse bereits beim Grundkonzept. Wo ist denn Dein ÜVS beim Systemkonzept gewesen ? Ich bitte Dich, eine synchrone serielle Schnittstelle bei der ich eine Taktleitung mitschleppen muß ? Nicht Bus fähig, nicht adresserbar und schnarchlangsam ? Weder gibt diese verpfuschte Umsetzung jemals vernünftige Datenraten her, noch werden die Übertragungsfehler sicher detektiert. Die AD Wandlung misst irgendwas in abhängigkeit der jeweiligen Chips weil die für genaue Messungen notwendige Kalibrierung nicht stattfindet. Da kannst Du ruhig 10bit übertragen, das ist trotzdem Schrott mit begrenzter Aussage. Keine Entprellung der Inputs ? Das ist gröbster, dämlichster Pfusch und ist eher ~edel_optimiert, wenn Du weist was ich meine. >> Mit Verlaub. >> Das ist vollkommener Müll. > Du meinst weil klar ist, daß man es in C nicht kürzer gebacken bekommt? Nein, weil Du ja wirklich überhaupt keinen Plan hast wovon Du das faselst. Das beschränkt sich ja nicht auf Hochsprachen, das sieht bei Konzeption und Hardware genauso traurig aus. >> Die unterste Schmerzgrenze für Sensor Aktor Knoten sehe ich bei >> adressierbaren Master Slave Feldbussen mit min. 16 Teilnehmern. > Bist Du von der Industrie? Dann wär mir alles klar. So einer muß die > überteuerten Preise dort irgendwie rechtfertigen. Schenk Dir das. Geht > alles viel simpler, viel billiger ;-) Im Gegensatz zu Dir habe ich Systeme in Industrie und Luftfahrt konzeptioniert und gebaut. Ich kenne sowohl die Theorie als auch die Praxis die einen Feldbus zum Feldbus macht und warum man gut daran tut alles was ein paar Meter überbrücken muß störsicher auszulegen. Dein Kram ist weder billig noch simpel. Von jedem Knoten eine separate Leitung zum Master legen zu müssen und für jeden Knoten auf dem Master eigene Ports zu blockieren ist alles andere als billig und simpel. Das ist einfach nur dumm und zeugt davon das Du überhaupt nicht in der Lage bist Konzepte zu verstehen die über Deinen winzigen Tellerrand hinausgehen. Dazu verwendest Du die MCU Familie die wohl das schlechteste Preis Leistungs Verhältniss hat das man derzeit finden kann. Wenn Du wirklich 10% so clever wärst wie Du glaubst dann wärst Du in der Lage mit einer fast identischen Hardware, ohne Zusatzkosten einen Adressierbaren Sensorknoten zu bauen der einen bidirektionalen 1Draht Bus besitzt, in der Anwendung reprogrammierbar ist und mit einem kalibrierten AD, entprellten IOs (ja, auch Ausgängen) zuverlässigge Daten erhebt und die auf Anforderung des Masters mit einer zuverlässiggen CRC Summe überträgt. Du hingegen stümperst Dir hahnebüchenden Kram zusammen und nennst das edel optimiert mit ÜVS. Zu Ahnungslos zu sein sowas vernünftig umzusetzen kann ich ja noch akzeptieren, aber zu blöd auch nur ansatzweise zu verstehen was man da eigentlich in der Summe alles verbockt hat und darauf auch noch stolz zu sein ist wirklich eine ganz eigene Kategorie. Ich lege normalerweise nicht so den Finger in die Wunde, aber Deine Borniertheit schreit ja geradezu danach.
Wenn ich die Codes mir so vergleiche: Moby: https://www.mikrocontroller.net/attachment/highlight/277428 Witzkatz: https://www.mikrocontroller.net/attachment/highlight/277579 Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch verstehen. Da werden irgend welche Zahlenwerte in Register geschrieben, ohne Datenblatt zu wälzen ist es schwer. Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten angesagt. Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt die Bits gezeigt die gesetzt werden. Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann was gleichbedeutend mit RAM Verbrauch ist. Daher ist es einfach nur einseitig gedacht "ich brauche kein SRAM" - obwohl die Register wohl auch SRAM sind. Oder was sind Register denn sonst? Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe angeht: 24 Bit senden, mit 80 ms Pause ??? Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je nach Auslastung des Programmes des Master Boardes wohl auch nicht so leicht ist. Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B. STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur Synchronisation und kann problemlos mit 9600 Baud geschehen. Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext mit übertragen, die von der Gegenstelle gezeigt werden! Das wäre flexieben, aber so es ist nur eine Krücke/Krampf.
:
Bearbeitet durch User
Markus M. schrieb: > Unterm Strich ist der Speicherverbrauch > wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich > auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann > was gleichbedeutend mit RAM Verbrauch ist. Egal, Moby macht hier die Regeln was eine "Ressource" ist. - SRAM ist natürlich die Wichtigste, die Kostbarste. Denn mit ihr steht und fällt die Möglichkeit, seinen Code mit C zu schlagen. - Erweiterbarkeit, Lesbarkeit, Entwicklungszeit, Testbarkeit, Portierbarkeit, Wiederverwendbarkeit, Skalierbarkeit dagegen sind unwichtig. Diese Ressourcen sind billig und müssen daher auch nicht geschont werden - insbesondere die Entwicklungszeit ist völlig vernachläsigbar da Menschen ja über unbegrenzt Freizeit/Lebenszeit verfügen
Moby A. schrieb: > Vermutlich beherrscht Du Asm nicht insoweit als daß Du die > Funktionskapselung in meinem Code erkennen konntest ;-) Ach ja? Von Dir kann ich das noch nicht mal als Beleidigung auffassen. Ein hingepfuschtes Frickelprogramm, eine proprietäre serielle Übertragung in Morsegeschwindigkeit, den kompletten Befehlssatz eines Anfängerprocessors auch nach Jahren noch nicht vollständig drauf, ASM bedeutet AVR, weil Dein Horizont knapp davor aufhört ... Das Einzige, was an Dir wirklich bewundernswert ist, wie Du mit so wenig Wissen den Mund dermassen voll nehmen kannst.
Markus M. schrieb: > Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch > verstehen. Dir fehlt ganz eindeutig ÜVS! Leute, nur noch 33 Beiträge, dann gibt Lothar uns ein Bier aus! :-) (Oder hatte ich ihn da falsch verstanden? ;)
Jörg W. schrieb: > dann gibt Lothar uns ein Bier aus! Jedem Forumteilnehmer? Man das gibt ja ne Riesenparty.
Markus M. schrieb: > Oder was sind Register denn sonst? Multiported SRAM. Erheblich teurer als normales SRAM.
>ich brauche kein SRAM
Ich habe ein Auto teuer gekauft.
Aber ich verwende es nie. Habe ich mit ÜVS hoch und edel optimiert.
Markus M. schrieb: > Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je > nach Auslastung des Programmes des Master Boardes wohl auch nicht so > leicht ist. Ich sag dir, ich würde bares Geld dafür zahlen, den XMega-Code des Masters sehen zu dürfen. Insbesondere wie er mehrere Sensorboard-Daten einliest und dieses krude Protokoll parst während im Hintergrund die Regelung weiterläuft würde mich echt interessieren.
A. K. schrieb: > Markus M. schrieb: >> Oder was sind Register denn sonst? > > Multiported SRAM. Erheblich teurer als normales SRAM. PS: Cores mit Akkumulator statt grossem Registersatz sind in dieser Hinsicht billiger als AVR. Bei Tiny10&Co hat Atmel deshalb den halben Registersatz weggelassen und lieber ein paar Bytes RAM implementiert.
:
Bearbeitet durch User
Dumdideididel die Katz hat die Fidel und die Kuh springt über den Mond. Einer kleiner Sprung für die Kuh, ein großer Sprung für die Kuhheit. So, noch 32 Beiträge.
Moby Code: https://www.mikrocontroller.net/attachment/highlight/277428 Ist ein Spaghetticode ohne erkennbare Struktur, dafür braucht er wirklich ÜVS, denn sonst könnte er das niemals zu hin bekommen Witzkatz Code: https://www.mikrocontroller.net/attachment/highlight/277579 hingegen ist klar strukturiert, ordentliche Bezeichner und unterteilt in Funktionen mit den einzelnen Aufgaben und somit: - Wartbarer - leichter zu erweitern - leichter anpassbar auf andere Anforderungen - direkt mit der Spezifikation vergleichbar
> parst während im Hintergrund die Regelung weiterläuft wü Macht ein extra Hardwarechip, natürlich dazugekauft. Da kein typisches 8bit MSR. >lieber ein paar Bytes RAM implementiert. Gut für Moby, kann mehr von der gekauften Ressource nicht verwendet werden.
Markus M. schrieb: > Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das > C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch > wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich > auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann > was gleichbedeutend mit RAM Verbrauch ist. Damit blendet er sich selbst. Die RAM-"Einsparung" dient der angeblichen "Erweiterungsmöglichkeit". Dazu muss der Erweiterer nur einige Register auf dem Stack sichern. Wenn also eine Anzahl, sagen wir mal 5, von Registern als Speicher für globale Variablen benutzt werden, müssen diese von der Erweiterung auf dem Stack gesichert werden. Das bedeutet, dass immer 5 Byte RAM "verloren" gehen. Würde man die Variablen, wie jeder mit Hirn versehene Programmierer das tut, im RAM anlegen, gingen für die Erweiterbarkeit auch 5 Byte RAM "verloren". Was ist der Unterschied für die RAM-Auslastung? Ausser, dass man sich daran aufgeilen und den grossen Macker spielen kann, leider gar keiner. Sondern Überheblichkeit, Verbohrtheit und Selbstüberschätzung. Aber abgerechnet wird zum Schluss. Und dann werden solche unsinnigen Spielereien schonungslos aufgedeckt. Programmierung ist nämlich kein Voodoo-Zauber. @Moby: Mir und den meisten anderen ist klar, dass du das nicht verstehst. mfg.
:
Bearbeitet durch User
le x. schrieb: > Egal, Moby macht hier die Regeln was eine "Ressource" ist. > - SRAM ist natürlich die Wichtigste, die Kostbarste. Biete 1k SRAM (garantiert unbenutzt) gegen 1 Monat Lebenszeit. Wer macht mit?
Markus M. schrieb: > Jörg W. schrieb: >> dann gibt Lothar uns ein Bier aus! > > Jedem Forumteilnehmer? > > Man das gibt ja ne Riesenparty. Juhuu, dann hatte der Thread ja doch einen Sinn :-)
Jörg W. schrieb: > Leute, nur noch 33 Beiträge, dann gibt Lothar uns ein Bier aus! :-) > (Oder hatte ich ihn da falsch verstanden? ;) Dann macht mal langsam, ich darf mein Bier erst nächsten Montag aufmachen. Es ist noch nicht "reif"... http://www.bergbier.de/brauereibesichtigung.html
Moby A. schrieb: > Harte C Fakten > zu meinem Projekt sind vermutlich ohnehin nicht mehr zu erwarten Du weisst noch nicht mal wie C geschrieben wird.
>Dann macht mal langsam, ich darf mein Bier erst nächsten Montag >aufmachen. Es ist noch nicht "reif"... >http://www.bergbier.de/brauereibesichtigung.html Das wirft doch zwangsläufig den notwendigen Vergleich des Ballmer Peak bei asm oder c-Kodierung auf! Hat da schon jemand Erfahrungen?
Du hast folgendes behauptet: > Moby A. schrieb: >> Was interessiert mich hier jede denkbare C-Umsetzung? >> Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Das sollst du jetzt bitteschön endlich mal beweisen. Moby A. schrieb: > Mein Code liegt vor. Beweise Du jetzt weniger Aufwand mit C. Nein, dein Code beweist in keiner Weise, dass "Asm in jedem Fall deutlich magerer" ist. Die Beweislast liegt nun klar bei dir. Du hast die Behauptung aufgestellt, du musst sie also auch beweisen.
Moby A. schrieb: > Johann L. schrieb: >> Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE >> C-Umsetzung. > > Falsch. Nur > 1. Mit Übung, Vorbereitung, System. > 2. Für den 8-Bit MC Bereich. > 3. Bei wenig Rechnerei und nicht allzuviel Daten! > 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache. Unter diesen engen Bedingungen soll ASM also immer effizienter als C sein? Zusammen mit folgender Aussage Moby A. schrieb: > Asm-Programmierung ist durchschnittlich aufwendiger, aber je nach Übung, > Vorbereitung und System. Dafür kommt mehr Effizienz bei raus. Allein um > diesen Punkt geht es mir aber- und zwar bis hoch zu 1M frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur wenige simple Berechnungen durchgeführt werden. Wie viele Daten verarbeitet werden, spielt nahezu keine Rolle. In erster Linie wird mehr RAM benötigt, Programmspeicher nur für das Arraygedöhns und eventuale Initialisierungen.
>Moby A. schrieb: >Allein um diesen Punkt geht es mir aber- und zwar bis hoch zu 1M Das hatte ich noch gar nicht gelesen. Wenns so ist, dann sollten wir aber einen Vergleich definieren für einen Code >> 10kBytes Flash. Und zwar mit einer Textaufgabe als Start.
be s. schrieb: > frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur > wenige simple Berechnungen durchgeführt werden. Na, Übung, Vorbereitung, System. Halt von allem genügend. :-)
Moby A. schrieb: > Johann L. schrieb: >> Nein, C als Sprache kennt weder Flash noch Register noch Stack oder >> Schalter. > > Was man für effizienten Code aber kennen sollte! Eine C-Implementation (Compiler) muss solche Konzepte kennen. Aber C als Sprache braucht von Flash nichts zu wissen. Es ist ja noch nicht mal klar, ob eine bestimmte Hardware überhaupt Flash hat! C beschreibt nur Eigenschaften die ein konformer Code haben muss, es macht keine Aussagen darüber, wie das erreicht werden darf! Beispiel: Wenn in einem C-Programm "a = b + 1" steht, dann bedeutet das weder, dass es im erzeugten Code eine Variable namens "a" geben muss, noch dass es eine Variable "b" geben muss, noch dass es irgendwo im Code eine Sequenz gibt, die "1" auf irgendwas addiert. Eine bestimmte C-Implementation (C-Compiler) darf das so machen, ist aber nicht gezwungen das zu tun. Und du (und viele andere hier) haben immer noch nicht verstanden, dass ein bestimmtes C-Programm, das mit einem bestimmten C-Compiler übersetzt worden ist, nur eine Obergrenze für den von C mindestens erforderlichen Resourcenverbrauch ergibt. Was du hier behauptest sind Untergrenzen für den Verbrauch, und dass dieses Minimum, egal von welchem C-Compiler erzeugt, immer größer ist als der Verbrauch des von dir vorgelegten Codes. Vielleicht solltest du dir erst mal den Unterschied zwischen Maximum und Minimum, zwischen Obergrenze und Untergrenze klar machen? > C selbst liefert ein Vielfaches an Begrifflichkeiten > (hatte ich alles schon hundert Mal aufgezählt) C kennt weder den begriff "Bürokratie" noch "Flash" noch "Register". Aber vielleicht hab ich ja auch was überlesen, und du bist so großzügig, uns die Stellen im C-Standard aufzuzeigen. >> Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine >> C-Implementation, und die darf ich wählen wie ich will? > > Du sollst von meiner Funktionsbeschreibung auf ein C-Programm kommen Und wie willst du von einem C-Programm auf einen Resourcenverbrauch kommen, ohne eine C-Implementation (vulgo: Compiler) zu haben? > >> Oder geht's dir nur um Compiler-Bashing? > > Nein. Ich weiß in Compilern steckt einiges KnowHow und viel Arbeit. Es > gibt viele Einsatzgebiete wo C eingesetzt werden kann. Mal sinnvollere, > mal weniger sinnvolle. Zu letzteren zählt 8-Bit MSR. > >> dann nen Blutsturz bekommen weil der 2 Bytes mehr verbraucht hat? > > Spar Dir die Poesie. > Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels > nach ;-) Wenn das C-Programm deine Spezifikation erfüllt, und dein Asm-Programm ebenfalls, dann stellt dieses Asm-Programm eine konforme Umsetzung des C-Codes dar. Mithin wäre dein Asm-Code eine obere Grenze für den Resourcenverbrauch eines optimalen C-Compilers. Oder sind deine Programme bewusst so geschrieben, dass sie nicht als C-Programm formuliert werden können? >> C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler. > > Nun stellst Du Dich auch noch dumm. Du weißt natürlich, daß der > resultierende Code hier im Fokus steht. Dafür brauchen wir aber einen Compiler. Welchen sollen wir da nehmen? >> Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln? > > Keinen.
Moby A. schrieb: > Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels > nach Wir hatten das alles schon. Du behauptest ständig, Assembler (meinetwegen mit ÜVS, also: aufwändiger Bürokratie) sei C überlegen. Statt Deine eigenen Behauptungen zu belegen, wie das unter Erwachsenen üblich ist, forderst Du, andere sollen Deine Behauptungen widerlegen... :-) Das hat Yalu dann getan und Dir unwiderlegbar bewiesen, daß sein C-Compiler sogar bei solch winzigen Popelprojektchen besseren Code produziert als Du, was für Yalu, für seinen Compiler, gegen Deine Fähigkeiten als Programmierer spricht und Dein Geblubber eindeutig widerlegt. :-) Daraufhin hast Du plötzlich ein neues Popelprojektchen aus Deinem Hütchen gezaubert, bei dem Du Dir offensichtlich die größte Mühe gegeben hast, dem Compiler möglichst viele Fallen zu stellen. Und als mein Honigtöpfchen dann trotzdem kleiner aussah, mußtest Du auf einmal panisch die neue Anforderung "darf kein SRAM benutzen" erfinden. Und genauso würde es wieder laufen, wenn jemand einen C-Code abliefert, der Dein Sensorprojektchen schlägt: entweder erfindest Du eine neue Anforderung oder Du kommst gleich mit einem neuen Popelprojektchen um die Kurve. Been there, done that, got the t-shirt. Solche Betrügereien sagen ja vor allem etwas über die hohle Frucht, die sie offensichtlich nötig hat. Und sie sind ein Beweis dafür, daß Du nicht einmal selbst an Dein dummes Gelaber glaubst. :-)
Sheeva P. schrieb: > Und genauso würde es wieder laufen, wenn jemand einen C-Code abliefert, > der Dein Sensorprojektchen schlägt: entweder erfindest Du eine neue > Anforderung oder Du kommst gleich mit einem neuen Popelprojektchen um > die Kurve. Glaub ich nicht, dann könnte er sich gleich hier abmelden. ;-) Außerdem: Sind euch denn die Slimeys, mit denen er fast jede seiner Aussagen abschließt, verborgen geblieben? ;-) Der Mann mag Slimeys! ;-) Könnte man ihm nicht einen C-Compiler bauen, der anstatt des Semikolon einen Sliley frisst? So als kleines Leckerli um ihn den Einstieg zu versüßen ;-)
:
Bearbeitet durch User
Moby A. schrieb: >> Mein Code lässt sich kompilieren > > ... ist aber keine vollständige 1:1 Umsetzung meines Projekts. Merke: > Die .hex Wenn du nach C-Umsetzung deines ADC Klackers fragst, bekommst du genau das - eine C-Umsetzung in edelstem C verfasst. Du darfst sie im Ganzen oder die einzelnen Routinen davon gerne auf der µC Plattform deiner Wahl mit dem Compiler deiner Wahl verwenden. Eine .hex Datei ist kein C-Projekt. Aber das kannst du nicht verstehen, weil das ein Satz mit C ist. Also jetzt ein Quiz für Moby und alle, die es werden möchten: In welcher Programmiersprache ist eine C-Umsetzung verfasst, A. ist es A, B. oder B C. oder vielleicht C? Als Hauptgewinn winkt 1k freien RAM auf einem attiny13.
Witkatz :. schrieb: > Eine .hex Datei ist kein > C-Projekt. Schau einer an. Na sowas. Aber vielleicht ein eindeutiger Ausdruck der manchem hier klarmacht, daß eine vollständige Umsetzung statt irgendwelcher Bruchstücke gewünscht ist?
Moby A. schrieb: > Aber vielleicht ein eindeutiger Ausdruck der manchem hier klarmacht, daß > eine vollständige Umsetzung statt irgendwelcher Bruchstücke gewünscht > ist? Da du ja der erfahrenste von uns allen bist, macht es schon Sinn, das du die Vorgaben machst.
In den fast 2000 Beiträgen ist doch nunmehr nachlesbar bewiesen, dass weder Assembler auf dem Vormarsch ist, noch das es C, oft selbst als Makroassembler verschrien, gelingt, dermaßen schlechten Code zu generieren wie Moby. Im Gegenteil, durch sparsame und sinnvolle Verwendung der zur Verfügung stehenden Ressourcen, enstehen wart- und erweiterbare Anwendungen, die nur wenig mehr an Ressourcen verwenden. Und das bereits ab einer Codegröße von wenigen Byte. Auch das Verwenden von Worthülsen wie SÜV, VSÜ, ÜVS, SVÜ, VÜS und ÜSV ändert nichts an diesem Ergebnis. Die Selbstdemontage des einsamen Protagonisten war vollumfänglich und seiner Sache hat er eher einen Bärendienst erwiesen. Vielleicht kann dieser Thread ja nun geschlossen werden, bevor Lem recht behält. ;-)
Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will, muss sich das hier ansehen: Beitrag "Fast JPEG decoder on AT(x)mega"
Robert L. schrieb: > fällte sowas noch unter 8-bit MSR: > Heizkurve berechnen > PI(D) Regler Für eine reine Raumtemperaturregelung (habe Fernheizung) nicht nötig. > Dimmkurve für led berechnen Man kann auch ne Wissenschaft draus machen ;-) > RMS (Strom/Spannung/(Blind-)Leistung usw.) Wo fallen da große Berechnungen an? Für Blindleistungs-Berechnung? Das mag ja für Spezialfälle interessant sein- für alle anderen gibts 10€ Fertiggeräte ;-) Bei mir hab ich eine einzige selbstgebaute Strommessung im Einsatz: Die misst den Strom bei einem billigen Heizungs-Stellglied zur Feststellung des Endanschlags. Und was soll ich Dir sagen: Das geht locker auch mit Asm. Entsprechende Sensoren sind einfach auszuwerten. > NTC/PTC Kennlinien Bei fertigen Temperatursensoren unnötig. > Sonnenstand berechnen Da schau ich aus dem Fenster ;-) > ? Hab ich mich auch gefragt... Nein im Ernst, daß (Spezial-) Anwendungen mit erhöhtem Rechen- und Datenverwaltungsbedarf den Einsatz einer Hochsprache (und ggf. stärkerer Controller ) rechtfertigen können hatte ich doch nicht ausgeschlossen!
:
Bearbeitet durch User
Jay W. schrieb: > dermaßen schlechten Code zu > generieren wie Moby. Der ließe sich nur mit besserem toppen. Scheint aber nicht so einfach zu sein ;-) Michael K. schrieb: > Ich gönne Moby außerdem nicht das letzte Wort Das letzte Wort spricht Stand heute immer noch mein ungeschlagenes Asm-Projekt ;-) Mensch Leute, nun reißt Euch mal am Riemen! Dermaßen schlechten Code muß doch hier jeder kürzer in C hinbekommen! Besonders die großen Sprücheklopfer, denen trau ich das am ehesten zu ;-)
Rufus Τ. F. schrieb: > Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will, > muss > sich das hier ansehen: > > Beitrag "Fast JPEG decoder on AT(x)mega" Was heißt hier wahnwitzig? In erster Linie ist es möglich! Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-)
Moby A. schrieb: > Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-) Gut, dazu zähle ich jetzt nicht, aber es gibt schon interessanten Code. Auch gelegentlich in ASM. Den habe ich hier aber noch nicht gesehen :-)
Mist, zu spät :-/ Gut, dann ist dies hier eben der 2001. Beitrag :) Damit hat Lothar seine Wette grandios gewonnen. Gratulation! Ich freue mich schon riesig auf das Bier, das er Gerüchten zufolge ausgeben will :) Da auch ich nicht mit leeren Händen zur Party kommen möchte, habe ich eine C-Portierung von Mobys sensationellem 8-Bit-MSR-Assemblerprogramm mitgebracht, von der sich jeder, der heute bis 24 Uhr einen Beitrag in diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D Das Programm entspricht exakt der von lex_91 zusammengefassten und von Moby bestätigten bzw. ergänzten Spezifikation: Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Kleine Anmerkung an Moby: Die Bits in deinem Zeitdiagramm stimmen nicht mit deinen aktuellen textuellen Anforderungen überein. Es stammt wohl von deiner ersten Programmversion mit der seltsamen Prüfsumme und der umgekehrten Bitreihenfolge bei der Datenübertragung. Das Einlesen, die Auswertung und das Versenden der Messdaten findet komplett im Timerinterrupthandler statt. Das Hauptprogramm läuft nach der Initialisierungm der I/O-Register in eine leere Endlosschleife. Der Gesamtablauf ist also praktisch genauso wie bei Mobys Assemblerprogramm. Auch die Konfiguration des Timers und des ADC habe ich von dort übernommen, nur mit etwas mehr Symbolik bei den Registerinhalten. Nach diesen Erläuterungen zur Spezifikation Beitrag "Re: Assembler wieder auf dem Weg nach vorn" habe ich die RAM-Initialisierung und den Sleep weggelassen. Für den Vergleich habe ich auch in Mobys Assemblerprogramm die entsprechenden Passagen entfernt, was dessen Codegröße um 16 Bytes verringert. Wenn es gewünscht wird, rüste ich gerne auch eine C-Variante mit Sleep und RAM-Initialisierung nach. Quellcode und Hexfile liegen bei, auf dass sie von Moby zerissen werden mögen (keine Angst, ich habe noch eine Kopie davon) und damit er seine Spezifikation noch einmal "überarbeiten" kann ;-) Das Programm wird gebaut mit
1 | avr-gcc-4.7.4 -mmcu=attiny13 -Os -nostdlib -o sensorboard sensorboard.c |
Mobys Programm hat noch einen kleinen Fehler: Die Register A1LO1, A1H, A2LO2 und A2HO3 werden anfangs nicht mit 0 initialisiert, weswegen der jeweils erste übertragene ADC-Mittelwert für jeden Kanal falsch sein kann. Ich habe die dafür erforderlichen Befehle (2 CLR und 1 MOVW) hinzugefügt, wodurch sein Programm wieder um 6 Bytes wächst. Hier sind die Ergebnisse des Vergleichs:
1 | Speicherverbrauch in Bytes |
2 | |
3 | Mobys ASM Yalus C |
4 | —————————————————————————————————— |
5 | Flash 206 158 |
6 | SRAM (Stack) 2 2 |
7 | —————————————————————————————————— |
Ein Teil der eingesparten Flash-Bytes kommt daher, dass in meinem C-Programm der normalerweise für die ungenutzten Interruptvektoren vorgesehene Platz mit Programmcode belegt wird. Tut man dies auch bei Mobys Programm, verringert sich dessen Flash-Bedarf um 18 Bytes auf 188 Bytes, was aber immer noch deutlich über den 158 Bytes des C-Codes liegt. Insgesamt hat der Compiler eine recht gute Arbeit abgeliefert: Beim Durchsehen des erzeugten Assemblercodes sind mir auf Anhieb nur drei Stellen mit Optimierungsbedarf aufgefallen, bei denen jeweils ein Registertransfer (MOV bzw. MOVW) eingespart werden könnte. Das würde das Programm von 158 auf 152 Bytes verkürzen, was aber nicht einmal 4% ausmacht . Ich habe das C-Programm auf einen ATtiny13 geladen und für verschiedene Spannungen und Logikpegel an den Analogeingängen bzw. an PB1 mit dem Oszilloskop das Takt- und Datensignal überprüft. Sowohl das Timing (im Rahmen der Genauigkeit des internen RC-Oszillators) als auch die übertragenen Bits stimmten mit den Vorgaben und auch mit Mobys Programm überein. Nur den PB5-Eingang habe ich nicht getestet, weil ich dazu den Reset-Eingang hätte wegfusen müssen. Aber das Programm wird ja sowieso von Moby noch auf Herz und Nieren geprüft werden :) *********************************************************************** Es ist also tatsächlich möglich, Mobys Assembleranwendung deutlich ressourcensparender in C zu schreiben. Damit bietet C nicht nur bei großen Programmen, sondern sogar bei solchen Miniprogrammen (in Mobys Sprache "typische 8-Bit-MSR-Anwendungen") klare Vorteile. *********************************************************************** Natürlich hat Moby das längst geahnt (oder sogar gewusst?) und schon einmal entsprechend vorgebaut: Moby A. schrieb: > Johann L. schrieb: >> Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm >> findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und >> komplett versagt? > > Wer wird denn hier von Versagen reden? Der Vorteil simpler Codierung > ohne viel Bürokratie bleibt Asm dann immer noch. Nur die > Ressourcen-Geschichte hätte sich dann (für mich) erledigt. Ok, die Ressourcenfrage hat sich nun erledigt. Als einzige Vorteile von Assembler gegenüber C bleiben also die simple Codierung und die geringere "Bürokratie". Beide Kriterien lassen sich aber leider weder klar definieren noch objektiv messen, weswegen sich bzgl. dieser Punkte am besten jeder sein eigenes Bild macht. Ein paar Gedankenanstöße hierzu: 1. Simple Codierung Man vergleiche die Interrupthandler der beiden Programme miteinander: Obwohl im Wesentlichen beide dasselbe tun, ist die C-Version sehr viel kompakter. So ist bspw.
1 | sum.all += ADC; |
und
1 | sum.all /= 8; |
zur Berechnung des Mittelwerts meiner Meinung nach nicht nur leichter zu schreiben, sondern auch besser zu verstehen als
1 | in r16,ADCL |
2 | in r17,ADCH |
3 | add A1LO1,r16 |
4 | adc A1H,r17 |
und
1 | lsr A1H |
2 | ror A1LO1 |
3 | lsr A1H |
4 | ror A1LO1 |
5 | lsr A1H |
6 | ror A1LO1 |
Hinzu kommen die leichteren Konfigurationsmöglichkeiten. In Mobys Code kann man immerhin die Spannungsreferenzen für die beiden ADC-Kanäle getrennt voneinander einstellen (auch wenn ich anfangs nicht ganz nachvollziehen konnte, woher dieser "magische" Wert $c0 kommt, den man für die interne Referenz angeben muss ;-)). In C ist es aber ein Leichtes, auch die komplette Pinbelegung und die Taktfrequenz der Datenübertragung konfigurierbar zu machen. Einiges davon ginge sicher auch in Assembler, aber schon die Übersetzung von Portnummern in die entsprechenden ADC-Kanäle durch den Compiler bzw. Assembler – in C ganz geradlinig mit einem Compilezeit-Array als Look-Up-Tabelle möglich – dürfte in Assembler schon einige Verrenkungen erfordern. Das Schöne dabei: Der Compiler ändert bei einer Umkonfiguration nicht einfach nur ein paar Operanden der generierten Maschinenbefehle, wie dies beim Assembler der Fall wäre, sondern optimiert – je nach Wahl der Konfigurationsparameter – den Code durch Weglassen unnötiger Befehle oder gar geschicktes Umschreiben ganzer Befehlssequenzen. In Assembler erfordert so etwas meist Handarbeit, was nicht nur Zeit kostet, sondern auch eine potentielle Fehlerquelle darstellt. Zugegebermaßen gibt es auch in meinem C-Code ein paar Stellen, die man, wenn man nicht unbedingt jedes einzelne Flash-Byte umdrehen muss, auch etwas klarer gestalten hätte können. Ich hoffe, dass die Kommentar den Ablauf trotzdem halbwegs verständlich machen. 2. Bürokratie Bürokratie hat ja etwas mit Verwaltungswahn zu tun. Anders als in C obliegt in Assembler die Verwaltung der einzelnen Register und des Datenspeichers komplett dem Programmierer. Einige der Register haben eine feste Funktion und sind deswegen von Moby mit Namen (SIC, A1LO1, A2LO2 usw.) versehen worden. Aber was ist mit den Registern R16, R17 und R18? Die Bedeutung dieser Register ändert sich ständig, weswegen keine sinnvollen Namen vergeben werden können. Ohne Namen ist aber bspw. nur schwer zu erkennen, das der Registerinhalt von R18 in Zeile 98 eine 14 Zeilen früher angelegte Kopie von SIC ist. Jeder temporären Variable ein eigenes benamstes Register zuzuordnen geht aber auch nicht, weil sonst die 32 Register ganz schnell aufgebraucht sind. Wenn man nicht sorgfältig Buch darüber führt, von wo bis wo im Code jedes Register welchen Inhalt hat, wird man ziemlich schnell im Chaos versinken. Diese Buchführung wird durch die vielen assemblertypischen Kreuz- und Quersprünge noch zusätzlich erschwert. Wenn man dann nicht nur Register, sondern auch noch Statusflags zur Übertragung von Informationen über weite Strecken innerhalb des Programms nutzt, ist die Buchführung durch den Programmierer kaum mehr praktikabel, da die Änderungen der Statusflags durch die entsprechenden Befehle meist implizit erfolgt, was schnell einmal übersehen wird. In diese Falle ist trotz ÜVS sogar der Meister höchstpersönlich getappt, als er eins seiner anderen Miniprogrämmchen schnell mal um ein paar scheinbar triviale Dinge erweitern wollte, wodurch halt zufälligerweise einer der hinzugefügten Befehle an ungünstiger Stelle das Carryflag überschrieb: Beitrag "Re: C versus Assembler->Performance" Und was geschieht, wenn das Programm trotz aller Vorbereitung am Ende doch etwas datenintensiver wird und man gerne ein paar Variablen von "guten" Registern (R16 bis R31) in die weniger guten (R0 bis R15 mit eingeschränkten Adressierungsarten) oder gar ins RAM verlagern möchte? Oder der 8-Bit-Wertebereich stellt sich für eine Variable als zu knapp heraus, und man möchte stattdessen mit 16-Bit-Werten in Registerpaaren arbeiten? In C sind das alles keine großen Herausforderungen, in Assembler hingegen läuft das ganz schnell auf das Neuschreiben ganzer Codepassagen hinaus. In höheren Programmiersprachen ist für solche Buchhaltertätigkeiten ganz klar der Compiler zuständig, der auch bei komplexen Programmen nie den Überblick verliert. Natürlich muss der Programmierer den Compiler dabei mit ein paar Informationen unterstützen, was wohl das ist, was Moby als Bürokratie empfindet. Dass man all diese Information bei der Assembler- Progammierung ebenfalls vorhalten muss (statt im Quellcode eben auf einem Blatt Papier, das gerne verloren geht oder gar im Kopf, der sie nach ein paar Wochen vergisst), ist ihm wohl nicht bewusst. Anders als in anderen höheren Programmiersprachen kann man – sofern man das möchte – in C die Verwaltungsaebeit des Compilers in vielfältiger weise beeinflussen, um mehr Effizienz des Programms zu erzielen. So gibt es im obigen C-Programm einige explizite Registerzuordnungen für globale Variablen. Diese sind aber nur Mobys unsinniger Anforderung nach null RAM-Verbrauch geschuldet und würden bei dieser Anwendung (und den allermeisten anderen ebenfalls) weggelassen werden, da sie nur ganz selten einen wirklichen Nutzen bringen. Normalerweise macht sich der C-Programmierer keine Gedanken darüber, in welchen RAM-Zellen oder Registern Variablen abgelegt werden und wann sich mehrere temporäre Variablen ein Register teilen, weil es einfach viel zu viel Bürokratie wäre, über das alles im Detail Bescheid wissen zu müssen ;-) 3. Weitere Kriterien Moby, dir fallen doch ganz neben dem Ressourcenverbrauch, der simplen Codierung und der Bürokratie, in denen ASM nun ja doch nicht ganz so gut abschneidet, noch weitere (am besten messbare) Kriterien ein, die man zum Vergleich zwischen Assembler und C heranziehen könnte. Das würde mal wieder etwas neuen Schwung in die Diskussion bringen, so dass der Thread auch nach dem Überschreiten der 2000er-Grenze unterhaltsam bleibt. Ich bin auf deine neuen Argumente schon gespannt wie ein Flitzebogen ;-)
Moby A. schrieb: > Jay W. schrieb: >> dermaßen schlechten Code zu generieren wie Moby. > > Der ließe sich nur mit besserem toppen. Scheint aber nicht so einfach zu > sein ;-) Moby, diese Aussage ist eine rabulistische Meisterleistung. Chapeau! Mittlerweile hat Yalu nun auch den endgültigen Beweis erbracht. Für seine Leistung und seinen Langmut gebührt ihm meine höchste Anerkennung. Wahnsinn!
:
Bearbeitet durch User
Der Moby ist ja wieder da, also poste ich das nochmal... Wenn ich die Codes mir so vergleiche: Moby: https://www.mikrocontroller.net/attachment/highlight/277428 Ist ein Spaghetticode ohne erkennbare Struktur, dafür braucht er wirklich ÜVS, denn sonst könnte er das niemals hin bekommen Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch verstehen. Da werden irgend welche Zahlenwerte in Register geschrieben, ohne Datenblatt zu wälzen ist es schwer. Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten angesagt. Witzkatz Code: https://www.mikrocontroller.net/attachment/highlight/277579 Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt die Bits gezeigt die gesetzt werden. hingegen ist klar strukturiert, ordentliche Bezeichner und unterteilt in Funktionen mit den einzelnen Aufgaben und somit: - Wartbarer - leichter zu erweitern - leichter anpassbar auf andere Anforderungen - direkt mit der Spezifikation vergleichbar - einzelne Anschnitte der Spezifikation in Funktionen gepackt, womit eine Änderung der Spezifikation leichter umsetzbar ist. Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann was gleichbedeutend mit RAM Verbrauch ist. Daher ist es einfach nur einseitig gedacht "ich brauche kein SRAM" - obwohl die Register wohl auch SRAM sind. Oder was sind Register denn sonst? Wie schon mal von mir geschrieben: ein STM32 hat CCM RAM, also kann ich problemlos alles, incl. Stack dort drin laufen lassen und es wird KEIN SRAM benutzt. Und wenn ich einen externen DataFlash anschließe und das Programm in den RAM lade, braucht es auch kein FLASH mehr (das geht z.B. mit Cypress µC). Somit, Moby deine Anforderungen sind einfach nur Blödsinn. Und der Preis vom schlechtesten Spagetti Code hast du allemal gewonnen. Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe angeht: 24 Bit senden, mit 80 ms Pause ??? Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je nach Auslastung des Programms des Master Boards wohl auch nicht so leicht ist. Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B. STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur Synchronisation und kann problemlos mit 9600 Baud geschehen. Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext mit übertragen, die von der Gegenstelle gezeigt werden! Das wäre flexibel, aber so es ist nur eine Krücke/Krampf.
Jay W. schrieb: > Vielleicht kann dieser Thread ja nun geschlossen werden, bevor Lem recht > behält. ;-) Nö. Bevor die C-Fraktion sich vollends blamiert ;-) Michael K. schrieb: > Ich bitte Dich, eine synchrone serielle Schnittstelle bei der ich eine > Taktleitung mitschleppen muß ? Das möchte ich mal aus Deinem Plädoyer für eine kompliziertere, umständlichere Lösung herausgreifen: Du checkst offensichtlich nicht, daß diese Taktleitung a) einer easy Auswertung dient und b) einen nicht genau bekannten/schwankenden MC-Takt wie er nunmal von einem internen Osc geliefert wird zur Verwendung ermöglicht. Ansonsten ist meine Lösung für die gegebene Sensorausstattung fast ideal optimiert und simpel. So muß das ausschauen! Markus M. schrieb: > Wenn ich die Codes mir so vergleiche: > Moby: > https://www.mikrocontroller.net/attachment/highlight/277428 > > Witzkatz: > https://www.mikrocontroller.net/attachment/highlight/277579 > > Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch > verstehen. Da wären AVR-Asm Kenntnisse angebracht ;-) > Da werden irgend welche Zahlenwerte in Register geschrieben, ohne > Datenblatt zu wälzen ist es schwer. Für einen ASMler gehört zur optimalen Controller-Anpassung immer das Datenblatt in die Hand. > Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht > mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten > angesagt. Ein Label im funktionsführenden (Timer-) System-Interrupt. > Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt > die Bits gezeigt die gesetzt werden. Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist professionelles Vorgehen. > Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das > C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch > wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich > auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann > was gleichbedeutend mit RAM Verbrauch ist. Könnte man meinen. Den gleichen Registersatz R0-32 hat aber jeder AVR. Im zusätzlichen RAM unterscheiden sie sich. Der soll gespart werden. Den Registersatz hatte ich für C nicht verboten zu nutzen. Auch wenn mehr als 11 genutzte Register dann vergleichsmäßig sehr unschön rüberkommen ;-) > Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe > angeht: 24 Bit senden, mit 80 ms Pause ??? > Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je > nach Auslastung des Programmes des Master Boardes wohl auch nicht so > leicht ist. Die Pause dient der Synchronisierung und macht die einfache Auswertung erst möglich. Ein Beispiel ist in meinem Projekt enthalten! > Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B. > STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur > Synchronisation und kann problemlos mit 9600 Baud geschehen. Aber nicht mit Tiny13 ohne UART. Der langt für die Aufgabe aber genauso. Eine UART setzt auch noch einen hinreichend genauen Systemtakt voraus. > Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext > mit übertragen, die von der Gegenstelle gezeigt werden! Man könnte vieles und jenes. Die gestellte Aufgabe wird aber erfüllt. > aber so es ist nur eine Krücke/Krampf. Aber so ist es die optimale Umsetzung der Aufgabenstellung mit viiel Platz übrig für Erweiterungen ;-)
Moby A. schrieb: > Was heißt hier wahnwitzig? Es ist --wie jedes Assemblerprogramm-- praktisch unwartbar.
Yalu X. schrieb: > Ok, die Ressourcenfrage hat sich nun erledigt. Na schaun mer mal. Morgen hab ich etwas Zeit Deinen Code praktisch zu prüfen. Würd mich freuen wenn er weiteren Streit erübrigen würde. > Ich bin auf deine neuen Argumente schon gespannt wie ein Flitzebogen ;-) Bekommst Du ;-) Danke für's Erste.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Es ist --wie jedes Assemblerprogramm-- praktisch unwartbar. Wie hab ich bloß die letzten 20 Jahre überstanden ;-) Jay W. schrieb: > Für > seine Leistung und seinen Langmut gebührt ihm meine höchste Anerkennung. > Wahnsinn! Es hätte, wenn meine realisierte Funktion tatsächlich 1:1 abgebildet wird, auch lang genug dazu gebraucht. Wahnsinn ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Da wären AVR-Asm Kenntnisse angebracht ;-) Moby A. schrieb: > Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist > professionelles Vorgehen. Wieso sollte ich nun unbedingt den Dialikt vom AVR lernen? Der nächste schreibt ein PIC ASM Code, der nächste MIPS und wieder einer Renesas. Jedes mal irgend ein µC spezifischen Code lernen, damit ich das von fremden Leuten verzapfte verstehe? Ne danke. Ich bleib bei C. Das ist so ähnlich wenn es elektronische Datenblätter in Chinesisch, Russisch, Französisch, Italienisch, Hebräisch usw. gäbe. Aber zum Glück sind alle englisch und ein jeder Weltweit braucht nur Englisch lernen!
Moby A. schrieb: >> Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt >> die Bits gezeigt die gesetzt werden. > > Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist > professionelles Vorgehen. Das ist mal wieder dein übliches Geblubber. Ein Datenblatt brauche ich für Prozessorspezifisches. In deinem Gewusel braucht man es aber auch für triviale Sachen, wie elementare Operationen über mehrere Anweisungen, wo man in jeder vernünftigen Sprache etwas lesbares hinschreibt. Wobei man natürlich auch in ASM mehr oder weniger klar ausdrücken kann; ebenso wie ein Depp natürlich auch in anderen Sprachen unlesbares Kauderwelsch schreibt. Nur ist es in Hochsprache halt leichter und schneller, sauberen Quelltext zu schreiben - der auch dank eines Compilers noch effizient ist. Würde dich lesbarer Quelltext interessieren, würdest du entweder schöneres ASM hinschreiben, oder gleich etwas anderes nehmen. Aber jeder wie er will, ich muß mit deinen Quelltexten ja nichts machen.
Moby A. schrieb: > Rufus Τ. F. schrieb: >> Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will, >> muss sich das hier ansehen: >> >> Beitrag "Fast JPEG decoder on AT(x)mega" > > Was heißt hier wahnwitzig? > In erster Linie ist es möglich! Ja klar ist sowas möglich, warum sollte sowas nicht möglich sein? > Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-) So ein Projekt ist beachtlich. Unbegreiflich für mich ist jedoch, warum man es so implementiert, dass die Wiederverwendbarkeit stark eingeschränkt ist (Atmel-Assembler) und es insbesondere unmöglich ist, den Code von C aus zu verwenden. Das ist doch überaus kurzsichtig. Vor allem weil es kein Mehraufwand gewesen wäre, Wiederverwendbarkeit zu bieten. Wenn man sich schon solche Arbeit macht, warum dann nicht so programmieren, dass es möglichst vielseitig verwendbar ist? Mir steht da echt der Mund offen ... nämlich wegen der dargebotenen Kurzsichtigkeit.
Yalu X. schrieb: > Hier sind die Ergebnisse des Vergleichs: > > Speicherverbrauch in Bytes > > Mobys ASM Yalus C > —————————————————————————————————— > Flash 206 158 > SRAM (Stack) 2 2 > —————————————————————————————————— Herrlich, im Ring heist das K.O. auf ganzer Linie. Ich sehe Moby aber schon wieder das Maul aufreisen wegen ......... nun ja wegen was wohl? Nun ihm wird schon was einfallen.
Johann L. schrieb: > Mir steht da echt der Mund offen ... nämlich wegen der dargebotenen > Kurzsichtigkeit. Ich sehe solche Ansätze eher in der Tradition jeder Spinner, die sich zusammen mit möglichst vielen anderen Leuten in eine Telefonzelle quetschen. Kann Spass machen und man ist hinterher stolz. Aber um telefonieren geht es dabei üblicherweise nicht.
Gu. F. schrieb: > Yalu X. schrieb: >> Hier sind die Ergebnisse des Vergleichs: >> >> Speicherverbrauch in Bytes >> >> Mobys ASM Yalus C >> —————————————————————————————————— >> Flash 206 158 >> SRAM (Stack) 2 2 >> —————————————————————————————————— > > Herrlich, im Ring heist das K.O. auf ganzer Linie. > Ich sehe Moby aber schon wieder das Maul aufreisen wegen ......... nun > ja wegen was wohl? > Nun ihm wird schon was einfallen. Hab es doch gesagt: Jeder findet seinen Meister. Ich vermute: Yalu hat mehr ÜVS benötigt.
Yalu X. schrieb: > Das Programm wird gebaut mit > > avr-gcc-4.7.4 -mmcu=attiny13 -Os -nostdlib -o sensorboard sensorboard.c Wie geht das denn nun am einfachsten? Code einfach in ein Studio-Projekt für Tiny13 reinkopieren und Solution builden/assemblieren wie bei Asm ist ja hier nicht. Entsprechendes für ein GCC-Projekt erzeugt nur Fehlermeldungen. Hilfe! Möchte für eine einfache .hex Erstellung nicht gleich im C-Optionschaos versinken ;-(
Die übliche Antwort: https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial Setzt die hin und fang endlich an zu lernen.
Moby A. schrieb: > Wie geht das denn nun am einfachsten? Debian installieren und das darin enthaltene Paket gcc-avr installieren. Der ist zwar 4.7.2, liefert aber auch 158 Bytes ab. in Yalus Kommandzeile ändert sich dann nur ebendiese Versionsnummer. Ok, das ist natürlich hauptsächlich dann am einfachsten, wenn man sowieso schon so eine Kiste rumliegen hat. ;-)
:
Bearbeitet durch User
Gu. F. schrieb: > Setzt die hin und fang endlich an zu lernen. Ganz sicher werd ich das jetzt nicht durcharbeiten nur um eine .hex eines C-Codes zu erstellen ;-) Einfach heißt: Code reinladen, compilieren, .hex! A. K. schrieb: > Debian installieren und das darin enthaltene Paket gcc-avr installieren. Köstlich. Genau das werd ich jetzt... Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus Code. Das wär schade.
:
Bearbeitet durch User
Moby A. schrieb: > Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus > Code. Das wär schade. Ich fand das toteinfach. Ich musste einfach nur Yalus Kommandozeile ausführen. Der Rest war schon da. Wenn du natürlich noch nicht einmal einen Compiler auf der Kiste hast, dann wird es wirklich schwierig, den Compiler zu starten und somit völlig unmöglich, deinen Forderungen nachzukommen. Aber das gilt umgekehrt auch, weil meine Debian-Kiste mit deinem Asm-Quellcode genauso über Kreuz liegt.
:
Bearbeitet durch User
A. K. schrieb: > Wenn du natürlich noch nicht einmal einen Compiler auf der Kiste hast, Wer sagt das? Mein Studio7 enthält einen. Ich kann problemlos ein GCC-Projekt erstellen. > Aber das gilt > umgekehrt auch, weil meine Debian-Kiste mit deinem Asm-Quellcode genauso > über Kreuz liegt. Warum sollte sich mein Asm-Code dort nicht genauso assemblieren lassen wie er auf dem Bildschirm erscheint?
:
Bearbeitet durch User
Moby A. schrieb: > Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus > Code. Ich habe doch extra für dich, auch weil du es so gefordert hast, das Hex-File angehängt. Das schiebst du auf die gleiche Weise auf den Controller wie du es mit mit deinen sonstigen Programmen tust. Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt nicht nur deine, sondern auch meine Fähigkeiten.
Moby A. schrieb: > Wer sagt das? Mein Studio7 enthält einen. Ich kann problemlos ein > GCC-Projekt erstellen. Weshalb weigerst du dich dann, das zu tun? > Warum sollte sich mein Asm-Code dort nicht genauso assemblieren lassen > wie er auf dem Bildschirm erscheint? Weil auf genannter Debian-Kiste kein Assembler von Atmel drauf ist und der GNU Assembler eine völlig andere Quellcode-Notation verwendet.
:
Bearbeitet durch User
Yalu X. schrieb: > Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt > nicht nur deine, sondern auch meine Fähigkeiten. Zuviel Bürokratie? ;-)
Yalu X. schrieb: > das > Hex-File angehängt. Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern hergestellt. > Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt > nicht nur deine, sondern auch meine Fähigkeiten. Klasse. Das spricht für C ;-)
A. K. schrieb: > Weshalb weigerst du dich dann, das zu tun? Wer sagt das ich mich weigere? Von Fehlermeldungen bei der Projekterstellung / Buildvorgang hatte ich doch schon gesprochen, oder?
:
Bearbeitet durch User
Moby A. schrieb: > Das spricht für C ;-) Yalu verwendet möglicherweise nicht das anerkannte Monster an Bürokratie, das Atmel mit dem Studio 7 in die Welt gesetzt hat. Du jedoch scheinst mit überbordender Bürokratie diesmal ausnahmsweise keine Probleme zu haben. Denn so einen fetten Klops auf die Kiste zu wuchten, bloss um einen ATtiny13 zu füttern, das spottet jeder Beschreibung.
A. K. schrieb: > Du > jedoch scheinst mit überbordender Bürokratie diesmal ausnahmsweise keine > Probleme zu haben. Die Projekterstellung/Assemblierung selber ist wie beschrieben ausgesprochen einfach. > Denn so einen fetten Klops auf die Kiste zu wuchten, > bloss um einen ATtiny13 zu füttern, das spottet jeder Beschreibung. Da spottet gar nichts denn damit wird nicht nur ein Tiny13 versorgt ;-)
Moby A. schrieb: > Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da > wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern > hergestellt. Tut es auch der Asm-Output vom Compiler?
A. K. schrieb: > Tut es auch der Asm-Output vom Compiler? Das ist wenigstens mal ein Angebot. Danke. Freilich hätte ich dessen Erstellung schon gern selbst in der Hand. Morgen schau ich erstmal was die .hex in meiner Hardware so treibt.
Und nochmal als Disassembly, mit C Quellcode zwischenrein gemixt.
A. K. schrieb: > Und nochmal als Disassembly, mit C Quellcode zwischenrein gemixt. OK. Prima. Die Einarbeitung in Linux kommt allein für diese Geschichte hier nicht in Frage.
Moby A. schrieb: > Die Einarbeitung in Linux kommt allein für diese Geschichte hier nicht > in Frage. Wär wohl auch nicht nötig. Wahrscheinlich lässt sich im Studio enthaltene GCC auch direkt per Kommandozeile aufrufen - wenn man weiss wie. Aber das ist mir zu viel Bürokratie.
Gu. F. schrieb: > Nun ihm wird schon was einfallen. Schon geschehen: Moby A. schrieb: > Wie geht das denn nun am einfachsten? Moby A. schrieb: > Hilfe! Möchte für eine einfache .hex Erstellung nicht gleich im > C-Optionschaos versinken Moby A. schrieb: > Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus > Code. Moby A. schrieb: > Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da > wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern > hergestellt. Einfach nur erbärmlich. mfg.
Thomas E. schrieb: > Einfach nur erbärmlich. Alles berechtigte Einwände und Fragen für jemanden der die Wissenschaft "C" bisher nicht nötig hatte. Erbärmlich ist eher Deine (fehlende) Antwort darauf ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Alles berechtigte Einwände und Fragen für jemanden der die Wissenschaft > "C" bisher nicht nötig hatte. Erbärmlich ist eher Deine (fehlende) > Antwort darauf ;- https://www.youtube.com/watch?v=omcbYPkh38I mfg.
Moby A. schrieb: > Yalu X. schrieb: >> das >> Hex-File angehängt. > > Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da > wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern > hergestellt. Du glaubst also, ich schummle, und das Hex-File stammt in Wirklichkeit von einem Assemblerprogramm, das ich in mühevoller Arbeit mit viel ÜVS von Hand geschrieben habe? Und A. K. unterstützt mich auch noch bei meiner Schummelei, indem er einen angeblichen Asm-Output des Compiler postet, den er in Wirklichkeit von mir zusammen mit einem Barscheck zugesandt bekommen hat? Die beiden Compiler-Versionen erzeugen übrigens exakt den gleichen Code, die Asm-Outputs unterscheiden sich nur in der nicht relevanten letzten Zeile:
1 | $ diff sensorboard-yalu.s sensorboard-ak.s |
2 | 138c138 |
3 | < .ident "GCC: (GNU) 4.7.4" |
4 | --- |
5 | > .ident "GCC: (GNU) 4.7.2" |
Bitte zu den Programmanforderungen hinzufügen: - muß von jeden V..horst, der keinen Bock hat sich damit zu befassen von Sourcecode aus direkt in den ATtiny13 geflashed werden können. Was hatte irgendwer schon mal geschrieben: er wird neue Anforderungen finden, die das C-Programm nicht erfüllt.
Carl D. schrieb: > - muß von jeden V..horst, der keinen Bock hat sich damit zu befassen von > Sourcecode aus direkt in den ATtiny13 geflashed werden können. Einfaches Handling ist auch ein Aspekt der Bürokratie. Asm bietet das. C wie wir gesehen haben nicht. > Was hatte irgendwer schon mal geschrieben: er wird neue Anforderungen > finden, die das C-Programm nicht erfüllt. Solche Vorhersagen kannst Du in der Pfeife rauchen. Beschäftige Dich mit dem was hier eigentliches Thema ist, dann siehst Du auch für die Zukunft klarer. Und wenn ein Carl D. schrieb: > nicht“Gast“ schrieb: >> Warte nur, bis Moby hier aufschlägt. Der weiß wirklich Bescheid, was man >> so alles auf einen Atmel braucht. ;) > > Dann werde ich sofort von Jörg W.'s Angebot Gebrauch machen, ihn > rausbekamen zu lassen. beweist er nur, das oberste Level an Ratlosigkeit erreicht zu haben. Auch wenn die kleine Unsicherheit im entscheidenden Wort noch etwas Raum zur Hoffnung lässt ;-)
Blöd auch daß Jörg Wort gehalten hat. Danke! Und zu "Bürokratie": Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt ab.
:
Bearbeitet durch User
Yalu X. schrieb: > Die beiden Compiler-Versionen erzeugen übrigens exakt den gleichen Code, > die Asm-Outputs unterscheiden sich nur in der nicht relevanten letzten > Zeile: > > $ diff sensorboard-yalu.s sensorboard-ak.s > 138c138 > < .ident "GCC: (GNU) 4.7.4" > --- >> .ident "GCC: (GNU) 4.7.2" Yalu, du weißt ja schon um die Kryptischen DIFF ausgaben verstehen zu können man einige Wochen Einarbeitungszeit benötigt. Das ist viel zu komplex und bürokratisch. Und wehe Du hast auch noch den DIFF umgeschrieben ....
Yalu X. schrieb: > Du glaubst also, ich schummle, und das Hex-File stammt in Wirklichkeit > von einem Assemblerprogramm, das ich in mühevoller Arbeit mit viel ÜVS > von Hand geschrieben habe? Nein. Das glaube ich nicht. Trotzdem wird es doch wohl legitim sein zu verlangen, daß ich Deinen C Code selbst nachvollziehen kann. Interessant wär mal der hier schon oft erwähnte Aspekt der Entwicklungszeit: Etwa von Beitrag 1 dieses Threads an? Oder gar von noch früher? (meinen Projektthread gibts ja schon ne ganze Weile) ;-)
Carl D. schrieb: > Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu > kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt > ab. Du wirst mir sicher gleich sagen, wo das in der AtmelStudio- Software bloß "einzutippen" ist. Zeig Deinen "Interlekt" mal ;-)
Markus M. schrieb: > Start > Ausführen > CMD.EXE Na probiers mal. Was dann wohl kommt??? Ich hoffe doch schon, daß ein MS Windows und ein fettes 7er Studio auslangen ;-) Tipp: Du hast Yalu X. schrieb: > Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt > nicht nur deine, sondern auch meine Fähigkeiten. überlesen ;-)
Beitrag #4395415 wurde von einem Moderator gelöscht.
Beitrag #4395420 wurde von einem Moderator gelöscht.
ich bin ja so ein Arduino "fritze" hab davon 0.0 Ahnung aber ICH hab das im Atmel Studio 6.2 compiliert bekommen
1 | ------ Build started: Project: GccApplication1, Configuration: Debug AVR ------ |
2 | Build started. |
3 | Project "GccApplication1.cproj" (default targets): |
4 | Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!=''). |
5 | Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Atmel Studio 6.2\Vs\Compiler.targets" from project "D:\Eigene Dateien\documents\Atmel Studio\6.2\GccApplication1\GccApplication1\GccApplication1.cproj" (target "Build" depends on it): |
6 | Task "RunCompilerTask" |
7 | Shell Utils Path C:\Program Files (x86)\Atmel\Atmel Studio 6.2\shellUtils |
8 | C:\Program Files (x86)\Atmel\Atmel Studio 6.2\shellUtils\make.exe all |
9 | Building file: .././GccApplication1.c |
10 | Invoking: AVR/GNU C Compiler : 4.8.1 |
11 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe" -x c -funsigned-char -funsigned-bitfields -DDEBUG -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny13 -c -std=gnu99 -nostdlib -MD -MP -MF "GccApplication1.d" -MT"GccApplication1.d" -MT"GccApplication1.o" -o "GccApplication1.o" ".././GccApplication1.c" |
12 | Finished building: .././GccApplication1.c |
13 | Building target: GccApplication1.elf |
14 | Invoking: AVR/GNU Linker : 4.8.1 |
15 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe" -o GccApplication1.elf GccApplication1.o -nostdlib -Wl,-Map="GccApplication1.map" -Wl,--start-group -Wl,-lm -Wl,--end-group -Wl,--gc-sections -mmcu=attiny13 |
16 | Finished building target: GccApplication1.elf |
17 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "GccApplication1.elf" "GccApplication1.hex" |
18 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex "GccApplication1.elf" "GccApplication1.eep" || exit 0 |
19 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "GccApplication1.elf" > "GccApplication1.lss" |
20 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "GccApplication1.elf" "GccApplication1.srec" |
21 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-size.exe" "GccApplication1.elf" |
22 | text data bss dec hex filename |
23 | 166 0 0 166 a6 GccApplication1.elf |
24 | Done executing task "RunCompilerTask". |
25 | Task "RunOutputFileVerifyTask" |
26 | Program Memory Usage : 166 bytes 16,2 % Full |
27 | Data Memory Usage : 0 bytes 0,0 % Full |
28 | Done executing task "RunOutputFileVerifyTask". |
29 | Done building target "CoreBuild" in project "GccApplication1.cproj". |
30 | Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != ''). |
31 | Target "Build" in file "C:\Program Files (x86)\Atmel\Atmel Studio 6.2\Vs\Avr.common.targets" from project "D:\Eigene Dateien\documents\Atmel Studio\6.2\GccApplication1\GccApplication1\GccApplication1.cproj" (entry point): |
32 | Done building target "Build" in project "GccApplication1.cproj". |
33 | Done building project "GccApplication1.cproj". |
34 | |
35 | Build succeeded. |
36 | ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ========== |
projekt anlegen code rein kopieren ja, man bekommt einen fehler -> checkbox für nostdlib suchen -> optimierung hoch stellen schon gehts..
Robert L. schrieb: > projekt anlegen > code rein kopieren > ja, man bekommt einen fehler > -> checkbox für nostdlib suchen > -> optimierung hoch stellen > schon gehts.. Danke Robert. Das schau ich mir nochmal an. be s. schrieb: > frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur > wenige simple Berechnungen durchgeführt werden. Die Sorge möchte ich Dir nehmen. 1M war etwas ironisch gemeint ;-) le x. schrieb: > - SRAM ist natürlich die Wichtigste, die Kostbarste. Denn mit ihr steht > und fällt die Möglichkeit, seinen Code mit C zu schlagen. Na vielleicht stimmt das ja gar nicht ? Morgen sehen wir weiter.
:
Bearbeitet durch User
Man Leute, gestern wäre das hier bei 1985 fast eingeschlafen.. Jetzt stehts bei 2047.. Und Yalu hat nochmal bewiesen, was ausser Moby alle wussten. Sodann: Grossartig und Skoll: >der heute bis 24 Uhr einen Beitrag in >diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D bleibt nur noch eins zu sagen:
1 | return SUCCESS; |
Matthias L. schrieb: > Man Leute, gestern wäre das hier bei 1985 fast eingeschlafen.. > Jetzt stehts bei 2047.. Ich hatte die Hoffnung, dass da bei 2000 nochmal Schwung in die Sache kommt... ;-) Yalu X. schrieb: > Damit hat Lothar seine Wette grandios gewonnen. Gratulation! War ja einfach... > Ich freue mich schon riesig auf das Bier, das er Gerüchten zufolge > ausgeben will :) Du darfst dir auch eines aufmachen. Das hast du dir verdient. Aber echt: ein Code der abzüglich der unnötigen Kommentare und trotz der vielen Umbrüche komplett auf eine Seite passt. Genial!
So, anbei noch ein Atmel Studio7-Projekt. Ich hoffe mal, dass die getroffenen Einstellungen alle mitgesichert werden. PS. Ich sehe gerade mein Kompilat hat noch 166 Bytes Verbrauch, also habe ich wohl einen Einstellungsfehler. Aber die Größe reicht ja auch.
:
Bearbeitet durch User
A. K. schrieb: > Wahrscheinlich lässt sich im Studio enthaltene GCC auch direkt per > Kommandozeile aufrufen - wenn man weiss wie. Dazu täte es einfach not, dass man, statt auf andere Betriebssysteme zu schimpfen, in die man sich nicht „einarbeiten“ will, sich wenigstens mal in das auserwählte eigene Betriebssystem einarbeitete, um ein Konzept wie das des Suchpfades verstanden zu haben. Dummerweise übernimmt das Gigabyte-Monster von Atmel es halt nicht automatisch, den Suchpfad zum Compiler selbst im System einzutragen. Wäre wohl zu viel Bürokratie. Das Ändern der PATH-Variablen in Windows hat allerdings eines der grauenvollstens GUIs, die es gibt. Man bekommt auf einen Pfadnamen von in der Regel mehreren hundert Zeichen Länge nur ein kleines Guckloch. Während sonst jeder Ar***h heutzutage im Vollbildmodus starten will (wen interessiert schon, dass der Monitor 1900 Zeichen breit ist und viel Platz für anderes böte, wenn man sich gerade die Smartphone-Welt als Ziel ausgemacht hat?), kann man dieses beknackte GUI auch nicht in der Größe ändern.
Jörg W. schrieb: > Das Ändern der PATH-Variablen in Windows hat allerdings eines der > grauenvollstens GUIs, die es gibt. Und je nach Windows Version ist schon allein die Suche nach diesem Dialog ziemlich spannend.
Moby A. schrieb: > Interessant wär mal der hier schon oft erwähnte Aspekt der > Entwicklungszeit: Etwa von Beitrag 1 dieses Threads an? Oder gar von > noch früher? (meinen Projektthread gibts ja schon ne ganze Weile) Dir ist wirklich nichts zu peinlich, oder? Schau mal nach, seit wann es die von dir bestätigte Programmspezifikation gibt. Bei deiner schlangenartigen Argumentationsweise in diesem und anderen Threads, bin ich mir sicher, dass niemand vorher ernsthaft angefangen hat. Yalu wird vermutlich heute vormittag, nach einem erquicklichen Schlaf und einem reichhaltigen Frühstück, die Zeit bis zum Mittag genutzt haben, um das Programm zu schreiben. Nach dem Mittag und dem dazugehörigen Schläfchen hat er es dann veröffentlicht. Das war ja einfach.
Jay W. schrieb: > PS. Ich sehe gerade mein Kompilat hat noch 166 Bytes Verbrauch, also > habe ich wohl einen Einstellungsfehler. Oder eine andere Version des Compilers. Robert kam beim Studio 6.2 mit GCC 4.8.1 auch auf 166 Bytes.
:
Bearbeitet durch User
A. K. schrieb: > Oder eine andere Version des Compilers. Robert kam beim Studio 6.2 mit > GCC 4.8.1 auch auf 166 Bytes. Korrekt. Im Studio 7 werkelt ein GCC 4.9.2
A. K. schrieb: > Und je nach Windows Version ist schon allein die Suche nach diesem > Dialog ziemlich spannend. Gibts da nicht, um diese horrende Bürokratie zu umgehen, einen kleinen asm-Befehl dafür?
Jetzt noch eine CommandLine Einweisung? Ist ja schon klar, dass DOS erst NACH Assembler erfunden wurde. Daher kann Moby das nicht wissen. PATH=%PATH%;<PfadZumGCCfürAVR> Damit ist dies für die aktuelle Console-Sitzung aktiv.
Moby A. schrieb: > Carl D. schrieb: >> Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu >> kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt >> ab. > > Du wirst mir sicher gleich sagen, wo das in der AtmelStudio- Software > bloß "einzutippen" ist. Zeig Deinen "Interlekt" mal ;-) Jemand, der Assembler wegen Kompaktheit und Klarheit benutzt UND etwas von der Materie versteht (also ein Programmierer), der benutzt normalerweise kein "Studio" oder IDE, auch keine GUI, sondern eine Shell. Damit hat er nämlich die Klarheit, wie es funktioniert, und damit wirklich alles in der Hand. Der kann dann auch das Kommando von Yalu einfach aufrufen. Wer das nicht kann, sollte mal ganz klein das lernen anfangen, statt nur heisse Luft zu produzieren. Moby, Du hasts geschafft, dich wird keiner mehr ernst nehmen....einem Schüler hätte man das noch abgenommen, aber einem, der behauptet, seit 20 Jahren zu programmieren..
Yalu X. schrieb: > Speicherverbrauch in Bytes > > Mobys ASM Yalus C > —————————————————————————————————— > Flash 206 158 > SRAM (Stack) 2 2 > —————————————————————————————————— Vielen Dank, Yalu! :-) Und Moby windet sich einmal mehr wie eine Schlange, obwohl nun wirklich alles bewiesen ist. Hätte er auch nur ein Fünkchen Respekt und Anstand, so würde er eingestehen, dass er sich geirrt hat. Das wäre übrigens der geringere Gesichtsverlust, als was er aktuell abzieht...
A. K. schrieb: > Robert kam beim Studio 6.2 mit > GCC 4.8.1 auch auf 166 Bytes. Auf die komme ich mit Studio7 auch, unter den Projekt-Optionen war bei AVR/GNU Linker unter General noch ein Häkchen bei "No startup or default libs (-nostdlib)" zu setzen. Manchmal ist's doch einfacher als man denkt. Diese 166 Bytes sind jetzt für mich maßgeblich und genau die teste ich auch, es sei denn jemand liefert unter Studio7 noch passendere Optionen. Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 Bytes. Mein Code erreicht mit gestrichener Ram- + Sleep-Initialisierung 196 Bytes. Irgendwelche weiteren Grundinitialisierungen lasse ich mir da nicht zuaddieren weil die in der Praxis ohne Bedeutung sind. Vorbehaltlich eines genaueren Funktionsvergleichs (hab nur mal kurz drübergeschaut) und des Funktionstests auf realer Hardware hat C damit eine Leistungsfähigkeit im Ressourcenverbrauch demonstriert die mich beeindruckt hat. Positiv möchte ich außerdem vermerken, daß dazu laut Listing nicht allzuviele Register verwendet wurden. Schaut also bislang gut aus. Bernhard M. schrieb: > der benutzt > normalerweise kein "Studio" oder IDE, auch keine GUI, sondern eine > Shell. Damit hat er nämlich die Klarheit, wie es funktioniert, und damit > wirklich alles in der Hand. Das würde ich als Rückschritt sehen. Das Studio ist schon, bei aller Größe, zumindest bei Assemblerprogrammierung sehr komfortabel und einfach. "In der Hand haben" möchte ich auch nicht tausend C-Compiler Optionen sondern nur meinen Code! Jay W. schrieb: > Dir ist wirklich nichts zu peinlich, oder? Schau mal nach, seit wann es > die von dir bestätigte Programmspezifikation gibt. Das Programm samt zugehöriger "Projektchen"-Beschreibung gibts weitgehend unverändert seit 5.September. Also theoretisch viel Zeit sich vorzubereiten ;-) Vielleicht möchte sich Mod Yalu ja noch dazu äußern, wielang er dran gefeilt hat? Das Thema Entwicklungszeit kam in seinem Beitrag auffällig kurz ;-) P. M. schrieb: > Und Moby windet sich einmal mehr wie eine > Schlange, obwohl nun wirklich alles bewiesen ist. Hätte er auch nur ein > Fünkchen Respekt und Anstand, so würde er eingestehen, dass er sich > geirrt hat. Das wäre übrigens der geringere Gesichtsverlust, als was er > aktuell abzieht... Nun sprich mir mal nicht vorschnell Respekt und Anstand ab. Den von Dir gewünschten Gesichtsverlust eines anonymen Moby wirst Du auch nicht erleben, immerhin bekam der die Funktionalität in wenigen Bytes mehr ohne jedes Compiler-KnowHow zusammen- während Dein und anderer "Experten" KnowHow meist gerade mal für höhnische Kommentare langte ;-) Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das nehm ich mal als Ansporn! Mehr dazu und ggf. zur "Preisverleihung" dann im Laufe des Sonntags!
:
Bearbeitet durch User
nur mal zur Erinnerung, Moby war der Meinung man könne SEINEN optimierten! Code überhaupt nicht in C schlagen.. Moby A. schrieb: > Markus M. schrieb: >> Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich >> zurück mit Falschaussagen > > Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt > gezeigt wurde nicht geschlagen und ist nicht zu schlagen. Höchstens in > gewissen Wunschfantasien ;-) Speziell Dein Beitrag dazu war bislang > überschaubar und fachlich: nicht vorhanden. auf die Entwicklungszeit rausreden wird auch schwierig: es ist ein Wunder, dass überhaupt jemand sich die Mühe gemacht hat, dieses doch recht unnütze Projekt* nochmal in C zu schreiben (ich hätte nicht damit gerechnet) und niemand weiß wie lange Moby gebraucht hat, für die "fehlerfreie"** Version *Beitrag "Re: Assembler wieder auf dem Weg nach vorn" **es wird ja scheinbar unnötigerweise der ganze Speicher initialisiert, aber die wichtigen Sachen nicht.. erst Yalu hat das korrigiert
:
Bearbeitet durch User
Moby A. schrieb: > Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 > Bytes. Warum?
A. K. schrieb: > Moby A. schrieb: >> Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 >> Bytes. > > Warum? Weil Yalu bezüglich Optimierung weiter gedacht hat als Moby, das ist nicht erlaubt!
Moby A. schrieb: > Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das > nehm ich mal als Ansporn! Je schlechter einer ist, desto grösser ist sein Verbesserungspotential. Auf die Steigerungsfähigkeit muss das indes nicht zutreffen. ;-)
Moby A. schrieb: > Vorbehaltlich eines genaueren Funktionsvergleichs (hab nur mal kurz > drübergeschaut) und des Funktionstests auf realer Hardware hat C damit > eine Leistungsfähigkeit im Ressourcenverbrauch demonstriert die mich > beeindruckt hat. Positiv möchte ich außerdem vermerken, daß dazu laut > Listing nicht allzuviele Register verwendet wurden. Schaut also bislang > gut aus. Dieses Eingeständnis möchte ich nach dieser überaus zähen und sich ständig im Kreis drehenden ewigen Diskussion als sehr positiv zu wertendes Ergebnis ansehen.
Speicherverbrauch in Bytes
Mobys ASM Yalus C
——————————————————————————————————
Flash 206 158
SRAM (Stack) 2 2
——————————————————————————————————
Schon gut Moby. Oben stehen die Fakten. Glasklar. Auch dein
unangenehmer, ab vorhersehbarer Versuch, neue Anforderungen
hervorzuzaubern oder Bytes abzuziehen (bei dir) oder hinzuzurechnen (bei
Yalu) ändert daran nichts.
Deine Einlassungen zum Studio sind auch wieder ein Kleinod der
Rabulistik. Gerade wenn man, so wie du, Probleme hat sich ein paar
Konsolenkommandos und Compilerschalter zu merken, ist das Studio im
Vorteil. Es nimmt einem nämlich diese "Bürokratie" ab.
:
Bearbeitet durch User
Jay W. schrieb: > Schon gut Moby. Hey, mach die Diskussion nicht kaputt, in dem Du Moby Dinge vorwirfst, die er mittlerweile selbst eingesehen hat.
Rufus Τ. F. schrieb: > Hey, mach die Diskussion nicht kaputt, in dem Du Moby Dinge vorwirfst, > die er mittlerweile selbst eingesehen hat. Na gut, warten wir den weiteren Verlauf ab. Vielleicht behältst du recht.
Moby A. schrieb: > A. K. schrieb: >> Robert kam beim Studio 6.2 mit >> GCC 4.8.1 auch auf 166 Bytes. > > Auf die komme ich mit Studio7 auch, unter den Projekt-Optionen war bei > AVR/GNU Linker unter General noch ein Häkchen bei "No startup or default > libs (-nostdlib)" zu setzen. Manchmal ist's doch einfacher als man > denkt. > > Diese 166 Bytes sind jetzt für mich maßgeblich und genau die teste ich > auch, es sei denn jemand liefert unter Studio7 noch passendere Optionen. Nur, weil du eine schlechtere Compiler-Version genommen hast als ich? Ich könnte ja andersherum genauso argumentieren, dass ich hier einen ganz schlechten Assembler habe, der nach jedem Befehl automatisch noch einen NOP einfügt. Damit sind bei deinem Code für mich nicht die 216 Bytes, sondern 432 Bytes maßgeblich. In der Spezifikation ist nirgends vorgegeben, welcher C-Compiler zu benutzen ist, d.h. jeder von uns beiden wählt die Tools, die er für richtig hält oder die er auch sonst benutzt. Für mich der GCC 4.7.4 der derzeitige Standard, den ich für alle meine Projekte verwende. Für dich wird er es wahrscheinlich ebenso sein, falls du dich demnächst dazu entschließen solltest, tiefer in C einzusteigen. Im Gegensatz zum IAR-Compiler, der den Code vermutlich noch etwas besser optimiert hätte, ist der GCC sogar frei, so dass du – wie auch jeder andere hier im Forum – die Ergebnisse nachzuvollziehen kannst, ohne dass dir dadurch irgendwelche Kosten entstehen. Aber sei's drum. Da C so viel ressourcensparender als Assembler ist und ich keine Lust auf eine Diskussion darüber habe, werde ich die 8 Bytes eben opfern. Zumal ich stark bezweifle, dass du in der Lage wärst, den GCC 4.7.4 auf deinem PC zu installieren ;-) > Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 > Bytes. Nur weil du nicht auf dieselbe Idee gekommen bist und dein Code deswegen unnötig aufgebläht ist? Ich dachte, hier geht es darum, keine wertvollen Ressourcen zu verschwenden. Wenn du dir das nicht zu Herzen nimmst, ist das doch nicht mein Problem, sondern deins, oder? Aber sei's drum. Da C so viel ressourcensparender als Assembler ist und ich keine Lust auf eine Diskussion darüber habe, werde ich eben auch diese Bytes opfern. Es sind aber nicht nicht 16, sondern 18 Bytes, die ich eingespart habe: Die 10 RJMPs in der Vektortabelle minus 1 RJMP, der nötig ist, um im Initialisierungscode den über in Weg liegenden Interrupthandler zu springen, also 9·2 Bytes = 18 Bytes. Das um die vollständige (wenn auch unnütze) Interruptvektortabelle erweiterte Programm habe ich angehängt. > Mein Code erreicht mit gestrichener Ram- + Sleep-Initialisierung 196 > Bytes. Das Entfernen der RAM-Initialisierung und des Sleeps ist in Ordnung, weil das ja vorher schon so vereinbart war. > Irgendwelche weiteren Grundinitialisierungen lasse ich mir da nicht > zuaddieren weil die in der Praxis ohne Bedeutung sind. Das ist nicht in Ordnung. Warum sollten wir so einen Pfusch zulassen? Außerdem steht in der von dir bestätigten Spezifikation geschrieben: Moby A. schrieb: >> jeder Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2) > > Richtig. Sind die Summenregister anfangs uninitialisiert, ist das aus den ersten 8 ADC-Messwerten jedes Kanals berechnete Ergebnis nicht der Mittelwert, sondern irgendetwas Zufälliges, was ganz klar gegen die Spezifikation verstößt. Ich bestehe deswegen darauf, dass du auch bei dir die Summenregister anfangs auf 0 setzt. Wie du das machst, ist mir egal. In meinem obigen Beitrag habe ich dir ja schon verraten, wie du statt mit 8 zusätzlichen Bytes (für 4 CLRs) auch mit nur 6 Bytes auskommen kannst. Die Codegröße deines gemäß der Spezifikation korrigierten Programms beträgt also 202 Bytes Auf Grund massivster Zugeständnisse meinerseits, die in keiner Weise von der Spezifikation gefordert waren, wächst die Codegröße meines Programms von 158 Bytes auf 184 Bytes Zu weiteren Zugeständnissen bin ich aber definitiv nicht bereit! Diese Ergebnisse 202 Bytes vs. 184 Bytes sind fix. Sie werden nur noch dann geändert, wenn sich herausstellt, dass eines der Programme fehlerhaft ist oder anderweitig nicht der Spezifikation entspricht. Dann wird dieses Programm von seinem Autor korrigiert und die Größe neu bestimmt.
Moby A. schrieb: > Nun sprich mir mal nicht vorschnell Respekt und Anstand ab. Den von Dir > gewünschten Gesichtsverlust eines anonymen Moby wirst Du auch nicht > erleben, immerhin bekam der die Funktionalität in wenigen Bytes mehr > ohne jedes Compiler-KnowHow zusammen Aha. Du gibts also implizit zu, dass es ein Compiler doch besser macht, als der Mensch?
Yalu X. schrieb: > Da auch ich nicht mit leeren Händen zur Party kommen möchte, habe ich > eine C-Portierung von Mobys sensationellem 8-Bit-MSR-Assemblerprogramm > mitgebracht, von der sich jeder, der heute bis 24 Uhr einen Beitrag in > diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D Meine Hochachtung, Yalu!
Jay W. schrieb: > Deine Einlassungen zum Studio sind auch wieder ein Kleinod der > Rabulistik. Welche meinst Du? Jörg W. schrieb: > Dazu täte es einfach not, dass man, statt auf andere Betriebssysteme > zu schimpfen, Wer hat über andere Betriebssysteme geschimpft? Nur weil ich es für ein Unding empfinde, für eine simple C-Compilierung erst ein Linux installieren zu müssen? Robert L. schrieb: > auf die Entwicklungszeit rausreden Nun seht mal nicht alles durch die "Ausreden"-Brille. War ja nur ne Frage. Eine berechtigte allerdings, da mir das Thema Entwicklungszeit ja öfter vorgehalten wurde ;-) A. K. schrieb: > Moby A. schrieb: >> Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182 >> Bytes. > > Warum? Weil mein Code vielleicht seine Vektortabelle auch behalten hat? Nun seht mal nicht alles durch die "Wer gewinnt" Brille. Mich interessierte in erster Linie die Leistungsfähigkeit von C; zu meinem Glück fand sich jemand der dazu in der Lage war es endlich zu demonstrieren. Manch anderer "Experte" hatte ja selbst in Frage gestellt, daß C für Programme dieser Größenordnung und ohne RAM-Verwendung Erfolg beim Ressourcensparen verspricht ;-) So frage ich mich schon, ob nicht doch erheblich mehr KnowHow im Umgang mit C vonnöten ist wenn Yalu's Ergebnis erreicht werden will. Rufus Τ. F. schrieb: > Dieses Eingeständnis möchte ich nach dieser überaus zähen und sich > ständig im Kreis drehenden ewigen Diskussion als sehr positiv zu > wertendes Ergebnis ansehen. So schauts aus. Meine Funktionsprüfung auf Hardware gibt nun grünes Licht: Alles funktioniert wie erwartet. Der Zeitablauf ist etwas gedehnter als bei meinem Code (Das genaue Timing ist nicht gleich, z.B. Sync-Pause 20ms länger- Warum?), aber meine fertige Auswerteroutine kam natürlich auch damit klar. So eine separate Taktleitung hat schon was Gutes ;-) Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER Vielen Dank für Deine Mühe, das Ergebnis hat mich überrascht und hab ich was bei gelernt. Insbesondere finde ich gut, daß Du Dich weitestgehend an die vorgegebene Programmarchitektur gehalten hast, was die Codes gut vergleichbar macht! Etwas Kontra zu Deinen weiteren Erläuterungen wirst Du nun sicher noch vertragen: Yalu X. schrieb: > Als einzige Vorteile von Assembler gegenüber C bleiben also die simple > Codierung und die geringere "Bürokratie". Beide Kriterien lassen sich > aber leider weder klar definieren noch objektiv messen, weswegen sich > bzgl. dieser Punkte am besten jeder sein eigenes Bild macht. Davon rücke auch nicht ab- aber Du hast Recht, das soll jeder für sich entscheiden und es ist nicht notwendig, dies weitere 1000 Beiträge zu diskutieren. > sum.all /= 8; > > zur Berechnung des Mittelwerts meiner Meinung nach nicht nur leichter zu > schreiben, sondern auch besser zu verstehen als ... Natürlich. Auch wenn sich das kryptische in diesem Ausdruck schon andeutet. Daß sich viele Berechnungen so vorhanden in C besser abhandeln lassen hatte ich doch mehrmals betont. > In C ist es aber ein Leichtes, auch die komplette Pinbelegung und die > Taktfrequenz der Datenübertragung konfigurierbar zu machen. Einiges > davon ginge sicher auch in Assembler ... So ist es. Und zwar das was nötig ist. > Das Schöne dabei: Der Compiler ändert bei einer Umkonfiguration ... Solchen Notwendigkeiten bin ich bislang durch vorherige Abklärung der Aufgabenstellung erfolgreich aus dem Weg gegangen ;-) > Bürokratie hat ja etwas mit Verwaltungswahn zu tun. Anders als in C > obliegt in Assembler die Verwaltung der einzelnen Register und des > Datenspeichers komplett dem Programmierer. Das ist das Wenigste. Mit einem Register-System allemal. Dann ist da auch keine "Buchführung" nötig. 32 Register langen schon eine ganze Weile! Größere Datenmengen können ein Fall für den C-Compiler sein. Im SmartHome fallen die weder an einzelnen Aktor/Sensorknoten noch in kleinen lokalen Steuerungen an. > In diese Falle ist trotz ÜVS sogar der Meister höchstpersönlich getappt, > als er eins seiner anderen Miniprogrämmchen schnell mal um ein paar > scheinbar triviale Dinge erweitern wollte, wodurch halt zufälligerweise > einer der hinzugefügten Befehle an ungünstiger Stelle das Carryflag > überschrieb: Ja ja sogar der "Meister"... Meist passiert das nur wenn man mal schnell was fürs Forum fertig macht ;-) 99% der Fehlersuche dreht sich aber nicht um solche Trivialitäten. Hatte ich auch schon mal gesagt. > In höheren Programmiersprachen ist für solche Buchhaltertätigkeiten ganz > klar der Compiler zuständig, der auch bei komplexen Programmen nie den > Überblick verliert. Die sogenannten "Buchhaltertätigkeiten" sorgen aber für Ef....- fast hätt ichs ausgesprochen ;-) OK, sogesehen ein Pluspunkt für C. > weil es einfach > viel zu viel Bürokratie wäre, über das alles im Detail Bescheid wissen > zu müssen Speicherverwaltung ist keine Bürokratie. Die genauen Locations verschiedener Variablen interessieren mich auch nicht, es sein denn, man macht eine RAM Adresse zum Bestandteil des Codes (z.B. bei Erreichen einer bestimmten Pointerposition). Generell muß man das Thema der Hardware-Verwaltung bei AVR nicht so hoch hängen, soviel ist da nicht zu verwalten.
Interessanterweise ist es Moby, der unbedingt auf die Verwendung der 2 Bytes SRAM besteht. Das C Programm käme auch ohne Einschränkung der Funktion locker auch völlig ohne SRAM aus. Nur müsste man dann Mobys Forderungskatalog etwas lockerer interpretieren, indem man zwar die Interrupt-Logik des Timers nutzt, nicht aber die des Prozessors.
A. K. schrieb: > Interessanterweise ist es Moby, der unbedingt auf die Verwendung der 2 > Bytes SRAM besteht. Das C Programm käme auch ohne Einschränkung der > Funktion locker auch völlig ohne SRAM aus. Weniger wäre mir egal gewesen, die Funktion entscheidet. Ohne Verpacken/Kapseln der Funktionalität in einem Interrupt hätte natürlich auch ein Asm-Programm keinen Stack benötigt ;-)
Moby A. schrieb: > Weniger wäre mir egal gewesen, die Funktion entscheidet. Ei gucke da! Inwieweit hätten denn 30 Bytes mehr SRAM und 300 Bytes mehr Flash diese Funktion beeinträchtigt?
A. K. schrieb: > Inwieweit hätten denn 30 Bytes mehr SRAM und 300 Bytes mehr > Flash diese Funktion beeinträchtigt? Eine dumme Frage, A.K. Schließlich ging es um den Vergleich, welche Sprache mit weniger Ressourcen auskommt ;-)
Yalu X. schrieb: > Ich könnte ja andersherum genauso argumentieren, dass ich hier einen > ganz schlechten Assembler habe, der nach jedem Befehl automatisch noch > einen NOP einfügt. Das ist aber jetzt kein elegantes Argument ;-) Ein Assembler übersetzt immer was da steht. Nicht einmal besser oder einmal schlechter.
Moby A. schrieb: > Schließlich ging es um den Vergleich, welche Sprache mit /weniger/ > Ressourcen auskommt ;-) Eben. Die besagte Variante benötigt sogar im RAM weniger Ressourcen. Und nun ist das auf einmal egal?
:
Bearbeitet durch User
Moby A. schrieb: > Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten > von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: > > DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER > > Vielen Dank für Deine Mühe, das Ergebnis hat mich überrascht und hab ich > was bei gelernt. Insbesondere finde ich gut, daß Du Dich weitestgehend > an die vorgegebene Programmarchitektur gehalten hast, was die Codes gut > vergleichbar macht! Mein vorhin schon ausgedrücktes Lob an Moby für diesen Abschluss des Threads sei an dieser Stelle wiederholt.
Moby A. schrieb: > Schließlich ging es um den Vergleich, welche Sprache mit weniger > Ressourcen auskommt ;-) So dumm ist die Frage nicht. Wieviel Prozent belegt das aktuelle Programm von den *sowieso vorhandenen* Ressourcen? Was geschieht mit dem vielen unbenutzten Ressourcen? Welche möglichen Erweiterungen würde in diesem Fall denn Sinn machen? Wieviel Zeit hast Du in die Entwicklung des asm und Yalu in die Entwicklung gesteckt? Auch das sind Ressourcen.
Yalu X. schrieb: > Sind die Summenregister anfangs uninitialisiert, ist das aus den ersten > 8 ADC-Messwerten jedes Kanals berechnete Ergebnis nicht der Mittelwert, > sondern irgendetwas Zufälliges, was ganz klar gegen die Spezifikation > verstößt. > > Ich bestehe deswegen darauf, Darüber wollen wir nicht streiten. In der Theorie hast Du Recht, für meine Praxis ist das unbedeutend. > Zumal ich stark bezweifle, dass du in der Lage wärst, den GCC 4.7.4 auf > deinem PC zu installieren ;-) Wenn ich das nicht schaffen würde dann sicher eine Menge mehr. Kein Argument für C ;-) > Nur weil du nicht auf dieselbe Idee gekommen bist und dein Code deswegen > unnötig aufgebläht ist? Diese sogenannte "Idee" wurde schon in meinem Projektthread angesprochen. Was bereits da steht lädt gleich zur Erweiterung ein ;-) > Zu weiteren Zugeständnissen bin ich aber definitiv nicht bereit! Entspann Dich bitte, Mod Yalu. Der Fight der Systeme ist vorbei ;-) Matthias L. schrieb: > Wieviel Zeit hast Du in die Entwicklung des asm und Yalu in die > Entwicklung gesteckt? Auch das sind Ressourcen. Darauf werden wir hier keine erschöpfende nachprüfbare Auskunft mehr bekommen... Mein Code entstand bereits im September. An einem Nachmittag ;-)
:
Bearbeitet durch User
Moby A. schrieb: > So frage ich mich schon, ob nicht doch erheblich mehr KnowHow im Umgang > mit C vonnöten ist wenn Yalu's Ergebnis erreicht werden will. Es hätte wohl normalerweise niemand so als Projekt angefangen. Wenn es mein Projekt wäre, hätte ich: 1) Einen ATtiny25 genommen, wegen der USI, die einem bei der seriellen Kommunikation einen Großteil der Arbeit abnimmt. Hätte außerdem den Vorteil, dass der dortige ADC in der Lage ist, die Versorgungsspannung zu messen, ohne dass man externe Hardware braucht (indem man Vref gegen Vcc als Referenz misst). So kann man noch ein Flag mit durchreichen, dass die Batterie gewechselt werden muss. Ernsthaft mehr Geld kostet das Ding ja sowieso nicht. 2) Die Daten an Bytegrenzen ausgerichtet. Das macht die Sache ringsum viel einfacher, auch wenn man ein paar Bits verschwendet bei der Übertragung, weil man für 10 Bit Analogwert 2 Byte braucht. 3) Eine ordentliche CRC benutzt, mindestens eine 8-Bit-CRC. Da haben Generationen von Ingenieuren einfach schon genug Gedanken reingesteckt, wie man Übertragungsfehler möglichst sicher erkennt, das muss ich nicht ignorieren. Konkreter RAM- und Flash-Verbrauch wäre ohnehin egal, solange alles mit ausreichend Reserve (für Erweiterungen, wobei mehr als 50 % bei beiden auf jeden Fall als „ausreichend“ genügt) in den ATtiny25 passt. Mit diesen Prämissen hätte man das wohl problemlos an einem Abend umgesetzt, einschließlich Funktionstest. Meine Hochachtung an Yalu für seine erwiesene Geduld!
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Wenn es mein Projekt wäre, hätte ich: > Eine vernüftiges (fertig entwickeltes) Protokol benutzt, das nicht für jeden Sensor 2 PortPins benutzt. Bei der geforderten Bitrate hätte OneWire auf einen PortPin einige zig Temperaturen messen. Bei Bedarf kann man einen Slave auch in einen ATtiny13 pressen (in C): https://www.tm3d.de/index.php/1-wire-device-mit-avr Und damit könnte man alles was das Moby-Board macht auch tun. Nur eben z.B. direkt an Raspberry anschließbar, Software eingeschlossen. Ja, der Link hat natürlich keine fertige .HEX für M.'s Anforderungen und auf dem Tiny13 ist etwas zu wenig Platz für alle Busfunktionen. Ab Tiny25 ist das dann aber ein vollwertiges OneWire-Device. Und für Temperatur einfach mal einen Ds18b20 an den Bus klemmen ist dann auch drin.
Moby A. schrieb: > Alles funktioniert wie erwartet. Juhu! :) > Der Zeitablauf ist etwas gedehnter als bei meinem Code In meinem Programm wird OCR0A so gesetzt, dass bei der nominellen Oszillatorfrequenz (128 kHz) das Timing exakt stimmt:
1 | OCR0A = 128000 / 64 / 200 - 1 = 9 |
Du hingegen hast OCR0A auf 7 gesetzt, um die Abweichung der tatsächlichen von der nominellen Oszillatorfrequenz auszugleichen. Wenn du die tatsächliche Frequenz kennst und du sie in Zeile 16
1 | #define F_CPU 128000
|
einträgst, berechnet der Compiler automatisch den optimalen Wert für OCR0, und das Timing sollte dann ziemlich genau stimmen. Da jedoch die prozentuale Auflösung des OCR0A-Werts in diesem Bereich recht schlecht ist (es macht einen großen Unterschied, ob man bspw. 9 oder 8 einträgt), kann das Timing immer noch ungenau sein. Aber warum nimmst du statt dem 64:1-Vorteilers nicht einfach den 8:1-Vorteiler (CS2=0, CS1=1, CS0=0)? Dann ist für die Nominalfrequenz OCR0A=79, und die Interruptfrequenz kann in viel feineren Schritten eingestellt werden. Hier sind die entsprechenden Änderungen im Programm (
1 | // OCR0A = (uint8_t)((double)F_CPU / 64 / (2 * F_DATA) + 0.5)-1;
|
2 | OCR0A = (uint8_t)((double)F_CPU / 8 / (2 * F_DATA) + 0.5)-1; |
3 | ^
|
4 | ...
|
5 | // TCCR0B = 1<<CS00 | 1<<CS01;
|
6 | TCCR0B = 0<<CS00 | 1<<CS01; |
7 | ^
|
Wenn du jetzt noch in Zeile 16 die richtige Oszillatorfrequenz einträgst, ist das Timing genauer als ±0,7%. Bei meinem Tiny beträgt die Oszillatorfrequenz fast exakt 120 kHz. Wenn ich diesen Wert ins Programm eintrage und den Vorteiler wie beschrieben auf 8:1 einstelle, messe ich mit dem Oszi einen Datentakt von 100,2 Hz (ideal wären 100,0 Hz). Was will man mehr? Man muss es mit der Kalibrierung aber auch nicht übertreiben, denn die RC-Oszillatorfrequenz ist stark abhängig von der Temperatur und der Versorgungsspannung. > (Das genaue Timing ist nicht gleich, z.B. Sync-Pause 20ms länger- > Warum?) Siehe oben. Außerdem musst du berücksichtigen, dass die Sync-Pause, gemessen von der letzten fallenden Taktflanke vor der Pause bis zur ersten steigende Taktflanke nach der Pause nicht 80 ms, sondern 85 ms betragen muss, da zu den 80 ms Pause ja noch die Low-Phase des letzten Takts (5 ms) hinzukommt.. Moby A. schrieb: > Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten > von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: > > DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER Jetzt bleibt mir aber wirklich die Spucke weg ... Wenn ich ganz ehrlich bin, hätte ich nicht erwartet, dass wir uns in diesem Punkt irgendwann in den nächsten 1000 Jahren einig werden ;-) Offensichtlich bist du doch nicht ganz so sehr der absolut unverrückbare tonnenschwere Betonklotz, für den ich dich gehalten habe. Daumen hoch!
Moby A. schrieb: > Der Fight der Systeme ist vorbei ;-) Es hat nie einen "Fight der Systeme" gegeben. Es hat nur einen Moby gegeben, der stur nicht glauben wollte, was andere schon längst wissen.
Yalu X. schrieb: > Moby A. schrieb: >> Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten >> von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: >> >> DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER Ja Moby, das Ergebnis war zu erwarten. Der Kompiler kann beim Compilieren das gesamte Programm optimieren. Du immer nur Deine vorgefertigten Blöcke. Vielleicht macht es ja Sinn, das Du Dir C doch mal in Ruhe ansiehst?
Ich meine, ich hätte den folgenden Beitrag heute Nachmittag schon abgeschickt, habe aber wohl vergessen, auf den "Absenden"-Knopf zu drücken: Moby A. schrieb: > Vielleicht möchte sich Mod Yalu ja noch dazu äußern, wielang er dran > gefeilt hat? Die Grundversion des C-Programms mit der geforderten Funktionalität hat mich eine gute halbe Stunde gekostet. Diese Version hat allerdings noch RAM für Variablen und die Sicherung von Registern im Interrupthandler benötigt. Zudem war darin noch der Startup-Code der C-Bibliothek enthalten, der mehr tut als im konkreten Fall gefordert und deswegen etwas mehr Flash belegt, als unbedingt nötig. Trotzdem wäre in einem realen Projekt die Softwareentwicklung an dieser Stelle weitgehend abgeschlossen gewesen, da alle Funktionen vollständig implementiert waren, und man wäre direkt zur Testphase übrgegangen. Aber hier ging es ja nicht primär darum, eine lauffähige Anwendung zu entwickeln, sondern deine unsinnigen Zusatzanforderung nach fast völligem Verzicht auf die RAM-Nutzung zu erfüllen. Ich musste nun also versuchen, - sämtliche Variablen (insbesondere auch die globalen) in Register zu bringen, - die in diesem Fall überflüssigen PUSHs und POPs im Interrupthandler zu vermeiden, - den Compiler/Linker dazu zu bringen, den Startup-Code wegzulassen und - diejenigen Teile aus dem Startup-Code, die man trotzdem benötigt, in C nachzuprogrammieren. Das sind alles Dinge, die niemand auf der Welt (außer dir natürlich) tut, weil sie völlig unsinnig sind. Entsprechend findet man im Netz auch kein Howto, in dem das alles in zusammengefasster Form und ready-to-use beschrieben wird. Da ich selber so etwas auch noch nie gemacht habe, musste ich mir die notwendigen Informationen also mühevoll aus mehreren Einzelquellen zusammentragen und immer wieder testen, ob die gewonnenen Erkenntnisse vom Compiler und Linker auch wirklich so umgesetzt werden, wie ich mir das vorgestellt hatte. Das hat etliche Stunden gedauert. So genau weiß ich das nicht, weil ich nicht auf die Uhr geschaut und zwischendurch immer wieder andere Dinge (wie Essen, Einkaufen usw.) getan habe. Schließlich habe ich noch einen kleinen Testaufbau mit dem ATtiny13 zusammengesteckt, um zu sehen, ob die Ausgangssignale bzgl. Timing und den Dateninhalten stimmen. Um die Ausgabe mit der deines Programms vergleichen zu können, habe ich auch dieses auf den Controller geladen und die Signale auf dem Oszi angeschaut. Da ich kein Atmel-Studio habe, musste ich dazu deinen Quellcode erst einmal in die GNU-Assemblersyntax, die von der Atmel-Syntax etwas abweicht, übersetzen. Das hat einschließlich einiger kleiner Fehlerkorrekturen zusammen weitere zwei Stunden gedauert. Die mit Abstand meiste Zeit nahm somit der Wissenserwerb für die "RAM-freie" Programmierung in C in Anspruch. Ich betrachte das mal als persönliche Fortbildungsmaßnahme, die für mich vielleicht irgendwann mal wieder von Nutzen sein wird (auch wenn ich das eher bezweifle ;-)). Auf jeden Fall bin ich jetzt mehr denn je davon beeindruckt, welche Möglichkeiten der GCC für das gezielte Abspecken von Programmcode bietet. Noch vor ein paar Tagen hätte ich es für unwahrscheinlich gehalten, dass man mit dem GCC das Eckmannsche Programm erzeugen kann:
1 | ; Programmanfang an Adresse 0 |
2 | sbi DDRB,1 |
3 | sbi PINB,1 |
4 | ; Programm läuft im unprogrammierten Flash weiter und wird |
5 | ; wiederholt, wenn der Programmzähler am Flash-Ende überläuft |
(Quelle: Beitrag "Re: Assembler wieder auf dem Weg nach vorn") Jetzt weiß ich aber, dass es geht :) Und wenn mal erst einmal gelernt hat, wie diese Fähigkeiten des GCC zu nutzen sind, schreibt man extrem ressourcensparende Programme fast mit der gleichen Leichtigkeit wie gewöhnliche C-Programme, auf jeden Fall aber in viel kürzerer Zeit als mit Assemblerprogrammierung. Wenn wir jetzt – wie damals von Karl Heinz vorgeschlagen – einen Wettbewerb veranstalten würden, bei dem jeder von uns in limitierter Zeit eine vorgegebene µC-Anwendung realisiert und am Ende neben der Fehlerfreiheit der Ressourcenverbrauch bewertet wird, würdest du mit deiner ASM-Programmiererei vermutlich sehr schlecht aussehen :) Bei einer nichttrivialen Anwendung (>> 1KB), zu der dich Karl Heinz herausgefordert hatte, hättest du sowieso keine Chance, aber auch bei einem Mickymaus-Programm, vergleichbar mit dem deines Sensorboards, würde ich dich dank der Produktivität von C und der Fähigkeiten des GCC, kompakten Code zu generieren, ganz sicher schlagen :D Aber das ist inzwischen Schnee von gestern, da du jetzt ja ganz groß in die C-Programmierung einsteigen wirst und damit künftig genauso schnell ressourcensparenden Code entwickeln wirst wie alle anderen. Deswegen ist jetzt schon klar, dass der Wettbewerb nur mit einem Remis enden kann :) Bewundern wir stattdessen lieber den gewaltigen Sprung nach oben, den C in der nächsten Ausgabe des Tiobe-Index machen wird :)
Yalu X. schrieb: > das Eckmannsche Programm ... find ich geil! Klingt fast wie 'Eulersche Zahl' oder 'Satz des Thales' :-)
Yalu X. schrieb: > da du jetzt ja ganz groß in > die C-Programmierung einsteigen wirst Dazu wiegt > der absolut unverrückbare > tonnenschwere Betonklotz jahrelanger Asm-Praxis zu schwer ;-) Du hast Dir aber redlich Mühe gegeben mir einen neuen Weg zu bahnen (mit viel Ressourcenspar-Häppchen als Lockmittel), aber soweit liegen Dein jahrelang erfahrener Profi-C Code und mein 0815 Code im Ergebnis nun auch nicht auseinander, daß für mich die Gegenrichtung Moby A. schrieb: > Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das > nehm ich mal als Ansporn! nicht in Frage käme. Schließlich liefert ja jeder Compiler auch nur Asm-Output ;-) Daß Du meinen Asm Code hier zuweilen korrigiert hast ist doch auch ein Angebot... Außerdem bleibe ich bei Moby A. schrieb: > Das schlimmste ist die unnötige Bürokratie. > Dieser hochgradig umständliche Aufwand. > Das würde ich von der Priorität her fast noch über den gesteigerten > Ressourcenbedarf setzen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > nicht in Frage käme. Schließlich liefert ja jeder Compiler auch nur > Asm-Output ;-) Meist Maschinencode.
Moby A. schrieb: > Moby A. schrieb: >> Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das >> nehm ich mal als Ansporn! Nope, genau da liegst du falsch und das versuchen wir dir auch seit rund 2000 Beiträgen zu erklären: Ein Compiler kann Optimierungen machen, die ein Mensch nicht mehr überblicken kann. Das wahre Optimierungspotential liegt nicht bei ein paar kunstvollen Assembler-Kniffen, sondern beim sturen Durchrechnen der Resourcenbelegung, z.B. Cache- oder Registerzuweisung. Und selbst wenn die kunstvollen Assembler-Kniffe etwas bringen: Die kennt und nutzt der Compiler sowieso. Moby, es gibt einfach wirklich nichts, ausser: (a) Ausbildungs-/Spasszwecken (b) Wenn die Instruktionssequenz aus einem ganz konkreten Grund von Hand vorgegeben muss, z.B. "Takte zählen". (c) Bibliotheksfunktionen, die ganz spezifische Hardware-Eigenschaften nutzen soll oder Code-Snippets für die Verwendung innerhalb von Compilern Für generelle Anwendungsentwicklung ohne sehr konkreten Optimierungsdruck ist C um Welten geeigneter.
Ralf G. schrieb: > ... find ich geil! Klingt fast wie 'Eulersche Zahl' oder 'Satz des > Thales' Für so ein legendäres Programm... Ich bin gespannt, wann die Arduino-Fraktion sich daran versucht und der Bootloader sie in den Wahnsinn treibt. mfg.
Moby A. schrieb: > aber soweit liegen Dein > jahrelang erfahrener Profi-C Code und mein 0815 Code im Ergebnis nun > auch nicht auseinander, daß für mich die Gegenrichtung > [...] > nicht in Frage käme. Schließlich liefert ja jeder Compiler auch nur > Asm-Output ;-) War ja klar, dass Du die Unterschiede nun herunterspielst. Ich verstehe nur nicht, warum Du in hunderten von Beiträgen vorher so einen Aufstand geübt und einen so großen Bohei drum gemacht hast. Dass C und ASM sich bei einem Mini-Progrämmchen nicht groß unterscheiden, war von vornherein klar. Egal, ob jetzt C oder ASM bei 200 Byte Code die Nase vorn hat: der Unterschied ist marginal. Das sagst Du ja nun selber. Die eigentlichen Stärken spielt der C-Compiler nämlich erst bei größeren Projekten aus. Dann ist es in jedem Fall wurscht, ob Interruptvektor-Tabellen drin sind oder ob man RAM benutzt. Das kann dann der Compiler wesentlich besser entscheiden als der Mensch. Yalus Klimmzüge bzgl. Mobyischer Einsparungen kann man sich dann schenken und Deine ganzen Argumente bzgl. Ressourcen-Einsparung lösen sich bei C in Luft auf. Der C-Programmierer kann sich voll der eigentlichen Programmier-Aufgabe widmen, der ASM-Programmierer jedoch muss weiterhin all seine Register, Calling Conventions und andere Fallen immer im Auge behalten. Der ASM-Programmierer ist daher doppelt belastet: Er muss sich neben der eigentlichen Programmieraufgabe zusätzlich noch permanent um sein "Werkzeug" kümmern. Bleib ruhig bei ASM. Steht Dir auch besser. P.S. Wegen Deinem permanenten nervösen Augenzwinkern solltest Du mal zum Arzt gehen. ;-)
:
Bearbeitet durch Moderator
Kaum ist man mal ein absoluter Resourcenverschwender (ich habe die
Resource Freizeit am Wochenende mit meiner Freundin auf dem
Weihnachtsmarkt am Bodensee maßlos verschwendet),
schon taucht ein extrem resourcensparendes ce ("C") Programm auf
(welches ich so nicht gedacht hatte dass es - der Unnötigkeit wegen -
gemacht wird):
Yalu hat es bewiesen und deshalb gilt meine absolute Hochachtung Yalu !
Im Übrigen läßt sich Yalus Programm auch mit der AVR-GCC Version 4.8.1
übersetzen (was ich allerdings so dann auch erwartet habe).
Absolute Hochachtung für Yalu !!!
Das "tricky" Hacking für "main1" "main2" und "main3" werde ich mir doch
tatsächlich einmal zu Gemüte führen (weil, auch wenn ich glaube dass das
unnötig ist, ich gerne lernen mag, was da denn ganz genau passiert).
Respekt !
Ich möchte Yalu auf jeden Fall auch noch meinen Respekt zollen. Ich programmiere schon eine ganze Zeit in c, seltener in asm. Auch beruflich. Dabei bin ich nicht erfolglos, gehöre aber sicher auch nicht zu den allerhellsten Kerzen in der Branche.... Ich finde das ist schon eine wirklich beachtliche Leistung was du gemacht hast. Yalu hat schön gezeigt, was alles Motivation sein kann, Neues zu machen und eine Herausforderung zu lösen. Ein so oft gehörtes Phrasenargument bezüglich asm und c ist ja, dass man in Assembler genau weiß, was der Prozessor gerade macht, keinen Takt verschwendet, jedes Bit gesetzt hat, genau den Überblick über Register etc. pp hat. das ist vermutlich ein Relikt, was sich vor über 30 Jahren gebildet hat und viel zu oft einfach nachgeblökt wird. Es wäre schön, wenn das Ergebnis des Threads helfen könnte, dieses (zumindest von Moby) nicht mehr immer zu hören. Moby, du musst dir halt auch eingestehen, dass du genau DAS in 2000 Posts und vielen Threads gemacht hast: deinen asm Code als den perfekten bitoptimierten Code angepriesen, der deshalb von etwas geschwätzigen wie c nicht "geschlagen" werden kann. Hat sich erledigt. Hast du ja auch auf deine Art gewürdigt. Das Assembler, wie gesagt, im Hobby einfach seiner selbst willen mal Spaß machen kann ist damit nicht widerlegt. Portabel und wie ich meine Praxisrelevant ist die c-Lösung ja nun auch nicht. Ich kann auch verstehen, dass der Einstiegswiderstand bzgl. c groß ist. ABER: es haben dir ja auch echt viele Leute in dem Thread soooo oft versucht rüberzubringen und dich dahingehend zum nachdenken zu bewegen, dass dein Sensor in c genauso gut funktionieren würde, wenn 50 Byte mehr flash und paar Byte ram verbraucht würden. Kein bischen schlechter. Nicht mal weniger erweiterbar - eher mehr. Von daher würde ich es einfach mal wagen, immer auch ein c Projekt anzugehen. Die Moderatoren und einige andere haben hier ja wirklich lange und sachlich diskutiert; die werden sicher auch bei c Fragen helfen. Btw. der c-thread den du mal zitiert hast ist ein Beispiel für etwas was mich auch regelmäßig wundert bis verstört (vielleicht hast du den Link zur Hand). Nämlich das Verhalten von dem gcc. Dabei ging es ja um einen expliziten unsigned-cast, der dem compiler erheblich unter die Arme greift. So wirklich verstehen, warum der nicht selber auf die Idee kommt, wenn ich ja z.B. ein Rechenergebnis einem unsigned Register zuweise tue ich nicht. Aber(!) das ist ja auch wirklich fast immer nicht so dramatisch. Wenn das Programm und die Ressourchenaufteilung wohl überlegt ist, bringt eine Berechnung mit 3 Takten mehr meistens keinen Beinbruch. Bei manchen anderen ist hier direkt wieder der Reflex zum nachtreten zu sehen. Meine Güte: seid Männer! Hier ist kein Schulhof wo gilt: einmal Arsch, immer Arsch. Man kann sich auch streiten und dann in die Kneipe zurückziehen. Sollte man jedenfalls versuchen. Leider weiß ich für mich persönlich jetzt IMMER noch nicht, ob der Moby-Member in Wirklichkeit auch so borniert sein kann, oder ob das eine Menge Selbstdisziplin gefordert hat. ;-) So und mit der Smiley ist doch ein guter Punkt, sich aus dem Thread auszuklinken. Wie schön. Endlich quasi-Konsens. Warum quasi? Das seht ihr in den nächsten 500 Posts.
Clemens M. schrieb: > Btw. der c-thread den du mal zitiert hast ist ein Beispiel für etwas was > mich auch regelmäßig wundert bis verstört (vielleicht hast du den Link > zur Hand). Nämlich das Verhalten von dem gcc. Dabei ging es ja um einen > expliziten unsigned-cast, der dem compiler erheblich unter die Arme > greift. So wirklich verstehen, warum der nicht selber auf die Idee > kommt, wenn ich ja z.B. ein Rechenergebnis einem unsigned Register > zuweise tue ich nicht. Eine einfache Erklärung - ohne in Details zu gehen: In C werden Berechnungen standardmäßig in Integer (int) durchgeführt. Das Problem beim Schieben eines Wertes nach links bzw. rechts ist, dass das Vorzeichen (MSB) dabei immer erhalten bleiben muss. Bei unsigned-Werten, wo das keine Rolle spielt, muss man dem Compiler das dann explizit sagen, denn auf den Typ der Zielvariablen kommts nicht an - vielmehr auf den Typ der Operanden.
Meine Hochachtung gilt Moby: > Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten > von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn: > > DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER Das zu schreiben war nach diesem Riesenthread sicher nicht einfach! Für mich steckt die Herausforderung beim Programmieren auch ganz wesentlich in der Konfrontation mit eigenen Fehlern, die unausweichlich in jedem Programm stecken. Nur wer diese erkennt, findet den Bug oder die bessere Lösung beim Refactoring oder dem nächsten Design. Moby, ich denke, hier können Dich mehr verstehen, als Du glaubst. Lange Zeit war meine Einstellung zu C-Compilern ähnlich wie Deine. Früher war der ASM-Output des Compilers deutlich schlechter als handoptimierter Assembler, auch noch bei den ersten gcc-Versionen für den AVR. Aber die Compiler werden immer besser, das Ergebnis hat uns Yalu gezeigt. Früher haben die Schachgroßmeister die Maschine als Konkurrenten gesehen, heute werden sie als Hilfestellung benutzt, um komplexe Lösungen besser zu finden und zu verstehen. Dieser Weg ist auch für uns Programmierer der Richtige. Gruß, Stefan
:
Bearbeitet durch User
Klar, Frank. Das ist mir soweit natürlich bewusst. Ich tendiere wie es aussieht dazu, einem Compiler eben zu viel anstatt zu wenig zu zutrauen und daher habe ich das öfter einfach ausgeblendet. Von daher war der oben genannte thread für mich persönlich gut. Wenn ich mich in Zukunft wundere, warum ein Code ungewöhnlich aussieht, habe ich die Problematik in meinem aktiven Hirn.
Clemens M. schrieb: > Ich tendiere wie es > aussieht dazu, einem Compiler eben zu viel anstatt zu wenig zu zutrauen > und daher habe ich das öfter einfach ausgeblendet. Ja, mich stört es auch, dass man immer wieder daran denken muss. Es gibt andere Sprachen (z.B. Java), in denen man einen "unsigned shift" durch drei Größer-Zeichen - also '>>>' - explizit angeben kann. Schade, dass das in C nicht geht. Ich würde nämlich dann immer '>>>' statt '>>' verwenden, da man einen Shift mit Vorzeichen-Wahrung eher selten braucht.
:
Bearbeitet durch Moderator
Ich glaube, Moby hat einfach ein Problem / Abneigung gegen die Begriffe "Algorithmen" und "Datenstrukturen". Komplexere Algorithmen als nur ein paar Bit-Schubsereien und deutlich komplexere Datenstrukturen als die eines digitalen 8-bit-Eingangs/Ausgangsports sind nun mal das Grundgerüst der meisten heutigen Systeme (nicht nur von Magnetfeld-Steuerungen von Teilchenbeschleunigern, auch "einfachere" Steuerungen - z.B. Quadkopter-Steuerung). Sowas läßt sich halt nur vernünftig in einer abstrahierenden Programmiersprache darstellen, bei der man sich um das klein-klein einzelner Registerbelegungen keinen Kopf mehr zu machen braucht.
Selbst wenn man Yalus 'hackish' Tricks weglässt und per Copy&Paste einfach in AVR Studio 4 'sensorboard.c' kompiliert, ist es immer noch kleiner als der ASM Kram:
1 | Build started 21.12.2015 at 09:52:14 |
2 | avr-gcc -mmcu=attiny13 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT sensorboard.o -MF dep/sensorboard.o.d -c ../sensorboard.c |
3 | avr-gcc -mmcu=attiny13 -Wl,-Map=sensorboard.map sensorboard.o -o sensorboard.elf |
4 | avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature sensorboard.elf sensorboard.hex |
5 | avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex sensorboard.elf sensorboard.eep || exit 0 |
6 | avr-objdump -h -S sensorboard.elf > sensorboard.lss |
7 | |
8 | AVR Memory Usage |
9 | ---------------- |
10 | Device: attiny13 |
11 | |
12 | Program: 184 bytes (18.0% Full) |
13 | (.text + .data + .bootloader) |
14 | |
15 | Data: 0 bytes (0.0% Full) |
16 | (.data + .bss + .noinit) |
17 | |
18 | |
19 | Build succeeded with 0 Warnings... |
Ralph S. schrieb: > Das "tricky" Hacking für "main1" "main2" und "main3" werde ich mir doch > tatsächlich einmal zu Gemüte führen (weil, auch wenn ich glaube dass das > unnötig ist, ich gerne lernen mag, was da denn ganz genau passiert). Geht mir auch so, ich habs fürs Kompilieren erstmal auskommentiert und aus 'void main3(void)' einfach mal 'int main(void) gemacht - sonst will Studio 4 nicht.
:
Bearbeitet durch User
Matthias S. schrieb: > sonst will Studio 4 nicht Das hat weniger mit Studio 4 zu tun als eher mit dem alten avr-gcc von 2010. Hier eine Kurzanleitung, wie man auch neuere avr-gcc mit Studio 4 nutzen kann: Beitrag "Re: avr-gcc 4.7 für Atmel Studio 4 Windows" Ich persönlich nutze avr-gcc 4.7.2. Für Windows gibts den hier: http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/
Frank M. schrieb: > Hier eine Kurzanleitung, wie man auch neuere avr-gcc mit Studio 4 nutzen > kann: > > Beitrag "Re: avr-gcc 4.7 für Atmel Studio 4 Windows" Das ist sehr nett von dir, aber wie man sieht, ist jegliche Trickserei ja gar nicht nötig und ich persönlich bin mit dem 'normalen' Startup der gcc Kompiler sehr zufrieden. Ich habe auch festgestellt, das es für gesparte Bytes im Flash ja gar kein Geld zurückgibt :-) Wimre habe ich hier sogar noch WinAVR von 2010 laufen, das wäre GCC 4.3.3. Würde ich was neueres brauchen für neue MC, dann lasse ich AVR Studio 4 so wie es ist und kippe Atmel Studio 7 oder so mit auf den Rechner.
Jetzt müsste man nur noch klären ob ASM tatsächlich "einfach und selbsterklärend" ist .. @moby avr: hast du anhand dieses selbsterklärenden ASM Code schon festgestellt was der GCC jetzt besser gemacht hat als du? Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Matthias S. schrieb: > Das ist sehr nett von dir, aber wie man sieht, ist jegliche Trickserei > ja gar nicht nötig und ich persönlich bin mit dem 'normalen' Startup der > gcc Kompiler sehr zufrieden. Es gibt aber durchaus noch andere Verbesserungen, z.B. LTO-Support und den neuen Typ "__flash" vs. PROGMEM. Ausserdem ist der Compiler-Output auch ohne Tricksereien besser als der vom avr-gcc 4.3.3.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Auch __int24 und __uint24 kamen m.W. erst mit GCC 4.7. Ja, die sind Kollateralnutzen von __memx, das ja eh 24-Bit Arithmetik braucht. Mit wenig Mehraufwand (z.B. Division, die für Zeigerarithmetik nicht notwendig ist) waren also 24-Bit Typen zu haben.
Moby A. schrieb im Beitrag #4644241:
> http://m.heise.de/newsticker/meldung/Programmiersp...
Geht das jetzt wieder los?
Egal, ob Platz 10 oder Platz 99: 2,28% sind einfach nicht der Rede wert.
Meinetwegen kann dieser Thread dichtgemacht werden.
Logisch. Heute kam grad eine Meldung, dass der Quellcode des Apollo Guidance Compilers veröffentlicht wurde. Der ist auch in Assembler. Soviel Quellcode auf einem Haufen...
A. K. schrieb: > Logisch. Heute kam grad eine Meldung, dass der Quellcode des > Apollo > Guidance Compilers veröffentlicht wurde. Der ist auch in Assembler. Klasse. Gibts auch einen Weg, den Counter von "Assembler" wieder zu drücken? Vielleicht durchstreichen: ̶A̶̶s̶̶s̶̶e̶̶m̶̶b̶̶l̶̶e̶̶r̶
:
Bearbeitet durch Moderator
So also mal wieder in einem Alten vergessenen Thread Rum-stochern :D Egal was die Ststitik sagt, egal was da geschrieben wird. Wen ein Neuer Prozessor entwickelt wird, ist das erste wass es Gibt Maschienensprache bzw Assembler. es gibt nur sehr wenige Prozessoren "die von Hause aus" eine Hochsprache verstehen (bsw. Tynibasic). Das heißt Assembler muss auch heute noch Programmiert werden. Unsere Firma bsw programmiert NUR in Assembler, den wir stellen Geräte her an denen Menschenleben hängen, und eine Hochsprache kan unkontrollierte Fehler machen, bsw. Stackoverflow usw. Im weiteren ist eine Hochsprache nie so Hardware nah wie Assembler, den da muss man den uC verstehen. Eine Hochsprache die in einer Hochsprache geschrieben ist ist ja auch nicht das gelbe vom Ei?!? Warum bloss macht auch C++ zuerst Assemblercode ?!? Hmmmm.... Warum schlägt ihr euch gegenseitig fast die Köpe ein ob oder ob nicht? Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir suchen Permanent gute Assembler (und hin und wieder auch C++ & Co) Programmierer] und keiner Geschaft. Aber Unsere Assembler Programmierer tun das und packen auch noch eine Sensorsteuer- und Regel-Software mit rein! Da es immer wieder Neue Prozessoren gibt, wird auch Assembler und Maschinensprache nie aussterben, sonst würden auch keine Kinder mehr auf die Welt kommen die Zuerst in die Schule müssen. Assembler ist die Sprache des Prozessors, und es ist immer besser die Direkte Sprache zu sprechen als sie zuerst von "etwas" übersetzen lassen. Oder Versucht mal im Google Sprache x in Y zu übersetzen was Kommt raus? ...EBEN.. und das obwohl Millionen dafür ausgegeben werden es zu Perfektionieren. und auch genau so verhält es sich bei den Hochsprachen für uC die Compiler oder gar Interpreter sind nie Perfekt. Und ja Windows wurde ja hier im Thread auch angesprochen, Stimmt ist vollständig in mehreren Hochsprachen geschrieben.(ja nicht nur in einer das sieht man deutlich, wenn man den Quellcode analysiert). Und was ist das Resultat? Windows ist "Launisch", Instabil und wird nicht für Livesupport (Geräte an denen Leben hängen) zugelassen....hmmm warum wohl?..... Die Meinung bei uns in der Firma (und übrigens auch bei FDA) ist klar Livesupport, Assembler Only..... So Sorry wenn ich jemandem auf den Slips getreten bin, aber bin auf den Thread aufmerksam geworden weil ich doch Tatsächlich "Assembler" bei Google eingegeben habe, nicht weil ich Software suche, sondern weil bei uns im Betrieb ein Assemblerprogrammierer in Pension geht und wir wieder einen suchen :-D ........
Patrick L. schrieb: > Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache > zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu > kriegen Beitrag "Re: Assembler wieder auf dem Weg nach vorn" q.e.d. schon vor knapp einem Jahr, der Compiler ist vermutlich nur noch besser geworden, der Mensch bleibt bei 1.0 Lies zur Sicherheit auch die anderen 2k Beiträge durch.
Patrick L. schrieb: > Wen ein Neuer Prozessor entwickelt wird, ist das erste wass es Gibt > Maschienensprache bzw Assembler. Und zwar Testcases um den Prozessor zu debuggen. Parallel dazu entsteht ein C Compiler, auf Fremdhardware entwickelt, weil man ohne den keinen Prozessor mehr auf den Markt bringen kann, wenn man auf Stückzahlen Wert legt.
Patrick L. schrieb: > Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache > zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu > kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir > suchen Permanent gute Assembler (und hin und wieder auch C++ & Co) > Programmierer] und keiner Geschaft. Dein Problem mit Hochsprachen scheint sich nicht nur auf C zu beschränken.
Gu. F. schrieb: > Patrick L. schrieb: >> Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache >> zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu >> kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir >> suchen Permanent gute Assembler (und hin und wieder auch C++ & Co) >> Programmierer] und keiner Geschaft. > > Dein Problem mit Hochsprachen scheint sich nicht nur auf C zu > beschränken. Und wie verzweifelt müssen die Leute dort sein, die einen TCP/IP Stack in Assembler programmieren? Das ist das Äquivalent zum Steine klopfen im Zuchthaus. Und das wo ordentliche Controller mit genug Speichern für eine ordentliches SW-Entwicklung nichts mehr kosten. Höchstrafe!
@Operator S. Hallo danke für deinen Interessanten Beitrag :) Operator S. schrieb: > q.e.d. schon vor knapp einem Jahr, der Compiler ist vermutlich nur noch > besser geworden, der Mensch bleibt bei 1.0 > > Lies zur Sicherheit auch die anderen 2k Beiträge durch. Ja das wäre ja Toll, bloß habe ich den Beitrag nicht gefunden, würde mich rein Persönlich Interessieren? aber Trotzdem, ändert nix daran, das es für Livesupport nicht zugelassen ist....... @A. K. Auch dir Danke für dein Beitrag, ist aber nicht ganz richtig, wir haben gerade diesen Monat wieder 2 Hybridprozessoren auf den Markt gebracht, zu denen es (noch) keinen "C" Compiler gibt. das eine ist ein 16 Bit uC das andere ist ein 128Bit DSP... Klar das es irgend wann auch für die meisten, "C" & Co geben wird, aber nicht für alle, von uns auf den Markt gebrachten uC's, gibts Hochsprachen und Trotzdem, Unmengen davon sind weltweit im Einsatz....:) im Bereich Sicherheitstechnik (Livesupport), Lenktechnik, Hochsicherheit's-Verschlüsselungssysteme, und da hat's in den letzten 30 Jahren keine Hochsprache gegeben und wirds wahrscheinlich auch in Zukunft nicht geben, wir Produzieren diese uC's aber immer noch und sie werden auch noch eingesetzt...... die einen Ja da hast du recht, in sehr kleinen Stückzahlen aber es sind auch welche die wir Outgesourct haben (bzw. stellt unser Kunde nun selber her, aber wurde von Unserem Team entwickelt) und die gehen schon in große Stückzahlen rein. Nichts dest do Trotz suchen wir halt Assembler Programmierer..... ...Bist du einer? Interesse? ....:-D Gruß..... Nachtrag: @Cyblord >Und wie verzweifelt müssen die Leute dort sein, die einen TCP/IP Stack >in Assembler programmieren? Das ist das Äquivalent zum Steine klopfen im >Zuchthaus. Und das wo ordentliche Controller mit genug Speichern für >eine ordentliches SW-Entwicklung nichts mehr kosten. Höchstrafe! Versuch doch mal auf 100nm³ mehr unterzukrigen......dan werden wir es tun, zur Zeit ist aber die Technologie nicht so weit....Schade...Deshalb müssen wir das.....
:
Bearbeitet durch User
> Patrick Linder (Firma: S-C-I DATA GbR) dass IHR nur Assembler verwendet ist schön, wird keiner ein Problem damit haben dass ihr Assembler in einer (sehr kleinen) Niesche verwendet beweist aber doch genau das gegenteil von: >Assembler wieder auf dem Weg nach vorn
Robert L. schrieb: > > dass IHR nur Assembler verwendet ist schön, wird keiner ein Problem > damit haben ..Das Hoffe ich doch :D GRINS....... > > dass ihr Assembler in einer (sehr kleinen) Niesche verwendet beweist > aber doch genau das gegenteil von: > >>Assembler wieder auf dem Weg nach vorn Wo du Recht hast, hast du Recht, von Vormarsch kann echt nicht die Rede sein das ist so. (Braucht zu viel Hirnschmalz und Hardwarekenntnis) .....Hehe..... Aber ich sage ja nur, Assembler wird es immer geben solange es neue Prozessoren gibt, deren Sprache Assembler bzw. Maschinensprache ist. Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man damit umgehen kann) und auch zuverlässiger, weil man eben Maschinen bzw. Prozessor nah programmieren muss... Und wäre Windows in Assembler geschrieben würd es vielleicht auch zuverlässig laufen, den selbst WIN10 Kennt den Bluescreen und das noch öfters als Win 7 oder gar XP...... Gruß....
Patrick L. schrieb: > (Braucht zu viel Hirnschmalz und Hardwarekenntnis) Hardwarekenntnis brauchst du für hardwarenahe Programmierung immer, da unterscheiden sich andere Sprachen von Assembler gar nicht – zumindest nicht, wenn man die Hardware auch wirklich selbst ansteuert und nicht fertige Bibliotheken dafür nimmt (wie bspw. Bascom oder Arduino etc.). Das wesentliche unterschlägst du: Assemblerprogrammierung braucht vor allem Zeit, und zwar sehr viel mehr als jede höhere Sprache, wenn das Gesamtproblem nicht mehr trivial ist. Das ist doch der wesentliche Grund, warum man es nicht macht, wenn es irgendwie vermeidbar ist. Die entsprechende Software wird dadurch einfach teuer. > Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man Wurde im dir bereits zitierten Beitrag widerlegt. ;-) > damit umgehen kann) und auch zuverlässiger, Das ist ein Trugschluss. Der wesentliche Fehlerfaktor ist ja nicht der Compiler sondern der Mensch, und durch die geringe Codedichte ergibt sich automatisch erstmal eine höhere Fehlerwahrscheinlichkeit bei Lösung des gleichen Problems. > Und wäre Windows in Assembler geschrieben würd es vielleicht auch > zuverlässig laufen Nein: es würde gar kein Windows geben, sondern MS-DOS 32.0.
Patrick L. schrieb: > Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man > damit umgehen kann) und auch zuverlässiger, weil man eben Maschinen bzw. > Prozessor nah programmieren muss... Für ultrakleine Programme mag das ja richtig sein. Aber ab einer bestimmten Programmgröße nimmt die Komplexität dermaßen zu, dass die Maschine (sprich Compiler) besser optimieren kann als der Mensch (in Assembler). Hier in diesem Thread wurde sogar gezeigt, dass auch kleine Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden. > Und wäre Windows in Assembler geschrieben würd es vielleicht auch > zuverlässig laufen, den selbst WIN10 Kennt den Bluescreen und das noch > öfters als Win 7 oder gar XP...... Wäre Windows in Assembler geschrieben, wäre das Erscheinungsdatum von Win7 irgendwann im Jahre 2107 gewesen. Die Argumente, die Du bringst, wurden hier schon alle angeführt. Allein die Nettiquette gebietet es, dass Du Dir diesen Thread erst einmal komplett durchliest, bevor Du hier mit Kamellen kommst, die längst alle schon durchgekaut wurden. Vielleicht willst Du aber auch nur provozieren... Moby Version 2.0...
:
Bearbeitet durch Moderator
Frank M. schrieb: > .....Für ultrakleine Programme mag das ja richtig sein. Aber ab einer > bestimmten Programmgröße nimmt die Komplexität dermaßen zu, dass die > Maschine (sprich Compiler) besser optimieren kann als der Mensch (in > Assembler)....... ...die Meinung lass ich dir, auch wenn ich sie nach über 40 Jahren Erfahrung nicht teile........ > Hier in diesem Thread wurde sogar gezeigt, dass auch kleine > Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden. > .... ....lass ich auch stehen, kommt aber auch da auf das wissen und können des Programmierers an...... > ........ > Wäre Windows in Assembler geschrieben, wäre das Erscheinungsdatum von > Win7 irgendwann im Jahre 2107 gewesen. > .... ....finde, Ist ein bisschen übertrieben, aber da will ich mich nict drauf einlassen, wir haben Komplexe Programme in Assembler geschrieben die in GB Bereich reichen....Wen unser Kunde das will weil FDA das vorschreibt, tun wir das...... > Die Argumente, die Du bringst, wurden hier schon alle angeführt. Allein > die Nettiquette gebietet es, dass Du Dir diesen Thread erst einmal > komplett durchliest, bevor Du hier mit Kamellen kommst, die längst alle > schon durchgekaut wurden. > ..... ...Ohhh sorry, erwähne ich weil ich mich über Windows und über seine Zuverlässigkeit immer wieder ärgere, da aber leider viel Werkzeug das wir haben müssen nur unter Windows laufen :(... ....und....ich habe sehr viel im Thread gelesen ja... aber um so einen Langen Thread durchzulesen fehlt mir die Zeit....Also bitte etwas Toleranz ja in Bezug auf die.... > ... die Nettiquette gebietet es, .... .... irgend wann sind die Threads zu lange...... > Vielleicht willst Du aber auch nur provozieren... ....nein will ich nicht.... Will nur klar mitteilen das Assembler oft sehr Abschätzig behandelt wird und dabei vergessen wird dass es halt doch Vorzüge hat und auch die Mutter aller Programmiersprachen ist den das Kind (der uC) spricht nun mal in den meisten fällen diese Sprache.... Und ändert auch nix daran das speziell wir damit arbeiten müssen weil es nun mal nicht anders geht. Wir haben diese Vorschriften nicht gemacht aber wenn wir liefern wollen müssen wir uns daran halten. Und wenn keiner Assembler Programmieren könnte würde es sehr schlecht um neue Prozessoren stehen den sie so Aufzubauen das sie von Haus aus eine Hochsprache sprechen ist derart aufwendig, das auch wir dieses Projekt eines "C" Prozessors stillgelegt haben. Der Prototyp den wir entwickelt hatten brauchte 10 x soviel Chipfläche wie ein Vergleichbaren Maschinencode basierenden Prozessor. Aber ein Punkt muss ich dir lassen, Unser "C" Prozessor Prototyp ist gut im Factor >100 schneller als jeder andere den wir bis heute entwickelt hatten. Den er kan somit oft Mehrere hundert Befehle in einem Cyclus abarbeiten... Leider kann man Ihn bedingt durch seinen Platzaufwand und Komplexität auf dem Waver nicht bezahlen.. Ca 5 Mio würde er kosten bis er ausgereift ist.... Und deshalb wollen wir auch den Guten Mann der über 30 Jahre bei uns gearbeitet hat auch wieder ersetzen, ....es geht nicht ohne Assembler.... Lieben Gruß
Patrick L. schrieb: > Will nur klar mitteilen das Assembler oft sehr Abschätzig behandelt wird Ach was: keiner hier behandelt den „abschätzig“. Man sollte nur keinen Hype draus machen, genau das hatte der Thread aber mal bezweckt.
Patrick L. schrieb: > wir haben Komplexe Programme in Assembler geschrieben > die in GB Bereich reichen Da wäre doch mal interessant zu erfahren um was es da geht. Erzähl doch mal...
Patrick L. schrieb: > ....finde, Ist ein bisschen übertrieben, aber da will ich mich nict > drauf einlassen, wir haben Komplexe Programme in Assembler geschrieben > die in GB Bereich reichen....Wen unser Kunde das will weil FDA das > vorschreibt, tun wir das...... Ihr würdest wahrscheinlich auch eine Weltumrundung auf Händen und Knien machen wenn euer Kunde das von euch verlangt. Aber dann zu argumentieren dies wäre irgendwie sinnvoll oder gar nicht Wahnsinnig, ist eben lächerlich.
Jörg W. schrieb: > Man sollte nur keinen Hype draus machen, genau das hatte der Thread > aber mal bezweckt. AAARRRG Sorry jetzt wo du es sagst....Grmpf..habe mich doch echt Mitreißen lassen :'(....... ...Das habe ich nicht bemerkt aber es ist so da hast du 10000% Recht..... Hätte wohl lieber einen Neuen Thread aufgemacht so ala .. ....Programmierer in Assembler gesucht..... Grumpf...werde wohl doch langsam ALT..... GRINS Aber denke auch da wär's zur Provokation geworden... weil... Habe Viele Threads, hier im Forum gefunden die mit Assembler zu tun haben aber meistens wird's eine Schlammschlacht, desshalb. Kurz im Google "Assembler Programmierer gesucht" und hier gelandet.... Nochmals Sorry dass ich mich hab Hinreißen lassen.. Hat wohl meine Ehre etwas angekratzt, weil ich seit rund 50 Jahre in Assembler Programmiere.... Gruß....
Hast du eigentlich einen Punkte-Fetisch? Übel zu lesen deine Posts. Kommt das von zu viel Assembler?
das mit dem "windows in ASM" ist schon sehr abenteuerlich.. (das ist ja maximal ein troll verusch) was ich nicht verstehe: wenn ICH jetzt eine neue CPU entwickeln würde, mit (warum auch immer) komplett neuem befehlssatz.. ja, dann müsste ich Assembler können, aber ich müsste doch nicht auch "große programme" damit schreiben (wozu auch??) würde ich doch als erstes (wo es die CPU noch nicht mal real gibt) einen compiler-compiler mit dem neuen befehlssatz beauftragen.. und hätte dann gleich einen riesen Satz an Testroutinen von der letzten CPU die ich entwickelt habe.. (ps. die chancen dass eine mini-stückzalen CPU selber irgend einen BUG hat ist doch 100 mal höher als eine millonenfach produzierte CPU mit millionenfach verwendetem compiler..?!)
:
Bearbeitet durch User
Hmmm jaahhhhh Punkte sind doch Cool, beim Kommentieren Praktisch, zeigen sie doch im Liesting wo was hingehört. LOL So Von mir aus tippt was ihr wollt, GRINS. der thread ist eindeutig Provokativ, ziht Provokationen an und dient nicht dem Zweck welchen ich gedacht habe.
>weil ich seit rund 50 Jahre in Assembler >Programmiere. und da suchst du JETZT einen Assembler programmieren? besser spät als nie ist ja wie bei der NASA ;-) http://www.heise.de/newsticker/meldung/NASA-sucht-Programmierer-fuer-Voyager-Sonden-2866565.html
Patrick L. schrieb: > der thread [...] dient nicht dem Zweck welchen ich gedacht habe. Korrekt. Wenn Du einen Assembler-Programmierer suchst, kannst Du hier eine Stellenanzeige schalten: https://www.mikrocontroller.net/jobs/info Ein Diskussionsthread wie dieser ist gewiss nicht dafür geeignet.
Patrick L. schrieb: > Aber denke auch da wär's zur Provokation geworden... weil... ...zu diesem Thema schon alles gesagt wurde. Nur noch nicht von jedem. Weil bei diesem Thema immer so lange polarisiert wird, bis keine Seite bereit ist, von ihrer Position abzurücken. Weil es einfach nur nervt, immer wieder das gleiche Zeug rauszukramen. Wie bei den unzähligen Windows/Linux-Debatten. Haben die schon ein einziges Mal zu etwas geführt? Das sind nichts anderes als Trolldebatten.
nur noch schnell: Patrick L. schrieb: > und auch genau so verhält es sich bei den Hochsprachen > für uC die Compiler oder gar Interpreter sind nie Perfekt. warum habt ihr nicht einfach selber den Compiler in ASM geschrieben, dann wäre er Perfekt ;-)
Sorry Robert L. Wir haben wohl gleichzeitig geschrieben war nicht auf dich bezogen. Robert L. schrieb: > das mit dem "windows in ASM" ist schon sehr abenteuerlich.. > (das ist ja maximal ein troll verusch) Hmmm oder eben gewollt vom Threadersteller zu provozieren, hat ja auch wunderbar geklappt. > > was ich nicht verstehe: > > wenn ICH jetzt eine neue CPU entwickeln würde, mit (warum auch immer) > komplett neuem befehlssatz.. > ja, dann müsste ich Assembler können, aber ich müsste doch nicht auch > "große programme" damit schreiben (wozu auch??) Weil es nun mal Vorgeschrieben ist, für gewisse Anwendungen den bsw unterstützen sehr viele Hochsprachen oft gewisse gesonderte wirkungsvolle Befehle der CPU Nicht.(Ja und auch ganz besonders in der heutigen Zeit) Mag mich an ein Hype in unserer Firma erinnern, da war ein totaler C Freak bei uns neu und es gab da endlose Diskussionen warum der C Befehl den "LDIR" befahl nicht nutze, dabei war es eben wie hier eine reine Provokation, den wenn man ihn benutzt anstelle eine Schlaufe zu generieren, was die Z80 C compiler damals taten, ist die Software 100x schneller und auch Stackoverflow sicher, wenn interuppts in die Verschiebeschlaufe geraten. Und genau an solchen Sachen setzt wahrscheinlich auch die Vorschrift der FDA an > > > würde ich doch als erstes (wo es die CPU noch nicht mal real gibt) einen > compiler-compiler mit dem neuen befehlssatz beauftragen.. > muss ich das Verstehen? wie meinst du das? > (ps. die chancen dass eine mini-stückzalen CPU selber irgend einen BUG > hat ist doch 100 mal höher als eine millonenfach produzierte CPU mit > millionenfach verwendetem compiler..?!) Och Bugs? das haben auch heute noch die meisten CPU's die Errata's der Hersteller sind oft Abenteuerlich GRINS.
Bei Assemblerleuten heißen Schleifen also "Schlaufen". Man lernt ja nie aus.
Patrick L. schrieb: > Mag mich an ein Hype in unserer Firma erinnern, da war ein totaler C > Freak bei uns neu und es gab da endlose Diskussionen warum der C Befehl > den "LDIR" befahl nicht nutze, Damals - in den 80ern - also ungefähr die 50 Jahre her, seitdem Du bereits in Assembler programmierst, waren die C-Compiler noch ziemlich unterbelichtet. Ein memcpy() in C (was Deinem LDIR in Z80 Assembler gleichkommt) war halt eine Schleife ohne irgendwelche prozessorspezifische Optimierungen. Das hat sich erst mit den 3B-Prozessoren von AT&T geändert, welche solche C-Funktionen wie memcpy() und strcpy() direkt als Assembler-Befehl kannten. > dabei war es eben wie hier eine reine > Provokation, den wenn man ihn benutzt anstelle eine Schlaufe zu > generieren, was die Z80 C compiler damals taten, ist die Software 100x > schneller und auch Stackoverflow sicher, wenn interuppts in die > Verschiebeschlaufe geraten. Ein LDIR schützt Dich nicht automatisch gegen Stackoverflow. Da waren Deine Interrupt-Routinen eher nicht sauber genug programmiert bzgl. Register-Rettung.
Lies die anderen 2K Beiträge dann verstehst Du das kaum einer der Meinung ist es gäbe keinen Anwendungsfall für ASM. Einige wenige sind aber der Meinung ASM wäre immer und in jedem Fall überlegen was nun wirklich vollkommener Humbug ist. Die Mehrheit ist nur der Meinung das es eben sehr, sehr wenig Gründe gibt heute noch exzessiv ASM zu verwenden wenn entsprechende Compiler und fortschrittliche CPUs zur Verfügung stehen um auch damit sicherheitsrelevante Software zu schreiben. Das alles von Dir beschriebene in 2K Flash + 128B Ram zu bekommen ist wahrlich eine Heroische Tat und ich werde Eure ASM Coder lobend in meinem Nachtgebet erwähnen. Im Regelfall halte ich aber einen anderen Controller für die bessere Wahl.
Frank M. schrieb: > welche solche C-Funktionen wie > memcpy() und strcpy() direkt als Assembler-Befehl kannten. Bloss um dann festzustellen, dass solche Funktionen explizit ausprogrammiert und optimiert oft schneller sind, als eventuell vorhandenen Prozessorbefehle fürs Speicherschaufeln.
Wahrheiten hängen ja zuweilen daran, wer es sagt... Solche aktuellen Meldungen renommierter Fachmedien sprechen jedenfalls nicht gerade von einem furiosen Asm-Niedergang: http://www.elektroniknet.de/markt-technik/embedded/assembler-boomt-134158.html http://www.heise.de/newsticker/meldung/Programmiersprachen-Ranking-Assembler-stabil-Go-im-Aufwind-3458803.html Frank M. schrieb: > Hier in diesem Thread wurde sogar gezeigt, dass auch kleine > Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden. Mit einem gewissen C-Know-How, das hat auch nicht jeder! In https://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C stellst Du ja für zumindest mal für die Anwendung Bootloader selber fest: "Jedoch sind diese Bootloader allesamt in Assembler realisiert, denn nur hier hat der Programmierer alle Freiheiten, die er braucht, um die Speicherverwaltung im SRAM (und auch im Flash) selbst zu kontrollieren. C (hier im speziellen avr-gcc) ermöglicht es eigentlich nicht, ohne größere Klimmzüge einen Bootloader für ATtinys zu programmieren" oder "Da ein in Assembler geschriebener Bootloader in der Regel viel weniger Speicherplatz benötigt und daher effizienter auf einem kleinen µC ist als ein in C programmierter Bootloader, ist dieser Artikel eher akademischer Natur" So ist es. Dieses Ansinnen bleibt von Natur aus meist akademisch :)
Christian M. schrieb: > In > https://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C > stellst Du ja für zumindest mal für die Anwendung Bootloader selber > fest: > [...] Diese Vorgehensweise, Bruchstücke, die nur in einem sehr speziellen Fall gelten (nämlich Bootloader für ATTiny) zu verallgemeinern, kommt mir sehr sehr bekannt vor - und zwar nicht gerade im angenehmen Sinne. Schon für ATmegas gilt diese Aussage nicht mehr. Hier wäre C ganz klar mein Favorit für einen Bootloader. Und das nicht, weil mehr Flash/RAM zur Verfügung steht, sondern weil hier der Bootloader eine eigene Interrupt-Vektor-Tabelle und einen geschützten Bootloader-Bereich hat. Genau diese Problematik macht es einem C-Programmierer schwer, einen Bootloader spziell für ATTinys in C zu formulieren. Das steht auch so klar in dem zitierten Artikel. Dein Argument ist nicht verallgemeinerbar. Und daher hinfällig.
Für den Tiny841 habe ich ebenfalls einen Bootloader komplett in C geschrieben.
Wieso wird hier denn wieder diskutiert? Dachte alles sei geklärt, sogar Moby musste damals seine Niederlage eingestehen (was er immerhin auch tat!). Assembler mag für Nischenanwendungen oder Hobby interessant sein, das wars aber auch. Alles was irgendwie kommerziell ist wird schon nicht mehr in ASM gemacht, von kleinsten Codestellen (z.B. startup-Code) abgesehen. Das ASM nicht total verschwindet ist der Technik und Historie geschuldet: Prozessoren "sprechen" erstmal nur Assembler. Deswegen wird er auch nie verschwinden. 99,5% der Anwender müssen aber damit nicht in Berührung kommen.
Patrick L. schrieb: > ...die Meinung lass ich dir, auch wenn ich sie nach über 40 Jahren > Erfahrung nicht teile........ Patrick L. schrieb: > weil ich seit rund 50 Jahre in Assembler > Programmiere.... wie die Zeit vergeht
Thread beobachten
Seitenaufteilung abschalten
#/media/File:Colossal_Cave_Adventure_on_VT100_terminal.jpg){kind=link}
