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 der Sache liegt. Jedoch vermute
ich, daß er C ganz passabel beherrscht und recht gut weiß, was so ein
C-Compiler kann, denn sonst hätte er seine Falle nicht so ausgefeilt
konstruiert.
Insofern bin ich hinsichtlich Deiner These etwas unschlüssig -- aber das
gehört ja zu dem, was die Geschichte so unterhaltsam macht. g> Stellenweise hat dieser Thread wirklich lehrreiche Dinge zu Tage> gefördert, wozu ich unter anderem auch teilweise Deine Beiträge zähle.
Danke -- ich hoffe, nicht nur als Sozialstudie! g
Hmm, so einmal am Tag über die neuen Posts in diesem Thread gehen ist
schon amüsant.
Auf der einen Seite Moby, der davon überzeugt ist, das man mit
Lochkarten näher an der Maschine ist und deswegen immer effizienter
arbeiten kann gegen den Rest, der weiß, daß man mit mit Tastatur und
Bildschirm praktisch immer im Vorteil ist....
Michael K. schrieb:> Vor allem glaube ich eines.> Wenn man mit einem Typen wie Moby beim Bier zusammensitzen würde währe> man wahrscheinlich baff erstaunt wie vielschichtig und reflektiert der> über unterscheidlichste Dinge reden kann.
Brrr die Vorstelltung find ich grad gruselig.
Der wird sicher nicht auf Knopfdruck zum besten Kumpel. Wer sich mit
Lügen und derart arrogant (wenn auch sehr unterschwellig) solche
Garbenkämpfe liefert ist am Abend in der Kneipe immer noch der selbe Typ
Mensch.
A. K. schrieb:> ein DS18x20,> ein serielles Interface zu einer damals schon alten Conrad Funkuhr, ein> LCD-Display,
lol
alles was du nicht selber kannst, hast du also in externe Hardware
ausgelagert...
;-)
ps. warum braucht C eigentlich (per se?) mehr speicher?
sollte es nicht (durch "lokale variablen", bessere ausnützen der
register usw) für C viel einfacher sein, speicher mehrfach (stack usw.)
zu verwenden.. (und eben nur so kurz wie möglich zu reservieren)
Robert L. schrieb:> ps. warum braucht C eigentlich (per se?) mehr speicher?
Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu
suchen, für die man komplett und ausschlieslich mit den Registern der
CPU durchkommt. Speicher braucht er dann nur für den Returnstack.
Das ist in C ein bisschen schwer zu realisieren. Man könnte zwar mittels
'register' den Compiler auffordern, bestimmte Variablen in bestimmte
Register zu legen, aber das ist ein 2-schneidiges Schwert, sobald
irgendwelche System Library Aufrufe dazukommen, die von dieser
Reservierung nichts wissen.
Robert L. schrieb:> alles was du nicht selber kannst, hast du also in externe Hardware> ausgelagert...
Stimmt. ;-)
> ps. warum braucht C eigentlich (per se?) mehr speicher?
Tut es nicht. Nur zeigt grad das Beispiel meines gestern geposteten
Asm-Codes die Grenzen der üblichen Compiler. Der Compiler wird Variablen
nicht über die Grenzen von Funktionen hinaus in Registern platzieren.
Grad bei Prozessoren mit vielen Registern, wie AVR, kann das einen
erheblichen Unterschied ausmachen.
Da aber die Anzahl Register begrenzt ist, ist es auch die Anzahl darin
platzierbarer Variablen. Bei kleinen Programmen ist das kein Problem.
Bei grossen und bei oft signifikant veränderten Programmen eignet sich
diese Programmiertechnik weniger.
Man könnte natürlich auch einen optimierenden Compiler bauen, der
globale Registerplatzierung effizient nutzt, wenn ihm das sinnvoll
erscheint. Ein solcher Compiler könnte auch bei kleinen Programmen
locker mithalten.
Nur müsste man dann immer alles zusammen übersetzen, sämtliche Libraries
eingeschlossen. Das ist bei kleinen Programmen nur problemlos möglich,
wenn der Quellcode der Libraries vorliegt, und bei grossen Programmen
nicht praktikabel.
Robert L. schrieb:> ich dachte mir es gibt vielleicht sowas wie "fastcall"
Bei Architekturen mit ausreichender Anzahl Register werden Parameter
üblicherweise in Registern übergeben, soweit möglich. Bei AVR ebenfalls.
Diese fastcall Methode ist also Stand der Technik.
Das x86 ABI, aus dem man fastcall kennt, geht allerdings auf Zeiten vor
ANSI-C zurück, und ohne Parameterdeklaration gibts bei der
routinemässigen Übergabe in Registern kleine Probleme.
Bei dem was ich grad schrieb geht es aber nicht um die Übergabe von
Parametern, sondern um statische/globale Variablen.
Karl H. schrieb:> Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu> suchen, für die man komplett und ausschlieslich mit den Registern der> CPU durchkommt. Speicher braucht er dann nur für den Returnstack.
Ja. Und andere Aufgaben sind keine typischen 8bit MSR Anwendungen und
werden per externem IC beigefügt.
Bernhard M. schrieb:> Hmm, so einmal am Tag über die neuen Posts in diesem Thread gehen ist> schon amüsant.
Ja, es sind ein paar gute Kolumnisten dabei.
Karl H. schrieb:> Robert L. schrieb:>>> ps. warum braucht C eigentlich (per se?) mehr speicher?>> Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu> suchen, für die man komplett und ausschlieslich mit den Registern der> CPU durchkommt. Speicher braucht er dann nur für den Returnstack.
So ist es, weswegen er ja auch nur solche Mickymausanwendungen für einem
Vergleich zur Verfügung stellt.
Wenn man sich nämlich einmal die etwas größere Applikation von Moby
anschaut (für deren Programmierung Assembler seiner Ansicht nach ja
ebenfalls nur Vorteile bringen soll), stellt man fest, diese sehr wohl
RAM benutzt und davon nicht einmal wenig, nämlich 5415 Byte, s. dieser
Beitrag:
Moby A. schrieb:> 10K Asm-Codesize
Eine solch intensive Speichernutzung entsteht meist dadurch, dass man
größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal
in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler
keine Vorteile bietet. Anders als in Assembler hat man aber in C die
Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger
zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von
8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder
12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden.
Wenn man wie Moby darauf erpicht ist, immer den jeweils kleinstmöglichen
Controller einzusetzen, sehe ich hier gute Chancen, mit der Verwendung
von C-Bitfields den ATxmega128A4U durch einen ATxmega64A4U mit halb
soviel Speicher (4096 Byte RAM) zu ersetzen. Dadurch wird das Binary des
Programms zwar etwas länger und langsamer, aber Flash-Speicher steht bei
diesen Controllern sowieso im Überfluss zur Verfügung, und auch die
Laufzeiteffizienz dürfte bei dieser Anwendung nicht die entscheidende
Rolle spielen.
Natürlich könnte man dasselbe auch in Assembler tun, allerdings
erfordert das viel zusätzlichen Programmieraufwand, zudem wird das
Programm durch die komplizierteren Elementzugriffe unübersichtlich und
schlecht wartbar. In C hingegen hat man durch die Verwendung von
Bitfields praktisch überhaupt keinen zusätzlichen Entwicklungsaufwand,
da man im Wesentlichen nur die Datenstruktur(en) etwas anders
deklarieren muss. Die Zugriffe auf Elemente mit "krummen" Bitzahlen
werden vom Compiler automatisch erzeugt und unterscheiden sich im
Quellcode überhaupt nicht von gewöhnlichen Elementzugriffen.
Deswegen würde ich sagen, dass bei datenintensiven Anwendungen wie Mobys
Haussteuerung C nicht nur bzgl. der Entwicklungszeit sondern auch des
RAM-Verbrauchs klare Vorteile bietet.
Naja, prinzipiell geht das alles in ASM ja auch, insofern kann man nicht
sagen daß C weniger Speicher braucht.
Nur ist der Programmieraufwand inklusive Fehleranfälligkeit in ASM
natürlich drastisch höher, wenn man so geizig programmiert.
Per Definition ist es dann aber keine typische Anwendung mehr :-)
Yalu X. schrieb:> Hmm, du hast für das Projekt einen ATxmega128A4U genommen, weil der> nächstkleinere ATxmega64A4U zu wenig RAM hat. Von der Flash-Größe hätte> sogar ein ATxmega16A4U locker gereicht (sogar mit etlichen freien KB für> Erweiterungen ;-)).
Was ist denn das für ein altkluger Vorwurf...
Da handelt es sich um Code für meine SmartHome-Zentrale.
Da wird ständig erweitert, die ist niemals fertig.
Wie dumm, bei solch absehbarer Zukunft am falschen Ende zu sparen.
Ganz anders sieht das z.B. bei Sensor-Aktor Knoten und kleinen
dezentralen Steuerungen aus. Halt weiteren Millionen 8-Bit MSR
Anwendungen.
Yalu X. schrieb:> Siehst du, und bei C bleibt die Codedichte auch bei größeren Programmen> konstant.
Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter
bleibt. Die etwas nachlassende Codedichte geht im Wesentlichen auf die
notwendige Gliederung des Codes zurück, um bei größeren Projekten den
Überblick zu behalten. In einem finalen Schritt könnte man das
freilich vieles zusammenlegen.
Frank M. schrieb:> Moby A. schrieb:>> Frank M. schrieb:>>> Ab 1KB Codegröße ist ASM mit C IMMER schlagbar>>>> Das halte ich für falsch. Und wir wollen gleich nochmal klarstellen,>> daß nichts als der Ressourcen-Verbrauch gemeint ist.>> Genau dafür hast Du keinen Beleg.
Hast Du denn einen Beleg für Deine Behauptung ?
Wie man schön sieht handelt es sich bei mangelnden
Vergleichsmöglichkeiten hier um ein Totschlagargument, mit dem kein
Blumentopf zu gewinnen ist. Um da weiterzukommen und mal einen Anfang zu
machen habe ich mich für meine Behauptung um eine simple, aber
vollständige Asm-App zum Vergleich bemüht:
Beitrag "Kleines Tiny13 Sensorboard"
Wie zu erwarten kam natürlich nichts besseres. Die meisten werden hier
trotz anderslautender Heuchelei wissen, daß man sich mit dem Versuch nur
in die Nesseln setzen kann. Denn wenn manche Profis hier nur halb so
viel C-Experte sind wie sie tun wär das längst fertig ;-)
@Mod: Die Beantwortung von Beiträgen wird ohne funktionierende
Aufteilung bei langen Threads immer zäher. Ist das Absicht? ;-)
Moby A. schrieb:> Die Beantwortung von Beiträgen wird ohne funktionierende> Aufteilung bei langen Threads immer zäher.
Nach welchen Kriterien willst du aufteilen?
"Sinnvoll" und "nicht sinnvoll"?
Klaus W. schrieb:> Nach welchen Kriterien willst du aufteilen?> "Sinnvoll" und "nicht sinnvoll"?
Du meinst "Sinnvoll" so wie Dein Beitrag gerade?
Immer wieder beeindruckend, was manche "Profis" hier so draufhaben ;-(
Moby A. schrieb:> Hast Du denn einen Beleg für Deine Behauptung ?> Wie man schön sieht handelt es sich bei mangelnden> Vergleichsmöglichkeiten hier um ein Totschlagargument, mit dem kein> Blumentopf zu gewinnen ist.
Moby FALSCH!!!
Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich
zurück mit Falschaussagen
Beitrag "Re: C versus Assembler->Performance"
Moby A. schrieb:> Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter> bleibt. Die etwas nachlassende Codedichte geht im Wesentlichen auf die> notwendige Gliederung des Codes zurück, um bei größeren Projekten den> Überblick zu behalten.
Und eben deswegen ist die Code auch nicht dichter als in C. Ganz im
Gegenteil: Der vom C-Compiler erzeugte Assemblercode braucht nicht
übersichtlich zu sein, deswegen darf der Compiler gerne etwas mehr
optimieren (und tut das auch) als du es mit Rücksicht auf die
Übersichtlichkeit tun würdest.
> In einem finalen Schritt könnte man das freilich vieles zusammenlegen.
Was aber rein hypothetisch ist, da der finale Schritt nie stattfinden
wird, wie du ja selbst schreibst:
Moby A. schrieb:> Da handelt es sich um Code für meine SmartHome-Zentrale.> Da wird ständig erweitert, die ist niemals fertig.
In C muss man für so etwas nicht bis zum finalen Schritt warten, weil
mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher
Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit
verbunden ist.
>>>> Ab 1KB Codegröße ist ASM mit C IMMER schlagbar>>> Das halte ich für falsch.>> Genau dafür hast Du keinen Beleg.> Hast Du denn einen Beleg für Deine Behauptung ?> ...> Beitrag "Kleines Tiny13 Sensorboard"
Zurück auf los!
Yalu X. schrieb:> In C muss man
Dafür muss man erst C lernen.
Oder als Workaround sich ASM schön reden.
Yalu X. schrieb:> größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal> in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler> keine Vorteile bietet. Anders als in Assembler hat man aber in C die> Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger> zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von> 8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder> 12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden.
Nicht nur das. Ich habe auch die Möglichkeit, schnell und einfach die
komplette Datenorganisation zu ändern, wenn sich im Laufe der Zeit die
Anforderungen ändern oder erweitert werden muss. In Assembler artet so
ein Unterfangen regelmässig in einen mittleren Albtraum aus. Und ja, ich
weiss durchaus wovon ich da spreche, hab ich schon gemacht - würde ich
nie wieder tun.
Karl H. schrieb:> wenn sich im Laufe der Zeit die> Anforderungen ändern oder erweitert werden
Du hast vorher nur nicht genügend Vorbereitung Planung und Übung
gemacht.
Moby A. schrieb:> Egal was ich> hier aber veröffentlichen würde- wenn auf C-Seite keiner in der Lage und> willens ist, selbst einen 200-Byte Code nachzuprogrammieren fehlt ein> C-Äquivalent zum Vergleich.
Ich werde Dir jetzt mal vorführen, warum Deine Argumentation Schwachsinn
ist.
Situation A
===========
- Moby legt ein 200Byte-Programm vor
- Moby sagt: "Solange kein C-Programmierer ein äquivalentes
C-Programm vorlegt, ist mein Programm in ASM das optimalste
Programm der Welt!"
- Keiner hat Lust, Mobys Programm in allen Einzelheiten zu verstehen
(weils Zeit kostet) und alle verlieren auch sämtliche Lust,
weil Moby plötzlich nachschiebt, als er seine Felle schwimmen
sieht: "Das Programm darf KEIN RAM nutzen!". Auch hat keiner
Lust, da Arbeit reinzustecken, weil keiner es braucht
- Moby schreit: "Aha, ihr könnt es nicht! ASM ist also BESSER!"
Soweit so gut.
Jetzt drehe ich den Spieß rum:
Situation B
===========
- N.N. legt ein C-Programm vor mit 1KB Binärgröße
- N.N. sagt: "Solange kein ASM-Programmierer ein äquivalentes
ASM-Programm vorlegt, ist mein Programm in C das optimalste
Programm der Welt!"
- Moby sagt: "Nee, habe ich keine Lust, weil ichs nicht brauche".
- N.N. schreit: "Aha, Du kannst es nicht! C ist also BESSER!"
Würdest du so einen Scheiß akzeptieren?
Ich kann Dir hunderte von C-Programmen hier präsentieren, wo Du
überhaupt nicht in der Lage wärest, diese in ASM nachzugrogrammieren.
Aber nur um zu sagen: "C ist besser als ASM"? Bestimmt nicht. Weil diese
Argumentation Schwachsinn ist.
Frank M. schrieb:> - Keiner hat Lust, Mobys Programm in allen Einzelheiten zu verstehen> (weils Zeit kostet)
Eigentlich nicht. Yalu hat mich da wieder auf ein paar Ideen gebracht,
wie man den Compiler für seine Sensorboard Aufgabenstellung mit dem
kruden Übertragungformat zu seinem Nutzen einspannen könnte. Und auch
die Sache mit den Register-Variablen würde man IMHO in den Griff kriegen
(avr-gcc unterstützt ja noch das 'register' Schlüsselwort und Library
Aufrufe sind nicht notwendig)
Nur hab ich deswegen keine Lust dazu, weil sich Moby konsequent in der
umgekehrten Richtung weigert, aus einer etwas umfangreicheren Vorgabe in
absehbarer Zeit ein entsprechendes ASM-Programm zu schreiben. Also genau
dein Szenario B, nur das ich etwas größer angesetzt hätte als lediglich
1K, damit die Diskrepanz so richtig schön zum tragen kommt :-) Ich
versteh natürlich, dass er da nicht 3 Wochen jeden Tag 3 bis 4 Stunden
über dem Code brüten will, um den Flash Verbrauch wieder um 3 Bytes zu
drücken. Aber auf der anderen Seite ist genau das die Lektion, um die es
geht: Erstens interessiert das keinen, ob das Programm 3 Bytes kürzer
ist oder nicht, solange es in den Flash passt und zweitens ist genau das
Argument, das Moby immer wieder bringt ("Ich hab mit meiner Zeit
besseres zu tun") genau eines der Argumente, warum Hochsprachen meistens
die bessere Wahl sind - eben weil wir mit unserer Zeit besseres zu tun
haben, als 3 Bytes im Flash nachzujagen.
Moby A. schrieb:> Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter> bleibt.
Hör jetzt bitte mal auf mit dem Unsinn, das ist wirklich nur noch
lächerlich und keiner Diskussion mehr würdig. Sollte man nach dermassen
viel Widerspruch von deutlich erfahreneren Leuten ja irgendwann
kapieren, findest du nicht?
Markus M. schrieb:> Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich> zurück mit Falschaussagen
Am Anfang war Moby einfach stur und uneinsichtig, dann begann er,
Argumente und Fakten ganz zu ignorieren und mittlerweile ist er sogar zu
Lügen und Falschaussagen übergegangen.
Markus M. schrieb:> Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich> zurück mit Falschaussagen
Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt
gezeigt wurde nicht geschlagen und ist nicht zu schlagen. Höchstens in
gewissen Wunschfantasien ;-) Speziell Dein Beitrag dazu war bislang
überschaubar und fachlich: nicht vorhanden.
Yalu X. schrieb:> In C muss man für so etwas nicht bis zum finalen Schritt warten, weil> mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher> Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit> verbunden ist.
Auch ohne "finale Schritte" bleibt Asm Code effizienter.
Wenn großartige Datenstrukturen zu optimieren, also mit umfangreichen,
verschiedenen Datenmengen umzugehen wäre dann mag die Welt anders
ausschauen.
Karl H. schrieb:> Yalu X. schrieb:>> größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal> in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler> keine Vorteile bietet. Anders als in Assembler hat man aber in C die> Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger> zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von> 8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder> 12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden.>> Nicht nur das. Ich habe auch die Möglichkeit, schnell und einfach die> komplette Datenorganisation zu ändern, wenn sich im Laufe der Zeit die> Anforderungen ändern oder erweitert werden muss. In Assembler artet so> ein Unterfangen regelmässig in einen mittleren Albtraum aus. Und ja, ich> weiss durchaus wovon ich da spreche, hab ich schon gemacht - würde ich> nie wieder tun.
Diese Möglichkeiten sind ja schön und gut- aber s.o.
Moby A. schrieb:> Markus M. schrieb:>> Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich>> zurück mit Falschaussagen>> Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt> gezeigt wurde nicht geschlagen und ist nicht zu schlagen.
Das ist wieder eine glatte Lüge/Falschaussage:
1
Mobys Asm-Code Yalus C-Code
2
—————————————————————————————————————————————————
3
Flash-Verbrauch 266 256
4
RAM-Verbrauch¹ 6 + 1 GPIOR 9
5
Stack-Verbrauch 2 4
6
Quellcodezeilen² 143 91
7
Quellcodezeichen³ 1614 1707
8
—————————————————————————————————————————————————
9
¹) ohne Stack
10
²) ohne Leer- und Kommentarzeilen
11
³) ohne Kommentare, Leerraum und Zeilenvorschübe
12
13
Compiler: GCC 4.7.4
14
Assembler/Linker: Binutils 2.25.1
15
C-Standardbibliothek: AVR-Libc 1.8.1
Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code
braucht weniger RAM und weniger Codezeichen.
Matthias L. schrieb:> Karl H. schrieb:> wenn sich im Laufe der Zeit die> Anforderungen ändern oder erweitert werden>> Du hast vorher nur nicht genügend Vorbereitung Planung und Übung> gemacht.
Da ist was dran. Zumindest bei Projekten < 10K ;-)
Frank M. schrieb:> - Moby sagt: "Nee, habe ich keine Lust, weil ichs nicht brauche".
Genau da liegt der Fehler in Deinem Szenario: Wenn Moby wie die
C-Sturköpfe hier darauf besteht, daß sein Code sparender wär und für
sich ein KnowHow wie manche hier in Anspruch nimmt wird er sich
gefälligst auf den Hosenboden setzen und es beweisen. Ansonsten sieht
er seine Thesen selbstverständlich nicht für bewiesen an. Genauso
schauts hier aus: Aussage gegen Aussage.
Frank M. schrieb:> Ich kann Dir hunderte von C-Programmen hier präsentieren, wo Du> überhaupt nicht in der Lage wärest, diese in ASM nachzugrogrammieren.
Programme aus dem hinlänglich umrissenen Einsatzbereich lassen sich
jederzeit besser in Asm coden. Umgekehrt könnte ich Dir viele
Asm-Programme präsentieren. Aber Du scheiterst ja mit Deinem Anspruch
auch schon an meinen kleinsten "Projektchen" ;-)
> Aber nur um zu sagen: "C ist besser als ASM"? Bestimmt nicht. Weil diese> Argumentation Schwachsinn ist.
Stimmt. Allgemein "C ist besser als Asm" wäre Schwachsinn. Bei 8-Bit MSR
(ohne große Berechnungen und Datenmengen) ist Asm besser. Dabei bleibt
es. Wer anderes behauptet darf das tun, wer mich aber wiederlegen will
kommt an der C-Codierung meiner entsprechend optimierten Beispiele
nicht vorbei!
P. M. schrieb:> Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code> braucht weniger RAM und weniger Codezeichen.
Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu
halten ist hatte ich weiter oben bereits das Nötige gesagt.
Karl H. schrieb:> Eigentlich nicht. Yalu hat mich da wieder auf ein paar Ideen gebracht,> wie man den Compiler für seine Sensorboard Aufgabenstellung mit dem> kruden Übertragungformat zu seinem Nutzen einspannen könnte.
Na dann mal los. Mal sehen was für ein leichtverständlicher Code dabei
rauskommt ;-)
> Nur hab ich deswegen keine Lust dazu
Ach sooo... Wird nun wohl doch nix ;-(
Na ja so ein Vollzeit-Forumsmensch hat auch wenig Zeit. Verstehe ich.
Dann sollte man sich mit kruden Thesen zur C-Überlegenheit aber
zumindest etwas zurückhalten bzw. sie nicht für bewiesen erklären.
Moby A. schrieb:> Genau da liegt der Fehler in Deinem Szenario: Wenn Moby wie die> C-Sturköpfe hier darauf besteht, daß sein Code sparender wär und für> sich ein KnowHow wie manche hier in Anspruch nimmt wird er sich> gefälligst auf den Hosenboden setzen und es beweisen. Ansonsten sieht> er seine Thesen selbstverständlich nicht für bewiesen an. Genauso> schauts hier aus: Aussage gegen Aussage.
Ich brauche also hier nur ein C-Programm zu posten mit 1KB Binärcode und
dann darf ich behaupten, dass C besser ist als ASM und Du würdest dann
versuchen, es in ASM besser zu schaffen?
Habe ich das richtig verstanden? Klasse!
Moby A. schrieb:> Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu> halten ist hatte ich weiter oben bereits das Nötige gesagt.
Genau: du hast im Anschluss die von Yalu vorgelegte Lösung mal wieder
als irrelevant wegdiskutiert und irgendwelche Details deiner
Implementierung nachträglich zum unbedingt vorhanden sein müssenden
Feature erklärt.
Damit kannst du dir deine Welt natürlich irgendwie schönreden, nur
glaubt dir das mittlerweile keiner mehr. Yalus Code war nun für
genau die Klasse Mickymausprogramme, in denen du sonst noch deine
Domäne siehst (die du gleich mal großzügig auf 10 K und mehr an Code
ausdehnst), und selbst dort hat er dich in weiten Teilen (wenn auch
nicht in allen) nach deinen Maßstäben schlagen können (weniger Flash,
mehr RAM).
Lass mal, ist ein unterhaltsamer Thread, wir wissen, dass du von deiner
Meinung nicht abzubringen bist, nicht einmal durch Beweise.
Moby A. schrieb:> Bei 8-Bit MSR> (ohne große Berechnungen und Datenmengen) ist Asm besser. Dabei bleibt> es.
Nein, das ist schon für sich falsch, wie Yalu gezeigt hat - nochmals,
weils so schön ist:
1
Mobys Asm-Code Yalus C-Code
2
—————————————————————————————————————————————————
3
Flash-Verbrauch 266 256
4
RAM-Verbrauch¹ 6 + 1 GPIOR 9
5
Stack-Verbrauch 2 4
6
Quellcodezeilen² 143 91
7
Quellcodezeichen³ 1614 1707
8
—————————————————————————————————————————————————
9
¹) ohne Stack
10
²) ohne Leer- und Kommentarzeilen
11
³) ohne Kommentare, Leerraum und Zeilenvorschübe
12
13
Compiler: GCC 4.7.4
14
Assembler/Linker: Binutils 2.25.1
15
C-Standardbibliothek: AVR-Libc 1.8.1
Moby A. schrieb:> P. M. schrieb:>> Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code>> braucht weniger RAM und weniger Codezeichen.>> Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu> halten ist hatte ich weiter oben bereits das Nötige gesagt.
Ja, du hast viel dazu gesagt und zeigst damit gleich selbst, dass
Assembler nur unter vielen, vielen Bedingungen besser ist als C. Selbst
im 8-Bit-MSR-Bereich.
Moby A. schrieb:> Da handelt es sich um Code für meine SmartHome-Zentrale.> Da wird ständig erweitert, die ist niemals fertig.
Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome
Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU
leider nicht Codekompatibel ist.
Als Workaround kann man dann auch was richtig großes nehmen und den AVR
darauf komplett emulieren.
Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C
?
P. M. schrieb:> Nein, das ist schon für sich falsch, wie Yalu gezeigt hat - nochmals,> weils so schön ist:
Bitte jeden Tag neu posten, vielleicht liest es Moby ja mal :-)
Moby A. schrieb:> Yalu X. schrieb:>> In C muss man für so etwas nicht bis zum finalen Schritt warten, weil>> mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher>> Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit>> verbunden ist.>> Auch ohne "finale Schritte" bleibt Asm Code effizienter.
Nein.
Vielleicht bei einigen von dir ausgewählten Mickymausprogrammen mit
speziell dafür von dir hin"optimierten" Anforderungen.
Aber definitiv nicht bei deinem 10K-Programm, auf das ich mich bezog.
Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler-
als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat
(und davon gibt es hier im Forum viele), wird dies bestätigen.
Da du selbst aber nicht zu dieser Personengruppe gehörst, bleibt deine
Behauptung einfach nur eine Behauptung, die du ohne jegliche Grundlage
in die Welt hinausposaunst. Die Vehemenz und die Ausdauer, mit der du
dies tust, ändert an dieser Tatsache nicht das geringste.
Michael K. schrieb:> Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome> Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU> leider nicht Codekompatibel ist.
Ja eben. Absolute Sackgasse. Ich persönlich freue mich dass es noch
etwas anderes als AVR gibt und es macht mir außerordentlichen Spaß, zu
sehen, wie einfach doch (portabel geschriebene) C-Programme auf komplett
andere Prozessorfamilien angepasst werden können.
Mobys ASM Smarthome-Projekt ist dann einfach nur noch für die Tonne.
> Als Workaround kann man dann auch was richtig großes nehmen und den AVR> darauf komplett emulieren.
Ja klar, schon heutzutage kann man komplette Sinclair Spectrum Computer
von 1982 mittlerweile auf einem STM32F429 Discovery für ein paar Euro
emulieren. Sogar die Spiele laufen 1:1. :-)
Aber da Moby ja für jedes kleine MickyMaus-Problem auch einen eigenen µC
einsetzt, muss er wahrscheinlich erst Tausende von ATTinys emulieren,
bis er das Licht im Wohnzimmer anschalten kann ;-)
> Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C> ?
Den kann sich Moby dann verkneifen.
Michael K. schrieb:
> Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome> Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU> leider nicht Codekompatibel ist.
Ist doch kein Problem.
Aus dem Thread "CP/M auf AVR" machen wir "AVR auf ARM" oder "AVR auf
JS" und die Assenbler-Sause kann weiter gehen.
Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen
lassen:
- M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander
pappen kann.
- -> das ist doch der Vorwurf an Compiler.
- M.: man muß am Ende eben optimieren.
- M.:(2 Posts später) auch ohne Optimierung ist ASM schneller
Wie er's braucht und ohne jede Scham beim Lügen.
Jeman mit dem man eben nicht ein Bier trinken gehen will.
Carl D. schrieb:> Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen> lassen:> - M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander> pappen kann.> - -> das ist doch der Vorwurf an Compiler.> - M.: man muß am Ende eben optimieren.> - M.:(2 Posts später) auch ohne Optimierung ist ASM schneller
Japp, genau das macht er schon den ganzen Thread hindurch. Er wechselt
ständig von einem (Schein-)Argument zum nächsten. Dass diese in keinster
Weise zusammen passen, hat er entweder nicht gemerkt, oder es ist ihm
egal.
Yalu X. schrieb:> Vielleicht bei einigen von dir ausgewählten Mickymausprogrammen
Ich schlage vor nutzlose Programme die kein RAM benutzen, keiner braucht
und max. 200 bytes groß sind zu Ehren unseres AVR Spar Königs künftig
MobyMausProgramme zu nennen.
Jetzt ist Schluss mit diesem unsäglichen hin und her.
Jetzt kommt der Beweis:
Damit nicht nur ausgwiesene Assembler-Koryphäen und C-Experten diese
Codes verstehen, sondern auch Anfänger etwas mitnehmen können, habe ich
ein sehr einfaches <10K-Beispiel gewählt:
Eine blinkende LED, Blinkfrequenz ca. 2Hz.
Die vorgegebene Hardware:
Atmega88
LED
sowie das übliche Vogelfutter
Das C-Programm:
Takt: 1MHz, intern
1
#ifndef F_CPU
2
#error F_CPU not defined.
3
#endif
4
5
#include<avr/io.h>
6
#include<avr/interrupt.h>
7
8
volatilecharjobflag;
9
10
intmain(void)
11
{
12
charcount=0;
13
TCCR0A=(1<<WGM01);
14
TCCR0B=(1<<CS02)|(1<<CS00);
15
TIMSK0=(1<<OCIE0A);
16
OCR0A=60;
17
DDRB=(1<<1);
18
sei();
19
while(1)
20
{
21
if(jobflag)
22
{
23
jobflag=0;
24
count++;
25
count%=4;
26
if(!count)PINB|=(1<<1);
27
}
28
}
29
}
30
31
ISR(TIMER0_COMPA_vect)
32
{
33
jobflag=1;
34
}
Statistik:
Resourcenverbrauch:
Flash: 164 Bytes
RAM: 1 Byte + Stack
E²PROM 0
Register: einige
Fortgeschrittene oder besser:
Entwicklungszeit: <= 10 Min.
Frustfaktor: keiner
Kenntnisvoraussetzungen: hoch
Anfänger:
Entwicklungszeit: Mit Karl-Heinz' geduldiger Hilfe in einem Thread mit
93 Beiträgen(davon 17 gelöscht) und hilfreichen Tips wie "Kauf dir ein
C-Buch" oder Hinweisen in Form rhetorischer Fragen wie " Hast du kein
Google", dreimal der Antwort "42", einem deftigen Anschiss von c-hater
und einem aufmunternden Gedicht von Paul: 1 Woche
Frustfaktor zu Anfang keiner, voller Elan
Freundin: stinksauer
Frustfaktor: hoch
Freundin: Schluss gemacht
Frustfaktor: noch höher
Frustfaktor: nach dem Anschiss von c-hater stark suizidgefährdet
Frustfaktor: nach dem Gedicht von Paul ging das dann wieder
Lernnotwendigkeit: sehr hoch
Das Assembler-Programm:
Takt: 16KHz, ja Kilohertz!
Taktflankenschonende und stromsparende 16KHz
128KHz intern, Clockprescaler 8
1
sbi$04,1
2
sbi$03,1
Statistik:
Resourcenverbrauch:
Flash: 4 Bytes
RAM: 0, kein Stack
E²PROM 0
Register: 0
Fortgeschrittene:
Entwicklungszeit < 1 Min.
Frustfaktor keiner
Kenntnisvoraussetzungen: egal
Anfänger:
Entwicklungszeit <= 1 Min.
Frustfaktor: keiner
Freundin: hat sie gar nicht mitgekriegt
Frustfaktor: 0
Lernnotwendigkeit: sehr gering, da aus dem Instruction Set nur eine
einzige Anweisung verwendet wird. Alle anderen Anweisungen des Atmega88
werden geschont und können später gelernt werden. Also dann, wenn man
sie braucht.
Resultat:
Resourcenverbrauch, also das einzige, was wirklich zählt:
Flash: 164 Bytes / 4 Bytes = Faktor 41 oder 4100%
RAM und Register werden vom Assembler-Programm gar nicht verwendet.
Das einzige, wo der C-Compiler mithalten kann, ist der E²PROM-Verbrauch.
Im C-Programm steckt sicher noch Optimierungspotenzial. Das
Assembler-Programm dagegen ist unoptimierbar.
Das C-Programm muss für jeden anderen Controller neu kompiliert werden.
Der Opcode des Asm-Programms kann auf alle Atmega und Attiny einfach so
draufgeflasht werden. Einzige Voraussetzung ist, dass sie Pin-Toggle mit
den PIN-Registern können. Manchmal blinken sie etwas schneller oder
langsamer. Aber das läst sich hervorragend als RAM-Größen-Indikator
verwenden.
Das sind die Fakten.
mfg.
Frank M. schrieb:> Habe ich das richtig verstanden? Klasse!
Das hast Du natürlich so verstanden wie Du es brauchst. Hab ich aber
nicht anders erwartet ;-)
Jörg W. schrieb:> Genau: du hast im Anschluss die von Yalu vorgelegte Lösung mal wieder> als irrelevant wegdiskutiert und irgendwelche Details deiner> Implementierung nachträglich zum unbedingt vorhanden sein müssenden> Feature erklärt.
Nimm einfach das zur Kenntnis was ich dazu weiter oben schon gesagt
habe. Ansonsten: Warte auf den entsprechenden Projektthread. Das Thema
ist nicht abgeschlossen.
> Lass mal, ist ein unterhaltsamer Thread, wir wissen, dass du von deiner> Meinung nicht abzubringen bist, nicht einmal durch Beweise.
Doch: Mit einer besseren Lösung als mein entsprechend optimiertes
Asm-Projekt.
Michael K. schrieb:> Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome> Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU> leider nicht Codekompatibel ist.
Meinst Du?
Das bestreite ich. Mein älteres, immer noch in Betrieb befindliches
Home-Control System läuft ja schon mit einem Mega128, in verschiedenen
Ausbauphasen seit 10 Jahren. Von den AVRs hab ich genügend auf Lager.
Und, schonmal in den ersten 2016er Reichelt Katalog geschaut? Da gibts
noch den Z80 ;-)
> Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C> ?
Blöd. Aber der Fall wird nicht eintreten.
Yalu X. schrieb:> Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler-> als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat> (und davon gibt es hier im Forum viele), wird dies bestätigen.
Wer den gleichen Funktionsumfang tatsächlich zweimal kodiert (wer
würde das tun?) und den Asm-Code mit Übung, Vorbereitung und System zu
optimieren weiß würde das nicht bestätigen.
Die meisten aber programmieren ohnehin nur in C.
Frank M. schrieb:> muss er wahrscheinlich erst Tausende von ATTinys emulieren,> bis er das Licht im Wohnzimmer anschalten kann ;-)
Tatsächlich sind es drei Controller:
Die M128 Hauptsteuerung kontrolliert die Stromzuführung, ein alter
Xmega32 schaltet vorort zwischen Licht/Beamer Betrieb um und in der
eigentlichen Lampe steckt noch ein helligkeitsgesteuerter Tiny ;-)
Moby A. schrieb:> Yalu X. schrieb:>> Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler->> als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat>> (und davon gibt es hier im Forum viele), wird dies bestätigen.>> Wer den gleichen Funktionsumfang tatsächlich zweimal kodiert (wer> würde das tun?) und den Asm-Code mit Übung, Vorbereitung und System zu> optimieren weiß würde das nicht bestätigen.
Doch.
Thomas E. schrieb:> Jetzt ist Schluss mit diesem unsäglichen hin und her.>> Jetzt kommt der Beweis:> ....
Mist.
Ausgerechnet heute ist die weiße Fahne in der Wäsche.
Thomas E. schrieb:> Jetzt kommt der Beweis:> ...> Das sind die Fakten.
Ja ganz nett wie Du Dich den Vorteilen von Asm annäherst, wenn auch ein
ganz klein wenig übertrieben ;-)
Carl D. schrieb:> Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen> lassen:
Was Du unfair nennst ist in Wirklichkeit nur Dein Mangel an
Argumenten. Im übrigen, warum lässt Du die Diskussion nicht einfach?
> - M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander> pappen kann. - -> das ist doch der Vorwurf an Compiler.
Quatsch.
> - M.: man muß am Ende eben optimieren.
Hat niemand behauptet.
> Wie er's braucht und ohne jede Scham beim Lügen.
Die fehlt mir zum Beispiel bei Dir. Du wirst mich aber selbst damit
nicht beirren. Kein Wunder, daß Du so keine Punkte machst und
rumjammerst.
Yalu X. schrieb:> Doch.
Nö.
So ein Mist: Wieder Aussage gegen Aussage.
Probiers nochmal mit dem überlegenen Erfahrungsschatz, einer Portion
Lächerlichmachen oder auf die harte Tour: Der Vorwurf der Lüge kommt
immer gut ;-(
@Moby:
Mist, weil du deine letzten zwei Beiträge so schnell hintereinander
gepostet hast, habe ich dein Jubiläum verpasst.
Trotzdem nachträglich herzlichen Glückwunsch zu deinem
1
333 000 000
2
3 3 0 0 0 0
3
3 0 0 0 0
4
33 0 0 0 0
5
3 0 0 0 0
6
3 3 0 0 0 0
7
333 000 000 -sten Beitrag
in diesem Thread :)
Das muss dir erst mal jemand nachmachen.
(Inzwischen sind es sogar schon 301).
Spätestens bei 500 hast du ganz sicher alle hier von ASM überzeugt.
Yalu X. schrieb:> Trotzdem nachträglich herzlichen Glückwunsch.
Du überrascht mich.
Mit einem Glückwunsch zu irgendwelchen Beitragszahlen hab ich nicht
gerechnet. Mir tuts bloß um die armen Minuspunktbewerter leid die hier
soviel zu tun haben :-)
Ich will Dich aber auch mal überraschen:
Nämlich damit daß mir Beitragszahlen relativ schnuppe sind. Mich
interessiert doch tatsächlich das Thema und ich hatte so gehofft, daß
ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an
Effizienz gewinne... Ich geb die Hoffnung aber nicht auf ;-)
Moby A. schrieb:> wenn auch ein ganz klein wenig übertrieben
Was ist denn daran übertrieben?
Willst du etwa von der mangelnden Effienz in deinem Code ablenken?
Ich benutze nicht einmal die Register!
Und schummele auch nicht beim RAM!
Und ich habe den C-Code zum Vergleich zum beigefügt!
Das sind Fakten, denen nicht widersprochen werden kann.
mfg.
Moby A. schrieb:> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an> Effizienz gewinne.
Das könntest du, wenn du es nur wölltest – allerdings wahrscheinlich
nicht so sehr in deinem Sinne. Du würdest deine Entwicklungszeit
nämlich schätzungsweise zehnteln können, und dennoch passt das
alles noch ins gleiche Device rein. Davon abgesehen, mit nur wenigen
Cent mehr (ATtiny25 oder 45 statt 13) bekämst du eine in vielerlei
Hinsicht schönere Hardware zusätzlich zu mehr Platz geboten (wir
hatten gerade erst das Thema Messung der Batteriespannung mit dem
ADC ohne zusätzliche äußere Beschaltung, das geht mit dem 13 nicht,
mit dem 25 schon). Da du ja dann massig Zeit gewonnen hättest,
könntest du den nun gewonnenen Platz sogar mit weiteren Features
beleben. :-)
Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz
gewiss die letzten, die dir bei entsprechenden Fragen dann nicht
genauso zur Seite stehen würden, wie wir das mit jedem anderen tun.
Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der
gewillt ist, was zu lernen, die Sachen erklärt.
Kinder, streitet Euch doch nimmer... Mir kommt das vor wie der Streit um
den Bart des Kaisers.
Wie man zum Ziel kommt kann an sich ganz interessant sein, aber, mir ist
es ehrlich gesagt bei normalen, im Ablauf nicht superkritischen
Kriterien konformen Applikationen eigentlich ziemlich wurscht wieviel
Resourcen innerhalb eines vernünftigen Rahmens verbraucht werden solange
allen Erfordernissen Geltung gegeben wurde und das uC Programm die
gestellten Anforderungen einwandfrei erfüllt. Bei den modernen uC
braucht man doch mit den Resourcen wirklich nicht mehr soo knausrig
sein. Die Computersprache wurde ja nur für den Menschen erfunden und für
den Mikroprozessor sind alles was über Maschinensprache hinaus geht,
sowieso nur Hieroglyphen.
Es ist ja beeindruckend wenn man alles mit den internen Register
erledigen kann. Aber, does anybody really care very much? Ohne Moby hier
auf die Füße steigen zu wollen. Wenn dem uC von seinem Erzeuger RAM
gegeben worden ist, dann soll man es ruhig verwenden.
Da ich oft nur wenig Zeit habe möchte ich möglichst schnell ans Ziel
kommen. In C kann ich das viel besser wie in ASM, weil ich dort eben
erschreckend rostig bin und es nur in Extremfällen in inline einsetze.
Um ganz ehrlich zu sein, mir liegt ASM überhaupt nicht. Abgesehen davon
ist für mich die Wiederverwendung von funktionierenden Funktionen in C
einfacher und die Portierung von funktionierenden Code auf andere uC
viel einfacher.
Trotz aller (zu Tode diskutierten) nachgesagten Mängel der Sprache kommt
man doch in C praktisch meist trotzdem ganz gut zurecht. Was ist schon
perfekt in dieser Welt? In C fühlt man sich immer nahe genug an der
Hardware und das reicht mir. Für wirklich komplizierte Anwendungen
(Stacks) müssen natürlich andere Maßstäbe angelegt werden und ist der
Domain für wirkliche Experten.
Letzten Endes zählt nur die Erfüllung aller gesetzten Aufgaben mit
vernünftigen Aufwand.
Ehrlich gesagt finde ich man sollte diesen Thread hier ganz sanft und
leise einschlafen lassen.
Aber wie bei uns das Sprichwort sagt: "Opinions are like as...les,
everybody's got one". So belassen wir es besser bei dem gesagten...
Grüße aus dem verschneiten Alberta,
Gerhard
M.:
> Hat niemand behauptet.
Das werden aber die gefùhlt 50 Zeugen ganz anders sehen, Herr Miemand!
M.:
> Mich interessiert doch tatsächlich das Thema
Und von der Sorte gibt's hier viele.
Nur wenn man sich ernsthaft für den Vergleich interessiert, dann
braucht man zwei Dinge zum vergleichen. Wer sich nur über das
Funktionieren der ASM-Version freut, dem fehlt die Vergleichsgrundlage.
In C ist das einfacher. Da hat man nämlich auch die ASM-Version
vorliegen (ja, oh Wunder, der Compiler erzeugt ASM-Code, den dann ein
Assembler verlautbar für den kleinen AVR macht) und kann schnell
feststellen, ob man da händisch noch viel rausholen kann. Setzt aber
Mehrsprachigkeit voraus.
Jörg W. schrieb:> Ich kenne nur diese „helligkeitsgesteurten“ alten sowjetischen ICs.
Wenn man ein EPROM falsch herum in den Programmiersockel steckt und das
Programmiergerät genügend Puste hat, leuchten die auch. Erst weiss, dann
rot, dann schwarz. Aber ein Tiny hat ja ga kein EPROM und beheizt wird
er auch nicht.
mfg.
Jörg W. schrieb:> Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz> gewiss die letzten, die dir bei entsprechenden Fragen dann nicht> genauso zur Seite stehen würden, wie wir das mit jedem anderen tun.> Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der> gewillt ist, was zu lernen, die Sachen erklärt.
Zumal man ihm ja eigentlich gar nicht mehr so viel erklären müsste. Die
AVR Hardware kennt er ja in und auswendig.
Und Hand aufs Herz. So schwer ist ein
1
DDRD=0xFF
dann auch wieder nicht zu verstehen. Links steht das Ziel, rechts was in
dieses Ziel hinein soll. Was rechts stehen muss, weiss er ja. Das kennt
er zur Genüge. Welches Register links stehen muss, die kennt er auch
alle. Nur sollte man sich von der direkten Angabe von Hex-werten gerade
bei der Konfiguration von Registern trennen, auch wenn man das in C
selbstverständlich genausogut machen kann.
Und trennen sollte man sich auch davon, die genau Kontrolle über diese
Operation auf Registerebene zu verlangen. 0xFF landet im Register DDRD.
Punkt. Wie das genau funktioniert ist Sache des Compilers. Will ich gar
nicht wissen. Genausowenig wie ich wissen will, ob ich dafür einen OUT
oder einen STS brauche. Das der Compiler da nicht übertreibt, und aus
dem ein Monster macht, sondern genau dasselbe erzeugt, was auch
Assembler Programmierer benutzen würde, davon kann man sich natürlich im
Listing überzeugen. Aber nach dem 20 mal überzeugen, gibt man das
einfach auf. weil der Compiler immer die vernünftigste Lösung generiert
hat.
Jörg W. schrieb:> Thomas E. schrieb:>> Das ist das Steuerelement.>> Nur schade, dass man es nach jedem Steuervorgang ersetzen muss. :-)
Oh, und ich dachte schon, man stellt so OTP Speicher her...
Jörg W. schrieb:> Nur schade, dass man es nach jedem Steuervorgang ersetzen muss.
Ja, das ist richtig. Das hat man aber hauptsächlich als Bombenzünder
benutzt. Da relativiert sich der Nachteil.
mfg.
Thomas E. schrieb:> Das hat man aber hauptsächlich als Bombenzünder benutzt.
Mensch, jetzt hast du diesen friedlichen Thread bei allein
Drei-Buchstaben-Agenturen auftauchen lassen!
Jörg W. schrieb:> Mensch, jetzt hast du diesen friedlichen Thread bei allein> Drei-Buchstaben-Agenturen auftauchen lassen!
Ich meinte Arschbomben.
mfg.
Hoffentlich kam das jetzt noch rechtzeitig.
Thomas E. schrieb:> Moby A. schrieb:>> ein helligkeitsgesteuerter Tiny>> Du hast einen helligkeitsgesteuerten Tiny?
Da hab' ich doch glatt was vom "heiligkeitsgesteuerten Shiny" gelesen.
Moby A. schrieb:>> Wie er's braucht und ohne jede Scham beim Lügen.>> Die fehlt mir zum Beispiel bei Dir.
Hör jetzt einfach mal auf mit dem Blödsinn. Du hast keine Argumente, du
gehst nicht auf Gegenargumente ein, du verdrehst Aussagen, du tischst
Lügen auf. Du bist zwar mittlerweile dazu über gegangen, deinen Gegnern
das selbe zu unterstellen, aber das ist einfach Quatsch. Oder hast du
das Gefühl, die Diskussionsteilnehmer würden sich das gegenseitig
einfach so durchgehen lassen? Warum ist hier wohl alle-gegen-einen? Weil
die Sache umstritten ist? Oder doch eher, weil wir aus welchen Gründen
auch immer einfach Spass an einem Fast-Troll wie dir haben?
Langsam frage ich mich wie viele flames notwendig sind diesen war den
politischen gleichzusetzen und ihn zu sperren sowie Fortsetzungen zu
untersagen.
an Sinnlosigkeit stellt und Resuorcenverschwendung sowie Beleidigungen
hält er locker mit jedem Politthread mit.
Namamste
Thomas E. schrieb:> Das sind Fakten, denen nicht widersprochen werden kann
Sagen wir mal so: Dein Asm Code wirkt etwas unflexibel ;-)
Jörg W. schrieb:> Du würdest deine Entwicklungszeit> nämlich schätzungsweise zehnteln können, und dennoch passt das> alles noch ins gleiche Device rein.
Sicher. Siichchcher. Sagte schon Hausmeister Krause!
> Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz> gewiss die letzten, die dir bei entsprechenden Fragen dann nicht> genauso zur Seite stehen würden, wie wir das mit jedem anderen tun.> Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der> gewillt ist, was zu lernen, die Sachen erklärt.
Ganz hervorragend! Bitte weiter so! Kann man nicht hoch genug
einschätzen! Ich selbst bin allerdings mit dem AVR, programmiert in Asm
rundumst zufrieden und muß Problemstellungen nicht unbedingt
komplizierter lösen als nötig.
Gerhard O. schrieb:> Letzten Endes zählt nur die Erfüllung aller gesetzten Aufgaben mit> vernünftigen Aufwand.
Das sehe ich auch so (mit AVR/ASM gegeben).
Carl D. schrieb:> Nur wenn man sich ernsthaft für den Vergleich interessiert, dann> braucht man zwei Dinge zum vergleichen.
Tatsächlich? Waren wir nicht schon soweit? Warum reite ich dann so auf
der Notwendigkeit entsprechenden Vergleichsmaterials für meinen
Projektcode herum? Der nicht kommt? Von den vielen großen C Experten
hier für die das ein Leichtes sein könnte?
> Wer sich nur über das> Funktionieren der ASM-Version freut, dem fehlt die Vergleichsgrundlage.
Manchmal hat man, hab ich, auch Tomaten auf den Augen. Das betrifft aber
weniger die Asm-Implementierung als vielmehr die grundsätzliche
Herangehensweise an ein Problem, da wär kein Unterschied zu C.
> In C ist das einfacher. Da hat man nämlich auch die ASM-Version> vorliegen (ja, oh Wunder, der Compiler erzeugt ASM-Code, den dann ein> Assembler verlautbar für den kleinen AVR macht) und kann schnell> feststellen, ob man da händisch noch viel rausholen kann. Setzt aber> Mehrsprachigkeit voraus.
Wieviel Prozent der C-Programmierer dem resultierenden Asm-Code wohl
noch Beachtung schenken?
Thomas E. schrieb:> Wenn man ein EPROM falsch herum in den Programmiersockel steckt und das> Programmiergerät genügend Puste hat, leuchten die auch. Erst weiss, dann> rot, dann schwarz. Aber ein Tiny hat ja ga kein EPROM und beheizt wird> er auch nicht.
Logischer Fehler. Setzen. Sechs.
Von Selbst-Leuchten war ja hier schon mal gar nicht die Rede ;-)
Karl H. schrieb:> Und Hand aufs Herz. So schwer ist ein DDRD = 0xFF> dann auch wieder nicht zu verstehen.
Das ist ja zuckersüß...
Jo mei, wenn die C-Zeilen Welt immer so schön simpel wär ;-)
> Genausowenig wie ich wissen will, ob ich dafür einen OUT> oder einen STS brauche.
DAS will ich auch nicht. Entweder (meistens) weiß ich das sowieso und
wenn nicht probiert man einfach erstmal OUT. Der Assembler meckert
schon...
Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den
Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir
mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr
helfen...
Winfried J. schrieb:> an ... Beleidigungen> hält er locker mit jedem Politthread mit.
Meintest Du die Tausend Beleidigungen mir gegenüber oder meine
Beleidigung der C-Fraktion, daß Asm-Code manchmal besser wär?
Erstere sollte man nicht so in die Goldwaage legen.
Die sind immer ein Ausdruck des 'Nicht mehr weiter Wissens' ;-)
Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht
ja nicht. Ich hoffe das bessert sich wieder!
Moby A. schrieb:> Wieviel Prozent der C-Programmierer dem resultierenden Asm-Code wohl> noch Beachtung schenken?
Oh, den schau ich mir immer an wenn die Performance zu wünschen übrig
lässt, mir die Ressourcen ausgehen oder trotz korrektem C das Kompilat
einen Fehler enthält.
Also eigentlich nie.
Moby A. schrieb:> Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den> Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir> mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr> helfen...
"Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn
helfen? Hilfst Du irgend jemandem im Forum, wenn er ein ASM-Problem
hat?
Ich lese hier nur selbstdarstellende Beiträge von Dir.
P.S.
Dir ist sowieso nicht zu helfen.
@ Moby
wir beide haben zumindest gemein die Verachtung Anderer auf uns zu
ziehen weil wir unseren jeweiligen Standpunkt konsequent vertreten.
Deinen Standpunkt volle Programmablaufkontrolle auch die zeitliche durch
direkte ASM Programmierung zu erreiche teile ich im übrigen auch.
dies hat jedoch seinen Preis:
Maschinennahe Programmierung erschwert die Übersichtlichkeit. Das lässt
sich mit Macros zwar verbessern. Trotzdem bleibt es aufwendig.
Die Effizienz des erzeugten Codes hängt im hohen Maße vom komplex
logischen vermögen des Programmierers mit gleichzeitig hohem
Abstraktionsvermögen ab. Hier bieten Hochsprachen
Arbeitserleichterungen für den Programmierer. Zum Preis des Verstehens
des vom Compiler erzeugten ASM durch den Hochsprachen Programmierer.
Die Codeeffizienz eines lausigen Hochsprachenprogrammierers ist sicher
noch größer als die eines mittelmäßigen ASM Fetischisten
Nachdem HW heute billiger als SW-Entwicklungszeit (Programmiererlohn)
ist
ist ausgereizte ASM Programmierung schlicht zu teuer.
Im Übrigen empfinde ich Hochsprachen bequemer und nutze sie im
Bewusstsein,
dass ich nicht jedes Byte kenne, welches der Compiler daraus bastelt,
oder den genauen Ablauf einer Interpreterfunktion nicht kenne.
Einen Blick in den erzeugten Compiler-Code oder eine Interpreterroutine
ist allemal lehrreich.
Namaste
Moby A. schrieb:> Ich selbst bin allerdings mit dem AVR, programmiert in Asm rundumst> zufriedenMoby A. schrieb:> Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft,> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an> Effizienz gewinne...
Aha.
Moby A. schrieb:> Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft,> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an> Effizienz gewinne...
Moby, da hilft nur Übung, Vorbereitung, System.
Moby A. schrieb:> Sagen wir mal so: Dein Asm Code wirkt etwas unflexibel
Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken?
Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich
aus diesem nur einen einzigen Befehl verwende. Von der Kompaktheit des
Codes und dem flankenschonenden und stromsparenden Takt ganz zu
schweigen.
Das Programm ist in jeder erdenklicher Weise höchstoptimiert und stellt
somit Krone der Programmierkunst dar.
Das ist die ideale Effizienz. Das sind die unwidersprochenen Fakten!
mfg.
Und Moby macht einfach weiter, als wäre nichts gewesen. Obwohl Yalu in
einem Beispiel nun wirklich UNZWEIFELHAFT nachgewiesen hat, dass man
Assembler sogar bei Mini-Programmen mit C schlagen kann.
Einfach nochmals, für die Nachwelt, damit nie jemand auf die Idee kommen
wird, Moby's Theorien hätten auch nur ein Quäntchen Bedeutung:
Moby A. schrieb:> Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht> ja nicht.
Wozu Gegenargumente?
Haben wir hier in den letzten Tagen ein einziges Argument von Dir
gesehen?
Moby A. schrieb:> Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht> ja nicht. Ich hoffe das bessert sich wieder!
- Obwohl du als Hobbyist gegen eine ganze Horde an erfahrenen Profis
antrittst,
- obwohl ein halbes Forum deiner Einzelmeinung geschlossen widerspricht,
- obwohl du keine deiner Behauptungen belegen konntest,
- obwohl klare Gegenbeweise gegen deine Thesen bestehen,
- obwohl du einen Teil des Diskussionsgegenstands (Programmiersprache C)
nicht mal kennst,
=> benimmst du dich immer noch so, als wärst du im Recht und die anderen
auf dem Holzweg.
P. M. schrieb:
—————————————————————————————————————————————————
> Flash-Verbrauch 266 256> RAM-Verbrauch¹ 6 + 1 GPIOR 9> Stack-Verbrauch 2 4> Quellcodezeilen² 143 91> Quellcodezeichen³ 1614 1707> —————————————————————————————————————————————————> ¹) ohne Stack> ²) ohne Leer- und Kommentarzeilen> ³) ohne Kommentare, Leerraum und Zeilenvorschübe>> Compiler: GCC 4.7.4> Assembler/Linker: Binutils 2.25.1> C-Standardbibliothek: AVR-Libc 1.8.1
Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features
bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert.
le x. schrieb:> Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features> bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert.
Ein echter Nachteil von C.
Durch die bessere Lesbarkeit können auch untalentierte Programmierer nun
guten Code schreiben was langfristig zu schlechteren Programmierern
führt.
(Im Sinne von ASM Verständniss)
Zudem werden die Produktzyken kürzer weil gute Produkte schneller
entwickelt sind.
Die Menschen gewöhnen sich daran das fette Features schnell und
zahlreich zu etabieren sind und schrauben ihre Erwartungshaltung ständig
höher.
Das wiederum ist ein echtes Ressourcen / Umweltproblem.
Nur durch kurzlebige Modeerscheinungen wie Hochsprachen ist es überhaupt
möglich geworden ständig neue MCUs auf den Markt zu werfen.
Hardcore ASM Götter würden freiwillig nicht so schnell wechseln.
Dadurch das nun viele etwas können was vorher wenigen vorbehalten war
wird auch die Bezahlung schlechter.
Hochsprachen sind ausserdem eine Bedrohung für Frieden und Freiheit.
Weder flächendeckende Kommunikationsüberwachung, noch Gesichtserkennung,
Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät
wäre in der Form denkbar.
Hochsprachenprogrammierer sind Diener des Bösen.
Zwangsläufig wird die Gesellschaft sich davon befreien müssen indem
selbige nach nordkoreanischem Vorbild umerzogen werden.
Innovative deutsche Unternehmen haben das bereits erkannt und gerade
noch rechtzeitig ihren Betrieb eingestellt (Addison Wessley, Data
Becker)
[Die heutige Bücherverbrennung wird Ihnen präsentiert von: O'Reilly)
Michael K. schrieb:> le x. schrieb:> Ein echter Nachteil von C.> Durch die bessere Lesbarkeit können auch untalentierte Programmierer nun> guten Code schreiben was langfristig zu schlechteren Programmierern> führt.> [...]> Das wiederum ist ein echtes Ressourcen / Umweltproblem.> [...]> Hochsprachen sind ausserdem eine Bedrohung für Frieden und Freiheit.> Weder flächendeckende Kommunikationsüberwachung, noch Gesichtserkennung,> Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät> wäre in der Form denkbar.> [...]
Rettet die Welt, Programmiert ASM :^)
Michael K. schrieb:> Dadurch das nun viele etwas können was vorher wenigen vorbehalten war> wird auch die Bezahlung schlechter.
Zum Glück trifft das nicht auf die echten ASM-only-Programmierer zu.
Diese Helden, die sich ihren Fokus nicht durch die Verlockungen der
Hochsprachen-Sirenen haben verwässern lassen, sind heute in der
Industrie gefragte Experten, die locker mit dem Doppelten eines
Durchschnittsgehalts rechnen dürfen.
Gruß, Stefan
Michael K. schrieb:> Zudem werden die Produktzyken kürzer weil gute Produkte schneller> entwickelt sind.
Eben. In Assembler programmiert würde Microsoft nicht immer wieder die
Benutzeroberfläche auf den Kopf stellen und die Hälfte aller Knöpfe neu
verteilen. Es wäre eine Wohltat für viele Anwender. ;-)
Stefan K. schrieb:> sind heute in der> Industrie gefragte Experten, die locker mit dem Doppelten eines> Durchschnittsgehalts rechnen dürfen.
Dafür aber die 10-fache Entwicklungszeit benötigen und somit locker das
zwanzigfache pro Programm verdienen.
Asm-Effizienz in höchster Vollendung.
mfg.
A. K. schrieb:> Eben. In Assembler programmiert würde Microsoft nicht immer wieder die> Benutzeroberfläche auf den Kopf stellen und die Hälfte aller Knöpfe neu> verteilen. Es wäre eine Wohltat für viele Anwender. ;-)
Womit wir uns auch mal um den Blödsinn der hochauflösenden Farbmonitore
kümmern sollten.
Eingabefelder und Schieberegler sind seit Win 10 bei meinem billigst
Notebook fast nicht zu erkennen.
So ein Problem hatte ich auf meinem C64 mit dem Bernsteinmonitor nie.
Dieser ganze neumodische Schnickschnack hat doch mit diesem Tesla
angefangen und seiner Schnapsidee alle Haushalte zu bestromen.
Seit dem nur noch Hektik, Zeitdruck und arbeiten bis spät in die Nacht.
Probleme lösen die wir ohne Computer garnicht hätten.
Vorher:
Rentervorsorge? Ich bitte Dich, bei der Lebenserwartung ?
Schlafen wenn die Sonne untergeht, aufstehn wenn der Hahn kräht.
Moby hat das zugrunde liegende Problem gut erkannt, er setzt nur viel zu
spät an.
Die Kontrolle hätten wir behalten wenn wir nie von den Bäumen
runtergekommen wären. Ach was sage ich da, der Molch war doch in unserer
Evolution die glücklichste aller Daseinsformen.
Kein Stress und zu blöd sich Sorgen darum zu machen das man gefressen
werden könnte.
Ressourcenverbrauch ?
Da schneidet der Molch aber um Welten besser ab.
Wenn ich sehe was wir mit unserm ach so tollen Gehirn anstellen das weit
überdurchschnittlich viel Energie verbraucht, so ist dieser Thread das
beste Beispiel dafür das der Molch uns da klar überlegen ist.
Frank M. schrieb:> Moby A. schrieb:>> Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den>> Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir>> mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr>> helfen...>> "Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn> helfen? Hilfst Du irgend jemandem im Forum, wenn er ein ASM-Problem> hat?
Das wiederrum ist interessanterweise eine Eigenschaft, die er mit den
restlichen Assembler-über-alles Verfechtern teilt. Wenn es um ein
Assembler Problem geht, glänzen sie so gut wie fast immer .... durch
Abwesenheit.
le x. schrieb:> Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features> bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert.
@P.M.: Kannst du das bitte in das täglich zu wiederholende Posting
(Murmeltier) mit aufnehmen? Danke.
Michael K. schrieb:> Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät> wäre in der Form denkbar.
Der erste Marschflugkörper kam völlig ohne Programm aus. Der hatte
keinen einzigen Transistor drin, vielleicht nicht einmal Röhren.
Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden.
A.K. ist vom Glauben abgefallen:
Beitrag "Re: Eigenes Dev. Board für vintage CPU bauen"A. K. schrieb:> Ausserdem kann man beim 1802 leichter als irgendwo sonst auf total> überflüssige Hochsprachen wie Makro-Assembler verzichten und direkt in> Hex programmieren. Liest sich in kurzer Zeit fast genauso gut wie> normaler Assembler.
A.K. es ist noch nicht zu spät.
Kehre zurück auf den Pfad der Tugend und schwöre ab den falschen
Propheten.
Michael K. schrieb:> Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden.> A.K. ist vom Glauben abgefallen:
Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der
Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht
flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-)
Frank M. schrieb:> Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der> Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht> flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-)
Ging mir ähnlich beim 6502: Der Apple hatte in seinem Monitor-ROM zwar
einen einfachen Disassembler, aber keinen Assembler. Bei typischen
8-Bit-Anwendungen tippte man deswegen das Programm einfach als Hexcodes
ein und überprüfte anschließend deren Richtigkeit mit dem Disassembler.
Innerhalb kurzer Zeit kannte ich die Hexcodes für 90% der Befehle
auswendig, den selten genutzten Rest¹ musste ich halt nachschlagen.
Da ich irgendwann aber auch nichttypische 8-Bit-Anwendungen (d.h. mit
mehr als 200 Bytes) programmieren wollte, kaufte mir dann aber doch
einen Assembler.
Selbst die komplizierteren 16-Bit-Opcodes des 68000 konnte man sich gut
merken, da sie größtenteils nach einem einheitlichen Schema aufgebaut
sind. Da die Quell- und Zieladdressierungsart und -register von rechts
her jeweils als 3-Bit-Gruppen kodiert sind, nutzte man statt der
hexadezimalen die oktale Schreibweise.
Auch damit hatte ich einige Progrämmchen geschrieben, die ich aber nicht
als "typische 16-Bit- Anwendungen" bezeichnen würde ;-)
————————————
¹) Nein, Moby, der EOR-Befehl zählte nicht zu diesem Rest, der war unter
den 90% häufig genutzten Befehlen ;-)
Frank M. schrieb:> Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der> Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht> flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-)
Ist aber bei 8080-Code einfacher als bei optimiertem Z80-Code. Die
Rechnerei der relativen Sprünge ist ziemlich umständlich. Das ist das
schöne am 1802, der hat zwar kurze Sprünge, aber ohne umständliche
Rechnung. Da wird bloss das untere Byte der Programmadresse ersetzt.
Gegenüber der Oktalcodierung von 8080 besteht zudem der Vorteil, dass
etliche Befehle hexcodiert aufgebaut sind. Also 4-Bit Opcode und 4-Bit
Registernummer. Einfacher gehts nicht.
A. K. schrieb:> Die Rechnerei der relativen Sprünge ist ziemlich umständlich.
Das stimmt, aber die absoluten des 8080 gab's ja trotzdem noch,
insofern erstmal kein Nachteil.
Habe aber inzwischen fast alle vergessen. Kann mich nur noch an AF
und 21 xx xx erinnern. ;)
Einen kleinen Nachteil der Hex-Programmierung des 1802 muss ich aber
noch erwähnen: Nirgends hat man so viel Sex wie in 1802 Assembler
Programmierung. In Hex verschwindet der völlig aus den Augen.
http://www.atarimagazines.com/computeii/issue3/page52.php
Karl H. schrieb:> Und Hand aufs Herz. So schwer ist ein DDRD = 0xFF> dann auch wieder nicht zu verstehen.
Hmmm lass mal überlegen...
Moby A. schrieb:> Das ist kryptischer Kauderwelsch für Eingeweihte.> Dessen Studium ist für 8-Bit MSR überflüssig ;-)
le x. schrieb:> P. M. schrieb:> —————————————————————————————————————————————————>> Flash-Verbrauch 266 256>> RAM-Verbrauch¹ 6 + 1 GPIOR 9>> Stack-Verbrauch 2 4>> Quellcodezeilen² 143 91>> Quellcodezeichen³ 1614 1707>> —————————————————————————————————————————————————>> Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features> bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert.
Schon erstaunlich was man aus -10 Bytes alles herausholen kann ;-)
Frank M. schrieb:> Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der> Opcodes als Hex-Zahlen erstellt.
Na gut, dann muß ich beichten das ich das beim 8085 ebenso gemacht habe.
Man hatte ja keinen Vergleich und hat sich deswegen über jeden Befehl
gefreut der ausgeführt wurde.
Aus heutiger Sicht so spannend wie Lack beim trocknen zuzusehen.
Der 8031 war dagegen wie Balsam auf meine wunde Seele.
Timer, Ram, Uart alles in einem Chip.
Nur noch Eprom und A/D Latch ran und es lief (naja + ein paar Bauteile)
Das war so schön, ich hätte weinen können.
Der 8751 war mein größter Schatz und sein Gewicht in Gold wert.
4K on Chip ! Der brutale Wahnsinn.
Der 8085 endete quasi sofort als Türstopper.
Heute empfinde ich das als Zumutung wenn ich mehr als 30Cent ausgeben
muß für so eine kleine Gurke und dann auch noch mehr brauche als zwei
Kerkos um damit was zu machen.
Flash, ISP, OCD sind so selbstverständlich das ich erst solche Threads
brauche um mich an all die Klimmzüge und Leiden zu erinnern die damals
selbstverständlich waren.
Warum man die Hardwaresegnungen der 'neuen Zeit' mitnimmt aber sich
softwaremäßig (ASM) nicht weiterentwickelt kann ich persönlich nicht
nachvollziehen.
Frank M. schrieb:> Michael K. schrieb:>> Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden.>> A.K. ist vom Glauben abgefallen:>> Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der> Opcodes als Hex-Zahlen erstellt.
Was seid ihr denn für Wappler? :-)
Mein erster Z80 Eigenbau bekam sein erstes Programm
1
0xxxxx 0x76 HALT
indem ich mit Drahtbrücken im EEPROM Sockel den Befehl direkt am
Datenbus gesteckt habe. Der Chip Select Adressdecoder war noch nicht
fertig :-) Ich war stolz wie nachbars Lumpi, als das (geschenkte)
Phillips Voltmeter am Halt Pin den Zeiger nicht bewegte, während es bei
einem gesteckten
1
0xxxxx 0x00 NOP
brav mit einem Ausschlag die 5V vermeldete.
> Mit ein wenig Übung geht das recht> flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-)
Ja doch das ging schon. Das einzige bei dem ich am Anfang immer Probleme
hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie?
Michael K. schrieb:> Heute empfinde ich das als Zumutung wenn ich mehr als 30Cent ausgeben> muß für so eine kleine Gurke und dann auch noch mehr brauche als zwei> Kerkos um damit was zu machen.
Vor allen Dingen kein potentes Netzteil mehr :-)
Mit einem nackten Z80, bisschen Kleinkram rundum und eben das übliche
(EPROM, RAM, 8255, 8251), war man mit einem 1A Netzteil auf der 5V
Schiene nicht wirklich krass überdimensioniert. :-)
heißen? ;-)
Nein, einen EPROM hatte ich schon zu Anfang. Allerdings natürlich
keinen LA, mit dem man die Verdrahtungsfehler hätte suchen können,
nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und
Adressbus). Zum schrittweisen Durchschalten hab' ich mir dann eine
kleine Hardwaremimik gezimmert, die nach je einem Befehl immer wieder
/WAIT gezogen hat. Nach ein oder zwei Stunden war dann der Kurzschluss
auf einem der Busse gefunden.
Das Lösen des Henne-und-Ei-Problems für die ersten EPROMs benötigte
allerdings einen in Hardware gezimmerten Eprommer. Wehe dem, man
hatte sich bei einem der Bytes beim Eingeben vertan, dann musste
man von vorn anfangen. Computergesteuerten Eprommer habe ich dann
erst später gebaut. Passend zum Thema des Threads: dessen
Bediensoftware wurde in Turbo-Pascal geschrieben. Dadurch ließ sich
doch einiges an Bedien-Komfort mit vertretbarem Aufwand erreichen,
was ich mir hätte bei reiner Assemblerprogrammierung nicht antun
wollen. Nur die innerste Schleife habe ich nach dem initialen
Funktionstest dann in Inline-Assembler nachprogrammiert, damit er
schnell genug wurde.
Karl H. schrieb:> Was seid ihr denn für Wappler? :-)
Moment .....
https://de.wiktionary.org/wiki/Wappler
Aha !
Karl H. schrieb:> Das einzige bei dem ich am Anfang immer Probleme> hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie?
Da hilft nur: Übung, Vorbereitung, System
>> heißen? ;-)
Mea Culpa. Da hat wohl die C-Bürokratie die Oberhand gewonnen.
> Nein, einen EPROM hatte ich schon zu Anfang. Allerdings natürlich> keinen LA,
War ja auch unbezahlbar für einen Studenten.
Die 100 Mark wurden lieber in ein paar kB Speicher investiert.
> mit dem man die Verdrahtungsfehler hätte suchen können,> nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und> Adressbus).
Nobel.
Ich hatte Glück. Meinen Z80 konnte ich mit einer LED (und einem
Durchgangsprüfer, gebaut aus einem alten Texas Instruments Akkufach +
LED + 220 Ohm + Draht) in Betrieb nehmen und verifizieren, dass er
funktioniert.
> Das Lösen des Henne-und-Ei-Problems für die ersten EPROMs benötigte> allerdings einen in Hardware gezimmerten Eprommer.
:-)
Das war ein echtes Problem.
In der mc gab es einen Eprommer, der im Prinzip nur ein Schieberegister
war. An sich super. Nur, wie ansteuern, wenn der Rechner noch nicht
läuft. Ein Kumpel mit einem TRS80 hat mir dann aus der Patsche geholfen.
> erst später gebaut. Passend zum Thema des Threads: dessen> Bediensoftware wurde in Turbo-Pascal geschrieben.
Das hatte wohl jeder. D.h. sofern er sich ein Floppy Laufwerk leisten
konnte und unter der Hand ein CP/M irgendwo herbekam :-)
Karl H. schrieb:> D.h. sofern er sich ein Floppy Laufwerk leisten konnte
Welch ein Luxus.
Dump über die serielle Schnittstelle auf ein 1200er Modem und die
frequenzmodulierten Daten mit einem Kassettenrekorder aufgezeichnet.
Das war cool.
mfg.
Karl H. schrieb:> Mea Culpa. Da hat wohl die C-Bürokratie die Oberhand gewonnen.
Ja, da kannst du sehen, wohin diese Bürokratie noch führt!
>> nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und>> Adressbus).>> Nobel.
Die Anzeigebaugruppe wurde auch am Primitiv-Eprommer genutzt. Sie
bestand aus einer VQD30:
http://www.pollin.de/shop/dt/MDY3OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LED_Display_VQD30.html
einem BCD-7-Segment-Decoder (U40511, der hat auch die Hex-Zahlen
korrekt angezeigt) und Multiplexern, mit denen reihum die Busse
abgefragt wurden.
>> erst später gebaut. Passend zum Thema des Threads: dessen>> Bediensoftware wurde in Turbo-Pascal geschrieben.>> Das hatte wohl jeder. D.h. sofern er sich ein Floppy Laufwerk leisten> konnte und unter der Hand ein CP/M irgendwo herbekam :-)
Naja, Software war in der DDR kein Problem :), die wurde ja auch
ganz offiziell von robotron als Clone vertrieben. Beliebt war die
CP/A genannte Version des Instituts für Informatik an der Akademie
der Wissenschaften. Irgendwoher bekam man da auch ein Turbo-Pasal,
auf welchen Wegen die genau von Diskette zu Diskette gefunden haben,
hat damals hier keinen interessiert …
Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB),
sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte.
Jörg W. schrieb:> Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB),> sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte.
Krösus :-)
Ich hatte mir als Österreicher in München 2 Floppy Laufwerke erstanden.
Haben ein Schweine-Geld gekostet. Da kriegst heute einen ganzen PC drum,
und dann bleibt noch was übrig.
Mann war ich sauer, als mir beim Basteln das Krokoklemmenkabel
abgeschnippt ist. Blöderweise war es die GND-Leitung und das freie Ende
fiel auf die 230V Phase. Und vorbei wars mit den Laufwerken ... und dem
VT100 ... und überhaupt dem meisten in der als Gehäuse benutzen
Holzkiste. Eines der Laufwerke konnte ich noch retten, in dem ich auf
einem defekten IC (war irgendeine Gatter-Sache) einen weiteren IC
huckepack aufgeklebt und mit Fädeldraht angeschlossen habe. Aber das
2.te machte keinen Mucks mehr.
:-)
Und ich brings trotzdem nicht übers Herz, den 30 Jahre alten Krempel zu
entsorgen.
:-)
Thomas E. schrieb:> Karl H. schrieb:>> D.h. sofern er sich ein Floppy Laufwerk leisten konnte>> Welch ein Luxus.>> Dump über die serielle Schnittstelle auf ein 1200er Modem und die> frequenzmodulierten Daten mit einem Kassettenrekorder aufgezeichnet.> Das war cool.
Das war auch schon so ziemlich das einzige, was ich nie gemacht habe.
Hätte mit meinem 300 Baud Eigenbau Akustikkoppler auch nicht so
wahnsinnig toll funktioniert. Obwohl - wieso hab ich das eigentlich nie
ausprobiert?
Karl H. schrieb:>> Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB),>> sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte.>> Krösus :-)
Zusammengestoppelt. Schließlich kamen die Dinger initial aus dem
ZMD in Dresden ;), es sind noch welche dabei, die nicht mit dem später
offiziellen Etikett „U2164“ versehen sind, sondern „U264“. Es sind
aber auch auf der zweiten Platine offizielle Erfurter ICs drauf, die
es dann später preiswert als so genannte Bastlerware (2. Wahl) gab.
Aufgrund der vielen völlig verschiedenen Bauteile funktionierten
allerdings die „gängigen“ RAS-CAS-Ansteuerschaltungen auf der Basis
irgendwelcher Gatterlaufzeiten nicht bei diesem Mix. Ich bin erst
glücklich geworden, als ich einen definierten RAS-CAS-Versatz mit
dem vierfachen CPU-Takt (der zugleich Videotakt war) und einem
Schieberegister eingebaut hatte. Danach liefen die dRAMs stabil.
Das Desaster mit dem runtergefallen Kabel ist natürlich tragisch. In
solch trauriger Dimension ist es mir zum Glück erspart geblieben.
Thomas E. schrieb:> Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken?>> Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich> aus diesem nur einen einzigen Befehl verwende. Von der Kompaktheit des> Codes und dem flankenschonenden und stromsparenden Takt ganz zu> schweigen.>> Das Programm ist in jeder erdenklicher Weise höchstoptimiert und stellt> somit Krone der Programmierkunst dar.>> Das ist die ideale Effizienz. Das sind die unwidersprochenen Fakten!
Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier
Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können.
Damit hättest Du sogar den Mikrocontroller gespart!
Sheeva P. schrieb:> Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier> Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können.> Damit hättest Du sogar den Mikrocontroller gespart!
ist aber nicht 8Bit MSR konform.
Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den
Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch
kaum möglich...?
P. M. schrieb:> Was hat man denn damals mit den Computern gemacht?
Programmierung. Turbo-Pascal wurde ja schon genannt, da gab's dann
auch schon Dinge wie Knotenspannungsanalyse (hab' ich aber nie bis
zu Ende getippt).
Datenbanken (dBase).
Textverarbeitung (WordStar, damit habe ich bspw. meine Diplomarbeit
geschrieben, natürlich nur den Text, Bilder musste man einkleben).
Spiele (die berühmte Mondlandung, Ladder ist auch berühmt, wir hatten
hier noch UFO, weiß aber nicht mehr, wer das programmiert hatte).
Also eigentlich nichts anderes als heute auch. :-)
Sheeva P. schrieb:> Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier> Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können.> Damit hättest Du sogar den Mikrocontroller gespart!
Dann könnte man auch konsequenterweise eine blinkende LED nehmen.
Aber es geht hier schliesslich um Controller-Programmierung.
mfg.
Privat habe ich mit einem Atari 64XL begonnen nach dem ich hinreichend
mit Ataribasic und 6502 Assembler vertraut war programmierte ich eine
Minitextverarbeitung (64 zeichen pro zeile) mit 4 DIN A4 Seiten
Textspeicher den ich wahlweise über den Matrixdrucker oder die S3004
Ausgeben konnte. Das war das Werkzeug für mein EX Frau um in Heimarbeit
für den Funkbummi Handgeschreibene Manuskripte für den Lektor lesbar zu
gestalten.
Für mich war es Fingerübung und Lernobjekt das ich bis heute nicht
missen möchte. zuvor gab es fürmich nur Schwimmalle aka Lehrcomputer und
Tischrechner sowie den Specki meines Schwagers zum Trainingsschwimmen
und verstehen.
Die 6502 Atarikiste kenne ich heute innen in HW auswendig in SW
benötige ich immer wieder einen Blick in die Bibel des ROMS. Hatte für
mich den Vorteil, dass ich früh verschieden HW und Prozessor-
Rechnerkonzepte kennelernte. Und ich konnte sofort loslegen.
Von so etwas trennt man sich nicht freiwillig. ;)
Namaste
Gibts die blinkende LED nicht auch als Bausatz bei Conrad oder so was?
Dann braucht man mit dem AVR nur die Masseleitung verbinden, gar nichts
programmieren und hat maximal darauf Resourcen gespart.
Flash: 0
RAM: 0
Ist ja nicht schlimm, kompliziertes extern zuzukaufen...
Jörg W. schrieb:> Also eigentlich nichts anderes als heute auch. :-)
Du hast Tetris und Meniacs vergessen. Die sehen heute anders aus, folgen
aber immer noch dem gleichen Konzept.
Namaste
P. M. schrieb:> Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den> Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch> kaum möglich...?
Natürlich war damit auch damals schon das möglich, was auch heute noch
die Kerndinge auf einem PC sein dürften.
Textverarbeitung, Tabellenkalkulation, ein paar Spiele.
nur war das ganze halt nicht grafisch so aufgepeppt wie das heute ist.
Ein Text war einfach nur ein Text. ASCII. Fonts brauchte keiner. Wenn
der Drucker (Nadeldrucker) ein paar Fonts hatte, schön. Wenn nicht, dann
eben nicht. Zum Unterstreichen reicht auch eine Reihe '=' in der
nächsten Zeile, etc. etc.
Klaus W. schrieb:> Ist ja nicht schlimm, kompliziertes extern zuzukaufen...
Mache ich normalerweise auch so. Aber ich hatte bei diesem Projekt die
ultimative Herausforderung gesucht.
mfg.
Jörg W. schrieb:> Spiele (die berühmte Mondlandung, Ladder ist auch berühmt, wir hatten> hier noch UFO, weiß aber nicht mehr, wer das programmiert hatte).
Da sag ich nur Moriaaaaaaa
Und dann natürlich das Adventure (The Hall of the Mountain King, obwohl
das hies nicht wirklich so)
Jörg W. schrieb:> Also eigentlich nichts anderes als heute auch. :-)
Also eigentlich alles das wofür es heute ein Raspi mit Linux und 512MB
sein muß.
In 20 Jahren wird man Dich Fragen was man mit diesen Dinosauriern mit
weniger als 12TB Ram und ohne 1024 Kerne überhaupt machen konnte.
Schau Dir mal an was auf einem MOS6510 mit 64K und ein paar Spezialchips
für Sachen liefen (C64).
Das ist es was Moby immer wieder den Auftrieb gibt weil ein paar von
Euch denken das IT erst mit den jungen Göttern der heutigen
Hochschulausbildung angefangen hat.
Die ersten die Computer, Programmiersprachen und Algorithmen erfunden
haben und den Grundstein heutiger Hochschulausbildung gelegt haben waren
allesamt keine studierten Informatiker.
Die haben sich aus dem nichts all das überlegt, nur mit Bleistift,
Papier und ihrem Gehirn.
Du arbeitest mit dem was du hast. Klar das heute ein Raspi mit Python
vieles einfach erschlagen kann.
Ein 8085 mit 7seg. Anzeige hätte das aber meist auch gekonnt, nur nicht
so bunt.
Der 8085 hatte auch garkein Problem ms genaues Timing zu machen, der
Raspi braucht dafür einen Arduino angeflanscht.
Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung
und die Housekeeping Aufgaben des OS und wieviel davon harte
Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir
vorstellen was möglich ist wenn man low level nur noch
Kernfunktionalität programmiert.
Nur weil es heute kompfortabler geht bedeutet das nicht das wir damals
geduldig LEDs haben blinken lassen bis die 'richtigen' Computer kamen.
Nein, es kamen Leute wie Wozniak und haben mit dem 'Spielkram' Geräte
gebaut die ein Firmenimperium begründet haben.
Ich geb dir vollinhaltlich recht.
Und trotzdem fahre ich doch lieber mit einem heutigen Auto als mit einem
Ford Model T. Auch wenn man mit dem genauso von A nach B kommt.
Das Problem hast du überall. Die Weiterentwicklung bleibt nicht stehen.
Als die ersten graphischen Aufsätze aufkamen, GEM und dann natürlich der
Vater aller graphischen Computer - der originale Macintosh - haben auch
viele die Nase gerümpft und gesagt "was brauch ich den Scheiss". Und
Hand aufs Herz: wenn jemand mit einer Command Line umgehen konnte, war
er damit um Größenordnugen schneller als die ersten Mausschubser.
Trotzdem haben diese graphischen Systeme den Weg zur Massenverbreitung
geebnet, welche wiederrum Voraussetzung für den massiven Preissturz
waren.
Du weisst nie, wohin eine Entwicklung eines Tages hinführen wird.
Karl H. schrieb:> Du weisst nie, wohin eine Entwicklung eines Tages hinführen wird.
Doch das ist sicher es führt ins Nichts wenn es nicht zu Gott führt.
Namaste
P. M. schrieb:> Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den> Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch> kaum möglich...?
Beispielsweise den Gang von Uhren gemessen. Je nach Typ mit Mikrofon
oder Lichtschranke als Sensor.
Auf BASIC-Rechnern vergleichbar Apple II hatten 2 Jungs um 1981 herum in
der Schule ein Programm für Zeugnisauswertung und -druck geschrieben.
Und ja, darunter auch das eigene. ;-)
Für Leute die sich extrem schwer mit C tun, hier ein kleiner Einstieg...
Hier sind alle C Befehle und deren Syntax wie man die verwendet
aufgeschrieben und in deutsch leicht verständlich beschrieben:
http://www.utd.hs-rm.de/prof/hoch/download/cQuick.pdf
Nur Seite 7: "4. Ein- und Ausgabe" gibt es für den µC nicht, bzw. wird
dort nicht benötigt/verwendet.
Sollte mehr Interesse vorhanden sein, so liefert Google zu jedem Befehl
mehr Details und Beispiele.
Michael K. schrieb:> Also eigentlich nie.
Sag ich ja. Vorab wird natürlich für jedes Projekt hardwaremäßig
großzügig dimensioniert ;-)
Frank M. schrieb:> "Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn> helfen?
Wieder typisch Frank M. Versteht wie er's gerade braucht.
Mensch ich werd doch nicht nach Hilfe suchen für etwas, von dessen
Unmöglichkeit ich überzeugt bin... Doch wär es immer noch sinnvoller,
mich mit einer C-Version meines Projekts überzeugen zu "helfen" als mich
wochenlang mit allem möglichen, mehr oder weniger großen Unsinn zu
traktieren. Doch traut sich das niemand. Aus gutem Grund natürlich.
Jörg W. schrieb:> Moby A. schrieb:>> Ich selbst bin allerdings mit dem AVR, programmiert in Asm rundumst>> zufrieden>> Moby A. schrieb:>> Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft,>> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an>> Effizienz gewinne...>> Aha.
Ja- ich kann auch auf die ironische Art ;-)
Michael K. schrieb:> Moby A. schrieb:>> Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft,>> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an>> Effizienz gewinne...>> Moby, da hilft nur Übung, Vorbereitung, System.
Absolut. Nur ändert das nichts an den Nachteilen von C gegenüber Asm!
Thomas E. schrieb:> Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken?>> Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich> aus diesem nur einen einzigen Befehl verwende.
Spar Dir den Blödsinn. Im Fall des Falles kommt ein 555er zum Einsatz
oder die schon genannte fertige blinkende Leuchtdiode: Keep it simple!
Winfried J. schrieb:> wir beide haben zumindest gemein die Verachtung Anderer auf uns zu> ziehen weil wir unseren jeweiligen Standpunkt konsequent vertreten.
"Verachtung" hin oder her- ich weiß was ich an Asm habe.
> Maschinennahe Programmierung erschwert die Übersichtlichkeit. Das lässt> sich mit Macros zwar verbessern. Trotzdem bleibt es aufwendig.
Die Einschätzung teile ich ganz und gar nicht.
C-Codes, sobald sie über kleinste Anweisungen hinausgehen sind wirklich
alles andere als übersichtlich. Da lob ich mir die Asm Sequenzen
einfachster Instruktionen, die sich genauso hübsch funktionell gliedern
lassen.
> Die Effizienz des erzeugten Codes hängt im hohen Maße vom komplex> logischen vermögen des Programmierers mit gleichzeitig hohem> Abstraktionsvermögen ab.
Der Asm-Programmierer benötigt nur ersteres ;-)
> Die Codeeffizienz eines lausigen Hochsprachenprogrammierers ist sicher> noch größer als die eines mittelmäßigen ASM Fetischisten
Das bestreite ich, als nur "mittelmäßiger" ASMler.
> Nachdem HW heute billiger als SW-Entwicklungszeit (Programmiererlohn)> ist> ist ausgereizte ASM Programmierung schlicht zu teuer.
Asm-Programmierung ist durchschnittlich aufwendiger, aber je nach Übung,
Vorbereitung und System. Dafür kommt mehr Effizienz bei raus. Allein um
diesen Punkt geht es mir aber- und zwar bis hoch zu 1M ;-)
> Im Übrigen empfinde ich Hochsprachen bequemer und nutze sie im> Bewusstsein,> dass ich nicht jedes Byte kenne, welches der Compiler daraus bastelt,> oder den genauen Ablauf einer Interpreterfunktion nicht kenne.
Das will ich Dir nicht ausreden. Interessant ist aber nicht "jedes Byte,
welches der Compiler daraus bastelt" sondern die Kenntnis der konkreten
Hardware und die bestmögliche Anpassung daran für eine konkrete App.
> Einen Blick in den erzeugten Compiler-Code oder eine Interpreterroutine> ist allemal lehrreich.
Bestimmt. Angewiesen war ich bislang darauf nicht ;-)
Moby A. schrieb:> Doch wär es immer noch sinnvoller,> mich mit einer C-Version meines Projekts überzeugen zu "helfen"
Hat Yalu doch gemacht: Sein C-Programm ist kleiner und kann mehr als
Deins.
Dir wurde doch schon geholfen. Nur willst Du nicht lesen, was alle schon
wissen.
P. M. schrieb:> Und Moby macht einfach weiter, als wäre nichts gewesen. Obwohl Yalu in> einem Beispiel nun wirklich UNZWEIFELHAFT nachgewiesen hat, dass man> Assembler sogar bei Mini-Programmen mit C schlagen kann.
Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur
Kenntnis nimmst ;-)
P. M. schrieb:> - Obwohl du als Hobbyist gegen eine ganze Horde an erfahrenen Profis> antrittst,
Eine ganze Horde C-Ideologen ;-)
> - obwohl ein halbes Forum deiner Einzelmeinung geschlossen widerspricht,
Du solltest nicht mal für 1 Zehntausendstel des Forums sprechen ;-)
> - obwohl du keine deiner Behauptungen belegen konntest,
Mein Tiny13 Projekt steht für die von mir behauptetete Asm-Effizienz.
Bessere C-Tatsachen: Nicht in Sichtweite ;-)
> - obwohl klare Gegenbeweise gegen deine Thesen bestehen,
Meinst Du etwa Deine Unterstellungen, Unwahrheiten, Ablenkungsmanöver,
dummen Scherze, Beleidigungen usw usf? Eine etwas dünne Beweislage ;-)
> - obwohl du einen Teil des Diskussionsgegenstands (Programmiersprache C)> nicht mal kennst,
Was ich dazu kennen muß kenne ich schon aus eigener Erfahrung. Noch
besser aber ist ein regelmäßiger Blick in die vielen C-Problemthreads.
Besser als durch die Erfahrenen dort kann die umständliche C-Bürokratie
gar nicht zur Geltung kommen ;-)
> => benimmst du dich immer noch so, als wärst du im Recht und die anderen> auf dem Holzweg.
Tja, der Schluß ist eben alles andere als logisch. Nicht sehr ehrenhaft
für einen Programmierer ;-)
Karl H. schrieb:> Wenn es um ein> Assembler Problem geht, glänzen sie so gut wie fast immer .... durch> Abwesenheit.
Es kann halt nicht jeder einen Vollzeitjob hier machen.
Michael K. schrieb:> Karl H. schrieb:>> Und ich brings trotzdem nicht übers Herz, den 30 Jahre alten Krempel zu>> entsorgen.>> Moby auch nicht ;-)
Was Problemstellungen am einfachsten löst kann gern auch 300 Jahre alt
sein ;-)
Frank M. schrieb:> Moby A. schrieb:>> Doch wär es immer noch sinnvoller,>> mich mit einer C-Version meines Projekts überzeugen zu "helfen">> Hat Yalu doch gemacht: Sein C-Programm ist kleiner und kann mehr als> Deins.
Lies nochmal genau was ich schrieb. Schaffst Du das überhaupt?
Michael K. schrieb:> Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung> und die Housekeeping Aufgaben des OS und wieviel davon harte> Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir> vorstellen was möglich ist wenn man low level nur noch> Kernfunktionalität programmiert.
Na also. Zuweilen mischt sich unter die Ideologen noch ein klar
Denkender ;-)
@ moby
Mein weg durch die Programmiersprachen
auf verschiedenen Plattformen
U808
ASM
U880
ASM
6502
ASM
Basic verschiedene Dialekte
Pascal
ASM
Forth
Turbobasic
60386 .....
Basic verschiedene Dialekte
ASM
PDSBasic + inline ASM
Pascal
C(C++ versuchsweise)
Java versuchsweise
Purebasic
AVR*****
ASM
C + inline ASM
Bei allen größeren Projekten war ich mit Hochsprachen am Ziel noch bevor
ich in ASM den speicher organisierthabe und ein gerüst im PAP erzeugt
hatte.
Bei den AVR ist es eigentlich in C am einfachsten. Ich benutze CVAVR.
das zauberwort heiststrukturierte Programierung und ausagekräftige
Bezeichner.
Namaste
Moby A. schrieb:> Michael K. schrieb:>> Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung>> und die Housekeeping Aufgaben des OS und wieviel davon harte>> Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir>> vorstellen was möglich ist wenn man low level nur noch>> Kernfunktionalität programmiert.>> Na also. Zuweilen mischt sich unter die Ideologen noch ein klar> Denkender ;-)
Nun, ich mag eine gut gestaltete GUI auch wenn sie Ressourcen frisst.
Auch wenn das jetzt ein wenig aus dem Zusammenhang gerissen war, ist ein
grundlegender Konflikt ganz gut zu erkennen.
Die ungläubige Frage was denn bitteschön mit dem alten Kram anzufangen
gewesen wäre ausser ein wenig Heimgebastel lässt mich schon schmunzeln.
Das waren unsere Produktivsysteme meine Herren !
(Nein, ich bin noch ganz lange nicht in Rente, die Entwicklung war nur
sehr schnell)
Ein wenig Technikhistorie würde unseren 'jungen Wilden' ganz gut tun.
Du bist ja nicht im Unrecht das 'bare metal' und verzicht auf alles was
über blanke Funktionalität hinaus geht auf den alten MCU Dinge möglicht
macht die die neue Programmiererelite auf 8bit für unmöglich hält.
Deine Schlussfolgerung das das in ASM geschehen muß teile ich nicht.
Ja, das war mal so vor langen Jahren, aber die Compiler sind wirklich
gut geworden und die MCUs geben sich auch alle Mühe es ihnen leicht zu
machen.
Deine Aussagen sind ja bewusst provokativ. Das wirst Du gleich verneinen
aber das nehme ich Dir trotzdem nicht ab.
Ich finde das Software heute auch gut aussehen darf.
Das darf auch Rechenleistung kosten und man darf es sich auch durch
geeignete Hochsprachen einfacher machen.
Wir müssen zum Glück nicht mehr mit den argen Becshränkungen der grauen
Vorzeit leben und das darf man auch mal annehmen.
Du mach was Dir spaß macht.
Machst Du ja ohnehin.
Moby A. schrieb:> Karl H. schrieb:>> Wenn es um ein>> Assembler Problem geht, glänzen sie so gut wie fast immer .... durch>> Abwesenheit.>> Es kann halt nicht jeder einen Vollzeitjob hier machen.
Wenn du die Hälfte der Zeit, die du in diesen Thread hier versenkst,
stattdessen in die Beantwortung von Fragen zu Assembler in anderen
Threads stecken würdest, wäre dort viel gewonnen und hier nichts
verloren.
Michael K. schrieb:> Karl H. schrieb:>> Das einzige bei dem ich am Anfang immer Probleme>> hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie?> Da hilft nur: Übung, Vorbereitung, System
Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry.
http://www.mikrocontroller.net/articles/8bit-CPU:_bo8
Josef G. schrieb:> Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry.
Perfekt, jetzt ist die Stimmung im Arsch.
Moby, Josef... wo steckt eigentlich Kurt?
Ich denke, hier sind noch einige Sachen reichlich undefiniert. Kein
Wunder, dass bisher kein Konsens zustande kommen konnte.
Moby A. schrieb:> Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur> Kenntnis nimmst ;-)
Zitier mal bitte was du genau meinst. "Weiter oben" umfasst mittlerweile
eine Spanne von einigrn hundert Beiträgen.
Moby, hast du eigentlich immer noch nicht kapiert gegen welche geballte
Kompetenz du da anstinken willst?
Gerade der gestrige Nachmittag war für mich wieder sehr interessant. Da
waren einige neue Infos dabei, über die Anfänge der Heimelektronik und
was manche hier schon vor > 30 Jahren alles implementiert haben. Dagegen
willst du dich echt aufmandln?
Um beim Bayerischen zu bleiben: du bist echt a Kasperl...
le x. schrieb:> Um beim Bayerischen zu bleiben: du bist echt a Kasperl...
Der Kasperl der Bist Du, weil Du immer noch versuchst, dem Mann mit
Argumenten beizukommen. Dabei hat er doch mehr als einmal durchleuchten
lassen, dass es bei seinem "Asm" immer nur um kleine Anwendungen geht.
Ich verstehe nicht, warum hier immer noch verbissen ("Hnnngggg!") Recht
behalten werden muss.
Josef G. schrieb:> Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry.
Sieh an, hätte ich nicht gedacht: Noch ein Fan vom 1802. ;-)
Aber warum nicht konsequent, also auch ohne Carry-Flag? (MIPS)
Da hast du ausnahmsweise mal ins Schwarze getroffen, wenn auch
möglicherweise eher zufällig. Technisch betrachtet gibts es tatsächlich
gute Gründe, auf klassische Flags zu verzichten, aber wenns irgend geht
auch auf Carry. Bei OOO Implementierung sind Flags "a pain in the ass",
viel Aufwand mit wenig Ertrag. Der Ansatz von MIPS ist dann tatsächlich
effizienter.
Yalu X. schrieb:> Wenn du die Hälfte der Zeit, die du in diesen Thread hier versenkst,> stattdessen in die Beantwortung von Fragen zu Assembler in anderen> Threads stecken würdest, wäre dort viel gewonnen und hier nichts> verloren.
Jeder hat so seine Prioritäten.
Es ist auch nicht so daß ich noch nicht woanders geholfen hätte.
Die Vorstellung effizienter Asm-Programme könnte allerdings auch eine
effiziente Hilfe und Orientierung für manchen sein ;-)
Eddy C. schrieb:> Ich denke, hier sind noch einige Sachen reichlich undefiniert.
Genau. Wie riesig der Effizienzabstand Asm vs. C idealerweise wirklich
sein könnte ;-)
le x. schrieb:> Da> waren einige neue Infos dabei, über die Anfänge der Heimelektronik und> was manche hier schon vor > 30 Jahren alles implementiert haben. Dagegen> willst du dich echt aufmandln?
Wieso dagegen?
Mich interessiert die Effizienz von Asm beim Ressourcenverbrauch.
Dafür hab ich hier ein extra Projekt gezeigt.
Dagegen kam noch nix ;-)
Markus M. schrieb:> Alle haben Recht .... im Bereich bis zu ihrem Tellerrand.
Das kann man immer unterschreiben ;-)
Eddy C. schrieb:> Der Kasperl der Bist Du, weil Du immer noch versuchst, dem Mann mit> Argumenten beizukommen
Na ja, Argumente...
Aber die grundlegende Einsicht: Bravo!
Nun fehlt nur noch das Warum.
Warum ist Asm im umrissenen Einsatzgebiet überlegen!
Bevor aber die Chance bestünde, das nach >10000 Beiträgen endlich
akzeptiert herauszukristallisieren hat ein Mod längst entnervt den Hahn
zugedreht ;-)
Moby A. schrieb:> Spar Dir den Blödsinn. Im Fall des Falles kommt ein 555er zum Einsatz> oder die schon genannte fertige blinkende Leuchtdiode: Keep it simple!
Netter Versuch, um weiter von deinen eigenen Unzulänglichkeiten und
denen deines "Projektchens" abzulenken.
Ich gestehe dir aber zu, dass du aus deiner laienhaften Sicht als
Hobbybastler das wahre Potential dieses Programms natürlich nicht
erkennen kannst.
Den Atmega88 habe ich natürlich mit Bedacht ausgewählt, da sich dieses
Projekt auch an Anfänger richtet. Diese benutzen zumeist den Atmega8. Da
dieser Controller aber veraltet ist, führe ich sie mit meinem Projekt an
dessen Nachfolger heran.
Wie ich aber schon in meinem Beitrag, in dem ich das Projekt vorstellte,
schrieb, lässt sich das Programm ohne Änderungen auch auf anderen
Controllern ausführen. Z.B. auf einem Attiny85. Dieser Controller
unterscheidet sich in Bauform und Grösse nicht vom NE555. Bietet jedoch
den Vorteil, dass er mit wesentlich weniger externer Beschaltung
auskommt.
Eine selbstblinkende LED bietet nur auf den ersten Blick einen Vorteil.
Das Controller-Projekt ist über einen weiten Spannungsbereich
einsetzbar, während die selbstblinkende LED nur innerhalb geringer
Toleranzen benutzt werden kann.
Ausserdem bietet das Controller-Projekt die geniale Möglichkeit, mit
einer zweiten LED einen Wechselblinker aufzubauen. Die beiden LEDs
blinken dann mit absoluter Präzision im Wechseltakt. Das Besondere dabei
ist, dass es dazu keiner Änderung der Software bedarf. Das Programm
erkennt selbstständig, dass eine zweite LED vorhanden ist. Eine
Tatsache, die ganz klar in Richtung künstliche Intelligenz tendiert.
Ein Wechselblinker ist mit zwei selbstblinkenden LEDs unmöglich zu
realisieren.
Weiterhin besteht die Möglichkeit, mehrere, mit diesem Projekt
aufgebaute Schaltungen, taktgenau zu synchronisieren. Natürlich ohne
jegliche Änderungen an der Software durchzuführen. Dabei lassen sich
sogar verschiedene Controller einsetzen. Damit wird also eine heterogene
Struktur erreicht. Mit NE555 oder selbstblinkenden LEDs ist dies
ausgeschlossen.
Und das alles mit den schon genannten Vorteilen.
Absolute Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten.
mfg.
Thomas E. schrieb:> Netter Versuch, um weiter von deinen eigenen Unzulänglichkeiten und> denen deines "Projektchens" abzulenken.
Ich lenke nicht ab sondern sage nur: Keep it simple.
Das gilt für Anwendungen wo ein MC sinnvoll wird ganz genauso. Du aber
könntest ruhig zugeben, daß Deine Asm Blinker App oben Quatsch war.
> Den Atmega88 habe ich natürlich mit Bedacht ausgewählt, da sich dieses> Projekt auch an Anfänger richtet. Diese benutzen zumeist den Atmega8. Da> dieser Controller aber veraltet ist, führe ich sie mit meinem Projekt an> dessen Nachfolger heran.
Großartig. Was für ein Upgrade ;-)
> während die selbstblinkende LED nur innerhalb geringer> Toleranzen benutzt werden kann.
Die sind mit einem einfachen, entsprechend dimensionierten Vorwiderstand
ja viiiel größer ;-)
> Eine> Tatsache, die ganz klar in Richtung künstliche Intelligenz tendiert.
Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit
;-)
> Das sind die unwidersprochenen Fakten.
Moby A. schrieb:> daß Deine Asm Blinker App oben Quatsch war.
Das typische Verhalten, wenn einem die Argumente ausgehen und man von
seinen eigenen Unzulänglichkeiten ablenken will.
Moby A. schrieb:> Großartig. Was für ein Upgrade
Wieso Upgrade? Ich habe von vornherein betont, dass sich dieses Projekt
auch an Anfänger richtet.
Moby A. schrieb:> Die sind mit einem einfachen, entsprechend dimensionierten Vorwiderstand> ja viiiel größer
Sicher. Man kann die Schaltung sowohl für eine frei wählbare Spannung
dimensionieren, als auch durch den Einsatz einer KSQ universell
gestalten. Das kannst du als Hobbybastler natürlich nicht wissen. Aber
jetzt weisst du das auch. Hast also schon wieder etwas gelernt.
Moby A. schrieb:> Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit
So ist das mit den Argumenten. Siehe oben.
Moby A. schrieb:>> Das sind die unwidersprochenen Fakten.
Absolute Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
mfg.
PS: Ich habe ein C-Programm geliefert, um diese Fakten zu belegen! Du
dagegen, klopfst weiterhin nur Sprüche.
Thomas E. schrieb:> Ausserdem bietet das Controller-Projekt die geniale Möglichkeit,> mit einer zweiten LED einen Wechselblinker aufzubauen.
Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und
eine zweite z.B. mit 1.01 Hz.
Ein Blinky mit einer LED entspricht einem "Hallo Welt", d.h. der
Einsteiger muss sich erst mal mit Geraffel wie Editor, Programmer,
Spannungsversorgung, Beschaltung etc. herumschlagen.
Wenn das allles absolviert ist, wird i.d.R. das einfache Testprogramm
erweitert zu einer "richtigen" Anwendung, die aber alsbald über das Übel
der Verzögerung per delay stolpert.
Die 2 asynchron blinkenden LEDs zeigen schön den Weg zu delay-freier
Software.
Moby A. schrieb:> Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit> ;-)
Moby, wir wissen nicht aus welchem Motiv du in diesem Thread noch
unterwegs bist. Aber falls die gesamte Diskussion von deiner Seite
wirklich ernst gemeint war, dann muss man dir von der besagten Dummheit
doch so einiges unterstellen, und zwar nicht "künstliche", sondern
"natürliche" Dummheit.
Deine Beiträge bestehen eigentlich nur noch aus satzweise zitierten
Postings, wo du Satz für Satz mit einem dummen Spruch konterst. Ganz
ehrlich: Sowas lese ich nicht mehr durch.
Johann L. schrieb:> Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und> eine zweite z.B. mit 1.01 Hz.
Hab' ich mal gemacht als Blaulicht-Rundumleuchten-Imitiation für ein
kleines Spielzeugauto. Dort waren's 501 und 499 ms Periodendauer
für die beiden LEDs.
Ach, Mist, ist off-topic hier. War kein Assemblerprogramm.
Jörg, poste doch mal das C Progrämmchen, vielleicht macht das Moby als
ASM ;-)
Schreib aber nicht im Vorfeld den RAM/Flash verbrauch, damit er auch
noch dieses Jahr fertig wird mit optimieren g
Johann L. schrieb:> Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und> eine zweite z.B. mit 1.01 Hz.
Das ist keine typische 8-Bit-SLB*-Anwendung.
mfg.
* S y n c h r o n e s
L e u c h t d i o d e n
B l i n k e n
P. M. schrieb:> Moby, wir wissen nicht aus welchem Motiv du in diesem Thread noch> unterwegs bist.
Ich fürchte, Du weißt gar nichts.
Und ich fürchte, Du stehst hinter Thomas Eckmanns Jux-Beispiel ;-(
> Ganz> ehrlich: Sowas lese ich nicht mehr durch.
Daß Du Dinge nicht zur Kenntnis nimmst die Dir nicht in den Kram passen
weiß ich doch.
quatsch! Das ist eine typische ASM Anwendung 1 hw timer 2 sw zähler
oder wenn vorhanden 2 hw timer welche in in der IRS die nur die port
bits toggeln da gibt es nichts zu optimieren
da ist schon das öffnen der compiler IDE oversice
Namaste
Winfried J. schrieb:> da gibt es nichts zu optimieren
Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser
Code-Overhead hinzukommen und mehr Schreibaufwand allemal ;-)
Moby A. schrieb:> Ich fürchte, Du weißt gar nichts.> Und ich fürchte, Du stehst hinter Thomas Eckmanns Jux-Beispiel
Was heisst denn hier Jux?
Eine weitere unqualifizierte Äusserung, um von den eigenen
Unzulänglichkeiten abzulenken.
Nochmal:
Absolute Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
mfg.
Moby A. schrieb:> Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser> Code-Overhead hinzukommen und mehr Schreibaufwand allemal
Na, dann mach doch mal.
1Hz, 1,01Hz. Attiny13. Wir wollen ja niemand mit Timern verwöhnen.
mfg.
Thomas E. schrieb:> Was heisst denn hier Jux?>> Eine weitere unqualifizierte Äusserung
Du wirst doch nicht ernsthaft erwarten daß ich diese Asm-Anwendung ernst
nehme und weiter darauf eingehe.
Obwohl, eine Chance geb ich Dir noch:
Wenn Dir ein Mod und 5 weitere der 50 C-Granden, die hier auf den armen
Moby einhacken bestätigen, daß es sich bei Deiner Blink-App um eine
ernstzunehmende Assembler-Anwendung handelt ;-)
Davon mach ich mir dann einen Ausdruck, weil sowas kann man in
zukünftigen Diskussionen immer mal brauchen ;-)
> Na, dann mach doch mal.>> 1Hz, 1,01Hz. Attiny13. Wir wollen ja niemand mit Timern verwöhnen.
Verwöhn mich mal mit der C-Variante.
Dann sehen wir weiter.
Moby A. schrieb:> Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit> ;-)
Die Moby'schen Beiträge hingegen tendieren eindeutig Richtung natürliche
Dummheit ;-)
Moby A. schrieb:> Du wirst doch nicht ernsthaft erwarten daß ich diese Asm-Anwendung ernst> nehme und weiter darauf eingehe.
Nichts weiter als die Bestätigung deiner vorherigen Aussagen. Dir sind
die Argumente ausgegangen und jetzt benimmst du dich wie ein Kleinkind,
dass sich an der Supermarktkasse schreiend auf dem Boden wälzt, weil es
keinen Lolli bekommt.
Du kanst dem, von mir gezeigten Optimum, einfach nichts entgegensetzen.
Absolute Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
Moby A. schrieb:> Wenn Dir ein Mod und 5 weitere der 50 C-Granden, die hier auf den armen> Moby einhacken bestätigen, daß es sich bei Deiner Blink-App um eine> ernstzunehmende Assembler-Anwendung handelt
Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist
rein rhetorischer Art. Du hast es nötig.
Moby A. schrieb:> Verwöhn mich mal mit der C-Variante.> Dann sehen wir weiter.
Das war natürlich nicht anders zu erwarten. Erst die grossen Sprüche:
Moby A. schrieb:> Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser> Code-Overhead hinzukommen und mehr Schreibaufwand allemal
Dann natürlich nichts dahinter und andere sollen wieder in Vorlage
treten.
mfg.
Thomas E. schrieb:> Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist> rein rhetorischer Art. Du hast es nötig.
Was heißt hier rhetorisch?
Das war voll mein Ernst.
> Dann natürlich nichts dahinter und andere sollen wieder in Vorlage> treten.
War doch Dein Beispiel...
Dann zeig mal was. Ich zeig Dir dann, wie's kürzer geht. Hast bis morgen
Zeit. An meinem freien Sonntag würde ich dafür etwas Zeit erübrigen ;-)
Moby A. schrieb:> Thomas E. schrieb:>> Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist>> rein rhetorischer Art. Du hast es nötig.>> Was heißt hier rhetorisch?> Das war voll mein Ernst.
Grandioses Textverständnis!
Markus M. schrieb:> Jörg, poste doch mal das C Progrämmchen, vielleicht macht das Moby als> ASM ;-)
Da steht eine Beerware license drüber, insofern vermute ich, dass ich
das hier schon mal gepostet habe.
Nö, ich würde höchstens die Specs posten, nicht das Programm selbst.
Aber Moby hat doch sowieso keine Zeit für sowas.
Carl D. schrieb:> Wozu, du könntest ja die vielen Sonderzeichen gar nicht lesen
Ja genau. Die vielen vielen C-Sonderzeichen. Ein besonderer Aufwand:
Samt und sonders überflüssig wie ein Kropf ;-)
Carl D. schrieb:> Grandioses Textverständnis!
Du solltest Dich bemühen, nicht endgültig auf das Niveau von
Gu.F(orentroll) abzusacken ;-(
Moby A. schrieb:> Das war voll mein Ernst.
Ja sicher. Ich bezweifle auch nicht, dass du das nötig hast, weil du
meinen Fakten nichts entgegensetzen kannst.
Absolute Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
Moby A. schrieb:> War doch Dein Beispiel...
Das war nicht mein Beispiel. Ich habe nur die Anforderungen
zusammengefasst. Du kannst gerne auch einen anderen Controller nehmen.
Von dir kam aber die grosskotzige Ankündigung:
Moby A. schrieb:> Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser> Code-Overhead hinzukommen und mehr Schreibaufwand allemal
mfg.
Moby A. schrieb:> Ja genau. Die vielen vielen C-Sonderzeichen. Ein besonderer Aufwand:> Samt und sonders überflüssig wie ein Kropf ;-)
Zumindest beherrscht du schon diese 3 Sonderzeichen ;-)
Moby A. schrieb:> Carl D. schrieb:>> Grandioses Textverständnis!>> Du solltest Dich bemühen, nicht endgültig auf das Niveau von> Gu.F(orentroll) abzusacken ;-(
noch mal für dich in "ausführlich":
Du hast eine Antwort gegeben, aus der man leicht erkennen kann, daß du
den Text! auf den du antwortest, nicht verstanden hast. Oder war das
jetzt wieder zu kompliziert?
Gu. F. schrieb:> Morgen üben wir dann diese Sonderzeichen "("> Zusammen mit deinen schon bekannten kannst du dann schon eine C Funktion> formulieren.
Mit dem "^" können wird ja noch etwas warten ;-)
Thomas E. schrieb:> weil du> meinen Fakten nichts entgegensetzen kannst.
Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner
Asm Blink-App, dann können wir Deine "Fakten" neu bewerten ;-)
Carl D. schrieb:> Oder war das> jetzt wieder zu kompliziert?
Nö. Aber unwichtig.
Bevor wir uns weiter in diesem seichten, nichtssagenden Sumpf verlieren
les ich jetzt mal meine frische c't. Manchmal gibts da ganz nette
Meldungen (siehe z.B. Ausgangsposting). ;-)
Moby A. schrieb:> Bevor wir uns weiter in diesem seichten, nichtssagenden Sumpf verlieren> les ich jetzt mal meine frische c't.
Oder liest doch mal hier:
http://www.cprogramming.com/tutorial/c-tutorial.html Dann könntest du
irgendwann auf Augenhöhe mit uns diskutieren :-)
Moby A. schrieb:> Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner> Asm Blink-App, dann können wir Deine "Fakten" neu bewerten
Die Leier hatten wir doch schon. Fällt dir nie etwas Neues ein?
mfg.
Thomas E. schrieb:> Die Leier hatten wir doch schon.
Seh ich als gutes Zeichen, wenn Dir nur noch die Abqualifizierung als
"Leier" einfällt ;-)
Ich sags auch gern ein drittes, viertes, fünftes Mal wenn Dir an Deiner
Blöd-App soviel liegt...
P. M. schrieb:> Oder liest doch mal hier:> http://www.cprogramming.com/tutorial/c-tutorial.html
Wozu sollte ich mich damit unnütz mehr als nötig belasten? Wozu ein
Riesen-Faß mit Bergen von Regeln und Vorschriften, Operatoren, Typen,
Deklarationen, Konstruktionen und Lib-Funktionen aller Art aufmachen
wenn eine geeignete App auch mit ein paar simplen Asm-Instruktionen und
auch noch kürzer + ggf. mit mehr Speed zu realisieren ist?
> Dann könntest du> irgendwann auf Augenhöhe mit uns diskutieren :-)
Ach so? Wo hier welche Augenhöhen sind ist noch lange nicht ausgemacht.
Von Deiner hab ich noch nicht viel gespürt. Zumindest beim Thema Asm vs.
C ;-)
Moby A. schrieb:> Ach so? Wo hier welche Augenhöhen sind ist noch lange nicht ausgemacht.> Von Deiner hab ich noch nicht viel gespürt. Zumindest beim Thema Asm vs.> C ;-)
Du bist Hobbyist, der gerade mal etwas Assembler kann. Die meisten
anderen Diskussionsteilnehmer (und ich) haben Ausbildung, Studium und
insbesondere jahre- bis jahrzehntelange Berufserfahrung im Bereich der
hardwarenahen Software-Entwicklung. Keine Ahnung, wie man da ein Moby
noch auf die Idee kommen könnte, er wisse es besser...
P. M. schrieb:> Keine Ahnung, wie man da ein Moby> noch auf die Idee kommen könnte, er wisse es besser...
Du solltest nicht so schablonenhaft denken.
Vor allem aber nicht bloße (behauptete) Erfahrung als Argument
verwenden. Damit kannst Du vielleicht andere beeindrucken aber nicht
mich.
Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf
dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-)
Markus M. schrieb:> für ein STM32F4DISCOVERY, ganz ohne overhead im Hintergrund und ohne> Startup-Code
Sorry, wir reden hier von 8-Bit AVR Code.
Das Discovery ist schon von der Hardware her totaler Overkill für
typisches 8-Bit MSR, für die Assembler sowieso nicht mehr infrage kommt
;-(
Ich hab kein AVR mehr, den hab ich schon vor 10 Jahren wegen mangelnder
Funktionalität und Speicher entsorgt.
Aber Du hast doch ein STM32 Board zu Hause liegen, zumindest hast Du das
mal geschrieben. Doch weil Du das nie zum laufen bekommen hast liegt es
nun in der Ecke.
Moby A. schrieb:> Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf> dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-)
Hier, bitte:
Markus M. schrieb:> Aber Du hast doch ein STM32 Board zu Hause liegen, zumindest hast Du das> mal geschrieben. Doch weil Du das nie zum laufen bekommen hast liegt es> nun in der Ecke.
Stimmt.
Wollte es später in Markt verschenken aber nicht mal geschenkt wollte es
damals jemand ;-)
Es mag sicher auch seine Einsatzmöglichkeiten haben, (gepeinigt mit
daten/rechenintensiven Anwendungen oder hochabstraktem C++ ;-), die
liegen aber hinter meinem Tellerrand und den Notwendigkeiten von (fürs
SmartHome ausreichenden) 8-Bit MSR Problemlösungen.
P. M. schrieb:> Hier, bitte:
Ich befürchte bei Dir schon wieder was:
Daß Du was Entscheidendes überlesen hast ;-)
Moby A. schrieb:> Ich befürchte bei Dir schon wieder was:> Daß Du was Entscheidendes überlesen hast ;-)
Ja, ich weiss, dass du alles als ungültig erklärst, das nicht eine
exakte Nachprogrammierung deines Krams ist. Und selbst dann erfindest du
immer neue, absurde Nebenbedingungen.
Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als
Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei
widerlegt.
P. M. schrieb:> Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als> Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei> widerlegt.
Deine Zweifelsfreiheit in allen Ehren, aber das ist die These nicht. Das
Warum werde ich hier nicht tausendmal wiederholen. Du hast die
Gelegenheit des Nachweises aber nach wie vor bei meinem optimierten
Projekt. Dazu aber wird von Dir genau soviel kommen: Nichts. Lieber
versteckst Du Dich hinter Yalus Rücken bei einem Code und einem
Vergleich, bei dessen genauen Kontext Du nur durch Ahnungslosigkeit
glänzt ;-)
P. M. schrieb:> Ja, ich weiss, dass du alles als ungültig erklärst, das nicht eine> exakte Nachprogrammierung deines Krams ist.
Funktion ist Funktion. Da wollen wir schon genau bleiben und nicht
streitträchtig herumhudeln ;-)
> Und selbst dann erfindest du> immer neue, absurde Nebenbedingungen.
Falls das wieder auf den RAM-Verbrauch gemünzt war: Ja, der gehört zu
jedem vernünftigen Resourcenverbrauchs- Vergleich! Da ist rein gar
nichts absurd dran.
Moby A. schrieb:> Falls das wieder auf den RAM-Verbrauch gemünzt war: Ja, der gehört zu> jedem vernünftigen Resourcenverbrauchs- Vergleich! Da ist rein gar> nichts absurd dran.
Genau. Aber das ist natürlich nur ein Teil der einzusparenden Resourcen.
Absolute Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
Von denen du natürlich noch weit entfernt bist.
mfg.
Thomas E. schrieb:> Von denen du natürlich noch weit entfernt bist.
Gäääähn.
Natürlich, Thomas, so un-end-lich weit daß es schon fast an Wahnsinn
grenzt. Ich hoffe, ich konnte Dich jetzt zufriedenstellen!
Ich seh schon es kommt nichts Handfestes mehr...
Dann mach ich mal Feierabend, hier und heute!
Moby A. schrieb:> Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner> Asm Blink-App, dann können wir Deine "Fakten" neu bewerten ;-)
Ertmal Entschuldigung! Ich bin kein prominenter C-Zeuge. Aber trotzdem
versuch' ich's mal:
Du bezeichnest deine paar aneinandergereite ASM-Befehle als
hochoptimiertes, einfach zu erweiterndes, ...(*) Programm. Thomas hat
mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die
Funktionsweise der Hardware verstanden hat! Und: Ich verrate dir mal was
(es liest ja keiner mit): Ich schätze, er würde trotzdem für seine
Anwendung die kilo(byte)schwere C-Version verwenden. :-)
(*) 'hocheffizient' und den anderen Schwachsinn lass ich mal weg, das
sprengt den Rahmen
Moby A. schrieb:> Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf> dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-)
???
>(fürs SmartHome ausreichenden) 8-Bit MSR Problemlösungen.
genauso wie bei ASM sind das aber DEINE "Ansprüche" ..
die, wie du vielleicht doch irgendwann gemerkt hast, den Ansprüchen
aller anderen diametral engegengesetzt sind
otto-normalbürger stellt sich unter "SmartHome" wohl doch was anderes
vor, als dass was deine Hardware hergibt..
Ralf G. schrieb:> (*) 'hocheffizient' und den anderen Schwachsinn lass ich mal weg, das> sprengt den Rahmen
Dann solltest du "hochoptimiert" und "einfach zu erweitern" ebenfalls
weg lassen.
Ich grins mir immer einen ab, wenn ich mal wieder so eine Codezeile
schreibe:
1
printf("Mein super wichtiger Debugwert: %i, %i, %f",nVal1,nVal2,fVal1);
Der mir mal schnell per JTAG Debugger in der Debug Console irgend welche
Zustände schreibt.
Ach wie toll dass ich kein Assembler gefrickel nehmen muss.
Ralf G. schrieb:> Thomas hat> mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die> Funktionsweise der Hardware verstanden hat!
Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen
Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines
Programms, welches wohldefiniert wirklich etwas bewegt? Soll mich das
jetzt ärgern oder was bezweckst Du damit?
Ralf G. schrieb:> Ich verrate dir mal was> (es liest ja keiner mit):
... den Oszi-Output meines Projekts hab ich nur mit Paint gezeichnet ;-)
Robert L. schrieb:> genauso wie bei ASM sind das aber DEINE "Ansprüche" ..> die, wie du vielleicht doch irgendwann gemerkt hast, den Ansprüchen> aller anderen diametral engegengesetzt sind>> otto-normalbürger stellt sich unter "SmartHome" wohl doch was anderes> vor, als dass was deine Hardware hergibt..
Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der
Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle
anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe
nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im
Gegenteil eher unsicher und schwach.
> ... stellt sich unter "SmartHome" wohl doch was anderes> vor, als dass was deine Hardware hergibt..
Hast Du dafür irgendwelche Anhaltspunkte?
Oder vertraust Du hierfür nur Deiner angenommenen Mehrheitsmeinung bzw.
der Stimmungslage mir gegenüber in diesem Thread?
Moby A. schrieb:> Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der> Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle> anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe> nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im> Gegenteil eher unsicher und schwach.
Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und
alle anderen nicht mehr brauchen als du?
Klaus W. schrieb:> Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und> alle anderen nicht mehr brauchen als du?
Genau dafür wurde ja der Begriff "MobyMaus Projektchen" erfunden ;-)
Klaus W. schrieb:> Wer etwas kann und Übung, Vorbereitung, System hat, braucht keinen> Debugger.
Wenn man Code mit 5 anderen Programmieren zusammen bearbeiten darf, der
auf Bibliotheken stützt, den wiederum X unterschiedliche Programmierer
im Laufe der Jahre erstellt haben und zwischendurch es Upgrades von µC
gab, und man auch noch fremde Komponenten per irgend welchen
Schnittstellen einbinden darf, dann hilft ein Debugger sowie
Debug-Ausgaben ungemein.
Ich rede jetzt mal nicht von so einem Moby-Mini Dinges, sonder vom
täglichen Brot eines SW-Entwicklers einer Firma mit vielen Entwicklern
und Projekten.
Markus M. schrieb:> Ach wie toll dass ich kein Assembler gefrickel nehmen muss.
Das Wohl-Gefühl und der Spaß an der Sache ist das was zählt!
So eine Print-Funktion hat natürlich was. Aber ist natürlich klar, daß
jetzt nur mit den Rosinen aus dem großen, trockenen C-Kuchen geworben
wird!
So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit
vorab Variablen-initialisierten Registern kosten, wenn eine
entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine
Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine
fette C-Zeile ;-)
Moby A. schrieb:> So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit> vorab Variablen-initialisierten Registern kosten, wenn eine> entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine> Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine> fette C-Zeile ;-)
Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür
reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16. Plus
extra Kommentarzeilen damit man das versteht. Plus irgend ein Datenblock
für den String.
Es ist in einem Projekt schließlich nicht die einzige Debug-Ausgabe.
Klaus W. schrieb:> Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und> alle anderen nicht mehr brauchen als du?
Den Mehrverbrauch im SmartHome wirst Du mir sicher gleich erläutern.
Insbesondere interessieren mich die Stellen, wo man mit Asm undoder
8-Bit nicht mehr weiter kommt ;-)
Markus M. schrieb:> Ich rede jetzt mal nicht von so einem Moby-Mini Dinges, sonder vom> täglichen Brot eines SW-Entwicklers einer Firma mit vielen Entwicklern> und Projekten.
Gut daß Du diese Unterscheidung triffst.
Denn für den Firmen-Bereich rede ich hier nicht.
Nichtsdestotrotz sind auch viele Firmen-Anwendungen auf 8-Bit MSR
Niveau.
Moby A. schrieb:> Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der> Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle> anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe> nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im> Gegenteil eher unsicher und schwach.
Millionen fliegen irren nicht! "Scheiße ist lecker."
Das Problem ist doch "Die Apfellogik" hinter Allem. Es will und soll
niemand wissen warum etwas funktioniert solange es funktioniert.
Und es ist auch gar nicht mehr erwünscht das zu wissen, denn was jeder
kann besitzt keinen Wert!
Wissen teilen ist in der Informationsgesellschaft ein Loyalitätsbruch
am Kapital (siehe Snowden).
Um das wie etwas sollen sich bitte jene, welche man genau dafür
bezahlt, kümmern und das bitte auch für sich behalten damit das geschäft
nicht leidet. Und wenn "es" nicht funktioniert wie es soll, dann sind
"die" halt schuldig und haben den Schaden. Siehe VW Ingeneure. Das hat
System und ist die Basis der Wirtschaft, Schmalspurwissen und dumme
Konsumenten. Universalgelehrte und eine hohe Allgemeinbildung sind da
nur hinderlich und wurden auf beiden Seiten nur im "Kalten Krieg"
gebraucht aus Angst vor dem Potential des Gegners.
Namaste
Markus M. schrieb:> Klaus W. schrieb:>> Wer etwas kann und Übung, Vorbereitung, System hat, braucht keinen>> Debugger.>> ...> Schnittstellen einbinden darf, dann hilft ein Debugger sowie> Debug-Ausgaben ungemein.
sorry, muß wohl noch was nachreichen: :-)
Markus M. schrieb:> Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür> reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16.
Das ist wie bei Menschen. Fett zeigt sich in der Breite, nicht in der
Länge, 16 schmale unkommentierte Zeilen Asm sind viel weniger fett als
eine Zeile C, die quer den ganzen Bildschirm füllt. ;-)
> Plus irgend ein Datenblock für den String.
Nicht wenn man es richtig macht:
rcall ptext
db 'Hallo Welt!',13,10,0
Mach das mal in C.
Und float brauchen seine Anwendungen sowieso nicht. Schon mal ein 8-Bit
Fliesskommaformat gesehen?
A. K. schrieb:> Schon mal ein 8-Bit Fliesskommaformat> gesehen?
was nicht bedeutet, dass das auf 8-Bittern nicht einzusetzen wäre in
meinem 8 Bit Atarie waren 8 K Mathematik routinen drinnen auf welches
der Basicrom ger zugegriffen hat. leider habe ich dafür keine doku aber
so etwas ließe sich ach in einem Atmega sinnvoll einsetzen nicht nur von
Hochsprachen aus
auch aus ASM Calls wäe es sinnvol ansprechbar.
Namaste
Winfried J. schrieb:> was nicht bedeutet, dass das auf 8-Bittern nicht einzusetzen wäre
Aber bei Moby passte bislang alles, was des Programmierens wert wäre, in
8 Bits. Den Umgang mit grösseren Datentypen hatte ihm erst unlängst ein
C Compiler beigebracht.
Markus M. schrieb:> Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür> reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16. Plus> extra Kommentarzeilen damit man das versteht. Plus irgend ein Datenblock> für den String.> Es ist in einem Projekt schließlich nicht die einzige Debug-Ausgabe.
Du bist mit der Print-Ausgabe zweifellos flexibler, auch vom
Variablenformat her. Dem will ich mal Rosinen-Status zugestehen.
Bei meiner vorbereiteten Asm-Funktion müsste ich aber auch nur händisch
den schon enthaltenen Text ändern, Variablen sind höchstens 16-bittig.
Davon abgesehen läuft es in meiner Praxis sowieso gaaaanz anders.
Die Netzknoten an denen ich arbeite geben ihre Daten in einem
festgelegten Protokollstring drahtlos an mein PC Terminal-Programm
weiter. In deren Ausgabe-Puffer schreib ich einfach rein was ich wissen
will, der Rest geht eh automatisch.
Winfried J. schrieb:> Das Problem ist doch "Die Apfellogik" hinter Allem. Es will und soll> niemand wissen warum etwas funktioniert solange es funktioniert.
Oh je...
Mit C und seiner ganzen Bürokratie und Entwicklungsumgebung muß man aber
mehr wissen und beachten als mit Asm und der intimen Kenntnis eines
AVR-Controllers. Davon abgesehen ist die Apfel-Logik absolut richtig und
anzustreben. Ich sage nicht, das Asm mit direktem Hardware-Zugriff der
"Keep it simple"-Weisheit letzter Schluß ist. Ich sage aber, daß mit C
in typischen 8-Bit MSR Anwendungen unter dem Strich nichts einfacher und
(für den geübten ASM'ler) effizienter wird. Für eine tatsächliche
Vereinfachung der Programmierung müsste man meiner Meinung nach ganz
grundlegend an der Hardware ansetzen und nicht auf Kosten von
Ressourcenverbrauch, Schreibaufwand und Übersicht allein die Software
immer flexibler = immer abstrakter = immer komplizierter gestalten und
so nur fortlaufend die Hardware-Anforderungen erhöhen. Hardware auch,
die mit immer mehr zu beherrschenden da ach so flexiblen Features
überladen wird statt einfacher und intelligenter zu werden. Möge der
Schöpfer sicherstellen, daß einfache 8-Bit Hardware noch lange für
einfache 8-Bit MSR zur Verfügung steht ;-)
A. K. schrieb:> Aber bei Moby passte bislang alles, was des Programmierens wert wäre, in> 8 Bits.
Variablen sind i.a.R. nicht größer als 16 Bit- damit läßt sich mit
8-Bit AVR prima hantieren!
Mal ein 8-Bit Float erfinden:
Bit 7: Vorzeichen
Bit 6..5: Exponent
Bit 4..0: Mantisse
Damit Moby auch mal seine Projekte mit Mini-Float ausstatten kann.
Wo ein Wille ist ist auch ein Weg GRINS
Moby A. schrieb:> Variablen sind i.a.R. nicht größer als 16 Bit- damit läßt sich mit> 8-Bit AVR prima hantieren!
Manche müssen sich dazu aber erst vom C Compiler zeigen lassen, wie man
das überhaupt macht. So wie ein gewisser Moby. ;-)
Markus M. schrieb:> Damit Moby auch mal seine Projekte mit Mini-Float ausstatten kann.
Wofür? Für Vorzeichen und Kommastellen brauch ich jedenfalls kein C.
Und kannst Du mir mal sagen, wo in 8-Bit MSR Exponenten auftauchen?
A. K. schrieb:> Manche müssen sich dazu aber erst vom C Compiler zeigen lassen, wie man> das überhaupt macht. So wie ein gewisser Moby. ;-)
Na was denn? Klartext bitte.
Den Asm-Output eines Compilers kenn ich nur vom Hörensagen.
Moby A. schrieb:> Den Asm-Output eines Compilers kenn ich nur vom Hörensagen.
Ich habe nicht behauptet, dass du ihn selbst aufgerufen hast. Obwohl es
in dem Fall weniger peinlich gewesen wäre, es vorher zu tun. ;-)
Moby A. schrieb:> Davon abgesehen ist die Apfel-Logik absolut richtig und anzustreben.
Na Mahlzeit mit der Einstellung fährt D.(EU) wirtschaftlich entgültig
gegen die Wand. Wissen und Innovation ensteht durch Produktion und nicht
im Elfenbeinturm. Schon heute rennt uns Asien, ehemals als verlängerte
Werkbank von gierig agierenden BWLern erfunden, inovativ den Rang ab.
Und die Polemik der Politik zu diesem Thema steht "Erichs Sprüchen" in
nichts mehr nach. Selbst Nachrichten erreichen DDR-Niveau. Das könne
"wir in der DDR-sozialisierten" sehr schön mitverfolgen weil wir es
unabhängig welche Schlüsse wir daraus ziehen wiedererkennen. Das sehen
es viele, wenn nicht die meisten, von uns mit großem Unbehagen.
Namaste
DDR 2.0 gibts hier nicht: Assembler-Programme lügen nicht. C Compiler
schon, wenngleich recht selten.
Bin ja mal gespannt, wann der erste Prozessor rauskommt, dessen
Assembler-Sprache nur chinesische Schriftzeichen verwendet. Und dann
stell ich mir Moby bei dessen Programmierung vor.
A. K. schrieb:> Ich habe nicht behauptet, dass du ihn selbst aufgerufen hast. Obwohl es> in dem Fall weniger peinlich gewesen wäre, es vorher zu tun. ;-)
Ich sagte Klartext bitte ;-)
Wenn es irgend ein Fehlerchen war ist mir das nicht peinlich.
Die sind menschlich und sehr produktiv...
Winfried J. schrieb:> Na Mahlzeit mit der Einstellung fährt D.(EU) wirtschaftlich entgültig> gegen die Wand.
Wieso?
Die Dinge einfacher und einfacher benutzbar zu machen ist ein legitimes
Anliegen. Noch dazu in einer Zeit, wo immer mehr immer komplizierter
wird. Es ist auch erfolgreich, wie die Apfel-Verkaufszahlen trotz
astronomischer Preise zeigen. Nur so gehts wieder von der "Wand" weg!
Konfiguritis bis ins letzte Detail? Nein danke.
Moby A. schrieb:> Ich sagte Klartext bitte ;-)
Der Klartext wurde hier im Thread bereits verlinkt und auch ausführlich
kommentiert. Also ganz leicht zu finden und kein Grund, das zu
wiederholen.
Davor kommt der erste Chip mit HW Interpreter und Chinesischer
Sprachein/ausgabe in Mandarin mit 8Kanal 128bit paralel ADU im
Eingabekreis und Hardware-FFT. Allerdings wird der mehr als 8 oder auch
64 Bit parallel verarbeiten.
Und die Amis werden fünf Jahre benötigen, bevor die den ins Englische
kopiert haben. D. braucht dann noch einmal zehn Jahre.
Namaste
A. K. schrieb:> Auf den Klartext wurde hier im Thread bereits verlinkt.> Also ganz leicht zu finden.
Na meinetwegen.
Die Vorteile von Asm wird's trotzdem nicht tangieren.
A. K. schrieb:> Assembler-Programme lügen nicht.
So ist es.
Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede
Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar,
die Gestaltungsfreiheiten unbegrenzt. Die Freiheit, das Bestmögliche zu
erreichen. Aber man weiß ja, daß mit mehr Freiheit immer auch mehr
Verantwortung einhergeht.
Moby A. schrieb:> Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen> Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines> Programms, welches wohldefiniert wirklich etwas bewegt? Soll mich das> jetzt ärgern oder was bezweckst Du damit?
Was heisst "Soll mich das ärgern"?
Es ärgert dich!
Dieses Programm geht weit über die Grenzen deiner Erkenntnis und deines
Verstandes hinaus. Denn du hast dieser genialen Funktionaltät nichts
entgegenzusetzen. In diesem Programm ist die von dir vielbeschworene
Effizienz realisiert, während deine Programme noch meilenweit davon
entfernt sind:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
mfg.
Moby A. schrieb:> P. M. schrieb:>> Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als>> Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei>> widerlegt.>> Deine Zweifelsfreiheit in allen Ehren, aber das ist die These nicht.
Anstatt mit dummen Sprüchen zu kontern, hättest du hier auch einfach
deine These klarstellen können. Vermutlich willst du das aber nicht,
obwohl eine klare These, ein klarer Standpunkt eigentlich Ausgangslage
jeder Diskussion sein sollte.
Thomas E. schrieb:> 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM> Flankenschonender und stromsparender Takt> Maximal mögliche Schonung des Befehlssatzes
Der Moby hat endgültig seinen Meister gefunden!
Die Reaktion fällt natürlich aus wie zu erwarten...
Rausreden, Fakten verdrehen und wegdefinieren (Stichwort 8 bit MSR)
Johann L. schrieb:> eine LED mit 1 Hz blinken zu lassen und> eine zweite z.B. mit 1.01 Hz.Moby A. schrieb:> Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser> Code-Overhead hinzukommen und mehr Schreibaufwand allemalMoby A. schrieb:> An meinem freien Sonntag würde ich dafür etwas Zeit erübrigen
Moby, hast du das woanders gepostet? Ich finde das hier nicht.
Dieser Aus-Dem-Ärmel-Schüttler müsste doch längst fertig sein.
mfg.
Moby A. schrieb:> A. K. schrieb:>> Assembler-Programme lügen nicht.>> So ist es.> Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede> Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar,> die Gestaltungsfreiheiten unbegrenzt. Die Freiheit, das Bestmögliche zu> erreichen. Aber man weiß ja, daß mit mehr Freiheit immer auch mehr> Verantwortung einhergeht.
Liest sich so als hättest du eine symbiotische Beziehung zu AVR
Assembler.
Moby A. schrieb:> Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede> Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar,> die Gestaltungsfreiheiten unbegrenzt.
Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz
konkretes Beispiel.
P. M. schrieb:> Was kannst du in Assembler, das du in C nicht kannst?
Die Frage hast du unglücklich formuliert. Sie impliziert, dass er etwas
in C könne. Das ist aber nicht der Fall. Die Frage könnte er so, wie sei
gestellt ist, mit "Alles" beantworten. Das wäre selbst dann vollkommen
richtig, wenn er nur den nop-Befehl beherrschte.
Richtig müsste es also heisen:
Was kannst du in Assembler, was man in C nicht kann?
mfg.
Moby A. schrieb:> So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit> vorab Variablen-initialisierten Registern kosten, wenn eine> entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine> Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine> fette C-Zeile ;-)
Nö, eine Debugausgabe kostet mich nicht eine einzige Zeile Code und es
ist vollkommen egal was ich mir dabei anschauen will.
a.) Ich trage meine zu beobachtenden Variablen im Watch Window ein und
sehe live was passiert.
b.) Ich gehe auf HALT und schaue mir einfach jedes Register und jede
Speicherstelle in der MCU an die mich gerade interessiert.
c.) Ich lasse mir Kurven schreiben von Variablen die mich gerade
interessieren.
d.) Ich setze einen Breakpoint und schaue mir an ob das Programm bis
dahin läuft und schaue mir an was in den Variablen / Registern steht.
Alles das mir einer 30Cent MCU und einem kostenlosen Compiler + IDE +
einem 5€ Programmer / Debugger
(STM8S003 + IAR Kickstart)
Der Compiler wird da schon irgendwas im Hintergrund machen damit ich
bekomme was ich will. Ist mir aber total schnuppe solange ich bekomme
was ich will.
Ich habe wirklich keine Ahnung wann Du das letzte mal mit einer
vernünftigen IDE + C Compiler gearbeitet hast, aber es muß irgendwann in
den 80ern gewesen sein.
Im Normalfall klicke ich gerade mal ein paar Haken in den
Projektsettings an und bekomme das Make File nie zu Gesicht. Ich könnte,
aber warum sollte ich?
> fette C-Zeile ;-)
Wirklich, Du verwechselst da was.
Fett und kryptisch ist es erst alle Register freischaufeln zu müssen die
man für eine Debugausgabe braucht anstatt einfach den Wert anzuschauen
ohne sich vorher um irgendwas kümmern zu müssen.
Thomas E. schrieb:> Richtig müsste es also heisen:> Was kannst du in Assembler, was man in C nicht kann?
dem wäre nur zu entgegnen
Was kannst du in C, was man prinzipiell in Assembler nicht kann?
nichts da C grundsätzlich auf ASM Aufsetzt und nicht umgekehrt.
das Compilat ist stehts ein ASM file. also etwas das prinzipell auch
direkt in ASM gescchrieben werden kann
Du hast den Vorteil mehr vordefinierte Funktionen, was nicht heist, dass
man Selbige in ASM nicht generieren kann. das erspart Arbeit insofern
diese bereits zuvor von anderen erledigt wurde. Nachteil: Du weist nicht
per se wie der compiler das in ASM umsetzt.
Der einzige Vorteil von C und allen übrigen Hochsprachen ist, das sie
teilweise plattformübergreifend anwendbar sind, bei mehr oder weniger
definierter Syntax undman so nicht zufuß über stock und stein muß.
das aber ist für den hobbisten das ziel (der Weg)
Strukturierte Programmierung ist in jeder Programmiersprache die Regel,
welche der durchbrechen darf der sie beherrscht. Das ist für ASM noch
wichtiger als für jede Hochsprache.
niemand hindert im Übrigen den C Programmierer mittels Inline asm ASM
Code wie SBI /CBI für die es keine entsprechung in C gibt einzubinden.
umgekehrt kann man aus dem ASM code vorkompilierte C-Fuktionen aufrufen
warum nicht
Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze
entscheide ich danach wie groß und tief das Loch in der Wand werden soll
Das Werkzeug an der Wand ist immer ein Meißel, das am Prozessor ist
immer das Hexfile. Den Weg dorthin sieht man dem fertigen hexfile in
aller regel nicht mehr an. aber in C++ ist es schneller zusammen
geklickt. Ob der Programmierer noch weis was mit welchen Nebeneffekten
damit im Prozessor passiert, hängt von dem Wissensdurst des
Programmierers ab.
Namaste
Winfried J. schrieb:> Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze> entscheide ich danach wie groß und tief das Loch in der Wand werden soll
Das ist die gängige Meinung.
Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel
mit Hammer und Meisel aus dem Fels zu hauen. Einen Tunnelbohrer zu
benutzen ist totaler bürokratischer Quatsch. Den Beleg dazu kann auch
keiner bringen.
Gu.F. schrieb:> Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel> mit Hammer und Meisel aus dem Fels zu hauen.
mit "Übung, Vorbereitung, System" macht der Moby das Rucki Zucki.
Werner P. schrieb:> mit "Übung, Vorbereitung, System" macht der Moby das Rucki Zucki
Nein. Der Tunnel ist keine typsische 8bit MSR Anwendung. Das wird in
eine TBM ausgelagert und dazugekauft.
Gu. F. schrieb:> Winfried J. schrieb:>> Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze>> entscheide ich danach wie groß und tief das Loch in der Wand werden soll>> Das ist die gängige Meinung.> Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel> mit Hammer und Meisel aus dem Fels zu hauen. Einen Tunnelbohrer zu> benutzen ist totaler bürokratischer Quatsch. Den Beleg dazu kann auch> keiner bringen.
Leider viel schlimmer. Er will daß jeder davon überzeugt ist, daß die
Benutzung einer Tunnelbohrmaschine große Verschwendung ist.
Dabei ist doch auch Hammer und Meißel Verschwendung, denn beim Tunnelbau
fallen massenweise Faustkeile an, die ein noch direkteres Gefühl für's
Gestein rüber bringen.
Moby A. schrieb:> Den Asm-Output eines Compilers kenn ich nur vom Hörensagen.
Bitte ?
Aber Du predigst doch schon die ganze Zeit das ASM so viel geiler ist.
Woher willst Du das wissen wenn Du noch niemals überprüft hast welch
eleganten Konstruktionen ein C Compiler zustande bekommt ?
Moby A. schrieb:> Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede> Unaufmerksamkeit.
Moment, aber Dein Argument was doch das C fett und kryptisch ist und ein
ASMler schon lange fertig bevor ein Cler überhaupt mit dem lesen und
verstehen seines Sprachschatzes durch ist.
Nun ist es ein Nachteil von C den gröbsten Blödsinn von mir abzufangen
und ein Vorteil von ASM jedes Nachlassen der Konzentration sofort und
unmittelbar aufs härteste zu bestrafen ?
Moby A. schrieb:> Die Vorteile von Asm wird's trotzdem nicht tangieren.
Nun bin ich etwas verwirrt welche das noch sein sollen.
Wenn ich Deine Aussagen mal zusammenfasse und dabei auch beachte welchen
Aussagen Du vehement nicht widersprochen hast ergibt sich folgendes
Bild:
Dank Yalus Code wissen wir das C besser optimiert, selbts bei kleinsten
Programmen.
C fängt meine Fehler ab, ASM lässt mich voll reinrauschen.
C kann ich jederzeit und überall in jede Richtung erweitern, umbauen,
eindampfen und der Compiler regelt das schon hinter den Kulissen.
ASM braucht Übung, Vorbereitung, System und wenn ich da Mist mache dann
bin ich fällig und kann nicht mehr vor und nicht zurück ohne alles neu
zu schreiben.
Bei C+IDE ist debuggen so schwer wie in der Nase bohren, bei ASM muss
ich erst einen Batzen Routinen für dieses und jedes fertig haben und
dann auch jeweils ganz genau wissen was ich in diesem Programteil machen
darf und was nicht.
Große C Programme schreibe ich so wie kleine und die Codedichte ist
immer gleich. Size oder Speed opt. ist nur ein Häkchen anders setzen in
der IDE.
Kleine ASM Programme optimiere ich bis aufs Blut für jedes Bit für große
macht man copy paste und verschenkt viel Optimierungspotential weil man
den Überblick sonst nicht behalten kann. Habe ich auf Speed optimiert
und muß das jetzt auf Size machen weil mir der Platz ausgeht dann
schreibe ich alles neu dafür.
In C kann ich jederzeit ohne großen Aufwand die MCU Familie wechseln in
ASM muß ich alles neu schreiben.
Das sind im wesentlichen Dinge die Du selber so gesagt hast. Nur nie
alle auf einmal sondern nur in homöopatischen Dosen.
Das alles ist auch nicht aus den Fingern gesogen, sondern das waren im
wesentlichen genau die Gründe weswegen ich ASM vor langer Zeit den
Rücken gekehrt habe.
Micheal, du hast nicht die Größe und den Überblick eines wahren Mobys.
Dank Übung, Vorbereitung, System ist der "echte Programmierer" in der
Lage selbst gewaltige 200 Byte große MSR Projekte ohne kryptische,
bürokratische Hochsprachenkonstrukte aus dem FF zu beherrschen.
Jeder der da widerspricht hat einfach nicht die Vorraussetzung die
Dimensionen eines "MobyMaus Projektchen" wie das Tiny13 Sensorboard's zu
verstehen.
Gu. F. schrieb:> gewaltige 200 Byte große MSR Projekte
Auch solche mit 10 oder 100 KB, schließlich hat ihm ja nie jemand
(anhand seines 200-Byte-Beispiels) das Gegenteil demonstrieren können.
Manche mögen mich für übergeschnappt halten, aber ich biete eine Wette
an:
Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch
die 2000er Hürde schafft. Wer hält dagegen?
(*) ganz nutzlos ist er dank des "Leimruteneffekts" doch nicht.... ;-)
Thomas E. schrieb:> Dieser Aus-Dem-Ärmel-Schüttler müsste doch längst fertig sein.
Moby, was machst du denn den ganzen Tag? Ist das noch nicht fertig?
Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal
um diese Funktion erweitert.
Die Frequenzen werden wie folgt ausgegeben:
PB0: 2Hz
PB1: 1.01Hz
PB2: 1Hz
PB3: 1Hz
PB4: 1.01Hz (genau genommen sind es hier 1.01010101Hz = 100/99 Hz)
Die Ausgaben an PB0, PB3 und PB4 werden per Softwarezähler, getriggert
von Timer0, per PIN-Toggle ausgegeben.
Die Ausgaben an PB1 und PB2 werden mit Timer1 erzeugt. Die Ausgabe
erfolgt durch den Timer, also OC1A und OC1B. Softwarezähler werden nicht
benutzt.
Lediglich ein Einzeiler in der passenden Timer1-ISR.
Clock ist 1,8432MHz. Mit internen 1MHz liefe es also etwas mehr als halb
so schnell.
Ich habe das Hexfile zum Testen drangehängt. Den C-Quellcode zeige ich
dir, wenn du dein Asm-Programm gepostet hast. Ich will dich ja nicht in
die Versuchung bringen, abzuschreiben.
mfg.
Lothar M. schrieb:> Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch> die 2000er Hürde schafft. Wer hält dagegen?
Was ist dein Einsatz? Ich hoffe, er ist für alle und insbesondere Moby
attraktiv genug.
Denn dann wünsche ich dir jetzt schon viel Spaß beim Schreiben von 419
nutzlosen Beiträgen :D
Yalu X. schrieb:> Denn dann wünsche ich dir jetzt schon viel Spaß beim Schreiben von 419> nutzlosen Beiträgen :D
Das wird Moby problemlos schaffen:
Und zwar durch System, Übu.. äh durch Wiederholung seiner Floskeln
Lothar M. schrieb:> (*) ganz nutzlos ist er dank des "Leimruteneffekts" doch nicht.... ;-)
An der auch Moderatoren rudelweise dran kleben bleiben. Aber
verschmerzbar, sonst scheint grad kaum was los zu sein. ;-)
Yalu X. schrieb:>> Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch>> die 2000er Hürde schafft. Wer hält dagegen?>> Was ist dein Einsatz?
Ich biete einen AT90S1200. Ist doch ideal für Moby: wo kein RAM ist,
kann auch keiner verschwendet werden. :-)
Damals ... vor vieeelen Jahren hatte ich mein erstes EPROM von Hand
programmiert. Als armer Schüler gingt jede Mark für Bauteile drauf.
Das Handprogrammiergerät:
- 8er Dip Schalter für die Daten
- 7493 mit Monoflop als Adresszähler
- "Brennen" Taste, der die VPP und den Adresszähler ansteuert.
Computeruntergestütz habe ich das ASM Listing ausgedruckt und die
Opcodes ran geschrieben und dann die DIP's nacheinander eingestellt.
Nach 4h war das Programm dann drin.
Das habe ich genau 2x gemacht. (beim ersten mal hab ich mich einmal nach
3h beim Dip Einstellen vertan)
Danach habe ich mir ein EPROMer gebastelt samt Programm für einen
Schneider CPC6128. An deren Erweiterungs-Datenbus. Das war dann schon
deutlich angenehmer.
So richtig nostalgisch. Leider ist das schon 25 Jahre her und ich sammle
so zeug nicht, daher keine Bilder davon - schade.
PS: hier präsentiere ich nun die nutzlose Information Nr 1586
Markus M. schrieb:> So richtig nostalgisch. Leider ist das schon 25 Jahre her und ich sammle> so zeug nicht, daher keine Bilder davon - schade.
Meinen alten Hardware-Eprommer habe ich auch verschrottet, ohne noch
ein Foto davon zu machen. Da er auch noch 2708 (U555) programmieren
können sollte, war (neben der Spannungsversorgung mit -5, +5, +12 V)
noch das Problem, dass man den 2708 mit 50 Programmierimpulsen von
je 1 ms programmieren musste, statt eines mit 50 ms. Normalerweise
hatte man zwischendrin einfach alle 1024 Speicherstellen mit je 1 ms
weiter programmiert, aber bei einem Programmer, der nur den Inhalt
einer Stelle kennt, musste man diese mit hinreichenden Pausen dann
50mal programmieren.
Zusätzlich musste die Hardware es beherrschen, den Vpp-Impuls selbst
mit seinen 25 V zu schalten. Bei den späteren ROMs konnte man dann
Vpp direkt anlegen, und nur noch 50 ms lang einen TTL-Impuls schalten.
Aber ist natürlich alles kein Vergleich zu 1702-EPROMs, bei denen man
an allen Pins irgendwas um -45 V zum Programmieren schalten musste.
Moby A. schrieb:> Ralf G. schrieb:>> Thomas hat>> mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die>> Funktionsweise der Hardware verstanden hat!>> Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen> Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines> Programms, welches wohldefiniert wirklich etwas bewegt?
Ja! Und du hast dir die Antwort doch schon selber gegeben:
Moby A. schrieb:> Andersrum. Der hat die richtigen Antworten wenn es darum geht,> performanten Code auf engstem Raum zu verpacken,
Ich hatte mich damals auf den 27C256 Typ beschränkt, der 32K Typ. Andere
gingen damit nicht. Das war Preislich und von der Größe her akzeptabel
und die liefen auch gut mit dem Z80 zusammen (Zugriffzeiten von 150ns).
Markus M. schrieb:> Ich hatte mich damals auf den 27C256 Typ beschränkt, der 32K Typ.
Als ich die Kiste hier entworfen hab, gab's nichts anderes als 2708.
Alles andere kam später mit dem computerisierten Programmer und war
natürlich (vergleichsweise) viel einfacher.
Mein erster Brenner, !burnit, war ein Bit-Banger am LPT-Port.
Der konnte 8748/49 und 2716-27256.
Den hab' ich irgendwann zerlegt und daraus einen 8051-Flasher, !burnit2,
gebaut. Der existiert und funktioniert auch noch. Theoretisch, also wenn
der LPT-Port vom PC mitspielt.
mfg.
Ralf G. schrieb:> Ja! Und du hast dir die Antwort doch schon selber gegeben:> Moby A. schrieb:>> Andersrum. Der hat die richtigen Antworten wenn es darum geht,>> performanten Code auf engstem Raum zu verpacken,
Man sollte schon mehr von sehr wenig bis minimalster Funktionalität
unterscheiden können. Sinnvolles von sinnlosem. Und auch wohl
definiertes von weniger definiertem Programm-Verhalten. Jeweils
letzteres sind für einen guten Programmierer nicht unbedingt
schmeichelhaft ;-)
Jörg W. schrieb:> Ich biete einen AT90S1200. Ist doch ideal für Moby: wo kein RAM ist,> kann auch keiner verschwendet werden. :-)
Da kann aber auch niemand etwas erweitern.
Oder gar in C programmieren ;-)
Lothar M. schrieb:> Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch> die 2000er Hürde schafft. Wer hält dagegen?
Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in
die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott
versandet während ich mangels besserer C-Version immer noch auf den
konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-)
Matthias L. schrieb:> Und zwar durch System, Übu.. äh durch Wiederholung seiner Floskeln
Naja, die Textbausteine hat er schon fertig.
Bei größeren Threads ist das nur noch Copy Paste.
Bei kleineren wird da noch mehr handoptimiert.
Daher auch keine Antwort auf viele unangenehme Argumente.
Die Textbausteine dafür sind noch nicht fertig und die zu schreiben
dauert einfach seine Zeit.
Alles analog zu ASM.
Moby A. schrieb:> Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in> die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott> versandet während ich mangels besserer C-Version immer noch auf den> konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-)
Jetzt habe ich den Sinn des Threads und die Ausdauer des TO verstanden!
Die Aussagen ohne neue Informationen solange wiederholen, bis auch der
letzte
eingesehen hat, dass es sinnlos ist, darauf zu antworten.
Dann kann der Thread als "Sieg" gewertet werden!
Danke für die Klarstellung!
Moby A. schrieb:> Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in> die Asm-Vorteile nicht durch.
Ein Geisterfahrer?
Zehntausende!
Moby A. schrieb:> Ralf G. schrieb:>> Ja! Und du hast dir die Antwort doch schon selber gegeben:>> Moby A. schrieb:>>> Andersrum. Der hat die richtigen Antworten wenn es darum geht,>>> performanten Code auf engstem Raum zu verpacken,>> Man sollte schon mehr von sehr wenig bis minimalster Funktionalität> unterscheiden können. Sinnvolles von sinnlosem. Und auch wohl> definiertes von weniger definiertem Programm-Verhalten. Jeweils> letzteres sind für einen guten Programmierer nicht unbedingt> schmeichelhaft ;-)
Guten Morgen mein lieber Rosinenpicker,
seit gestern sind ein paar interessante Beiträge angefallen, nimmst du
dazu bitte auch Stellung?
Moment, ich such dir einen davon raus:
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Außerdem steht meine Frage noch unbeantwortet im Raum.
Dabei ging es darum, wieso Yalu's Code dir nicht als Beweis gereicht.
le x. schrieb:> Moby A. schrieb:>> Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur>> Kenntnis nimmst ;-)> Zitier mal bitte was du genau meinst. "Weiter oben" umfasst mittlerweile> eine Spanne von einigrn hundert Beiträgen.
Die Frage ist wirklich ernst gemeint. Mich interessiert deine Aussage
dazu, ich konnte sie aber nirgends mehr finden...
@ Bernhard M.
ja, das ist das Grundkonzept jedes Troll-Threads..
das schwierige ist, dass man immer nur sosehr unterschwellig Beleidigt
und Aufstachelt ;-) , dass nicht vorzeitig alle aufgeben oder man
überhaupt gesperrt wird
das war im 4000+ thread wo es um "modulation" ging sicher auch so,.. (wo
ist der überhaupt hin??)
zum Thema: ASM hat Vor- UND Nachteile, C hat auch Vor- UND Nachteile
(das hab Moby AVR auch nie bestritten)
ob bei 8-bit MSR jetzt die Vor- oder die Nachteile überwiegen, ist mir
immer noch egal.. (auch nach 2000 Posts wir es sich nicht ändern..)
Auch wenn jetzt 90% der/meine Projekt(chen) in die Kategorie (8-bit MSR)
fallen WÜRDEN, wäre es mir egal..
Moby A. schrieb:> Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in> die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott> versandet während ich mangels besserer C-Version immer noch auf den> konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-)
Ich möchte echt mal wissen, wer hinter diesem Moby steckt. Ein Troll?
Ein besserwisserischer Gymnasiast? Ein bornierter Rentner? Ein
selbstherrlicher so-läuft-das-hier-Machertyp? Ein grenzautistischer
Nerd? Ein Narzist, der sein "Gesicht" verteidigt bis ins Verderben?
P. M. schrieb:> Ich möchte echt mal wissen, wer hinter diesem Moby steckt. Ein Troll?> Ein besserwisserischer Gymnasiast? Ein bornierter Rentner? Ein> selbstherrlicher so-läuft-das-hier-Machertyp? Ein grenzautistischer> Nerd? Ein Narzist, der sein "Gesicht" verteidigt bis ins Verderben?
Darüber wurde schon einmal spekuliert:
Michael K. schrieb:> Ob er das wirklich alles glaubt, uns nur veräppelt, im realen Leben> Bankensoftware in Cobol programmiert oder eine übergewichtige Friseuse> aus Castrop Rauxel mit einem Hang zu Kreuzworträtseln und ASM ist werden> wir wohl nie herausfinden.
Eine von den beiden gefällt mir besonders gut.
mfg.
le x. schrieb:> Guten Morgen mein lieber Rosinenpicker,
Gemeint waren aber die wenigen C-Rosinen.
Die langen bei weitem nicht zu einem genussvollen Verzehr des trockenen
C-Kuchens aus ;-)
> seit gestern sind ein paar interessante Beiträge angefallen, nimmst du> dazu bitte auch Stellung?
Gerne. Meistens. Leider kann ich den Thread nicht in Vollzeit
bearbeiten, aber ich bemühe mich (schon mit vielen Hundert Beiträgen).
> Die Frage ist wirklich ernst gemeint. Mich interessiert deine Aussage> dazu, ich konnte sie aber nirgends mehr finden...
Dann solltest Du Dir auch mehr Mühe geben. Das war weiter oben in ein
paar Stichpunkten zusammengefasst.
Bernhard M. schrieb:> Dann kann der Thread als "Sieg" gewertet werden!
Lasst doch diese Kategorien aus der Steinzeit.
Mit einer besseren C-Version meines Projekts hätte es sich schnell
ausdiskutiert- jedenfalls von meiner Seite!
Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt
werden ;-)
P. M. schrieb:> Ich möchte echt mal wissen, wer hinter diesem Moby steckt.
Das ist einer Deiner Fehler: Du stellst die falschen Fragen. Mach Dir
lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau
gestellten Assembler-Überlegenheit zu begegnen ist ;-)
Moby A. schrieb:> Mit einer besseren C-Version meines Projekts hätte es sich schnell> ausdiskutiert- jedenfalls von meiner Seite!
Yalu hat es schon geliefert: kleiner, effizienter und besser!
> Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt> werden ;-)
Willst Du doch gar nicht. Du lügst. ;-)
Robert L. schrieb:> @ Bernhard M.>> ja, das ist das Grundkonzept jedes Troll-Threads..> das schwierige ist, dass man immer nur sosehr unterschwellig Beleidigt> und Aufstachelt ;-) , dass nicht vorzeitig alle aufgeben oder man> überhaupt gesperrt wird
Im Großen und Ganzen bleibt Moby höflich und das hier wurde ja von ihm
aufgemacht, also darf er auch diskutieren.
Wegen Unbelehrbarkeit wird hier niemand gesperrt (gilt für beide Seiten)
:-)
> das war im 4000+ thread wo es um "modulation" ging sicher auch so,.. (wo> ist der überhaupt hin??)
Den gibt es weiterhin:
Beitrag "Frage zum Frequenzmultiplex bei Modulation"
Das hat den Vorteil, dass Schreiber mit - sagen wir "eigenwilligen
Ansichten" nicht alle Threads kapern sondern so ihrer Meinung Ausdruck
verleihen können, ohne den sonstigen Ablauf im Forum zu stören.
Ist also eine Win-Win-Situation. Daher bleiben diese Threads auch offen.
Was wir deswegen in Zukunft freundlich aber bestimmt unterbinden werden
ist eine Verlagerung in weitere Threads.
> zum Thema: ASM hat Vor- UND Nachteile, C hat auch Vor- UND Nachteile> (das hab Moby AVR auch nie bestritten)> ob bei 8-bit MSR jetzt die Vor- oder die Nachteile überwiegen, ist mir> immer noch egal.. (auch nach 2000 Posts wir es sich nicht ändern..)>> Auch wenn jetzt 90% der/meine Projekt(chen) in die Kategorie (8-bit MSR)> fallen WÜRDEN, wäre es mir egal..
Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch
antworten. Er hat seine Meinung, die anderen die ihre. Ich halte Mobys
Ansicht auch für falsch, aber: was soll's? Ich muss ja nicht für ihn in
Assembler programmieren sondern kann das nehmen, was meiner Erfahrung
nach am schnellsten zum Ziel führt. Die Zeiten, wo ich Bytes sparen
musste, sind gottseidank lange vorbei. Und Moby kann weiterhin seine
Dinge in Assembler ausführen. Das schadet hier wohl niemandem :-)
Chris D. schrieb:> Das hat den Vorteil, dass Schreiber mit - sagen wir "eigenwilligen> Ansichten" nicht alle Threads kapern sondern so ihrer Meinung Ausdruck> verleihen können, ohne den sonstigen Ablauf im Forum zu stören.
Genial: Honeypot für Moby. :-)
>Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch>antworten.
also ich weiß schon warum ich hier antworte, weißt du das bei dir nicht
;-)
ich werde aber (so wie du) Moby nicht mehr direkt Antworten und auch
nicht zum Thema (was jetzt blöderweise einem "Threads kapern"
gleichkommt.. ) ;-)
Robert L. schrieb:> also ich weiß schon warum ich hier antworte, weißt du das bei dir nicht> ;-)
Kannst Du bitte so zitieren, dass man auch sieht, auf welches Posting Du
Dich beziehst. Danke.
Moby A. schrieb:> Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt> werden ;-)
Hm, Du möchtest also vom schinken/käse Geschmack der Erdbeertorte
überzeugt werden ? Das könnte schwer werden.
Ebensowenig kann ich Dir die Quadratur des Kreises liefern.
Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist.
Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf
das sowas zutrifft.
Ich kann Dir nicht den Vorteil eines Nachteiles beweisen der einfach
nicht existiert. Du verlangst das unmögliche.
Die Nachteile von ASM hingegen hast Du uns nun wirklich sehr schlüssig
bewiesen bzw bestätigt.
ASM schein auch einen sehr negativen Einfluss darauf zu haben wie
aufgeschlossen man noch übergeordneten Problemlösungsstrategien ist.
Die Fähigkeit also das klein, klein zu verlassen und die begrenze
Ressource 'Brainpower' dazu zu verwenden größere Konzepte zu entwerfen.
Chris D. schrieb:> Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch> antworten.
Weil sich hier mehr Moderatoren aktiv beteiligen als in jedem anderen
Thread.
Die ASM Leier ist natürlich immer dieselbe, aber sieh doch was sich hier
schon für überaus unterhaltsame Nebendiskussionen ergeben haben.
So ein wenig in der eigenen und fremden Historie zu graben finde ich
sehr erfrischend.
Michael K. schrieb:> Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist.> Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf> das sowas zutrifft.
Kryptisch trifft zu. Der Rest nicht.
Paradebeispiel einer bürokratischen Sprache ist COBOL:
1
000100 IDENTIFICATION DIVISION.
2
000200 PROGRAM-ID. HELLOWORLD.
3
000300
4
000400*
5
000500 ENVIRONMENT DIVISION.
6
000600 CONFIGURATION SECTION.
7
000700 SOURCE-COMPUTER. RM-COBOL.
8
000800 OBJECT-COMPUTER. RM-COBOL.
9
000900
10
001000 DATA DIVISION.
11
001100 FILE SECTION.
12
001200
13
100000 PROCEDURE DIVISION.
14
100100
15
100200 MAIN-LOGIC SECTION.
16
100300 BEGIN.
17
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
18
100500 DISPLAY "Hello world!" LINE 15 POSITION 10.
Michael K. schrieb:> aber sieh doch was sich hier> schon für überaus unterhaltsame Nebendiskussionen ergeben haben.> So ein wenig in der eigenen und fremden Historie zu graben finde ich> sehr erfrischend.
Da hast Du Recht - die Beiträge dazu sind wirklich interessant.
Irgendwo müsste ich auch noch zwei (nagelneue) 8749 rumfliegen haben.
Dafür wollte ich mir immer ein Programmiergerät gebaut haben und sie als
"Coprozessoren" an meinem Plus/4 einsetzen - aber dann rauchte der ab,
weil Optokoppler noch ein Fremdwort für mich waren. Man lernt durch
(finanziellen) Schmerz aber schnell und gründlich ;-)
Edit: gerade nachgeschaut - ich hab die tatsächlich noch :-) Ja, das
waren noch Gehäuse: Keramik, Quarzglas, wunderbar!
A. K. schrieb:> Kryptisch trifft zu.
wobei es einen ASM Programmieren, mit der "ich mach mir alles selber"
Einstellung, erstmals überhaupt nicht tangieren würde..
seinen EIGENEN Code, muss man ja nicht absichtlich kryptisch schreiben..
ein paar Anregungen was man in C zwar kann, aber nicht unbedingt machen
sollte gibts ja z.b. hier:
https://de.wikipedia.org/wiki/MISRA-C
Robert L. schrieb:> seinen EIGENEN Code, muss man ja nicht absichtlich kryptisch schreiben..
In C schon. Die Sprache selbst ist kryptisch, mit ihrer Nutzung von
allerlei Sonderzeichen und seltsamer Deklarationssyntax. Ist schon ein
Unterschied, ob da
char (*ptr1)[10]
char *ptr2[10]
oder sowas wie
dcl ptr1 as pointer to array [0..9] of char
dcl ptr2 as array [0..9] of pointer to char
steht.
Chris D. schrieb:> Dafür wollte ich mir immer ein Programmiergerät gebaut haben und sie als> "Coprozessoren" an meinem Plus/4 einsetzen
Sowas ähnliches wollte ich mal mit einem Z8 UPC machen, von dem ich ein
paar Exemplare rumliegen hatte. Ein µC, den man an als Slave einen
normalen 8-Bit Bus hängen kann und dessen Programm darüber in ein
Huckpack-SRAM geladen wird. Sieht optisch ähnlich eindrucksvoll aus.
Könnte man prima an ein FT2232 im Bus-Modus dranhängen.
Hatte nur einen Haken: Das Mistvieh legt per /WAIT den Bus für 5-10µs
lahm, wenn man drauf zugreift. Ist wohl eine Art Interrupt für den µC
nötig, damit der den internen Bus freigibt. Da geht der Sinn eines
Koporzessors ziemlich tief den Bach runter.
@ A. K.
ja, stimmt schon
>char (*ptr1)[10]>char *ptr2[10]
könnte man aber schon auch verständlicher schreiben?:
const int MaxLengthFileName = 10;
typedef char uCharArray_FileName[MaxLengthFileName];
uCharArray_FileName* ptr1
char* array2[irgendEineAndereKonstante]
Robert L. schrieb:> const int MaxLengthFileName = 10;> typedef char uCharArray_FileName[MaxLengthFileName];
Klappt in C nicht. "const" definiert keine Konstante, sondern eine
invariable Variable. ;-)
Ausserdem ist das nur ein Bisschen Zucker auf einer verbockten Syntax.
Die Deklarationen liessen sich ungefähr so einigermassen retten:
typedef char arrayOfChar[10];
arrayOfChar *ptr1;
typedef char *ptrToChar;
ptrToChar ptr2[10];
damit man nicht selbst recursive descent parser spielen muss, um diese
beiden Fälle korrekt zu unterscheiden und einzutüten.
A. K. schrieb:> In C schon. Die Sprache selbst ist kryptisch
Ich habe einen Narren am Fragezeichen-Operator gefressen, der ist
einfach cool... ;-)
Ich habe den Link wieder gefunden:
Beitrag "Re: VHDL: 4Bit Hex -> ASCII"
Moby A. schrieb:> P. M. schrieb:>> Ich möchte echt mal wissen, wer hinter diesem Moby steckt.>> Das ist einer Deiner Fehler: Du stellst die falschen Fragen. Mach Dir> lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau> gestellten Assembler-Überlegenheit zu begegnen ist ;-)
Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst
erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich
weitgehend einig, nur eine Person hält noch dagegen - diese Person
bringt aber weder Argumente noch kann sie auf einschlägige Erfahrung
verweisen. Sondern sie postuliert einfach, recht zu haben, so lange der
Standpunkt nicht widerlegt ist. Wobei sie natürlich definiert, was
widerlegt heisst.
P. M. schrieb:> Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst> erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich> weitgehend einig
... daß sich Assembler im umrissenen Einsatzgebiet nicht schlagen lässt,
meinst Du? Die C-Koryphäen schleichen wie Katzen um den heißen Brei
meines Projekts und keiner traut sich. Woran es allerdings nicht fehlt
ist allerlei Smalltalk und Ausreden so wie diese hier:
> kann sie auf einschlägige Erfahrung> verweisen> Wobei sie natürlich definiert, was> widerlegt heisst
Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar:
Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität.
Am Ende siegt aber dann doch die Angst ;-)
Frank M. schrieb:>> Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt>> werden ;-)>> Willst Du doch gar nicht. Du lügst. ;-)
Das tät ich schon gerne. Die Unwahrheit würd ich aber sagen, wenn ich es
hier offiziell für möglich halten würde, an besagten Nutzen zu glauben
;-)
Chris D. schrieb:> Was wir deswegen in Zukunft freundlich aber bestimmt unterbinden werden> ist eine Verlagerung in weitere Threads.
Dabei wärs so sinnvoll, gerade am praktischen Beispiel irgend einer
C-Unzulänglichkeit die Asm-Vorteile zu demonstrieren und nicht in einem
einzelnen Thread ein wenig ins Blaue hinein, da das vorhandene, konkrete
Demo-Projekt ja wie der Teufel das Weihwasser gemieden wird ;-)
P. M. schrieb:> Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz> konkretes Beispiel.Beitrag "Kleines Tiny13 Sensorboard"
;Segment Begin End Code Data Used Size Use%
; ---------------------------------------------------------------
; [.cseg] 0x000000 0x0000d8 216 0 216 1024 21.1%
; [.dseg] 0x000060 0x000060 0 0 0 64 0.0%
; [.eseg] 0x000000 0x000000 0 0 0 64 0.0%
; Assembly complete, 0 errors. 0 warnings
Moby A. schrieb:> P. M. schrieb:>> Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz>> konkretes Beispiel.>> Beitrag "Kleines Tiny13 Sensorboard"
Stimmt. Das kannst du in C nicht. Weil du kein C kannst. Und daraus
extrapolierst du, dass es alle anderen auch nicht gut hinkriegen würden.
Moby A. schrieb:> Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar:> Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität.
Dann erklär mir jetzt bitte mal, warum man das mit exakt deinem
Beispiel nachweisen kann, während der erbrachte (!!!) Beweis von Yalu
völlig ungültig sein soll.
Michael K. schrieb:> Hm, Du möchtest also vom schinken/käse Geschmack der Erdbeertorte> überzeugt werden ? Das könnte schwer werden.> Ebensowenig kann ich Dir die Quadratur des Kreises liefern.
So ist es. Die Vorteile von Asm sind wie in Stein gemeißelt, da beißt
man sich nur die Zähne dran aus!
> Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist.> Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf> das sowas zutrifft.
Dafür kenne ich Asm ;-)
> Die Nachteile von ASM hingegen hast Du uns nun wirklich sehr schlüssig> bewiesen bzw bestätigt.
In meinem noch nicht geschlagenen Projekt, meinst Du?
> ASM schein auch einen sehr negativen Einfluss darauf zu haben wie> aufgeschlossen man noch übergeordneten Problemlösungsstrategien ist.> Die Fähigkeit also das klein, klein zu verlassen und die begrenze> Ressource 'Brainpower' dazu zu verwenden größere Konzepte zu entwerfen.
"Größere Konzepte" bitte dahin wo sie hingehören.
Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und
Datenmengen überzustülpen bringt nur eins: O v e r h e a d !
Klaus W. schrieb:> sorry, muß wohl noch was nachreichen: :-)
Genau. Das hier:
Moby A. schrieb:> Klaus W. schrieb:>> Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und>> alle anderen nicht mehr brauchen als du?>> Den Mehrverbrauch im SmartHome wirst Du mir sicher gleich erläutern.> Insbesondere interessieren mich die Stellen, wo man mit Asm undoder> 8-Bit nicht mehr weiter kommt ;-)
Moby A. schrieb:> Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und> Datenmengen überzustülpen bringt nur eins: O v e r h e a d !
Dann zeig doch mal eine R-Anwendung in Assembler... :-D
P. M. schrieb:> Dann erklär mir jetzt bitte mal, warum man das mit exakt deinem> Beispiel nachweisen kann, während der erbrachte (!!!) Beweis von Yalu> völlig ungültig sein soll.
Warum soll ich Dir hier was erklären wenn ich das bereits ausführlich
getan habe? Kleine Vorab-Info: Erbracht ist gar nichts.
So Du Dir die Mühe machst die entsprechend stichpunkt-artige Begründung
herauszusuchen und darauf im Einzelnen einzugehen mach ich mir die Mühe
das (nochmal) mit einer Antwort zu würdigen ;-)
P. M. schrieb:> Und daraus> extrapolierst du,
Ich extrapoliere gar nichts sondern stelle nur fest.
Chris D. schrieb:> Die Zeiten, wo ich Bytes sparen> musste, sind gottseidank lange vorbei.
Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen
Win-PC, die nur noch GHz Prozessoren stemmen.
Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist
bei Controllern in vollem Gange. Also, bedient Euch ;-)
Moby A. schrieb:> Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und> Datenmengen überzustülpen bringt nur eins: O v e r h e a d !
Wir drehen uns im Kreis.
Das was du unter 'typisch' verstehst, ist es eben für die meisten
anderen nicht.
und bei den Dingen, die du bisher als 'typisch' vorgebracht hast, war es
völlig egal, ob das Programm im Flash 18 oder doch 21% belegt oder
nicht.
Moby A. schrieb:> Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen> Win-PC, die nur noch GHz Prozessoren stemmen.
Das was ein heutiger PC im Hintergrund noch alles mit erledigt, kannst
du dir doch gar nicht vorstellen.
Moby A. schrieb:> P. M. schrieb:>> Und daraus>> extrapolierst du,>> Ich extrapoliere gar nichts sondern stelle nur fest.
Nö. Stimmt schon. Du extrapolierst.
Du extrapolierst aus einer simplen Aufgabe, die du mit ein paar
Anweisungen erledigen kannst auf das Verhalten von größeren Programmen.
Und genau das ist nicht zulässig. Denn die zu bearbeitende Komplexität
steigt nicht linear sondern mindestens exponentiell. Genau deshalb sind
grosse Systeme auch so schwer zu schreiben, weil es mit jedem
zusätzlichen Subsystem immer schwieriger wird, die Querverbinden und
Verflechtungen im Auge zu behalten.
Genau das predigen wir hier die ganze Zeit.
> Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist> bei Controllern in vollem Gange. Also, bedient Euch ;-)
hi,
was verstehst du eigentlich unter MSR? Eine typische MSR-Anwendung wäre
in meinen Augen zum Beispiel die Implementierung eines Kalmannfilters +
PID Regler. Das ist aber unter Umständen eine reichlich Rechenintensive
Geschichte...
Ich glaube du unterschätzt den Begriff "MSR" erheblich. Jedenfalls ist
die Reglungstechnik eine Wissenschaft für sich und der Komplexitätsgrad
kann bei weitem "kleine Tiny-Sachen" übersteigen. Durchaus auch im
Hobbybereich.
Ich denke du stellst dir unter MSR immer etwas Simples vor. Das mag hie
und da zutreffen, aber es gibt viele Anwendungen, da ist ein Cortex
sinnig.
Moby A. schrieb:> So Du Dir die Mühe machst die entsprechend stichpunkt-artige Begründung> herauszusuchen und darauf im Einzelnen einzugehen mach ich mir die Mühe> das (nochmal) mit einer Antwort zu würdigen ;-)
Wenn du auch nur auf etwas eingehen würdest, dann hättest du vor rund
1000 Beiträgen eingesehen: Ja, ihr habt recht, Assembler ist nur für
sehr wenige Spezialfälle die erste Wahl, im grossen und ganzen ist die
Programmierung in C aber weit überlegen. Dann hättest du etwas
gelernt, und wir hätten weniger von unserer Zeit verschwendet.
(Zugegeben, so ein bisschen Spass macht es schon - wie früher wenn man
den Klassendepp mit seinen absurden Ansichten noch ein bisschen
aufgezogen hat.)
P. M. schrieb:> Dann zeig doch mal eine R-Anwendung in Assembler... :-D
Da gibts nix zum Lachen, sonst würd ich jetzt im Kalten sitzen ;-)
An eine Regelung zur Raumtemperatur müssen keine hohen Anforderungen
gestellt werden- wenn man's denn richtig macht.
Überhaupt ist MSR fürs SmartHome eine gemächliche Angelegenheit:
Messwerte für Temperatur, Feuchte, Druck, Helligkeit, CO2 usw. fallen
nicht im Tausendstel-Sekundentakt an, digitale Ein/Ausgaben z.B. einer
Tür-Geöffnet Anzeige oder eines Fensteröffners oder Lampe nicht im kHz
Bereich usw. usf.
8-Bit MSR ohne große Berechnungen und Datenmengen im Reinformat.
Das ist es immer woran ich denken muß, wenn mir selbsternannte Koryphäen
hier die Verwendung von bürokratischem C- am besten auf 32-Bit Technik-
raten ;-)
Thomas E. schrieb:> Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal> um diese Funktion erweitert.
Das ist aber schön für Dich.
Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen
werde. Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die
bloße Register-Initialisierung noch nicht die großen Unterschiede
bringt. Eher ist da der bürokratische Aufwand, veranschaulicht im
Quelltext interessant. Immerhin hast Du den in Deinem Nonsens-Beispiel
gut herausgearbeitet ;-)
Moby A. schrieb:> Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist> bei Controllern in vollem Gange. Also, bedient Euch ;-)
Das tun wir gerne - es ist schön zu sehen, dass mein vor zehn Jahren für
AVRs geschriebener C-Code ohne große Probleme auf den neuen
Architekturen läuft und dank der Leistungsfähigkeit Aufgaben wie
Grafikausgabe oder Bildverarbeitung, die früher in (teuren) eigenen
Modulen laufen mussten, vom Controller selbst übernommern werden.
Also: weniger Zeitaufwand, weniger Hardwareaufwand = mehr Geld für mich
:-)
P. M. schrieb:> Wenn du auch nur auf etwas eingehen würdest, dann hättest du vor rund> 1000 Beiträgen eingesehen: Ja, ihr habt recht, Assembler ist nur für> sehr wenige Spezialfälle die erste Wahl, im grossen und ganzen ist die> Programmierung in C aber weit überlegen. Dann hättest du etwas> gelernt, und wir hätten weniger von unserer Zeit verschwendet.
Ich seh schon, es ist Dir die Mühe gar nicht wert.
Soooo hab ich das erwartet ;-)
Auf die (gefühlte) Zeitverschwendung von irgend jemandem hab ich keinen
Einfluß. Eher tuts mir manchmal um die eigene leid. Niemand ist
gezwungen, hier seinen Senf hinzuzugeben. Wenn dennoch soviele Beiträge
zusammenkommen liegts aber vielleicht´a) an meiner Ernsthaftigkeit und
b) daran, daß die meisten wohl die Vorteilen von Asm anerkennen, dies
aber gegenüber einem dahergelaufenen Bastler partout nicht zugegeben
werden kann. Immerhin stellt das auch eine Teilmenge persönlicher
Investitionen, Lernzeit oder gar Studienzeit in Frage ;-)
Denk mal darüber nach!
>So ist es. Die Vorteile von Asm sind wie in Stein gemeißelt, da beißt>man sich nur die Zähne dran aus!
Dann präsentiere doch mal Leute, für die das nicht nur Hobby ist. Wen
kennst DU, der beruflich ASM programmiert??
>Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen>werde.
Warum sollen wir das dann tun? Die faire Aufgabe, eine ANforderung in
Klartext zu schreiben und durch dich in ASM und andere in C umzusetzen,
hast du abgeleht.
Chris D. schrieb:> Das tun wir gerne - es ist schön zu sehen, dass mein vor zehn Jahren für> AVRs geschriebener C-Code ohne große Probleme auf den neuen> Architekturen läuft und dank der Leistungsfähigkeit Aufgaben wie> Grafikausgabe oder Bildverarbeitung, die früher in (teuren) eigenen> Modulen laufen mussten, vom Controller selbst übernommern werden.
Prima. Wenn man Grafik-Ausgaben und Bildverarbeitung hat und haben will.
Fürs SmartHome brauchst Du das aber nicht unbedingt.
Entweder, weil mans günstig kaufen kann oder aber weil man Text +
grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-)
Moby A. schrieb:> Thomas E. schrieb:>> Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal>> um diese Funktion erweitert.>> Das ist aber schön für Dich.> Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen> werde.
Verstehe ich. Fakten würden ja stören, denn sie sind nunmal nicht mit
deiner Meinung kompatibel.
Matthias L. schrieb:> Warum sollen wir das dann tun? Die faire Aufgabe, eine ANforderung in> Klartext zu schreiben und durch dich in ASM und andere in C umzusetzen,> hast du abgeleht.
Die Anforderungen und die simple Funktion sind längst ausreichendst
dokumentiert. Eine Ausrede, die fauler nicht sein kann.
Matthias L. schrieb:> Dann präsentiere doch mal Leute, für die das nicht nur Hobby ist. Wen> kennst DU, der beruflich ASM programmiert??
Ich rede fürs Hobby, klar. Was aber nicht bedeutet, daß die gleiche
Vorgehensweise nicht auch zahlreichen Firmen-MSR-Projekten auf ähnlichem
Niveau gut täte! Aber mir ist klar, daß beruflich noch weitere
Prioritäten eine Rolle spielen. Nur- um die gehts mir gar nicht. Mir
gehts nur um den Vergleich von Asm vs. C. Im Ressourcen-Bedarf, im
bürokratischen Aufwand, im Lernaufwand. Immer schön gemessen an den
Bedürfnissen eines konkreten Projekts aus dem hinlänglich umrissenen
Einsatzbereich.
Moby A. schrieb:> Entweder, weil mans günstig kaufen kann oder aber weil man Text +> grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-)
Da hast Du dich nun aber mächtig ins Zeug gelegt. Einen Webserver in ASM
mit grafischer Ausgabe zu programmieren.
Wäre doch toll wenn Du das unter Code&Projekt veröffentlichen würdest.
Dann wärst du wirklich der ASM Gott
P. M. schrieb:> Verstehe ich. Fakten würden ja stören, denn sie sind nunmal nicht mit> deiner Meinung kompatibel.
Nö. Mit meiner Zeit. Eingebracht hab ich zur Demonstration der
Asm-Vorteile immerhin ein größeres Projekt was wirklich was Sinnvolles
tut (und bei mir schon im Einsatz ist). "Größeres" sag ich deshalb weil
es für die Allermeisten hier tatsächlich schon "zu groß" zur Analyse und
zum Nachbau ist ;-)
Moby A. schrieb:> Fürs SmartHome brauchst Du das aber nicht unbedingt.> Entweder, weil mans günstig kaufen kann oder aber weil man Text +> grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-)
Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen
Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren
und tonnenweise ineffiziente Software ;-)
Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf
erledigt das hier alles ein einziger, preiswerter, schneller,
hocheffizienter und stromsparender Chip ;-)
Ist doch merkwürdig, Moby ist so gegen C. Eigentlich sollte er
konsequenterweise jegliche Software und Module ablehnen und nicht
benutzen, die mit/in C geschrieben geschrieben wurden.
Also es sollte weder Windows, noch Linux, oder auch kein Mac benutzen.
Er sollte auch niemals einen Router für Internet einsetzen oder andere
Geräte mit µC kaufen, denn die könnten alle mit dem verpönten C belastet
sein.
Genau so wie ein Veganer auch niemals ein Ei essen wird.
Er ist einfach nicht konsequent.
Markus M. schrieb:> Da hast Du dich nun aber mächtig ins Zeug gelegt. Einen Webserver in ASM> mit grafischer Ausgabe zu programmieren.
Den brauchts dazu aber nicht.
Weißt Du vermutlich...
Und Asm-Gott wollte ich allen Unterstellungen zum Trotz nie werden ;-)
Michael K. schrieb:> Woher willst Du das wissen wenn Du noch niemals überprüft hast welch> eleganten Konstruktionen ein C Compiler zustande bekommt ?
Deine Eleganz in allen Ehren, mein Projekt ist trotzdem seit Monaten
ungeschlagen ;-)
> Nun ist es ein Nachteil von C den gröbsten Blödsinn von mir abzufangen> und ein Vorteil von ASM jedes Nachlassen der Konzentration sofort und> unmittelbar aufs härteste zu bestrafen ?
Gebratene Tauben fliegen einem nirgendwo in den offenen Mund.
99% meiner Fehler gehen auf Fehler im PAP bzw. auf in der Praxis
auftretende, seltene Messwert-Konstellationen oder Protokoll-Konflikte
zurück- die man nicht im Fokus hatte. Das wäre alles 1:1 bei C
dasselbe Problem. Löse Dich von der Vorstellung, es ginge bei Asm
vorrangig darum, einen großen Instruktions Flag-Zirkus oder die
Register-Verwendung zu beherrschen.
> Dank Yalus Code wissen wir das C besser optimiert, selbts bei kleinsten> Programmen.> C fängt meine Fehler ab, ASM lässt mich voll reinrauschen.
Siehe weiter oben und das, was ich gerade sagte!
> C kann ich jederzeit und überall in jede Richtung erweitern, umbauen,> eindampfen und der Compiler regelt das schon hinter den Kulissen.> ASM braucht Übung, Vorbereitung, System und wenn ich da Mist mache dann> bin ich fällig und kann nicht mehr vor und nicht zurück ohne alles neu> zu schreiben.
Unfug. Übung, Vorbereitung und System vorausgesetzt- was kein
zusätzliches Studium eines ganzen Hochsprachen-Universums erfordert!
> Bei C+IDE ist debuggen so schwer wie in der Nase bohren, bei ASM muss> ich erst einen Batzen Routinen für dieses und jedes fertig haben und> dann auch jeweils ganz genau wissen was ich in diesem Programteil machen> darf und was nicht.
Richtig. Die hat man. Das ist die Vorbereitung. Mit System wird dann
verknüpft. Indem ich (durch Asm) bei 8 Bit AVR bleiben kann ist das
nur eine einmalige Investition. Hinzu kommt: Die AVR-Hardware ist
überschaubar.
> Große C Programme schreibe ich so wie kleine und die Codedichte ist> immer gleich
... aber kleiner als bei Asm-Programmen für bis mittelgroße Projekte.
> Kleine ASM Programme optimiere ich bis aufs Blut für jedes Bit für große> macht man copy paste und verschenkt viel Optimierungspotential weil man> den Überblick sonst nicht behalten kann.
Du optimierst? In Asm? Na bravo- genau das mach ich ja auch!
Bei größeren Programmen verschenkt man weniger Potential als Du hier
vorgibst- wenn man nämlich vorhandenes, effizientes Codematerial nur
miteinander verknüpft. Meine Verschwendung bei größeren Programmen für
mehr Übersicht besteht im wesentlichen nur darin, daß ich die
enthaltenen sequentiell abzuarbeitenden Bausteine in Form einer
Call-Liste aufrufe, die sich auch leicht abändern lässt. In einem
finalen Schritt könnte man die Funktionalität zusammenfassen, darunter
leidet aber die Übersicht mehr als daß es der gesparte Flashspeicher
wert ist.
> In C kann ich jederzeit ohne großen Aufwand die MCU Familie wechseln in> ASM muß ich alles neu schreiben.
Und ich brauch gar nicht erst wechseln- das ist gerade der gradiosen
Asm-Effizienz geschuldet ;-)
Chris D. schrieb:> Moby A. schrieb:>>> Fürs SmartHome brauchst Du das aber nicht unbedingt.>> Entweder, weil mans günstig kaufen kann oder aber weil man Text +>> grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-)>> Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen> Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren> und tonnenweise ineffiziente Software ;-)>> Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf> erledigt das hier alles ein einziger, preiswerter, schneller,> hocheffizienter und stromsparender Chip ;-)
Wenn ich jetzt verraten würde, daß ich für MSR-Anwendungen im
Hausbereiche gerade JavaScript und Lua evaluiere, dann würde ich auf den
ASM-Scheiterhaufen geführt werden. Aber so hab ich Web und Logging und
graphische Verknüpfung (node-red) und das alles Dank V8-Engine in
Compiler-Speed. Ging natürlich auch in ASM, aber in meinem Alter muß es
unter Jahren fertig werden.
Chris D. schrieb:> Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen> Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren> und tonnenweise ineffiziente Software ;-)
Aber woher denn. Das schickt mein XPort ins Netz ;-)
> Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf> erledigt das hier alles ein einziger, preiswerter, schneller,> hocheffizienter und stromsparender Chip ;
Super. Ja doch. Wär von der Hardware-Seite her effizienter auch wenn Du
mit "irrsinnig" jetzt maßlos übertreibst. In der Praxis ist man
Hardware-modular aber wesentlich flexibler. Warum schließlich soll ich
mich mit Grafik-Ausgaben und Bildverarbeitung abrackern wenn das alles
fertig zu haben ist?
Markus M. schrieb:> Also es sollte weder Windows, noch Linux, oder auch kein Mac benutzen.> Er sollte auch niemals einen Router für Internet einsetzen oder andere> Geräte mit µC kaufen, denn die könnten alle mit dem verpönten C belastet> sein.
Was für ein Gelaber...
Ich hoffe und nehme aber an mit Augenzwinkern ;-)
In diesem Sinne bis morgen. Moby muß früh raus ;-(
Moby A. schrieb:> Ich rede fürs Hobby, klar. Was aber nicht bedeutet, daß die gleiche> Vorgehensweise nicht auch zahlreichen Firmen-MSR-Projekten auf ähnlichem> Niveau gut täte! Aber mir ist klar, daß beruflich noch weitere> Prioritäten eine Rolle spielen. Nur- um die gehts mir gar nicht. Mir> gehts nur um den Vergleich von Asm vs. C. Im Ressourcen-Bedarf, im> bürokratischen Aufwand, im Lernaufwand. Immer schön gemessen an den> Bedürfnissen eines konkreten Projekts aus dem hinlänglich umrissenen> Einsatzbereich.
Ich identifiziere mindestens 5 Punkte in diesem Satz, die lang und breit
widerlegt wurden. Wo in der Fachwelt nun wirklich keine Zweifel mehr
bestehen. Was du mit einer sehr kurzen Recherche oder ein paar eigenen C
Experimenten problemlos nachvollziehen könntest. Das ist ungefähr das,
was interessierte/intelligente Leute machen, wenn sie in einer
Diskussion auf Gegenrede stossen.
Du hingegen erfindest ein absurdes Netz an Bedingungen, die erfüllt sein
müssen, damit du allenfalls bereit wärst, dich von der Gegenposition
überzeugen zu lassen. Merkst du eigentlich nicht, wie dumm und
hinderlich das für dich selbst ist?
Moby A. schrieb:> Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die> bloße Register-Initialisierung noch nicht die großen Unterschiede> bringt. Eher ist da der bürokratische Aufwand, veranschaulicht im> Quelltext interessant.
Jein.
Es stimmt wohl, dass eine handelsübliche Zeile C-Code länger ist als
eine Zeile Assembler.
Allerdings ist die C-Zeile aber auch vielfach mächtiger.
Kleines Beispiel:
Über ein Array von ADC-Messwerten (10 Bit) iterieren und den kleinsten
Wert heraussuchen.
In C kriegt man das in 2 Zeilen, vielleicht 4-5 wenns besser lesbar sein
soll.
In ASM schätze ich wirds länger.
Wie bewertest du also "Bürokratie"? Anzahl der Zeilen? Anzahl der
Spalten? Anzahl der Zeichen?
Oder war "Bürokratie" bei dir das Angeben-müssen von Datentypen?
Nun, dieses "Argument" hab ich dir ja schon mal demontiert.
Und, das Format heutiger Bildschirme im Hinterkopf, was machst du
eigentlich mit dem ganzen Platz links und rechts vom Listing?!
le x. schrieb:> Über ein Array von ADC-Messwerten (10 Bit) iterieren und den kleinsten> Wert heraussuchen.
Das ist doch kein 8bit MSR. Ausserdem kann man sowas als externes Modul
dazukaufen.
Moby A. schrieb:> Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen> werde.
Das hat niemand erwartet.
Von nichts kommt einfach nichts. Das ist jedem hier klar.
> Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die> bloße Register-Initialisierung noch nicht die großen Unterschiede> bringt.
Nur geht es nicht nur um die blosse Registerinitialisierung. Aber das
kannst du ja auch nicht wissen.
> Eher ist da der bürokratische Aufwand, veranschaulicht im> Quelltext interessant.
Den Quelltext wirst du nicht zu sehen bekommen. Wozu auch? Verstehst es
ja ohnehin nicht.
> Immerhin hast Du den in Deinem Nonsens-Beispiel gut herausgearbeitet
Nonsens nennst du das jetzt. Mal sehen, was als nächstes kommt, um von
deinen Unzulänglichkeiten, effizienten Asm-Code zu produzieren,
abzulenken.
Dieser Code funktioniert. Er macht exakt das, was er soll.
Und das mit absoluter Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
Da kommst du mit deinem Dödelprogramm nur nicht im entferntesten heran.
Das ärgert dich natürlich.
[deletia]
mfg.
Moby A. schrieb:> P. M. schrieb:>>> Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst>> erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich>> weitgehend einig>> ... daß sich Assembler im umrissenen Einsatzgebiet nicht schlagen lässt,> meinst Du? Die C-Koryphäen schleichen wie Katzen um den heißen Brei> meines Projekts und keiner traut sich. Woran es allerdings nicht fehlt> ist allerlei Smalltalk und Ausreden so wie diese hier:>>> kann sie auf einschlägige Erfahrung>> verweisen>>> Wobei sie natürlich definiert, was>> widerlegt heisst>> Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar:> Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität.> Am Ende siegt aber dann doch die Angst ;-)
Ja Moby. Die C-Koryphäen sind mit ihrem Latein nun am Ende. Dafür sind
aber wissenschaftliche Einrichtungen an deutschen Hochschulen und
Universitäten auf dein geniales Schaffen aufmerksam geworden und widmen
nun ihre Forschungen in deine Richtung.
Außerdem munkelt man in Fachkreisen, dass dein genialer Code verfilmt
werden soll. Bekannte Kurzfilmkoryphäen schlagen sich um das Drehbuch,
welches nur 5 Seiten hat! Die Filmmusik wird der geniale A.S. Melchior
komponieren. Er kommt mit nur 5 Tönen und 2 Instrumenten aus.
Koreographen arbeiten mit Hochdruck an einem Ballett, in dem nur dein
Code Einbeinigen getanzt von wird.
Eine ganz große C-Koryphäe wird sich deinen Code sogar auf sein bestes
Stück tätowieren lassen. Von der Länge passt er zum Glück!
Alter, du bist mein Held.
Mit so einer wahnsinns Portion Selbstüberschätzung lebt es sich doch
einfach prima. Nur leider interessiert dein Code hier niemand mehr.
Warum wohl? Denk mal darüber nach.
Moby A. schrieb:> Mir> gehts nur um den Vergleich von Asm vs. C.
Warum? Bist du nicht mehr glücklich mit Asm? Für dich und deine
Anwendungen ist doch ASM genau das Richtige. Du beherrscht es, dein
Programm läuft und der Hochsprachenlernaufwand lohnt dafür wirklich
nicht.
Ähm, worum geht es in dem Thread noch mal?
Witkatz :. schrieb:> Ähm, worum geht es in dem Thread noch mal?
„Assembler auf dem Weg nach vorn“ – auch wenn es halt nur durch eine
andere Wortwahl bei den Suchbegriffen ist. ;-)
Jörg W. schrieb:>> Ähm, worum geht es in dem Thread noch mal?>> „Assembler auf dem Weg nach vorn“ – auch wenn es halt nur durch eine> andere Wortwahl bei den Suchbegriffen ist. ;-)
Ach ja, danke.
Assembler, ach was waren das für entschleunigte Zeiten... ;-)
Ich glaube, heute ist das was für Puristen und man muss es einfach
lieben, so wie Naked Bikes und Oldtimer.
Vielleicht ist an der Statistik wirklich was dran und es deutet sich ein
nostalgischer Modetrend für Assembler und vergessene CPU's an?
Witkatz :. schrieb:
> Warum? Bist du nicht mehr glücklich mit Asm? Für dich und deine> Anwendungen ist doch ASM genau das Richtige. Du beherrscht es, dein> Programm läuft und der Hochsprachenlernaufwand lohnt dafür wirklich> nicht.>> Ähm, worum geht es in dem Thread noch mal?
Warum sollte bloß ich damit glücklich werden?
Warum sollte ich meine Aussage nicht mit Code beweisen dürfen?
Thomas E. schrieb:
> Da kommst du mit deinem Dödelprogramm nur nicht im entferntesten heran.> Das ärgert dich natürlich.
Warum denn?
Das würde ja zumindest mal den gleichen Funktionsumfang voraussetzen.
Da bist Du weit entfernt von ;-)
Markus M. schrieb:
> Nur leider interessiert dein Code hier niemand mehr.> Warum wohl? Denk mal darüber nach.
Weil er sich mit C nicht toppen läßt vielleicht?
Thomas E. schrieb:
> Hamburg ist bereit.
Klasse!
Witkatz :. schrieb:
> Vielleicht ist an der Statistik wirklich was dran und es deutet sich ein> nostalgischer Modetrend für Assembler und vergessene CPU's an?
Dafür wurde eine halbwegs plausible Erklärung längst geliefert!
Markus M. schrieb:
> Ja Moby. Die C-Koryphäen sind mit ihrem Latein nun am Ende. Dafür sind> aber wissenschaftliche Einrichtungen an deutschen Hochschulen und> Universitäten auf dein geniales Schaffen aufmerksam geworden und widmen> nun ihre Forschungen in deine Richtung.
Du übertreibst meine Ambitionen.
So wie Übertreibung hier eines der beliebtesten Stilmittel gedemütigter
C-Koryphäen ist ;-)
Wieder mal nur Lächerlich-Machen statt harter Fakten.
Der oft frequentierte Notausgang aus der Manege ;-)
le x. schrieb:> Allerdings ist die C-Zeile aber auch vielfach mächtiger.
Aber die Komplexität der Ausdrücke!
Aber die Kryptizität der Ausdrücke!
> Wie bewertest du also "Bürokratie"? Anzahl der Zeilen? Anzahl der> Spalten? Anzahl der Zeichen?
Bürokratie= Gesamtheit des Sprachumfangs, Regeln, Vorschriften, Typen,
Operatoren, Deklarationen usw.
> Oder war "Bürokratie" bei dir das Angeben-müssen von Datentypen?> Nun, dieses "Argument" hab ich dir ja schon mal demontiert.
Demontage? Was für ein großes Wort für dieses überflüssigste aller
überflüssigen Konstrukte!
Mein absoluter Liebling: Der Cast-Operator! Von der Abbildung konkreter
Projekt-Notwendigkeiten soweit entfernt wie eine Galaxie im Dark Field.
> Und, das Format heutiger Bildschirme im Hinterkopf, was machst du> eigentlich mit dem ganzen Platz links und rechts vom Listing?!
Vermutlich fühlst Du Dich schlecht wenn da nix mehr zu lesen ist. Ist
das eine unangenehme Leere? In Asm passen ggf. noch schöne Kommentare
hin!
Moby deine Kommentare über C hören sich so ähnlich an wie:
Feuer zu machen mit einem Feuerzeug ist so Komplexität und Kryptisch da
kann man an einem Regler die Flammengröße einstellen und man muss noch
auf einen Knopf drücken und kann sich sooo schnell verbrennen.
Ich bleibe bei meinem Feuerstein, da hab ich die Funkenbildung noch
selbst im Griff.
P. M. schrieb:> Ich identifiziere mindestens 5 Punkte in diesem Satz, die lang und breit> widerlegt wurden. Wo in der Fachwelt nun wirklich keine Zweifel mehr> bestehen.
Cool, wie Du für die Fachwelt sprichst.
Cool, wie Du mir die Fachwelt um die Ohren haust.
Leider seh ich für den umrissenen Einsatzbereich rein gar nichts
widerlegt!
> Du hingegen erfindest ein absurdes Netz an Bedingungen, die erfüllt sein> müssen
Erfüllt sein muß gar nichts außer von 100% Funktion. Schon mal gar
nicht im Hobby. Darum gehts hier aber nicht.
> Merkst du eigentlich nicht, wie dumm und> hinderlich das für dich selbst ist?
Ganz und gar nicht. Die Arbeit und das praktische Ergebnis meiner
Projekte beweisen mir jeden Tag das Gegenteil ;-)
Markus M. schrieb:> Ich bleibe bei meinem Feuerstein, da hab ich die Funkenbildung noch> selbst im Griff.
Ich bleibe bei dem was für die konkrete Aufgabenstellung am
einfachsten ist. Das kann ggf. auch eine Blink-LED sein ;-)
> M oby's> S imply> R esults
Carl D. schrieb:> Wenn ich jetzt verraten würde, daß ich für MSR-Anwendungen im> Hausbereiche gerade JavaScript und Lua evaluiere, dann würde ich auf den> ASM-Scheiterhaufen geführt werden. Aber so hab ich Web und Logging und> graphische Verknüpfung (node-red) und das alles Dank V8-Engine in> Compiler-Speed.
Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt
bist? Für MSR-Anwendungen im Hausbereich? Wenn aber etwas schnell fertig
werden soll und Du mit Lua vertraut bist- warum nicht.
Das berührt die Diskussion Asm vs. Hochsprache in punkto
Ressourceneinsparung und Effizienz aber in keinster Weise.
Jonny O. schrieb:> Ich glaube du unterschätzt den Begriff "MSR" erheblich.
Nein. Ich rede hier von 8-Bit MSR für datenarme und weniger
rechenintensive Anwendungen. Das es da viel mehr + anspruchsvolleres und
auch die Berechtigung für Hochspracheneinsatz (ggf. auf höherbittigen
MCs) gibt streitet doch niemand ab !
> Jedenfalls ist> die Reglungstechnik eine Wissenschaft für sich und der Komplexitätsgrad> kann bei weitem "kleine Tiny-Sachen" übersteigen. Durchaus auch im> Hobbybereich.
Im Hobbybereich? Aber sicher. Fürs SmartHome reicht 8-Bit MSR aber
locker aus. Wenn in Zukunft mehr Intelligenz in die If/Then Abläufe
reinkommt möglicherweise nicht mehr. Aber die IOT Auswertung soll sich
ja dann längst auf Servern im Netz abspielen.
MSR in Sensor/Aktorknoten wird sich nicht wesentlich ändern.
> Ich denke du stellst dir unter MSR immer etwas Simples vor. Das mag hie> aber es gibt viele Anwendungen, da ist ein Cortex> sinnig.
Kein Thema.
Moby A. schrieb:> Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt> bist?
...
Moby A. schrieb:> Aber die IOT Auswertung soll sich ja dann längst auf Servern im Netz> abspielen.
Jaja, die noch mehr Stromschluckende Hardware GRINSMoby A. schrieb:> Ich rede hier von 8-Bit MSR für datenarme und weniger> rechenintensive Anwendungen.
Und wieso sollte man für solche Anwendungen überhaupt sich die Mühe
machen das in Assembler mit maximaler Effizienz zu gestalten?
KOPFSCHÜTTEL
Ich habe immer noch nicht verstanden wieso ich Assembler lernen sollte,
wo ich doch schon C kann.
Moby A. schrieb:> Warum sollte bloß ich damit glücklich werden?> Warum sollte ich meine Aussage nicht mit Code beweisen dürfen?
Deine Aussage ist einzig und allein, dass man für eine simple
Steuerungsaufgabe keine Hochsprache lernen muss. Dein Code funktioniert
und du hast es bewiesen. Warum reicht dir das nicht?
Markus M. schrieb:> Moby A. schrieb:>> Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt>> bist?
Jaja, schönes Argument den Stromverbrauch anzuführen aber im gleichen
Zuge auf Gedeih und Verderb bei einer uralten Architektur zu bleiben.
Auf eine Hardware festgelegt bist auch nur Du mit Deinem ASM Gefriggel.
Moby A. schrieb:> Mein absoluter Liebling: Der Cast-Operator! Von der Abbildung konkreter> Projekt-Notwendigkeiten soweit entfernt wie eine Galaxie im Dark Field.
[Zitat]
Castings dienen dazu, die Bedeutung von Daten anders zu interpretieren,
bzw. der Programmiersprache zu sagen, dass man sich bewusst ist, was man
da eigentlich tut.
https://www.proggen.org/doku.php?id=c:cast
[Zitat Ende]
Wäre vieleicht doch mal ganz gut für Dich ein C Anfänger Tutorial
durchzuarbeiten.
Du würdest dann erkennen können das in genau solchen Dingen die großen
Vorteile einer dich unterstützenden Hochsprache bestehen.
Vergiss das, DU würdest das in 100 Jahren nicht erkennen können.
Moby A. schrieb:> Nein. Ich rede hier von 8-Bit MSR für datenarme und weniger> rechenintensive Anwendungen. Das es da viel mehr + anspruchsvolleres und> auch die Berechtigung für Hochspracheneinsatz (ggf. auf höherbittigen> MCs) gibt streitet doch niemand ab !
Also besteht die Effizienz von ASM darin das die Erweiterbarkeit da
aufhört wo ich auf Grund einer veränderten Problemstellung einen
Messwert direkt im Knoten verarbeiten müsste.
Die Effizient von ASM ist also dadurch gegeben das ich popelige
Messwerte an einen Server übermitteln muss damit der mir die
Berechnungen ausführt und zurückschickt.
Meine Güte ist das armseelig.
Welche verschrobenen Ansichten Du doch hast was unter MSR zu verstehen
ist.
MÜR (Messen, Übermitteln, Steuern) würde es wohl mehr treffen.
Deine Effizienz besteht doch nur darin die Finger von allem zu lassen
was einen gewissen Komplexitätsgrad überschreitet.
Das nennst Du dann Übung, Vorbereitung, System, frei nach dem Motto:
Sei Schlau, bleib Dumm.
Damit bist die die Katzenberger der MCU Programmierung.
Bravo!
>Übung, Vorbereitung, System,
der Satz ist sowas von Inhaltslos..
kennt jemand irgenwas, wo man das nicht braucht?
sogar für den Gang aufs Klo braucht man Übung, Vorbereitung, und System
..
Markus M. schrieb:> Jaja, die noch mehr Stromschluckende Hardware GRINS
Serverhardware in irgend einem Rechenzentrum muß mich doch zu Hause
nicht interessieren! Davon abgesehen, von zukünftiger Datenauswertung
war die Rede.
> Moby A. schrieb:> Ich rede hier von 8-Bit MSR für datenarme und weniger> rechenintensive Anwendungen.>> Und wieso sollte man für solche Anwendungen überhaupt sich die Mühe> machen das in Assembler mit maximaler Effizienz zu gestalten?> KOPFSCHÜTTEL
Gleichfalls Kopfschüttel. Wozu sollte man sich dazu die C-Bürokratie
aufbürden? Daß Asm mehr Effizienz liefert ist da nur ein Zusatz-Bonus
;-)
> Ich habe immer noch nicht verstanden wieso ich Assembler lernen sollte,> wo ich doch schon C kann.
Nun, in diesem Fall bleib doch bei C. Ist ja auch nicht alles schlecht
dran ;-)
Robert L. schrieb:> Übung, Vorbereitung, System,>> der Satz ist sowas von Inhaltslos..
Was damit in Zusammenhang mit Asm gemeint ist hab ich hinreichend
erläutert. Das trieft nur so vor Inhalt ;-)
Witkatz :. schrieb:> Deine Aussage ist einzig und allein, dass man für eine simple> Steuerungsaufgabe keine Hochsprache lernen muss. Dein Code funktioniert> und du hast es bewiesen.
Prima. Und gaaanz so simpel braucht die MSR Aufgabe nicht zu sein ;-)
Michael K. schrieb:> Also besteht die Effizienz von ASM darin das die Erweiterbarkeit da> aufhört wo ich auf Grund einer veränderten Problemstellung einen> Messwert direkt im Knoten verarbeiten müsste.
Asm begrenzt Erweiterbarkeit in keinster Weise, kann sich auf eine
gegebene Hardware aber auch optimal einstellen.
> Die Effizient von ASM ist also dadurch gegeben das ich popelige> Messwerte an einen Server übermitteln muss damit der mir die> Berechnungen ausführt und zurückschickt.
Da hab ich von der Zukunft des IOT geredet.
Aktor/Sensor Hard/Software und einfache MSR Steuerungen nehmen sich
sonst nichts.
> Meine Güte ist das armseelig.
Wie Du meine Aussagen zur Kenntnis nimmst, ja.
> Deine Effizienz besteht doch nur darin die Finger von allem zu lassen> was einen gewissen Komplexitätsgrad überschreitet.
Richtig. Z.B. bürokratisches C und 32-Bit Controller- beides unnötig,
übertrieben und umständlich für typische 8-Bit MSR Anwendungen!
> Sei Schlau, bleib Dumm.
Falsch. Sei schlau, machs simpel :-)
Karl H. schrieb:> Das was du unter 'typisch' verstehst, ist es eben für die meisten> anderen nicht.
Nochmal: Typische 8-Bit MSR Anwendungen verarbeiten ein paar Dutzend
max. 16 bittiger Messwerte und benötigen mit Asm keine 32 Bit Power,
weil sie nicht rechen- und datenintensiv sind.
Fürs SmartHome als einem typischen Einsatzort hab ich hier noch keine
typischen Gegenbeispiele gehört ;-)
> völlig egal, ob das Programm im Flash 18 oder doch 21% belegt oder> nicht.
Ob das im konkreten Fall egal ist weiß ich nicht.
Je mehr Reserven für Erweiterungen desto besser.
Mit Effizienz und Ressourcensparung beginnt man besser immer bei Null
und nicht irgendwo im Projekt!
Moby A. schrieb:> P. M. schrieb:>> Dann zeig doch mal eine R-Anwendung in Assembler... :-D>> Da gibts nix zum Lachen, sonst würd ich jetzt im Kalten sitzen ;-)> An eine Regelung zur Raumtemperatur müssen keine hohen Anforderungen> gestellt werden- wenn man's denn richtig macht.
Haha...auch hier sieht man wieder dein begrenztes Weltbild: Hat der Moby
eine einfache 2-Punkt-Regelung für seine Heizung gebastelt und das
genügt bereits als Beweis, dass Assembler für R völlig ausreicht.
Moby A. schrieb:>> Deine Effizienz besteht doch nur darin die Finger von allem zu lassen>> was einen gewissen Komplexitätsgrad überschreitet.>> Richtig. Z.B. bürokratisches C und 32-Bit Controller- beides unnötig,> übertrieben und umständlich für typische 8-Bit MSR Anwendungen!
Zu umständlich für dich, weil du es nicht kannst. Alle anderen
profitieren von massiv effizienterer Entwicklung. Der ganze Thread dient
dir doch eigentlich nur dazu, deinen begrenzten Fähigkeiten- und
Wissensstand schönzureden.
Moby A. schrieb:> Cool, wie Du für die Fachwelt sprichst.> Cool, wie Du mir die Fachwelt um die Ohren haust.> Leider seh ich für den umrissenen Einsatzbereich rein gar nichts> widerlegt!
Fakt ist, dass ich mit Software (in C/C++) Geld verdiene und du nicht.
Dass ich eine komplette Ausbildung darin habe und du nicht. Dass dies
auch für die anderen Leute gilt, die dir widersprechen. Ich mag dieses
Argument normalerweise nicht so, aber hier muss man einfach mal
feststellen: Der hat keine Ahnung, der versteht noch nicht mal die
Grundlagen des besprochenen Themas.
Moby A. schrieb:> Du optimierst? In Asm? Na bravo- genau das mach ich ja auch!
Ach so?
> Bei größeren Programmen verschenkt man weniger Potential als Du hier> vorgibst- wenn man nämlich vorhandenes, effizientes Codematerial nur> miteinander verknüpft. Meine Verschwendung bei größeren Programmen für> mehr Übersicht besteht im wesentlichen nur darin, daß ich die> enthaltenen sequentiell abzuarbeitenden Bausteine in Form einer> Call-Liste aufrufe, die sich auch leicht abändern lässt.
Das ist doch keine Optimierung! Das ist Speicher- und
Rechenzeitverschwendung!
Ich versuch mal ein Beispiel:
Man möchte einen Mittelwert bilden, z.B. aus verschiedenen Messungen vom
ADC. Nehmen wir mal für den Anfang zwei Messungen. Da steht dann
ziemlich am Anfang in einer C-Datei:
1
#define ANZAHL 2
Dann kommt eine Funktion die irgendwas Interessantes macht und am Ende
steht dort:
1
returnwert/ANZAHL;
Zur Erklärung des kryptischen C-Codes:
'define' gibt's in Assembler auch. Hat die gleiche Bedeutung. Dort heißt
es allerdings (kürzer und hochoptimiert) nur 'def'.
Die andere Zeile ins Deutsche übersetzt: Kehre mit dem Ergebnis der
Berechnung 'wert' geteilt durch 'ANZAHL' zurück. Für 'return' gilt das
gleiche wie oben. Heißt in Assembler stromsparend 'ret'. Nur: Wo ist
jetzt das Ergebnis? Natüüürlich: Dazu gibt es einen Hinweis als
Kommentar am Anfang der Funktion, wo alle verwendeten Register
dokumentiert sind und welche für Datenüber- und -rückgabe verwendet
werden. (Eventuell auch noch der Hinweis auf die Verwendung des Stacks.)
Was für ein Schreibaufwand ;-)
Die Assembler-Zeile vor dem 'ret' ist ganz einfach. Einmal nach rechts
schieben - fertig! (Ich verrate dir mal was: Das kennt der Compiler. Das
macht der genauso!)
Nun stellt sich im Laborversuch heraus: Nur zwei Werte sind zur
Mittelwertberechnung zu wenig, man müsste es mal mit vier probieren
(Okay, kein Problem, eine Zeile dazu). Mist. Besser wären drei! Noch
geiler wäre es vielleicht, nur Differenzen zu messen. Oops, da werden
die Zahlen ja negativ ... Zumindest wird das niemals eine Funktion für
die Codesammlung! [ Geht jetzt weit am Thema vorbei: Das wäre ein Fall
für C++ :-) ]
Gleichzeitig kann die Definition 'ANZAHL' hervorragend beim Einlesen der
Messwerte verwendet werden :) Wie von Zauberhand erstellt der Compiler
daraus den optimalen Assembler-Code.
> In einem> finalen Schritt könnte man die Funktionalität zusammenfassen, darunter> leidet aber die Übersicht mehr als daß es der gesparte Flashspeicher> wert ist.
Siehst Du, dass ist Optimierung! So macht das der Compiler!
-----
Ich weiß, ist gegen eine Wand geredet. Ich hab' das aber mal gebraucht
;-)
Moby A. schrieb:> Cool, wie Du für die Fachwelt sprichst.
Das steht ihm als Fachmann auch zu.
> Cool, wie Du mir die Fachwelt um die Ohren haust.
Das steht ihm als Fachmann auch zu.
Moby A. schrieb:> Nochmal: Typische 8-Bit MSR Anwendungen verarbeiten ein paar Dutzend> max. 16 bittiger Messwerte
In deinem Piffelprojekt werden doch gar keine Daten verarbeitet, sondern
nur aufgenommen und weitergereicht. Von Dutzenden ganz zu schweigen.
Messen beinhaltet nicht nur das Auslesen eines Wertes, sondern auch eine
Verarbeitung. Die findet dort aber nicht statt.
Eine Steuerung findet an der Stelle auch nicht statt.
Das Thema Regelung hatten wir ja schon.
Dein Projektchen ist also überhaupt keine "MSR"-Anwendung, sondern eine
" "-Anwendung. Im Grunde nichts anderes als ein popeliger Datenlogger.
Du trägst nur dick auf und wirfst mit Begriffen um dich, von denen du
nicht das geringste verstehst. Wie ein Esoteriker. Es werden einfach
Dinge behauptet und wenn es um den Nachweis geht, wird gekniffen.
mfg.
P. M. schrieb:> Ich mag dieses> Argument normalerweise nicht so, aber hier muss man einfach mal> feststellen: Der hat keine Ahnung, der versteht noch nicht mal die> Grundlagen des besprochenen Themas.
Da muss ich P.M. zustimmen.
Das Problem ist doch, wer wenig weiß der weiß in der Regel nicht DASS er
wenig weiß.
Erst mit größerem Wissen über ein Fachgebiet kann man oft erst
beurteilen wie es sich mit dem eigenen Wissensstand verhält, wo man
Defizite hat.
Außerdem erkennt man Probleme wo der Ungebildete sich denkt "Ist doch
alles kein Problem!".
Sehr schön ist das in diesem Thread zu beobachten:
Beitrag "LED-Matrix | Einfachste methode für animationen?"
Der TO hat dort augenscheinlich so wenig Ahnung von der Materie dass er
garnicht weiß was er sich da vorgenommen hat.
Deswegen immer wieder der Wunsch nach einer "einfachen Lösung ohne
Programmieren".
In der PRaxis führt dass dann dazu (im Beruf oft erlebt) dass die
Wenig-Wisser kräftig auf den Putz hauen und die Fachmänner eher ruhig im
Hintergrund über die Machbarkeit nachdenken.
Ich habe gelernt: wenn mir jemand kommt mit "Ist doch ganz einfach..."
oder "da muss man doch nur..." ist Vorsicht geboten!
Auf diesen Thread bezogen: du Moby, lebst in so einer kleinen Welt dass
du nicht ansatzweise erkennen kannst wie wenig du eigentlich weißt.
Vielleicht nicht ganz unpassend:
https://de.wikipedia.org/wiki/H%C3%B6hlengleichnis
P. M. schrieb:
> Ich mag dieses> Argument normalerweise nicht so, aber hier muss man einfach mal> feststellen: Der hat keine Ahnung, der versteht noch nicht mal die> Grundlagen des besprochenen Themas.
Hehe.. Ja der Ton wird etwas rauher.
Aber es war zu erwarten. Es stimmt auch. Moby "Projekt" liest ein ADC
und sendet in irgendwohin. Das kann man als "Messen" durchgehen lassen.
Von MSR ist das weit entfernt. Ebenso ein 2/3-Punktregler. Ein richtiger
Regler ist was völlig anderes. Und eine Datenverarbeitung findet auch
nicht statt...
Aber natürlich irrt nicht der eine Geisterfahrer, sondern die
Entgegenkommenden...
Matthias L. schrieb:> Von MSR ist das weit entfernt.
Nicht nur das: Es ist auch nur in dieser speziellen Konstellation
nutzbar und daher für alle anderen User außer Moby selbst wertlos.
Karl H. schrieb:> Moby A. schrieb:>> Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen> Win-PC, die nur noch GHz Prozessoren stemmen.>> Das was ein heutiger PC im Hintergrund noch alles mit erledigt, kannst> du dir doch gar nicht vorstellen.
Du auch nicht. Und mit der Gültigkeit meiner Aussage hat das auch wenig
zu tun.
Moby A. schrieb:> Und mit der Gültigkeit meiner Aussage hat das auch wenig zu tun.
Gültigkeit welcher Aussage? Wie gesagt: Du extrapolierst von 200 Byte
auf 10KB. Das ist kompletter Unsinn.
Nein: Dein Dreirad fährt NICHT 200 km/h - auch wenn Moby draufsitzt
und Prrrmmmm Prrrrmmm macht.
Frank M. schrieb:> Dein Dreirad fährt NICHT 200 km/h
Insbesondere wird es eben auch nicht in die Lage versetzt, 200 km/h
zu fahren, indem man einfach das Treten beherrscht und dann „nur noch“
ausreichend schnell treten muss.
le x. schrieb:> Ich habe gelernt: wenn mir jemand kommt mit "Ist doch ganz einfach..."> oder "da muss man doch nur..." ist Vorsicht geboten!
Woher kennst du meinen Ex-Chef?
Matthias L. schrieb:> Hehe.. Ja der Ton wird etwas rauher.
Man muss einfach mal. Ich mag es eigentlich nicht, in einer Diskussion
laut oder unfreundlich zu werden. Aber es muss einfach mal gezeigt
werden, dass wir hier nicht mehr ein Fachgespräch führen, sondern uns
mit einem quengelnden Kind herumschlagen. Und da werden die Eltern ja
auch mal etwas lauter :-)
Und Moby, ich bin jederzeit dir zu verraten, auf welche Erfahrungen sich
meine Aussagen stützen und ich bin auch jederzeit bereit, dir ein paar
Tipps betreffend der Effizienz von C zu geben. Schreib einfach ne PN.
Karl H. schrieb:
"Du extrapolierst aus einer simplen Aufgabe, die du mit ein paar
Anweisungen erledigen kannst auf das Verhalten von größeren Programmen.
Und genau das ist nicht zulässig. Denn die zu bearbeitende Komplexität
steigt nicht linear sondern mindestens exponentiell"
Nein. Das lässt sich pauschal unabhängig jedweder konkreter Anwendung so
nicht sagen.
"Genau deshalb sind grosse Systeme auch so schwer zu schreiben, weil es
mit jedem zusätzlichen Subsystem immer schwieriger wird, die
Querverbinden und Verflechtungen im Auge zu behalten."
Das ist solange richtig wie zusätzliche Subsysteme mehr
Querverbindungen, Verflechtungen, Nebenwirkungen mitbringen. Allerdings
gibt es wirksame Gegenmittel: Kapselung, funktionelle Gliederung,
einheitliche Interfaces. Kurzum: System beim System-Aufbau. Die
Notwendigkeit strukturierter Hochsprachen lässt sich so weit
hinauszögern, weit noch aus dem 8-Bit MSR Bereich hinaus.
Moby A. schrieb:> hinauszögern
Hinauszögern trifft es gut. Ja, man kommt lange darum herum, aber es
wird extrem mühsam und ineffizient.
Moby A. schrieb:> Nein. Das lässt sich pauschal unabhängig jedweder konkreter Anwendung so> nicht sagen.
Sagt wer? Sagt jemand, der gerade mal ein paar kleine 8-Bit-Projektchen
durchgezogen und noch nie einen Code mit mehr als ein paar hundert
Zeilen gesehen hat.
Moby A. schrieb:> Das ist solange richtig wie zusätzliche Subsysteme mehr> Querverbindungen, Verflechtungen, Nebenwirkungen mitbringen. Allerdings> gibt es wirksame Gegenmittel: Kapselung, funktionelle Gliederung,> einheitliche Interfaces. Kurzum: System beim System-Aufbau.
Du solltest dich in Berlin bei BER bewerben. Jemanden wie dich können
sie dort brauchen. Also jemanden mit System.
Frank M. schrieb:> Nein: Dein Dreirad fährt NICHT 200 km/h - auch wenn Moby draufsitzt und> Prrrmmmm Prrrrmmm macht.
Das muß es auch nicht, das ist ja der Witz ;-)
P. M. schrieb:> Aber es muss einfach mal gezeigt> werden, dass wir hier nicht mehr ein Fachgespräch führen, sondern uns> mit einem quengelnden Kind herumschlagen. Und da werden die Eltern ja> auch mal etwas lauter :-)
Solange Diskussionen so herablassend in Überlegenheitsmanier geführt
werden hab ich es besonders leicht ;-)
Anders wäre der Fall wenn die angeblichen "Eltern" ihre Elternschaft mal
mit besserer C-Codierung meines Projekts unter Beweis stellen würden!
> Und Moby, ich bin jederzeit dir zu verraten, auf welche Erfahrungen sich> meine Aussagen stützen und ich bin auch jederzeit bereit, dir ein paar> Tipps betreffend der Effizienz von C zu geben.
Gib Dir selber mal ein paar Tipps, wie sich mein Projekt in C doch noch
sparender umsetzen lässt ;-)
Moby A. schrieb:> Solange Diskussionen so herablassend in Überlegenheitsmanier geführt> werden hab ich es besonders leicht ;-)
Naja, wenn ein Hobbyist, der kein C kann, gegenüber 5-10 professionellen
Entwicklern so überzeugt die Überlegenheit von Assembler gegenüber
Hochsprachen predigt und gegen jegliche Argumente resistent ist, dann
muss man einfach mal die Autoritätskeule auspacken.
Und wie jetzt, du hast es leicht? Konntest du bisher irgend jemand von
deinem Standpunkt überzeugen?
Moby A. schrieb:> Bürokratie= Gesamtheit des Sprachumfangs, Regeln, Vorschriften, Typen,> Operatoren, Deklarationen usw.
Im Prinzip also alles was Moby nicht versteht. Komisch nur dass es genau
(alle - 1) sonst verstehen.
P. M. schrieb:> Naja, wenn ein Hobbyist, der kein C kann, gegenüber 5-10 professionellen> Entwicklern so überzeugt die Überlegenheit von Assembler gegenüber> Hochsprachen predigt und gegen jegliche Argumente resistent ist, dann> muss man einfach mal die Autoritätskeule auspacken.
Pack aus was Du willst... Wenn Du meinst, es könnte als "Argument"
gebraucht werden.
Eine Predigt ist für mich übrigens etwas, was nicht mit Code belegt ist
;-)
Moby A. schrieb:> Eine Predigt ist für mich übrigens etwas, was nicht mit Code belegt ist> ;-)
Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler
sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber
C, aber du kannst es nicht durch Code belegen.
Um mal wieder bisl produktiv zu werden:
Im Sensorboard-Thread wurde ja mal versucht, die Anforderungen an die
Software zusammenzufassen.
Du hast dich damals sehr unkooperativ gezeigt, trotzdem bitte ich dich
nochmal, die dortige Lsite kurz durchzusehen und falsche Anforderungen
aufzuzeigen oder sogar zu korrigieren.
Hier der anscheinend letzte Stand dieser Anforderungsliste:
1
- Der Prozessor soll den internen 128kHz Takt verwenden
2
- es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4)
3
und AINP-CHANNEL2 (entspricht PB3) eingelesen werden (1)
4
- die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen werden
5
- das Einlesen soll im free-running Modus des ADC stattfinden, jeder
6
Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2)
7
- es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1)
8
und DINP2-LOW (entspricht PB5) eingelesen werden
9
- das Einlesen soll unmittelbar vor der Datenübertragung erfolgen
10
- es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte, versandt werden
11
- das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden
12
- ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK
13
(entspricht PB2) ausgegeben werden
14
- das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden
15
durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden)
- die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in
24
einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird
25
- das Telegram soll alle 320 ms wiederholt werden; der genaue Wert
26
ist unkritisch
27
- Das Telegram soll eine Bit-Zykluszeit von ca. 10 ms haben, also 80 ms
28
pro Byte
29
- sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen
30
- das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben
31
- es ist nur 1 Timerinterrupt zu verweden, andere Interrupts sind für
32
Erweiterungszecke reserviert
Ich hab hierzu 2 Fragen, die ich oben gekennzeichnet habe:
1) Soll 8 mal AINP-CHANNEL1 und dann 8 mal AINP-CHANNEL2 eingelesen
werden oder soll dies im Wechsel geschehen?
2) Soll zwischen den 8 Messpunkten gewartet werden (z.B. im nächsten
Timer-Interrupt) oder soll eine Messung gestartet werden, sobald der ADC
wieder frei ist?
Kannst du dazu bitte was sagen?
P. M. schrieb:> Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler> sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber> C, aber du kannst es nicht durch Code belegen.
Das behaupte ich, ja. Ausgehend von meinem existenten Code.
Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen. Soweit
waren wir schon ;-)
le x. schrieb:> Um mal wieder bisl produktiv zu werden:
Prima.
> Kannst du dazu bitte was sagen?
Gerne. Heute abend. Auch wenn es sinnlos ist. Obwohl längst alles dazu
gesagt wurde ;-(
Moby A. schrieb:> P. M. schrieb:>> Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler>> sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber>> C, aber du kannst es nicht durch Code belegen.>> Das behaupte ich, ja. Ausgehend von meinem existenten Code.
Wie gross ist er denn, der Code?
> Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen. Soweit> waren wir schon ;-)
Eine ganze Industrie, die für schwachbrüstige Mikrocontroller wie auch
für High-Performance-Anwendungen weitestgehend C und nicht Assembler
verwendet, ist wohl Beweis genug, dass C gegenüber Assembler keine
nennenswerten Effizienznachteile hat.
Moby A. schrieb:> Werner P. schrieb:>> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen>> von Moby eh schon verloren.>> SO IST ES !
Was für eine schwachsinnige Aussage.
Robert L. schrieb:> der Satz ist sowas von Inhaltslos..> kennt jemand irgenwas, wo man das nicht braucht?>> sogar für den Gang aufs Klo braucht man Übung, Vorbereitung, und System> ..
Das beschreibt Mobys Horizont schon sehr gut ;-)
Werner P. schrieb:> sobald Du auch nur ein Byte SRAM "verschwendest"
Wobei natürlich das Abarbeiten von Interrupts (die Stack belegen)
keine Verschwendung ist, auch wenn man die Aufgabe selbstverständlich
ganz ohne solche genauso lösen könnte. Merke: Moby legt fest, welcher
Verbrauch „Verschwendung“ ist und welcher nicht. Flash, der für das
Initialisieren nicht benutzten RAMs verplempert wird, ist beispielsweise
keine, aber SRAM statt Registern zu belegen, ist per definitionem
eine solche (obwohl doppelt so viel SRAM da ist wie Register, letztere
als teurer sind).
Vielleicht sollte er ja mal bei Atmel nachfragen, ob er den nicht
benutzten RAM auch zurückgeben darf gegen ein wenig Rabatt. :)
Moby A. schrieb:> Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen.
Nur deshalb, weil du dich ja nicht auf einen solchen Vergleich einlässt.
Vorgeschlagen hatte Karl Heinz dir einen, und nein, der war ohne
irgendeinen „Heimvorteil“, sprich eine bereits existierende
Implementierung in C.
Oder meinst du etwa, wir müssten dann auch noch das zugehörige
Assemblerprogramm schreiben? Wie stellst du dir dieses „belegen“
denn sonst vor?
(OK, jetzt geh' ich mal wieder Ressourcen verplempern, dafür werde ich
ja schließlich bezahlt.)
Moby A. schrieb:> Werner P. schrieb:>> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen>> von Moby eh schon verloren.>> SO IST ES !
Definiere genauer RAM-Verbrauch.
Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen.
Gruß, Stefan
Matthias L. schrieb:> Was für eine schwachsinnige Aussage.
... besonders für den, der diese Aufgabe nicht lösen kann ;-)
Es geht hier ja nicht darum, Ressourcen da wo nötig nicht in Anspruch zu
nehmen. Aber es geht darum, ob C im Bedarf an Asm herabkommt. Wird der
Code des durchschnittlichen Asm-Programmierers Moby gar unterboten, wird
sich hier kein Moby der Welt mehr hinstellen und C prinzipiell
mangelnde Effizienz vorwerfen!
Moby A. schrieb:> Es geht hier ja nicht darum, Ressourcen da wo nötig nicht in Anspruch zu> nehmen.
also darf jetzt SRAM verwendet werden oder nicht?
Bitte ein Ja oder ein Nein.
Stefan K. schrieb:> Definiere genauer RAM-Verbrauch.> Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen.
Weiter oben stand schon mal das Ergebnis der Assemblierung. Das ist auch
in meinem Code zu besichtigen.
So, weiter gehts am Abend!
Jörg W. schrieb:>> sobald Du auch nur ein Byte SRAM "verschwendest">> Wobei natürlich das Abarbeiten von Interrupts (die Stack belegen)
Wie der oben aufgeführte AT90S1200 zeigt, kann man auch ohne RAM mit
Interrupts arbeiten.
A. K. schrieb:> Wie der oben aufgeführte AT90S1200 zeigt, kann man auch ohne RAM mit> Interrupts arbeiten.
Aber nur, wenn man einen separaten Stack hat. Sein ATtiny13 braucht
dagegen schon RAM dafür. ;-)
(War's nicht der i8008, der auch nur einen Hardwarestack hatte? Der
ist evolutionsmäßig an mir vorbeigegangen.)
A. K. schrieb:> Wie der oben aufgeführte AT89S1200 zeigt, kann man auch ohne RAM mit> Interrupts arbeiten.
und? dann kommt Moby und sagt: Es muss ein Attiny13 sein.
Moby A. schrieb:>> Definiere genauer RAM-Verbrauch.>> Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen.>> Weiter oben stand schon mal das Ergebnis der Assemblierung. Das ist auch> in meinem Code zu besichtigen.
Den Begriff Definition kannst Du im Duden nachschlagen.
Stefan K. schrieb:>> Definiere genauer RAM-Verbrauch.> Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen.>> Gruß, Stefan
Doch, natürlich geht das und dazu braucht an keinen μC mit
Hardwarestack. Man muß lediglich auf Interrupts verzichten, was bei den
oben zu findenden Specs kein Problem ist. Einen Timer kann man auch
pollen, ADC genauso -> Stack ist unnötig, Register sichern ist unnötig,
RAM initialisieren ist unnötig, ...
Nur können muß man halt und damit meine ich nicht die
Maschinenbefehlsketten, sonder das darüber liegende Schema.
"Problemorientiert" nennt sich diese Ebene auch und damit sind nicht
8-Bit-Register-Beschränktheits-Probleme gemeint.
PS: mal sehen in welchen Schipsel der Text von M. wieder "freundlich"
herabgelassen wird.
Carl D. schrieb:> Doch, natürlich geht das und dazu braucht an keinen μC mit> Hardwarestack. Man muß lediglich auf Interrupts verzichten
Klar geht das, verletzt aber die Spezifikation:
le x. schrieb:> - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen
Das erinnert mich an mein Betriebspraktikum (schon eine Weile her), wo
die Forderung die genau umgekehrte war: keinen Timer-ISR und auch keinen
Timerwert verwenden. Der Entwicklungsleiter hatte wohl mal schlechte
Erfahrungen mit Interrupts gemacht und meinte, der Timer wird durch
Störungen fehlgetriggert. Die Folge war, daß alle if-else-Zweige einer
sehr komplexen Regelung mit nop-Schleifen auf gleiche Länge getrimmt
wurden.
Diese Steuerungen wurden dann später übrigens in Planierraupen eingebaut
...
Gruß, Stefan
Stefan K. schrieb:> Diese Steuerungen wurden dann später übrigens in Planierraupen eingebaut> ...
Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten
gegeben. ;-)
Moby A. schrieb:> Werner P. schrieb:>> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen>> von Moby eh schon verloren.>> SO IST ES !
Dann skalieren wir das mal hoch, wie Moby es gern macht:
Ein 200Byte-Programm darf KEIN RAM verbrauchen.
Daraus folgt zwingend nach Mobys Skalierungsregeln:
Ein 10KB-Programm darf KEIN RAM verbrauchen.
Dein angeblich existententes Haus-und-Hof-10-KB-Programm, braucht das
eigentlich RAM?
Ich bin mir sicher, dass es RAM braucht. Du bist also ein Lügner.
Achja: Damit ein Interrupt einen RETI machen kann, muss es die
Rücksprungadresse vom Stack aus dem RAM holen.
Also:
Dein 200Byte-Programm verbraucht RAM!
Und schon wieder eine Lüge.
Carl D. schrieb:> Man muß lediglich auf Interrupts verzichten[...]> [...]Nur können muß man halt und damit meine ich nicht die> Maschinenbefehlsketten, sonder das darüber liegende Schema.
Das hatten wir ja schon. Für das, was er nicht kann, hat er dann wieder
irgendeine Ausrede.
mfg.
Jörg W. schrieb:> Thomas E. schrieb:>> Für das, was er nicht kann, hat er dann wieder irgendeine Ausrede.>> Oder es wird zugekauft. :)
für Moby kein Problem. Bei so viel "Übung, Vorbereitung, und System"
Thomas E. schrieb:> Das hatten wir ja schon. Für das, was er nicht kann, hat er dann wieder> irgendeine Ausrede.
So ist es. Die Forderung "Kein RAM!" kam ja auch erst später hinzu, als
Yalu ihm schon vorgeführt hatte, dass es effizienter und kleiner in C
geht.
Da hat er einfach mal so die Spielregeln geändert. Und genau deshalb
will das hier auch keiner nachprogrammieren. Er wird sofort die wieder
die Spielregeln ändern, zum Beispiel so:
"Das C-Programm muss in ASM geschrieben sein!"
Er ist einfach ein schlechter Verlierer - nichts weiter.
Jörg W. schrieb:> Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten> gegeben. ;-)
Ja, das hatte mich damals sehr "beeindruckt" ...
Was ich damals gelernt habe: die alten Hasen haben zwar viel Wissen, oft
aber auch viele (Vor-)Urteile, die vor ein paar Jahren sicher sinnvoll
waren, mittlerweile aber so nicht mehr stimmen.
Gruß, Stefan
Frank M. schrieb:> So ist es. Die Forderung "Kein RAM!" kam ja auch erst später hinzu, als> Yalu ihm schon vorgeführt hatte, dass es effizienter und kleiner in C> geht.
Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da,
um gebraucht zu werden, das hat nichts aber auch gar nichts mit
Ineffizienz zu tun.
P. M. schrieb:> Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da,> um gebraucht zu werden, das hat nichts aber auch gar nichts mit> Ineffizienz zu tun.
Erstens das und zweitens ist es ja nur Zufall, dass er kein RAM
braucht. Das Micky-Maus-Programm ist halt so lächerlich klein, dass
alles in Register passt. Bei einem etwas größeren Programm klappt das
schon nicht mehr.
An 0 Byte RAM festzumachen, dass ASM C überlegen ist, ist einfach nur
lächerlich.
Aber hier wiederholen sich nur noch die Argumente und man kann nur noch
den Kopf schütteln. Ich klinke mich daher nun aus diesem Thread aus und
kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys
Provokationen zu reagieren.
Soll der Troll sich doch mit sich selbst hier unterhalten. Selbst ein
Kleinkind ist vernünftiger als dieses Balg.
Frank M. schrieb:> Soll der Troll sich doch mit sich selbst hier unterhalten. Selbst ein> Kleinkind ist vernünftiger als dieses Balg.
Das ist schon länger klar, ja. Mich interessiert eigentlich einzig und
alleine noch, wer hinter dieser Person steckt. Meint er das wirklich
ernst oder ist er doch irgendwie ein Troll?
P. M. schrieb:> Meint er das wirklich ernst oder ist er doch irgendwie ein Troll?
Das ist mir scheissegal. Es ist auch schnurz, denn überzeugen kann ihn
sowieso niemand. Da ist mir eine Betonwand, der ich gut zurede, lieber.
Und daher jetzt für mich EOD.
Frank M. schrieb:> Ich klinke mich daher nun aus diesem Thread aus und> kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys> Provokationen zu reagieren.
Das widerum seh ich anders.
Ich habe hier viele vergnügliche Stunden verbracht und hoffe das geht
noch eine Weile so, wenigstens bis zu meinem Urlaub ;-)
Ich schäme mich zwar ein wenig für meine niederen Instinkte, aber das
hier trifft es doch recht anschaulich:
P. M. schrieb:> (Zugegeben, so ein bisschen Spass macht es schon - wie früher wenn man> den Klassendepp mit seinen absurden Ansichten noch ein bisschen> aufgezogen hat.)
Aber mal abwarten ob ich heute Abend irgendwelche Bestätigungen in
Punkto Anforderungsliste kriege.
Ich glaub zwar nicht so recht dran, denn daran ist ja schon der
Sensorboard-Thread gescheitert. Aber wenn was kommt probier ich
vielleicht ein bischen rum, was mit Compiler/Linkerflags so alles drin
ist.
Und wenn es nur dazu dient die nächste Ausrede zu hören ;-)
Stefan K. schrieb:> Jörg W. schrieb:>> Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten>> gegeben. ;-)>> Ja, das hatte mich damals sehr "beeindruckt" ...>> Was ich damals gelernt habe: die alten Hasen haben zwar viel Wissen, oft> aber auch viele (Vor-)Urteile, die vor ein paar Jahren sicher sinnvoll> waren, mittlerweile aber so nicht mehr stimmen.
Ein alter Hund lernt keine neuen Tricks mehr.
:-)
Stimmt schon was du da sagst. Da muss ich mich auch an der Nase nehmen.
Viele Dinge mach ich heute so, weil ich sie 'schon immer' so gemacht
habe, weil ich die Technik dazu gut kenne und oft erfolgreich angewendet
habe. Was man eben im Schlaf beherrscht, kommt immer wieder gerne zum
Einsatz. Oft entscheidet auch das Bauchgefühl anhand von Analogien.
le x. schrieb:> Ich habe hier viele vergnügliche Stunden verbracht
Ein schönes vorweihnachtliches Thema. Erinnert an den Buch-Thread. Einer
weiss und kann alles und alle anderen sind zu doof.
mfg.
Frank M. schrieb:> P. M. schrieb:>> Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da,>> um gebraucht zu werden, das hat nichts aber auch gar nichts mit>> Ineffizienz zu tun.>> Erstens das und zweitens ist es ja nur Zufall, dass er kein RAM> braucht. Das Micky-Maus-Programm ist halt so lächerlich klein, dass> alles in Register passt. Bei einem etwas größeren Programm klappt das> schon nicht mehr.
Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern,
so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die
Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist
auch nicht mehr gross rum rechnen. Was machst du mit dem übrig
gebliebenem RAM? Öhmmmmm.
> An 0 Byte RAM festzumachen, dass ASM C überlegen ist, ist einfach nur> lächerlich.
Wenn man den Compiler anweist, die Variablen in Register zu legen, würde
man wahrscheinlich auch das noch wegkriegen. Aber ich hab jetzt ehrlich
gesagt Yalus Programm noch gar nicht gesehen, was er da eigentlich alles
gemacht hat.
Karl H. schrieb:> Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern,> so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die> Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist> auch nicht mehr gross rum rechnen. Was machst du mit dem übrig> gebliebenem RAM? Öhmmmmm.
jo, es wird auch langweilig hier. Moby bringt nichts Neues. Wiederholt
sich nur und beharrt auf seiner Meinung. Den SRAM hat er eh voll
verschwendet. Er schreibt ihn ja am Anfang seines Programms mit Nullen
voll. Warum auch immer.
Jeder findet seinen Meister. Ich bin mir sicher dass es genügend
C-Profis gibt die das ASM-Programm von Moby toppen. Auch wenn er das
nicht glauben mag. Was solls. Wenns ihn freut ;-)
Hier bricht ja jetzt die nackte Panik aus ;-)
Frank M. schrieb:> Ich bin mir sicher, dass es RAM braucht. Du bist also ein Lügner.> Achja: Damit ein Interrupt einen RETI machen kann, muss es die> Rücksprungadresse vom Stack aus dem RAM holen.> Dein 200Byte-Programm verbraucht RAM!>> Und schon wieder eine Lüge.
Oh, da schlägt ja einer wild um sich ;-)
Daß mein Projekt RAM in Gestalt des Stackbedarfs eines Interrupt-Calls
benötigt erschließt sich natürlich aus dem Programmcode. Aber nur für
Kenner ;-)
Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem
C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den
Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur
Verfügung = 1 Unterprogramm-Ebene.
Frank M. schrieb:> Ich klinke mich daher nun aus diesem Thread aus und> kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys> Provokationen zu reagieren.
Gut so Frank. Du machst das einzig Richtige. Deine Provokationen
sind ja auch weitgehend verpufft ;-)
Ne der missioniert gerade:
Beitrag "Re: Heim Automatisierungswahn"
Wobei er ein BLE-Module entdeckt hat, auf dem ein M0 mit 128k Flash und
16k RAM werkelt, auf dem ein sicher nicht in ASM geschriebener
BASIC-Interperter läuft. Wichtig ist eben eins: keine irgendwie
erkennbare C-Bürokratie. Aber noch besser sind kleine AVR Boards, die
per proprietären Drahtprotokoll plaudern. Sagt er.
Werner P. schrieb:> Ich bin mir sicher dass es genügend> C-Profis gibt die das ASM-Programm von Moby toppen. Auch wenn er das> nicht glauben mag.
Ob Du's glaubst oder nicht- mich würde das freuen.
Aber Du hast Recht, dran glauben mag ich nicht.
Jörg W. schrieb:> Merke: Moby legt fest, welcher> Verbrauch „Verschwendung“ ist und welcher nicht.
Nein. Moby legt nur fest, daß zu einem sinnvollen Ressourcen-Vergleich
natürlich das SRAM gehört. ;-)
le x. schrieb:> Ich schäme mich zwar ein wenig für meine niederen Instinkte
Das ehrt Dich. Wenigstens einer der's mal ehrlich zugibt ;-)
le x. schrieb:> Aber mal abwarten ob ich heute Abend irgendwelche Bestätigungen in> Punkto Anforderungsliste kriege.
Selbstverständlich. Setz mich gleich nochmal dran.
> Ich glaub zwar nicht so recht dran, denn daran ist ja schon der> Sensorboard-Thread gescheitert. Aber wenn was kommt probier ich> vielleicht ein bischen rum, was mit Compiler/Linkerflags so alles drin> ist.
Ja, das fürchte ich auch: Mehr als ein bischen Rumprobieren kommt nicht
bei raus. Ich denke, das haben in der Zwischenzeit schon ganz andere
gemacht ;-)
> Und wenn es nur dazu dient die nächste Ausrede zu hören ;-)
Wenn Du es nicht schaffst ist meiner Meinung nach Streit
vorprogrammiert. Ich bin schon gespannt worüber. Denn eines wird auf
Biegen und Brechen erstmal nicht passieren: Daß die C-Seite die
unbestreitbaren Vorteile von Asm eingesteht ;-)
Moby A. schrieb:> Daß mein Projekt RAM in Gestalt des Stackbedarfs eines Interrupt-Calls> benötigt erschließt sich natürlich aus dem Programmcode. Aber nur für> Kenner ;-)>> Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem> C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den> Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur> Verfügung = 1 Unterprogramm-Ebene.
D.h. es kann möglich sein, ein dem Assemblerprogramm gleichwertiges
Programm in C zu schreiben, wenn der Compiler den identischen Assembler
output erzeugt, bzw. exact die gleichen Bytes ins Flash gebrannt werden.
Alles andere ist eine Verletzung der Spezifikation.
Damit geht ein besseres Programm per Definition nicht.
Der Thread ist somit beendet.
Bitte schliessen.
Moby A. schrieb:> Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem> C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den> Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur> Verfügung = 1 Unterprogramm-Ebene.
Was ist das für ein unsinniger Mikrocontroller? Selbst lausigste
kleinste PIC hat 2 Stack-Ebenen.
Und warum etwas "sparen", was man schon gekauft und bezahlt hat? Man
kann sich auch selber geißeln. Es ist so schön, wenn der Schmerz wieder
nachlässt...
Bernhard M. schrieb:> Der Thread ist somit beendet.> Bitte schliessen.
Neineinein! Dann verliere ich die 2000er-Wette. Auch wenns nur ums
"Recht haben" geht... ;-)
Moby A. schrieb:> Daß die C-Seite die unbestreitbaren Vorteile von Asm eingesteht
Dazu musst du aber ein Programm zeigen, dass die Vorteile auch nutzt.
So, wie ich das in meinem genialen Programm gemacht habe.
Es macht exakt das, was es soll. Nicht mehr und nicht weniger.
Und das mit absoluter Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran.
mfg.
Bernhard M. schrieb:> Alles andere ist eine Verletzung der Spezifikation.
So ist es. Ist es schlechter, hat Moby gewonnen, ist es besser, dann
fehlt ihm irgendein Feature, welches nachträglich als wesentlich
erklärt wird. Da die „Spezifikation“ ja nur im „selbsterklärenden
Assemblerprogramm“ besteht, ist das doch auch völlig logisch, oder?
> Der Thread ist somit beendet.
Nein, schließlich ist Assembler ja „auf dem Weg nach vorn“. :-)
Ich habe gestern ein Buch über Assembler-Programmierung geschenkt
bekommen. In seinem Vorwort enthält es den Absatz:
1
When writing a book on the assembly language of a processor, we know in
2
advance that it will not register in posterity. By its very nature, an assembly
3
language has the same life expectancy as the processor it supports perhaps 20
4
years at best. What's more, this type of programming is obviously not used for the
5
development of software projects and so is of little consequence. (*)
Man würde sich wünschen, Moby würde den gleichen Realismus an den
Tag legen wie der Autor dieses Buches. ;-)
(*) Für die, die des Englischen nicht ganz so mächtig sind:
Wenn man ein Buch über Assembler-Programmierung eines bestimmten
Prozessors schreibt, ist von vornherein klar, dass es nicht für die
Ewigkeit bestimmt ist. Prinzipbedingt hat die Assemblersprache die
gleiche Lebenserwartung wie der durch sie unterstützte Prozessor,
vielleicht maximal 20 Jahre. Jedoch wird diese Art von Programmierung
nicht für die Entwicklung von Softwareprojekten genutzt, sodass das
keine großartigen Konsequenzen nach sich zieht.
Carl D. schrieb:> Ne der missioniert gerade:
Irrtum Carl D. Ich bin mit ganzem Einsatz wieder hier bei meinem
Lieblingsthema. Lass mal das BLE-Modul. Das interessiert hier nicht!
Karl H. schrieb:> Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern,> so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die> Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist> auch nicht mehr gross rum rechnen. Was machst du mit dem übrig> gebliebenem RAM? Öhmmmmm.
Du warst beim Lesen meines Projekt-Threads eben auch nicht aufmerksam.
Das will ich Dir aber keinesfalls vorwerfen, da Dein Zeiteinsatz bei den
vielen Hilfe-Threads in jedem Falle höher zu bewerten ist.
Ja, was macht man mit zusätzlichem Platz? Warum bist Du da jetzt
plötzlich so einsilbig einfallslos?
Stell Dir eine Messwert-Vorabauswertung vor, bevor die Daten auf die
Reise gehen. Garniert vielleicht mit einen kleinen History. Da kann man
u.U. jedes Bytchen gebrauchen. Die Main ist noch frei. Idealer
Erweiterungspunkt, um Funktionalität wunderbar unabhängig von der
periodischen Datenausgabe mit vielleicht ein paar Unterprogrammebenen
einzuziehen.
Du weißt natürlich selbst, daß es mir nicht darum geht, vorhandene
Ressourcen ungenutzt zu lassen. Natürlich. Natürlich weißt Du, daß es
nur um den prinzipiellen Ressourcenvergleich C vs. Asm geht bei
bitteschön gleich(st)er Vergleichs-Funktionalität geht... Natürlich K.H.
Gibs halt mal zu ;-)
Ist halt für einen überforderten C-Profi schwierig, bei diesen
Schwierigkeiten nicht in konstruierte Nebenkriegs- Schauplätze und
Plänkeleien abzugleiten. Immerhin bleibst Du im zweiten KnowHow
Vergleich unter den steil emporragenden C-Koryphäen, der hier so
hintergründig mitläuft überzeugend- da Du der Versuchung widerstehst,
das zwar tröstende, erheiternde, ablenkende- aber eigentlich doch so
dumme und entlarvende Hohn/ Spott/ Beileidigungs/ Betrugsvorwurf-
Spielchen mitzuspielen. Respekt.
> Wenn man den Compiler anweist, die Variablen in Register zu legen, würde> man wahrscheinlich auch das noch wegkriegen.
Ich bin doch eigentlich sooo gutmütig und großzügig: Die Möglichkeit
massierten Registereinsatzes hab ich für C doch offengelassen. Auch
wenns im Vergleich zu den meinigen 11 von 32 Registern dann natürlich
nicht schön ausschaut und, wenn nicht den faktischen, so aber zumindest
den moralischen Sieg kostet ;-)
Jörg W. schrieb:> hat Moby gewonnen,
Ja. Dann hat er aber nur eine Schlacht gewonnen. Den Krieg hab längst
ich gewonnen.
Mit meinem absolut genialen Programm.
Es macht exakt das, was es soll. Nicht mehr und nicht weniger.
Und das mit absoluter Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
Da kommt er mit seinem Dödelprogramm nicht im entferntesten heran.
mfg.
Thomas E. schrieb:> Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran.
Und Du mit Deiner Rumpffunktionalität nicht im Entferntesten an die
Arbeitsresultate meines Projekts. Hattest Du das noch nicht bemerkt?
Es spricht momentan nicht gerade für Dich, daß Du so unterschiedliche
Funktionalität unbedingt im Ressourcenverbrauch vergleichen willst.
Also mir wär das peinlich ;-)
Bernhard M. schrieb:> D.h. es kann möglich sein, ein dem Assemblerprogramm gleichwertiges> Programm in C zu schreiben, wenn der Compiler den identischen Assembler> output erzeugt, bzw. exact die gleichen Bytes ins Flash gebrannt werden.> Alles andere ist eine Verletzung der Spezifikation.
So eine Aussage wär mir auch peinlich...
> Der Thread ist somit beendet. (*)> Bitte schliessen.
(*) Wegen Überforderung des C-Compilers.
Schnell weg damit. Aus dem Auge, aus dem Sinn.
So liebe Leute, auch wenns gerade so einen Spaß macht mich an dem
hilflosen Herumrudern mancher Akteure hier zu laben- ich schau nochmal
auf mein Programm wegen der -hochtrabend so genannten - "Spezifikation"
...
Fortsetzung folgt.
Moby A. schrieb:> Und Du mit Deiner Rumpffunktionalität nicht im Entferntesten an die> Arbeitsresultate meines Projekts. Hattest Du das noch nicht bemerkt?> Es spricht momentan nicht gerade für Dich, daß Du so unterschiedliche> Funktionalität unbedingt im Ressourcenverbrauch vergleichen willst.
Welch ein Ausbruch, um von der eigenen Unzulänglichkeit abzulenken.
Ich will gar nichts vergleichen. Mein geniales Programm lässt sich mit
nichts vergleichen. Das Beste gewinnt jeden Vergleich. Und dieses
Programm ist sogar das absolut Beste.
Es macht exakt das, was es soll. Nicht mehr und nicht weniger.
Und das mit absoluter Effizienz:
4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM
Flankenschonender und stromsparender Takt
Maximal mögliche Schonung des Befehlssatzes
Das sind die unwidersprochenen Fakten!
Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran.
mfg.
So, also nochmal:
le x. schrieb:
> Hier der anscheinend letzte Stand dieser Anforderungsliste:> - Der Prozessor soll den internen 128kHz Takt verwenden
OK.
> - es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4)> und AINP-CHANNEL2 (entspricht PB3) eingelesen werden (1)
OK. Die zu verwendende Referenzspannung wird für jeden Kanal einzeln in
Form einer Konstante vorgegeben!
> - die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen> werden
Natürlich. Wir wollen doch nix "verschwenden" ;-)
> - das Einlesen soll im free-running Modus des ADC stattfinden
Im Interesse der Interrupt-Einsparung wärs gut. Kann man aber auch
manuell starten/im ADC-Int auslesen. Aber Stackbeschränkung (s.u.)
beachten!
> jeder Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2)
Richtig.
> - es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1)> und DINP2-LOW (entspricht PB5) eingelesen werden
Richtig.
> - das Einlesen soll unmittelbar vor der Datenübertragung erfolgen
Ja. Wär echt sinnvoll, daß die nächste Datenausgabe aktuelle Werte
enthält...
> - es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte,> versandt werden> - das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden> - ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK> (entspricht PB2) ausgegeben werden
OK.
> - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden> durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden)> - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits> - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits> - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits> - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits> - Bit 20: DINP1-LOW> - Bit 21: DINP2-LOW
Ok.
> - Bits 22-23: Checksumme über das Datentelegram> - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in> einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird
Bit22= Bit 0 der Summe, Bit23= Bit 1 der Summe
> - das Telegram soll alle 320 ms wiederholt werden; der genaue Wert> ist unkritisch> - Das Telegram soll eine Bit-Zykluszeit von ca. 10 ms haben, also 80 ms> pro Byte
Genau. 80ms Pause zwischendurch dienen der Synchronisierung.
Siehe Diagramm! Dort ist dann auch zu sehen, daß das letzte Datenbit auf
PB0 in der Pause stehenbleibt.
> - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen> - das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben
Die letzten 2 Punkte hatte ich schon zum Abschuß freigegeben.
Wär natürlich schön, der Anwender könnte auf dieser Architektur
aufbauend einfachst erweitern, ohne daß die unabhängige
Ausgabe-Funktionalität gestört würde (dann mit entsprechender
TimerInt-Registersicherung).
> - es ist nur 1 Timerinterrupt zu verwenden, andere Interrupts sind für> Erweiterungszecke reserviert
Siehe auch Stack-Beschränkung!
> 1) Soll 8 mal AINP-CHANNEL1 und dann 8 mal AINP-CHANNEL2 eingelesen> werden oder soll dies im Wechsel geschehen?
Ist doch wurscht.
> 2) Soll zwischen den 8 Messpunkten gewartet werden (z.B. im nächsten> Timer-Interrupt) oder soll eine Messung gestartet werden, sobald der ADC> wieder frei ist?
Was willst Du da starten? Der ADC läuft doch Free Running...
Wenn Du den schön regelmäßig ausliest hast Du immer aktuelle Werte.
Mit einer anderen Lösung muss in jedem Fall eines sichergestellt sein:
Die Datenausgabe enthält den Durchschnitt von 8 aktuellen Messungen!
Und zum Abschluß das Wichtigste:
Für den faktischen Sieg soll
a) die Datenausgabe stimmen (was ich sehr schnell mit der .hex prüfen
kann)
b) kein Byte Flash mehr verbraucht werden
c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt
werden.
Alles klar?
Wenn nicht, bitte fragen.
Anbei auch nochmal das aktuelle Programm.
Moby A. schrieb:> a) die Datenausgabe stimmen (was ich sehr schnell mit der .hex prüfen> kann)> b) kein Byte Flash mehr verbraucht werden> c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt> werden.
Ich dachte, wir sprechen von Programmen jeglicher Grösse, aber ich sehe
bei dir nur ein Mickymausprogramm...
Bevor wir darüber sprechen, sollten wir uns über sinnvolle Vorgaben
und daraus folgend eine sinnvolle Architektur unterhalten. Denn die
beinhaltet dein Programm nicht.
Und: Die obige Anforderungsliste ist alleine schon kryptischer als das
zugehörige C-Programm.
P. M. schrieb:> Ich dachte, wir sprechen von Programmen jeglicher Grösse, aber ich sehe> bei dir nur ein Mickymausprogramm...>> Bevor wir darüber sprechen, sollten wir uns über sinnvolle Vorgaben> und daraus folgend eine sinnvolle Architektur unterhalten. Denn die> beinhaltet dein Programm nicht.>> Und: Die obige Anforderungsliste ist alleine schon kryptischer als das> zugehörige C-Programm.
Schon klar.
Die Ausreden gehen gleich wieder los- und woher wußte ich nur, daß
ausgerechnet Du den Anfang machst ;-)
Deine Vorstellungen von "sinnvoller Architektur" kannst Du woanders
einbringen. Hier gehts nur darum, die beschriebene, sehr einfache
Funktionalität kürzestmöglich umzusetzen.
Toi toi toi...
Moby A. schrieb:> Schon klar.> Die Ausreden gehen gleich wieder los- und woher wußte ich nur, daß> ausgerechnet Du den Anfang machst ;-)>> Deine Vorstellungen von "sinnvoller Architektur" kannst Du woanders> einbringen. Hier gehts nur darum, die beschriebene, sehr einfache> Funktionalität kürzestmöglich umzusetzen.
Die Kernaussage der meisten Diskussionsteilnehmer ist:
"C verbraucht selbst bei kleinsten Programm in der Regel (wenn
überhaupt) nicht wesentlich mehr Resourcen als ein hochoptimiertes
Assembler-Programm UND ab mittelgrossen Programmen ist es durch
Assembler nicht mehr zu schlagen."
Und du kommst her, und verlangst, diese Behauptung zu beweisen, indem
eine C-Umsetzung deines Mickymausprogramms kein Byte mehr brauchen darf
als deine Assembler-Version? Absurd.
... es ist unglaublich mit welcher Geduld mit Moby diskutiert wird...
Jetzt habe ich mir fast den ganzen Abend lang die Texte gelesen,
manchmal amüsiert, dann wieder gelangweilt und dann wieder hoch erstaunt
ob einer extremen Ignoranz (von Seiten Moby).
Ich habe lange Jahre programmiert, den C64 in Assembler, einen Schneider
CPC, mein erster ganzer Stolz, einen Commodore PC1 (mit einem wahnwitzig
schnellen 8088 CPU 4,7MHZ ... langsamer ging es auf PC Basis nie).
Die habe ich der Effizienz wegen noch in Maschinensprache programmiert,
wobei beim Schneider CPC und dem PC1 schon auch Turbo Pascal eingesetzt
wurde (und auch zu diesen Zeiten gab es schon die Glaubenskriege um die
Sprache).
Zunehmend (mit leistungsfähigeren Teilen) wurde Maschinensprache immer
seltener (und mein letztes großes Projekt - irgendwann Anfang der 80er -
war ein Texteditor der den maximalen Speicher Segementgrenzen hinweg
verwenden konnte. DA war auf den damals langsamen Kisten Pascal und C zu
langsam dafür). Ich hatte DOS gleichzeitig gehasst und geliebt. Mein
erster Controller war ein 8048 und den musste ich mangels vorhandenem
Compiler in Maschinensprache programmieren.
Auf Controllerebene das letzte große Projekt in (reiner)
Maschinensprache war ein Logger, der über Temperatureinwirkung über der
Zeit ein bestimme Qualitätsaussage zu einem Produkt machen mußte. Was
für ein Grauen !!!! Das Gerätchen mußte über serielle Schnittstelle eine
klare Aussage in Gleitkommadarstellung machen. Bei der Verrechnung der
Daten mußte ein Logartihmus programmiert werden. !!!!
Sowas ... in Maschinensprache ... will ich nie mehr machen müssen! Vllt.
war ich "besser" als ein Compiler (aber ich wage das mal zu bezweifeln).
Jeder hier (außer wohl Moby) weiß, wann er welche Sprache einsetzt und
wann er (wenn es halt nicht mehr anderst geht) wirklich Maschinensprache
einsetzt. Bei den heutigen Controllern, bei denen nicht mehr die
Leistungsfähigkeit des Controllers den Preis desselbigen bestimmt,
sondern die Absatzzahlen, müssen - glücklichweise - nicht mit jedem
Byte gegeizt werden damit etwas läuft.
Wie hier schon oft erwähnt: Entwicklungszeiten sind mit ganz großers
Sicherheit in Assembler länger (wenn es nicht gerade Trivialprogramme
sind).
Hier schreiben Koryphäen ihres Fachs wie Jörg Wunsch (um einen einzigen
mal zu nennen), dem ich ungesehen fast jedes Wort glaube was er schreibt
und ich wundere mich sehr, woher sie die Geduld und die Motivation
genommen haben sich mit Moby auseinander zu setzen.
Ich gebe zu, dass mich Maschinensprache auch heute noch reitzt und ich
das auch immer wieder mal zum Spaß anpacke und ich mich drüber freue mit
wie wenig Code man etwas anstellen kann. Auch zum Lehren wie das Ding
das man da programmiert denn eigentlich wirklch funktioniert, zum
Zeigen, dass man eine Subtraktion durch eine Addition mit mit dem
Komplement bewerkstelligt werden kann ist es super.
Fürs Schreiben von kompletten Appliationen jedoch nicht.
Meine Hochachtung gilt hier all denjenigen Experten, die sich mit Moby
auseinandergesetzt haben und es wohl auch weiter tun werden (allerdings
müssten sie wissen, dass es aus
cli();
while(1);
sei();
kein Entrinnen gibt, das Wiedereinschalten der Interrupts nie
stattfindet und sich in der while-Schleife die "Diskussion" (es ist
keine) mit Moby wiederfindet.
Gute Nacht allen, die vllt. noch lesen !
P. M. schrieb:> ab mittelgrossen Programmen
An die Vorstellung eines 1-10K Asm Programms und die Annahme, jemand
würde das in C neu formulieren wage ich gar nicht erst zu denken, wenn
sich schon bei 200 Bytes jeder C'ler hier die Zähne ausbeißt.
Damit bleibts bei Aussage gegen Aussage.
P. M. schrieb:> Und du kommst her, und verlangst, diese Behauptung zu beweisen, indem> eine C-Umsetzung deines Mickymausprogramms kein Byte mehr brauchen darf> als deine Assembler-Version? Absurd.
Absurd wäre wohl die Annahme, daß Du das schaffst.
Mit Übung, Vorbereitung und System lassen auch noch viel größere
Asm-Programme C im Ressourcenverbrauch im Regen stehen, da summieren
sich die Einspareffekte noch. Irgendwann setzt dann mal die Übersicht
sinnvolle Grenzen- aber weit über dem hinaus, was Experten wie Du
vielleicht für möglich halten.
Ralph S. schrieb:> (allerdings> müssten sie wissen, dass es aus>> cli();> while(1);> sei();>kein entrinnen gibt...
Was seid ihr doch für Nachteulen;-)
P.S. Den Arduino Watchdog müßt Ihr entschuldigen, konnte keinen für den
AVR finden...
... lach, ich geb mich geschlagen .... mit dem Wachhund...
(ob ich jetzt fieberhaft nach einem AVR OHNE WDT suchen soll? Vllt.
findet sich ja noch irgendwo ein altes Exemplar bei dem das nicht
implementiert ist.... bevor jetzt jemand kommt: Reset-Taste zählt nicht)
Ralph S. schrieb:> ... lach, ich geb mich geschlagen .... mit dem Wachhund...>> (ob ich jetzt fieberhaft nach einem AVR OHNE WDT suchen soll? Vllt.> findet sich ja noch irgendwo ein altes Exemplar bei dem das nicht> implementiert ist.... bevor jetzt jemand kommt: Reset-Taste zählt nicht)
Ganz so war das doch nicht gemeint.;-)
Ralph S. schrieb:> ... es ist unglaublich mit welcher Geduld mit Moby diskutiert> wird...
Diese Energie wird nun wohlweislich nicht in eine C-Version meines
simplen Projekts gesteckt- und damit in den einzig möglichen, reellen
Vergleich. Das gibt doch zu denken...
Interessant auch, was Du alles als Diskussion bezeichnest ;-)
> Fürs Schreiben von kompletten Appliationen jedoch nicht.
Für so einen kleinen AVR ist das bei 8-Bit MSR kein Problem.
Nur keinen Elefanten aus ner kleinen Maus machen ...
> in der while-Schleife die "Diskussion" (es ist> keine) mit Moby wiederfindet.
Die While-Schleife läuft so ab:
- Moby beschreibt und zeigt die Effizienz von Asm.
- die Cler erkennen diese (manchmal nur versteckt an)
- da aber nicht sein kann was nicht sein darf: Attacke!
(alle Mittel sind recht)
Goto 1 ;-)
Moby A. schrieb:> Die While-Schleife läuft so ab:> - Moby beschreibt und zeigt die Effizienz von Asm.
Guten Morgen Moby,
wann schnallst due endlich, dass Effizienz nicht nur Flash- und SRAM
Verbrauch bedeuten, sondern die hier bereits in aller Länge und Breite
dargelegten anderen Faktoren beinhaltet!!!
> - die Cler erkennen diese (manchmal nur versteckt an)
Die "Cler" hier kennen sich meist alle viel besser und tiefer mit ASM
aus als du. Und jeder weiß, wann und warum die eine oder die andere Art
des Programmierens für ihn sinnvoller und effektiver ist.
Dein "sehr spezieller" Datenlogger loggt zumindest keinen hinter dem
kalten OPfen hervor. Bei einem Projekt, f+r dass das Gehirn wenigstens
warmläuft sähe das sicher anders aus.
> - da aber nicht sein kann was nicht sein darf: Attacke!> (alle Mittel sind recht)
Das stimmt allerdings. Besser wäre es, das Thema von nun an zu
ignorieren, weil es so sinnlos ist. Es ist scheißegal, ob das Programm 3
Byte größer oder kleiner ist, 4 Byte SRAM belegt oder nicht. Und DAS ist
der Punkt, den du beharrlich verteidigst. Leider für den Restderwelt
grundsätzlich bedeutungslos.
Vlt. erschlägt ja auch jemand den ganzen Müll hier mit einem C Programm
das tatsächlich kürzer ist, und dich damit mit deinen eigenen Waffen
-nein, Dogmen.
Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu haben
ist Moby irgendwie wirklich verzweifelt....
Nicht dass du anscheinend wirklich ausgeblendet hast, dass dein erstes
ultimatives Programm verloren hast, du predigst von Planung, Ordnung,
Blabla und hast immer fehlerhaften Code gepostet (Wie auch immer das
passieren kann) Du ignorierst Gegenfragen. Das Argument der potentiellen
Erweiterbarkeit deiner Projekte ist inzwischen kaum noch zu hören. DAS
war ja dein Argument manisch Ram und Flash zu sparen - als Karl Heinz
mal fragte, was genau an 1 kB Flash an Erweiterungen im Raum stehen
könnten hat man natürlich nix gehört. Wenn dein Sensor eine Kennlinie
bekommen muss, passt die nicht rein. Wenn du die Kennlinie berechnen
könntest, wäre es keine typische 8 bit Anwendung... sic.
Inzwischen ist das aber auch im Hintergrund. Jetzt ist deine neue Sau
ein Stack der keiner ist....
Wie wäre es mit einem Remi? Deinen Code als inline asm in einem C
Programm? Dass du nur ein einziges, künstlich konstruiertes Eisen im
Feuer hast (was ja trotz Planung verbuggt war) und dieses Eisen wirklich
nur seiner selbst willen von dir hochgehalten wird blendest du wirklich
aus?
Selbst um eine Aussage zu untermauern wie 'bis 1kB ist händischer asm
Code einem c Code in puncto Flash/Ram Verbrauch bzw Geschwindigkeit
überlegen' wäre etwas mehr als eine statistische Ausnahme angesagt.
Mach doch mal bei einem angebotenen Vergleich mit. Gerade diejenigen die
es dir angeboten haben sind faire Leute, die dich nicht wegen etwaiger
Fehler zerreißen werden.
Es lesen viele mit, die sich bestimmt auch als Hobbyisten zu Assembler
bekehren lassen würden. Du würdest dir einen Namen machen. Also jetzt
nicht nur als Witzfigur.
Frage (an die Allgemeinheit) zu dem ADC und Durchschnitt..
moby macht ja aus den 8 Werten einen Durchschnitt, der dann aber auch
wieder nur 10 bit hat..
ich hab es bei meinem Helligkeitssensor so gemacht, dass ich einfach 10
Werte addiere.
in der Hoffnug dadurch einen höhere genauigkeit zu erhalten (vorallem
bei dämmerung) (also ungefähr 13Bit)
ist das unrealistisch? sind die (nur) 10Bit schon unrealistisch?
warum moby hier einen durchschnitt rechnet, verstehe ich nicht,
gehts hier um Falschmessungen die dann nur 1/8 ins ergebnis einfließen
sollen?
muss man das machen? konnte bei mir jetzt nicht feststellen dass da auch
mal was falsch gemessen wird..
würde man dann nicht 10 Werte messen und min und max weglassen?
einen Durchschnittüber die Zeit (300ms) will moby eh nicht (bzw ist es
ihm egal? die doku ist hier sehr "mager")
Markus M. schrieb:> Es ist scheißegal, ob das Programm 3> Byte größer oder kleiner ist, 4 Byte SRAM belegt oder nicht.
Für Moby eben nicht. diese 3 Byte Flash und 4 Byte RAM sind sein
Notnagel, sein letzter Strohhalm.
C ist ausgelegt für die Benutzung eines Stacks und der AVR ist
ausgelegt für C.
Trotzdem führt er immer wieder den Stackverbrauch als DAS Kriterium, als
die härteste aller Anforderungen an. Weil er weiß dass er damit jedem
Compiler massive Knüppel zwischen die Beine wirft.
Da könnte das Programm tausendmal schneller implementiert, tausendmal
besser lesbar und tausendmal besser erweiterbar sein.
1 Byte Stack (ne sorry, 3 - denn Moby braucht ja auch 2) und du hast
verloren.
Das ist so wie wenn du gegen Usain Bolt im Sprint antrittst, ihm aber
Arme und Beine zusammenbindest.
Du kannst dich nachher vielleicht gut fühlen, aber die Aussagekraft so
eines Experimentes kann man wohl bestreiten...
Ich zitier mich mal selbst:
le x. schrieb:> Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein> ganz anderer:> Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung> eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man> keinen Krüppel-Code schreiben will), dieser befindet sich traditionell> ebenfalls im RAM.>> Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne> Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu> gewinnen...
Moby A. schrieb:> Diese Energie wird nun wohlweislich nicht in eine C-Version meines> simplen Projekts gesteckt- und damit in den einzig möglichen, reellen> Vergleich. Das gibt doch zu denken...
Warum auch.
Braucht man 20B weniger Flash aber 1Byte mehr SRAM -> Verloren
Braucht man kein SRAM aber 1Byte mehr Flash -> Verloren
Braucht man weniger Flash UND weniger SRAM -> Verloren
Für den dritten Fall wirst Du Dir dann irgendwas ausdenken was jetzt
ganz plötzlich ein unglaublich wichtiges Kriterium ist.
Nutzloses RAM zu initialisieren oder auf einem Bein zu hüpfen und dabei
wie ein Huhn zu gackern oder sonst was.
Zur Not muß die Zeichenlänge des Quellcodes herhalten oder der RAM
Verbrauch des Compiler auf dem Entwicklungssystem oder wie viele
Mausclicks man braucht um die IDE zu starten.
Dir wird schon was einfallen was man als völlig hirnrissiges Argument
mißbrauchen kann.
le x. schrieb:> Hier der anscheinend letzte Stand dieser Anforderungsliste:
Super.
Eine Checksumme die so schwach ist das ich würfeln kann ob die Werte
wirklich stimmen.
Völlig ineinander verwurstelte Daten die ich am Zielsystem erst wieder
auseinandernehmen muß um was damit machen zu können.
Eine synchrone unidirektionale Punkt zu Punkt Verbindung bei der im
Zeitlupentempo Daten übermittelt werde statt ein vernünftiger Feldbuss
mit Master / Slave Protokoll und starker CRC.
RS485, Lin, Can, DALI, herje es gibt so viel Busse die alle mehr können
als dieser Unfug.
Wenigstens eine Manchester Codierung für Gleichspannungsfreie
Datenübertragung mit Impulsübertragern und Taktrückgewinnung aus den
Daten hätte man doch machen können um irgendwas sinnvolles bei einem
proprietären Bus zu machen.
Den Teil wo die Entprellung der digitalen IOs stattfindet oder die
Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden
können.
Mit Verlaub.
Das ist vollkommener Müll.
Warum sollte man sich die Mühe geben so einen sinnlosen Kram zu
programmieren der unzuverlässige Daten erhebt und auf eine unflexible
und unzuverlässige Art übermittelt.
Die unterste Schmerzgrenze für Sensor / Aktor Knoten sehe ich bei
adressierbaren Master / Slave Feldbussen mit min. 16 Teilnehmern.
Michael K. schrieb:> Den Teil wo die Entprellung der digitalen IOs stattfindet oder die> Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden> können.
Das ist keine typische 8bit MSR Anwendung.
>Master / Slave Protokoll und starker CRC.>RS485, Lin, Can, DALI
Das verbraucht alles RAM und Flash. => Wird ausgelagert.
Matthias L. schrieb:> Michael K. schrieb:>> Den Teil wo die Entprellung der digitalen IOs stattfindet oder die>> Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden>> können.>> Das ist keine typische 8bit MSR Anwendung.
Damit treibt Moby die ganzen Anfänger ins 32bit Lager.
Die lesen was für Moby typische 8bit Anwendungen sind nehmen lieber
gleich einen STM32.
Matthias L. schrieb:>>Master / Slave Protokoll und starker CRC.>>RS485, Lin, Can, DALI> Das verbraucht alles RAM und Flash. => Wird ausgelagert.
Das was wirklich völlig sinnloser Flash und Ram Verbrauch ist nennt Moby
eine typische 8bit MSR Anwendung.
Nach meinem Empfinden das nicht mehr als ein 8bit MSR 'Hello World'
Das primitivste Grundgerüst eines Programmes das nicht mehr kann als zu
zeigen das man prinzipiell ein Programm zum laufen bekommt.
Moby A. schrieb:> Die While-Schleife läuft so ab:> - Moby beschreibt und zeigt die Effizienz von Asm.> - die Cler erkennen diese (manchmal nur versteckt an)> - da aber nicht sein kann was nicht sein darf: Attacke!> (alle Mittel sind recht)>> Goto 1 ;-)
Falsch.
1
#define PHRASENDRESCHERMODUS 0
2
#define IMMER_AN 0
3
4
while(PHRASENDRESCHERMODUS==IMMER_AN)printf("Mit Uebung, Vorbereitung und System...");
Moby A. schrieb:> b) kein Byte Flash mehr verbraucht werden
Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm
findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut
und komplett versagt?
Moby A. schrieb:> An die Vorstellung eines 1-10K Asm Programms und die Annahme, jemand> würde das in C neu formulieren wage ich gar nicht erst zu denken, wenn> sich schon bei 200 Bytes jeder C'ler hier die Zähne ausbeißt.> Damit bleibts bei Aussage gegen Aussage.
Andersrum: Du weisst haargenau, dass du nur bei so einem Miniprogramm
eine Chance hast.
Kein Mensch schreibt in nützlicher Frist ein 10kB+ Assembler-Programm,
das einen guten C-Compiler schlägt. Und nur beim Mini-Programm kann man
darauf hoffen, dass ein kleiner (fixer) C-Overhead den
Speicher-Verbrauch doch noch um die entscheidenden* paar Bytes hin die
Höhe treibt.
* "Entscheidend" im Mobyschen Sinn, nicht nach sinnvollen
Designkriterien.
Moby A. schrieb:> Also mir wär das peinlich ;-)>>> So eine Aussage wär mir auch peinlich...
Also da muß ich mich schon wundern.
Bis jetzt war dir doch echt nix zu peinlich. Z.B. das hier
Moby A. schrieb:> Mach Dir> lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau> gestellten Assembler-Überlegenheit zu begegnen ist ;-)
>> in der Hoffnug dadurch einen höhere genauigkeit zu erhalten (vorallem>> bei dämmerung) (also ungefähr 13Bit)>> ist das unrealistisch?
Ja
Schaust du letzten Beitrag unter 2 (Seitenaufteilung). Da bin ich darauf
eingegangen und habe Fotos beigefügt von dem was geht. Ist aber keine
typische Anwendung für kleine AVRs :-) braucht zu viele Resourcen :-)
12 BIT bei 256 Werten kannst du in der Praxis erwarten, mehr ist nicht
drin.
Johann L. schrieb:> Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm> findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und> komplett versagt?
Nein, keinesfalls. Wurde ja schon gemacht. Das, was die dann
kürzere Lösung notwendigerweise weggelassen hat, wird zum zwingend
notwendigen Feature der anderen Implementierung erklärt. Das ist ja
in seinem Sinne durchaus folgerichtig, denn es gibt ja keinerlei
„offizielle“ Spec außer der bestehenden Implementierung.
Damit ist es völlig klar, dass jegliche alternative Implementierung
bei ihm keine Chance hat. Selbst eine Implementierung in C müsste
notwendigerweise exakt den gleichen Assemblercode liefern, um
akzeptiert zu werden.
Jörg W. schrieb:> Das ist ja> in seinem Sinne durchaus folgerichtig, denn es gibt ja keinerlei> „offizielle“ Spec außer der bestehenden Implementierung.
Wobei es mittlerweile ja eine vom ihm gereviewede und kommentierte Spec
gibt. Von dem her müsste das jetzt als "offiziell" gelten.
Moby hat doch geschrieben
> c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt
Damit dürfte klar sein dass das C Programm keinen SRAM verwenden darf.
Ausser 2 Bytes vom Stack.
Ergo: Wenn das C-Programm kleiner ist (Flash) und keinen SRAM verbraucht
hast gewonnen.
Ausser Moby fällt dann wieder was ein ;-)
Matthias L. schrieb:>>12 BIT bei 256 Werten>> 12bit ist grösser 8bit. Und 256 ist auch grösser 8bit
256 Werte passen in 8 Bits. Nicht aber der Wert 256. ;-)
Moby A. schrieb:> Gerhard O. schrieb:>> http://www.zoe-online.org/dateien/Einblick_02_11.jpg>>>> Seufz...>> Ja, die Aufgabe ist für C nicht einfach ;-(> Dieses verdammt sperrige Sprachinstrumentatium !
Mit Verlaub, Du hast Dich verlaufen. Und daß Du mit einigem rhetorischen
Geschick die Horden, die Dir hier ausführlichst widersprachen, zunehmend
aufs Glatteis geführt hast*), macht es nicht besser.
Vergiss den TIOBE-Index. Man muß nicht dieses alte Goebbels-Zitat
(->http://www.statistik.baden-wuerttemberg.de/Veroeffentl/Monatshefte/PDF/Beitrag04_11_11.pdf)
bemühen ("Glaube keiner Statistik ..."), um zu begreifen, daß bloße
Popularität auch im Bereich der Programmiersprachen kein vernünftiges
Kriterium für irgendwas ist. Abgesehen davon erkennten diejenigen, die
diesen schlechten Spruch klopfen, erfahrungsgemäß eine gefälschte
Statistik nicht mal dann, wenn sie sie in die Nase bisse.
Wenn ich anfangs noch eine gewisse Sympathie den Ansatz und das Motiv
betreffend hatte, das ich bzgl. Deines Anliegens zu erkennen glaubte,
nämlich den Ansatz, gegen den Trend mit modernen Mitteln minimalistische
Lösungen zu erkunden, so sehe ich inzwischen, daß dafür offenbar
entweder die Kenntnisse oder das Interesse fehlen, oder beides.
Was Du und nicht nur Du nämlich übersiehst und was in den beiden obigen
Bemerkungen herauskommt ist der Glaube, daß mit ASM hier und C dort sich
gewissermaßen komplementäre Ansätze gegenüberstünden, deren Vorzüge es
auszufechten gelte.
Wenn man sich aber die Entwicklung der Programmiersprachen der letzten
rund fünfzig Jahre betrachtet, beginnend mit Autocoder
https://en.wikipedia.org/wiki/Autocoder (ca 1950), Fortran (ca 1957),
Algol (1958), Lisp (1958), Snobol (1962), PL/I (1964), APL (1965),
Simula (1967), Prolog (1972), ML (1972), C (1973), Haskell (1990), Rust
(2010), usw.
so sieht man, daß C keineswegs die abstrakte, abgehobene, sperrige
Programmiersprache darstellt, die Du darin zu sehen glaubst, sondern
eine späte Regression, eine Rückkehr (fast) zu der Sprachebene des
Assembler, wenn man aber auf die Erfahrung mit Sprachdesign, Compilerbau
und Codegenerierung für Sprachen wie PL/I, Algol, Algol68, Lisp oder
Fortran zurückblicken kann. Was man halt macht, wenn man eine PDP11
geschenkt bekommt und damit ein kleines OS portieren (i.e.
reimplementieren) möchte, ohne auf den Komfort einer vernünftigen
Programmiersprache verzichten zu müssen.
Money quote aus http://www.bell-labs.com/usr/dmr/www/chist.html "...and
we regretted losing the advantages of writing programs in a language
above the level of assembler, such as ease of writing and clarity of
understanding".
Mein Hauptkritikpunkt an C ist der unterbelichtete Preprocessor. Ein
Assembler, mit dem ich vor 'zig Jahren in einem größeren Projekt
gearbeitet habe, konnte in der Makrophase erheblich mehr als der C
preprocessor heute, so daß sich auf Basis dessen durchaus
Kontrollstrukturen oder kleinere DSL bauen ließen.
Mein Ansatz, hätte ich auf dem Gebiet irgendwelche Aktien, wäre zu
untersuchen, ob sich z.B. ein runtimelibfreies Rust soweit abspecken
läßt, daß sich damit auch Plattformen unterhalb des üblichen
32+-Bit-Geraffels als Targent verwenden lassen. Das wäre aber
Dickbrettbohren, weil auch das im Moment gegen den allgemeinen Trend
geht und mit einer Menge Arbeit verbunden.
*) Rhetorisches 101: ignoriere eisern alle guten Gegenargumente, dann
werden Deine Widersacher im weiteren Verlauf zunehmend auch die
schlechten Argumente durchprobieren. Du hattest aber in dem Moment
verloren, als Du Dich geweigert hast, eine abstrakte, vernünftige und
abschließende Spezifikation einer Aufgabenstellung zu formulieren,
anhand deren man verschiedene Implementationsansätze vergleichen könnte.
Der Rest ist nur noch davon ablenkendes Geplänkel.
>vernünftige und>abschließende Spezifikation einer Aufgabenstellung
diese müsste aber alle Behauptungen von Moby beinhalten, also auch z.b.
vorallem die angebliche einfache Erweiterbarkeit, müsste irgendwie
"getestet" werden (ohne konkretes Beispiel wird das nicht gehen..)
die "Einfachheit" ansich von ASM
(es müsste also definiert werden, was "Einfach" ist..)
welche Resourcen wie wichtig sind:
also wer "gewonnen" hat wenn die (dann erweiterte) Version 1 Byte mehr
RAM, die andere dafür 1 Byte mehr Flash braucht..
und man müsste definieren, was denn mit dieser "Aufgabenstellung"
bezweickt werden soll, und ob das mit der "Aufgabenstellung" überhaupt
möglich ist..
Jörg W. schrieb:> Ich habe gestern ein Buch über Assembler-Programmierung geschenkt> bekommen.
Gratuliere.
> In seinem Vorwort enthält es den Absatz:> ... By its very nature, an assembly language has the same life> expectancy as the processor it supports perhaps 20 years at best.
An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig.
Eine Lebensdauer über ein halbes Menschenleben dürfte es eher treffen.
Mit gut gelagerten Reserven allemal.
Ansonsten ist die Feststellung unter einem weiteren Gesichtspunkt
irrelevant: Egal ob mit Asm oder Hochsprache- ob viele kommerzielle
Produkte (heutzutage und vor allem zukünftig bei beschleunigter
IT-Entwicklung) auch noch in >20 Jahre unverändert Verwendung finden
werden ist doch seeeehr zweifelhaft.
Wolfgang S. schrieb:> so sieht man, daß C keineswegs die abstrakte, abgehobene, sperrige> Programmiersprache darstellt, die Du darin zu sehen glaubst, sondern> eine späte Regression, eine Rückkehr (fast) zu der Sprachebene des> Assembler, wenn man aber auf die Erfahrung mit Sprachdesign, Compilerbau> und Codegenerierung für Sprachen wie PL/I, Algol, Algol68, Lisp oder> Fortran
Na ja gemessen an den anderen heißen Kandidaten (für andere, z.T. viel
größere Systeme) schon. Das interessiert aber hier jetzt herzlich wenig.
> Du hattest aber in dem Moment> verloren, als Du Dich geweigert hast, eine abstrakte, vernünftige und> abschließende Spezifikation einer Aufgabenstellung zu formulieren,> anhand deren man verschiedene Implementationsansätze vergleichen könnte.
Und ich sage Dir: Ich könnte noch 100 abstrakte, vernünftige und
abschließende Spezifikationen der Aufgabenstellung formulieren und es
würde an einem nichts ändern: Ein erfolgreicher C-Nachbauer findet sich
nicht. Kann sich nicht finden. Asm bleibt C gegenüber bei 8-Bit MSR eben
für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit
Übung, Vorbereitung und System drangeht ;-)
An der Ausrede für ein derart kleines, höchstdokumentiertes Projektchen,
der C-Nachbau würde an einer Spezifikation scheitern, kann ich mich nur
regelmäßig belustigen.
So, gerade keine Zeit, in der Nacht dann wieder.
Vielen Dank für die weiter zahlreichenden Rückmeldungen.
Moby A. schrieb:> Asm bleibt C gegenüber bei 8-Bit MSR eben> für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit> Übung, Vorbereitung und System drangeht ;-)
Ich folgere mal daraus:
"Wenn man NICHT mit ÜVS rangeht ist ASM gegenüber C NICHT überlegen."
Der selbe Satz, aber ohne die beiden Negierungen:
"Ohne ÜVS ist ASM gegenüber C unterlegen."
Jetzt bringen wir mal ÜVS auf beide Seiten ins Spiel, d.h. der
ASM-Programmierer und der C-Programmierer benützen jetzt ÜVS. Dann wird
daraus:
"Mit ÜVS ist ASM gegenüber C mit ÜVS unterlegen."
Oder, salopp ausgedrückt: Der ASM-Programmierer muss sich ganz schön ins
Zeug legen (ÜVS) um mit einem systemlosen C-Programmierer mitzuhalten.
Gibt sich der C-ler aber auch ein wenig Mühe (also jetzt auch ÜVS) kann
der ASM-ler einpacken, denn dieser ist ja schon am Limit.
Nichts anderes predigen wir dir ja auch schon die ganze Zeit.
Find ich Prima dass der Thread doch noch zu einem Ergebnis gekommen ist
das beide Seiten so unterschreiben können!
Moby A. schrieb:> An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig.
Deine Meinung? Also dieses wackelige Ding, dessen gesamtes Fundament aus
ein bisschen Assemblerprogrammierung besteht? Dieses Machwerk, in das du
kein Wissen von erfahrenen Leuten einfliessen lässt? Ja, diese Meinung
muss ja Gewicht haben.
le x. schrieb:>> für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit>> Übung, Vorbereitung und System drangeht ;-)>> Ich folgere mal daraus:> "Wenn man NICHT mit ÜVS rangeht ist ASM gegenüber C NICHT überlegen."
Diese Schlussfolgerung ist unzulässig.
Du hast die Zeile 42 überlesen.
if (das_passt_mir_nicht_in_den_kram) printf("verloren");
EDIT: Damit Moby das versteht. Kann das jemand nach ASM übersetzen?
le x. schrieb:> - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden> durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden)> - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits> - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits> - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits> - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits> - Bit 20: DINP1-LOW> - Bit 21: DINP2-LOW> - Bits 22-23: Checksumme über das Datentelegram> - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in> einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird
Das ist in C auch nur eine einfache Zuweisung, bei dem man sich einfach
den passenden Datentyp anlegt:
Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle
Schnittstelle.
PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.
Operator S. schrieb:> le x. schrieb:>> A. K. schrieb:>>> Diese Schlussfolgerung ist unzulässig.>>>> Wo liegt mein Denkfehler?>> https://de.wikipedia.org/wiki/Kontraposition
Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird
wohl nix...
le x. schrieb:> Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird> wohl nix...
In C würde man ja zum Beenden der Endlosschleife einfach ein
le x. schrieb:> Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird> wohl nix...
Beenden? Aber... was soll ich dann mit meiner ganzen frei werdenden Zeit
machen? Und Moby erst!
Markus M. schrieb:> PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.
VERLOREN!
Der Code DARF nicht auf einem mc ausserhalb von Mobys Universum laufen!
Gruß, Stefan
le x. schrieb:> Darf ich für den (nicht explizit vorhandenen) SONST-Pfad nicht (ASM < C)> annehmen?
Aus einer falschen Prämisse folgt nichts.
Bei WENN a DANN b:
a:true dann b:true
a:false dann b:any
>>>>>>PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.>> Wie ineffizient ist das denn
Falsch, muß auf Tiny13 laufen und der braucht kein CALL, weil RCALL +-2k
abdeckt und hat es deshalb auch nicht.
Ob Moby es kennt? Bei entsprechender ÜVS (oder war es ÜSV?) kann man
auch auf xMega ohne CALL auskommen. Man muß ja nur Caller und Callee
richtig positionieren.
Zudem: CALL braucht 4 Bytes statt den zweien des RCALL's. Damit werden
der Nachwelt wertvolle unbenutzte Flash-Zellen vorenthalten.
Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung"
untersucht, dann kommen unbenützte Speicherbereiche schlecht weg.
Gu. F. schrieb:> Endlich C lernen.
Das würde er gerne. Hat er auch schon probiert. Aber C lässt sich von
ihm nicht lernen. Programmiersprachen haben auch ihren Stolz.
mfg.
Carl D. schrieb:> Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung"> untersucht, dann kommen unbenützte Speicherbereiche schlecht weg.
Hihi genau. Und dank diesem Thread hier steht das auch ganz oben.
Matthias L. schrieb:> Carl D. schrieb:>> Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung">> untersucht, dann kommen unbenützte Speicherbereiche schlecht weg.>> Hihi genau. Und dank diesem Thread hier steht das auch ganz oben.
War ja nicht extrem ernst gemeint.
Aber etwas nutzlos zu produzieren, damit einer sich daran aufgeilt es
nicht zu benutzen, ist doch leicht schräg, oder?
le x. schrieb:> Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird> wohl nix..
Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott.
Ob mich daß bei Deinem Logik-Verständnis weiter oben überraschen sollte?
Na dann wenigstens Dankeschön für die (letzte) Live-Demo der
Sinnlosigkeit jeglicher wiederholter "Spezifikation". Oder?
Markus M. schrieb:> Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle> Schnittstelle.>> PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.
Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige
Bruchwerk aber noch nirgendwo. Von konkreten Ressourcenverbrauchs-Fakten
ganz zu schweigen. Eine klassische serielle Schnittstelle wird von
meinem Code auch nicht bedient.
P. M. schrieb:> Also dieses wackelige Ding
Langsam machst Du mit Deinen kompetenten Beobachtungen Carl D.
Konkurrenz...
Mein Code steht bombenfest, bewährt sich längst in der Praxis- aber Du
machst mir nicht den Eindruck, daß Du Dich damit jemals befasst hast
undoder ihn überhaupt verstehst. :-(
> kein Wissen von erfahrenen Leuten einfliessen lässt
Lass das mal in Deine C-Fassung einfließen. Da werd ich aber lange
warten. Dann dann zeigt sich schnell wer hier wen belehren müsste ;-)
Moby A. schrieb:> Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott.
Unglaublich! :-)
Da hängt er schon seit einer Ewigkeit in den Seilen und trotzdem kommt
immer sowas wie 'Hat ja gar nicht weh getan!'. Da wird der Kampf
sicherlich über 2000 Runden gehen.
Wobei...: Der Ringrichter wettet auf den Verlauf des Kampfes?! ;-/
Clemens M. schrieb:> Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu> haben ist Moby irgendwie wirklich verzweifelt....
Du solltest besser am RAM-Bedarf eines C-Compilers verzweifeln. Scheint
ja ein fetter Pferdefuß des fetten C zu sein. Beim ganzen Rest Deiner
konstruierten Jammerei erinnerst Du mich an einen gewissen Sheeva ;-)
Michael K. schrieb:> Nutzloses RAM zu initialisieren
Kein Problem Michael. Das und die Sleep Geschichte wird noch
rausgestrichen! Für den Vergleich hier ist das überflüssig. Da wird
der Volkszorn der Trolle, Stänkerer und verkrachten C-Existenzen zwar
hier wieder hochkochen, jeder einigermaßen neutrale und rationale
Beobachter wird mir aber zugestehen, daß nur gleiche mit gleicher
Funktionalität verglichen werden sollte und eine Ram- bzw. Sleep
Initialisierung nicht auf der Agenda äh "Spezifikation" steht. Macht
dann nach Adam Riese weniger als 200 Bytes verbrauchter Flash ;-)
> Mit Verlaub.> Das ist vollkommener Müll.
Du meinst weil klar ist, daß man es in C nicht kürzer gebacken bekommt?
> Die unterste Schmerzgrenze für Sensor Aktor Knoten sehe ich bei> adressierbaren Master Slave Feldbussen mit min. 16 Teilnehmern.
Bist Du von der Industrie? Dann wär mir alles klar. So einer muß die
überteuerten Preise dort irgendwie rechtfertigen. Schenk Dir das. Geht
alles viel simpler, viel billiger ;-)
A. K. schrieb:> Hab auch schon an ELIZA gedacht.
Da ist was dran ;-)
So wie ein großer Teil der C-Überzeugungstäter hier konstant weg von den
unangenehmen Fakten meines Projekts driftet müssen diese Leute konstant
auch wieder zurück zu den wunden Punkten (=Ressourcenverbrauch) geführt
werden. Da brauchts Eliza-gleiche Geduld ;-)
Johann L. schrieb:> Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm> findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und> komplett versagt?
Wer wird denn hier von Versagen reden? Der Vorteil simpler Codierung
ohne viel Bürokratie bleibt Asm dann immer noch. Nur die
Ressourcen-Geschichte hätte sich dann (für mich) erledigt. Du redest da
aber von Wunschträumen ;-)
Moby A. schrieb:> le x. schrieb:>> Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird>> wohl nix..>> Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott.> Ob mich daß bei Deinem Logik-Verständnis weiter oben überraschen sollte?> Na dann wenigstens Dankeschön für die (letzte) Live-Demo der> Sinnlosigkeit jeglicher wiederholter "Spezifikation". Oder?>> Markus M. schrieb:>>>> PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.>> Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige> Bruchwerk aber noch nirgendwo. Von konkreten Ressourcenverbrauchs-Fakten> ganz zu schweigen. Eine klassische serielle Schnittstelle wird von> meinem Code auch nicht bedient.>> P. M. schrieb:>> Also dieses wackelige Ding>> Langsam machst Du mit Deinen kompetenten Beobachtungen Carl D.> Konkurrenz...> Mein Code steht bombenfest, bewährt sich längst in der Praxis- aber Du> machst mir nicht den Eindruck, daß Du Dich damit jemals befasst hast> undoder ihn überhaupt verstehst. :-(>>> kein Wissen von erfahrenen Leuten einfliessen lässt>> Lass das mal in Deine C-Fassung einfließen. Da werd ich aber lange> warten. Dann dann zeigt sich schnell wer hier wen belehren müsste ;-)
Moby, falls du das Theater hier selber ernst nehmen solltest.:
Du bist der Einzige!
Ja, DER EINZIGE.
Welche Motivation sollte ein Leser hier haben, in seiner Freizeit ein
Programm zu schreiben, welches er niemals für irgend etwas einsetzen
wird? Ja, warum sollte er das wohl tun? Nur um über deine Stöckchen zu
springen? Deinen Ego Trip weiter anzuheizen?
Du bietest weder eine spannende Herausforderung noch sinnvolle Regeln.
Dein beabsichtigter Ram-und-Flash Kontest ist wenig Anspruchsvoll, um
nicht zu sagen einfach nur lächerlich. Du scheinst das nicht zu merken -
als Einziger.
Ich und auch kein anderer möchten dir den Erfolg deines privates
Projektes und seine Funktion in Abrede stellen. Es ist und bleibt ein
tolles Gefühl, selbst etwas auf die Beine gestellt und zum Laufen
gebracht zu haben. Doch stellt sich dann niemand hin und schwört auf die
Überlegenheit seiner Programmiermethode.
Wenn du Interesse an einer vergleichenden Betrachtung gehabt hättest,
wärest du den Bitten nach den Specs deines Projektes mit mehr Eifer
nachgekommen und hättest nicht auf deinen ASM Code verwiesen. Wissen wir
denn, ob der deine Specs überhaupt erfüllt? In der Schule haben wir
gelernt, dass jede Aufgabe über die Aufgabenstellung formuliert wird. Je
klarer die ist, umso weniger Streit gibt es bei der Interpretation der
Ergebnisse.
Lange Rede..
Wenn du wirklich Interesse hast, dann komm mit etwas vernünftigen, etwas
worüber sich die sach- und fachliche Auseinandersetzung für alle Seiten
hier lohnt.
Deinen Kinderspielchen sind hier alle schon längst erwachsen. Mir
scheint es, als ob selbst die fachliche Beurteilung der hier schon
gebotenen Lösungen oder Teillösungen deinen Horizont meilenweit
überschreitet. Zu keinem Ansatz hast du jemals Stellung bezogen. Warum
sollte also jemand etwas liefern? Wozu?
Du erwartest nur die nackte Programmgröße. Ich habe den Eindruck, dass
du damit im falschen Forum gelandet bist.
Wenn du das gleich wieder als Resignation vor der Aufgabe, Versagen der
C-Fraktion, Üblegenheit deiner Progammierkunst oder dergleichen
interpretieren wirst,.. es ist alles nur in deinem Kopf so..
..und ich programmiere auch fast alles in ASM - noch, weil ich mehr und
mehr von der Überlegenheit von C überzeugt bin und es deshalb lerne.
Nachdem ich die Antwort auf alle möglichen Fragen gefunden habe, hat man
einfach die Fragen geändert...
Nachdem ich alle Lösungen zu einem Problem gefunden habe, hat man das
Problem geändert.
Nachdem es keine Probleme mehr gab ... bin ich wieder zur
Maschinensprache zurück gekehrt ( smile nein, bin ich nicht
grundsätzlich ).
Das wäre jetzt so, als würde man mir sagen: Hey, schreibe absichtlich
wieder schier unwartbare Programme.
Witzig ist schlicht: alte Programmteile (egal ob in Pascal, Delphi oder
C) wie bspw. Interpolationsfunktionen, "Linearisierungen" von NTC
Widerständen, Funktionsparser konnte ich von meinen uralten zum Teil aus
C/PM Zeiten stammende Routinen relativ gut nach C portieren. Die meisten
Assemblerfunktionen nicht (okay, in Wirklichkeit war mir der Aufwand zu
groß und ich habs lieber neu geschrieben).
Es ist für mich sowas von unglaublich, dass man sich auf das Niveau von
Herrn M. herunterziehen lässt und seine "Anforderungsliste" übernimmt wo
es doch hunderttausende Vorzüge einer höheren Sprache (egal welche)
gegenüber ASM gibt. Wie kann man nur so verbohrt sein, seine
"Lieblingssprache" auf so extrem wenige (und sorry, wirklich relativ
triviale) Anwendungen zu begrenzen?
Die Welt... besteht nicht nur aus (von Herrn M. definierten) 8 Bit
Anwendungen.
Ein bestes Beispiel: ich bin hoch fasziniert von einem Mitglied hier,
der einen Softwaresynthesizer auf einem ATmega (und das in meiner
Meinung nach guten Qualität) hinbekommen hat (ehrliche Hochachtung
hierfür).
Viele Teile des Syntesizers sind in C geschrieben und nur die wirklich
zeitkritischen in Assembler.
Ich war/bin wirklich davon fasziniert. Dieses Teil Lehrlingen gezeigt
können diese meine Faszination (eigentlich zu Recht) nicht verstehen:
"Herr xyz, das ist ja schön und gut, aber auf unseren STM Nucleoboards
benötigt es hierfür keine Maschinensprache).
Was erwiedert man einer solchen Aussage? Nichts, denn sie haben schlicht
recht.
Würde ich ein Spielzeug entwerfen, dass ich was weiß wieviele 1000 mal
verkaufen würde, würde der Preis vllt. eine Rolle spielen und deshalb
wohl hierfür ein AVR eingesetzt werden, aber selbst in diesem Falle ist
der Hauptanteil in C geschrieben.
Ich würde gerne mal einen Softwaresynthesizer von Herrn M. sehen, der
komplett in ASM gemacht ist !!!
Hier wird extrem viel ohne Beweise behauptet und jetzt lasse ich mich
auf das gleiche ein:
Ich erkenne an, dass ASM so viel flexibler und einfacher ist, wenn Herr
M. einen Syntesizer schreibt (das sind jetzt Specs) die:
- min. 4 stimmige unterschiedliche Instrumente spielen können
- eine Mididatei die auf einem PC in ein beliebiges proprietäres Format
gewandelt werden dürfen und einem AVR über ein Nachladen von einer SD
Karte zugeführt werden
- der Rauschabstand nicht kleiner als 50 dB betragen darf (ich hoffe
dass Herr M. weiß was das ist)
Ich (und das nehme ich mir heraus weil ICH und nicht Herr M. die Specs
bestimmt) äußere: das ist eine 8 Bit Anwendung weil es auf einer 8 Bit
MCU läuft !
ASM hat gewonnen, wenn er dieses in 3 Wochen zum Laufen gebracht hat !
Ich verschärfe jetzt nicht in dem ich verlange, dass er den Code den er
erstellt hat nun auf einer anderen Plattform zum Laufen bringt (denn ich
will den auf AVR funktionierenden Code nicht nach STM32 portieren,
glaube aber, dass ich wohl doch in der Lage wäre das auch auf einem
Nucleo hin zu bekommen).
( ich glaube ich kann jetzt schon ein höhnisches Gelächter von Herrn M.
hören und ich glaube ich kann auch schon die Gebetsmühlenartig
vorgetragenen unsinnigen "Argumente" und "Forderungen" hören ).
Was ich wirklich nicht glauben kann ist, dass ich mich hinreisen lasse
und hier einen Kommentar schreibe. Aber irgendwie ist das wie mit der
Maschinensprache: Manche Dinge faszinieren ohne wirklich erkennbaren
Grund ... und hier ist es die Ignoranz).
Wenn Herr M. kein "Projekt" (ich sage mal, dass eine Minisensorplatine
einfach kein "Projekt" ist) veröffentlichen will (weil uns das ja
angeblich nicht "interessiert"), dann soll er doch mal wenigstens
erzählen, welches seiner Projekte, die er ja schon erarbeitet hat, 10
KByte groß sind (Hex-File) und was die jetzt alles in allem können !
Was .... wurde denn in so großer Menge schon realisiert und in welcher
Zeit?
Warum richten sich die "Diskutanten" nach den Anforderungen von Herrn
M., warum stellen sie nicht ihre eigenen Specs ?
Hier im Forum wimmelt es nur so von wirklichen Schätzen bei denen sich
manche Programmierer in C das Hirn verrenkt haben (smile, "nur" um etwas
in den nächstkleineren Controller zu bekommen)... Ich will sehen wie
Herr M. das schafft.
Immer dann, wenn gerechnet werden muß, immer dann wenn floating point
ins Spiel kommt, spätestens dann wird es mit ASM kritisch.
Gute Nacht
Markus M. schrieb:> ..und ich programmiere auch fast alles in ASM - noch, weil ich mehr und> mehr von der Überlegenheit von C überzeugt bin und es deshalb lerne.
... es geht nicht darum, was "überlegen" ist, es geht darum, mit welchem
Aufwand ein Problem bewältigt werden kann.
Entwicklerzeit = Aufwand.
Eliminiert ein geringerer Hardwarepreis einen höheren Entwickleraufwand,
wird eine preiswertere Hardware verwendet, ansonsten eben nicht !
Preis Reichelt (okay, nicht WIRKLICH zwingend Bezugsquelle Nr. 1):
ATtiny13 SOIC (1k Byte Flash / 64 Byte RAM) => 0,86 Euro
ATtiny85 SOIC (8k Byte Flash / 512 Byte RAM) => 1,30 Euro
Um wieviel länger darf ich da entwickeln, dass da noch etwas in den
Tiny13 passt ?
Also ehrlich, wäre es nicht mal an der Zeit mal an die frische Luft zu
gehen und einzuatmen und die schöne Natur zu bewundern. Mal Schifahren
zu gehen oder Eislaufen, oder sonst irgendetwas, aber nur nicht mit der
Elektronik verbunden. Da bekommt dann gleich eine andere Einstellung.
Wenn man den ganzen Tag vor dem Monitor sitzt, verblödet man doch fast
und frisst sich leicht in einer Furche fest.
Gut gemeint,
Gerhard
Moby A. schrieb:> Der Vorteil simpler Codierung> ohne viel Bürokratie bleibt Asm dann immer noch. Nur die> Ressourcen-Geschichte hätte sich dann (für mich) erledigt. Du redest da> aber von Wunschträumen ;-)
Der Vorteil der simplen Codierung ist für dich, dass du deine simplen
Programme auch ohne eine Hochsprache zu lernen gebacken bekommst.
Moby A. schrieb:> So wie ein großer Teil der C-Überzeugungstäter hier konstant weg von den> unangenehmen Fakten meines Projekts driftet müssen diese Leute konstant> auch wieder zurück zu den wunden Punkten (=Ressourcenverbrauch) geführt> werden.
Unangenehm ist lediglich dein infantiles Getue, weil nun nienamd mehr
mit dir spielen will.
Der Resourcenverbrauch in C ist in erster Line von dem abhängig, der vor
dem Rechner sitzt. Das ist in ASM nicht anders.
Falls du dir den Gefallen tust, und mal bischen C lernen würdest, wäre
das deine erste Erkenntnis.
Ich habe übrigens mal ähnlich verbockt auf C geschimpft. Grund war mein
Frust über die "kryptische Syntax". Ja, sicher wäre es einfacher
gewesen, ich hätte vor 30 Jahren damit begonnen. Stattdessen gab es da
auch für mich Z80 in ASM und OP-Code.
Das erste, was ich nach dem Kompilieren meiner C-Versuche mache, ist das
Untersuchen der ASM Ausgabe des Compilers. Und ehrlich, ich war
überrascht wie kurz und elegant der Compiler übersetzt. Tut er es mal
nicht, dann hat das seinen Grund im Quellcode. Er sieht dann etwas, was
ich übersehen, oder zumindest anders gemeint habe. Aber mit ÜVS wird das
ASM Listing immer kürzer und knackiger.
Gerhard O. schrieb:> Mal Schifahren zu gehen oder Eislaufen
Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf
gefallen dabei. :o/
Ich bevorzuge doch lieber Fortbewegungsmittel mit ordentlichen Bremsen.
:)
Viele Grüße nach Kanada, ist vermutlich kühler dort als hier.
Ralph S. schrieb:> Die Welt... besteht nicht nur aus (von Herrn M. definierten) 8 Bit> Anwendungen.
Da hast Du doch Recht!
Nur für diese rede ich aber hier.
Es sind aber immer noch Millionen...
Z.B. im großen Feld Smart Home.
Markus M. schrieb:> Du bist der Einzige!> Ja, DER EINZIGE.
Und Du meinst, eine solche Feststellung hätte irgend einen Wert als
fachliches Argument?
Mich beeindruckt das nicht, das Ablenkungs-Theater von der von mir
demonstrierten Asm-Effizienz hat aber einen gewissen Unterhaltungswert
;-)
> Welche Motivation sollte ein Leser hier haben, in seiner Freizeit ein> Programm zu schreiben, welches er niemals für irgend etwas einsetzen> wird? Ja, warum sollte er das wohl tun?
"Programm" ist erstens schonmal arg übertrieben.
Zweitens muß das niemand tun. Wer aber meinen Aussagen zu den
Ressourcenvorteilen von Asm überzeugend wiedersprechen will wird nicht
umhinkommen, dies an meinem bereits fertigen Projektchen durch die
Fakten einer C-Fassung zu belegen. So ein 200 Byte-Kaliber sollte für
die behauptet hochexpertiösen Protagonisten hochproduktiven C's wirklich
kein Problem sein ;-)
Jörg W. schrieb:> Gerhard O. schrieb:>> Mal Schifahren zu gehen oder Eislaufen>> Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf> gefallen dabei. :o/
Eislaufen ist heimtückischer wie Schifahren. Beim Schifahren hat man
viel mehr Möglichkeiten zur Korrektur.
>> Ich bevorzuge doch lieber Fortbewegungsmittel mit ordentlichen Bremsen.
Da hast Du auch wieder recht.
> :)>> Viele Grüße nach Kanada, ist vermutlich kühler dort als hier.
Nicht zu schlimm. Nur -6 Grad im Augenblick obwohl es in ein paar Tagen
sehr viel kühler werden soll(-20). Mit dem ganzen Schnee ist einer
weihnachtlichen Stimmung nichts im Wege gelegt. Schnee in den Bergen ist
reichlich und die Schifahrer sind Happy.
Viele Grüße nach D,
Gerhard
Markus M. schrieb:> Der Vorteil der simplen Codierung ist für dich, dass du deine simplen> Programme auch ohne eine Hochsprache zu lernen gebacken bekommst.
So simpel sind offensichtlich selbst 200 Byte Asm Programme nicht, sonst
hätten wir längst eine reelle C-Vergleichsmöglichkeit auf dem Tisch ;-)
Und ja doch, Asm ist simpel! Da gibts bei 8-Bit MSR keinerlei
Veranlassung auf Umständlicheres und Bürokratischeres und Komplexeres zu
wechseln!
Das spricht für Asm!
> Unangenehm ist lediglich dein infantiles Getue, weil nun nienamd mehr> mit dir spielen will.
Asm ist vergleichsweise infantil im Vergleich zu C.
Man kann auch sagen simpler ;-)
> Der Resourcenverbrauch in C ist in erster Line von dem abhängig, der vor> dem Rechner sitzt. Das ist in ASM nicht anders.
Klar gibts auch diese Abhängikeit.
Die interessiert hier aber nicht.
Hier gehts um objektive Mängel von Hochsprache.
Dokumentiert in sovielen C-Problemthreads.
Um mal einen aktuellen aufzugreifen:
Beitrag "Einstieg in C - komische Fragen"> Falls du dir den Gefallen tust, und mal bischen C lernen würdest, wäre> das deine erste Erkenntnis.
Die ersten "Erkenntnisse" sind in obigem Thread wunderschön beschrieben.
Ich komm geradezu ins Schwärmen ;-)
> Das erste, was ich nach dem Kompilieren meiner C-Versuche mache, ist das> Untersuchen der ASM Ausgabe des Compilers.
Das brauch ich nicht. Das hab ich zum Glück selber in der Hand.
> Und ehrlich, ich war> überrascht wie kurz und elegant der Compiler übersetzt. Tut er es mal> nicht, dann hat das seinen Grund im Quellcode.
Eleganz käme frühestens dann zum Tragen, wenn die Anzahl der Register
nicht mehr ausreicht. Das ist mit Übung, Vorbereitung und System noch
für viele viele KB AVR Code bei 8-Bit MSR kein Thema!
> Aber mit ÜVS wird das> ASM Listing immer kürzer und knackiger.
Nur leider nicht so knackig wie mit pure Asm ;-)
Von den vielen richtig zu bedienenden Stell- und Optimierschrauben in C
ganz abgesehen.
Moby A. schrieb:> So ein 200 Byte-Kaliber sollte für> die behauptet hochexpertiösen Protagonisten hochproduktiven C's wirklich> kein Problem sein ;-)
Ist es auch nicht.
Aber die beschäftigen sich lieber mit ernsthafteren Sachen.
Und "Resourcenverbrauch" verstehen die/wir nicht als Flashverbrauch.
Denn Flash verbraucht nicht. Er ist nach wie vor vorhanden. Und je
besser er genutzt wird, um so besser ist die Resourcennutzung. Und um
die geht es.
Die Resourcen "Flash" und "SRAM" durch maximale Kastration der Programme
nur unzureichend zu nutzen, stellt eine reine Resourcenverschwendung da.
Warum möchtest du einen professionellen Softwareersteller dazu bewegen?
Das Ergebnis wird weder besser noch schlechter, wenn es 2 Byte mehr oder
weniger Speicher belegt. Das ist der Punkt!
Markus M. schrieb:> Die Resourcen "Flash" und "SRAM" durch maximale Kastration der Programme> nur unzureichend zu nutzen, stellt eine reine Resourcenverschwendung da.
Du hast nicht verstanden, daß es mir um die prinzipiellen Vorteile von
Asm geht. Was konkret wie in der Praxis genutzt werden kann steht auf
einem anderen Blatt. Wenn Asm aber weniger Ressourcen erfordert (mit
ÜVS) ist das doch nur gut. Wenn die Programmierung mit der bloßen
Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC
geschehen kann umso besser.
> Warum möchtest du einen professionellen Softwareersteller dazu bewegen?
Irrtum. Ich möchte eigentlich selber überzeugt werden. Das ist hier
aber momentan auf einem ganz ganz schlechten Weg ;-)
Moby A. schrieb:> Asm ist vergleichsweise infantil im Vergleich zu C.> Man kann auch sagen simpler ;-)
Das darf und kann nur jemand beurteilen, das beide Sprachen
beherrscht.
Schon aus meiner Sicht ist deine Aussage falsch.
Moby A. schrieb:> Wenn die Programmierung mit der bloßen> Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC> geschehen kann umso besser.
Und genau das macht der C-Kompiler. Je nach Optimierungsstufe mal mit
Schwerpunkt Codelänge oder Ausführungsgeschwindigkeit.
Moby A. schrieb:>> Warum möchtest du einen professionellen Softwareersteller dazu bewegen?>> Irrtum. Ich möchte eigentlich selber überzeugt werden. Das ist hier> aber momentan auf einem ganz ganz schlechten Weg ;-)
Daran ist dein bisherriges Verhalten nicht ganz unursächlich.
Mein Rat: lerne ein bischen C und überzeug dich selbst. Dass du hier
professionelle Hilfe bekommen kanst, weißt du sicherlich auch. Du wirst
sehen, welch wunderbar kurzen und knackigen Code der Compiler produziert
bzw produzieren kann. Damit kannst du deine ASM Kenntnisse sogar noch
weiter ausbauen.
Und der Aufwand, das Programm nach deinen Wünschen umzugestalten ist
weitaus geringer als auf ASM Ebene. Das ist für mich ein entscheidender
Vorteil. Diesen bezahlst du aber keineswegs mit mehr Overhead oder
ähnlichem.
Vlt bringst du ja auch C nur in irgend einer Hinsicht mit Bascom in
Verbindung und beziehst daraus deine Vorurteile(?)
Markus M. schrieb:> Das darf und kann nur jemand beurteilen, das beide Sprachen beherrscht.
Das kannst Du gern so festlegen.
Mit C durfte ich durchaus schon intensiv Bekanntschaft schließen. Viel
aussagekräftiger sind aber entsprechende Problemthreads hier, wo mit
viel Erfahrung noch jeder Haken der Hochsprache zum Vorschein kam. Du
mußt doch nicht glauben, daß die Vorteile von C (z.B.beim Rechnen, beim
Handling größerer Datenmengen) mit Nix erkauft werden...
Die allerbeste Beurteilung der C-"Vorzüge" aber ist, daß sich hier
bislang keiner der sonst so sprachgewaltigen Experten imstande sieht,
ein kleinwenig Funktionalität in C zu coden. Natürlich weiß ich warum
;-)
Mit "lerne ein bischen C" hast Du bei mir keine Chance.
Da will ich schon mehr sehen!
Jörg W. schrieb:> Moby A. schrieb:> An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig.>> Deine Selbstüberschätzung ist einfach unübertroffen. :-)
Sollte mich das jetzt von irgendwas überzeugen?
Warum gehst Du nicht darauf ein was ich sagte?
Vielleicht, weils richtig war ? ;-)
Moby A. schrieb:> Wenn die Programmierung mit der bloßen> Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC> geschehen kann umso besser.
Noch was..
Geht es um das initialisieren der Peripherie, das setzen von Registern,
das Hin- und Herschieben von Registerinhalten, um Bitmanipulationen,
dann nehmen sich C und Hand-ASM nichts.
Wenn dem Controller aber eswas "Grips" eingehaucht werden soll, wenn
Berechnungen, die über einfachste Additionen hinausgehen implementiert
werden sollen, wenn skalierbare Datenstrukturen angelegt werden müssen,
Statemaschinen her müssen, oder das Programm einfach nur sehr
umfangreich wird, dann ist der Compiler in jeder Beziehung besser. Ihn
zu schlagen würde - wenn es überhaupt möglich wäre - einen enormen
Zeitaufwand verursachen.
Ich sehe in ASM mittlerweile keinerlei Vorteile mehr. Vertrau dem
Kompiler, kontrolliere seinen Output. Du wirst sehen, der verarscht dich
nicht und macht auch nicht heimlich Dinge die du nicht willst.
Jörg W. schrieb:> Selbst eine Implementierung in C müsste> notwendigerweise exakt den gleichen Assemblercode liefern, um akzeptiert> zu werden.
Wie kommst Du auf diesen ausgemachten Blödsinn?
Hinter solchen Aussagen scheint doch die nackte Angst durch: Wenn wir
unseren C-Compiler nicht zum gleichen Asm-Output bewegen können haben
wir verloren!!! ;-)
Moby A. schrieb:> Natürlich weiß ich warum> ;-)>> Mit "lerne ein bischen C" hast Du bei mir keine Chance.> Da will ich schon mehr sehen!
Mit dieser Einstellung wirtst du das niemals sehen.
Moby A. schrieb:> Du> mußt doch nicht glauben, daß die Vorteile von C (z.B.beim Rechnen, beim> Handling größerer Datenmengen) mit Nix erkauft werden...
Geglaubt wird in der Kirche ;-)
Die Vorteile werden nicht "erkauft". Sie resultieren aus der Fähigkeit
des Compilers, den "Überblick" auch bei noch-so-großen Datenmengen nicht
zu verlieren und jederzeit in wenigen Sekunden ein optimales Ergebnis zu
liefern.
Moby A. schrieb:> Die allerbeste Beurteilung der C-"Vorzüge" aber ist, daß sich hier> bislang keiner der sonst so sprachgewaltigen Experten imstande sieht,> ein kleinwenig Funktionalität in C zu coden. Natürlich weiß ich warum> ;-)
Nein, du glaubst es nur zu wissen. Warum das so ist, habe ich oben
dargestellt, und viele andere versuchen dir das auch klar zu machen.
N8
Markus M. schrieb:> Geht es um das initialisieren der Peripherie, das setzen von Registern,> das Hin- und Herschieben von Registerinhalten, um Bitmanipulationen,> dann nehmen sich C und Hand-ASM nichts.
Das ist richtig.
Das hatte ich ein paar Hundert Beiträge weiter oben auch schon
festgestellt.
> Wenn dem Controller aber eswas "Grips" eingehaucht werden soll, wenn> Berechnungen, die über einfachste Additionen hinausgehen implementiert> werden sollen, wenn skalierbare Datenstrukturen angelegt werden müssen,> Statemaschinen her müssen, oder das Programm einfach nur sehr> umfangreich wird, dann ist der Compiler in jeder Beziehung besser
Das ist ebenfalls richtig.
Das hatte ich ein paar Hundert Beiträge weiter oben ebenfalls schon
festgestellt.
> Ich sehe in ASM mittlerweile keinerlei Vorteile> mehr.
Das ist falsch.
Denn Du unterschlägst mal eben Millionen MSR-Anwendungen, die eben keine
aufwendigen Berechnungen und Datenstrukturen enthalten.
> Vertrau dem Kompiler, kontrolliere seinen Output. Du wirst sehen,> der verarscht dich nicht und macht auch nicht heimlich Dinge die du> nicht willst.
Dazu gilt es aber eine Bürokratie und Ineffizienz in Kauf zu nehmen, die
für obige Anwendungen nicht zwingend sind.
Moby A. schrieb:> Klar gibts auch diese Abhängikeit.> Die interessiert hier aber nicht.> Hier gehts um objektive Mängel von Hochsprache.> Dokumentiert in sovielen C-Problemthreads.> Um mal einen aktuellen aufzugreifen:
Ach Moby..
Diese Abhängigkeit ist _das Entscheidende!_ Und sie ist der Grund für
die sog. "Problemthreads"!! Sie resultieren nicht aus Unzulänglichkeiten
des Compilers oder der Sprache C!
Na klar hat man als Anfänger noch nicht den Überblick über alles!! Ja,
das ist in ASM alles einfacher, weil da kein Compiler zwischengeschaltet
ist.
Mit zunehmenden Lernerfolg wird man aber auf genau diese "Probleme"
sensibilisiert. Das Denken nimmt einem der Compiler nicht auch noch ab!
Und so weit, dass der Compiler weiß was der Mensch davor gemeint hat,
oder gar Kommentare liest, soweit sind wir noch nicht! Was erwartest du
eigentlich?
Moby A. schrieb:> Dazu gilt es aber eine Bürokratie und Ineffizienz in Kauf zu nehmen, die> für obige Anwendungen nicht zwingend sind.
Beweise das an konkreten Beispielen und stelle die Nachteile in
jeglicher Hinsicht nachvollziehbar dar.
Definiere den Begriff Nachteil, bewerte ihn in jeglicher Hinsicht.
Beweise, dass C überflüssigen Code produziert.
Belege die "Bürokratie" entsprechend mit Codebeispielen.
..oder schweige zu diesem Thema für immer.
Moby A. schrieb:> Das ist falsch.> Denn Du unterschlägst mal eben Millionen MSR-Anwendungen, die eben keine> aufwendigen Berechnungen und Datenstrukturen enthalten.
Millionen...
Nenn uns doch bitte mal zehn.
Markus M. schrieb:> Beweise das an konkreten Beispielen und stelle die Nachteile in> jeglicher Hinsicht nachvollziehbar dar.
Du kannst gerne an meinem fertigen Beispiel Deine besseren
C-Verbrauchsfakten demonstrieren ;-)
> Beweise, dass C überflüssigen Code produziert.
Obiges gelingt 1000 C-Experten nicht ;-)
> Belege die "Bürokratie" entsprechend mit Codebeispielen.
Dafür brauchts nichtmal Beispiele. Dafür langt schon ein Blick ins dicke
C-Buch ;-)
> ..oder schweige zu diesem Thema für immer.
Das könnte Dir so passen ;-)
Nichtsdestotrotz wünsch ich Dir maximalen Erfolg mit Deinem C.
So, jetzt kannst Du guten Gewissens schlafen gehen. Du hast alles
versucht ;-)
Moby A. schrieb:> Jörg W. schrieb:>> Selbst eine Implementierung in C müsste>> notwendigerweise exakt den gleichen Assemblercode liefern, um akzeptiert>> zu werden.>> Wie kommst Du auf diesen ausgemachten Blödsinn?> Hinter solchen Aussagen scheint doch die nackte Angst durch: Wenn wir> unseren C-Compiler nicht zum gleichen Asm-Output bewegen können haben> wir verloren!!! ;-)
Nö, ein gewisser Moby hat es genau so geschrieben. Das ist der Nachteil
schriftlicher Statements. Sie können jederzeit zu 100% rekonstruiert
werden. Das mit der nackten Angst (vor was auch immer) trifft eher dich.
> Obiges gelingt 1000 C-Experten nicht ;-)
Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu
korrigieren. Das ist nämlich dein eigentliches Problem: ein zementiertes
Weltbild, zumindest beim Thema "Programmieren von
MobySpartRam-Anwendungen". Andere machen das nur, wenn es knapp wird.
Wie schafft ihr es eigentlich hier im Forum nächtelang Tinte zu
verspritzen und dann am nächsten Morgen algorithmische Höchstleistungen
zu leisten? Ich könnte das nicht.
Ralph S. schrieb:> Das wäre jetzt so, als würde man mir sagen: Hey, schreibe absichtlich> wieder schier unwartbare Programme.
Da fehlt Dir einfach ÜVS ;-)
> Wie kann man nur so verbohrt sein, seine> "Lieblingssprache" auf so extrem wenige (und sorry, wirklich relativ> triviale) Anwendungen zu begrenzen?
Mein Beispiel ist zwar trivial, aber offensichtlich immer noch zu
kompliziert. Größere Asm-Programme aus meiner Feder hätten erst recht
keine Chance auf Vergleich- als einzig möglicher Beweismöglichkeit.
> Ich würde gerne mal einen Softwaresynthesizer von Herrn M. sehen, der> komplett in ASM gemacht ist !!!
Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig
kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und
rechenintensiv ist. Damit ziemlich ungeeignet für Asm.
> Ich verschärfe jetzt nicht in dem ich verlange, dass er den Code den er> erstellt hat nun auf einer anderen Plattform zum Laufen bringt (denn ich> will den auf AVR funktionierenden Code nicht nach STM32 portieren,> glaube aber, dass ich wohl doch in der Lage wäre das auch auf einem> Nucleo hin zu bekommen).
Ich brauch meine Anwendungen nicht portieren.
Da langt ein AVR auf ewig. Vor allem wegen Asm ;-)
> ( ich glaube ich kann jetzt schon ein höhnisches Gelächter von Herrn M.> hören und ich glaube ich kann auch schon die Gebetsmühlenartig> vorgetragenen unsinnigen "Argumente" und "Forderungen" hören ).
Was Du so alles hörst.
Für Beiträge wie den Deinigen sollte ich mir wirklich mal ein
Eliza-Programm zulegen, welches die Rahmenbedingungen meiner Aussagen
für alle Neuankömmlinge permanent wiederholt.
> Immer dann, wenn gerechnet werden muß, immer dann wenn floating point> ins Spiel kommt, spätestens dann wird es mit ASM kritisch.
Ja ja, das Rechnen wieder...
Hatte ich schon gesagt, daß mich bislang Floating Point und ähnliche
schlimme mathematische Dinge verschont haben? Daß mir mein Smart Home
automatisch zu Diensten ist muß irgend einen anderen Hintergrund haben
;-)
Moby A. schrieb:> Da fehlt Dir einfach ÜVS ;-)
Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen!
Wie soll man da am anderen Ende der Welt noch mitkommen...
Carl D. schrieb:> Nö, ein gewisser Moby hat es genau so geschrieben.
Na das zeig mir mal! Da bin ich aber jetzt gespannt!
Ich glaub ja Du willst mir irgendeine Deiner Aussagen oder
Interpretationen unterschieben ;-)
> Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu> korrigieren.
Ach so? Für viele windelweich faktenlose Beiträge hier langts aber?
Dabei hab ich doch gehört, daß C so hochproduktiv sein soll... Ach
stimmt ja: Ich bin ja der Einzige und die Gegenseite hat diese große
Erfahrung.
Oh, daraufhin muß ich wohl umdenken...
Was glaubst Du eigentlich korrigieren zu müssen?
Ein funktions-äquivalenter C-Entwurf ist verlangt.
Du wärst freilich der Letzte von dem ich das erwarten könnte. Stimmts?
Gerhard O. schrieb:> Moby A. schrieb:> Da fehlt Dir einfach ÜVS ;-)>> Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen!
Übung. Vorbereitung. System.
> Wie soll man da am anderen Ende der Welt noch mitkommen...
Da wird das Diskussionsthema auch nicht so relevant sein. Hier gehts um
deutsche Gründlichkeit ;-)
Wo bitte lauscht Du denn gerade?
Moby A. schrieb:> Gerhard O. schrieb:>> Moby A. schrieb:>> Da fehlt Dir einfach ÜVS ;-)>>>> Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen!>> Übung. Vorbereitung. System.>>> Wie soll man da am anderen Ende der Welt noch mitkommen...>> Da wird das Diskussionsthema auch nicht so relevant sein. Hier gehts um> deutsche Gründlichkeit ;-)> Wo bitte lauscht Du denn gerade?
Hallo Moby,
Danke für die Erklärung.
Ich lausche ganz aus der Ferne im Land der Holzfäller und Maple Syrup.
Edmonton, Alberta, Canada
Gruß,
Gerhard
P.S. Wer behauptet, daß wir in Kanada nicht gründlich sind?
Gerhard O. schrieb:> Edmonton, Alberta, Canada
Interessant.
Lohnt sich denn die Reise dorthin ? (frage ich mal als potentieller
Tourist).
Was interessiert Dich denn am Thema Asm vs. C ?
Moby A. schrieb:> Gerhard O. schrieb:>> Edmonton, Alberta, Canada>> Interessant.> Lohnt sich denn die Reise dorthin ? (frage ich mal als potentieller> Tourist).>> Was interessiert Dich denn am Thema Asm vs. C ?
Ganz ohne Frage. Wenn Du die Natur liebst, vor den Bären keine Angst
hast(;-))und Dir die Abwesenheit von vielen Menschenansammlungen nichts
ausmacht, kannst Du bei uns viel erleben. Ich verbringe meine Ferien
meistens in den Rockys an der Westküste mit Bergwandern und finde es
immer sehr erholsam. An sich findet man auch in kanadischen Städten
Sehenswerten, nur kann ich Edmonton zur Zeit nicht empfehlen weil bei
uns zur Zeit zu viel gebaut wird. British Columbia gefällt mir sehr gut.
Die Gegend um Vancouver ist recht toll. Man kann viel unternehmen. Die
Berggegend dort ist sehr beeindruckend. Die Nachbarschaft zwischen
Pazifischem Gewässer und den vollbewaldeten Küsten schafft viele
photogenische Momente.
Was interessiert mich am Thema?
Ich liebe die embedded uC Technik und bin beruflich und Hobbymäßig erwas
damit vorbelastet. ASM mag ich weniger und verwende es nur in kleinen
homöopathischen Dosen und nur wenn unbedingt notwendig. Abgesehen davon
befasse ich mich mehr mit PICs und nur ganz wenig mit AVRs. Bin also in
Deinen Augen ein hoffnungsloser C Programmierer;-)
Was soll ich zum Thread sagen? Ich finde es ist halt schon viel digitale
Tinte verbraucht worden...
Naja, wenn Du mich jetzt in die Ecke drängst, muß ich Eure
Standhaftigkeit und Gelassenheit bewundern. Mir persönlich ist es
innerhalb vernünftiger Grenzen eigentlich Wurscht wieviel Resourcen ein
Programm vebraucht solange die Vorgaben einwandfrei erfüllt werden. Auf
der Ebene des Mikroprozessors ist jedes Programm ganz gleich wie es
erstellt worden ist, nur Maschinensprache und das arme Würstchen muß den
Stuss den wir alle irgendwann schreiben, stur und sklavenhaft
abarbeiten. Wenn Mikros nur sprechen könnten...
In dem Sinne, noch eine gute Nacht,
Gerhard
Moby A. schrieb:> Besten Dank Gerhard für den touristischen Einblick in Deine Gegend. Die> kann es glaub ich mit meinem Bayern aufnehmen ;-)>> Gute Nacht aus D
Du bist aus Bayern? Von wo ungefähr? Die Chiemseegegend kenne ich noch
gut von früher her und auch Rosenheim mit dem großen K dort. Ich bin von
über der Grenze her, die Stadt mit der alten Festung und seiner
Heldenorgel die man auch gut über der Grenze in Bayern hört.
Guten Abend aus C
Jörg W. schrieb:>> Mal Schifahren zu gehen oder Eislaufen>> Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf> gefallen dabei. :o/
Da hat es wohl an Übung, Vorbereitung und System gefehlt...
Moby A. schrieb:>> Belege die "Bürokratie" entsprechend mit Codebeispielen.>> Dafür brauchts nichtmal Beispiele. Dafür langt schon ein Blick ins dicke> C-Buch ;-)
Hmm, die Assembler Handbücher sind meist dicker als der C-Standard, und
man braucht für jede Prozessorfamilie ein neues...
D.h. also Assembler ist viel bürokratischer als C - stimmt aus meiner
Erfahrung.
Moby A. schrieb:> Größere Asm-Programme aus meiner Feder hätten erst recht> keine Chance auf Vergleich- als einzig möglicher Beweismöglichkeit.
Oh man, hätten, könnten, würden, ... alles klar ;-)
Moby A. schrieb:> Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig> kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und> rechenintensiv ist. Damit ziemlich ungeeignet für Asm.
(Ironie an)
Wenn ASM doch ach so überlegen ist, dann kann es doch für gar nichts
ungeeignet sein (Ironie wieder aus)
Moby A. schrieb:
> Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig> kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und> rechenintensiv ist. Damit ziemlich ungeeignet für Asm.
Okay, Moby sagt uns also ganz offiziell:
Jede Software die man kaufen kann (unabhängig vom Preis ?) ist einem
selbst programmieren mit ASM vorzuziehen.
Muß daran liegen das kein Preis der Welt es rechtfertigt sich das in ASM
anzutun.
Man kann alles in ASM schreiben solange es nicht komplex (Definition ?),
datenintensiv (Definition ?) und rechenintensiv (Definition ?) ist.
Für jeden anderen Fall muß man dann eine zweite Programmiersprache
lernen und alles wegwerfen was man bisher in ASM dazu geschrieben hat.
Ja, lieber Moby, das ist so ungefähr die Einschätzung der großen
Mehrheit hier. Dann liegen wir doch garnicht so weit auseinander.
Was wir nur einfach nicht verstehen können ist warum man die
Beherrschung eines Werkzeuges bis ins Detail perfektionieren soll das
versagt sobald die Aufgabe größer wird, wenn man statt dessen die
gleiche Arbeit in ein Werkzeg stecken kann das auch große Aufgaben
stemmt.
In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten
möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen
läßt.
Laß uns diesen Müll doch mal entsorgen und ein tiny Sensorboard mit
einem vernünftigen Feldbuss definieren und einer Meßwertaufbereitung die
diesen Namen auch verdient. Einer wirklich tyischen 8bit MSR Aufgabe
eben.
Das setzt eine jede Fraktion in Ihrer bevorzugten Programmierspache um
und wir schauen mal wie dann das Ergebniss aussieht.
Jaja, ich weiß, kein Argument kann die Vorteile von ASM tangieren.
Deswegen wird auf gefährliche Argumente ja von Dir auch prinzipiell
nicht geantwortet.
Leider ist der einzige Vorteil von ASM nur noch das Du nichts anderes
kannst. Das ist aber etwas was nur Du ändern kannst.
Gerhard O. schrieb:> Wenn Mikros nur sprechen könnten...
Gottlob (darf ich als Atheist sagen!) quasseln die eben nicht soviel
Unsinn wie ihre Programmierer.
Bin froh, daß wenigstens die µC die Klappe halten.
Moby A. schrieb:>> - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden>> durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden)>> - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits>> - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits>> - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits>> - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits>> - Bit 20: DINP1-LOW>> - Bit 21: DINP2-LOW>> Ok.>>> - Bits 22-23: Checksumme über das Datentelegram>> - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in>> einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird>> Bit22= Bit 0 der Summe, Bit23= Bit 1 der SummeMoby A. schrieb:> Markus M. schrieb:>> Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle>> Schnittstelle.>>>> PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.>> Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige> Bruchwerk aber noch nirgendwo.
Mich würde brennend interessieren, wie Du diese 2 Punkte von Dir
verifizierte Anforderung in dem Kryptischen und Komplexen Assembler
umsetzen würdest. Ich habe bereits dies in C umgesetzt, also darf ich
doch auch von Dir erwarten dass Du mit einer konkreten Lösung diese
Teilaufgabe auch als Gegenpart in Assembler zur Schau darstellst.
Schließlich bist du ja einverstanden gewesen mit den Spezifikationen.
Hier mein Code:
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Wenn Du mal hier den Teil erstellst, dann können wir auch gerne den Rest
der Anforderung auch umsetzen (in C / ASM).
Da Du ein Meister von Ausreden bist kann ich wohl nichts erwarten,
schade :-(
Lothar M. schrieb:> Leute, durchhalten! Zusammen wir schaffen das! ;-)> Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Eben deswegen hängen wir uns doch richtig rein.
Lothar, das machen wir nur für Dich.
Ich gönne Moby außerdem nicht das letzte Wort.
Ach Jungs,
ihr könnt machen was ihr wollt. Dem Moby interessiert das alles nicht.
Zusammenfassung:
Moby hat ein ASM Programm auf einem Tiny13.
Die Anforderungen stehen mittlerweile fest.
Nur sein Programm zählt. Nix mit Ausgabe an serieller Schnittstelle,
Fedlbus, anderer MC usw.
Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein
SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus
der ISR.
Nicht mehr und nicht weniger. Ihr könnt schreiben was ihr wollt. Er wird
sich immer auf sein ASM Programm beziehen.
>Gewonnen habt ihr ...
ja, wenn jemand ein C-Programm schreiben würde, dass ... usw. usw.
erfüllt, hätte man Gewonnen
wie weiter oben schon festgestellt wurde,
heißt das im Umkehrschluss nicht dass wenn keiner mitmacht, Moby
gewinnt..
Werner P. schrieb:> Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein> SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus> der ISR.
Ich lache mich immer schlapp wenn ich "SRAM" lese.
Beim STM32 habe ich 64KB CCM RAM und nach einiges an BACKUP-RAM. Also
brauche ich da den SRAM niemals belegen GRINS
Lothar M. schrieb:> Leute, durchhalten! Zusammen wir schaffen das! ;-)> Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn"Ralf G. schrieb:> Wobei...: Der Ringrichter wettet auf den Verlauf des Kampfes?! ;-/
Robert L. schrieb:> Moby> gewinnt..
ehrlich gesagt ist mir das Sch...egal ob Moby gewinnt oder nicht.
Der Typ hat sowas von einen beschränkten Horizont. Labert laufend von
ÜVS und wie toll ASM ist. Kreischt wie ein kleines Kind: "Du darfst kein
SRAM verwenden!". usw. usw.
Kindergarten halt.
Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer
sein Programm locker in 30 Minuten programmiert. Klar wird dann SRAM
verwendet und eventuell mehr Flash.
ABER WEM INTERESSIERT DAS?
EDIT: Aber irgendwie lustig ist der Thread schon ;-)
Werner P. schrieb:> Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer> sein Programm locker in 30 Minuten programmiert. Klar wird dann SRAM> verwendet und eventuell mehr Flash.
Meine Rede.
Ich behaupte sogar, dass 10-15min realistischer sind.
Den größten Aufwand drüfte das Heraussuchen der ADC- und Timer-Register
aus dem Datenblatt sein und das aufpriemeln der Bits.
Allerdings wird im ersten Schuss zwangsläufig RAM benutzt, ja mei, ist
halt so, und eventuell ein paar Bytes mehr Flash.
Könnte man alles trotzdem irgendwie hinpfuschen. Der gcc gibt einem ja
viele Möglichkeiten:
- Den StartUp-Code könnte man weglassen oder anpassen, RAM muss ja
keiner initialisiert werden, denn SP kann man zur Not selbst
initialisieren.
- die main() deklariert man als "os_main"
- die ISR deklariert man "naked"
- dann gibts noch den "register"-qualifier
- und wenn man mal die Doku durcharbeitet findet man bestimmt noch mehr
Ansatzpunkte um den Compiler in die gewünschte Richtung zu zwingen
Aber das hat dann halt wirklich nur noch sportlichen Wert, Aussagekraft
über Vor- oder Nachteile hätte so ein Programm dann nicht mehr.
Man hätte dann wirklich nur gezeigt dass die Erfinder von C und die
Entwickler des gcc genug Flexibilität vorgesehen haben um jede noch so
abstruse Forderung erfüllen zu können.
Wenn ich aber die geforderte Funktion in 10min umsetzen kann, jeder den
Code sofort versteht und dafür nur 5% mehr Flash/RAM verbraucht werden
als bei der hochoptimierten, alle Kniffe nutzenden , nicht mehr
erweiterbaren ASM-Lösung wär das für mich schon ein Punkt für die
C-Lösung.
Und ich vermute mal, für 99% der Anwesenden hier auch.
>ehrlich gesagt ist mir das Sch...egal ob Moby gewinnt oder nicht.
also mir nicht
ich fände das Super wenn er Gewinnen würde und allen hier aufzeigen
würde wie es Richtig geht..
wenn er sein git/svn repository von seiner SmartHome Zentrale (read
only) zur Verfügung stellen würde..
wo man sieht wie er Schritt für Schritt, mit System um Eleganz und Top
dokumentiert das Programm erweitert hat..
Wie einfach und übersichtlich dort alles ist, wie jedes Byte Flash 3 mal
umgedreht wurde und jedes byte RAM soweit möglich eingespart wurde..
Moby A. schrieb:>> Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu>> korrigieren.>> Ach so? Für viele windelweich faktenlose Beiträge hier langts aber?
Faktenlose Beiträge? Ich denke wir haben dir aus allen denkbaren
Perspektiven erklärt und belegt, was Sache ist. Du überliest es aber
geflissentlich, oder erfindest neue Argumente, warum es nicht gelten
soll. Neue Fakten braucht es da nicht mehr, es geht einzig und alleine
noch darum, dir zu zeigen, wie absurd deine Haltung ist. Und ja, den
Klassendepp mit seinen Ideen noch ein wenig aufziehen ist halt
unterhaltsam :-)
le x. schrieb:> Und ich vermute mal, für 99% der Anwesenden hier auch.
genau so ist es. Nur einer rafft das halt nicht.
Eigentlich war ja der Thread: Assembler wieder auf dem Weg nach vorn
von mir aus ist Assembler auf dem Weg nach vorn. Kann mir nur nicht
vorstellen dass im professionellen Bereich von C hin zu ASM gegangen
wird. Und selbst im Hobbybereich kann ich es mir nur schwer vorstellen.
Aber das ist jetzt meine Meinung.
Einen AVR und fast jeden anderen MC kann ich in C und oft auch in
anderen Hochsprachen programmieren. Ist doch toll. Jeder sucht sich
seine Sprache aus.
Früher hat mich C auch abgeschreckt. Aber mittlerweile finde ich C
einfach nur gut.
Aber jedem das womit er glücklich wird.
Moby A. schrieb:> Für viele windelweich faktenlose Beiträge hier langts aber?> Dabei hab ich doch gehört, daß C so hochproduktiv sein soll...
Deine Behauptung vom fetten C ist und bleibt deine private,
vorgefertigte Meinung, möge ÜVS mit dir sein. Wie viele C Umsetzungen
brauchst du, um sie zu überdenken?
Ich hänge noch mal mein PIC12F675 XC8 FREE Projektchen an. Ich habe es
an deine allerneueste Anforderungsliste angepasst mit dem Ergebnis: das
Compilat hat 198 Maschinenbefehle - auf einer archaischen MCU, die: nach
allgemeiner Lehrmeinung für C ungeeignet ist, nur ein Arbeitsregister,
35 Instruktionen, zerkluftete Achitektur und noch nichtmal freilaufende
ADC hat. Also müsste es mit deiner ÜVS ein klacks sein, das Projekt auf
einer modernen AVR MCU in <100 Befehlen zu implementieren. Sonst schicke
ich dein Projekt an die Mythbuster ;-)
Matthias L. schrieb:>>> 200Bytes => Verloren
Je nee ist klar.
Gegen einen so meilenhoch überlegenen Gegner zu verlieren ist doch keine
Schande. Jetzt gibt doch bitte endlich dem Moby seinen verdienten
ÜVS-Orden!
Witkatz :. schrieb:> Jetzt gibt doch bitte endlich dem Moby seinen verdienten> ÜVS-Orden!
Nicht bevor Lothar seine Wette gewonnen hat.
Bis dahin zählt jeder Beitrag, auch Mobys.
Geht ja zum Glück schon lange nicht mehr um Inhalte.
Zur Not Verteile ich etwas Katzenfutter auf der Tastatur um die letzten
Beiträge voll zu bekommen.
Inhaltsärmer als ÜVS kann das auch nicht mehr sein.
Michael K. schrieb:> Geht ja zum Glück schon lange nicht mehr um Inhalte.
Ja siicher! Es geht immer nur um "Assembler wieder auf dem Weg nach
vorn"
Ausserdem ist das Wachstum dieses inhaltslosen Threads ein
unwiderlegbarer Beweis für die Expansion des Universum.
Also in dem Sinne. Möge ÜVS mit Dir sein!
Moby A. schrieb:> Clemens M. schrieb:>> Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu>> haben ist Moby irgendwie wirklich verzweifelt....>> Du solltest besser am RAM-Bedarf eines C-Compilers verzweifeln. Scheint> ja ein fetter Pferdefuß des fetten C zu sein.
Beziehst du dich bei deinen fetten Behauptungen auf die fette SPRACHE C
im fetten Allgemeinen oder auf eine bestimmte fette C-Implementation
vulgo: fetter C-Compiler?
Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE
Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code,
d.h. dass es fett UNMÖGLICH ist, mit einem hypotetischen fetten
C-Compiler besser als mit fettem Assembler zu sein?
Falls du dich auf eine fette KONKRETE IMPLEMENTATION beziehst wie
fett-gcc, so liefert ein damit fett compiliertes fettes Programm nur
eine fette UNTERGRENZE für die fette Effizient von C, aber KEINE
OBERGRENZE derselben — und das auch nur für den fetten Fall eines
bestimmten fetten C-Programms, das mit einer bestimmten fetten Version
eines bestimmten fetten Compilers mit bestimmten fetten Optionen
übersetzt wurde.
Gehts dir also um fettes fette Compiler-Bashing?
Oder um fettes Bashing einer fetten Sprache und dem fetten Nachweis,
dass die fette Effizienz NIEMALS über einer bestimmten fetten Grenze
liegen kann?
Musst fett entschuldigen, wenn ich fett ein paar fetts vergessen hab...
Johann L. schrieb:> Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE> Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code,> d.h. dass es fett UNMÖGLICH ist, mit einem hypotetischen fetten> C-Compiler besser als mit fettem Assembler zu sein?
Um die Diskussion zu gewinnen, müsste Moby genau das tun. Er müsste
nachweisen, dass compiliertes C nicht effizienter sein kann als direkt
in Assembler geschriebener Code. Oder dass es zumindest für eine gewisse
Klasse an Problemen keine solchen gibt.
Ich 'jammer' noch mal. Obwohl es wahrscheinlich nur Moby schafft in
meinem post unfassbar weit oben auf gejammer zu schließen.
Du bist ja extrem stolz auf dein Programm. Geschenkt. Ist ein schönes
Programm - per inline asm auch in c portierbar. Glückwünsch.
Angenommen es würde wirklich jemand den von dir gewünschten Wettkampf,
genau DIESES Ding in c "besser" zu programmieren, was genau sollte da
raus kommen? Du hast EINEN Pfeil im Köcher. Dein sagenumwobenes
Programm. Um damit auf eine generelle Aussage wie "....die allgemeinen
Vorteile von asm...." zu kommen, musst du wenigstens noch einen zweiten
Treffer landen. Karl Heinz hat die ein Angebot unterbreitet, was dir
augenscheinlich Angst gemacht hat.
Weil das fast jeder versteht und dein Programm so unbedeutend für die
Sache ist, kannst du dir deine Tastatur kaputt hacken in dem Thread.
Wenn es dir ein gutes Gefühl gibt und irgendwie terapeutischen Nutzen
hat sei es dir gegönnt.
Aber ich -hoffe- du bist dir selber im klaren, dass du nicht auf der
Gewinnerstrasse bist. Weder mit deinen Resultaten, noch mit deiner
Argumentation (wenn ich deine posts mal so nennen mag)
Folgendes zu sagen würde bestimmt jeder akzeptieren:
-Einen Mini Code bis maximal 1 kB kann man händisch in asm noch besser
optimieren als in c. Wenn man viel Erfahrung hat wohlgemerkt. Wenn viel
Interrupt Last dazu kommt vielleicht noch besser. Das Resultat in c ist
dafür recht problemlos portierbar.
-Es macht zugegeben aber auch Spaß als Hobby solange Bits zu schubsen
bis man selber zufrieden ist und mit Papier und Bleistift Computer zu
spielen. Es macht aber auch Spaß als Hobby eine abstraktere Codierung zu
wählen und sich stattdessen um Algorithmen und Mathematik zu kümmern.
-Von einem minimalistischen Code auf eine allgemeine Aussage zu kommen
asm sei c überlegen ist Schwachsinn.
-Ich kann mit meiner asm Codebasis auch größere Projekte zusammendübeln.
Ich muss aber auch eingestehen, dass eine Maschine dabei den Überblick
besser waren kann und eine Maschine dabei die Planung und Vorbereitung
variabel halten kann...was schnell zum Vorteil gereicht.
Ich glaube aber auch, dass ich nach Monaten oder Jahren der Benutzung
von c auch DORT eine gewisse Codebasis anhäufe auf die ich dann
zurückgreifen kann....... Kannste dir doch bestimmt irgendwie vortellen
oder?
-Die verschwenderische Programmierung auf dem PC, die z.B. Adobe
hinbekommt ist lästig nervig und steht auf einem ganz anderen Blatt und
hat gar nix mit dem diskutierten Problem uc zu tun. Die ist bescheuert
und nervt wohl fast jeden. Auch wenn die Programmierer in den Branchen
bestimmt erklären können dass das modern und zudem egal ist.
Das Visual Studio was du zum asm Programmieren benutzt ist z.B. auch so
ein Software gau.
-(...)
Ich hoffe du nimmst dich in Wahrheit nicht so ernst wie du tust und
glaubst dein krudes Geschreibe wirklich. Dann hast du irgendwie ein
Logik Problem. Oder sonst irgendein Problem.
Was spricht dagegen deine Windmühlen mal rational zu betrachten wie oben
skizziert?
Habe noch mal quer gelesen und möchte dir zugestehen, dass du
tatsächlich unter irgendwas pathologischem leidest.
Selektive Wahrnehmung wäre so was. Lies noch mal nach: viele warten
sicher noch auf Antworten auf gechriebene Punkte.
Johann L. schrieb:> Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE> Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code
Was interessiert mich hier jede denkbare C-Umsetzung?
Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation.
Vom Ressourcen-Bedarf her und mit der fetten C-Bürokratie, die ja wohl
immer zur Anwendung kommen muß erst recht.
Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage
wiederspricht und ich mich reuevoll korrigieren muß.
Drehe nur ein bischen an den tausend kleinen optimierenden
C-Stellschrauben, dann sollte daß doch fett klappen, oder?
Fett eingeschüchtert in der Ecke kauernd hast Du mich schon ;-)
> Musst fett entschuldigen, wenn ich fett ein paar fetts vergessen hab
Kein Problem. C hat sicher noch andere fette Pferdefüße, die mir gerade
nicht in den Sinn kommen oder noch gar nicht bekannt sind ;-)
Mit fetten Grüßen!
Clemens M. schrieb:> Habe noch mal quer gelesen und möchte dir zugestehen, dass du> tatsächlich unter irgendwas pathologischem leidest.
Kenn ich schon. Läuft wieder der Beleidigungsschiene.
Da bin ich aber inzwischen dermaßen von was abgehärtet... ;-)
> Selektive Wahrnehmung wäre so was.
Wenn Du das pathologisch nennst ist es ein Massenphänomen.
Dich natürlich ausgeschlossen ;-)
> Lies noch mal nach: viele warten> sicher noch auf Antworten auf gechriebene Punkte.
Natürlich Clemens. In der Nacht hab ich wieder Zeit zur netten
Unterhaltung. Also bis bald!
Moby A. schrieb:> Johann L. schrieb:>> Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE>> Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code>> Was interessiert mich hier jede denkbare C-Umsetzung?> Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation.
Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE
C-Umsetzung.
> Vom Ressourcen-Bedarf her und mit der fetten C-Bürokratie,> die ja wohl immer zur Anwendung kommen muß erst recht.
Nein, C als Sprache kennt weder Flash noch Register noch Stack oder
Schalter.
> Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage> wiederspricht und ich mich reuevoll korrigieren muß.
Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine
C-Implementation, und die darf ich wählen wie ich will?
Oder geht's dir nur um Compiler-Bashing?
D.h. du hast mal — ohen C zu können — irgend nen Text von einen
C-Compiler übersetzt bekommen, und dann nen Blutsturz bekommen weil der
2 Bytes mehr verbraucht hat?
> Drehe nur ein bischen an den tausend kleinen optimierenden> C-Stellschrauben,
C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler.
Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln?
Nee eine Beleidigungsschiene ist das nicht. Soll es jedenfalls nicht.
Da du aber ganz offensichtlich fast 2000 Posts gar nicht wirklich
Argumente oder Programm(e!) austauschen willst dachte ich, dass du etwas
Galgenhumor bei deinen Kollegen in diesem Thread erwartest.
Und, ja, du hast eine mir fast unangenehme Ader, taub und blind zu sein
wenns dem Vorteil gereicht.
Du bist aber schon technisch interessiert? Also nicht dass du irgendwie
deine Bachelor Arbeit in Psychologie schreibst während wir hier
Serverplatz verbrauchen.
>Dich natürlich ausgeschlossen ;-)
Erklär mir doch mal wo ich dir Unrecht tue oder einfach Aussagen
ignoriere. Was sagst du zu meinen Konsens-Stichpunkten?
Moby A. schrieb:> Was interessiert mich hier jede denkbare C-Umsetzung?> Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation.
Also, hopp, beweis es! Komm! Beweis es! Beweis es oder höre auf mit
solche Behauptungen!
Ach Leute, hört halt auf diesen asm Troll mit unendlich Futter zu
versorgen.
Seit 2000 Seiten hat unser Moby
- gerade mal ein Projektchen mit gut 20 Zeilen gezeigt. Der Rest ist
Angeberei.
- offensichtlich keine Ahnung von C und einem C compiler.
- rudimentäre bis wenig Kenntnisse in Asm (Stichwort EOR ;-) )
- alle chancen was zu lernen verpasst
- alle Angebote zu einem fairen Vergleich aus Angst zu verlieren
abgeblockt
- sich mit bescheuerten Argumenten lächerlich gemacht (Stichwort ÜVS)
- keine Ahnung wie lächerlich er sich bisher gemacht hat (das ist wohl
das komischste am Thread)
- sich hundert mal selber widersprochen
- immer wieder jemand gefunden der ihn offensichtlich ernst nimmt (warum
auch immer)
- die mit Abstand meisten downvotes in diesem Forum kassiert ;-)
Gu. F. schrieb:> Seit 2000 Seiten
Nein, noch nicht ganz.... ;-)
> Seit 2000 Seiten hat unser Moby> ... grausig lange Aufzählung ...
Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist
keinen müden Cent billiger. Und der braucht auch nicht weniger Strom.
Und er ist auch nicht leichter.
Das Einzige, was passiert, ist dass die hocheffiziente und RAM-sparende
Appliktation ein halbes Jahr zu spät an den Markt kommt und sie dann
keiner mehr will.
> - immer wieder jemand gefunden der ihn offensichtlich ernst nimmt> (warum auch immer)
Ist ja klar: keiner kann die 1886 Posts alle lesen und so erkennen, dass
Alles, schlicht Alles schon einmal gesagt wurde...
Moby A. schrieb:> Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage> wiederspricht.
Hab ich doch längst, s.o. Mein Fazit:
Mit ÜVS bleibt C bei kleinen 8bit Aufgaben genauso schlank wie ASM!
So! Das schreibst du jetzt 100 mal reuevoll ab - und zwar mit printf!
Wenn mit ÜVS sowas raus kommt :
> Eine Checksumme die so schwach ist das ich würfeln kann ob die Werte> wirklich stimmen.> Völlig ineinander verwurstelte Daten die ich am Zielsystem erst wieder> auseinandernehmen muß um was damit machen zu können.> Eine synchrone unidirektionale Punkt zu Punkt Verbindung bei der im> Zeitlupentempo Daten übermittelt werde statt ein vernünftiger Feldbuss> mit Master / Slave Protokoll und starker CRC.> Den Teil wo die Entprellung der digitalen IOs stattfindet oder die> Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden> können.
dann möchte ich bitte sofort gegen ÜVS geimpft werden.
Scheint den kognitiven Fähigkeiten ziemlich übel mitzuspielen.
Lothar M. schrieb:> Ist ja klar: keiner kann die 1886 Posts alle lesen und so erkennen, dass> Alles, schlicht Alles schon einmal gesagt wurde...
... nur noch nicht von jedem.
Ja, auch das wurde schon gesagt :-)
Lothar M. schrieb:> Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist> keinen müden Cent billiger. Und der braucht auch nicht weniger Strom.> Und er ist auch nicht leichter.
Vielleicht liegt es Moby ja da dran:
In einem bekannten ASM seine Frickelprogrämmchen stur nach ÜVS
schreiben,
händisch durchorgeln, "optimieren", eindampfen etc.
Nach dieser Optmierung wird dann Atmel angeschrieben und ein Tiny 9,85
bestellt. Die Codegrösse ist dann ja bekannt.
Bei echter Stückzahl gehen die bei Atmel bestimmt drauf ein ;)
>Bei echter Stückzahl gehen die bei Atmel bestimmt drauf ein ;)
Ja. Sie verkaufen im einen Tiny13 mit anderer ID, wo im Atmel-Studio
jeder Zugriff auf auf FLASH-Zellen über Adresse 9,85k geblockt wird mit
er Info:
"Zugriff nicht möglich, da gespart mit ÜVS"
Markus M. schrieb:> Oder mit reduziertem ASM Befehlssatz die mittels ÜVS ermittelt wurden.
Gerade der Verzicht auf EOR könnte einige Gatter in der ALU einsparen.
Carl D. schrieb:> Gerade der Verzicht auf EOR könnte einige Gatter in der ALU einsparen.
Aber nicht viele. Weil identisch mit Addition ohne Übertrag.
Beim Multiplier lohnt es eher, aber den hat sein geliebter 13er ohnehin
nicht. Oder den halben Registersatz indem etwas mehr billiges RAM
genutzt und teure Register einspart werden.
Matthias L. schrieb:> im Atmel-Studio> jeder Zugriff auf auf FLASH-Zellen über Adresse 9,85k geblockt wird
Kann man das nicht mit einem ÜVS Fuse regeln? Beim Abschalten des ÜVS
Fuse müssen aber unbedingt Schockbilder vor der fetten Bürokratie
warnen.
Warum Übung, Vorbereitung und System Assembler so stark machen können
und ihn viele C-Programme vom Ressourcenbedarf her schlagen lassen wird
wohl manchem Comedian im Thread über mir auf ewig verschlossen bleiben.
Da wird lieber weiter mit C auf den Controller eingeprügelt bis wieder
mal dessen Schuhgröße oder gar gleich die ganze Architektur gewechselt
werden muß. Das ist natürlich insofern komfortabel als C angeblich so
schön portabel ist... um sich dann mit kleinen Hardwareänderungen und
dem Neulernen einer Architektur, dem Anpassen der Entwicklungsumgebung
und den Tausend Optimieroptionen die Nächte um die Ohren zu schlagen ;-)
Gerhard O. schrieb:> Du bist aus Bayern? Von wo ungefähr?
Von dort wo der Inn wieder Deine alte Heimat berührt ;-)
Moby A. schrieb:> Da wird lieber weiter mit C auf den Controller eingeprügelt bis wieder> mal dessen Schuhgröße oder gar gleich die ganze Architektur gewechselt> werden muß. Das ist natürlich insofern komfortabel als C angeblich so> schön portabel ist... um sich dann mit kleinen Hardwareänderungen und> dem Neulernen einer Architektur, dem Anpassen der Entwicklungsumgebung> und den Tausend Optimieroptionen die Nächte um die Ohren zu schlagen ;-)
Wo hast du das denn her? Aus der Bildzeitung? Das zeigt nur, daß Du
allen Unsinn nachplapperst und keine Ahnung hast....
Im übrigen wunderts mich, daß jemand, der von Assembler so überzeugt
ist, eine IDE zum Entwickeln benutzt...
Bernhard M. schrieb:> Hmm, die Assembler Handbücher sind meist dicker als der C-Standard, und> man braucht für jede Prozessorfamilie ein neues...
Die Auflistung aller Instruktionen ist schnell erledigt, deren
Verständnis auch. Kein Vergleich mit C.
Wenn man dann bei 8-Bit MSR Apps bei seiner Architektur bleiben kann
dann auch wegen Asm.
Michael K. schrieb:> Jede Software die man kaufen kann (unabhängig vom Preis ?) ist einem> selbst programmieren mit ASM vorzuziehen.
Das Selbstprogrammieren mit Asm macht zunächst mal auf kleinen 8-Bit
Controllern Sinn! Dort gibts auch wenig zu kaufen.
> Was wir nur einfach nicht verstehen können ist warum man die> Beherrschung eines Werkzeuges bis ins Detail perfektionieren soll das> versagt sobald die Aufgabe größer wird
Mit ÜVS versagt Asm bei 8-Bit MSR Aufgaben so schnell nicht.
> In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten> möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen> läßt.
So edel optimiert muß Software auf einem kleinen Controller aber
ausschauen! Sparsamer Verbrauch, Kapselung der Funktionalität, einfache
Erweiterbarkeit.
> Laß uns diesen Müll doch mal entsorgen
Müll ist, was Du statt dessen für die Aufgabe, die mein kleines
Sensorboard erfüllen soll vorschlägst:
> tiny Sensorboard> mit einem vernünftigen Feldbuss definieren und einer Meßwertaufbereitung> die diesen Namen auch verdient.
Völlig unnützer Aufwand. So überdimensioniert bürokratisch wie
bücherfüllendes C gegenüber Asm ;-)
Markus M. schrieb:> Mich würde brennend interessieren> Wenn Du mal hier den Teil erstellst
Ist ja nett. Ich habe für meinen Teil und für diesen Thread genug
erstellt. Weitere Mühen lohnen eher nicht, wenn ich das Ergebnis des
Threads so betrachte.
Nun will ich für meine Vorlage kürzeren C-Code sehen den ich kompilieren
und testen kann.
> Da Du ein Meister von Ausreden bist
Ja ja, die lieben Ausreden.
Ich komm mir wie ein Kämpfer gegen einen übermächtigen C- Drachen vor,
dessen Köpfe voller Ausreden ständig nachwachsen. Mein scharfes
Laserschwert in Form fertigen, für jeden nachvollziehbaren Codes kann
ich gar nicht so schnell schwingen ;-)
Werner P. schrieb:> Ach Jungs,>> ihr könnt machen was ihr wollt. Dem Moby interessiert das alles nicht.>> Zusammenfassung:>> Moby hat ein ASM Programm auf einem Tiny13.> Die Anforderungen stehen mittlerweile fest.>> Nur sein Programm zählt. Nix mit Ausgabe an serieller Schnittstelle,> Fedlbus, anderer MC usw.>> Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein> SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus> der ISR.>> Nicht mehr und nicht weniger. Ihr könnt schreiben was ihr wollt. Er wird> sich immer auf sein ASM Programm beziehen.
Hey, da hat einer die Situation ja seeehr klar erkannt!
Genau. Ich beziehe mich auf harte Fakten! Die gilt es jetzt zu schlagen
und nicht darum, irgendwelchen Fantasien nachzuhängen ;-)
Moby A. schrieb:> Die Auflistung aller Instruktionen ist schnell erledigt, deren> Verständnis auch. Kein Vergleich mit C.
Die Auflistung der C Schlüsselworte und Operatoren ist dreimal so
schnell erledigt.
Moby A. schrieb:> Ich beziehe mich auf harte Fakten!
Auch Fakten, die dir nicht in den Kram passen?
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"Moby A. schrieb:> Ich komm mir wie ein Kämpfer gegen einen übermächtigen C- Drachen vor,> dessen Köpfe voller Ausreden ständig nachwachsen. Mein scharfes> Laserschwert...Moby A. schrieb:> Die gilt es jetzt zu schlagen> und nicht darum, irgendwelchen Fantasien nachzuhängen
Also was denn jetzt. Erst fantasierst du dir was über C zusammen und
dann willst du doch nicht Fantasien nachhängen...
So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer noch
nicht warum man mit C die Architektur wechseln müsste. Kein AVR kann da
zu klein sein, selbst wenn ich C-Anfänger bin. Es gibt also schlichtweg
keinen Grund die Architektur zu wechseln, egal ob Assembler oder C (bei
8-bit MSR mit SÜV). Damit fällt doch auch dieser pathologische Sparzwang
weg.
Ich programmiere schon mein ganzes Leben lang Assember (ESER-Rechner,
Z80, 8086, 68000) und auch C (+ diverse andere schöne Hochsprachen). Bei
Robotron haben wir in den 80ern mal versucht einen "16 auf 8 bit"
Crossassembler zu entwickeln, weil die Ressourcen beschränkt waren. Aber
so ein Gewese wie Moby hier veranstaltet...
kopfschüttel
Markus M. schrieb:> Ich lache mich immer schlapp wenn ich "SRAM" lese.>> Beim STM32 habe ich 64KB CCM RAM und nach einiges an BACKUP-RAM. Also> brauche ich da den SRAM niemals belegen GRINS
Ich muß auch grinsen: Wenn ich für (alle) Apps den einfachen,
unkomplizierten AVR nehmen kann!
Werner P. schrieb:> Der Typ hat sowas von einen beschränkten Horizont.
Beschränkt sind eher die Möglichkeiten, mit C effizientem Asm-Code bei
8-Bit MSR Konkurrenz zu machen ;-)
> "Du darfst kein> SRAM verwenden!". usw. usw.
Zu dumm daß es zu den zu vergleichenden Ressourcen gehört! Ich versteh
Deinen Frust.
> Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer> sein Programm locker in 30 Minuten programmiert.
Na dann mal los. Viel Funktionalität ist ja nicht (zu vergleichen).
> ABER WEM INTERESSIERT DAS?
Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher
abgeneigt ;-)
> EDIT: Aber irgendwie lustig ist der Thread schon ;-)
Na das ist doch auch schon was.
Ein bischen Schmiermittel braucht jedes ernste Leben.
Moby A. schrieb:> Wenn man dann bei 8-Bit MSR Apps bei seiner Architektur bleiben kann> dann auch wegen Asm.
Da hast Du wohl "kann" und "muss" verwechselt ;-)
Moby A. schrieb:> Kapselung der Funktionalität
bedeutet bei Dir:
für jeden Hühnerschiss einen anderen mc.
Das definiert der Rest der Welt irgendwie anders!
Moby A. schrieb:> Markus M. schrieb:>> Mich würde brennend interessieren>> Wenn Du mal hier den Teil erstellst>> Ist ja nett. Ich habe für meinen Teil und für diesen Thread genug> erstellt. Weitere Mühen lohnen eher nicht, wenn ich das Ergebnis des> Threads so betrachte.> Nun will ich für meine Vorlage kürzeren C-Code sehen den ich kompilieren> und testen kann.>
Mein Code lässt sich kompilieren, also nutze den.
Moby A. schrieb:> Ich muß auch grinsen: Wenn ich für (alle) Apps den einfachen,> unkomplizierten AVR nehmen kann!
(Alle) Apps, die es in Deinem Weltbild gibt, meintest Du wohl?
So wie Du hier über C und neue Architekturen redest, so haben die Leute
im Mittelalter übers Lesen und Schreiben geredet ... völlig
überflüssiger neumodischer Kram ;-)
Jay W. schrieb:> So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer> noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR> kann da zu klein sein
Hast Du eine Ahnung!
> Damit fällt doch auch dieser> pathologische Sparzwang weg.
Hier gehts nicht um Sparzwang oder Verschwendungssucht.
> Bei> Robotron haben wir in den 80ern mal versucht einen "16 auf 8 bit"> Crossassembler zu entwickeln, weil die Ressourcen beschränkt waren.
Interessant. Ich hab mit dem KC87 angefangen ;-)
> Aber> so ein Gewese wie Moby hier veranstaltet...
Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was
mich persönlich sehr interessiert. Danke für Deinen Beitrag, der dieses
Thema aber leider verfehlt ;-(
Moby A. schrieb:> Gerhard O. schrieb:>> Du bist aus Bayern? Von wo ungefähr?>> Von dort wo der Inn wieder Deine alte Heimat berührt ;-)
Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein
Österreicher...
Gerhard
Moby A. schrieb:> Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm,
Das "C vs." lass bitte weg. Solange du in Hochsprachen keinen Fuß auf
den Boden kriegst, sind es nichts als deine Fantasiewelten.
Es geht immer noch um "Assembler wieder auf dem Weg nach vorn" und
nichts anderes.
Moby A. schrieb:> Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was> mich persönlich sehr interessiert.
Das stimmt nicht. Du versucht aus einem eingeschränkten
Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist,
mit Verlaub, blödsinnig.
Stefan K. schrieb:> völlig> überflüssiger neumodischer Kram ;-)
... im Bereich 8-Bit MSR allemal.
Das schlimmste ist die unnötige Bürokratie.
Dieser hochgradig umständliche Aufwand.
Das würde ich von der Priorität her fast noch über den gesteigerten
Ressourcenbedarf setzen ;-)
le x. schrieb:> Meine Rede.> Ich behaupte
Schwing mal keine großen Reden sondern mach Dich an die Arbeit, wenn
> 10-15min realistischer sind.
...
> Allerdings wird im ersten Schuss zwangsläufig RAM benutzt, ja mei, ist> halt so, und eventuell ein paar Bytes mehr Flash.
Also. Vergleich verloren.
> Könnte man alles trotzdem irgendwie hinpfuschen.
Du sagst es. Mit C eine einzige Rumpfuscherei
> jede noch so> abstruse Forderung erfüllen
Logo. Beim Vergleich des Ressourcenbedarfs ist der Vergleich der
Ressourcen eine abstruse Forderung.
> nicht mehr> erweiterbaren ASM-Lösung
Erzähl keinen Müll. Die ist mit zusätzlicher Funktionalität wunderbar
erweiterbar und auch schon entsprechend vorbereitet.
> Und ich vermute mal, für 99% der Anwesenden hier auch
Sprich mal nicht für ein Publikum was Du im Rücken wähnst sondern allein
für Dich.
P. M. schrieb:> Faktenlose Beiträge? Ich denke wir haben dir aus allen denkbaren> Perspektiven erklärt
Du solltest Deine Perspektiven nicht mit Fakten verwechseln.
> belegt, was Sache ist
Belege geschehen mit Fakten und nix anderem, schon gar nicht mit
Perspektiven.
> es geht einzig und alleine> noch darum, dir zu zeigen, wie absurd deine Haltung ist
Schon klar. Die Mühe von harten Fakten wär jetzt auch zuviel verlangt.
Da könntest Du mal "zeigen". Mit Deinem behaupteten Wissensstand ein
Klacks ;-)
> Klassendepp
Ohne Beleidigung gehts nicht mehr.
Ein Beleg für Dein Scheitern ;-)
Moby A. schrieb:> Werner P. schrieb:>> Der Typ hat sowas von einen beschränkten Horizont.>> Beschränkt sind eher die Möglichkeiten, mit C effizientem Asm-Code bei> 8-Bit MSR Konkurrenz zu machen ;-)
was ist da beschränkt? Nur weil Du in ASM ein paar Bytes weniger
verbrauchst. Wenn es Dir was bringt, gerne. ich spare lieber Zeit und
kann mich wichtigeren Dingen widmen während du noch mit ÜSV beschäftigt
bist.
>>> "Du darfst kein>> SRAM verwenden!". usw. usw.>> Zu dumm daß es zu den zu vergleichenden Ressourcen gehört! Ich versteh> Deinen Frust.>
Ich bin nicht frustriert. Warum auch.
>> Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer>> sein Programm locker in 30 Minuten programmiert.>> Na dann mal los. Viel Funktionalität ist ja nicht (zu vergleichen).>
Nix dann mal los. Wozu?
>> ABER WEM INTERESSIERT DAS?>> Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher> abgeneigt ;-)>
ich verliere/verschwende nur ungern Zeit. Von daher verwende ich
Hochsprachen.
Moby A. schrieb:> Beim Vergleich des Ressourcenbedarfs ist der Vergleich der> Ressourcen eine abstruse Forderung.
Seit fast 2000 Beträgen versuchen wir dir das klarzumachen. Schön, dass
du das endlich eingesehen hast.
Dafür bekommst du jetzt auch mal ein "lebenswert".
mfg.
Witkatz :. schrieb:> Gerhard O. schrieb:>> Dann bist Du ja schon fast ein>> Österreicher...>> Ich hab's irgendwie geahnt ;-)
Das war aber nicht sehr nett;-)
Moby A. schrieb:> Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was> mich persönlich sehr interessiert.
Nen Scheißdreck tust du.
Am Anfang des Threads konnte man noch den Eindruck haben dass du dir die
Beiträge wirklich durchliest. Da bist du noch mehr oder weniger drauf
eingegangen.
Aber ab den letzten ca. 1000 Beiträgen kommen von dir nur noch
inhaltslose Phrasen.
Da machen sich Leute die Mühe und Verfassen technisch fundierte
Beiträge, versuchen die Vor- und Nachteile von Sprachkonstrukten (z.B.
Datentypen) zu erleutern oder dir die Funktionsweise eines Compilers zu
erklären, stecken echt viel Zeit rein und du - du gehst entweder
garnicht drauf ein, oder holst entweder die Bürokratie- die ÜSV- oder
die Verschwender-Keule raus.
Völlig egal um was es geht. Man hat nicht mehr das Gefühl dass du dir
die Beiträge durchliest. Du bist nur noch am Phrasendreschen,
inhaltsloses Geschwurbel, zufällig aneinandergereiht.
Gib also nicht den Interessierten. Es geht nur noch ums letzte Wort.
Irgendwer erwähnte ELIZA: wenns nicht so traurig wär, man könnts echt
meinen...
Witkatz :. schrieb:> Ich hänge noch mal mein PIC12F675 XC8 FREE Projektchen an. Ich habe es> an deine allerneueste Anforderungsliste angepasst
Nett von Dir, aber Dein PIC Code hilft gerade nicht weiter. Hatte ich
dazu nicht schon ausführlich Stellung genommen?
Nochmal im Klartext: Spart Euch weitere Codebrocken.
So viel Funktionalität hat enthalten meine <200 Bytes Flash nicht.
Michael K. schrieb:> Geht ja zum Glück schon lange nicht mehr um Inhalte.
Du meinst, bei Dir?
Ja, der Eindruck drängt sich auf.
Aber kein Wunder wenns mit C nicht zu stemmen ist ;-)
Ich habe Verständnis.
Moby A. schrieb:> Nett von Dir, aber Dein PIC Code hilft gerade nicht weiter. Hatte ich> dazu nicht schon ausführlich Stellung genommen?>> So viel Funktionalität hat enthalten meine <200 Bytes Flash nicht.
Doch, mein Code hat volle Funktionalität bei 198 PIC Maschinenbefehlen.
Ich kann doch nichts dafür, dass du über C nur schwafeln kannst, aber
noch nicht mal in der Lage bist C zu buchstabieren.
> Nochmal im Klartext: Spart Euch weitere Codebrocken.
Ja wie denn jetzt, wirfst du schon die Flinte in den Korn?
Gerhard O. schrieb:> Das war aber nicht sehr nett;-)
Das war auch eines der ernstzunehmenden Argumente hier ;-)
le x. schrieb:> Da machen sich Leute die Mühe und Verfassen technisch fundierte> Beiträge, versuchen die Vor- und Nachteile von Sprachkonstrukten (z.B.> Datentypen) zu erleutern oder dir die Funktionsweise eines Compilers zu> erklären, stecken echt viel Zeit rein und du - du gehst entweder> garnicht drauf ein, oder holst entweder die Bürokratie- die ÜSV- oder> die Verschwender-Keule raus.
Du begreifst es nicht.
Ich möchte nichts erklärt haben, ich möchte überzeugt werden. Mit
Fakten. Dafür hab ich ein fix und fertiges Projekt eingebracht. Also
bitte, kein
> inhaltsloses Geschwurbel, zufällig aneinandergereiht.
sondern eine bessere C-Fassung meines Projekts bitte!
Das müsstest Du in 10-15 min noch vor dem Schlafengehen schaffen ;-)
Moby A. schrieb:> Jay W. schrieb:>> So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer>> noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR>> kann da zu klein sein>> Hast Du eine Ahnung!>
Welches deiner Programme hat den bis jetzt nicht in einen 8-bit AVR
gepasst? Die "C"-Kompilate passen dann auch rein.
>> Damit fällt doch auch dieser>> pathologische Sparzwang weg.>> Hier gehts nicht um Sparzwang oder Verschwendungssucht.>
"Wer mehr als 2 Byte SRAM oder 1 Byte mehr an Flash verbraucht, hat
verloren." Wie würdest du das bezeichnen? Redest du nicht immer von
"fettem C" ?
Die wichtigste Ressource im Leben eines Menschen ist die "Zeit". Da du
dein Tinysensorboardprogramm immer noch optimierst, würde ich glattweg
behaupten, dass du deine Lebenszeit verschwendest. Schade.
Assembler zu beherrschen und zu wissen, wann man ihn am besten
einsetzt, sind die Tugenden eines Programmierers, nicht das sture
Beharren auf der Sprache.
> Danke für Deinen Beitrag, der dieses Thema aber leider verfehlt ;-(
Ich bin zerknirscht. :-(
Manche Tellerränder scheinen ziemlich hoch zu sein.
Wißt Ihr wieviele tolle Projekte man in der Zeitspanne, die dieser
Thread schon konsumiert hat, hätte durchziehen können?
Durchschnittliche Beitragsschreib- und Denkdauer ca 5 min. Macht also
10Kh oder 400 Mannstunden. Was hätte man also in dieser Zeitspanne alles
schaffen können...
Schade!
Zieht die Bremsen an, bevor der Zug unanhaltbar wird.
Gruß,
Gerhard
Witkatz :. schrieb:> Gerhard O. schrieb:>> Zieht die Bremsen an, bevor der Zug unanhaltbar wird.>> Wir sind gerade bei 1933, es dauert nicht mehr lang.
Und was passiert dann?
Witkatz :. schrieb:> Gerhard O. schrieb:>>> Wir sind gerade bei 1933, es dauert nicht mehr lang.>>>> Und was passiert dann?>> Nichts ist eindeutiger als eine Zweideutigkeit? ;-)> Nö, es geht um Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Ja, fast hätte ich es vergessen. Ich dachte schon er meinte Wiley Coyote
aus Braunau...
Gerhard O. schrieb:> Witkatz :. schrieb:>>>> Wir sind gerade bei 1933, es dauert nicht mehr lang.>> Und was passiert dann?
Nach Stanislaw Lem in seinen "Sterntagebüchern" hat die Information dann
die kritische Masse erreicht und wird zu Materie, sich dabei selbst
auslöschend.
Chaos!
Gerhard O. schrieb:> Was hätte man also in dieser Zeitspanne alles> schaffen können...
ein etwas komplexeres ASM Programm ;-)
bald 1945. dann ist Schluss mit lustig
Moby A. schrieb:> Ich möchte nichts erklärt haben, ich möchte überzeugt werden.
... das ist schlichtweg eines: G E L O G E N
... egal wie oft Sie das wiederholen !
Sie möchten hier nur eines: Sich unglaublich darüber amüsieren, wieviele
Menschen Ihnen ob ihren absoluten zensiert Beiträgen auf den Leim
gehen.
Jemand, der überzeugt werden mag, macht sich Gedanken. Sie ... haben das
Denken schon seit längerer Zeit schlicht eingestellt !
Gerhard O. schrieb:> Moby A. schrieb:>> Gerhard O. schrieb:>>> Du bist aus Bayern? Von wo ungefähr?>>>> Von dort wo der Inn wieder Deine alte Heimat berührt ;-)>> Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein> Österreicher...>> Gerhard
Ein Bayer, der nach eigenen Angaben als ersten Computer einen
"Heimcomputer" der frühen 80er der Firma Robotron bediente. Klingt ja
völlig ungelogen.
Clemens M. schrieb:> Nee eine Beleidigungsschiene ist das nicht.> Erklär mir doch mal wo ich dir Unrecht tue
Ich weiß gar nicht, wie ich Dir bei soviel zur Schau gestellten
Hilflosigkeit noch helfen kann. ;-(
Überhaupt bitte ich um Verständnis, daß ich mich lieber mit dem
eigentlichen Thema beschäftige:
Johann L. schrieb:> Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE> C-Umsetzung.
Falsch. Nur
1. Mit Übung, Vorbereitung, System.
2. Für den 8-Bit MC Bereich.
3. Bei wenig Rechnerei und nicht allzuviel Daten!
4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache.
> Nein, C als Sprache kennt weder Flash noch Register noch Stack oder> Schalter.
Was man für effizienten Code aber kennen sollte!
C selbst liefert ein Vielfaches an Begrifflichkeiten (hatte ich alles
schon hundert Mal aufgezählt)
> Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine> C-Implementation, und die darf ich wählen wie ich will?
Du sollst von meiner Funktionsbeschreibung auf ein C-Programm kommen
> Oder geht's dir nur um Compiler-Bashing?
Nein. Ich weiß in Compilern steckt einiges KnowHow und viel Arbeit. Es
gibt viele Einsatzgebiete wo C eingesetzt werden kann. Mal sinnvollere,
mal weniger sinnvolle. Zu letzteren zählt 8-Bit MSR.
> dann nen Blutsturz bekommen weil der> 2 Bytes mehr verbraucht hat?
Spar Dir die Poesie.
Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels
nach ;-)
> C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler.
Nun stellst Du Dich auch noch dumm. Du weißt natürlich, daß der
resultierende Code hier im Fokus steht.
> Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln?
Keinen.
Moby A. schrieb:> Falsch. Nur> 1. Mit Übung, Vorbereitung, System.> 2. Für den 8-Bit MC Bereich.> 3. Bei wenig Rechnerei und nicht allzuviel Daten!> 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache.
Irgendwas fehlt hier doch.
Ach ja: MSR
Bitte, gern geschehen.
P. M. schrieb:> Moby A. schrieb:> Was interessiert mich hier jede denkbare C-Umsetzung?> Asm ist in jedem Fall deutlich magerer> Also, hopp, beweis es! Komm! Beweis es!
Mein Code liegt vor. Beweise Du jetzt weniger Aufwand mit C. Laß Dich
nicht von den übergroß drohenden Zielen unnötig Angst machen: 197 Bytes
Flash und 2 Bytes auf dem Stack ;-)
Schaffst Du das nicht sag ich trotzdem Dankeschön.
Lothar M. schrieb:> Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist> keinen müden Cent billiger. Und der braucht auch nicht weniger Strom.> Und er ist auch nicht leichter.
Du hast ein "Und" vergessen:
- Und um das alles gehts hier gar nicht!
> Das Einzige, was passiert, ist dass die hocheffiziente und RAM-sparende> Appliktation ein halbes Jahr zu spät an den Markt kommt und sie dann> keiner mehr will.
Ein Argument in einer Firma- bei einem weniger Asm- geeigneten Projekt!
Witkatz :. schrieb:> Die Auflistung der C Schlüsselworte und Operatoren
... wird wohl kaum für prsktische C-Programmierung ausreichen ;-)
> Also was denn jetzt. Erst fantasierst du dir was über C zusammen
Ach woher denn. Da kommt mir z.B. gleich wieder
Beitrag "Einstieg in C - komische Fragen"
in den Sinn. Hilfe! Hilfe!
Klaus W. schrieb:> Irgendwas fehlt hier doch.>> Ach ja: MSR>> Bitte, gern geschehen.
Ist ja eh das meiste.
Wolltest Du mir nicht noch was nachliefern?
Wo überall im SmartHome Asm und 8Bit nicht reichen?
Stefan K. schrieb:> Moby A. schrieb:> Kapselung der Funktionalität>> bedeutet bei Dir:> für jeden Hühnerschiss einen anderen mc. Das definiert der Rest der Welt> irgendwie anders!
Vermutlich beherrscht Du Asm nicht insoweit als daß Du die
Funktionskapselung in meinem Code erkennen konntest ;-)
Was die vielen MC's angeht: Der MC muß sich dort befinden wo er im
SmartHome für Sensor/Aktorknoten auch gebraucht wird. Mit der
allumfassenden 32 Bit Zentral-CPU gewinnst Du da keinen Blumentopf.
Markus M. schrieb:> Mein Code lässt sich kompilieren
... ist aber keine vollständige 1:1 Umsetzung meines Projekts. Merke:
Die .hex soll dann gleich in meine Tiny13-Zielhardware ;-)
Gerhard O. schrieb:> Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein> Österreicher...>> Gerhard
Aber nur fast :-)
Das aber doppelt:
Von der Grenznähe und vom "östlichen" her ;-)
Jay W. schrieb:> Das stimmt nicht. Du versucht aus einem eingeschränkten> Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist,> mit Verlaub, blödsinnig.
Der eingeschränkte Anwendungsbereich der einen lässt Platz frei für die
andere. Was ist daran blödsinnig?
Witkatz :. schrieb:> Moby A. schrieb:> Beschränkt sind eher die Möglichkeiten, mit C..>> Für dich auf jeden Fall. Es ist eine andere Welt.
Und eine Welt ohne jeden Reiz im 8-Bit MSR Bereich!
Gerhard O. schrieb:> Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein> Österreicher...>> Gerhard
Aber nur fast :-)
Das aber doppelt:
Von der Grenznähe und vom "östlichen" her ;-)
Jay W. schrieb:> Das stimmt nicht. Du versucht aus einem eingeschränkten> Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist,> mit Verlaub, blödsinnig.
Der eingeschränkte Anwendungsbereich der einen lässt Platz frei für die
andere. Was ist daran blödsinnig?
Witkatz :. schrieb:> Moby A. schrieb:> Beschränkt sind eher die Möglichkeiten, mit C..>> Für dich auf jeden Fall. Es ist eine andere Welt.
Und eine Welt ohne jeden Reiz im 8-Bit MSR Bereich!
Thomas E. schrieb:> Dafür bekommst du jetzt auch mal ein "lebenswert".
Kannst Du behalten. Lese/zitiere lieber richtig.
Jay W. schrieb:> Welches deiner Programme hat den bis jetzt nicht in einen 8-bit AVR> gepasst? Die "C"-Kompilate passen dann auch rein.> Damit fällt doch auch dieser> pathologische Sparzwang weg.
Möglicherweise. Hier und da.
Was in jedem Fall weg fällt ist die C-Bürokratie.
> "Wer mehr als 2 Byte SRAM oder 1 Byte mehr an Flash verbraucht, hat> verloren." Wie würdest du das bezeichnen? Redest du nicht immer von> "fettem C" ?
Tja Du darfst nicht vergessen, daß wir hier nur von einem <200 Byte
Projektchen reden und noch lange nicht ausgemacht ist wieviel ein
C-Projekt mehr verbraten würde! Hat ja keiner den Mumm, die angeblichen
"15" Minuten zu erübrigen ;-)
> Die wichtigste Ressource im Leben eines Menschen ist die "Zeit". Da du> dein Tinysensorboardprogramm immer noch optimierst, würde ich glattweg> behaupten, dass du deine Lebenszeit verschwendest.
Da optimier ich gar nix. Nur für den Vergleich hier streiche ich hier
und da noch zusammen ;-)
> Assembler zu beherrschen und zu wissen, wann man ihn am besten einsetzt,> sind die Tugenden eines Programmierers, nicht das sture Beharren auf der> Sprache.
Die Tugend besteht immer darin, welche Lösung den geringsten Aufwand
macht. Dazu zählt auch das zu beherrschende Sprachinstrumentarium.
> Ich bin zerknirscht. :-( Manche Tellerränder scheinen ziemlich hoch zu> sein.
Hab auch den Eindruck ;-)
Gerhard O. schrieb:> Zieht die Bremsen an, bevor der Zug unanhaltbar wird.
Gerhard, was fachlich nicht klärt geht fließend ins Entertainment über.
Mach Dir keine Sorgen. Ich hab Spaß dran.
Sheeva P. schrieb:> Moby A. schrieb:> Ich habe Verständnis.>> Wie das? Dazu bedürfte es schließlich eines Verstandes.
Zu Bedeutenderem reichts bei Dir wohl nicht mehr?
Genügend Verstand hätte auch Umsetzung meines Projekts durch einen
C-Programmierer benötigt ;-)
Ralph S. schrieb:> Moby A. schrieb:> Ich möchte nichts erklärt haben, ich möchte überzeugt werden.>> ... das ist schlichtweg eines: G E L O G E N>> ... egal wie oft Sie das wiederholen !>> Sie möchten hier nur eines: Sich unglaublich darüber amüsieren, wieviele> Menschen Ihnen ob ihren absoluten zensiert Beiträgen auf den Leim gehen.>> Jemand, der überzeugt werden mag, macht sich Gedanken. Sie ... haben das> Denken schon seit längerer Zeit schlicht eingestellt !
Für meinen Geschmack schreist Du hier recht wirr durch die Gegend. Ein
untrügliches Anzeichen,wenn sich einer nicht mehr unter Kontrolle hat.
Wenn Du meinst, mir auf den "Leim" zu gehen dann mach das Naheliegende:
Bleib fern. Ein gutgemeinter Ratschlag.
Carl D. schrieb:> Ein Bayer, der nach eigenen Angaben als ersten Computer einen> "Heimcomputer" der frühen 80er der Firma Robotron bediente. Klingt ja> völlig ungelogen.
Tja Carl D. Deine kombinatorischen Fähigkeiten sind wohl auch nicht mehr
das was sie mal waren... Meine Person ist hier aber nicht das Thema, sie
gestaltet es höchstens mit.
So, damit sollten alle wichtigen Beiträge des Tages passend quittiert
sein. Hab die nächsten Tage nicht mehr ganz soviel Zeit. Harte C Fakten
zu meinem Projekt sind vermutlich ohnehin nicht mehr zu erwarten und
wenn, dann bitte ich um Fortsetzung in meinem Projekt-Thread:
Beitrag "Kleines Tiny13 Sensorboard"
Gute Nacht und Danke für die rege Beteiligung ;-)
>Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher>abgeneigt ;-)
Muhaha! Das ist doch mal ein nettes Zitat. Suche mal oben nach Karl
Heinz Vorschlag und ergötze dich wie du dich da rauswindest.
Moby A. schrieb:> Die Auflistung aller Instruktionen ist schnell erledigt, deren> Verständnis auch. Kein Vergleich mit C.
Richtig heist der Satz:
"Die Auflistung aller mir bekannten Instruktionen ist schnell
erledigt, deren Verständnis auch. Kein Vergleich mit C."
Moby A. schrieb:> Das schlimmste ist die unnötige Bürokratie.> Dieser hochgradig umständliche Aufwand.
Gibts eig. einen Grund warum du ständig deine persönlichen Defizite
herausstellst? Wenn du das bischen C Syntax wirklich nicht verstehst
dann sollte dir das eher peinlich sein.
Das schickt man als Rohdaten an den PC und rechnet in Excel. So bleibt
die Reinheit des 8-Bit Glaubens bewahrt und man muss sich nicht mit
fetter Bürokratie rumärgern.
Moby A. schrieb:>> In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten>> möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen>> läßt.>> So edel optimiert muß Software auf einem kleinen Controller aber> ausschauen! Sparsamer Verbrauch, Kapselung der Funktionalität, einfache> Erweiterbarkeit.
Edel Optimiert ?
Das ist dilletantisches Gemurkse bereits beim Grundkonzept.
Wo ist denn Dein ÜVS beim Systemkonzept gewesen ?
Ich bitte Dich, eine synchrone serielle Schnittstelle bei der ich eine
Taktleitung mitschleppen muß ?
Nicht Bus fähig, nicht adresserbar und schnarchlangsam ?
Weder gibt diese verpfuschte Umsetzung jemals vernünftige Datenraten
her, noch werden die Übertragungsfehler sicher detektiert.
Die AD Wandlung misst irgendwas in abhängigkeit der jeweiligen Chips
weil die für genaue Messungen notwendige Kalibrierung nicht stattfindet.
Da kannst Du ruhig 10bit übertragen, das ist trotzdem Schrott mit
begrenzter Aussage.
Keine Entprellung der Inputs ?
Das ist gröbster, dämlichster Pfusch und ist eher ~edel_optimiert, wenn
Du weist was ich meine.
>> Mit Verlaub.>> Das ist vollkommener Müll.> Du meinst weil klar ist, daß man es in C nicht kürzer gebacken bekommt?
Nein, weil Du ja wirklich überhaupt keinen Plan hast wovon Du das
faselst. Das beschränkt sich ja nicht auf Hochsprachen, das sieht bei
Konzeption und Hardware genauso traurig aus.
>> Die unterste Schmerzgrenze für Sensor Aktor Knoten sehe ich bei>> adressierbaren Master Slave Feldbussen mit min. 16 Teilnehmern.> Bist Du von der Industrie? Dann wär mir alles klar. So einer muß die> überteuerten Preise dort irgendwie rechtfertigen. Schenk Dir das. Geht> alles viel simpler, viel billiger ;-)
Im Gegensatz zu Dir habe ich Systeme in Industrie und Luftfahrt
konzeptioniert und gebaut. Ich kenne sowohl die Theorie als auch die
Praxis die einen Feldbus zum Feldbus macht und warum man gut daran tut
alles was ein paar Meter überbrücken muß störsicher auszulegen.
Dein Kram ist weder billig noch simpel.
Von jedem Knoten eine separate Leitung zum Master legen zu müssen und
für jeden Knoten auf dem Master eigene Ports zu blockieren ist alles
andere als billig und simpel.
Das ist einfach nur dumm und zeugt davon das Du überhaupt nicht in der
Lage bist Konzepte zu verstehen die über Deinen winzigen Tellerrand
hinausgehen.
Dazu verwendest Du die MCU Familie die wohl das schlechteste Preis
Leistungs Verhältniss hat das man derzeit finden kann.
Wenn Du wirklich 10% so clever wärst wie Du glaubst dann wärst Du in der
Lage mit einer fast identischen Hardware, ohne Zusatzkosten einen
Adressierbaren Sensorknoten zu bauen der einen bidirektionalen 1Draht
Bus besitzt, in der Anwendung reprogrammierbar ist und mit einem
kalibrierten AD, entprellten IOs (ja, auch Ausgängen) zuverlässigge
Daten erhebt und die auf Anforderung des Masters mit einer
zuverlässiggen CRC Summe überträgt.
Du hingegen stümperst Dir hahnebüchenden Kram zusammen und nennst das
edel optimiert mit ÜVS.
Zu Ahnungslos zu sein sowas vernünftig umzusetzen kann ich ja noch
akzeptieren, aber zu blöd auch nur ansatzweise zu verstehen was man da
eigentlich in der Summe alles verbockt hat und darauf auch noch stolz zu
sein ist wirklich eine ganz eigene Kategorie.
Ich lege normalerweise nicht so den Finger in die Wunde, aber Deine
Borniertheit schreit ja geradezu danach.
Wenn ich die Codes mir so vergleiche:
Moby:
https://www.mikrocontroller.net/attachment/highlight/277428
Witzkatz:
https://www.mikrocontroller.net/attachment/highlight/277579
Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch
verstehen.
Da werden irgend welche Zahlenwerte in Register geschrieben, ohne
Datenblatt zu wälzen ist es schwer.
Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht
mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten
angesagt.
Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt
die Bits gezeigt die gesetzt werden.
Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das
C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch
wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich
auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann
was gleichbedeutend mit RAM Verbrauch ist.
Daher ist es einfach nur einseitig gedacht "ich brauche kein SRAM" -
obwohl die Register wohl auch SRAM sind. Oder was sind Register denn
sonst?
Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe
angeht: 24 Bit senden, mit 80 ms Pause ???
Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je
nach Auslastung des Programmes des Master Boardes wohl auch nicht so
leicht ist. Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B.
STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur
Synchronisation und kann problemlos mit 9600 Baud geschehen.
Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext
mit übertragen, die von der Gegenstelle gezeigt werden!
Das wäre flexieben, aber so es ist nur eine Krücke/Krampf.
Markus M. schrieb:> Unterm Strich ist der Speicherverbrauch> wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich> auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann> was gleichbedeutend mit RAM Verbrauch ist.
Egal, Moby macht hier die Regeln was eine "Ressource" ist.
- SRAM ist natürlich die Wichtigste, die Kostbarste. Denn mit ihr steht
und fällt die Möglichkeit, seinen Code mit C zu schlagen.
- Erweiterbarkeit, Lesbarkeit, Entwicklungszeit, Testbarkeit,
Portierbarkeit, Wiederverwendbarkeit, Skalierbarkeit dagegen sind
unwichtig. Diese Ressourcen sind billig und müssen daher auch nicht
geschont werden
- insbesondere die Entwicklungszeit ist völlig vernachläsigbar da
Menschen ja über unbegrenzt Freizeit/Lebenszeit verfügen
Moby A. schrieb:> Vermutlich beherrscht Du Asm nicht insoweit als daß Du die> Funktionskapselung in meinem Code erkennen konntest ;-)
Ach ja? Von Dir kann ich das noch nicht mal als Beleidigung auffassen.
Ein hingepfuschtes Frickelprogramm, eine proprietäre serielle
Übertragung in Morsegeschwindigkeit, den kompletten Befehlssatz eines
Anfängerprocessors auch nach Jahren noch nicht vollständig drauf, ASM
bedeutet AVR, weil Dein Horizont knapp davor aufhört ...
Das Einzige, was an Dir wirklich bewundernswert ist, wie Du mit so wenig
Wissen den Mund dermassen voll nehmen kannst.
Markus M. schrieb:> Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch> verstehen.
Dir fehlt ganz eindeutig ÜVS!
Leute, nur noch 33 Beiträge, dann gibt Lothar uns ein Bier aus! :-)
(Oder hatte ich ihn da falsch verstanden? ;)
Markus M. schrieb:> Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je> nach Auslastung des Programmes des Master Boardes wohl auch nicht so> leicht ist.
Ich sag dir, ich würde bares Geld dafür zahlen, den XMega-Code des
Masters sehen zu dürfen.
Insbesondere wie er mehrere Sensorboard-Daten einliest und dieses krude
Protokoll parst während im Hintergrund die Regelung weiterläuft würde
mich echt interessieren.
A. K. schrieb:> Markus M. schrieb:>> Oder was sind Register denn sonst?>> Multiported SRAM. Erheblich teurer als normales SRAM.
PS: Cores mit Akkumulator statt grossem Registersatz sind in dieser
Hinsicht billiger als AVR. Bei Tiny10&Co hat Atmel deshalb den halben
Registersatz weggelassen und lieber ein paar Bytes RAM implementiert.
Dumdideididel die Katz hat die Fidel und die Kuh springt über den Mond.
Einer kleiner Sprung für die Kuh, ein großer Sprung für die Kuhheit.
So, noch 32 Beiträge.
Moby Code:
https://www.mikrocontroller.net/attachment/highlight/277428
Ist ein Spaghetticode ohne erkennbare Struktur, dafür braucht er
wirklich ÜVS, denn sonst könnte er das niemals zu hin bekommen
Witzkatz Code:
https://www.mikrocontroller.net/attachment/highlight/277579
hingegen ist klar strukturiert, ordentliche Bezeichner und unterteilt in
Funktionen mit den einzelnen Aufgaben und somit:
- Wartbarer
- leichter zu erweitern
- leichter anpassbar auf andere Anforderungen
- direkt mit der Spezifikation vergleichbar
> parst während im Hintergrund die Regelung weiterläuft wü
Macht ein extra Hardwarechip, natürlich dazugekauft. Da kein typisches
8bit MSR.
>lieber ein paar Bytes RAM implementiert.
Gut für Moby, kann mehr von der gekauften Ressource nicht verwendet
werden.
Markus M. schrieb:> Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das> C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch> wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich> auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann> was gleichbedeutend mit RAM Verbrauch ist.
Damit blendet er sich selbst. Die RAM-"Einsparung" dient der angeblichen
"Erweiterungsmöglichkeit". Dazu muss der Erweiterer nur einige Register
auf dem Stack sichern.
Wenn also eine Anzahl, sagen wir mal 5, von Registern als Speicher für
globale Variablen benutzt werden, müssen diese von der Erweiterung auf
dem Stack gesichert werden. Das bedeutet, dass immer 5 Byte RAM
"verloren" gehen.
Würde man die Variablen, wie jeder mit Hirn versehene Programmierer das
tut, im RAM anlegen, gingen für die Erweiterbarkeit auch 5 Byte RAM
"verloren".
Was ist der Unterschied für die RAM-Auslastung?
Ausser, dass man sich daran aufgeilen und den grossen Macker spielen
kann, leider gar keiner. Sondern
Überheblichkeit,
Verbohrtheit und
Selbstüberschätzung.
Aber abgerechnet wird zum Schluss. Und dann werden solche unsinnigen
Spielereien schonungslos aufgedeckt. Programmierung ist nämlich kein
Voodoo-Zauber.
@Moby: Mir und den meisten anderen ist klar, dass du das nicht
verstehst.
mfg.
le x. schrieb:> Egal, Moby macht hier die Regeln was eine "Ressource" ist.> - SRAM ist natürlich die Wichtigste, die Kostbarste.
Biete 1k SRAM (garantiert unbenutzt) gegen 1 Monat Lebenszeit.
Wer macht mit?
Markus M. schrieb:> Jörg W. schrieb:>> dann gibt Lothar uns ein Bier aus!>> Jedem Forumteilnehmer?>> Man das gibt ja ne Riesenparty.
Juhuu, dann hatte der Thread ja doch einen Sinn :-)
Jörg W. schrieb:> Leute, nur noch 33 Beiträge, dann gibt Lothar uns ein Bier aus! :-)> (Oder hatte ich ihn da falsch verstanden? ;)
Dann macht mal langsam, ich darf mein Bier erst nächsten Montag
aufmachen. Es ist noch nicht "reif"...
http://www.bergbier.de/brauereibesichtigung.html
>Dann macht mal langsam, ich darf mein Bier erst nächsten Montag>aufmachen. Es ist noch nicht "reif"...>http://www.bergbier.de/brauereibesichtigung.html
Das wirft doch zwangsläufig den notwendigen Vergleich des Ballmer Peak
bei asm oder c-Kodierung auf!
Hat da schon jemand Erfahrungen?
Du hast folgendes behauptet:
> Moby A. schrieb:>> Was interessiert mich hier jede denkbare C-Umsetzung?>> Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation.
Das sollst du jetzt bitteschön endlich mal beweisen.
Moby A. schrieb:> Mein Code liegt vor. Beweise Du jetzt weniger Aufwand mit C.
Nein, dein Code beweist in keiner Weise, dass "Asm in jedem Fall
deutlich magerer" ist. Die Beweislast liegt nun klar bei dir. Du hast
die Behauptung aufgestellt, du musst sie also auch beweisen.
Moby A. schrieb:> Johann L. schrieb:>> Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE>> C-Umsetzung.>> Falsch. Nur> 1. Mit Übung, Vorbereitung, System.> 2. Für den 8-Bit MC Bereich.> 3. Bei wenig Rechnerei und nicht allzuviel Daten!> 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache.
Unter diesen engen Bedingungen soll ASM also immer effizienter als C
sein? Zusammen mit folgender Aussage
Moby A. schrieb:> Asm-Programmierung ist durchschnittlich aufwendiger, aber je nach Übung,> Vorbereitung und System. Dafür kommt mehr Effizienz bei raus. Allein um> diesen Punkt geht es mir aber- und zwar bis hoch zu 1M
frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur
wenige simple Berechnungen durchgeführt werden. Wie viele Daten
verarbeitet werden, spielt nahezu keine Rolle. In erster Linie wird mehr
RAM benötigt, Programmspeicher nur für das Arraygedöhns und eventuale
Initialisierungen.
>Moby A. schrieb:>Allein um diesen Punkt geht es mir aber- und zwar bis hoch zu 1M
Das hatte ich noch gar nicht gelesen.
Wenns so ist, dann sollten wir aber einen Vergleich definieren für einen
Code >> 10kBytes Flash. Und zwar mit einer Textaufgabe als Start.
be s. schrieb:> frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur> wenige simple Berechnungen durchgeführt werden.
Na, Übung, Vorbereitung, System. Halt von allem genügend. :-)
Moby A. schrieb:> Johann L. schrieb:>> Nein, C als Sprache kennt weder Flash noch Register noch Stack oder>> Schalter.>> Was man für effizienten Code aber kennen sollte!
Eine C-Implementation (Compiler) muss solche Konzepte kennen. Aber C
als Sprache braucht von Flash nichts zu wissen. Es ist ja noch nicht
mal klar, ob eine bestimmte Hardware überhaupt Flash hat!
C beschreibt nur Eigenschaften die ein konformer Code haben muss, es
macht keine Aussagen darüber, wie das erreicht werden darf!
Beispiel: Wenn in einem C-Programm "a = b + 1" steht, dann bedeutet das
weder, dass es im erzeugten Code eine Variable namens "a" geben muss,
noch dass es eine Variable "b" geben muss, noch dass es irgendwo im Code
eine Sequenz gibt, die "1" auf irgendwas addiert.
Eine bestimmte C-Implementation (C-Compiler) darf das so machen, ist
aber nicht gezwungen das zu tun.
Und du (und viele andere hier) haben immer noch nicht verstanden, dass
ein bestimmtes C-Programm, das mit einem bestimmten C-Compiler übersetzt
worden ist, nur eine Obergrenze für den von C mindestens
erforderlichen Resourcenverbrauch ergibt.
Was du hier behauptest sind Untergrenzen für den Verbrauch, und dass
dieses Minimum, egal von welchem C-Compiler erzeugt, immer größer ist
als der Verbrauch des von dir vorgelegten Codes.
Vielleicht solltest du dir erst mal den Unterschied zwischen Maximum und
Minimum, zwischen Obergrenze und Untergrenze klar machen?
> C selbst liefert ein Vielfaches an Begrifflichkeiten> (hatte ich alles schon hundert Mal aufgezählt)
C kennt weder den begriff "Bürokratie" noch "Flash" noch "Register".
Aber vielleicht hab ich ja auch was überlesen, und du bist so großzügig,
uns die Stellen im C-Standard aufzuzeigen.
>> Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine>> C-Implementation, und die darf ich wählen wie ich will?>> Du sollst von meiner Funktionsbeschreibung auf ein C-Programm kommen
Und wie willst du von einem C-Programm auf einen Resourcenverbrauch
kommen, ohne eine C-Implementation (vulgo: Compiler) zu haben?
>>> Oder geht's dir nur um Compiler-Bashing?>> Nein. Ich weiß in Compilern steckt einiges KnowHow und viel Arbeit. Es> gibt viele Einsatzgebiete wo C eingesetzt werden kann. Mal sinnvollere,> mal weniger sinnvolle. Zu letzteren zählt 8-Bit MSR.>>> dann nen Blutsturz bekommen weil der 2 Bytes mehr verbraucht hat?>> Spar Dir die Poesie.> Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels> nach ;-)
Wenn das C-Programm deine Spezifikation erfüllt, und dein Asm-Programm
ebenfalls, dann stellt dieses Asm-Programm eine konforme Umsetzung des
C-Codes dar. Mithin wäre dein Asm-Code eine obere Grenze für den
Resourcenverbrauch eines optimalen C-Compilers.
Oder sind deine Programme bewusst so geschrieben, dass sie nicht als
C-Programm formuliert werden können?
>> C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler.>> Nun stellst Du Dich auch noch dumm. Du weißt natürlich, daß der> resultierende Code hier im Fokus steht.
Dafür brauchen wir aber einen Compiler. Welchen sollen wir da nehmen?
>> Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln?>> Keinen.
Moby A. schrieb:> Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels> nach
Wir hatten das alles schon. Du behauptest ständig, Assembler
(meinetwegen mit ÜVS, also: aufwändiger Bürokratie) sei C überlegen.
Statt Deine eigenen Behauptungen zu belegen, wie das unter Erwachsenen
üblich ist, forderst Du, andere sollen Deine Behauptungen widerlegen...
:-)
Das hat Yalu dann getan und Dir unwiderlegbar bewiesen, daß sein
C-Compiler sogar bei solch winzigen Popelprojektchen besseren Code
produziert als Du, was für Yalu, für seinen Compiler, gegen Deine
Fähigkeiten als Programmierer spricht und Dein Geblubber eindeutig
widerlegt. :-)
Daraufhin hast Du plötzlich ein neues Popelprojektchen aus Deinem
Hütchen gezaubert, bei dem Du Dir offensichtlich die größte Mühe gegeben
hast, dem Compiler möglichst viele Fallen zu stellen. Und als mein
Honigtöpfchen dann trotzdem kleiner aussah, mußtest Du auf einmal
panisch die neue Anforderung "darf kein SRAM benutzen" erfinden.
Und genauso würde es wieder laufen, wenn jemand einen C-Code abliefert,
der Dein Sensorprojektchen schlägt: entweder erfindest Du eine neue
Anforderung oder Du kommst gleich mit einem neuen Popelprojektchen um
die Kurve. Been there, done that, got the t-shirt.
Solche Betrügereien sagen ja vor allem etwas über die hohle Frucht, die
sie offensichtlich nötig hat. Und sie sind ein Beweis dafür, daß Du
nicht einmal selbst an Dein dummes Gelaber glaubst. :-)
Sheeva P. schrieb:> Und genauso würde es wieder laufen, wenn jemand einen C-Code abliefert,> der Dein Sensorprojektchen schlägt: entweder erfindest Du eine neue> Anforderung oder Du kommst gleich mit einem neuen Popelprojektchen um> die Kurve.
Glaub ich nicht, dann könnte er sich gleich hier abmelden. ;-)
Außerdem: Sind euch denn die Slimeys, mit denen er fast jede seiner
Aussagen abschließt, verborgen geblieben? ;-)
Der Mann mag Slimeys! ;-)
Könnte man ihm nicht einen C-Compiler bauen, der anstatt des Semikolon
einen Sliley frisst? So als kleines Leckerli um ihn den Einstieg zu
versüßen ;-)
Moby A. schrieb:>> Mein Code lässt sich kompilieren>> ... ist aber keine vollständige 1:1 Umsetzung meines Projekts. Merke:> Die .hex
Wenn du nach C-Umsetzung deines ADC Klackers fragst, bekommst du genau
das - eine C-Umsetzung in edelstem C verfasst. Du darfst sie im Ganzen
oder die einzelnen Routinen davon gerne auf der µC Plattform deiner Wahl
mit dem Compiler deiner Wahl verwenden.
Eine .hex Datei ist kein C-Projekt. Aber das kannst du nicht verstehen,
weil das ein Satz mit C ist.
Also jetzt ein Quiz für Moby und alle, die es werden möchten:
In welcher Programmiersprache ist eine C-Umsetzung verfasst,
A. ist es A,
B. oder B
C. oder vielleicht C?
Als Hauptgewinn winkt 1k freien RAM auf einem attiny13.
Witkatz :. schrieb:> Eine .hex Datei ist kein> C-Projekt.
Schau einer an. Na sowas.
Aber vielleicht ein eindeutiger Ausdruck der manchem hier klarmacht, daß
eine vollständige Umsetzung statt irgendwelcher Bruchstücke gewünscht
ist?
Moby A. schrieb:> Aber vielleicht ein eindeutiger Ausdruck der manchem hier klarmacht, daß> eine vollständige Umsetzung statt irgendwelcher Bruchstücke gewünscht> ist?
Da du ja der erfahrenste von uns allen bist, macht es schon Sinn, das du
die Vorgaben machst.
In den fast 2000 Beiträgen ist doch nunmehr nachlesbar bewiesen, dass
weder Assembler auf dem Vormarsch ist, noch das es C, oft selbst als
Makroassembler verschrien, gelingt, dermaßen schlechten Code zu
generieren wie Moby.
Im Gegenteil, durch sparsame und sinnvolle Verwendung der zur Verfügung
stehenden Ressourcen, enstehen wart- und erweiterbare Anwendungen, die
nur wenig mehr an Ressourcen verwenden. Und das bereits ab einer
Codegröße von wenigen Byte.
Auch das Verwenden von Worthülsen wie SÜV, VSÜ, ÜVS, SVÜ, VÜS und ÜSV
ändert nichts an diesem Ergebnis.
Die Selbstdemontage des einsamen Protagonisten war vollumfänglich und
seiner Sache hat er eher einen Bärendienst erwiesen.
Vielleicht kann dieser Thread ja nun geschlossen werden, bevor Lem recht
behält. ;-)
Robert L. schrieb:> fällte sowas noch unter 8-bit MSR:> Heizkurve berechnen> PI(D) Regler
Für eine reine Raumtemperaturregelung (habe Fernheizung) nicht nötig.
> Dimmkurve für led berechnen
Man kann auch ne Wissenschaft draus machen ;-)
> RMS (Strom/Spannung/(Blind-)Leistung usw.)
Wo fallen da große Berechnungen an? Für Blindleistungs-Berechnung?
Das mag ja für Spezialfälle interessant sein- für alle anderen gibts 10€
Fertiggeräte ;-)
Bei mir hab ich eine einzige selbstgebaute Strommessung im Einsatz: Die
misst den Strom bei einem billigen Heizungs-Stellglied zur Feststellung
des Endanschlags. Und was soll ich Dir sagen: Das geht locker auch mit
Asm. Entsprechende Sensoren sind einfach auszuwerten.
> NTC/PTC Kennlinien
Bei fertigen Temperatursensoren unnötig.
> Sonnenstand berechnen
Da schau ich aus dem Fenster ;-)
> ?
Hab ich mich auch gefragt...
Nein im Ernst, daß (Spezial-) Anwendungen mit erhöhtem Rechen- und
Datenverwaltungsbedarf den Einsatz einer Hochsprache (und ggf. stärkerer
Controller ) rechtfertigen können hatte ich doch nicht ausgeschlossen!
Jay W. schrieb:> dermaßen schlechten Code zu> generieren wie Moby.
Der ließe sich nur mit besserem toppen. Scheint aber nicht so einfach zu
sein ;-)
Michael K. schrieb:> Ich gönne Moby außerdem nicht das letzte Wort
Das letzte Wort spricht Stand heute immer noch mein ungeschlagenes
Asm-Projekt ;-)
Mensch Leute, nun reißt Euch mal am Riemen!
Dermaßen schlechten Code muß doch hier jeder kürzer in C hinbekommen!
Besonders die großen Sprücheklopfer, denen trau ich das am ehesten zu
;-)
Rufus Τ. F. schrieb:> Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will,> muss> sich das hier ansehen:>> Beitrag "Fast JPEG decoder on AT(x)mega"
Was heißt hier wahnwitzig?
In erster Linie ist es möglich!
Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-)
Moby A. schrieb:> Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-)
Gut, dazu zähle ich jetzt nicht, aber es gibt schon interessanten Code.
Auch gelegentlich in ASM.
Den habe ich hier aber noch nicht gesehen :-)
Mist, zu spät :-/
Gut, dann ist dies hier eben der 2001. Beitrag :)
Damit hat Lothar seine Wette grandios gewonnen. Gratulation!
Ich freue mich schon riesig auf das Bier, das er Gerüchten zufolge
ausgeben will :)
Da auch ich nicht mit leeren Händen zur Party kommen möchte, habe ich
eine C-Portierung von Mobys sensationellem 8-Bit-MSR-Assemblerprogramm
mitgebracht, von der sich jeder, der heute bis 24 Uhr einen Beitrag in
diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D
Das Programm entspricht exakt der von lex_91 zusammengefassten und von
Moby bestätigten bzw. ergänzten Spezifikation:
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Kleine Anmerkung an Moby:
Die Bits in deinem Zeitdiagramm stimmen nicht mit deinen aktuellen
textuellen Anforderungen überein. Es stammt wohl von deiner ersten
Programmversion mit der seltsamen Prüfsumme und der umgekehrten
Bitreihenfolge bei der Datenübertragung.
Das Einlesen, die Auswertung und das Versenden der Messdaten findet
komplett im Timerinterrupthandler statt. Das Hauptprogramm läuft nach
der Initialisierungm der I/O-Register in eine leere Endlosschleife. Der
Gesamtablauf ist also praktisch genauso wie bei Mobys Assemblerprogramm.
Auch die Konfiguration des Timers und des ADC habe ich von dort
übernommen, nur mit etwas mehr Symbolik bei den Registerinhalten.
Nach diesen Erläuterungen zur Spezifikation
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
habe ich die RAM-Initialisierung und den Sleep weggelassen. Für den
Vergleich habe ich auch in Mobys Assemblerprogramm die entsprechenden
Passagen entfernt, was dessen Codegröße um 16 Bytes verringert. Wenn es
gewünscht wird, rüste ich gerne auch eine C-Variante mit Sleep und
RAM-Initialisierung nach.
Quellcode und Hexfile liegen bei, auf dass sie von Moby zerissen werden
mögen (keine Angst, ich habe noch eine Kopie davon) und damit er seine
Spezifikation noch einmal "überarbeiten" kann ;-)
Das Programm wird gebaut mit
Mobys Programm hat noch einen kleinen Fehler: Die Register A1LO1, A1H,
A2LO2 und A2HO3 werden anfangs nicht mit 0 initialisiert, weswegen der
jeweils erste übertragene ADC-Mittelwert für jeden Kanal falsch sein
kann. Ich habe die dafür erforderlichen Befehle (2 CLR und 1 MOVW)
hinzugefügt, wodurch sein Programm wieder um 6 Bytes wächst.
Hier sind die Ergebnisse des Vergleichs:
1
Speicherverbrauch in Bytes
2
3
Mobys ASM Yalus C
4
——————————————————————————————————
5
Flash 206 158
6
SRAM (Stack) 2 2
7
——————————————————————————————————
Ein Teil der eingesparten Flash-Bytes kommt daher, dass in meinem
C-Programm der normalerweise für die ungenutzten Interruptvektoren
vorgesehene Platz mit Programmcode belegt wird. Tut man dies auch bei
Mobys Programm, verringert sich dessen Flash-Bedarf um 18 Bytes auf 188
Bytes, was aber immer noch deutlich über den 158 Bytes des C-Codes
liegt.
Insgesamt hat der Compiler eine recht gute Arbeit abgeliefert: Beim
Durchsehen des erzeugten Assemblercodes sind mir auf Anhieb nur drei
Stellen mit Optimierungsbedarf aufgefallen, bei denen jeweils ein
Registertransfer (MOV bzw. MOVW) eingespart werden könnte. Das würde das
Programm von 158 auf 152 Bytes verkürzen, was aber nicht einmal 4%
ausmacht .
Ich habe das C-Programm auf einen ATtiny13 geladen und für verschiedene
Spannungen und Logikpegel an den Analogeingängen bzw. an PB1 mit dem
Oszilloskop das Takt- und Datensignal überprüft. Sowohl das Timing (im
Rahmen der Genauigkeit des internen RC-Oszillators) als auch die
übertragenen Bits stimmten mit den Vorgaben und auch mit Mobys Programm
überein. Nur den PB5-Eingang habe ich nicht getestet, weil ich dazu den
Reset-Eingang hätte wegfusen müssen. Aber das Programm wird ja sowieso
von Moby noch auf Herz und Nieren geprüft werden :)
***********************************************************************
Es ist also tatsächlich möglich, Mobys Assembleranwendung deutlich
ressourcensparender in C zu schreiben. Damit bietet C nicht nur bei
großen Programmen, sondern sogar bei solchen Miniprogrammen (in Mobys
Sprache "typische 8-Bit-MSR-Anwendungen") klare Vorteile.
***********************************************************************
Natürlich hat Moby das längst geahnt (oder sogar gewusst?) und schon
einmal entsprechend vorgebaut:
Moby A. schrieb:> Johann L. schrieb:>> Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm>> findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und>> komplett versagt?>> Wer wird denn hier von Versagen reden? Der Vorteil simpler Codierung> ohne viel Bürokratie bleibt Asm dann immer noch. Nur die> Ressourcen-Geschichte hätte sich dann (für mich) erledigt.
Ok, die Ressourcenfrage hat sich nun erledigt.
Als einzige Vorteile von Assembler gegenüber C bleiben also die simple
Codierung und die geringere "Bürokratie". Beide Kriterien lassen sich
aber leider weder klar definieren noch objektiv messen, weswegen sich
bzgl. dieser Punkte am besten jeder sein eigenes Bild macht.
Ein paar Gedankenanstöße hierzu:
1. Simple Codierung
Man vergleiche die Interrupthandler der beiden Programme miteinander:
Obwohl im Wesentlichen beide dasselbe tun, ist die C-Version sehr viel
kompakter. So ist bspw.
1
sum.all+=ADC;
und
1
sum.all/=8;
zur Berechnung des Mittelwerts meiner Meinung nach nicht nur leichter zu
schreiben, sondern auch besser zu verstehen als
1
in r16,ADCL
2
in r17,ADCH
3
add A1LO1,r16
4
adc A1H,r17
und
1
lsr A1H
2
ror A1LO1
3
lsr A1H
4
ror A1LO1
5
lsr A1H
6
ror A1LO1
Hinzu kommen die leichteren Konfigurationsmöglichkeiten. In Mobys Code
kann man immerhin die Spannungsreferenzen für die beiden ADC-Kanäle
getrennt voneinander einstellen (auch wenn ich anfangs nicht ganz
nachvollziehen konnte, woher dieser "magische" Wert $c0 kommt, den man
für die interne Referenz angeben muss ;-)).
In C ist es aber ein Leichtes, auch die komplette Pinbelegung und die
Taktfrequenz der Datenübertragung konfigurierbar zu machen. Einiges
davon ginge sicher auch in Assembler, aber schon die Übersetzung von
Portnummern in die entsprechenden ADC-Kanäle durch den Compiler bzw.
Assembler – in C ganz geradlinig mit einem Compilezeit-Array als
Look-Up-Tabelle möglich – dürfte in Assembler schon einige Verrenkungen
erfordern.
Das Schöne dabei: Der Compiler ändert bei einer Umkonfiguration nicht
einfach nur ein paar Operanden der generierten Maschinenbefehle, wie
dies beim Assembler der Fall wäre, sondern optimiert – je nach Wahl der
Konfigurationsparameter – den Code durch Weglassen unnötiger Befehle
oder gar geschicktes Umschreiben ganzer Befehlssequenzen. In Assembler
erfordert so etwas meist Handarbeit, was nicht nur Zeit kostet, sondern
auch eine potentielle Fehlerquelle darstellt.
Zugegebermaßen gibt es auch in meinem C-Code ein paar Stellen, die man,
wenn man nicht unbedingt jedes einzelne Flash-Byte umdrehen muss, auch
etwas klarer gestalten hätte können. Ich hoffe, dass die Kommentar den
Ablauf trotzdem halbwegs verständlich machen.
2. Bürokratie
Bürokratie hat ja etwas mit Verwaltungswahn zu tun. Anders als in C
obliegt in Assembler die Verwaltung der einzelnen Register und des
Datenspeichers komplett dem Programmierer.
Einige der Register haben eine feste Funktion und sind deswegen von Moby
mit Namen (SIC, A1LO1, A2LO2 usw.) versehen worden. Aber was ist mit den
Registern R16, R17 und R18? Die Bedeutung dieser Register ändert sich
ständig, weswegen keine sinnvollen Namen vergeben werden können. Ohne
Namen ist aber bspw. nur schwer zu erkennen, das der Registerinhalt von
R18 in Zeile 98 eine 14 Zeilen früher angelegte Kopie von SIC ist. Jeder
temporären Variable ein eigenes benamstes Register zuzuordnen geht aber
auch nicht, weil sonst die 32 Register ganz schnell aufgebraucht sind.
Wenn man nicht sorgfältig Buch darüber führt, von wo bis wo im Code
jedes Register welchen Inhalt hat, wird man ziemlich schnell im Chaos
versinken. Diese Buchführung wird durch die vielen assemblertypischen
Kreuz- und Quersprünge noch zusätzlich erschwert.
Wenn man dann nicht nur Register, sondern auch noch Statusflags zur
Übertragung von Informationen über weite Strecken innerhalb des
Programms nutzt, ist die Buchführung durch den Programmierer kaum mehr
praktikabel, da die Änderungen der Statusflags durch die entsprechenden
Befehle meist implizit erfolgt, was schnell einmal übersehen wird.
In diese Falle ist trotz ÜVS sogar der Meister höchstpersönlich getappt,
als er eins seiner anderen Miniprogrämmchen schnell mal um ein paar
scheinbar triviale Dinge erweitern wollte, wodurch halt zufälligerweise
einer der hinzugefügten Befehle an ungünstiger Stelle das Carryflag
überschrieb:
Beitrag "Re: C versus Assembler->Performance"
Und was geschieht, wenn das Programm trotz aller Vorbereitung am Ende
doch etwas datenintensiver wird und man gerne ein paar Variablen von
"guten" Registern (R16 bis R31) in die weniger guten (R0 bis R15 mit
eingeschränkten Adressierungsarten) oder gar ins RAM verlagern möchte?
Oder der 8-Bit-Wertebereich stellt sich für eine Variable als zu knapp
heraus, und man möchte stattdessen mit 16-Bit-Werten in Registerpaaren
arbeiten? In C sind das alles keine großen Herausforderungen, in
Assembler hingegen läuft das ganz schnell auf das Neuschreiben ganzer
Codepassagen hinaus.
In höheren Programmiersprachen ist für solche Buchhaltertätigkeiten ganz
klar der Compiler zuständig, der auch bei komplexen Programmen nie den
Überblick verliert. Natürlich muss der Programmierer den Compiler dabei
mit ein paar Informationen unterstützen, was wohl das ist, was Moby als
Bürokratie empfindet. Dass man all diese Information bei der Assembler-
Progammierung ebenfalls vorhalten muss (statt im Quellcode eben auf
einem Blatt Papier, das gerne verloren geht oder gar im Kopf, der sie
nach ein paar Wochen vergisst), ist ihm wohl nicht bewusst.
Anders als in anderen höheren Programmiersprachen kann man – sofern man
das möchte – in C die Verwaltungsaebeit des Compilers in vielfältiger
weise beeinflussen, um mehr Effizienz des Programms zu erzielen.
So gibt es im obigen C-Programm einige explizite Registerzuordnungen für
globale Variablen. Diese sind aber nur Mobys unsinniger Anforderung nach
null RAM-Verbrauch geschuldet und würden bei dieser Anwendung (und den
allermeisten anderen ebenfalls) weggelassen werden, da sie nur ganz
selten einen wirklichen Nutzen bringen.
Normalerweise macht sich der C-Programmierer keine Gedanken darüber, in
welchen RAM-Zellen oder Registern Variablen abgelegt werden und wann
sich mehrere temporäre Variablen ein Register teilen, weil es einfach
viel zu viel Bürokratie wäre, über das alles im Detail Bescheid wissen
zu müssen ;-)
3. Weitere Kriterien
Moby, dir fallen doch ganz neben dem Ressourcenverbrauch, der simplen
Codierung und der Bürokratie, in denen ASM nun ja doch nicht ganz so gut
abschneidet, noch weitere (am besten messbare) Kriterien ein, die man
zum Vergleich zwischen Assembler und C heranziehen könnte. Das würde mal
wieder etwas neuen Schwung in die Diskussion bringen, so dass der Thread
auch nach dem Überschreiten der 2000er-Grenze unterhaltsam bleibt.
Ich bin auf deine neuen Argumente schon gespannt wie ein Flitzebogen ;-)
Moby A. schrieb:> Jay W. schrieb:>> dermaßen schlechten Code zu generieren wie Moby.>> Der ließe sich nur mit besserem toppen. Scheint aber nicht so einfach zu> sein ;-)
Moby, diese Aussage ist eine rabulistische Meisterleistung. Chapeau!
Mittlerweile hat Yalu nun auch den endgültigen Beweis erbracht. Für
seine Leistung und seinen Langmut gebührt ihm meine höchste Anerkennung.
Wahnsinn!
Der Moby ist ja wieder da, also poste ich das nochmal...
Wenn ich die Codes mir so vergleiche:
Moby:
https://www.mikrocontroller.net/attachment/highlight/277428
Ist ein Spaghetticode ohne erkennbare Struktur, dafür braucht er
wirklich ÜVS, denn sonst könnte er das niemals hin bekommen
Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch
verstehen.
Da werden irgend welche Zahlenwerte in Register geschrieben, ohne
Datenblatt zu wälzen ist es schwer.
Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht
mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten
angesagt.
Witzkatz Code:
https://www.mikrocontroller.net/attachment/highlight/277579
Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt
die Bits gezeigt die gesetzt werden.
hingegen ist klar strukturiert, ordentliche Bezeichner und unterteilt in
Funktionen mit den einzelnen Aufgaben und somit:
- Wartbarer
- leichter zu erweitern
- leichter anpassbar auf andere Anforderungen
- direkt mit der Spezifikation vergleichbar
- einzelne Anschnitte der Spezifikation in Funktionen gepackt, womit
eine Änderung der Spezifikation leichter umsetzbar ist.
Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das
C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch
wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich
auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann
was gleichbedeutend mit RAM Verbrauch ist.
Daher ist es einfach nur einseitig gedacht "ich brauche kein SRAM" -
obwohl die Register wohl auch SRAM sind. Oder was sind Register denn
sonst?
Wie schon mal von mir geschrieben: ein STM32 hat CCM RAM, also kann ich
problemlos alles, incl. Stack dort drin laufen lassen und es wird KEIN
SRAM benutzt. Und wenn ich einen externen DataFlash anschließe und das
Programm in den RAM lade, braucht es auch kein FLASH mehr (das geht z.B.
mit Cypress µC). Somit, Moby deine Anforderungen sind einfach nur
Blödsinn.
Und der Preis vom schlechtesten Spagetti Code hast du allemal gewonnen.
Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe
angeht: 24 Bit senden, mit 80 ms Pause ???
Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je
nach Auslastung des Programms des Master Boards wohl auch nicht so
leicht ist. Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B.
STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur
Synchronisation und kann problemlos mit 9600 Baud geschehen.
Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext
mit übertragen, die von der Gegenstelle gezeigt werden!
Das wäre flexibel, aber so es ist nur eine Krücke/Krampf.
Jay W. schrieb:> Vielleicht kann dieser Thread ja nun geschlossen werden, bevor Lem recht> behält. ;-)
Nö. Bevor die C-Fraktion sich vollends blamiert ;-)
Michael K. schrieb:> Ich bitte Dich, eine synchrone serielle Schnittstelle bei der ich eine> Taktleitung mitschleppen muß ?
Das möchte ich mal aus Deinem Plädoyer für eine kompliziertere,
umständlichere Lösung herausgreifen: Du checkst offensichtlich nicht,
daß diese Taktleitung a) einer easy Auswertung dient und b) einen nicht
genau bekannten/schwankenden MC-Takt wie er nunmal von einem internen
Osc geliefert wird zur Verwendung ermöglicht. Ansonsten ist meine Lösung
für die gegebene Sensorausstattung fast ideal optimiert und simpel. So
muß das ausschauen!
Markus M. schrieb:> Wenn ich die Codes mir so vergleiche:> Moby:> https://www.mikrocontroller.net/attachment/highlight/277428>> Witzkatz:> https://www.mikrocontroller.net/attachment/highlight/277579>> Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch> verstehen.
Da wären AVR-Asm Kenntnisse angebracht ;-)
> Da werden irgend welche Zahlenwerte in Register geschrieben, ohne> Datenblatt zu wälzen ist es schwer.
Für einen ASMler gehört zur optimalen Controller-Anpassung immer das
Datenblatt in die Hand.
> Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht> mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten> angesagt.
Ein Label im funktionsführenden (Timer-) System-Interrupt.
> Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt> die Bits gezeigt die gesetzt werden.
Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist
professionelles Vorgehen.
> Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das> C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch> wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich> auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann> was gleichbedeutend mit RAM Verbrauch ist.
Könnte man meinen. Den gleichen Registersatz R0-32 hat aber jederAVR.
Im zusätzlichen RAM unterscheiden sie sich. Der soll gespart werden. Den
Registersatz hatte ich für C nicht verboten zu nutzen. Auch wenn mehr
als 11 genutzte Register dann vergleichsmäßig sehr unschön rüberkommen
;-)
> Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe> angeht: 24 Bit senden, mit 80 ms Pause ???> Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je> nach Auslastung des Programmes des Master Boardes wohl auch nicht so> leicht ist.
Die Pause dient der Synchronisierung und macht die einfache Auswertung
erst möglich. Ein Beispiel ist in meinem Projekt enthalten!
> Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B.> STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur> Synchronisation und kann problemlos mit 9600 Baud geschehen.
Aber nicht mit Tiny13 ohne UART. Der langt für die Aufgabe aber genauso.
Eine UART setzt auch noch einen hinreichend genauen Systemtakt voraus.
> Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext> mit übertragen, die von der Gegenstelle gezeigt werden!
Man könnte vieles und jenes. Die gestellte Aufgabe wird aber erfüllt.
> aber so es ist nur eine Krücke/Krampf.
Aber so ist es die optimale Umsetzung der Aufgabenstellung mit viiel
Platz übrig für Erweiterungen ;-)
Yalu X. schrieb:> Ok, die Ressourcenfrage hat sich nun erledigt.
Na schaun mer mal. Morgen hab ich etwas Zeit Deinen Code praktisch zu
prüfen. Würd mich freuen wenn er weiteren Streit erübrigen würde.
> Ich bin auf deine neuen Argumente schon gespannt wie ein Flitzebogen ;-)
Bekommst Du ;-)
Danke für's Erste.
Rufus Τ. F. schrieb:> Es ist --wie jedes Assemblerprogramm-- praktisch unwartbar.
Wie hab ich bloß die letzten 20 Jahre überstanden ;-)
Jay W. schrieb:> Für> seine Leistung und seinen Langmut gebührt ihm meine höchste Anerkennung.> Wahnsinn!
Es hätte, wenn meine realisierte Funktion tatsächlich 1:1 abgebildet
wird, auch lang genug dazu gebraucht. Wahnsinn ;-)
Moby A. schrieb:> Da wären AVR-Asm Kenntnisse angebracht ;-)Moby A. schrieb:> Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist> professionelles Vorgehen.
Wieso sollte ich nun unbedingt den Dialikt vom AVR lernen?
Der nächste schreibt ein PIC ASM Code, der nächste MIPS und wieder einer
Renesas.
Jedes mal irgend ein µC spezifischen Code lernen, damit ich das von
fremden Leuten verzapfte verstehe?
Ne danke. Ich bleib bei C.
Das ist so ähnlich wenn es elektronische Datenblätter in Chinesisch,
Russisch, Französisch, Italienisch, Hebräisch usw. gäbe.
Aber zum Glück sind alle englisch und ein jeder Weltweit braucht nur
Englisch lernen!
Moby A. schrieb:>> Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt>> die Bits gezeigt die gesetzt werden.>> Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist> professionelles Vorgehen.
Das ist mal wieder dein übliches Geblubber.
Ein Datenblatt brauche ich für Prozessorspezifisches.
In deinem Gewusel braucht man es aber auch für triviale Sachen, wie
elementare Operationen über mehrere Anweisungen, wo man in jeder
vernünftigen Sprache etwas lesbares hinschreibt.
Wobei man natürlich auch in ASM mehr oder weniger klar ausdrücken kann;
ebenso wie ein Depp natürlich auch in anderen Sprachen unlesbares
Kauderwelsch schreibt.
Nur ist es in Hochsprache halt leichter und schneller, sauberen
Quelltext zu schreiben - der auch dank eines Compilers noch effizient
ist.
Würde dich lesbarer Quelltext interessieren, würdest du entweder
schöneres ASM hinschreiben, oder gleich etwas anderes nehmen.
Aber jeder wie er will, ich muß mit deinen Quelltexten ja nichts machen.
Moby A. schrieb:> Rufus Τ. F. schrieb:>> Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will,>> muss sich das hier ansehen:>>>> Beitrag "Fast JPEG decoder on AT(x)mega">> Was heißt hier wahnwitzig?> In erster Linie ist es möglich!
Ja klar ist sowas möglich, warum sollte sowas nicht möglich sein?
> Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-)
So ein Projekt ist beachtlich. Unbegreiflich für mich ist jedoch, warum
man es so implementiert, dass die Wiederverwendbarkeit stark
eingeschränkt ist (Atmel-Assembler) und es insbesondere unmöglich ist,
den Code von C aus zu verwenden.
Das ist doch überaus kurzsichtig. Vor allem weil es kein Mehraufwand
gewesen wäre, Wiederverwendbarkeit zu bieten.
Wenn man sich schon solche Arbeit macht, warum dann nicht so
programmieren, dass es möglichst vielseitig verwendbar ist?
Mir steht da echt der Mund offen ... nämlich wegen der dargebotenen
Kurzsichtigkeit.
Yalu X. schrieb:> Hier sind die Ergebnisse des Vergleichs:>> Speicherverbrauch in Bytes>> Mobys ASM Yalus C> ——————————————————————————————————> Flash 206 158> SRAM (Stack) 2 2> ——————————————————————————————————
Herrlich, im Ring heist das K.O. auf ganzer Linie.
Ich sehe Moby aber schon wieder das Maul aufreisen wegen ......... nun
ja wegen was wohl?
Nun ihm wird schon was einfallen.
Johann L. schrieb:> Mir steht da echt der Mund offen ... nämlich wegen der dargebotenen> Kurzsichtigkeit.
Ich sehe solche Ansätze eher in der Tradition jeder Spinner, die sich
zusammen mit möglichst vielen anderen Leuten in eine Telefonzelle
quetschen. Kann Spass machen und man ist hinterher stolz. Aber um
telefonieren geht es dabei üblicherweise nicht.
Gu. F. schrieb:> Yalu X. schrieb:>> Hier sind die Ergebnisse des Vergleichs:>>>> Speicherverbrauch in Bytes>>>> Mobys ASM Yalus C>> ——————————————————————————————————>> Flash 206 158>> SRAM (Stack) 2 2>> ——————————————————————————————————>> Herrlich, im Ring heist das K.O. auf ganzer Linie.> Ich sehe Moby aber schon wieder das Maul aufreisen wegen ......... nun> ja wegen was wohl?> Nun ihm wird schon was einfallen.
Hab es doch gesagt: Jeder findet seinen Meister.
Ich vermute: Yalu hat mehr ÜVS benötigt.
Yalu X. schrieb:> Das Programm wird gebaut mit>> avr-gcc-4.7.4 -mmcu=attiny13 -Os -nostdlib -o sensorboard sensorboard.c
Wie geht das denn nun am einfachsten?
Code einfach in ein Studio-Projekt für Tiny13 reinkopieren und Solution
builden/assemblieren wie bei Asm ist ja hier nicht.
Entsprechendes für ein GCC-Projekt erzeugt nur Fehlermeldungen.
Hilfe! Möchte für eine einfache .hex Erstellung nicht gleich im
C-Optionschaos versinken ;-(
Moby A. schrieb:> Wie geht das denn nun am einfachsten?
Debian installieren und das darin enthaltene Paket gcc-avr installieren.
Der ist zwar 4.7.2, liefert aber auch 158 Bytes ab. in Yalus
Kommandzeile ändert sich dann nur ebendiese Versionsnummer.
Ok, das ist natürlich hauptsächlich dann am einfachsten, wenn man
sowieso schon so eine Kiste rumliegen hat. ;-)
Gu. F. schrieb:> Setzt die hin und fang endlich an zu lernen.
Ganz sicher werd ich das jetzt nicht durcharbeiten nur um eine .hex
eines C-Codes zu erstellen ;-)
Einfach heißt: Code reinladen, compilieren, .hex!
A. K. schrieb:> Debian installieren und das darin enthaltene Paket gcc-avr installieren.
Köstlich. Genau das werd ich jetzt...
Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus
Code. Das wär schade.
Moby A. schrieb:> Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus> Code. Das wär schade.
Ich fand das toteinfach. Ich musste einfach nur Yalus Kommandozeile
ausführen. Der Rest war schon da.
Wenn du natürlich noch nicht einmal einen Compiler auf der Kiste hast,
dann wird es wirklich schwierig, den Compiler zu starten und somit
völlig unmöglich, deinen Forderungen nachzukommen. Aber das gilt
umgekehrt auch, weil meine Debian-Kiste mit deinem Asm-Quellcode genauso
über Kreuz liegt.
A. K. schrieb:> Wenn du natürlich noch nicht einmal einen Compiler auf der Kiste hast,
Wer sagt das? Mein Studio7 enthält einen. Ich kann problemlos ein
GCC-Projekt erstellen.
> Aber das gilt> umgekehrt auch, weil meine Debian-Kiste mit deinem Asm-Quellcode genauso> über Kreuz liegt.
Warum sollte sich mein Asm-Code dort nicht genauso assemblieren lassen
wie er auf dem Bildschirm erscheint?
Moby A. schrieb:> Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus> Code.
Ich habe doch extra für dich, auch weil du es so gefordert hast, das
Hex-File angehängt. Das schiebst du auf die gleiche Weise auf den
Controller wie du es mit mit deinen sonstigen Programmen tust.
Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt
nicht nur deine, sondern auch meine Fähigkeiten.
Moby A. schrieb:> Wer sagt das? Mein Studio7 enthält einen. Ich kann problemlos ein> GCC-Projekt erstellen.
Weshalb weigerst du dich dann, das zu tun?
> Warum sollte sich mein Asm-Code dort nicht genauso assemblieren lassen> wie er auf dem Bildschirm erscheint?
Weil auf genannter Debian-Kiste kein Assembler von Atmel drauf ist und
der GNU Assembler eine völlig andere Quellcode-Notation verwendet.
Yalu X. schrieb:> Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt> nicht nur deine, sondern auch meine Fähigkeiten.
Zuviel Bürokratie? ;-)
Yalu X. schrieb:> das> Hex-File angehängt.
Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da
wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern
hergestellt.
> Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt> nicht nur deine, sondern auch meine Fähigkeiten.
Klasse.
Das spricht für C ;-)
A. K. schrieb:> Weshalb weigerst du dich dann, das zu tun?
Wer sagt das ich mich weigere?
Von Fehlermeldungen bei der Projekterstellung / Buildvorgang hatte ich
doch schon gesprochen, oder?
Moby A. schrieb:> Das spricht für C ;-)
Yalu verwendet möglicherweise nicht das anerkannte Monster an
Bürokratie, das Atmel mit dem Studio 7 in die Welt gesetzt hat. Du
jedoch scheinst mit überbordender Bürokratie diesmal ausnahmsweise keine
Probleme zu haben. Denn so einen fetten Klops auf die Kiste zu wuchten,
bloss um einen ATtiny13 zu füttern, das spottet jeder Beschreibung.
A. K. schrieb:> Du> jedoch scheinst mit überbordender Bürokratie diesmal ausnahmsweise keine> Probleme zu haben.
Die Projekterstellung/Assemblierung selber ist wie beschrieben
ausgesprochen einfach.
> Denn so einen fetten Klops auf die Kiste zu wuchten,> bloss um einen ATtiny13 zu füttern, das spottet jeder Beschreibung.
Da spottet gar nichts denn damit wird nicht nur ein Tiny13 versorgt ;-)
Moby A. schrieb:> Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da> wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern> hergestellt.
Tut es auch der Asm-Output vom Compiler?
A. K. schrieb:> Tut es auch der Asm-Output vom Compiler?
Das ist wenigstens mal ein Angebot. Danke.
Freilich hätte ich dessen Erstellung schon gern selbst in der Hand.
Morgen schau ich erstmal was die .hex in meiner Hardware so treibt.
A. K. schrieb:> Und nochmal als Disassembly, mit C Quellcode zwischenrein gemixt.
OK. Prima.
Die Einarbeitung in Linux kommt allein für diese Geschichte hier nicht
in Frage.
Moby A. schrieb:> Die Einarbeitung in Linux kommt allein für diese Geschichte hier nicht> in Frage.
Wär wohl auch nicht nötig. Wahrscheinlich lässt sich im Studio
enthaltene GCC auch direkt per Kommandozeile aufrufen - wenn man weiss
wie. Aber das ist mir zu viel Bürokratie.
Gu. F. schrieb:> Nun ihm wird schon was einfallen.
Schon geschehen:
Moby A. schrieb:> Wie geht das denn nun am einfachsten?Moby A. schrieb:> Hilfe! Möchte für eine einfache .hex Erstellung nicht gleich im> C-Optionschaos versinkenMoby A. schrieb:> Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus> Code.Moby A. schrieb:> Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da> wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern> hergestellt.
Einfach nur erbärmlich.
mfg.
Thomas E. schrieb:> Einfach nur erbärmlich.
Alles berechtigte Einwände und Fragen für jemanden der die Wissenschaft
"C" bisher nicht nötig hatte. Erbärmlich ist eher Deine (fehlende)
Antwort darauf ;-)
Moby A. schrieb:> Yalu X. schrieb:>> das>> Hex-File angehängt.>> Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da> wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern> hergestellt.
Du glaubst also, ich schummle, und das Hex-File stammt in Wirklichkeit
von einem Assemblerprogramm, das ich in mühevoller Arbeit mit viel ÜVS
von Hand geschrieben habe?
Und A. K. unterstützt mich auch noch bei meiner Schummelei, indem er
einen angeblichen Asm-Output des Compiler postet, den er in Wirklichkeit
von mir zusammen mit einem Barscheck zugesandt bekommen hat?
Die beiden Compiler-Versionen erzeugen übrigens exakt den gleichen Code,
die Asm-Outputs unterscheiden sich nur in der nicht relevanten letzten
Zeile:
Bitte zu den Programmanforderungen hinzufügen:
- muß von jeden V..horst, der keinen Bock hat sich damit zu befassen von
Sourcecode aus direkt in den ATtiny13 geflashed werden können.
Was hatte irgendwer schon mal geschrieben: er wird neue Anforderungen
finden, die das C-Programm nicht erfüllt.
Carl D. schrieb:> - muß von jeden V..horst, der keinen Bock hat sich damit zu befassen von> Sourcecode aus direkt in den ATtiny13 geflashed werden können.
Einfaches Handling ist auch ein Aspekt der Bürokratie. Asm bietet das. C
wie wir gesehen haben nicht.
> Was hatte irgendwer schon mal geschrieben: er wird neue Anforderungen> finden, die das C-Programm nicht erfüllt.
Solche Vorhersagen kannst Du in der Pfeife rauchen. Beschäftige Dich mit
dem was hier eigentliches Thema ist, dann siehst Du auch für die Zukunft
klarer. Und wenn ein
Carl D. schrieb:> nicht“Gast“ schrieb:>> Warte nur, bis Moby hier aufschlägt. Der weiß wirklich Bescheid, was man>> so alles auf einen Atmel braucht. ;)>> Dann werde ich sofort von Jörg W.'s Angebot Gebrauch machen, ihn> rausbekamen zu lassen.
beweist er nur, das oberste Level an Ratlosigkeit erreicht zu haben.
Auch wenn die kleine Unsicherheit im entscheidenden Wort noch etwas Raum
zur Hoffnung lässt ;-)
Blöd auch daß Jörg Wort gehalten hat. Danke!
Und zu "Bürokratie":
Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu
kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt
ab.
Yalu X. schrieb:> Die beiden Compiler-Versionen erzeugen übrigens exakt den gleichen Code,> die Asm-Outputs unterscheiden sich nur in der nicht relevanten letzten> Zeile:>> $ diff sensorboard-yalu.s sensorboard-ak.s> 138c138> < .ident "GCC: (GNU) 4.7.4"> --->> .ident "GCC: (GNU) 4.7.2"
Yalu, du weißt ja schon um die Kryptischen DIFF ausgaben verstehen zu
können man einige Wochen Einarbeitungszeit benötigt.
Das ist viel zu komplex und bürokratisch.
Und wehe Du hast auch noch den DIFF umgeschrieben ....
Yalu X. schrieb:> Du glaubst also, ich schummle, und das Hex-File stammt in Wirklichkeit> von einem Assemblerprogramm, das ich in mühevoller Arbeit mit viel ÜVS> von Hand geschrieben habe?
Nein. Das glaube ich nicht.
Trotzdem wird es doch wohl legitim sein zu verlangen, daß ich Deinen C
Code selbst nachvollziehen kann.
Interessant wär mal der hier schon oft erwähnte Aspekt der
Entwicklungszeit: Etwa von Beitrag 1 dieses Threads an? Oder gar von
noch früher? (meinen Projektthread gibts ja schon ne ganze Weile)
;-)
Carl D. schrieb:> Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu> kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt> ab.
Du wirst mir sicher gleich sagen, wo das in der AtmelStudio- Software
bloß "einzutippen" ist. Zeig Deinen "Interlekt" mal ;-)
Markus M. schrieb:> Start > Ausführen > CMD.EXE
Na probiers mal. Was dann wohl kommt???
Ich hoffe doch schon, daß ein MS Windows und ein fettes 7er Studio
auslangen ;-)
Tipp: Du hast
Yalu X. schrieb:> Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt> nicht nur deine, sondern auch meine Fähigkeiten.
überlesen ;-)
Robert L. schrieb:> projekt anlegen> code rein kopieren> ja, man bekommt einen fehler> -> checkbox für nostdlib suchen> -> optimierung hoch stellen> schon gehts..
Danke Robert. Das schau ich mir nochmal an.
be s. schrieb:> frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur> wenige simple Berechnungen durchgeführt werden.
Die Sorge möchte ich Dir nehmen.
1M war etwas ironisch gemeint ;-)
le x. schrieb:> - SRAM ist natürlich die Wichtigste, die Kostbarste. Denn mit ihr steht> und fällt die Möglichkeit, seinen Code mit C zu schlagen.
Na vielleicht stimmt das ja gar nicht ?
Morgen sehen wir weiter.
Man Leute, gestern wäre das hier bei 1985 fast eingeschlafen.. Jetzt
stehts bei 2047..
Und Yalu hat nochmal bewiesen, was ausser Moby alle wussten.
Sodann: Grossartig und Skoll:
>der heute bis 24 Uhr einen Beitrag in>diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D
bleibt nur noch eins zu sagen:
Matthias L. schrieb:> Man Leute, gestern wäre das hier bei 1985 fast eingeschlafen..> Jetzt stehts bei 2047..
Ich hatte die Hoffnung, dass da bei 2000 nochmal Schwung in die Sache
kommt... ;-)
Yalu X. schrieb:> Damit hat Lothar seine Wette grandios gewonnen. Gratulation!
War ja einfach...
> Ich freue mich schon riesig auf das Bier, das er Gerüchten zufolge> ausgeben will :)
Du darfst dir auch eines aufmachen. Das hast du dir verdient. Aber echt:
ein Code der abzüglich der unnötigen Kommentare und trotz der vielen
Umbrüche komplett auf eine Seite passt. Genial!
So, anbei noch ein Atmel Studio7-Projekt. Ich hoffe mal, dass die
getroffenen Einstellungen alle mitgesichert werden.
PS. Ich sehe gerade mein Kompilat hat noch 166 Bytes Verbrauch, also
habe ich wohl einen Einstellungsfehler. Aber die Größe reicht ja auch.
A. K. schrieb:> Wahrscheinlich lässt sich im Studio enthaltene GCC auch direkt per> Kommandozeile aufrufen - wenn man weiss wie.
Dazu täte es einfach not, dass man, statt auf andere Betriebssysteme
zu schimpfen, in die man sich nicht „einarbeiten“ will, sich wenigstens
mal in das auserwählte eigene Betriebssystem einarbeitete, um ein
Konzept wie das des Suchpfades verstanden zu haben.
Dummerweise übernimmt das Gigabyte-Monster von Atmel es halt nicht
automatisch, den Suchpfad zum Compiler selbst im System einzutragen.
Wäre wohl zu viel Bürokratie.
Das Ändern der PATH-Variablen in Windows hat allerdings eines der
grauenvollstens GUIs, die es gibt. Man bekommt auf einen Pfadnamen
von in der Regel mehreren hundert Zeichen Länge nur ein kleines
Guckloch. Während sonst jeder Ar***h heutzutage im Vollbildmodus
starten will (wen interessiert schon, dass der Monitor 1900 Zeichen
breit ist und viel Platz für anderes böte, wenn man sich gerade die
Smartphone-Welt als Ziel ausgemacht hat?), kann man dieses beknackte
GUI auch nicht in der Größe ändern.
Jörg W. schrieb:> Das Ändern der PATH-Variablen in Windows hat allerdings eines der> grauenvollstens GUIs, die es gibt.
Und je nach Windows Version ist schon allein die Suche nach diesem
Dialog ziemlich spannend.
Moby A. schrieb:> Interessant wär mal der hier schon oft erwähnte Aspekt der> Entwicklungszeit: Etwa von Beitrag 1 dieses Threads an? Oder gar von> noch früher? (meinen Projektthread gibts ja schon ne ganze Weile)
Dir ist wirklich nichts zu peinlich, oder? Schau mal nach, seit wann es
die von dir bestätigte Programmspezifikation gibt. Bei deiner
schlangenartigen Argumentationsweise in diesem und anderen Threads, bin
ich mir sicher, dass niemand vorher ernsthaft angefangen hat.
Yalu wird vermutlich heute vormittag, nach einem erquicklichen Schlaf
und einem reichhaltigen Frühstück, die Zeit bis zum Mittag genutzt
haben, um das Programm zu schreiben. Nach dem Mittag und dem
dazugehörigen Schläfchen hat er es dann veröffentlicht.
Das war ja einfach.
Jay W. schrieb:> PS. Ich sehe gerade mein Kompilat hat noch 166 Bytes Verbrauch, also> habe ich wohl einen Einstellungsfehler.
Oder eine andere Version des Compilers. Robert kam beim Studio 6.2 mit
GCC 4.8.1 auch auf 166 Bytes.
A. K. schrieb:> Oder eine andere Version des Compilers. Robert kam beim Studio 6.2 mit> GCC 4.8.1 auch auf 166 Bytes.
Korrekt. Im Studio 7 werkelt ein GCC 4.9.2
A. K. schrieb:> Und je nach Windows Version ist schon allein die Suche nach diesem> Dialog ziemlich spannend.
Gibts da nicht, um diese horrende Bürokratie zu umgehen, einen kleinen
asm-Befehl dafür?
Jetzt noch eine CommandLine Einweisung?
Ist ja schon klar, dass DOS erst NACH Assembler erfunden wurde. Daher
kann Moby das nicht wissen.
PATH=%PATH%;<PfadZumGCCfürAVR>
Damit ist dies für die aktuelle Console-Sitzung aktiv.
Moby A. schrieb:> Carl D. schrieb:>> Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu>> kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt>> ab.>> Du wirst mir sicher gleich sagen, wo das in der AtmelStudio- Software> bloß "einzutippen" ist. Zeig Deinen "Interlekt" mal ;-)
Jemand, der Assembler wegen Kompaktheit und Klarheit benutzt UND etwas
von der Materie versteht (also ein Programmierer), der benutzt
normalerweise kein "Studio" oder IDE, auch keine GUI, sondern eine
Shell. Damit hat er nämlich die Klarheit, wie es funktioniert, und damit
wirklich alles in der Hand.
Der kann dann auch das Kommando von Yalu einfach aufrufen.
Wer das nicht kann, sollte mal ganz klein das lernen anfangen, statt nur
heisse Luft zu produzieren.
Moby, Du hasts geschafft, dich wird keiner mehr ernst nehmen....einem
Schüler hätte man das noch abgenommen, aber einem, der behauptet, seit
20 Jahren zu programmieren..
Yalu X. schrieb:> Speicherverbrauch in Bytes>> Mobys ASM Yalus C> ——————————————————————————————————> Flash 206 158> SRAM (Stack) 2 2> ——————————————————————————————————
Vielen Dank, Yalu! :-) Und Moby windet sich einmal mehr wie eine
Schlange, obwohl nun wirklich alles bewiesen ist. Hätte er auch nur ein
Fünkchen Respekt und Anstand, so würde er eingestehen, dass er sich
geirrt hat. Das wäre übrigens der geringere Gesichtsverlust, als was er
aktuell abzieht...
A. K. schrieb:> Robert kam beim Studio 6.2 mit> GCC 4.8.1 auch auf 166 Bytes.
Auf die komme ich mit Studio7 auch, unter den Projekt-Optionen war bei
AVR/GNU Linker unter General noch ein Häkchen bei "No startup or default
libs (-nostdlib)" zu setzen. Manchmal ist's doch einfacher als man
denkt.
Diese 166 Bytes sind jetzt für mich maßgeblich und genau die teste ich
auch, es sei denn jemand liefert unter Studio7 noch passendere Optionen.
Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182
Bytes.
Mein Code erreicht mit gestrichener Ram- + Sleep-Initialisierung 196
Bytes. Irgendwelche weiteren Grundinitialisierungen lasse ich mir da
nicht zuaddieren weil die in der Praxis ohne Bedeutung sind.
Vorbehaltlich eines genaueren Funktionsvergleichs (hab nur mal kurz
drübergeschaut) und des Funktionstests auf realer Hardware hat C damit
eine Leistungsfähigkeit im Ressourcenverbrauch demonstriert die mich
beeindruckt hat. Positiv möchte ich außerdem vermerken, daß dazu laut
Listing nicht allzuviele Register verwendet wurden. Schaut also bislang
gut aus.
Bernhard M. schrieb:> der benutzt> normalerweise kein "Studio" oder IDE, auch keine GUI, sondern eine> Shell. Damit hat er nämlich die Klarheit, wie es funktioniert, und damit> wirklich alles in der Hand.
Das würde ich als Rückschritt sehen. Das Studio ist schon, bei aller
Größe, zumindest bei Assemblerprogrammierung sehr komfortabel und
einfach.
"In der Hand haben" möchte ich auch nicht tausend C-Compiler Optionen
sondern nur meinen Code!
Jay W. schrieb:> Dir ist wirklich nichts zu peinlich, oder? Schau mal nach, seit wann es> die von dir bestätigte Programmspezifikation gibt.
Das Programm samt zugehöriger "Projektchen"-Beschreibung gibts
weitgehend unverändert seit 5.September. Also theoretisch viel Zeit sich
vorzubereiten ;-)
Vielleicht möchte sich Mod Yalu ja noch dazu äußern, wielang er dran
gefeilt hat? Das Thema Entwicklungszeit kam in seinem Beitrag auffällig
kurz ;-)
P. M. schrieb:> Und Moby windet sich einmal mehr wie eine> Schlange, obwohl nun wirklich alles bewiesen ist. Hätte er auch nur ein> Fünkchen Respekt und Anstand, so würde er eingestehen, dass er sich> geirrt hat. Das wäre übrigens der geringere Gesichtsverlust, als was er> aktuell abzieht...
Nun sprich mir mal nicht vorschnell Respekt und Anstand ab. Den von Dir
gewünschten Gesichtsverlust eines anonymen Moby wirst Du auch nicht
erleben, immerhin bekam der die Funktionalität in wenigen Bytes mehr
ohne jedes Compiler-KnowHow zusammen- während Dein und anderer
"Experten" KnowHow meist gerade mal für höhnische Kommentare langte ;-)
Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das
nehm ich mal als Ansporn!
Mehr dazu und ggf. zur "Preisverleihung" dann im Laufe des Sonntags!
nur mal zur Erinnerung, Moby war der Meinung man könne SEINEN
optimierten! Code überhaupt nicht in C schlagen..
Moby A. schrieb:> Markus M. schrieb:>> Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich>> zurück mit Falschaussagen>> Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt> gezeigt wurde nicht geschlagen und ist nicht zu schlagen. Höchstens in> gewissen Wunschfantasien ;-) Speziell Dein Beitrag dazu war bislang> überschaubar und fachlich: nicht vorhanden.
auf die Entwicklungszeit rausreden wird auch schwierig:
es ist ein Wunder, dass überhaupt jemand sich die Mühe gemacht hat,
dieses doch recht unnütze Projekt* nochmal in C zu schreiben
(ich hätte nicht damit gerechnet)
und niemand weiß wie lange Moby gebraucht hat, für die "fehlerfreie"**
Version
*Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
**es wird ja scheinbar unnötigerweise der ganze Speicher initialisiert,
aber die wichtigen Sachen nicht.. erst Yalu hat das korrigiert
A. K. schrieb:> Moby A. schrieb:>> Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182>> Bytes.>> Warum?
Weil Yalu bezüglich Optimierung weiter gedacht hat als Moby, das ist
nicht erlaubt!
Moby A. schrieb:> Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das> nehm ich mal als Ansporn!
Je schlechter einer ist, desto grösser ist sein Verbesserungspotential.
Auf die Steigerungsfähigkeit muss das indes nicht zutreffen. ;-)
Moby A. schrieb:> Vorbehaltlich eines genaueren Funktionsvergleichs (hab nur mal kurz> drübergeschaut) und des Funktionstests auf realer Hardware hat C damit> eine Leistungsfähigkeit im Ressourcenverbrauch demonstriert die mich> beeindruckt hat. Positiv möchte ich außerdem vermerken, daß dazu laut> Listing nicht allzuviele Register verwendet wurden. Schaut also bislang> gut aus.
Dieses Eingeständnis möchte ich nach dieser überaus zähen und sich
ständig im Kreis drehenden ewigen Diskussion als sehr positiv zu
wertendes Ergebnis ansehen.
Speicherverbrauch in Bytes
Mobys ASM Yalus C
——————————————————————————————————
Flash 206 158
SRAM (Stack) 2 2
——————————————————————————————————
Schon gut Moby. Oben stehen die Fakten. Glasklar. Auch dein
unangenehmer, ab vorhersehbarer Versuch, neue Anforderungen
hervorzuzaubern oder Bytes abzuziehen (bei dir) oder hinzuzurechnen (bei
Yalu) ändert daran nichts.
Deine Einlassungen zum Studio sind auch wieder ein Kleinod der
Rabulistik. Gerade wenn man, so wie du, Probleme hat sich ein paar
Konsolenkommandos und Compilerschalter zu merken, ist das Studio im
Vorteil. Es nimmt einem nämlich diese "Bürokratie" ab.
Rufus Τ. F. schrieb:> Hey, mach die Diskussion nicht kaputt, in dem Du Moby Dinge vorwirfst,> die er mittlerweile selbst eingesehen hat.
Na gut, warten wir den weiteren Verlauf ab. Vielleicht behältst du
recht.
Moby A. schrieb:> A. K. schrieb:>> Robert kam beim Studio 6.2 mit>> GCC 4.8.1 auch auf 166 Bytes.>> Auf die komme ich mit Studio7 auch, unter den Projekt-Optionen war bei> AVR/GNU Linker unter General noch ein Häkchen bei "No startup or default> libs (-nostdlib)" zu setzen. Manchmal ist's doch einfacher als man> denkt.>> Diese 166 Bytes sind jetzt für mich maßgeblich und genau die teste ich> auch, es sei denn jemand liefert unter Studio7 noch passendere Optionen.
Nur, weil du eine schlechtere Compiler-Version genommen hast als ich?
Ich könnte ja andersherum genauso argumentieren, dass ich hier einen
ganz schlechten Assembler habe, der nach jedem Befehl automatisch noch
einen NOP einfügt. Damit sind bei deinem Code für mich nicht die 216
Bytes, sondern 432 Bytes maßgeblich.
In der Spezifikation ist nirgends vorgegeben, welcher C-Compiler zu
benutzen ist, d.h. jeder von uns beiden wählt die Tools, die er für
richtig hält oder die er auch sonst benutzt.
Für mich der GCC 4.7.4 der derzeitige Standard, den ich für alle meine
Projekte verwende. Für dich wird er es wahrscheinlich ebenso sein, falls
du dich demnächst dazu entschließen solltest, tiefer in C einzusteigen.
Im Gegensatz zum IAR-Compiler, der den Code vermutlich noch etwas besser
optimiert hätte, ist der GCC sogar frei, so dass du – wie auch jeder
andere hier im Forum – die Ergebnisse nachzuvollziehen kannst, ohne dass
dir dadurch irgendwelche Kosten entstehen.
Aber sei's drum. Da C so viel ressourcensparender als Assembler ist und
ich keine Lust auf eine Diskussion darüber habe, werde ich die 8 Bytes
eben opfern.
Zumal ich stark bezweifle, dass du in der Lage wärst, den GCC 4.7.4 auf
deinem PC zu installieren ;-)
> Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182> Bytes.
Nur weil du nicht auf dieselbe Idee gekommen bist und dein Code deswegen
unnötig aufgebläht ist? Ich dachte, hier geht es darum, keine wertvollen
Ressourcen zu verschwenden. Wenn du dir das nicht zu Herzen nimmst, ist
das doch nicht mein Problem, sondern deins, oder?
Aber sei's drum. Da C so viel ressourcensparender als Assembler ist und
ich keine Lust auf eine Diskussion darüber habe, werde ich eben auch
diese Bytes opfern.
Es sind aber nicht nicht 16, sondern 18 Bytes, die ich eingespart habe:
Die 10 RJMPs in der Vektortabelle minus 1 RJMP, der nötig ist, um im
Initialisierungscode den über in Weg liegenden Interrupthandler zu
springen, also 9·2 Bytes = 18 Bytes.
Das um die vollständige (wenn auch unnütze) Interruptvektortabelle
erweiterte Programm habe ich angehängt.
> Mein Code erreicht mit gestrichener Ram- + Sleep-Initialisierung 196> Bytes.
Das Entfernen der RAM-Initialisierung und des Sleeps ist in Ordnung,
weil das ja vorher schon so vereinbart war.
> Irgendwelche weiteren Grundinitialisierungen lasse ich mir da nicht> zuaddieren weil die in der Praxis ohne Bedeutung sind.
Das ist nicht in Ordnung. Warum sollten wir so einen Pfusch zulassen?
Außerdem steht in der von dir bestätigten Spezifikation geschrieben:
Moby A. schrieb:>> jeder Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2)>> Richtig.
Sind die Summenregister anfangs uninitialisiert, ist das aus den ersten
8 ADC-Messwerten jedes Kanals berechnete Ergebnis nicht der Mittelwert,
sondern irgendetwas Zufälliges, was ganz klar gegen die Spezifikation
verstößt.
Ich bestehe deswegen darauf, dass du auch bei dir die Summenregister
anfangs auf 0 setzt. Wie du das machst, ist mir egal. In meinem obigen
Beitrag habe ich dir ja schon verraten, wie du statt mit 8 zusätzlichen
Bytes (für 4 CLRs) auch mit nur 6 Bytes auskommen kannst.
Die Codegröße deines gemäß der Spezifikation korrigierten Programms
beträgt also
202 Bytes
Auf Grund massivster Zugeständnisse meinerseits, die in keiner Weise von
der Spezifikation gefordert waren, wächst die Codegröße meines Programms
von 158 Bytes auf
184 Bytes
Zu weiteren Zugeständnissen bin ich aber definitiv nicht bereit!
Diese Ergebnisse
202 Bytes vs. 184 Bytes
sind fix.
Sie werden nur noch dann geändert, wenn sich herausstellt, dass eines
der Programme fehlerhaft ist oder anderweitig nicht der Spezifikation
entspricht. Dann wird dieses Programm von seinem Autor korrigiert und
die Größe neu bestimmt.
Moby A. schrieb:> Nun sprich mir mal nicht vorschnell Respekt und Anstand ab. Den von Dir> gewünschten Gesichtsverlust eines anonymen Moby wirst Du auch nicht> erleben, immerhin bekam der die Funktionalität in wenigen Bytes mehr> ohne jedes Compiler-KnowHow zusammen
Aha. Du gibts also implizit zu, dass es ein Compiler doch besser macht,
als der Mensch?
Yalu X. schrieb:> Da auch ich nicht mit leeren Händen zur Party kommen möchte, habe ich> eine C-Portierung von Mobys sensationellem 8-Bit-MSR-Assemblerprogramm> mitgebracht, von der sich jeder, der heute bis 24 Uhr einen Beitrag in> diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D
Meine Hochachtung, Yalu!
Jay W. schrieb:> Deine Einlassungen zum Studio sind auch wieder ein Kleinod der> Rabulistik.
Welche meinst Du?
Jörg W. schrieb:> Dazu täte es einfach not, dass man, statt auf andere Betriebssysteme> zu schimpfen,
Wer hat über andere Betriebssysteme geschimpft?
Nur weil ich es für ein Unding empfinde, für eine simple C-Compilierung
erst ein Linux installieren zu müssen?
Robert L. schrieb:> auf die Entwicklungszeit rausreden
Nun seht mal nicht alles durch die "Ausreden"-Brille.
War ja nur ne Frage. Eine berechtigte allerdings, da mir das Thema
Entwicklungszeit ja öfter vorgehalten wurde ;-)
A. K. schrieb:> Moby A. schrieb:>> Hinzu kommen 16 Bytes für die bei Yalu gesparten Int-Vektoren. Macht 182>> Bytes.>> Warum?
Weil mein Code vielleicht seine Vektortabelle auch behalten hat?
Nun seht mal nicht alles durch die "Wer gewinnt" Brille.
Mich interessierte in erster Linie die Leistungsfähigkeit von C; zu
meinem Glück fand sich jemand der dazu in der Lage war es endlich zu
demonstrieren. Manch anderer "Experte" hatte ja selbst in Frage
gestellt, daß C für Programme dieser Größenordnung und ohne
RAM-Verwendung Erfolg beim Ressourcensparen verspricht ;-)
So frage ich mich schon, ob nicht doch erheblich mehr KnowHow im Umgang
mit C vonnöten ist wenn Yalu's Ergebnis erreicht werden will.
Rufus Τ. F. schrieb:> Dieses Eingeständnis möchte ich nach dieser überaus zähen und sich> ständig im Kreis drehenden ewigen Diskussion als sehr positiv zu> wertendes Ergebnis ansehen.
So schauts aus.
Meine Funktionsprüfung auf Hardware gibt nun grünes Licht:
Alles funktioniert wie erwartet. Der Zeitablauf ist etwas gedehnter als
bei meinem Code (Das genaue Timing ist nicht gleich, z.B. Sync-Pause
20ms länger- Warum?), aber meine fertige Auswerteroutine kam natürlich
auch damit klar. So eine separate Taktleitung hat schon was Gutes ;-)
Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten
von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn:
DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER
Vielen Dank für Deine Mühe, das Ergebnis hat mich überrascht und hab ich
was bei gelernt. Insbesondere finde ich gut, daß Du Dich weitestgehend
an die vorgegebene Programmarchitektur gehalten hast, was die Codes gut
vergleichbar macht!
Etwas Kontra zu Deinen weiteren Erläuterungen wirst Du nun sicher noch
vertragen:
Yalu X. schrieb:> Als einzige Vorteile von Assembler gegenüber C bleiben also die simple> Codierung und die geringere "Bürokratie". Beide Kriterien lassen sich> aber leider weder klar definieren noch objektiv messen, weswegen sich> bzgl. dieser Punkte am besten jeder sein eigenes Bild macht.
Davon rücke auch nicht ab- aber Du hast Recht, das soll jeder für sich
entscheiden und es ist nicht notwendig, dies weitere 1000 Beiträge zu
diskutieren.
> sum.all /= 8;>> zur Berechnung des Mittelwerts meiner Meinung nach nicht nur leichter zu> schreiben, sondern auch besser zu verstehen als ...
Natürlich. Auch wenn sich das kryptische in diesem Ausdruck schon
andeutet. Daß sich viele Berechnungen so vorhanden in C besser abhandeln
lassen hatte ich doch mehrmals betont.
> In C ist es aber ein Leichtes, auch die komplette Pinbelegung und die> Taktfrequenz der Datenübertragung konfigurierbar zu machen. Einiges> davon ginge sicher auch in Assembler ...
So ist es. Und zwar das was nötig ist.
> Das Schöne dabei: Der Compiler ändert bei einer Umkonfiguration ...
Solchen Notwendigkeiten bin ich bislang durch vorherige Abklärung der
Aufgabenstellung erfolgreich aus dem Weg gegangen ;-)
> Bürokratie hat ja etwas mit Verwaltungswahn zu tun. Anders als in C> obliegt in Assembler die Verwaltung der einzelnen Register und des> Datenspeichers komplett dem Programmierer.
Das ist das Wenigste. Mit einem Register-System allemal. Dann ist da
auch keine "Buchführung" nötig. 32 Register langen schon eine ganze
Weile!
Größere Datenmengen können ein Fall für den C-Compiler sein.
Im SmartHome fallen die weder an einzelnen Aktor/Sensorknoten noch in
kleinen lokalen Steuerungen an.
> In diese Falle ist trotz ÜVS sogar der Meister höchstpersönlich getappt,> als er eins seiner anderen Miniprogrämmchen schnell mal um ein paar> scheinbar triviale Dinge erweitern wollte, wodurch halt zufälligerweise> einer der hinzugefügten Befehle an ungünstiger Stelle das Carryflag> überschrieb:
Ja ja sogar der "Meister"... Meist passiert das nur wenn man mal
schnell was fürs Forum fertig macht ;-)
99% der Fehlersuche dreht sich aber nicht um solche Trivialitäten.
Hatte ich auch schon mal gesagt.
> In höheren Programmiersprachen ist für solche Buchhaltertätigkeiten ganz> klar der Compiler zuständig, der auch bei komplexen Programmen nie den> Überblick verliert.
Die sogenannten "Buchhaltertätigkeiten" sorgen aber für Ef....- fast
hätt ichs ausgesprochen ;-) OK, sogesehen ein Pluspunkt für C.
> weil es einfach> viel zu viel Bürokratie wäre, über das alles im Detail Bescheid wissen> zu müssen
Speicherverwaltung ist keine Bürokratie. Die genauen Locations
verschiedener Variablen interessieren mich auch nicht, es sein denn, man
macht eine RAM Adresse zum Bestandteil des Codes (z.B. bei Erreichen
einer bestimmten Pointerposition). Generell muß man das Thema der
Hardware-Verwaltung bei AVR nicht so hoch hängen, soviel ist da nicht zu
verwalten.
Interessanterweise ist es Moby, der unbedingt auf die Verwendung der 2
Bytes SRAM besteht. Das C Programm käme auch ohne Einschränkung der
Funktion locker auch völlig ohne SRAM aus. Nur müsste man dann Mobys
Forderungskatalog etwas lockerer interpretieren, indem man zwar die
Interrupt-Logik des Timers nutzt, nicht aber die des Prozessors.
A. K. schrieb:> Interessanterweise ist es Moby, der unbedingt auf die Verwendung der 2> Bytes SRAM besteht. Das C Programm käme auch ohne Einschränkung der> Funktion locker auch völlig ohne SRAM aus.
Weniger wäre mir egal gewesen, die Funktion entscheidet.
Ohne Verpacken/Kapseln der Funktionalität in einem Interrupt hätte
natürlich auch ein Asm-Programm keinen Stack benötigt ;-)
Moby A. schrieb:> Weniger wäre mir egal gewesen, die Funktion entscheidet.
Ei gucke da! Inwieweit hätten denn 30 Bytes mehr SRAM und 300 Bytes mehr
Flash diese Funktion beeinträchtigt?
A. K. schrieb:> Inwieweit hätten denn 30 Bytes mehr SRAM und 300 Bytes mehr> Flash diese Funktion beeinträchtigt?
Eine dumme Frage, A.K.
Schließlich ging es um den Vergleich, welche Sprache mit weniger
Ressourcen auskommt ;-)
Yalu X. schrieb:> Ich könnte ja andersherum genauso argumentieren, dass ich hier einen> ganz schlechten Assembler habe, der nach jedem Befehl automatisch noch> einen NOP einfügt.
Das ist aber jetzt kein elegantes Argument ;-)
Ein Assembler übersetzt immer was da steht.
Nicht einmal besser oder einmal schlechter.
Moby A. schrieb:> Schließlich ging es um den Vergleich, welche Sprache mit /weniger/> Ressourcen auskommt ;-)
Eben. Die besagte Variante benötigt sogar im RAM weniger Ressourcen.
Und nun ist das auf einmal egal?
Moby A. schrieb:> Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten> von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn:>> DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER>> Vielen Dank für Deine Mühe, das Ergebnis hat mich überrascht und hab ich> was bei gelernt. Insbesondere finde ich gut, daß Du Dich weitestgehend> an die vorgegebene Programmarchitektur gehalten hast, was die Codes gut> vergleichbar macht!
Mein vorhin schon ausgedrücktes Lob an Moby für diesen Abschluss des
Threads sei an dieser Stelle wiederholt.
Moby A. schrieb:> Schließlich ging es um den Vergleich, welche Sprache mit weniger> Ressourcen auskommt ;-)
So dumm ist die Frage nicht.
Wieviel Prozent belegt das aktuelle Programm von den *sowieso
vorhandenen* Ressourcen? Was geschieht mit dem vielen unbenutzten
Ressourcen? Welche möglichen Erweiterungen würde in diesem Fall denn
Sinn machen?
Wieviel Zeit hast Du in die Entwicklung des asm und Yalu in die
Entwicklung gesteckt? Auch das sind Ressourcen.
Yalu X. schrieb:> Sind die Summenregister anfangs uninitialisiert, ist das aus den ersten> 8 ADC-Messwerten jedes Kanals berechnete Ergebnis nicht der Mittelwert,> sondern irgendetwas Zufälliges, was ganz klar gegen die Spezifikation> verstößt.>> Ich bestehe deswegen darauf,
Darüber wollen wir nicht streiten.
In der Theorie hast Du Recht, für meine Praxis ist das unbedeutend.
> Zumal ich stark bezweifle, dass du in der Lage wärst, den GCC 4.7.4 auf> deinem PC zu installieren ;-)
Wenn ich das nicht schaffen würde dann sicher eine Menge mehr.
Kein Argument für C ;-)
> Nur weil du nicht auf dieselbe Idee gekommen bist und dein Code deswegen> unnötig aufgebläht ist?
Diese sogenannte "Idee" wurde schon in meinem Projektthread
angesprochen.
Was bereits da steht lädt gleich zur Erweiterung ein ;-)
> Zu weiteren Zugeständnissen bin ich aber definitiv nicht bereit!
Entspann Dich bitte, Mod Yalu. Der Fight der Systeme ist vorbei ;-)
Matthias L. schrieb:> Wieviel Zeit hast Du in die Entwicklung des asm und Yalu in die> Entwicklung gesteckt? Auch das sind Ressourcen.
Darauf werden wir hier keine erschöpfende nachprüfbare Auskunft mehr
bekommen... Mein Code entstand bereits im September. An einem Nachmittag
;-)
Moby A. schrieb:> So frage ich mich schon, ob nicht doch erheblich mehr KnowHow im Umgang> mit C vonnöten ist wenn Yalu's Ergebnis erreicht werden will.
Es hätte wohl normalerweise niemand so als Projekt angefangen.
Wenn es mein Projekt wäre, hätte ich:
1) Einen ATtiny25 genommen, wegen der USI, die einem bei der seriellen
Kommunikation einen Großteil der Arbeit abnimmt. Hätte außerdem den
Vorteil, dass der dortige ADC in der Lage ist, die Versorgungsspannung
zu messen, ohne dass man externe Hardware braucht (indem man Vref gegen
Vcc als Referenz misst). So kann man noch ein Flag mit durchreichen,
dass die Batterie gewechselt werden muss. Ernsthaft mehr Geld kostet
das Ding ja sowieso nicht.
2) Die Daten an Bytegrenzen ausgerichtet. Das macht die Sache
ringsum viel einfacher, auch wenn man ein paar Bits verschwendet
bei der Übertragung, weil man für 10 Bit Analogwert 2 Byte braucht.
3) Eine ordentliche CRC benutzt, mindestens eine 8-Bit-CRC. Da haben
Generationen von Ingenieuren einfach schon genug Gedanken reingesteckt,
wie man Übertragungsfehler möglichst sicher erkennt, das muss ich nicht
ignorieren.
Konkreter RAM- und Flash-Verbrauch wäre ohnehin egal, solange alles
mit ausreichend Reserve (für Erweiterungen, wobei mehr als 50 % bei
beiden auf jeden Fall als „ausreichend“ genügt) in den ATtiny25 passt.
Mit diesen Prämissen hätte man das wohl problemlos an einem Abend
umgesetzt, einschließlich Funktionstest.
Meine Hochachtung an Yalu für seine erwiesene Geduld!
Jörg W. schrieb:> Wenn es mein Projekt wäre, hätte ich:>
Eine vernüftiges (fertig entwickeltes) Protokol benutzt, das nicht für
jeden Sensor 2 PortPins benutzt. Bei der geforderten Bitrate hätte
OneWire auf einen PortPin einige zig Temperaturen messen. Bei Bedarf
kann man einen Slave auch in einen ATtiny13 pressen (in C):
https://www.tm3d.de/index.php/1-wire-device-mit-avr
Und damit könnte man alles was das Moby-Board macht auch tun. Nur eben
z.B. direkt an Raspberry anschließbar, Software eingeschlossen.
Ja, der Link hat natürlich keine fertige .HEX für M.'s Anforderungen und
auf dem Tiny13 ist etwas zu wenig Platz für alle Busfunktionen. Ab
Tiny25 ist das dann aber ein vollwertiges OneWire-Device. Und für
Temperatur einfach mal einen Ds18b20 an den Bus klemmen ist dann auch
drin.
Moby A. schrieb:> Alles funktioniert wie erwartet.
Juhu! :)
> Der Zeitablauf ist etwas gedehnter als bei meinem Code
In meinem Programm wird OCR0A so gesetzt, dass bei der nominellen
Oszillatorfrequenz (128 kHz) das Timing exakt stimmt:
1
OCR0A = 128000 / 64 / 200 - 1 = 9
Du hingegen hast OCR0A auf 7 gesetzt, um die Abweichung der
tatsächlichen von der nominellen Oszillatorfrequenz auszugleichen.
Wenn du die tatsächliche Frequenz kennst und du sie in Zeile 16
1
#define F_CPU 128000
einträgst, berechnet der Compiler automatisch den optimalen Wert für
OCR0, und das Timing sollte dann ziemlich genau stimmen. Da jedoch die
prozentuale Auflösung des OCR0A-Werts in diesem Bereich recht schlecht
ist (es macht einen großen Unterschied, ob man bspw. 9 oder 8 einträgt),
kann das Timing immer noch ungenau sein.
Aber warum nimmst du statt dem 64:1-Vorteilers nicht einfach den
8:1-Vorteiler (CS2=0, CS1=1, CS0=0)? Dann ist für die Nominalfrequenz
OCR0A=79, und die Interruptfrequenz kann in viel feineren Schritten
eingestellt werden.
Hier sind die entsprechenden Änderungen im Programm (
Wenn du jetzt noch in Zeile 16 die richtige Oszillatorfrequenz
einträgst, ist das Timing genauer als ±0,7%.
Bei meinem Tiny beträgt die Oszillatorfrequenz fast exakt 120 kHz. Wenn
ich diesen Wert ins Programm eintrage und den Vorteiler wie beschrieben
auf 8:1 einstelle, messe ich mit dem Oszi einen Datentakt von 100,2 Hz
(ideal wären 100,0 Hz). Was will man mehr?
Man muss es mit der Kalibrierung aber auch nicht übertreiben, denn die
RC-Oszillatorfrequenz ist stark abhängig von der Temperatur und der
Versorgungsspannung.
> (Das genaue Timing ist nicht gleich, z.B. Sync-Pause 20ms länger-> Warum?)
Siehe oben. Außerdem musst du berücksichtigen, dass die Sync-Pause,
gemessen von der letzten fallenden Taktflanke vor der Pause bis zur
ersten steigende Taktflanke nach der Pause nicht 80 ms, sondern 85 ms
betragen muss, da zu den 80 ms Pause ja noch die Low-Phase des letzten
Takts (5 ms) hinzukommt..
Moby A. schrieb:> Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten> von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn:>> DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER
Jetzt bleibt mir aber wirklich die Spucke weg ...
Wenn ich ganz ehrlich bin, hätte ich nicht erwartet, dass wir uns in
diesem Punkt irgendwann in den nächsten 1000 Jahren einig werden ;-)
Offensichtlich bist du doch nicht ganz so sehr der absolut unverrückbare
tonnenschwere Betonklotz, für den ich dich gehalten habe. Daumen hoch!
Moby A. schrieb:> Der Fight der Systeme ist vorbei ;-)
Es hat nie einen "Fight der Systeme" gegeben. Es hat nur einen Moby
gegeben, der stur nicht glauben wollte, was andere schon längst wissen.
Yalu X. schrieb:> Moby A. schrieb:>> Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten>> von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn:>>>> DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER
Ja Moby, das Ergebnis war zu erwarten. Der Kompiler kann beim
Compilieren das gesamte Programm optimieren. Du immer nur Deine
vorgefertigten Blöcke.
Vielleicht macht es ja Sinn, das Du Dir C doch mal in Ruhe ansiehst?
Ich meine, ich hätte den folgenden Beitrag heute Nachmittag schon
abgeschickt, habe aber wohl vergessen, auf den "Absenden"-Knopf zu
drücken:
Moby A. schrieb:> Vielleicht möchte sich Mod Yalu ja noch dazu äußern, wielang er dran> gefeilt hat?
Die Grundversion des C-Programms mit der geforderten Funktionalität hat
mich eine gute halbe Stunde gekostet.
Diese Version hat allerdings noch RAM für Variablen und die Sicherung
von Registern im Interrupthandler benötigt. Zudem war darin noch der
Startup-Code der C-Bibliothek enthalten, der mehr tut als im konkreten
Fall gefordert und deswegen etwas mehr Flash belegt, als unbedingt
nötig.
Trotzdem wäre in einem realen Projekt die Softwareentwicklung an dieser
Stelle weitgehend abgeschlossen gewesen, da alle Funktionen vollständig
implementiert waren, und man wäre direkt zur Testphase übrgegangen.
Aber hier ging es ja nicht primär darum, eine lauffähige Anwendung zu
entwickeln, sondern deine unsinnigen Zusatzanforderung nach fast
völligem Verzicht auf die RAM-Nutzung zu erfüllen. Ich musste nun also
versuchen,
- sämtliche Variablen (insbesondere auch die globalen) in Register zu
bringen,
- die in diesem Fall überflüssigen PUSHs und POPs im Interrupthandler zu
vermeiden,
- den Compiler/Linker dazu zu bringen, den Startup-Code wegzulassen und
- diejenigen Teile aus dem Startup-Code, die man trotzdem benötigt, in C
nachzuprogrammieren.
Das sind alles Dinge, die niemand auf der Welt (außer dir natürlich)
tut, weil sie völlig unsinnig sind. Entsprechend findet man im Netz auch
kein Howto, in dem das alles in zusammengefasster Form und ready-to-use
beschrieben wird.
Da ich selber so etwas auch noch nie gemacht habe, musste ich mir die
notwendigen Informationen also mühevoll aus mehreren Einzelquellen
zusammentragen und immer wieder testen, ob die gewonnenen Erkenntnisse
vom Compiler und Linker auch wirklich so umgesetzt werden, wie ich mir
das vorgestellt hatte.
Das hat etliche Stunden gedauert. So genau weiß ich das nicht, weil ich
nicht auf die Uhr geschaut und zwischendurch immer wieder andere Dinge
(wie Essen, Einkaufen usw.) getan habe.
Schließlich habe ich noch einen kleinen Testaufbau mit dem ATtiny13
zusammengesteckt, um zu sehen, ob die Ausgangssignale bzgl. Timing und
den Dateninhalten stimmen. Um die Ausgabe mit der deines Programms
vergleichen zu können, habe ich auch dieses auf den Controller geladen
und die Signale auf dem Oszi angeschaut. Da ich kein Atmel-Studio habe,
musste ich dazu deinen Quellcode erst einmal in die GNU-Assemblersyntax,
die von der Atmel-Syntax etwas abweicht, übersetzen.
Das hat einschließlich einiger kleiner Fehlerkorrekturen zusammen
weitere zwei Stunden gedauert.
Die mit Abstand meiste Zeit nahm somit der Wissenserwerb für die
"RAM-freie" Programmierung in C in Anspruch. Ich betrachte das mal als
persönliche Fortbildungsmaßnahme, die für mich vielleicht irgendwann mal
wieder von Nutzen sein wird (auch wenn ich das eher bezweifle ;-)).
Auf jeden Fall bin ich jetzt mehr denn je davon beeindruckt, welche
Möglichkeiten der GCC für das gezielte Abspecken von Programmcode
bietet. Noch vor ein paar Tagen hätte ich es für unwahrscheinlich
gehalten, dass man mit dem GCC das Eckmannsche Programm erzeugen kann:
1
; Programmanfang an Adresse 0
2
sbi DDRB,1
3
sbi PINB,1
4
; Programm läuft im unprogrammierten Flash weiter und wird
5
; wiederholt, wenn der Programmzähler am Flash-Ende überläuft
(Quelle: Beitrag "Re: Assembler wieder auf dem Weg nach vorn")
Jetzt weiß ich aber, dass es geht :)
Und wenn mal erst einmal gelernt hat, wie diese Fähigkeiten des GCC zu
nutzen sind, schreibt man extrem ressourcensparende Programme fast mit
der gleichen Leichtigkeit wie gewöhnliche C-Programme, auf jeden Fall
aber in viel kürzerer Zeit als mit Assemblerprogrammierung.
Wenn wir jetzt – wie damals von Karl Heinz vorgeschlagen – einen
Wettbewerb veranstalten würden, bei dem jeder von uns in limitierter
Zeit eine vorgegebene µC-Anwendung realisiert und am Ende neben der
Fehlerfreiheit der Ressourcenverbrauch bewertet wird, würdest du
mit deiner ASM-Programmiererei vermutlich sehr schlecht aussehen :)
Bei einer nichttrivialen Anwendung (>> 1KB), zu der dich Karl Heinz
herausgefordert hatte, hättest du sowieso keine Chance, aber auch bei
einem Mickymaus-Programm, vergleichbar mit dem deines Sensorboards,
würde ich dich dank der Produktivität von C und der Fähigkeiten des GCC,
kompakten Code zu generieren, ganz sicher schlagen :D
Aber das ist inzwischen Schnee von gestern, da du jetzt ja ganz groß in
die C-Programmierung einsteigen wirst und damit künftig genauso schnell
ressourcensparenden Code entwickeln wirst wie alle anderen. Deswegen ist
jetzt schon klar, dass der Wettbewerb nur mit einem Remis enden kann :)
Bewundern wir stattdessen lieber den gewaltigen Sprung nach oben, den C
in der nächsten Ausgabe des Tiobe-Index machen wird :)
Yalu X. schrieb:> da du jetzt ja ganz groß in> die C-Programmierung einsteigen wirst
Dazu wiegt
> der absolut unverrückbare> tonnenschwere Betonklotz
jahrelanger Asm-Praxis zu schwer ;-)
Du hast Dir aber redlich Mühe gegeben mir einen neuen Weg zu bahnen (mit
viel Ressourcenspar-Häppchen als Lockmittel), aber soweit liegen Dein
jahrelang erfahrener Profi-C Code und mein 0815 Code im Ergebnis nun
auch nicht auseinander, daß für mich die Gegenrichtung
Moby A. schrieb:> Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das> nehm ich mal als Ansporn!
nicht in Frage käme. Schließlich liefert ja jeder Compiler auch nur
Asm-Output ;-)
Daß Du meinen Asm Code hier zuweilen korrigiert hast ist doch auch ein
Angebot... Außerdem bleibe ich bei
Moby A. schrieb:> Das schlimmste ist die unnötige Bürokratie.> Dieser hochgradig umständliche Aufwand.> Das würde ich von der Priorität her fast noch über den gesteigerten> Ressourcenbedarf setzen ;-)
Moby A. schrieb:> Moby A. schrieb:>> Jeder durchschnittliche Asm-Programmierer ist noch steigerungsfähig, das>> nehm ich mal als Ansporn!
Nope, genau da liegst du falsch und das versuchen wir dir auch seit rund
2000 Beiträgen zu erklären: Ein Compiler kann Optimierungen machen, die
ein Mensch nicht mehr überblicken kann. Das wahre Optimierungspotential
liegt nicht bei ein paar kunstvollen Assembler-Kniffen, sondern beim
sturen Durchrechnen der Resourcenbelegung, z.B. Cache- oder
Registerzuweisung.
Und selbst wenn die kunstvollen Assembler-Kniffe etwas bringen: Die
kennt und nutzt der Compiler sowieso.
Moby, es gibt einfach wirklich nichts, ausser:
(a) Ausbildungs-/Spasszwecken
(b) Wenn die Instruktionssequenz aus einem ganz konkreten Grund von Hand
vorgegeben muss, z.B. "Takte zählen".
(c) Bibliotheksfunktionen, die ganz spezifische Hardware-Eigenschaften
nutzen soll oder Code-Snippets für die Verwendung innerhalb von
Compilern
Für generelle Anwendungsentwicklung ohne sehr konkreten
Optimierungsdruck ist C um Welten geeigneter.
Ralf G. schrieb:> ... find ich geil! Klingt fast wie 'Eulersche Zahl' oder 'Satz des> Thales'
Für so ein legendäres Programm...
Ich bin gespannt, wann die Arduino-Fraktion sich daran versucht und der
Bootloader sie in den Wahnsinn treibt.
mfg.
Moby A. schrieb:> aber soweit liegen Dein> jahrelang erfahrener Profi-C Code und mein 0815 Code im Ergebnis nun> auch nicht auseinander, daß für mich die Gegenrichtung> [...]> nicht in Frage käme. Schließlich liefert ja jeder Compiler auch nur> Asm-Output ;-)
War ja klar, dass Du die Unterschiede nun herunterspielst. Ich verstehe
nur nicht, warum Du in hunderten von Beiträgen vorher so einen Aufstand
geübt und einen so großen Bohei drum gemacht hast. Dass C und ASM sich
bei einem Mini-Progrämmchen nicht groß unterscheiden, war von vornherein
klar. Egal, ob jetzt C oder ASM bei 200 Byte Code die Nase vorn hat: der
Unterschied ist marginal. Das sagst Du ja nun selber.
Die eigentlichen Stärken spielt der C-Compiler nämlich erst bei größeren
Projekten aus. Dann ist es in jedem Fall wurscht, ob
Interruptvektor-Tabellen drin sind oder ob man RAM benutzt. Das kann
dann der Compiler wesentlich besser entscheiden als der Mensch.
Yalus Klimmzüge bzgl. Mobyischer Einsparungen kann man sich dann
schenken und Deine ganzen Argumente bzgl. Ressourcen-Einsparung lösen
sich bei C in Luft auf. Der C-Programmierer kann sich voll der
eigentlichen Programmier-Aufgabe widmen, der ASM-Programmierer jedoch
muss weiterhin all seine Register, Calling Conventions und andere Fallen
immer im Auge behalten. Der ASM-Programmierer ist daher doppelt
belastet: Er muss sich neben der eigentlichen Programmieraufgabe
zusätzlich noch permanent um sein "Werkzeug" kümmern.
Bleib ruhig bei ASM. Steht Dir auch besser.
P.S.
Wegen Deinem permanenten nervösen Augenzwinkern solltest Du mal zum Arzt
gehen. ;-)
Kaum ist man mal ein absoluter Resourcenverschwender (ich habe die
Resource Freizeit am Wochenende mit meiner Freundin auf dem
Weihnachtsmarkt am Bodensee maßlos verschwendet),
schon taucht ein extrem resourcensparendes ce ("C") Programm auf
(welches ich so nicht gedacht hatte dass es - der Unnötigkeit wegen -
gemacht wird):
Yalu hat es bewiesen und deshalb gilt meine absolute Hochachtung Yalu !
Im Übrigen läßt sich Yalus Programm auch mit der AVR-GCC Version 4.8.1
übersetzen (was ich allerdings so dann auch erwartet habe).
Absolute Hochachtung für Yalu !!!
Das "tricky" Hacking für "main1" "main2" und "main3" werde ich mir doch
tatsächlich einmal zu Gemüte führen (weil, auch wenn ich glaube dass das
unnötig ist, ich gerne lernen mag, was da denn ganz genau passiert).
Respekt !
Ich möchte Yalu auf jeden Fall auch noch meinen Respekt zollen.
Ich programmiere schon eine ganze Zeit in c, seltener in asm. Auch
beruflich. Dabei bin ich nicht erfolglos, gehöre aber sicher auch nicht
zu den allerhellsten Kerzen in der Branche.... Ich finde das ist schon
eine wirklich beachtliche Leistung was du gemacht hast.
Yalu hat schön gezeigt, was alles Motivation sein kann, Neues zu machen
und eine Herausforderung zu lösen.
Ein so oft gehörtes Phrasenargument bezüglich asm und c ist ja, dass man
in Assembler genau weiß, was der Prozessor gerade macht, keinen Takt
verschwendet, jedes Bit gesetzt hat, genau den Überblick über Register
etc. pp hat. das ist vermutlich ein Relikt, was sich vor über 30 Jahren
gebildet hat und viel zu oft einfach nachgeblökt wird. Es wäre schön,
wenn das Ergebnis des Threads helfen könnte, dieses (zumindest von Moby)
nicht mehr immer zu hören.
Moby, du musst dir halt auch eingestehen, dass du genau DAS in 2000
Posts und vielen Threads gemacht hast: deinen asm Code als den perfekten
bitoptimierten Code angepriesen, der deshalb von etwas geschwätzigen wie
c nicht "geschlagen" werden kann. Hat sich erledigt. Hast du ja auch auf
deine Art gewürdigt. Das Assembler, wie gesagt, im Hobby einfach seiner
selbst willen mal Spaß machen kann ist damit nicht widerlegt.
Portabel und wie ich meine Praxisrelevant ist die c-Lösung ja nun auch
nicht.
Ich kann auch verstehen, dass der Einstiegswiderstand bzgl. c groß ist.
ABER: es haben dir ja auch echt viele Leute in dem Thread soooo oft
versucht rüberzubringen und dich dahingehend zum nachdenken zu bewegen,
dass dein Sensor in c genauso gut funktionieren würde, wenn 50 Byte mehr
flash und paar Byte ram verbraucht würden. Kein bischen schlechter.
Nicht mal weniger erweiterbar - eher mehr. Von daher würde ich es
einfach mal wagen, immer auch ein c Projekt anzugehen. Die Moderatoren
und einige andere haben hier ja wirklich lange und sachlich diskutiert;
die werden sicher auch bei c Fragen helfen.
Btw. der c-thread den du mal zitiert hast ist ein Beispiel für etwas was
mich auch regelmäßig wundert bis verstört (vielleicht hast du den Link
zur Hand). Nämlich das Verhalten von dem gcc. Dabei ging es ja um einen
expliziten unsigned-cast, der dem compiler erheblich unter die Arme
greift. So wirklich verstehen, warum der nicht selber auf die Idee
kommt, wenn ich ja z.B. ein Rechenergebnis einem unsigned Register
zuweise tue ich nicht. Aber(!) das ist ja auch wirklich fast immer nicht
so dramatisch. Wenn das Programm und die Ressourchenaufteilung wohl
überlegt ist, bringt eine Berechnung mit 3 Takten mehr meistens keinen
Beinbruch.
Bei manchen anderen ist hier direkt wieder der Reflex zum nachtreten zu
sehen. Meine Güte: seid Männer! Hier ist kein Schulhof wo gilt: einmal
Arsch, immer Arsch. Man kann sich auch streiten und dann in die Kneipe
zurückziehen. Sollte man jedenfalls versuchen.
Leider weiß ich für mich persönlich jetzt IMMER noch nicht, ob der
Moby-Member in Wirklichkeit auch so borniert sein kann, oder ob das eine
Menge Selbstdisziplin gefordert hat. ;-) So und mit der Smiley ist doch
ein guter Punkt, sich aus dem Thread auszuklinken. Wie schön. Endlich
quasi-Konsens. Warum quasi? Das seht ihr in den nächsten 500 Posts.
Clemens M. schrieb:> Btw. der c-thread den du mal zitiert hast ist ein Beispiel für etwas was> mich auch regelmäßig wundert bis verstört (vielleicht hast du den Link> zur Hand). Nämlich das Verhalten von dem gcc. Dabei ging es ja um einen> expliziten unsigned-cast, der dem compiler erheblich unter die Arme> greift. So wirklich verstehen, warum der nicht selber auf die Idee> kommt, wenn ich ja z.B. ein Rechenergebnis einem unsigned Register> zuweise tue ich nicht.
Eine einfache Erklärung - ohne in Details zu gehen:
In C werden Berechnungen standardmäßig in Integer (int) durchgeführt.
Das Problem beim Schieben eines Wertes nach links bzw. rechts ist, dass
das Vorzeichen (MSB) dabei immer erhalten bleiben muss. Bei
unsigned-Werten, wo das keine Rolle spielt, muss man dem Compiler das
dann explizit sagen, denn auf den Typ der Zielvariablen kommts nicht an
- vielmehr auf den Typ der Operanden.
Meine Hochachtung gilt Moby:
> Kurz und gut, damit ist der Vergleich im Ressourcenverbrauch zugunsten> von C entschieden und ich überreiche Dir, Mod Yalu den Gewinn:>> DER KÜNFTIG SCHWEIGENDE ASM-MOBY IM BECKEN DER EFFIZIENTEN C-SCHWIMMER
Das zu schreiben war nach diesem Riesenthread sicher nicht einfach!
Für mich steckt die Herausforderung beim Programmieren auch ganz
wesentlich in der Konfrontation mit eigenen Fehlern, die unausweichlich
in jedem Programm stecken. Nur wer diese erkennt, findet den Bug oder
die bessere Lösung beim Refactoring oder dem nächsten Design.
Moby, ich denke, hier können Dich mehr verstehen, als Du glaubst. Lange
Zeit war meine Einstellung zu C-Compilern ähnlich wie Deine. Früher war
der ASM-Output des Compilers deutlich schlechter als handoptimierter
Assembler, auch noch bei den ersten gcc-Versionen für den AVR. Aber die
Compiler werden immer besser, das Ergebnis hat uns Yalu gezeigt.
Früher haben die Schachgroßmeister die Maschine als Konkurrenten
gesehen, heute werden sie als Hilfestellung benutzt, um komplexe
Lösungen besser zu finden und zu verstehen. Dieser Weg ist auch für uns
Programmierer der Richtige.
Gruß, Stefan
Klar, Frank. Das ist mir soweit natürlich bewusst. Ich tendiere wie es
aussieht dazu, einem Compiler eben zu viel anstatt zu wenig zu zutrauen
und daher habe ich das öfter einfach ausgeblendet.
Von daher war der oben genannte thread für mich persönlich gut. Wenn ich
mich in Zukunft wundere, warum ein Code ungewöhnlich aussieht, habe ich
die Problematik in meinem aktiven Hirn.
Clemens M. schrieb:> Ich tendiere wie es> aussieht dazu, einem Compiler eben zu viel anstatt zu wenig zu zutrauen> und daher habe ich das öfter einfach ausgeblendet.
Ja, mich stört es auch, dass man immer wieder daran denken muss. Es gibt
andere Sprachen (z.B. Java), in denen man einen "unsigned shift" durch
drei Größer-Zeichen - also '>>>' - explizit angeben kann. Schade, dass
das in C nicht geht. Ich würde nämlich dann immer '>>>' statt '>>'
verwenden, da man einen Shift mit Vorzeichen-Wahrung eher selten
braucht.
Ich glaube, Moby hat einfach ein Problem / Abneigung gegen die Begriffe
"Algorithmen" und "Datenstrukturen".
Komplexere Algorithmen als nur ein paar Bit-Schubsereien und deutlich
komplexere Datenstrukturen als die eines digitalen
8-bit-Eingangs/Ausgangsports sind nun mal das Grundgerüst der meisten
heutigen Systeme (nicht nur von Magnetfeld-Steuerungen von
Teilchenbeschleunigern, auch "einfachere" Steuerungen - z.B.
Quadkopter-Steuerung).
Sowas läßt sich halt nur vernünftig in einer abstrahierenden
Programmiersprache darstellen, bei der man sich um das klein-klein
einzelner Registerbelegungen keinen Kopf mehr zu machen braucht.
Selbst wenn man Yalus 'hackish' Tricks weglässt und per Copy&Paste
einfach in AVR Studio 4 'sensorboard.c' kompiliert, ist es immer noch
kleiner als der ASM Kram:
Ralph S. schrieb:> Das "tricky" Hacking für "main1" "main2" und "main3" werde ich mir doch> tatsächlich einmal zu Gemüte führen (weil, auch wenn ich glaube dass das> unnötig ist, ich gerne lernen mag, was da denn ganz genau passiert).
Geht mir auch so, ich habs fürs Kompilieren erstmal auskommentiert und
aus 'void main3(void)' einfach mal 'int main(void) gemacht - sonst will
Studio 4 nicht.
Frank M. schrieb:> Hier eine Kurzanleitung, wie man auch neuere avr-gcc mit Studio 4 nutzen> kann:>> Beitrag "Re: avr-gcc 4.7 für Atmel Studio 4 Windows"
Das ist sehr nett von dir, aber wie man sieht, ist jegliche Trickserei
ja gar nicht nötig und ich persönlich bin mit dem 'normalen' Startup der
gcc Kompiler sehr zufrieden.
Ich habe auch festgestellt, das es für gesparte Bytes im Flash ja gar
kein Geld zurückgibt :-)
Wimre habe ich hier sogar noch WinAVR von 2010 laufen, das wäre GCC
4.3.3.
Würde ich was neueres brauchen für neue MC, dann lasse ich AVR Studio 4
so wie es ist und kippe Atmel Studio 7 oder so mit auf den Rechner.
Jetzt müsste man nur noch klären ob ASM
tatsächlich "einfach und selbsterklärend" ist ..
@moby avr:
hast du anhand dieses selbsterklärenden ASM Code schon festgestellt was
der GCC jetzt besser gemacht hat als du?
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Matthias S. schrieb:> Das ist sehr nett von dir, aber wie man sieht, ist jegliche Trickserei> ja gar nicht nötig und ich persönlich bin mit dem 'normalen' Startup der> gcc Kompiler sehr zufrieden.
Es gibt aber durchaus noch andere Verbesserungen, z.B. LTO-Support und
den neuen Typ "__flash" vs. PROGMEM. Ausserdem ist der Compiler-Output
auch ohne Tricksereien besser als der vom avr-gcc 4.3.3.
Yalu X. schrieb:> Auch __int24 und __uint24 kamen m.W. erst mit GCC 4.7.
Ja, die sind Kollateralnutzen von __memx, das ja eh 24-Bit Arithmetik
braucht. Mit wenig Mehraufwand (z.B. Division, die für Zeigerarithmetik
nicht notwendig ist) waren also 24-Bit Typen zu haben.
Moby A. schrieb im Beitrag #4644241:
> http://m.heise.de/newsticker/meldung/Programmiersp...
Geht das jetzt wieder los?
Egal, ob Platz 10 oder Platz 99: 2,28% sind einfach nicht der Rede wert.
Meinetwegen kann dieser Thread dichtgemacht werden.
Logisch. Heute kam grad eine Meldung, dass der Quellcode des Apollo
Guidance Compilers veröffentlicht wurde. Der ist auch in Assembler.
Soviel Quellcode auf einem Haufen...
A. K. schrieb:> Logisch. Heute kam grad eine Meldung, dass der Quellcode des> Apollo> Guidance Compilers veröffentlicht wurde. Der ist auch in Assembler.
Klasse. Gibts auch einen Weg, den Counter von "Assembler" wieder zu
drücken? Vielleicht durchstreichen: ̶A̶̶s̶̶s̶̶e̶̶m̶̶b̶̶l̶̶e̶̶r̶
So also mal wieder in einem Alten vergessenen Thread Rum-stochern :D
Egal was die Ststitik sagt, egal was da geschrieben wird.
Wen ein Neuer Prozessor entwickelt wird, ist das erste wass es Gibt
Maschienensprache bzw Assembler. es gibt nur sehr wenige Prozessoren
"die von Hause aus" eine Hochsprache verstehen (bsw. Tynibasic).
Das heißt Assembler muss auch heute noch Programmiert werden.
Unsere Firma bsw programmiert NUR in Assembler, den wir stellen Geräte
her an denen Menschenleben hängen, und eine Hochsprache kan
unkontrollierte Fehler machen, bsw. Stackoverflow usw.
Im weiteren ist eine Hochsprache nie so Hardware nah wie Assembler, den
da muss man den uC verstehen.
Eine Hochsprache die in einer Hochsprache geschrieben ist ist ja auch
nicht das gelbe vom Ei?!?
Warum bloss macht auch C++ zuerst Assemblercode ?!? Hmmmm....
Warum schlägt ihr euch gegenseitig fast die Köpe ein ob oder ob nicht?
Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache
zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu
kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir
suchen Permanent gute Assembler (und hin und wieder auch C++ & Co)
Programmierer] und keiner Geschaft. Aber Unsere Assembler Programmierer
tun das und packen auch noch eine Sensorsteuer- und Regel-Software mit
rein!
Da es immer wieder Neue Prozessoren gibt, wird auch Assembler und
Maschinensprache nie aussterben, sonst würden auch keine Kinder mehr auf
die Welt kommen die Zuerst in die Schule müssen.
Assembler ist die Sprache des Prozessors, und es ist immer besser die
Direkte Sprache zu sprechen als sie zuerst von "etwas" übersetzen
lassen.
Oder Versucht mal im Google Sprache x in Y zu übersetzen was Kommt raus?
...EBEN.. und das obwohl Millionen dafür ausgegeben werden es zu
Perfektionieren. und auch genau so verhält es sich bei den Hochsprachen
für uC die Compiler oder gar Interpreter sind nie Perfekt.
Und ja Windows wurde ja hier im Thread auch angesprochen, Stimmt ist
vollständig in mehreren Hochsprachen geschrieben.(ja nicht nur in einer
das sieht man deutlich, wenn man den Quellcode analysiert).
Und was ist das Resultat?
Windows ist "Launisch", Instabil und wird nicht für Livesupport (Geräte
an denen Leben hängen) zugelassen....hmmm warum wohl?.....
Die Meinung bei uns in der Firma (und übrigens auch bei FDA) ist klar
Livesupport, Assembler Only.....
So Sorry wenn ich jemandem auf den Slips getreten bin, aber bin auf den
Thread aufmerksam geworden weil ich doch Tatsächlich "Assembler" bei
Google eingegeben habe, nicht weil ich Software suche, sondern weil bei
uns im Betrieb ein Assemblerprogrammierer in Pension geht und wir wieder
einen suchen :-D ........
Patrick L. schrieb:> Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache> zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu> kriegenBeitrag "Re: Assembler wieder auf dem Weg nach vorn"
q.e.d. schon vor knapp einem Jahr, der Compiler ist vermutlich nur noch
besser geworden, der Mensch bleibt bei 1.0
Lies zur Sicherheit auch die anderen 2k Beiträge durch.
Patrick L. schrieb:> Wen ein Neuer Prozessor entwickelt wird, ist das erste wass es Gibt> Maschienensprache bzw Assembler.
Und zwar Testcases um den Prozessor zu debuggen. Parallel dazu entsteht
ein C Compiler, auf Fremdhardware entwickelt, weil man ohne den keinen
Prozessor mehr auf den Markt bringen kann, wenn man auf Stückzahlen Wert
legt.
Patrick L. schrieb:> Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache> zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu> kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir> suchen Permanent gute Assembler (und hin und wieder auch C++ & Co)> Programmierer] und keiner Geschaft.
Dein Problem mit Hochsprachen scheint sich nicht nur auf C zu
beschränken.
Gu. F. schrieb:> Patrick L. schrieb:>> Versucht doch mal ein Komplettes TCP/IP Protokoll in einer Hochsprache>> zu schreiben das in einem uC mit 2K FLASH und 128Byt RAM hat runter zu>> kriegen, Das haben in unserer Firma mehrere Bewerber Versucht [Ja wir>> suchen Permanent gute Assembler (und hin und wieder auch C++ & Co)>> Programmierer] und keiner Geschaft.>> Dein Problem mit Hochsprachen scheint sich nicht nur auf C zu> beschränken.
Und wie verzweifelt müssen die Leute dort sein, die einen TCP/IP Stack
in Assembler programmieren? Das ist das Äquivalent zum Steine klopfen im
Zuchthaus. Und das wo ordentliche Controller mit genug Speichern für
eine ordentliches SW-Entwicklung nichts mehr kosten. Höchstrafe!
@Operator S. Hallo danke für deinen Interessanten Beitrag :)
Operator S. schrieb:> q.e.d. schon vor knapp einem Jahr, der Compiler ist vermutlich nur noch> besser geworden, der Mensch bleibt bei 1.0>> Lies zur Sicherheit auch die anderen 2k Beiträge durch.
Ja das wäre ja Toll, bloß habe ich den Beitrag nicht gefunden,
würde mich rein Persönlich Interessieren?
aber Trotzdem, ändert nix daran, das es für Livesupport nicht zugelassen
ist.......
@A. K.
Auch dir Danke für dein Beitrag,
ist aber nicht ganz richtig, wir haben gerade diesen Monat wieder 2
Hybridprozessoren auf den Markt gebracht, zu denen es (noch) keinen "C"
Compiler gibt. das eine ist ein 16 Bit uC das andere ist ein 128Bit
DSP...
Klar das es irgend wann auch für die meisten, "C" & Co geben wird,
aber nicht für alle, von uns auf den Markt gebrachten uC's, gibts
Hochsprachen und Trotzdem, Unmengen davon sind weltweit im Einsatz....:)
im Bereich Sicherheitstechnik (Livesupport), Lenktechnik,
Hochsicherheit's-Verschlüsselungssysteme, und da hat's in den letzten 30
Jahren keine Hochsprache gegeben und wirds wahrscheinlich auch in
Zukunft nicht geben, wir Produzieren diese uC's aber immer noch und sie
werden auch noch eingesetzt...... die einen Ja da hast du recht, in sehr
kleinen Stückzahlen aber es sind auch welche die wir Outgesourct haben
(bzw. stellt unser Kunde nun selber her, aber wurde von Unserem Team
entwickelt) und die gehen schon in große Stückzahlen rein.
Nichts dest do Trotz suchen wir halt Assembler Programmierer.....
...Bist du einer? Interesse? ....:-D
Gruß.....
Nachtrag:
@Cyblord
>Und wie verzweifelt müssen die Leute dort sein, die einen TCP/IP Stack>in Assembler programmieren? Das ist das Äquivalent zum Steine klopfen im>Zuchthaus. Und das wo ordentliche Controller mit genug Speichern für>eine ordentliches SW-Entwicklung nichts mehr kosten. Höchstrafe!
Versuch doch mal auf 100nm³ mehr unterzukrigen......dan werden wir es
tun, zur Zeit ist aber die Technologie nicht so weit....Schade...Deshalb
müssen wir das.....
> Patrick Linder (Firma: S-C-I DATA GbR)
dass IHR nur Assembler verwendet ist schön, wird keiner ein Problem
damit haben
dass ihr Assembler in einer (sehr kleinen) Niesche verwendet beweist
aber doch genau das gegenteil von:
>Assembler wieder auf dem Weg nach vorn
Robert L. schrieb:>> dass IHR nur Assembler verwendet ist schön, wird keiner ein Problem> damit haben
..Das Hoffe ich doch :D GRINS.......
>> dass ihr Assembler in einer (sehr kleinen) Niesche verwendet beweist> aber doch genau das gegenteil von:>>>Assembler wieder auf dem Weg nach vorn
Wo du Recht hast, hast du Recht, von Vormarsch kann echt nicht die Rede
sein das ist so. (Braucht zu viel Hirnschmalz und Hardwarekenntnis)
.....Hehe.....
Aber ich sage ja nur, Assembler wird es immer geben solange es neue
Prozessoren gibt, deren Sprache Assembler bzw. Maschinensprache ist.
Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man
damit umgehen kann) und auch zuverlässiger, weil man eben Maschinen bzw.
Prozessor nah programmieren muss...
Und wäre Windows in Assembler geschrieben würd es vielleicht auch
zuverlässig laufen, den selbst WIN10 Kennt den Bluescreen und das noch
öfters als Win 7 oder gar XP......
Gruß....
Patrick L. schrieb:> (Braucht zu viel Hirnschmalz und Hardwarekenntnis)
Hardwarekenntnis brauchst du für hardwarenahe Programmierung immer,
da unterscheiden sich andere Sprachen von Assembler gar nicht –
zumindest nicht, wenn man die Hardware auch wirklich selbst ansteuert
und nicht fertige Bibliotheken dafür nimmt (wie bspw. Bascom oder
Arduino etc.).
Das wesentliche unterschlägst du: Assemblerprogrammierung braucht
vor allem Zeit, und zwar sehr viel mehr als jede höhere Sprache,
wenn das Gesamtproblem nicht mehr trivial ist.
Das ist doch der wesentliche Grund, warum man es nicht macht, wenn
es irgendwie vermeidbar ist. Die entsprechende Software wird dadurch
einfach teuer.
> Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man
Wurde im dir bereits zitierten Beitrag widerlegt. ;-)
> damit umgehen kann) und auch zuverlässiger,
Das ist ein Trugschluss. Der wesentliche Fehlerfaktor ist ja nicht
der Compiler sondern der Mensch, und durch die geringe Codedichte
ergibt sich automatisch erstmal eine höhere Fehlerwahrscheinlichkeit
bei Lösung des gleichen Problems.
> Und wäre Windows in Assembler geschrieben würd es vielleicht auch> zuverlässig laufen
Nein: es würde gar kein Windows geben, sondern MS-DOS 32.0.
Patrick L. schrieb:> Und es ändert nix daran das der Code im Assembler kleiner ist (Wen man> damit umgehen kann) und auch zuverlässiger, weil man eben Maschinen bzw.> Prozessor nah programmieren muss...
Für ultrakleine Programme mag das ja richtig sein. Aber ab einer
bestimmten Programmgröße nimmt die Komplexität dermaßen zu, dass die
Maschine (sprich Compiler) besser optimieren kann als der Mensch (in
Assembler).
Hier in diesem Thread wurde sogar gezeigt, dass auch kleine
Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden.
> Und wäre Windows in Assembler geschrieben würd es vielleicht auch> zuverlässig laufen, den selbst WIN10 Kennt den Bluescreen und das noch> öfters als Win 7 oder gar XP......
Wäre Windows in Assembler geschrieben, wäre das Erscheinungsdatum von
Win7 irgendwann im Jahre 2107 gewesen.
Die Argumente, die Du bringst, wurden hier schon alle angeführt. Allein
die Nettiquette gebietet es, dass Du Dir diesen Thread erst einmal
komplett durchliest, bevor Du hier mit Kamellen kommst, die längst alle
schon durchgekaut wurden.
Vielleicht willst Du aber auch nur provozieren... Moby Version 2.0...
Frank M. schrieb:> .....Für ultrakleine Programme mag das ja richtig sein. Aber ab einer> bestimmten Programmgröße nimmt die Komplexität dermaßen zu, dass die> Maschine (sprich Compiler) besser optimieren kann als der Mensch (in> Assembler).......
...die Meinung lass ich dir, auch wenn ich sie nach über 40 Jahren
Erfahrung nicht teile........
> Hier in diesem Thread wurde sogar gezeigt, dass auch kleine> Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden.> ....
....lass ich auch stehen, kommt aber auch da auf das wissen und können
des Programmierers an......
> ........> Wäre Windows in Assembler geschrieben, wäre das Erscheinungsdatum von> Win7 irgendwann im Jahre 2107 gewesen.> ....
....finde, Ist ein bisschen übertrieben, aber da will ich mich nict
drauf einlassen, wir haben Komplexe Programme in Assembler geschrieben
die in GB Bereich reichen....Wen unser Kunde das will weil FDA das
vorschreibt, tun wir das......
> Die Argumente, die Du bringst, wurden hier schon alle angeführt. Allein> die Nettiquette gebietet es, dass Du Dir diesen Thread erst einmal> komplett durchliest, bevor Du hier mit Kamellen kommst, die längst alle> schon durchgekaut wurden.> .....
...Ohhh sorry, erwähne ich weil ich mich über Windows und über seine
Zuverlässigkeit immer wieder ärgere, da aber leider viel Werkzeug das
wir haben müssen nur unter Windows laufen :(...
....und....ich habe sehr viel im Thread gelesen ja... aber um so einen
Langen Thread durchzulesen fehlt mir die Zeit....Also bitte etwas
Toleranz ja in Bezug auf die....
> ... die Nettiquette gebietet es, ....
.... irgend wann sind die Threads zu lange......
> Vielleicht willst Du aber auch nur provozieren...
....nein will ich nicht....
Will nur klar mitteilen das Assembler oft sehr Abschätzig behandelt wird
und dabei vergessen wird dass es halt doch Vorzüge hat und auch die
Mutter aller Programmiersprachen ist den das Kind (der uC) spricht nun
mal in den meisten fällen diese Sprache....
Und ändert auch nix daran das speziell wir damit arbeiten müssen weil es
nun mal nicht anders geht. Wir haben diese Vorschriften nicht gemacht
aber wenn wir liefern wollen müssen wir uns daran halten.
Und wenn keiner Assembler Programmieren könnte würde es sehr schlecht um
neue Prozessoren stehen den sie so Aufzubauen das sie von Haus aus eine
Hochsprache sprechen ist derart aufwendig, das auch wir dieses Projekt
eines "C" Prozessors stillgelegt haben. Der Prototyp den wir entwickelt
hatten brauchte 10 x soviel Chipfläche wie ein Vergleichbaren
Maschinencode basierenden Prozessor.
Aber ein Punkt muss ich dir lassen, Unser "C" Prozessor Prototyp ist gut
im Factor >100 schneller als jeder andere den wir bis heute entwickelt
hatten.
Den er kan somit oft Mehrere hundert Befehle in einem Cyclus
abarbeiten...
Leider kann man Ihn bedingt durch seinen Platzaufwand und Komplexität
auf dem Waver nicht bezahlen.. Ca 5 Mio würde er kosten bis er
ausgereift ist....
Und deshalb wollen wir auch den Guten Mann der über 30 Jahre bei uns
gearbeitet hat auch wieder ersetzen, ....es geht nicht ohne
Assembler....
Lieben Gruß
Patrick L. schrieb:> Will nur klar mitteilen das Assembler oft sehr Abschätzig behandelt wird
Ach was: keiner hier behandelt den „abschätzig“.
Man sollte nur keinen Hype draus machen, genau das hatte der Thread
aber mal bezweckt.
Patrick L. schrieb:> wir haben Komplexe Programme in Assembler geschrieben> die in GB Bereich reichen
Da wäre doch mal interessant zu erfahren um was es da geht.
Erzähl doch mal...
Patrick L. schrieb:> ....finde, Ist ein bisschen übertrieben, aber da will ich mich nict> drauf einlassen, wir haben Komplexe Programme in Assembler geschrieben> die in GB Bereich reichen....Wen unser Kunde das will weil FDA das> vorschreibt, tun wir das......
Ihr würdest wahrscheinlich auch eine Weltumrundung auf Händen und Knien
machen wenn euer Kunde das von euch verlangt. Aber dann zu argumentieren
dies wäre irgendwie sinnvoll oder gar nicht Wahnsinnig, ist eben
lächerlich.
Jörg W. schrieb:> Man sollte nur keinen Hype draus machen, genau das hatte der Thread> aber mal bezweckt.
AAARRRG Sorry jetzt wo du es sagst....Grmpf..habe mich doch echt
Mitreißen lassen :'(.......
...Das habe ich nicht bemerkt aber es ist so da hast du 10000%
Recht.....
Hätte wohl lieber einen Neuen Thread aufgemacht so ala ..
....Programmierer in Assembler gesucht.....
Grumpf...werde wohl doch langsam ALT..... GRINS
Aber denke auch da wär's zur Provokation geworden... weil...
Habe Viele Threads, hier im Forum gefunden die mit Assembler zu tun
haben aber meistens wird's eine Schlammschlacht, desshalb.
Kurz im Google "Assembler Programmierer gesucht" und hier gelandet....
Nochmals Sorry dass ich mich hab Hinreißen lassen.. Hat wohl meine Ehre
etwas angekratzt, weil ich seit rund 50 Jahre in Assembler
Programmiere....
Gruß....
das mit dem "windows in ASM" ist schon sehr abenteuerlich..
(das ist ja maximal ein troll verusch)
was ich nicht verstehe:
wenn ICH jetzt eine neue CPU entwickeln würde, mit (warum auch immer)
komplett neuem befehlssatz..
ja, dann müsste ich Assembler können, aber ich müsste doch nicht auch
"große programme" damit schreiben (wozu auch??)
würde ich doch als erstes (wo es die CPU noch nicht mal real gibt) einen
compiler-compiler mit dem neuen befehlssatz beauftragen..
und hätte dann gleich einen riesen Satz an Testroutinen von der letzten
CPU die ich entwickelt habe..
(ps. die chancen dass eine mini-stückzalen CPU selber irgend einen BUG
hat ist doch 100 mal höher als eine millonenfach produzierte CPU mit
millionenfach verwendetem compiler..?!)
Hmmm jaahhhhh Punkte sind doch Cool, beim Kommentieren Praktisch, zeigen
sie doch im Liesting wo was hingehört. LOL
So Von mir aus tippt was ihr wollt, GRINS. der thread ist eindeutig
Provokativ, ziht Provokationen an und dient nicht dem Zweck welchen ich
gedacht habe.
Patrick L. schrieb:> der thread [...] dient nicht dem Zweck welchen ich gedacht habe.
Korrekt. Wenn Du einen Assembler-Programmierer suchst, kannst Du hier
eine Stellenanzeige schalten:
https://www.mikrocontroller.net/jobs/info
Ein Diskussionsthread wie dieser ist gewiss nicht dafür geeignet.
Patrick L. schrieb:> Aber denke auch da wär's zur Provokation geworden... weil...
...zu diesem Thema schon alles gesagt wurde. Nur noch nicht von jedem.
Weil bei diesem Thema immer so lange polarisiert wird, bis keine Seite
bereit ist, von ihrer Position abzurücken.
Weil es einfach nur nervt, immer wieder das gleiche Zeug rauszukramen.
Wie bei den unzähligen Windows/Linux-Debatten. Haben die schon ein
einziges Mal zu etwas geführt? Das sind nichts anderes als
Trolldebatten.
nur noch schnell:
Patrick L. schrieb:> und auch genau so verhält es sich bei den Hochsprachen> für uC die Compiler oder gar Interpreter sind nie Perfekt.
warum habt ihr nicht einfach selber den Compiler in ASM geschrieben,
dann wäre er Perfekt ;-)
Sorry Robert L.
Wir haben wohl gleichzeitig geschrieben war nicht auf dich bezogen.
Robert L. schrieb:> das mit dem "windows in ASM" ist schon sehr abenteuerlich..> (das ist ja maximal ein troll verusch)
Hmmm oder eben gewollt vom Threadersteller zu provozieren, hat ja auch
wunderbar geklappt.
>> was ich nicht verstehe:>> wenn ICH jetzt eine neue CPU entwickeln würde, mit (warum auch immer)> komplett neuem befehlssatz..> ja, dann müsste ich Assembler können, aber ich müsste doch nicht auch> "große programme" damit schreiben (wozu auch??)
Weil es nun mal Vorgeschrieben ist, für gewisse Anwendungen den bsw
unterstützen sehr viele Hochsprachen oft gewisse gesonderte
wirkungsvolle Befehle der CPU Nicht.(Ja und auch ganz besonders in der
heutigen Zeit)
Mag mich an ein Hype in unserer Firma erinnern, da war ein totaler C
Freak bei uns neu und es gab da endlose Diskussionen warum der C Befehl
den "LDIR" befahl nicht nutze, dabei war es eben wie hier eine reine
Provokation, den wenn man ihn benutzt anstelle eine Schlaufe zu
generieren, was die Z80 C compiler damals taten, ist die Software 100x
schneller und auch Stackoverflow sicher, wenn interuppts in die
Verschiebeschlaufe geraten.
Und genau an solchen Sachen setzt wahrscheinlich auch die Vorschrift der
FDA an
>>> würde ich doch als erstes (wo es die CPU noch nicht mal real gibt) einen> compiler-compiler mit dem neuen befehlssatz beauftragen..>
muss ich das Verstehen? wie meinst du das?
> (ps. die chancen dass eine mini-stückzalen CPU selber irgend einen BUG> hat ist doch 100 mal höher als eine millonenfach produzierte CPU mit> millionenfach verwendetem compiler..?!)
Och Bugs? das haben auch heute noch die meisten CPU's die Errata's der
Hersteller sind oft Abenteuerlich GRINS.
Patrick L. schrieb:> Mag mich an ein Hype in unserer Firma erinnern, da war ein totaler C> Freak bei uns neu und es gab da endlose Diskussionen warum der C Befehl> den "LDIR" befahl nicht nutze,
Damals - in den 80ern - also ungefähr die 50 Jahre her, seitdem Du
bereits in Assembler programmierst, waren die C-Compiler noch ziemlich
unterbelichtet. Ein memcpy() in C (was Deinem LDIR in Z80 Assembler
gleichkommt) war halt eine Schleife ohne irgendwelche
prozessorspezifische Optimierungen. Das hat sich erst mit den
3B-Prozessoren von AT&T geändert, welche solche C-Funktionen wie
memcpy() und strcpy() direkt als Assembler-Befehl kannten.
> dabei war es eben wie hier eine reine> Provokation, den wenn man ihn benutzt anstelle eine Schlaufe zu> generieren, was die Z80 C compiler damals taten, ist die Software 100x> schneller und auch Stackoverflow sicher, wenn interuppts in die> Verschiebeschlaufe geraten.
Ein LDIR schützt Dich nicht automatisch gegen Stackoverflow. Da waren
Deine Interrupt-Routinen eher nicht sauber genug programmiert bzgl.
Register-Rettung.
Lies die anderen 2K Beiträge dann verstehst Du das kaum einer der
Meinung ist es gäbe keinen Anwendungsfall für ASM.
Einige wenige sind aber der Meinung ASM wäre immer und in jedem Fall
überlegen was nun wirklich vollkommener Humbug ist.
Die Mehrheit ist nur der Meinung das es eben sehr, sehr wenig Gründe
gibt heute noch exzessiv ASM zu verwenden wenn entsprechende Compiler
und fortschrittliche CPUs zur Verfügung stehen um auch damit
sicherheitsrelevante Software zu schreiben.
Das alles von Dir beschriebene in 2K Flash + 128B Ram zu bekommen ist
wahrlich eine Heroische Tat und ich werde Eure ASM Coder lobend in
meinem Nachtgebet erwähnen.
Im Regelfall halte ich aber einen anderen Controller für die bessere
Wahl.
Frank M. schrieb:> welche solche C-Funktionen wie> memcpy() und strcpy() direkt als Assembler-Befehl kannten.
Bloss um dann festzustellen, dass solche Funktionen explizit
ausprogrammiert und optimiert oft schneller sind, als eventuell
vorhandenen Prozessorbefehle fürs Speicherschaufeln.
Wahrheiten hängen ja zuweilen daran, wer es sagt...
Solche aktuellen Meldungen renommierter Fachmedien sprechen jedenfalls
nicht gerade von einem furiosen Asm-Niedergang:
http://www.elektroniknet.de/markt-technik/embedded/assembler-boomt-134158.htmlhttp://www.heise.de/newsticker/meldung/Programmiersprachen-Ranking-Assembler-stabil-Go-im-Aufwind-3458803.htmlFrank M. schrieb:> Hier in diesem Thread wurde sogar gezeigt, dass auch kleine> Assembler-Progrämmchen nach C übersetzt kleiner und performanter wurden.
Mit einem gewissen C-Know-How, das hat auch nicht jeder!
In
https://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C
stellst Du ja für zumindest mal für die Anwendung Bootloader selber
fest:
"Jedoch sind diese Bootloader allesamt in Assembler realisiert, denn nur
hier hat der Programmierer alle Freiheiten, die er braucht, um die
Speicherverwaltung im SRAM (und auch im Flash) selbst zu kontrollieren.
C (hier im speziellen avr-gcc) ermöglicht es eigentlich nicht, ohne
größere Klimmzüge einen Bootloader für ATtinys zu programmieren"
oder
"Da ein in Assembler geschriebener Bootloader in der Regel viel weniger
Speicherplatz benötigt und daher effizienter auf einem kleinen µC ist
als ein in C programmierter Bootloader, ist dieser Artikel eher
akademischer Natur"
So ist es. Dieses Ansinnen bleibt von Natur aus meist akademisch :)
Christian M. schrieb:> In> https://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C> stellst Du ja für zumindest mal für die Anwendung Bootloader selber> fest:> [...]
Diese Vorgehensweise, Bruchstücke, die nur in einem sehr speziellen Fall
gelten (nämlich Bootloader für ATTiny) zu verallgemeinern, kommt mir
sehr sehr bekannt vor - und zwar nicht gerade im angenehmen Sinne.
Schon für ATmegas gilt diese Aussage nicht mehr. Hier wäre C ganz klar
mein Favorit für einen Bootloader. Und das nicht, weil mehr Flash/RAM
zur Verfügung steht, sondern weil hier der Bootloader eine eigene
Interrupt-Vektor-Tabelle und einen geschützten Bootloader-Bereich hat.
Genau diese Problematik macht es einem C-Programmierer schwer, einen
Bootloader spziell für ATTinys in C zu formulieren. Das steht auch so
klar in dem zitierten Artikel.
Dein Argument ist nicht verallgemeinerbar. Und daher hinfällig.
Wieso wird hier denn wieder diskutiert?
Dachte alles sei geklärt, sogar Moby musste damals seine Niederlage
eingestehen (was er immerhin auch tat!).
Assembler mag für Nischenanwendungen oder Hobby interessant sein, das
wars aber auch.
Alles was irgendwie kommerziell ist wird schon nicht mehr in ASM
gemacht, von kleinsten Codestellen (z.B. startup-Code) abgesehen.
Das ASM nicht total verschwindet ist der Technik und Historie
geschuldet:
Prozessoren "sprechen" erstmal nur Assembler.
Deswegen wird er auch nie verschwinden.
99,5% der Anwender müssen aber damit nicht in Berührung kommen.
Patrick L. schrieb:> ...die Meinung lass ich dir, auch wenn ich sie nach über 40 Jahren> Erfahrung nicht teile........Patrick L. schrieb:> weil ich seit rund 50 Jahre in Assembler> Programmiere....
wie die Zeit vergeht
Thread beobachten
Seitenaufteilung abschalten
#/media/File:Colossal_Cave_Adventure_on_VT100_terminal.jpg){kind=link}
