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
>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."
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. :-)
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.
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.
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.
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 ;-)
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 ;-)
> ... 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.
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
;-)
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.
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.
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!
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 ;-)
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 ;-)
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 ?
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 :-)
Ü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.
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 ;-)
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!
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 ;-)
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 ;-)
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.
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?
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.
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 !!!
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?
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.
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 ;-)
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
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.
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
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 ;-)
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
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.
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.
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 ;-)
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-Modulhttp://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.
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.
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?
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.
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 ^^)
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...
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...
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.
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.
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.
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!
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.
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.
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)
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!
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.
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.
@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.
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.
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.
;-)
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 ...
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.)
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.
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ächerlichGu. 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ß ;-)
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
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:> 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.
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
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 ;-)
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...
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 ;-((
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.
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.
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.
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.
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"
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.
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.
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..)
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...
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...
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.
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...)
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 ;-)
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 ;-)
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.
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.
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.
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.
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.
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.
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 ;-)
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
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
voidmain(void){
2
loop:gotoloop;
3
}
braucht.
Ergo: Du hast keine Ahnung wovon dur hier rumschwadronierst...
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.
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
intmain(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.
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 ;-)
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.
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.
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.
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.
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.
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 ;-)
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.
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 ;-)
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 ;-)
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_tparams[8];
4
barometer_read(4,8,params);
5
6
inta0_int=(params[0]<<8)+params[1];
7
a0=a0_int/8.0;
8
intb1_int=(params[2]<<8)+params[3];
9
b1=b1_int/8192.0;
10
intb2_int=(params[4]<<8)+params[5];
11
b2=b2_int/16384.0;
12
intc12_int=(params[6]<<8)+params[7];
13
c12=c12_int/(16384.0*1024.0);
14
15
//…
16
uint8_tresults[4];
17
18
barometer_read(0,4,results);
19
unsignedpadc=(results[0]<<2)+(results[1]>>6);
20
unsignedtadc=(results[2]<<2)+(results[3]>>6);
21
22
doublepcomp=a0+(b1+c12*(double)tadc)
23
*(double)padc+b2*(double)tadc;
24
doublepressure=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...
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..
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
>> 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 ;-)
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?
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. ;-)
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 ;-)
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).
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 ;-)
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:
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.
> 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 ;-)
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.
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.
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
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?
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.
> 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.
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.
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:> 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
03B01A85BTFSCPORTA,0x5
2
03B11E05BTFSSPORTA,0x4
3
03B22BB8GOTO0x3B8
4
03B31A87BTFSCPORTC,0x5
5
03B41E07BTFSSPORTC,0x4
6
03B52BB8GOTO0x3B8
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.
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.
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!
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.
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 ;-(
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 ?
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.
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:> 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. ;-)
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!
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 ;-)
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.
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.
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.
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.
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:> 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:> 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.
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.
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 ...
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.
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 :-(( )
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 ;-)
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.
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...
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.
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...
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...
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.
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 ;-)
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.
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.
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!
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.]
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
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.
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.
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.
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. ;-)
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.
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.
@ 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.
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.
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.
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.
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.
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.
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.
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 ;-)
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 ;-)
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.
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.
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 ;-)
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:> 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:
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..
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.
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.
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...
> 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...
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 ;-)
Moby A. schrieb:> Mit Übung, Vorbereitung und SystemMoby 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 ;-(
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.
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 ;-)
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"
;-)
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)
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
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.
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?
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]
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.
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.)
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 ;-)
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.
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.
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 ;-)
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.
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 ;-)
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 ;-)
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.
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.
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.
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
:-)
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.
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.
> 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
voidmain(){
2
3
uint8_tthreshold=89;
4
5
uint8_tvalue_ptr=0;
6
uint8_tlast_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_tsum=0;
24
for(uint8_ti=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?
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 ;-)
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){
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.
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:MOVLW0x7
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.
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.
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 ;-)
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. :-)
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)
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:> 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.
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
}elsevalue_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
>}elsevalue_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.
>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:> 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.
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.
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.htmlhttp://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
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..
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...
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
voidmain(){
2
3
uint8_tthreshold=89;
4
5
uint8_tvalue_ptr=0;
6
uint8_tlast_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_tsum=0;
24
for(uint8_ti=0;i<8;i++){
25
sum+=last_values[i];
26
}
27
28
// check if average in ringbuffer exceeds threshold
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?
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.)
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.
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.
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.
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.
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?
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 ;-)
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.
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...
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.
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.
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.
>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.
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.
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.
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.
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.pdfhttp://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.
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
voidInitMCU(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
voidad_acq(uint8_tchs){
31
ADCON0bits.CHS=chs;
32
__delay_us(20);
33
ADCON0bits.GO=1;
34
while(ADCON0bits.GO_nDONE){;}
35
}
36
37
voidsendByte(uint8_ts){
38
uint8_tmask=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
voidmain(void){
52
uint8_ttmpByte3,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!
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.
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 ;-)
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 ;-)
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.
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 ;-)
Moby A. schrieb:> vermutlich kennst Du auch nur fetten C-CodeMoby 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: ;-) ;-) ;-)
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.
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.
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..
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
voidmain(){
2
3
uint8_tthreshold=89;
4
5
uint8_tvalue_ptr=0;
6
uint8_tlast_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_tsum=0;
24
for(uint8_ti=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.
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 ;-)
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 ;-)
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."
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ößeunschlagbar 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.
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.
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 .-)
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.
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.
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 :)
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.
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.
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.
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.
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 ;-)
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..
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.
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.
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.
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. ;-)
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. ;-)
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.
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 ;-)
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.
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...
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 ;-)
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?
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.
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.
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 ;-(
>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.
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.
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.
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.
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 gewinnenMichael 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.
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 :-)
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.
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.
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äääää?" ;-)
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.
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.
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.
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
// 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_tocr_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_tocr=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?
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.
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.
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.
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.
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.
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"..
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...
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.
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.
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.
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.
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.
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
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.
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 ;-)
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.
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.
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.
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 ;-)
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.
> 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.
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).
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.
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.
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.
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 ...
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
Announcement: there is an English version of this forum on 
