Moby A. schrieb: >> jeder einzelne hat in seinem Programmiererleben mehr Codezeilen in >> Assembler geschrieben, als du jemals in deinem Leben schreiben wirst. > > Du bist ja gut informiert. Bübchen, das umfangreichste Assembler-Programm, das ich je erweitern durfte, hat mir das Rechenzentrum als ASM-Liste auf Einzelblatt ausgedruckt. Das wurde dann in zwei dieser üblichen DruckerPapierkartons angeliefert. Beide randvoll. Da sind üblicherweise 5 Pakete a 500 Blatt drin. Falls das einen Überlauf deiner 8-Bit-ALU gibt: 5 Tausend Seite. Und die CPU, die das ausführte, darf dir nicht auf Fuß fallen, sonst ist der nicht nur ab, sondern der ganze Kerl ist Brei. Passiert ist das 9 Flugstunden Richtung Süden. Erzählt mir also mehr über den ATtiny13, da kann ich sicher noch was lernen! Diese Maschine hat im übrigen vieles gemeinsam mit ARM. Man kann die locker in ASM Programmieren, wenn man's kann und wenn man gerade seinen Compiler verlegt hat. Der macht das nämlich genau so gut!
:
Bearbeitet durch User
Moby A. schrieb: > Jörg W. schrieb: >> So ein kleiner Cortex-M0+ ist keineswegs komplexer als ein Xmega > > Warum tischt Du mir hier Märchen auf? Jetzt wirst du einfach nur noch unverschämt. > Noch dazu in jener unredlichen > Form, keine konkrete Implementierung zu nennen? Wenn dir das hilft, dann guck' dir einen SAMD20 von Atmel an, und vergleiche ihn mit einem XmegaA. Der SAMD20 ist da von der Peripherie her eher noch überschaubarer als der XmegaA. Dass man sich mit der Grundinitialisierung des Taktsystems rumschlagen muss, ist beim Xmega auch schon der Fall (OK, wenn man nicht gerade mit dem Standard-Takt nach Reset arbeiten will, aber das geht natürlich bei beiden). Das Einzige, was beim Cortex grundlegend anders ist als bei AVR (einschließlich Xmega): nach Reset werden nur die wichtigsten Peripheriebausteine mit Takt versorgt, alle anderen schlafen. Beim AVR muss man den Takt für die Baugruppen, die man nicht braucht, explizit abschalten, wenn man Energie sparen will. > Schau mal in den > Projekten nach, wieviele Asm-Programme es dort für Xmega und wieviele > für es für ARM einschließlich M0+ gibt... Welche Relevanz sollte das haben? Es ging um die Komplexität des Controllers und seiner Peripherie. Die ARM-CPU hat übrigens gerade mal 56 Befehle, bei Xmega sind es 142. > Du wirst doch nicht ernsthaft > behaupten Asm wäre die Sprache der Wahl bei diesen 32-Bittern ;-( Nein, das habe ich nicht behauptet. Warum auch? Außer für dich ist es auch bei heutigen 8-Bittern für niemanden die Sprache der Wahl. > [Xmega …], die Ansprache der Peripherie nicht > grundverschieden. Autsch. Jetzt glaube ich dir nicht mehr, dass du überhaupt jemals was mit einem Xmega gemacht hast. Ja, der Befehlssatz ist nur wenig mehr als der der MegaAVRs. Aber die Peripherie ist sowas von grundverschieden, dass du dich mit obiger Aussage einfach nur blamierst. Ehrlich gesagt, mit fällt auf Anhieb kein einziges Peripheral ein, das auch nur annähernd so bedient werden würde wie im MegaAVR. OK, da du (s. o.) sowieso unflätig wirst, genug für mich hier.
Moby A. schrieb: > Umgekehrt wurde der Xmega von Atmel sicher für C optimiert. Das gilt bereits für die alten AVRs. Deshalb auch die vielen Registern, die ein Compiler weit besser zuordnen kann, als ein Mensch. Ausser Moby natürlich ;-) Moby A. schrieb: > Wer sich 'blöd' fühlt muß das mit sich ausmachen. > Ich würde niemals so persönlich werden, auch wenn sich selbst 'Große > Jungs' hier desöfteren unbeherrscht wie kleine Kinder aufführen denen > das Spielzeug streitig gemacht wird ;-) Dafür repetierst du bestimmt zum zwanzigsten Mal deine Meinung, ohne ein einziges Beispiel zu zeigen, wo bei einer einfachen Aufgabe Assembler gegenüber C einen klaren Vorteil bringt. Bin schon gespannt, wie du dich diesmal aus der Forderung nach einem konkreten Beispiel windest.
Jörg W. schrieb: > Autsch. Jetzt glaube ich dir nicht mehr, dass du überhaupt jemals > was mit einem Xmega gemacht hast. Das brauchst Du nicht. Es reicht, daß ich das weiß ;-) > Ehrlich gesagt, mit fällt > auf Anhieb kein einziges Peripheral ein, das auch nur annähernd so > bedient werden würde wie im MegaAVR. Mir dafür genügend. Die (bekannten) Steuerbits sind etwas anders verteilt, ein paar mehr Möglichkeiten gibt es, das wars auch schon. > OK, da du (s. o.) sowieso unflätig wirst, genug für mich hier. Au weia. Ist aber auch ärgerlich, diese permanente Widerrede.
P. M. schrieb: > Dafür repetierst du bestimmt zum zwanzigsten Mal deine Meinung, ohne ein > einziges Beispiel zu zeigen, wo bei einer einfachen Aufgabe Assembler > gegenüber C einen klaren Vorteil bringt. Bin schon gespannt, wie du dich > diesmal aus der Forderung nach einem konkreten Beispiel windest. Da "repetiere" ich doch glatt schon wieder: Schau Dir mein Asm-Projekt an und zeig mir eine C-Lösung die mit weniger Ressourcen auskommt. Dann wird der klare Asm Vorteil für Dich vielleicht etwas klarer ;-) P. M. schrieb: > Moby A. schrieb: >> Umgekehrt wurde der Xmega von Atmel sicher für C optimiert. > > Das gilt bereits für die alten AVRs. Deshalb auch die vielen Registern, > die ein Compiler weit besser zuordnen kann, als ein Mensch. Ausser Moby > natürlich ;-) Ach woher denn. Für Asm gibts hier Projekte wie Sand am Meer, sicher auch von besseren Programmierern als mich. Der Moby ist weißgott nichts besonderes und hat allein die Vorzüge von Asm entdeckt.
:
Bearbeitet durch User
Naja, da es hier um Moby AVR gegen den Rest der Welt geht, sage ich auch noch was dazu. Klar sind die Compiler heute sehr sehr gut. Auch manche Controller sind mit einem minimalem Befehlssatz ausgerüstet, der durch einen Compiler leicht eingesetzt werden kann (z.B. PIC). Die meisten Controller, darunter auch RISC-Typen, bieten aber einen so großen Befehlsumfang, dass ein Compiler viele dieser Opcodes ignorieren muss, da sonst innerhalb des Compiler zu viele Fallunterscheidungen nötig werden. Da ist mit handgestricktem Assemblercode also durchaus noch etwas optimierbar. Ob das angesichts der Rechenleistung halbwegs moderner Controller relevant ist, ist vom Einzelfall abhängig.
Guido B. schrieb: > Die meisten > Controller, darunter auch RISC-Typen, bieten aber einen so großen > Befehlsumfang, dass ein Compiler viele dieser Opcodes ignorieren > muss, da sonst innerhalb des Compiler zu viele Fallunterscheidungen > nötig werden. Da ist mit handgestricktem Assemblercode also durchaus > noch etwas optimierbar. Mit verlaub, aber bevor du das mit Quellen belegen kannst, glaube ich da kein Wort. Opcodes zu ignorieren wegen "Fallunterscheidungen" im Compiler wäre dermassen unsinnig.
Diese Diskussion ist ungefähr genauso unsinnig wie "Python ist nutzlos, C ist viel schneller". Ja, stimmt. Nur dass mir für 99 von 100 Programmen die ich schreibe die Performance völlig egal ist, weil das Ganze schon in Python nur 0.3 Sekunden dauert. Ja, in C wären es vielleicht nur 0.01 Sekunden, aber wen interessiert's? Mich nicht. Dafür brauche ich in C die zehnfache Zeit um's aufzuschreiben. Nur dass bei dieser dämlichen C vs ASM-Debatte der Performance-Unterschied nichtmal 10000% ist wie bei Python vs C sondern vielleicht 10%. Und das auch nur, wenn man sich sehr geschickt anstellt in ASM. Nobody cares. Deal with it.
:
Bearbeitet durch User
@Sven Du hast wohl eher PC-Programme im Sinn ?! Performance ist ja nur der eine Aspekt. Der andere wesentliche ist der Platzbedarf. > Dafür > brauche ich in C die zehnfache Zeit um's aufzuschreiben. Diese Äußerlichkeiten zu erwähnen habe ich mich hier noch gar nicht getraut. Da finde ich Asm, garniert mit entsprechenden Kommentaren zu Funktion und Schnittstellen nämlich auch wesentlich kompakter und übersichtlicher. Ehrlich. Aber lassen wir das, denn dieses Empfinden ist höchst subjektiv und die Meinungen geteilt.
:
Bearbeitet durch User
Moby A. schrieb: > Der andere wesentliche ist der Platzbedarf. Dieses Argument gilt schon mindestens 20 Jahre nicht mehr und es für heutige Hardware vorzubringen, ist einfach nur lächerlich.
Moby A. schrieb: > @Sven > Du hast wohl eher PC-Programme im Sinn ?! > Performance ist ja nur der eine Aspekt. > Der andere wesentliche ist der Platzbedarf. Also mein uC für 8 Euro hat 1 MB Flash und davon hab ich vielleicht 100kB belegt. Moby A. schrieb: > Diese Äußerlichkeiten zu erwähnen habe ich mich hier noch gar nicht > getraut. Da finde ich Asm, garniert mit entsprechenden Kommentaren zu > Funktion und Schnittstellen nämlich auch wesentlich kompakter und > übersichtlicher. Ehrlich. Aber lassen wir das, denn dieses Empfinden ist > höchst subjektiv und die Meinungen geteilt. Schon, aber irgendwie sind 99.x% der Leute (auch in diesem Thread btw) zufällig der Meinung dass C leichter zu lesen ist. Hey, wenn du gern ASM schreibst, tu's doch einfach. Ich hab damit überhaupt kein Problem. Aber dieses rumgestreite, dass das das beste sei seit geschnitten Brot und alle Leute die C benutzen sind nur verblendet und es ginge besser ... was soll das denn. Das ist einfach bloß albern.
:
Bearbeitet durch User
Mein Brötchengeber würde mich rauswerfen, wenn ich jetzt mit Assembler programmieren würde. So von wegen effizientes Entwickeln. Zu Recht würde er das. ;-)
>Assembler wieder auf dem Weg nach vorn Syphilis weiter auf dem Vormarsch http://www.pharmazeutische-zeitung.de/index.php?id=49611 Danke, aber ich muß nicht jeden Trend mitmachen ;-)
Michael K. schrieb: >>Assembler wieder auf dem Weg nach vorn > > Syphilis weiter auf dem Vormarsch > http://www.pharmazeutische-zeitung.de/index.php?id=49611 > > Danke, aber ich muß nicht jeden Trend mitmachen ;-) Muahaha... jetzt hab ich Kaffeeflecken auf der Tastatur... Best answer ever...
Warum sich viele von Moby so angestachelt fühlen, liegt doch nur an folgender Tatsache: Moby verallgemeinert bewusst und provozierend seine Mini-Projekte, für die tatsächlich Assembler reicht, derart, dass er sagt: "Die ganze Welt kommt mit Mini-Programmen aus, Assembler reicht" Und genau hier liegt der Trugschluss. Moby kennt nur seine Mini-Programme, hat aber von Elektronik-Projekten in der Praxis (außer seinen eigenen) überhaupt keine Ahnung. Da, wo ein ATmega reicht, vernetzt er hunderte von ATTinys und sagt: "ATTiny reicht, Assmbler reicht". Warum? Weil er es nicht besser kann! Kann man zwar so machen, ist aber ineffizient. In C macht mans mit dem nächstgrößeren Prozessor in einem zehntel der Zeit. Da wo Moby viele Jahre an seinem Smart-Home-System rumbastelt, machts ein anderer in ein paar Wochen fertig. Die eigentliche Frechheit von Moby ist, von seinem Mikrokosmos auf den Rest der Welt zu schließen. Das ist sein großer Irrtum. Und es kommt absolut arrogant rüber. Wenn alle vor 20 Jahren auf Moby gehört hätten, dann stände bei uns kein PC unterm Tisch, sondern heute noch ein 8-Bit-Prozessor mit angeflanschter HEX-Tastatur. Das wiederum zeigt, dass Programmieren in Assembler eine Sackgasse ist. Soll Moby ruhig noch 20 Jahre mit ATTinys rummachen. Aber er soll einfach dabei die Füße stillhalten.
Moby A. schrieb: > P. M. schrieb: >> obwohl völlig klar ist, dass Moby's Behauptungen null >> Substanz haben. > > Schön, wenn Du das behauptest... Deine Begründung hat jedenfalls Null > Substanz, es gibt nämlich schlicht keine. Sag mal unser Moby hat doch definitiv Verwandte in Katzelsried. So viel Zufall gibts doch gar nicht. Die Krönung wäre jetzt noch beide in den gleichen Thread zu locken. Was würd ich dafür geben...
P. M. schrieb: > Moby, hast du eigentlich ein einzelnes Beispiel, wo du mit Assembler > tatsächlich besser Gefahren bist, als mit C? Das ist ja der Gag an der Geschichte. Mehr als einen 20 Zeiler (schon öfter auch Micky Maus code genannt) hat er nichts auf die Beine gestellt ;-) siehe hier: Beitrag "Kleines Tiny13 Sensorboard" Aber dann soooo ne Klappe ...
:
Bearbeitet durch User
Gu. F. schrieb: > Mehr als einen 20 Zeiler (schon öfter auch Micky Maus code genannt) hat > er nichts auf die Beine gestellt ;-) Naja, mehr hat er zumindest nicht präsentiert und ich würde es an seiner Stelle auch nicht tun. Der arme, sture Kerl hat doch die ganze Programmiererwelt gegen sich aufgebracht ;-)
Dank Moby haben wir alle über die Jahre in epischer Breite erfahren wo Vor- und Nachteile des ASM gegenüber einem Rudel anderer Spachen liegen und wie groß, klein, wesentlich oder unwesentlich die sind. Wir wissen jetzt was die Mehrheit darüber denkt und was Moby unbeeindruckt von jeglicher Argumentation darüber denkt. Wer nach all dieser Zeit wirklich immer noch inhaltlich mit Moby darüber diskutiert ist nicht weniger stur und uneinsichtig. Unnötig zu persönlichen Angriffen überzugehen.
Michael K. schrieb: > Dank Moby haben wir alle über die Jahre in epischer Breite erfahren wo > Vor- und Nachteile des ASM gegenüber einem Rudel anderer Spachen liegen > und wie groß, klein, wesentlich oder unwesentlich die sind. Nein, eben gerade nicht. Moby bringt ja eben gerade keine Fakten in die Diskussion ein, er windet sich bloss indem er jede Gegenrede mit dem nächsten seiner unbegründeten Argumente kontert, und dabei schon lange im Kreis geht. Michael K. schrieb: > Wer nach all dieser Zeit wirklich immer noch inhaltlich mit Moby darüber > diskutiert ist nicht weniger stur und uneinsichtig. Frage mich auch, warum ich das eigentlich mitmache. Keine Ahnung, warum es Spass macht. Überzeugen muss/kann man ja hier niemanden mehr und etwas lernen wird man schon gar nicht.
was man auch immer von Mobys starker Fokussierung auf ASM halten mag: Er bleibt in seiner Argumentation immer sachlich und wird nicht aufbrausend. Das ist ihm auf jeden Fall hoch anzurechnen.
Wegstaben V. schrieb: > was man auch immer von Mobys starker Fokussierung auf ASM halten mag: Er > bleibt in seiner Argumentation immer sachlich und wird nicht > aufbrausend. Das sehe ich anders. Er versieht jeden Satz, wo er lächelnd auf den anderen "herunterschaut", mit einem Smiley ";-)". Das kommt ziemlich herablassend rüber und zeugt von wenig Respekt.
Wegstaben V. schrieb: > Er > bleibt in seiner Argumentation immer sachlich und wird nicht > aufbrausend. Sachlich ist er schonmal nicht, da er bloss seine Argumente wiederholt und umformuliert, aber nicht auf Gegenfragen eingeht. Beispielsweise liefert er keinerlei belastbare Fakten oder konkrete Beispiele für seine Aussagen. Aufbrausend wird er nicht, das stimmt. Es gibt aber auch andere Möglichkeiten, um unanständig zu sein in einer Diskussion. Beispielsweise die freundlich-herablassende Art, die er pflegt.
Wegstaben V. schrieb: > was man auch immer von Mobys starker Fokussierung auf ASM halten mag: Er > bleibt in seiner Argumentation immer sachlich und wird nicht > aufbrausend. Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Sachlich? Würde ich mir anders vorstellen. (Wollte hier eigentlich nichts mehr schreiben, aber das konnte ich nun nicht so stehen lassen.)
:
Bearbeitet durch Moderator
P. M. schrieb: > Frage mich auch, warum ich das eigentlich mitmache. Das gleiche wie alle anderen hier (inklusive mir): unterhalten werden wollen. Es gibt Figuren in diesem Forum, da ist der Name schon ein Garant für beste Unterhaltung zur Mittagszeit. Ich will keine Namen nennen, aber die Diskussionen über Assembler, Basisteilchen und Hexadezimalsysteme sorgen immer wieder für Kurzweil.
P. M. schrieb: > Nein, eben gerade nicht. Moby bringt ja eben gerade keine Fakten in die > Diskussion ein Aber er ist der Tippgeber an denen sich die anderen abackern und viele gute Informationen liefern. Auch eine Leistung. le x. schrieb: > Ich will keine Namen nennen, aber die Diskussionen über Assembler, > Basisteilchen und Hexadezimalsysteme sorgen immer wieder für Kurzweil. https://de.wikipedia.org/wiki/Raymond_Kurzweil ?? Die unheilige Dreieinfältigkeit ... (kommt, soweit ich mich erinnern kann, von Falk) Ja, ist immer wieder lustig, aber wenn einem das Nervenkostüm dünn wird ob dieser Beratungsresistenz darf man auch einfach in den RO Modus wechseln. Ich glaube das Moby nicht halb so verbohrt ist wie man glaubt, er gönnt uns nur nicht das letzte Wort und bepinkelt sich vor Lachen wie viel Energie hier manche reinstecken seine Worte zu widerlegen und wie die aus der Naht gehen wenn nichts davon ankommt. Jörg W. schrieb: > Sachlich? Im Vergleich zu dem was hier oft abgeht, ja.
Assembler ist auch ein hohes Risiko für den Arbeitgeber. Scheidet ein Assemblerprogrammierer aus, ist die Gefahr, daß er verbrannte Erde hinterläßt, viel höher, als bei einem C-Programmierer. C läßt sich auch deutlich besser im Team programmieren, d.h. die Kollegen können gegenseitig die Qualität überwachen.
Uhu U. schrieb: > Moby A. schrieb: > Der andere wesentliche ist der Platzbedarf. > > Dieses Argument gilt schon mindestens 20 Jahre nicht mehr und es für > heutige Hardware vorzubringen, ist einfach nur lächerlich. Lächerlich für aktuell immer fettere Controller vielleicht. Oder gar ein Raspberry für einfache MSR Aufgaben. Woraus leitest Du ab daß diese immer die sinnvollste Lösung darstellen wenn mit etwas Investment in effiziente Asm-Programmierung ein kleiner AVR langt? Wolfgang R. schrieb: > Mein Brötchengeber würde mich rauswerfen, wenn ich jetzt mit > Assembler programmieren würde. Tja den hat der Bastler glücklicherweise nicht. Und damit auch nicht tausend weitere Vorgaben die die Wahl des Controllers beeinflussen. Für den Bastler zählt nur eines: Die konkreten Bedürfnisse seiner Anwendung. Die sind für einfache bis mittelkomplexe MSR Projekte meist locker mit einem AVR erledigt.
Frank M. schrieb: > Moby verallgemeinert bewusst und provozierend seine Mini-Projekte, > für die tatsächlich Assembler reicht Ich verallgemeinere keine Mini-Projekte sondern >90% aller MSR Projekte hier im Forum und im Alltag. > Moby kennt nur seine > Mini-Programme, hat aber von Elektronik-Projekten in der Praxis (außer > seinen eigenen) überhaupt keine Ahnung. Da, wo ein ATmega reicht, > vernetzt er hunderte von ATTinys und sagt: "ATTiny reicht, Assmbler > reicht". Warum? Weil er es nicht besser kann! Ich staune immer über das, was speziell Du zu wissen glaubst. Wenn ein Tiny für ein Projekt genügt dann genügt er- und man muß keinen Cortex-M einsetzen. Das ist Effizienz! Und zwar auf der ganzen Linie. > Da wo Moby viele > Jahre an seinem Smart-Home-System rumbastelt, machts ein anderer in ein > paar Wochen fertig. So ein Smart-Home ist nie fertig. Warum? Weil ständig neue Wünsche hinzukommen. > Die eigentliche Frechheit von Moby ist, von seinem Mikrokosmos auf den > Rest der Welt zu schließen. Das ist sein großer Irrtum. Und es kommt > absolut arrogant rüber. Ein Frank M. muß mir sicher nicht erklären, was frech und arrogant ist. Wenn der Fakt, daß Asm so effizient ist, Dein Weltbild und C-Selbstwertgefühl stört ist das nicht mein Problem. > Wenn alle vor 20 Jahren auf Moby gehört hätten, dann stände bei uns kein > PC unterm Tisch, sondern heute noch ein 8-Bit-Prozessor mit > angeflanschter HEX-Tastatur. Das wiederum zeigt, dass Programmieren in > Assembler eine Sackgasse ist. Jeder Zweck mit den richtigen Mitteln. Ein Asm-Betriebssystem und entsprechende Anwendersoft ginge freilich auf heutigen PC-Systemen ab wie eine Rakete und kein normaler Anwender würde noch von Aufrüstung reden. Klar, daß sowas schlecht für die Industrie wäre! > Aber er soll > einfach dabei die Füße stillhalten. Das könnte Dir so passen. Wenn sich in das Feuer lahmarschiger fetter C-Software eiskaltes Asm-Wasser gießen lässt dann mach ich das mit großer Freude und labe mich an den aufgeschreckt empörten Reaktionen ;-)
Moby A. schrieb: > effiziente Asm-Programmierung Blablabla Du bist einfach ein Schwätzer. Geh endlich heim spielen. Hier diskutierten Fachleute... Man man so viel Käse in einem Thread gibt's sonst nur beim Bindl.
Moby A. schrieb: > eiskaltes Asm-Wasser Dann lern erst mal assembler. Speziell solche Befehle wie EOR :-) Jaja Salz in die Wunde ich weiß...
Witkatz :. schrieb: > Naja, mehr hat er zumindest nicht präsentiert und ich würde es an seiner > Stelle auch nicht tun. Der arme, sture Kerl ... wird ganz sicher mit weiteren Projekten die Begrenztheiten von C vorführen. Aber sicher nicht, weil er arm und stur wäre ;-) Leider passen die großen Asm-Projekte von mir hier nicht rein, u.a. weil sie zu speziell an meine Bedürfnisse angepasst sind. Aber wenn ich es recht bedenke ist das noch lange nicht nötig, solange es die größten Marktschreier und sogenannten "Großen Jungs" hier nicht schaffen, schon für ein ganz kleines Asm-Programm eine ressourcensparendere Lösung mit dem angeblich so hochpoduktiv mönströsen C-Instrumentarium zu liefern ;-)
Uhu U. schrieb: > lächerlich. Moby A. schrieb: > Lächerlich Gu. F. schrieb: > Schwätzer Lächerlicher Schwätzer ! (empört mit dem Fuß aufstampf) So, besser jetzt ? Der eine will Java auf einer 8bit MCU und der andere WIN 10 in Assembler programmieren. Ich will nur weg hier wo sich Erwachsene wie bockige kleine Gören benehmen und das mach ich jetzt auch.
Gu. F. schrieb: > Du bist einfach ein Schwätzer. Warum muß ich da bloß immer zuerst an Dich denken? Stell mal hier was Eigenes auf die Beine dann reden wir weiter. Wenn ichs einfach haben wollte wär ich auch Bayern Fan und nicht der einer drittklassigen Mannschaft ;-) Michael K. schrieb: > Ich will nur weg Du wirst lachen. Das ist auch das Sinnvollste wenn man nicht mehr weiter weiß ;-)
:
Bearbeitet durch User
Moby A. schrieb: > für ein ganz kleines Asm-Programm eine ressourcensparendere Lösung mit > dem angeblich so hochpoduktiv mönströsen C-Instrumentarium zu liefern Genau darum geht es doch gerade nicht, bzw nicht in dem Sinn, wie du es meinst. Arbeitszeit ist auch eine wichtige Ressource, vor allem auch für Hobbyisten (nur wird sie da kurioserweise Freizeit genannt). Es mag ja sein, dass im Vergleich zu dem weltbesten ASM-Programmierer der C-Compiler im Mittel (!) geringfügig langsameren und größeren Code produziert, aber der Code ist sehr viel schneller geschrieben, sehr viel wartbarer und - Risesiger Bonus - problemlos (von der Hardwareabstraktion mal abgesehen) auf andere Platformen übertragbar. Und wenn ich mir für meine Einzelstücke durch einen 50Cent teureren Controller mit mehr Speicher all diese Vorteile erkaufen kann, wäre ich dumm, dies nicht zu tun. Edit: Und warum sollte man > für ein ganz kleines Asm-Programm überhaupt > eine ressourcensparendere Lösung finden wollen? Ein ganz kleines Projekt kriegt den Controller eh nicht voll. Und für gesparten Ram und Cycles gibts kein Geld zurück und noch weniger für die längere Entwicklungszeit
:
Bearbeitet durch User
Peter D. schrieb: > Scheidet ein Assemblerprogrammierer aus, ist die Gefahr, daß er > verbrannte Erde hinterläßt, viel höher, als bei einem C-Programmierer. Weil vielleicht die Doku schlecht ist? Weil vielleicht die Mehrzahl der Nachfolger kein Asm kann? Beides ließe sich korrigieren... > C läßt sich auch deutlich besser im Team programmieren, d.h. die > Kollegen können gegenseitig die Qualität überwachen. So wird es wohl sein. Es müsste aber nicht sein.
Moby A. schrieb: > Weil vielleicht die Doku schlecht ist? ok, kommt bei dir ja nicht vor - dank selbsterklärendem ASM.
Moby A. schrieb: > Ein Asm-Betriebssystem und entsprechende Anwendersoft ginge freilich auf > heutigen PC-Systemen ab wie eine Rakete Eher unwahrscheinlich. Wann hast du das letzte Mal in die Befehlsliste heutiger x86-64 reingesehen? Da lernst du manches Telefonbuch schneller auswendig. Und bis du bei einem solchen Betriebssystem die Handoptimierung des Codes fertig hast ist die dazu empfohlene Strategie aufgrund neuer Implementierungs-Architekturen schon 2 Generationen weiter und du kannst von vorne anfangen. Als einfaches Beispiel, um es nicht zu kompliziert zu machen: Versuch mal, deinen AVR Code so zu schreiben, dass hintereinander stehende Befehle nicht von einander abhängig sind und das Ergebnis eines Ladebefehls möglichst erst 10 Befehle später benötigt wird. Und denk dabei an versteckte Schweinereien, wie etwa ein INC Befehl, der das Carry-Flag zwar nicht nutzt, aber davon abhängt.
Michael K. schrieb: > Unnötig zu persönlichen Angriffen überzugehen. Das wäre in der Tat die nächste Phase, wenn Ignorieren und Lächerlichmachen erfolglos bleiben ;-) P. M. schrieb: > und > etwas lernen wird man schon gar nicht. Doch. Das könntest Du durchaus. Ein (womöglich Uni-) Bildungs-Investment in C oder gar OOP, in die Cortexe und andere Hochbitter dieser Welt lässt man aber nicht so einfach in Frage stellen... Da mag die App noch so einfach sein. Dafür hab ich doch Verständnis ;-)
Frank M. schrieb: > mit einem Smiley ";-)". Das kommt ziemlich > herablassend rüber und zeugt von wenig Respekt. Das soll nur meine Stimmungslage wiedergeben, wenn mal wieder C,OOP,Cortexe und andere Hochbitter für einfache Aufgaben als effiziente einfachste Lösung verkauft werden ;-) Michael K. schrieb: > er gönnt > uns nur nicht das letzte Wort und bepinkelt sich vor Lachen wie viel > Energie hier manche reinstecken seine Worte zu widerlegen und wie die > aus der Naht gehen Nö. Ich lerne auch gern was. Bei Diskussionen über Sinn und Zweck von Asm war das allerdings bislang enttäuschend wenig, so daß eher der Amüsierfaktor (s.o.) überwiegt. Ein praktischer Beweis der C-Effizienz anhand meiner Projektvorlage könnte mich allerdings zum Staunen und Umdenken bewegen- was die Bewertung der Hochsprache angeht.
A. K. schrieb: > versteckte Schweinereien, wie etwa ein INC Befehl, der das > Carry-Flag zwar nicht nutzt, aber davon abhängt. Um das mal an Code eines Pseudo-AVR zu illustrieren, der sich intern wie ein x86er dieses Jahrhunderts verhält: code1: ld r16,x add r16, r17 st x,r16 inc xl dec r16 brnz code1 code2: ld r16,x add r16, r17 st x,r16 subi xl, -1 subi r16, 1 brnz code2 Es geht jetzt nicht darum, den aufgrund der Unterschiede zu x86 nicht-optimalen Code zu verbessern. Sondern um die Frage eines erstaunten Programmierers, weshalb Code2 bei Intel zwischendurch mal viel schneller lief als Code1, während es bei AMD keinen Unterschied ergab.
:
Bearbeitet durch User
Vlad T. schrieb: > Und warum sollte man >> für ein ganz kleines Asm-Programm > überhaupt >> eine ressourcensparendere Lösung > finden wollen? Da fallen mir schon Gründe ein 1. aus sportlichem Ehrgeiz oder zum Spaß 2. als Lernbeispiel 3. um die Ergebnisse des Compilers mit dem ASM Code wirklich vergleichen zu können
A. K. schrieb: > Um das mal an Code eines Pseudo-AVR zu illustrieren, der sich intern wie > ein x86er dieses Jahrhunderts verhält: Sorry, ersetze den loop counter r16 in dec r16 bzw subi r16, 1 durch r18. Also code1: ld r16,x add r16, r17 st x,r16 inc xl dec r18 brnz code1 code2: ld r16,x add r16, r17 st x,r16 subi xl, -1 subi r18, 1 brnz code2
:
Bearbeitet durch User
Vlad T. schrieb: > aber der Code ist sehr viel schneller geschrieben, Das "sehr viel" kannst Du bei einem geübten Asmler streichen, insbesondere wenn er/sie mit System dran geht und das Rad nicht immer wieder neu erfindet. > sehr viel > wartbarer Einspruch. Das ist eine Sache der Doku- und der Übung in Asm. Was dessen Transparenz, Wartbarkeit und Fehlersuche erleichtert ist die Tatsache daß man 100% des endgültigen Codes stets vor sich hat. > und - Risesiger Bonus - problemlos (von der > Hardwareabstraktion mal abgesehen) auf andere Platformen übertragbar. Das erübrigt sich, wenn man wegen Asm bei der gleichen Architektur bleiben kann! > Ein ganz kleines Projekt kriegt den Controller eh nicht voll. Ein etwas größeres eher. Welches man womöglich zukünftig noch etwas erweitern möchte. Ist es nicht schön wenn das Ganze immer noch in den ausgesuchten, billigeren Controller passt ? Jetzt stell Dir mal vor das Ding ist schon irgendwo fix verbaut... Da dankst Du dem Allmächtigen, daß keine Neuentwicklung nötig wird ;-)
:
Bearbeitet durch User
A. K. schrieb: > Sondern um die Frage eines > erstaunten Programmierers, weshalb Code2 bei Intel zwischendurch mal > viel schneller lief als Code1, während es bei AMD keinen Unterschied > ergab. Das passt nicht hierher weil AMD und Intel Prozessoren eines viel komplexeren Kalibers sind. Die eklatanten Performance-Unterschiede zwischen unterschiedlichen Programmiersprachen sind da auf einem Controller viel relevanter und alltäglicher...
Moby A. schrieb: > Weil vielleicht die Doku schlecht ist? > Weil vielleicht die Mehrzahl der Nachfolger kein Asm kann? Beides ließe > sich korrigieren... Dann fang endlich an zu lernen. Deine Kasperei ist mindestens peinlich. Ein Blinder Maler ist eine schwacher Vergleich für Blindgänger wie dich. Ich habe ja immer noch die Hoffnung dass du nur trollst weil ich noch an einen Rest-IQ von dir glaube. Aber irgendwas sagt mir dass ich wieder enttäuscht werden ;-) Wie auch immer, ich kriege langsam Kreuzschmerzen wenn ich mich ständig auf deinen Horizont runterbeugen muss. Ich werde dich darum nicht weiter mit Trollfutter versorgen. Schönes Asm kennen noch. Vlt. schaffst du ja mal ein programm mit 30+ Zeilen...
:
Bearbeitet durch User
Gu. F. schrieb: > Ich werde dich darum nicht weiter > mit Trollfutter versorgen Soooo ein Pech ;-) Allzu erfolgreich warst Du zwar nicht aber ein bunter Farbtupfer in der Diskussion! Deine Minuspunkte werden mir fehlen ;-((
:
Bearbeitet durch User
Yalu X. schrieb: > Nennt man so einen besonders starken Kräuterschnaps? ;-) Will jetzt nicht arrogant wirken aber unter dem scheint mancher Forumsteilnehmer zuweilen zu stehen :-)
Moby A. schrieb: > Das passt nicht hierher weil AMD und Intel Prozessoren eines viel > komplexeren Kalibers sind. Es war dein eigener Vorschlag, heutige PC Systeme in Assembler zu programmieren: Moby A. schrieb: > Ein Asm-Betriebssystem und entsprechende Anwendersoft ginge freilich auf > heutigen PC-Systemen ab wie eine Rakete
A. K. schrieb: > Eher unwahrscheinlich. Wann hast du das letzte Mal in die Befehlsliste > heutiger x86-64 reingesehen? Da lernst du manches Telefonbuch schneller > auswendig. Mag sein. Ein Sammelsurium von Befehlen im krampfhaften Bemühen, über Jahrzehnte kompatibel zu allen möglichen Entwicklungen zu bleiben. Allerdings würden u.U. auch schon die 8086er Codes für hochperformante Asm-Programmierung ausreichen !? > Und bis du bei einem solchen Betriebssystem die Handoptimierung des > Codes fertig hast ist die dazu empfohlene Strategie aufgrund neuer > Implementierungs-Architekturen schon 2 Generationen weiter und du kannst > von vorne anfangen. In der Praxis hast Du angesichts dieser Entwicklung recht: Sich auf eine übergeordnete (Hochsprachen-)Ebene zu begeben scheint geboten. ABER: Wir reden hier vom PC Bereich und nicht von kleinen 8-bittigen MCs, die hardwarenah einfache MSR Aufgaben lösen. > Als einfaches Beispiel, um es nicht zu kompliziert zu machen: Versuch > mal, deinen AVR Code so zu schreiben, dass hintereinander stehende > Befehle nicht von einander abhängig sind und das Ergebnis eines > Ladebefehls möglichst erst 10 Befehle später benötigt wird. Und denk > dabei an versteckte Schweinereien, wie etwa ein INC Befehl, der das > Carry-Flag zwar nicht nutzt, aber davon abhängt. Schwierig. Aber zum Glück bei MCs nicht nötig.
A. K. schrieb: > Es war dein eigener Vorschlag, heutige PC Systeme in Assembler zu > programmieren Der wurde sogar schon umgesetzt. Also möglich wärs.
Moby A. schrieb: > Allerdings würden u.U. auch schon die 8086er Codes für hochperformante > Asm-Programmierung ausreichen !? Kannst du haben. MS-DOS war lange Zeit das auf PCs dominierende Betriebssystem und das wurde in Assembler geschrieben. Anwendungen nicht selten auch. Ich kenne freilich niemanden, der MS-DOS nachtrauert. > Schwierig. Aber zum Glück bei MCs nicht nötig. Pustekuchen. Der Cortex M7 (z.B. im STM32F7) ist dual-issue, d.h. der kann pro Takt 2 Befehle dekodieren und ausführen. Aber natürlich nur, wenn die nicht voneinander abhängen und sich auch nicht anderweitig gegenseitig auf den Füssen stehen. Das ist grob das Niveau vom Pentium P5 der 90er, was die Entwicklung der Implementierungen von Mikrocontrollern angeht. Und ebendieser P5 war der erste x86er, bei dem Handoptimierung in Assembler anfing, kompliziert zu werden. Und der CM7 war sicher nicht das letzte Wort zu diesem Thema.
:
Bearbeitet durch User
Moby A. schrieb: > Deine Minuspunkte werden mir fehlen Hab' dir mal ein paar "lebenswert" gegeben. Und immer schön wacker bleiben. mfg.
Moby A. schrieb: > Welches man womöglich zukünftig noch etwas > erweitern möchte. Und während sich die Programmierer in Villabacho bis spät in der Nacht durch meterweise ASM Code durchquälen, feiert Villariba längst die erfolgreichen Tests des erweiterten C-Projekts. Moby A. schrieb: > Ist es nicht schön wenn das Ganze immer noch in den > ausgesuchten, billigeren Controller passt ? Leidest du vielleicht an digitaler Agoraphobie? Wurde es schon erwähnt, dass ein vernünftig geschreibenes C Projekt genausogut rein passt?
A. K. schrieb: > Schwierig. Aber zum Glück bei MCs nicht nötig. > > Pustekuchen. Der Cortex M7 ... So ist das eben bei zuviel Komplexität. Das trägt sein Scherflein dazu bei daß die ARMen Dinger immer schlechter in Asm zu programmieren sind. Da lob ich mir die AVRs und daß alle einfache Sachen heute noch nicht mit ARM gelöst werden müssen.
Witkatz :. schrieb: > Wurde es schon erwähnt, > dass ein vernünftig geschreibenes C Projekt genausogut rein passt? Peter D. schrieb: > Im Schnitt sind daher C-Programme etwa 10..50% größer Um mir nicht schon wieder einen eigenen "Repetierer" aus dem Hirn leiern zu müssen ;-)
Moby A. schrieb: > Peter D. schrieb: >> Im Schnitt sind daher C-Programme etwa 10..50% größer Selbst verglichen hast du es also nicht, dass du dich auf fremde Statistiken berufen musst? Die Frage war rein rhetorischer Natur, weil es zig mal erwähnt wurde. 10..50% machen nur ganz selten den Ausschlag den µC zu wechseln. Bevor es so weit kommt, hat man auch in C viele Möglichkeiten die Ressourcennutzung zu optimieren. Gute C Programmierer können eben beides ASM und C und können aus dem ASM Listing Rückschlüsse auf die Qualität des C-Codes ziehen, wenn es drauf ankommt.
:
Bearbeitet durch User
Moby A. schrieb: > Woraus leitest Du ab > daß diese immer die sinnvollste Lösung darstellen wenn mit etwas > Investment in effiziente Asm-Programmierung ein kleiner AVR langt? Was ist denn die "sinnvollste Lösung"? Eine für die man Punkte im Programmiererhimmel bekommt, aber pleite geht? Mit deiner Einstellung wirst du jedenfalls im echten Leben ganz schnell einen Bankrott hinlegen. Na wenigstens hast du hinterher die Müße, darüber nachzudenken, ob das sinnvoll war...
Moby A. schrieb: > Ein Asm-Betriebssystem und entsprechende Anwendersoft ginge freilich auf > heutigen PC-Systemen ab wie eine Rakete und kein normaler Anwender würde > noch von Aufrüstung reden. Ich kann mich noch sehr gut an so ein ASM-Betriebssystem erinnern: KOS von Kontron für deren Z80-Rechner. Das lief wunderbar und vor allem sau schnell in der Warteschleife. Wenn es arbeiten sollte, hatte es einen unübersehbaren Hang zu Instabilität...
Moby A. schrieb: > Vlad T. schrieb: >> aber der Code ist sehr viel schneller geschrieben, > > Das "sehr viel" kannst Du bei einem geübten Asmler streichen, > insbesondere wenn er/sie mit System dran geht und das Rad nicht immer > wieder neu erfindet. vergiss es. Modularisierung und Wiederverwendbarkeit erfordert definierte Schnittstellen und Vereinbarungen, wie zB calling conventions, die das parameterpassing und register clobbering festlegen. Gerade die sorgen dafür. dass overhead entsteht, den ein guter compiler sogar beseitigen kann, wenn er eine whole program optimization macht. Ein guter compiler ist auch sehr viel besser darin, registerzuordnungen zu handlen und hinterher noch da durchzusehen, was zu welchem Zeitpunkt wo ist. Für ihn ist es kein Problem bei einer ge-inline-ten Funktion die Variablen so in die Register zu legen, dass sie nicht mit dem Caller collidieren. Mach das mal mit asm-Funktionen, wenn du nicht das Rad neu erfinden willst. Auch hier hat der gnu-Inline-Assembler deutliche vorteile: hier könnte man nämlich tatsächlich einen ASM-BLock definieren und im asm Platzhalter verwenden, so dass sich der Compiler selbst aussuchen kann durch welche Register er die Platzhalter ersetzt.
Yalu hat in diesem Beitrag unlängst bewiesen, dass Moby's Code in allen Belangen schlechter ist: Beitrag "Re: C versus Assembler->Performance"
Michael K. schrieb: > le x. schrieb: >> Ich will keine Namen nennen, aber die Diskussionen über Assembler, >> Basisteilchen und Hexadezimalsysteme sorgen immer wieder für Kurzweil. > ... > Die unheilige Dreieinfältigkeit ... > (kommt, soweit ich mich erinnern kann, von Falk) Beitrag "Re: 8bit-Computing mit FPGA"
Na endlich, jetzt fehlt nur noch Kurt. Das wird herrlich freu
Markus M. schrieb: > Yalu hat in diesem Beitrag unlängst bewiesen, dass Moby's Code in allen > Belangen schlechter ist: > > Beitrag "Re: C versus Assembler->Performance" in genau jenem Thread bin ich, neben jeder Menge Ignoranz und Unbelehrbarkeit als Reaktion (auf in meinen Augen) sinnvolle Anmerkungen/Hinweise/Ratschläge, auf folgende Aussage gestoßen: Beitrag "Re: C versus Assembler->Performance" Karl Heinz B. schrieb: > Das wars. > Mir reichts. Du bist unbelehrbar. Ich versuch dir eine Brücke zu bauen > und du nimmst nichts an. Gar nichts. Du bist wie ein sturer Esel. > Aber ich warne dich: bei der nächsten 'Nimm doch Assembler' Meldung > in einem C Thread, wird gelöscht. Für KHBs Verhältnisse (im Gegensatz zu seiner sonstigen Engelsgeduld, die er selbst den frechsten/dreistesten Fragestellern entgegenbringt) ist das ja schon ein regelrechter Ausraster.
:
Bearbeitet durch User
Uhu U. schrieb: > Was ist denn die "sinnvollste Lösung"? Die einfachste und Ressourcen-sparendste. > Mit deiner Einstellung wirst du jedenfalls im echten Leben ganz schnell > einen Bankrott hinlegen. Im Programmiereralltag bin ich mit den sinnvollsten Lösungen bislang immer gut gefahren ;-)
Witkatz :. schrieb: > aus dem ASM Listing Rückschlüsse auf die > Qualität des C-Codes ziehen Der Assembler-Programmierer muß nicht erst Rückschlüsse aus irgendwelchen Listings ziehen. Er sieht den einzigen, engültigen Code vor sich und das beste ist: Er hat ihn 100%ig selbst in der Hand!
Markus M. schrieb: > Yalu hat in diesem Beitrag unlängst bewiesen, dass Moby's Code in > allen > Belangen schlechter ist: > > Beitrag "Re: C versus Assembler->Performance" Da wurde gar nichts bewiesen. Asm-Code bleibt die Messlatte für alle anderen Sprachen. Der Thread an sich ist aber lesenswert, möge sich jeder selber ein Urteil dazu bilden.
Uhu U. schrieb: > Das lief wunderbar und vor allem sau schnell in der Warteschleife. Wenn > es arbeiten sollte, hatte es einen unübersehbaren Hang zu > Instabilität... Untauglicher Versuch, von der Qualität eines OS auf die Vor- und Nachteile von Asm zu schließen.
Moby A. schrieb: > Der Assembler-Programmierer muß nicht erst Rückschlüsse aus > irgendwelchen Listings ziehen. Er sieht den einzigen, engültigen Code > vor sich und das beste ist: Er hat ihn 100%ig selbst in der Hand! Das wichtigste: Er versteht davon 0%, wenn es nicht sein eigener ist.
Moby A. schrieb: > auf die Vor- und Nachteile von Asm zu schließen. Welche Nachteile hat denn Asm? mfg.
Moby A. schrieb: >> Beitrag "Re: C versus Assembler->Performance" > > Der Thread an sich ist aber lesenswert, Stimmt. ;-)
Das ist aber mal eine fiese Frage.
Frank M. schrieb: > Er versteht davon 0%, wenn es nicht sein eigener ist. Das mag für Dich zutreffen und Du hattest das in meinem erwähnten Projekt auch hinreichend demonstriert. Thomas E. schrieb: > Welche Nachteile hat denn Asm? Die schlechte Nachricht ist: Je nach eigenem Können, Vorbereitung und System ist etwas mehr Mühe und Zeit nötig. Die gute ist: Es zahlt sich aus ;-)
Moby A. schrieb: > Das mag für Dich zutreffen und Du hattest das in meinem erwähnten > Projekt auch hinreichend demonstriert. Achja... Dein Projekt. Wieviele Interessenten haben Dir mittlerweile ein Platinchen abgenommen? > Die schlechte Nachricht ist: Je nach eigenem Können, Vorbereitung und > System ist etwas mehr Mühe und Zeit nötig. Kannst Du das Wort "etwas" quantifizieren?
Vlad T. schrieb: > Karl Heinz B. schrieb: >> Das wars. >> Mir reichts. Du bist unbelehrbar. Ich versuch dir eine Brücke zu bauen >> und du nimmst nichts an. Gar nichts. Du bist wie ein sturer Esel. >> Aber ich warne dich: bei der nächsten 'Nimm doch Assembler' Meldung >> in einem C Thread, wird gelöscht. Ich meine der Zeitpunkt ist schon längst überfällig...
Moby A. schrieb: > Die schlechte Nachricht ist: Je nach eigenem Können, Vorbereitung und > System ist etwas mehr Mühe und Zeit nötig. Ach komm, das ist doch keine Aussage. Das gilt doch für nahezu alles. Sowohl Fahrrad fahren als auch Kuchen backen. So eine Antwort wirft doch nur noch mehr Fragen auf. Was sind denn die von dir angesprochenen Nachteile konkret? Wieviel und welches Können? Wieviel und welche Vorbereitung? Was hat das System damit zu tun? Welche Mühen sind das und wieviel Mühe und Zeit kostet das? mfg.
Eigentlich ist es ja recht einfach: ASM ist in der THEORIE immer besser als alles Andere egal wie groß das Probjekt ist insofern hat Moby AVR natürlich recht.. ein durchschnittlicher Programmierer, wird es aber nur bis zu einer gewissen komplexität schaffen, besser zu sein als mit C mit etwas Aufwand wird er es schaffen diese Grenze nach oben zu verschieben aber irgendwo ist die Grenze (weiter oben kommt dann nochmal eine, wo man nicht mehr C sonder z.b. Pascal/c#/java nimmt, aber das wollen wir jetzt nicht ausarten lassen..) "Argumente" wie "ASM ist einfach" sind natürlich auch recht einfach zu durchschauen: das ist so wie Schach-Regeln, die kann man auch in 5 Minuten erklären.. deshalb ist Schach-Spielen noch lange nicht einfach.. Ich für mich persönlich hab folgende Entscheidung getroffen: 99% meiner Projekte sind WEIT weg von der Linie, wo ich es es selber im ASM schreiben könnte... dort verwende ich auch z.b. fertige "Biliotheken" für 1-wire, crc, 443mhz funk, usw (wo findet man sowas überhaupt in ASM? fix/fertig?) ...von tcp/ip mit W5100 oder EncJ-irgnedwas mal ganz abgesehen.. die Restenlichen 1% der Fälle die ich VIELLEICHT in ASM schreiben könnte, funktionieren auch in C/C++, würde also für MICH überhaupt keinen Sinn ergeben das in ASM zu schreiben... vorallem weil ich dann für dieses 1% länger brauchen würde, als für die restlichen 99% (weil ich erstmal ASM so gut lernen müsste, dass was brauchbares rauskommt..)
:
Bearbeitet durch User
Moby A. schrieb: > Uhu U. schrieb: >> Was ist denn die "sinnvollste Lösung"? > > Die einfachste und Ressourcen-sparendste. Was ist "Ressourcen-sparend"? Wenn man an dem spart, von dem am meisten vorhanden ist, oder wenn man die knappen Resourcen schont? Aber ich sehe schon, derart einfache Überlegungen überfordern dich schon heillos - wie soll das erst bei einem ensthaften ASM-Projekt mit ein paar 100 KB Codeumfang werden...
Moby A. schrieb: > Der Assembler-Programmierer muß nicht erst Rückschlüsse aus > irgendwelchen Listings ziehen. Er sieht den einzigen, engültigen Code > vor sich und das beste ist: Er hat ihn 100%ig selbst in der Hand! Oh je... Du hast noch nie ASM-Code gesehen, der so richtig aus dem Ruder gelaufen und unpflegbar geworden ist... Du gehst offensichtlich davon aus, dass ASM-Programmierer biller sind, als Computer, die ihnen die Dreckarbeit abnehmen und so die Möglichkeit geben, ihren Hirnschmalz in Dinge zu investieren, die einen höheren Ertrag bringen, als das Maschinencodegepfriemel... Du hast das Zeug zum Pleitier. Moby A. schrieb: > Untauglicher Versuch, von der Qualität eines OS auf die Vor- und > Nachteile von Asm zu schließen. Na ja, was soll man von einem völlig unerfahrenen aber ziemlich großmäulugen Greenhorn anderes erwarten...
Moby A. schrieb: > Er sieht den einzigen, engültigen Code > vor sich Er sieht immer nur einen klitzekleinen Ausschnitt davon... ...es sei denn es ist ein 20zeiler. Und entgültig ist der ASM Code eh fast immer. In den packt nämlich keiner mehr gerne rein, wenn die Oberfläche angetrocknet ist.
Witkatz :. schrieb: > Moby A. schrieb: > Er sieht den einzigen, engültigen Code > vor sich > > Er sieht immer nur einen klitzekleinen Ausschnitt davon... Er sieht was -selbstverantwortet- endgültig ist. Was beim C-Code schließlich rauskommt ist je nachdem was verschiedene Compiler und diverse Optimierungen veranstalten nicht ganz so genau vorherbestimmt, das sieht dann man immer erst im (längeren) Asm-Listing. Uhu U. schrieb: > Oh je... Du hast noch nie ASM-Code gesehen, der so richtig aus dem Ruder > gelaufen und unpflegbar geworden ist... Übung, System und Doku können das verhindern. > Du gehst offensichtlich davon aus, dass ASM-Programmierer biller sind, > als Computer, die ihnen die Dreckarbeit abnehmen und so die Möglichkeit > geben, ihren Hirnschmalz in Dinge zu investieren, die einen höheren > Ertrag bringen, als das Maschinencodegepfriemel... Denkarbeit nimmt keine Programmiersprache der Welt ab. Asm verlangt für's Ergebnis manchmal etwas mehr Aufwand, der bei kleinen 8-Bittern aber überschaubar bleibt. > Na ja, was soll man von einem völlig unerfahrenen aber ziemlich > großmäulugen Greenhorn anderes erwarten... Daraus schließe ich, daß Dir auf meinen Einwand hin nur noch persönliche Angriffe bleiben ;-)
Moby A. schrieb: > Da wurde gar nichts bewiesen. Asm-Code bleibt die Messlatte für alle > anderen Sprachen. Das ist selbst bei Performance-Fragen Quatsch: Ein Assembler-Code ist nie um Grössenordnungen, sondern höchstens (seltenst) um einige zehn Prozente schneller. Die Rechenleistung pro Grösse/Preis/Energie verdoppelt sich bekanntlich ca. alle zwei Jahre. Wenn dein Assembler-Code also (unwahrscheinlich) 20% schneller ist, dann holt dich alleine die technische Entwicklung schon nach 6 Monaten wieder ein.
Uhu U. schrieb: > Was ist "Ressourcen-sparend"? Sparen an Flash, RAM, MHz, zuweilen Peripherie... Motivation ist natürlich nicht der Kauf von etwas was man nicht nutzt sondern maximale Nutzung dessen was man (eine Nummer kleiner) gekauft hat. Mit ein paar Reserven für die Zukunft, versteht sich! > Aber ich sehe schon, derart einfache Überlegungen überfordern dich Ich sehe daß Du überfordert bist. Mit Fragen wie der obigen...
:
Bearbeitet durch User
Moby A. schrieb: > Denkarbeit ... Asm verlangt > für's Ergebnis manchmal etwas mehr Aufwand Jetzt hast du selber ASM mindestens zum Denksport degradiert. Denk dran, du kannst nicht ASM sagen, ohne den Begriff SM zu benutzen...
:
Bearbeitet durch User
Moby A. schrieb: > Sparen an Flash, RAM, MHz, zuweilen Peripherie... In der richtigen Welt ist Hardware nur eine von vielen Resourcen, noch davon eine der günstigeren, und noch dazu mit ständig fallendem Preis. Insgesamt hast du ja recht, das muss man dir lassen. Nämlich für den Fall, dass man mit einer höchstens mässig komplexen Software das absolute Maximum aus einem sehr kleinen Controller herausholen will. Diese Ausgangslage trifft immerhin auf ca. 2% aller Hobbyprojekte und vermutlich mehr als 0.1% der kommerziellen Projekte zu.
Robert L. schrieb: > ASM ist in der THEORIE immer besser In der Praxis durchaus genauso. Sonst würde die Sprache längst nicht mehr verwendet. > ein durchschnittlicher Programmierer, wird es aber nur bis zu einer > gewissen komplexität schaffen, besser zu sein als mit C mit etwas > Aufwand wird er es schaffen diese Grenze nach oben zu verschieben > aber irgendwo ist die Grenze (weiter oben kommt dann nochmal eine, wo > man nicht mehr C sonder z.b. Pascal/c#/java nimmt, aber das wollen wir > jetzt nicht ausarten lassen..) Da hast Du sicher recht. Bei kleinen 8-Bittern würde ich die Grenze aber ziemlich weit oben ansiedeln. > "Argumente" wie "ASM ist einfach" sind natürlich auch recht einfach zu > durchschauen: das ist so wie Schach-Regeln, die kann man auch in 5 > Minuten erklären.. deshalb ist Schach-Spielen noch lange nicht einfach.. Asm ist insofern einfach als daß es nicht vieler Instruktionen und Programmiermittel bedarf. C-Bücher sind da ungleich dicker und warten mit vielen Konstruktionen auf die erstmal sinnvoll genutzt sein wollen wenn sie denn im konkreten Einsatzfall überhaupt simnvoll sind- und in Summe ja trotzdem nicht an das Asm-Ergebnis herankommen. Je umfangreicher die Sache allerdings desto mehr schmilzt der Asm-Vorsprung dahin. Hardwarenahe MSR Apps bis hin zu mittlerer Komplexität auf 8-Bittern sind da aber noch nicht oder nur selten betroffen. > Ich für mich persönlich hab folgende Entscheidung getroffen: > 99% meiner Projekte sind WEIT weg von der Linie, wo ich es es selber im > ASM schreiben könnte... dort verwende ich auch z.b. fertige > "Biliotheken" für 1-wire, crc, 443mhz funk, usw (wo findet man sowas > überhaupt in ASM? fix/fertig?) ...von tcp/ip mit W5100 oder > EncJ-irgnedwas mal ganz abgesehen.. Mach das. Für solche Dinge hat der geübte Asm-Programmierer, sofern benötigt, natürlich "längst fertig". Netzwerkzugriff, TCP/IP sollte man da auslagern- da hab ich persönlich keine Lust zu. > weil ich erstmal ASM so gut lernen müsste So viele Instruktionen sinds ja nicht, das lernst auch Du. Aber Übung macht den Meister- so wie überall! Die Verantwortung für alles hat auch was Gutes: Kein anderer Verantwortlicher für Fehler funkt in die eigene Arbeit.
Moby A. schrieb: > Mach das. Für solche Dinge hat der geübte Asm-Programmierer, sofern > benötigt, natürlich "längst fertig". Netzwerkzugriff, TCP/IP sollte man > da > auslagern- da hab ich persönlich keine Lust zu. Achja? Dort wo richtig Programmierarbeit und Rechenleistung anfällt also dann doch lieber kein Assembler? Ist eigentlich das, was wir dir seit einiger Zeit zu erklären versuchen, aber schön, dass du trotzdem noch selbst drauf kommst. Wenn auch vermutlich eher unbewusst.
Thomas E. schrieb: > Ach komm, das ist doch keine Aussage. Das gilt doch für nahezu alles. > Sowohl Fahrrad fahren als auch Kuchen backen. So eine Antwort wirft doch > nur noch mehr Fragen auf. Klar ist das eine Aussage. Kann aber sein, daß es schon einiger konkreter Erfahrung bedarf, den Nutzen von Können, Vorbereitung und System zu verstehen. Ich kann und brauche hier keinen Asm-Kurs zu geben, möchte aber auf Deine Fragen > Wieviel und welche Vorbereitung? > Was hat das System damit zu tun? > Welche Mühen sind das und wieviel Mühe und Zeit kostet das? soviel antworten: Vorbereitung ist wiederverwendbarer Code. System ist das Programmgrundgerüst mit vorbereitetem Code für Standardaufgaben. Mühe und Zeit sind dann je nach Können recht individuell.
Frank M. schrieb: > Achja... Dein Projekt. Wieviele Interessenten haben Dir mittlerweile ein > Platinchen abgenommen? Siehst Du. Projektferne Rumtrollerei war Dein einziger Beitrag. Wenngleich mit klarer Absicht ;-( > Die schlechte Nachricht ist: Je nach eigenem Können, Vorbereitung und > System ist etwas mehr Mühe und Zeit nötig. > Kannst Du das Wort "etwas" quantifizieren? Je nach eigenem Können, Vorbereitung und System ;-) Das kann weniger, gleich viel oder mehr Mühe sein. In der Regel für den geübten Programmierer und übliche MSR Aufgaben 'etwas' mehr.
Moby A. schrieb: > C-Bücher sind da ungleich dicker und warten > mit vielen Konstruktionen auf die erstmal sinnvoll genutzt sein wollen Aus der Perspektive einet Ameise sieht selbst ein Kuchenkrümel aus wie ein Berg ;-) Nicht böse sein ... jedem hier ist klar dass du diesen Seitenhieb nicht verstehst.
P. M. schrieb: > Moby A. schrieb: > Da wurde gar nichts bewiesen. Asm-Code bleibt die Messlatte für alle > anderen Sprachen. > > Das ist selbst bei Performance-Fragen Quatsch: Ein Assembler-Code ist > nie um Grössenordnungen, sondern höchstens (seltenst) um einige zehn > Prozente schneller. Die Rechenleistung pro Grösse/Preis/Energie > verdoppelt sich bekanntlich ca. alle zwei Jahre. Die Komplexität der Controller steigert sich genauso. Heutige ARMe MCUs sind so nicht mehr sinnvoll in Asm programmierbar. Bei einfachen 8 Bittern (möge es sie noch lange geben und das werden sie auch) gilt das. P. M. schrieb: > Insgesamt hast du ja recht, das muss man dir lassen. Nämlich für den > Fall, dass man mit einer höchstens mässig komplexen Software das > absolute Maximum aus einem sehr kleinen Controller herausholen will. > Diese Ausgangslage trifft immerhin auf ca. 2% aller Hobbyprojekte und > vermutlich mehr als 0.1% der kommerziellen Projekte zu. Die einfachen 8-Bitter zählen zu den (sehr) kleinen Controllern. Damit ist immer noch die Mehrzahl der Hobbyprojekte realisiert- und selbst wenn sie das nicht sind könnten sie es oft, vor allem als Asm-Version. Auch kommerziell spielen 8-Bitter nach wie vor eine bedeutende Rolle. Doch hat C hier aus verschiedensten Gründen die Nase vorn, die, wie man der Studie entnehmen kann, aber nicht in jedem Fall ausschlaggebend sind.
:
Bearbeitet durch User
P. M. schrieb: > Achja? Dort wo richtig Programmierarbeit und Rechenleistung anfällt also > dann doch lieber kein Assembler? Die fällt projektindividuell sonst schon genügend an. Gebratene Tauben fliegen niemand in den Mund. Sagte ich nicht, zur Effizienz gehört, das Rad nicht zweimal zu erfinden? Netzwerksachen, Multimedia, SD Interfaces, Grafik-LCD, all das kann man für MSR Anwendungen (sofern benötigt) locker auslagern. Genau dafür sind mir viele UART Schnittstellen wichtig. Meinen Stolz tangiert das alles nicht. Muß es das?
Moby A. schrieb: > verwende ich auch z.b. fertige >> "Biliotheken" für 1-wire, crc, 443mhz funk, usw (wo findet man sowas >> überhaupt in ASM? fix/fertig?) ...von tcp/ip mit W5100 oder >> EncJ-irgnedwas mal ganz abgesehen.. > > Mach das. Für solche Dinge hat der geübte Asm-Programmierer, sofern > benötigt, natürlich "längst fertig". ernsthaft jetzt? 1-wire schreibst du dir selber? abhören eine 433MHZ-Temp/Feuchte senders auch? oder ist mit "geübte Asm-Programmierer," jemand anderer gemeint;-) und ja ich kenn die Antwort schon: DU brauchst es nicht, aber WENN , dann würdes es in ASM schreiben.. ich hingegen verwende es einfach, mir ist es SCH.. egal wie 1-wire funktioniert, welches Protokoll es hat usw. da haben sich schon ein paar andere darüber den Kopf zerbrochen (denen ich sehr dankbar bin, und denen ich auch gerne mal einen Bug melde) (das ist jetzt nur ein beispiel von vielen..) und man ist NICHT darauf "angewiesen" was die verbrechen, sondern ganz im gegenteil ist der C-Code viel verständlicher/änderbarer, als ein ASM-Listing was in jeder 2. Zeile irgend einen unkommentierten "Trick" verwendet um 2 takte zu sparen.. (zu deinem tcp/ip auf xport auslagern sag ich nichts, damit hast dich ja sowieso disqualifiziert...)
:
Bearbeitet durch User
Robert L. schrieb: > als ein > ASM-Listing was in jeder 2. Zeile irgned eine unkommentierten "trick" > verwendet um 2 takte zu sparen.. Das kannst du ihm nicht vorhalten. Wenn du dir den Code von "seinem Projekt" ansiehst, wirst du sehen, dass solche Tricks da gar nicht drin sind. Sowas machen nur Compiler. mfg.
Robert L. schrieb: > 1-wire schreibst du dir selber? > abhören eine 433MHZ-Temp/Feuchte senders auch? 1-wire noch nicht, aber I2C, SPI, UART und analoge Schnittstellen haben bislang noch jedes Mal gelangt > mir ist es SCH.. egal wie 1-wire > funktioniert, Mir auch ;-) Schnittstellen zu verstehen kann aber (auch Dir) nicht schaden- da holt man ggf. mehr und genau das raus was man selber braucht und keine Library in dieser Form bietet > zu deinem tcp/ip auf xport auslagern sag ich nichts, damit hast dich ja > sowieso disqualifiziert Du Dich mit dieser Bemerkung auch. Frag mal bei Lantronix nach warum sie das Ding produzieren ;-)
Thomas E. schrieb: > Sowas machen nur Compiler. Auf ein besseres Compiler-Ergebnis warte ich nach wie vor ;-)
Moby A. schrieb: > Auf ein besseres Compiler-Ergebnis warte ich nach wie vor Das Programm in C hast du gefälligst selbst zu liefern, um zu beweisen, dass dein Code soviel effizienter ist. Seit wann kommt der Knochen zum Hund? mfg.
Thomas E. schrieb: > Das Programm in C hast du gefälligst selbst zu liefern, um zu beweisen, Ha ha... Das ist ja jetzt mal witzig. Meine These ist ja gerade: Unmöglich, es in C ressourcensparender hinzubekommen. Und das schon bei so einem Winzig-Progrämmchen... Was da erst in größeren für Potentiale stecken müssen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Sparen an Flash, RAM, MHz, zuweilen Peripherie... > Motivation ist natürlich nicht der Kauf von etwas was man nicht nutzt > sondern maximale Nutzung dessen was man (eine Nummer kleiner) gekauft > hat. Mit ein paar Reserven für die Zukunft, versteht sich! Aber nur, wenn der Programmierbimbo nix kostet, der das alles macht... Aber besehen wir die Sache doch mal von der anderen Seite: Wozu eigentlich ein Assembler? Das ist doch was für Weicheier: In den 1970ern kannten die richtig harten Jungs die Maschinencodes auswendig und haben die Programme mit dem Hex-Editor ins RAM geklopft. Ich kannte einen, er hielt in der Rechten die Zigarette und haute mit dem linken Mittelfinger seine Hexcodes in den Speicher. Programmkorrekturen - die waren zuweilen auch nötig - wurden per Rucksack in den Code rein gekloppt. Das geht also auch und nun kommst du Waschlappen daher und behauptest, der ASM sei das einzig Wahre. Der Typ mit dem Mittelfinger hätte sich schief gelacht ud gleichzeitig weiter programmiert... Wie willst du diese immense Resourcenverschleuderung, die ein Assembler darstellt rechtfertigen?
> Und das schon bei > so einem Winzig-Progrämmchen... Was da erst in größeren für Potentiale > stecken müssen ;-) Andersrum ;-) Die Effizienz eines ASM-Programms verhält sich praktisch umgekehrt proportional zur Code-Größe. Das ist auch der Grund, warum ASM in der Regel nicht verwendet wird, wenn die Komplexität und Codegröße ein gewisses Maß übersteigt.
Uhu U. schrieb: > Aber besehen wir die Sache doch mal von der anderen Seite... Wen nochmal wolltest Du damit nun beeindrucken? Ich hoffe Du nimmst das nicht selber ernst...
Jonny O. schrieb: > Und das schon bei so einem Winzig-Progrämmchen... Was da erst in > größeren für Potentiale stecken müssen ;-) > > Andersrum ;-) Nö. Die Potentiale sind in jedem Fall da. Und bis zu einer gewissen Projektgröße lohnt es sich, diese mit Asm auszuschöpfen. So wird ein Schuh draus.
> Nö. Die Potentiale sind in jedem Fall da. > Und bis zu einer gewissen Projektgröße lohnt es sich, diese mit Asm > auszuschöpfen. So wird ein Schuh draus. Ab welcher Codegröße / Komplexität lohnt es sich denn nicht mehr ASM einzusetzen?
> Meine These ist ja gerade: > Unmöglich, es in C ressourcensparender hinzubekommen. Und das schon > bei so einem Winzig-Progrämmchen... Was da erst in größeren für > Potentiale stecken müssen ;-) Ein echter Logiker vor dem Herrn. Wenn also das Programm beliebig klein ist, z.B. nur 1 Befehl, RJMP $-2, dann kann es in C nicht kürzer werden. Mit dem Verfahren kann man auch die völlige Sinnlosigkeit von Vektor-Prozessoren beweisen, denn die sind ja schon beim Berechnen von einer Operation nicht schneller als die "Normalen". Es bestreitet ja keiner, daß ein C-Programm, ich verwende mal kaufmännische Begriffe, Fixkosten > 0 hat. Nur sind die variablen Kosten von ASM größer, z.B. in einfachsten Fall, weil man für eine Integer-Addition mehr Zeilen schreiben muß. Und sobald man den Break-Even-Punkt erreicht hat, gewinnt C. Über die Lage dieses Punktes kann man sicher streiten, über seine Existenz nicht. > Netzwerksachen, Multimedia, SD Interfaces, Grafik-LCD, all das kann > man für MSR Anwendungen (sofern benötigt) locker auslagern. Genau > dafür sind mir viele UART Schnittstellen wichtig. Hurra, wenn ich eine kleine Temperatur-Meßbox bauen will, dann muß ich nur einen 1-Wire-Prozessor mit serieller Schnittstelle und einen SE-Card-Rozesser mit serieller Schnittstelle an einen Mega664 hängen (oder gibt's kleinere mit 2xUART?) und kann dann mit wenigen ASM-Zeilen meinen Temperatur-Logger bauen. Resourcenarm, sogar die mir wichtigste Resource, meine Lebenszeit wird nicht durch das Inkludieren von PeDa-/Fleury-Libs verschwendet. Endlich hab ich das Licht gesehen!
Jonny O. schrieb: > Ab welcher Codegröße / Komplexität lohnt es sich denn nicht mehr ASM > einzusetzen? Für Moby >20 Zeilen. Falls EOR drin vorkommt auch mal weniger ROFL
Moby A. schrieb: > Wen nochmal wolltest Du damit nun beeindrucken? > Ich hoffe Du nimmst das nicht selber ernst... Doch doch, das nehme ich sehr ernst und wenn in deiner bisherigen Pro-ASM-Argumentation nur ein Fünkchen Wahrheit steckt, dann wirst du jetzt einen hex-Editor bauen, den Assembler fortschmeißen und resourcensparend Maschinencode programmieren. Da du das aber offensichtlich nicht willst, versuchst du mit diesem billigen Trick deine Argumentationsschwäche zu vertuschen... In Wirklichkeit nimmst du dein ASM-ist-das-Beste-Geschwätz selbst nicht ernst.
:
Bearbeitet durch User
Wegstaben V. schrieb im Beitrag #4354426: > Man kann Moby's ASM-Fundalismus nicht mit rationalen Argumenten > begegnen. Da könntest Du Recht haben. Aber nicht wegen "Fundalismus" ;-) > Karl Heinz B. schrieb: > Du bist wie ein sturer Esel. Ich schätze Freundlichkeit, Hilfsbereitschaft und Kompetenz von Karl-Heinz sehr. Deswegen darf ihm auch mal sowas durchrutschen ;-)
Moby A. schrieb: > So viele Instruktionen sinds ja nicht, das lernst auch Du. C hat noch weniger Instruktionen, ist eben was für Weicheier und nichts für harte Byte-Cowboys wie dich. Moby A. schrieb: > Unmöglich, es in C ressourcensparender hinzubekommen. Für dich unmöglich, es in C überhaupt hinzubekommen. Ist eben eine andere Welt.
Moby A. schrieb: > Ha ha... Das ist ja jetzt mal witzig. Meine These ist ja gerade: > Unmöglich, es in C ressourcensparender hinzubekommen. Was ist denn daran witzig? Genau das sollst du beweisen, indem du ein C-Programm lieferst, dass größer, langsamer und was weiss ich noch alles ist. Wir werden das dann noch ein bisschen optimieren. Oder glaubst du wirklich, dass einer dein Assembler-Programm auseinanderdröselt, um daraus ein C-Programm zu machen? mfg.
Uhu U. schrieb: > resourcensparend Mach Dir bitte nochmal klar was mit "ressourcensparend" gemeint war. Tipp: Weiter oben hat ichs schonmal erklärt.
Thomas E. schrieb: > Oder glaubst du wirklich, dass einer dein Assembler-Programm > auseinanderdröselt, um daraus ein C-Programm zu machen? Nein. Das vorgegebene Ziel ist schlicht nicht erreichbar. Umso spektakulärer "argumentieren" hier auch manche große Experten ;-)
Moby A. schrieb: > Das vorgegebene Ziel ist schlicht nicht erreichbar Traust du dich nicht, deine Behauptung zu beweisen? Oder gibst du jetzt zu, dass alles, was du du von dir gibst, nur hohles Dummgeschwätz ist? mfg.
:
Bearbeitet durch User
Witkatz :. schrieb: > Für dich unmöglich, es in C überhaupt hinzubekommen. Das muß ich auch nicht wenns in Asm effizienter geht.
Thomas E. schrieb: > hohles Dummgeschwätz ist ... die Behauptung C könnte es besser. Beweise es doch. Aber Du kannst es nicht... Wolltest Du davon ablenken?
Moby A. schrieb: > ... die Behauptung C könnte es besser. Wo behaupte ich, dass C das besser kann? Du behauptest, dass du es in Assembler besser kannst. Also beweise es! mfg.
Warum diskutiert ihr mir diesem Kleingeist? Er will Trollen, nicht lernen!
Moby A. schrieb: > Mach Dir bitte nochmal klar was mit "ressourcensparend" gemeint war. > Tipp: Weiter oben hat ichs schonmal erklärt. Vermutlich meinst du diese "Erklärung": Moby A. schrieb: > Tatsächlich aber verhelfen die vielen Freiheiten des Asm-Programmierens > nicht nur zu effizientem, hochdichten Code ,sondern verleiten zuweilen > auch mit diesem und jenen Trick (z.B. bei Vielfachnutzung derselben > Ressourcen) zu einem unübersichtlichen Programm. Wer sagt, dass man mit Maschinencode im Hex-Format nicht auch "zu einem unübersichtlichen Programm" kommen kann? Und resourcensparender als so ein völlig unnützer Assembler ist es allemal, denn der Programmierbimbo kostet ja nix, während Speicherplatz, Rechenkapazität und Strom doch ziemlich teuer sind. Deine Einsilbigkeit ist verräterisch... Also nochmal die Frage: Wozu eigentlich ein Assembler? wenn es ein Hexeditor auch tut.
:
Bearbeitet durch User
> Wozu eigentlich ein Assembler? > wenn es ein Hexeditor auch tut. Weil dann nicht nur EOR ins Reich der Nebel verschwindet ...
Moby A. schrieb: > Witkatz :. schrieb: >> Für dich unmöglich, es in C überhaupt hinzubekommen. > > Das muß ich auch nicht wenns in Asm effizienter geht. Jaja und bitte an dem Glauben immer schön festhalten.
Thomas E. schrieb: > Du behauptest, dass du es in Assembler besser kannst. Also beweise es! Mit meinem Projektchen ist das schon geschehen... Nun beweise die Behauptung, das bischen Funktionalität mit den ach so effizienten Compilern, die jedem Asm-Programmierer was vormachen im Ressourcenverbrauch zu schlagen! Beachte bitte: Meine Asm-Fähigkeiten würde ich eher durchschnittlich nennen... Was? Dir erschließt sich diese Logik der Beweispflicht nicht? Sorry, dann kann ich Dir von dieser Stelle aus nicht mehr weiterhelfen ;-( Witkatz :. schrieb: > Jaja und bitte an dem Glauben immer schön festhalten. Da verwechselst Du was. Bislang ist es immer noch Wissen ;-)
Uhu U. schrieb: > Deine Einsilbigkeit ist verräterisch... So recht magst Du nicht zur Kenntnis nehmen welche Ressourcen Asm spart. Stimmts? Aber ich verstehe Dich. Auf diesem Feld ist gerade kein Blumentopf zu gewinnen ;-)
Moby A. schrieb: > Mit meinem Projektchen ist das schon geschehen... Nein. Du stellst hier eine Behauptung auf und bist nicht bereit, diese auch zu beweisen. Sondern zeigst hier ein Programm, von dem man nicht einmal weiss, ob es überhaupt funktioniert. Die Funktionalität dieses Progrämmchens in C oder wenigstens in Pseudo-Code darzustellen, kann doch nicht so schwer sein. Moby A. schrieb: > Beachte bitte: Meine Asm-Fähigkeiten würde ich eher durchschnittlich > nennen... Was willst du denn damit sagen? Falls es jemandem gelänge, ein C-Programm zu schreiben, dass in allen Belangen besser ist als dein Assembler-Programm, liegt es nicht an Assembler an sich, sondern nur an deinen bescheidenen Fähigkeiten? Und jemand, der mehr auf dem Kasten hätte als du, würde es sicher hinbekommen? mfg.
:
Bearbeitet durch User
Carl D. schrieb: > Wenn also das Programm beliebig klein ist, z.B. nur 1 Befehl, RJMP $-2, > dann kann es in C nicht kürzer werden. Richtig. Deshalb steckt in diesem Fall das geringste Potential der Verbesserungsmöglichkeiten durch Asm, nämlich Null. Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der Asm-Programmierer dieses Potential ob der schieren Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig die Stunde der Hochsprache. Hast Du das jetzt verstanden? > Endlich hab ich das Licht gesehen! Ich gebe die Hoffnung nicht auf ;-)
Thomas E. schrieb: > Moby A. schrieb: >> Beachte bitte: Meine Asm-Fähigkeiten würde ich eher durchschnittlich >> nennen... > Was willst du denn damit sagen? > Falls es jemandem gelänge, ein C-Programm zu schreiben, dass in allen > Belangen besser ist als dein Assembler-Programm, liegt es nicht an > Assembler an sich, sondern nur an deinen bescheidenen Fähigkeiten? Und > jemand, der mehr auf dem Kasten hätte als du, würde es sicher > hinbekommen? Damit will ich nur sagen, daß die Chancen doch gut stehen sollten, meine durchschnittlichen Assemblerfähigkeiten mit hocheffizientem Compilercode zu schlagen. Gelingt das werde ich hier Assembler nicht mehr als ernstzunehmende C-Konkurrenz hinstellen. Was natürlich nicht ausschließt daß wiederum ein anderer besserer ASMler daherkommt und dies mit Nachweis wieder behauptet ;-)
:
Bearbeitet durch User
Damit eine gute Nacht und vielen Dank an alle Mit-Diskutanten, vom redlich konstruktiven, unpolemischen Peter D. bis hin zum komplett gegenteiligen Gu.F(orentroll). Am Wochenende werde ich dann wieder etwas Zeit finden, die Vorteile und Annehmlichkeiten von Asm mit Euch zu diskutieren. Moby
:
Bearbeitet durch User
Moby A. schrieb: > Auf diesem Feld ist gerade kein Blumentopf zu gewinnen ;-) Deswegen meidest du die Antwort auf meine Frage: Wozu eigentlich ein Assembler? wenn es ein Hexeditor auch tut. wie der Teufel das Weihwasser...
Thomas E. schrieb: > Die Funktionalität dieses Progrämmchens in C oder wenigstens in > Pseudo-Code darzustellen, kann doch nicht so schwer sein. Alles, was man nicht kann, ist schwer...
Moby A. schrieb: > Carl D. schrieb: >> Wenn also das Programm beliebig klein ist, z.B. nur 1 Befehl, RJMP $-2, >> dann kann es in C nicht kürzer werden. > > Richtig. Deshalb steckt in diesem Fall das geringste Potential der > Verbesserungsmöglichkeiten durch Asm, nämlich Null. Oh, da bist du aber einem gewaltigen Irrtum aufgesessen. Natürlich bringt ASM in dem Fall einen, wenn auch kleinen Vorteil gegenüber dem C-Compiler, verschwendet dabei aber zur Übersetzungszeit wieder wahnsinnige Mengen an kostbaren Resourcen. Der Hex-Editor machts noch viel billiger: man braucht keinen Assembler und folglich auch keinen Rechner, auf dem er läuft und er spart den ganzen Speicheroverhead, den das C-Programm
1 | void main(void) { |
2 | loop: goto loop; |
3 | }
|
braucht. Ergo: Du hast keine Ahnung wovon dur hier rumschwadronierst...
Uhu U. schrieb: > void main(void) { > loop: goto loop; > } Das sollte man ausdrucken und dir um die Ohren hauen. mfg.
Robert L. schrieb: > ich hingegen verwende es einfach, mir ist es SCH.. egal wie 1-wire > funktioniert, welches Protokoll es hat usw. da haben sich schon ein paar > andere darüber den Kopf zerbrochen (denen ich sehr dankbar bin, und > denen ich auch gerne mal einen Bug melde) (das ist jetzt nur ein > beispiel von vielen..) Oh, kommt jetzt die Arduino-Fraktion auch noch in den Thread? ;-)
Moby A. schrieb: > Uhu U. schrieb: >> Was ist denn die "sinnvollste Lösung"? > > Die einfachste und Ressourcen-sparendste. Ist die Lebenszeit des Programmierers keine Ressource? Mir scheint dies die wertvollste Ressource überhaupt zu sein.
Uhu U. schrieb: > Wieso das denn? Weil "goto" absolut verpönt ist. Aber wenn es unbedingt sein muss, dann:
1 | comefrom: goto comefrom; |
Ausserdem heisst es
1 | int main(void) |
mfg.
Thomas E. schrieb: > Weil "goto" absolut verpönt ist. Ach du lieber Himmel... Das erzählt man den kleinen Buben, um sie zu disziplinieren. Was glaubst du wohl, warum Dennis Ritchie in den frühen 1970ern das goto in C eingebaut und keiner es seither wieder entfernt hat? Nicht um irgend welche Deppen zu verführen, Unsinn damit zu machen, sondern weil es Fälle gibt, in denen es von Nutzen ist und der Klarheit des Programmablaufs dient. > Aber wenn es unbedingt sein muss, dann: > comefrom: goto comefrom; Was soll das denn? > Ausserdem heisst es int main(void) Nö, das heißt int main(int argc, char *argv[]) aber C ist da tolerant und du musst noch viel, viel lernen...
Hier wurde bereits bewiesen, dass C sogar speicherplatzsparender als Mobys Assembler sein kann: Beitrag "Re: C versus Assembler->Performance" Zusätzlich zitiere ich aus dem dort verlinkten Thread: Moby AVR schrieb: > Hans schrieb: >> Wenn du nur 1:1 "übersetztst", dann wird C niemal kleiner als dein ASM >> code werden. > Kleiner? Wie soll denn das passieren? Da muss sich ein Asm-Programmierer > aber schon selten dämlich anstellen :-) Hier zu lesen: Beitrag "Re: C versus Assembler->Performance" Die jetzige "Diskussion" ist damit hinfällig und Moby darf uns nun endlich zeigen, wie man das kleine Progrämmchen mit handoptimiertem Assembler ressourcensparender niederschreiben kann. Uhu U. schrieb: > Nö, das heißt int main(int argc, char *argv[]) Oder eben auch
1 | int main(void){ /* ... */ } |
Dies sind die beiden Varianten, die im Standard definiert sind.
Edit: "or in some other implementation-defined manner."
> aber C ist da tolerant
Wenn, dann ist der Compiler tolerant.
:
Bearbeitet durch User
Moby A. schrieb: > Mit meinem Projektchen Hey, du erkennst also das dein Projektchen ein Projektchen ist :-) Moby A. schrieb: > Meine Asm-Fähigkeiten > würde ich eher durchschnittlich nennen... Ich würde das eher unterdurchschnittlich nennen (--> Micky Maus). Moby A. schrieb: > Sorry, > dann kann ich Dir von dieser Stelle aus nicht mehr weiterhelfen ;-( Dir ist schon lange nicht mehr zu helfen.
Guido B. schrieb: > Robert L. schrieb: >> ich hingegen verwende es einfach, mir ist es SCH.. egal wie 1-wire >> funktioniert, welches Protokoll es hat usw. da haben sich schon ein paar >> andere darüber den Kopf zerbrochen (denen ich sehr dankbar bin, und >> denen ich auch gerne mal einen Bug melde) (das ist jetzt nur ein >> beispiel von vielen..) > > Oh, kommt jetzt die Arduino-Fraktion auch noch in den Thread? ;-) ja, mir geht es eben ums Ergebnis, nicht um den Weg dort hin ;-) normalerweise, wobei ich gestern eclipse+stm32 (mit qemu und auch mit einem st-link + kaum 2€stück großem echtem board) ausprobiert hab.. einfach aus Spaß: wenn man seine Sachen dann auch debuggen kann,ist schon was feines... das Ding hat ja soviel "Moby-Resource" (aka Flash) dass man garnicht weiß was man alles tun soll damit... und ist um welten kleier als alles was man (ich) selber herstellen könnte... wenn ich es könnte.. auch qemu find ich genial, kann man an avr auch simulieren?? ;-) stellt sich echt die frage warum man noch mit 8-bit herumeiert ;-)
:
Bearbeitet durch User
Gu. F. schrieb: > Moby A. schrieb: >> Sorry, >> dann kann ich Dir von dieser Stelle aus nicht mehr weiterhelfen ;-( > Dir ist schon lange nicht mehr zu helfen. Man kann von seiner Meinung halten was man möchte: aber Moby bleibt bei seinen Ausführungen immer höflich. Das sollte auch für die Mitdiskutanten gelten. Das hier ist auch "sein" Thread, also kann er hier auch seine Thesen vertreten wie er möchte. Wir Mods haben nur etwas degegen, wenn er mit seiner Asm/AVR-Affinität andere Threads kapert. Man muss bei allen Meinungsverschiedenheiten auch bedenken, dass Moby das als Hobby betreibt, während die meisten hier wohl auch beruflich coden. Beruflich stellt sich die Frage ASM/Hochsprache kaum noch, weil Arbeitszeit und Portabilität erheblich kostbarer als Speicherplatz sind, wenn man damit Geld verdienen muss. Ich habe ja früher durchaus auch mit reinem Assembler gearbeitet (8048, eigenes BIOS für einen 80286-PC, Bordcomputer mit einem AVR 8535), allerdings war bei etwa 4-8k Codegröße dann Schluß und ich bin auf C umgestiegen. Bei den Projektgrößen und den Anforderungen, wie sie jetzt bei uns vorherrschen, wäre Programmierung in Assembler einfach undenkbar. Moby A. schrieb: > Richtig. Deshalb steckt in diesem Fall das geringste Potential der > Verbesserungsmöglichkeiten durch Asm, nämlich Null. > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der > Asm-Programmierer dieses Potential ob der schieren > Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig > die Stunde der Hochsprache. Und da hat Moby einfach mal Recht. Je mehr Code man hat, desto eher steigen für den Assembler-Programmierer die Chancen, Optimierungsmöglichkeiten zu übersehen. Ein Compiler tut das nicht. Der verliert auch nicht den Überblick. Schaut man sich schon bei kleinen Programmen (4k) an, wo ein Compiler Dinge findet, die er doppelt nutzen kann, dann ist das schon faszinierend (und teilweise unfassbar). Da muss man einfach den Hut vor den Compilerjungs ziehen. Ich würde also aus der Praxis heraus behaupten, dass ab einer gewissen Codegröße der Compiler den Assemblerprogrammierer auch recht locker in der Codegröße schlägt. Ich bin allerdings auch der Meinung, dass es für einen angehenden Programmierer gut ist, wenn er ein paar kleine Projekte in Assembler schreibt. Das hilft dabei, später effizienten Code in C zu schreiben und auch Fehler schneller zu lokalisieren, weil man zumindest erahnen kann, was auf Prozessorebene geschieht.
Uhu U. schrieb: > Nicht um irgend welche Deppen zu verführen, Unsinn damit zu machen, > sondern weil es Fälle gibt, in denen es von Nutzen ist und der Klarheit > des Programmablaufs dient. goto ist die Mutter allen Spaghetticodes. mfg.
Thomas E. schrieb: > goto ist die Mutter allen Spaghetticodes. wie wir wissen, braucht es aber auch noch nen Vater, der mit der Mutter schmutzige Sachen anstellt. So ganz allein, ist die Mutter anständig und kann nützlich sein ;)
Thomas E. schrieb: > Uhu U. schrieb: >> Nicht um irgend welche Deppen zu verführen, Unsinn damit zu machen, >> sondern weil es Fälle gibt, in denen es von Nutzen ist und der Klarheit >> des Programmablaufs dient. > > goto ist die Mutter allen Spaghetticodes. Ich selbst habe in den letzten 30 Jahren C-Programmierung niemals ein goto gebraucht, trotzdem würde ich das nicht so allgemein formulieren. Es gibt durchaus in speziellen Situationen Gründe, ein goto zu verwenden. Zum Beispiel im Linux-Kernel, um von einem Ausnahmezustand einen wohldefinierten "Normalzustand" wieder zu erreichen. Trotzdem würde ich niemals behaupten, dass der Linux-Kernel-Code Spaghetticode wäre.
Frank M. schrieb: > Trotzdem würde ich niemals behaupten, dass der Linux-Kernel-Code > Spaghetticode wäre. Ausnahmen bestätigen die Regel. Aber jetzt lasst uns diesen Thread nicht kapern. Das ist ein ASM-Thread von Moby. Er bekommt auch was auf den Deckel, wenn er in anderen Threads seine ASM-Ansichten verbreitet. mfg.
Chris D. schrieb: > Ich würde also aus der Praxis heraus behaupten, dass ab einer gewissen > Codegröße der Compiler den Assemblerprogrammierer auch recht locker in > der Codegröße schlägt. Das sehe ich absolut genauso. Das Problem ist aber, dass Moby diese kritische Codegrenze noch nie erreicht hat - da er eher kleinere Progrämmchen schreibt. Leider verallgemeinert er aber dermaßen seinen erreichten Zustand, dass es so rüberkommt, als wäre Assembler generell das Mittel der Wahl und alles größer als ATTiny Teufelswerk, was man nicht braucht. Kurzum: Er schließt von seinem Mikrokosmos auf sämtliche µC-Anwendungen, prahlt damit ziemlich großkotzig rum und degradiert jeden C-Programmierer zu einem nichtsnutzigen Wesen, was die Welt nicht braucht. P.S. Deine Meinung, Moby bliebe bei seinen Ausführungen immer höflich, kann ich leider nicht teilen. Er wird zwar nicht verbal ausfallend, jedoch macht er das subtiler. Zum Beispiel hat er Karl Heinz (buchegg) ziemlich kaltschnäuzig (d.h. respektlos) gegen die Wand fahren lassen, so dass ich zum ersten Mal erleben konnte, wie Karl Heinz die Hutschnur platzte. Das kommt nicht von ungefähr. Respekt zeigen ist nicht gerade Mobys Stärke. Die provozierend gesetzten zwinkernden Smileys, die er bei Widerspruch bewusst platziert, führen dazu, dass seine davor platzierte Meinung ziemlich herablassend und schon gar nicht höflich rüberkommt. Fazit: Moby hats drauf, bewusst zu provozieren. Das macht er aber nicht offen, sondern sehr verdeckt.
:
Bearbeitet durch Moderator
Thomas E. schrieb: > goto ist die Mutter allen Spaghetticodes. In der Hand von Stümpern mag das stimmen. Profis wissen, wozu es gut ist und wozu nicht - mit einem Messer kann man auch nicht nur Schlimmes anstellen... Ein Beispiel ist das Verlassen einer inneren Schleife. Man kann die ganze geschachtelte Schleife als Funktion ausführen und mit return in einer inneren herausspringen, oder man lässt die Funktion weg und springt sauber hinter das Ende der äußeren Schleife. Ansonsten gibt es wenig strukturerhaltende Anwendungen für goto. Dogmen sind mit Informatik jedenfalls nicht kompatibel...
Frank M. schrieb: > Deine Meinung, Moby bliebe bei seinen Ausführungen immer höflich, kann > ich leider nicht teilen. Einmal in die Enge getrieben, schlägt er wild um sich. Siehe ganz oben auf dieser Seite, wo er mich des „Märchenerzählers“ bezichtigt, um kurz danach selbst zu behaupten, die Peripherals eines Xmega seien eigentlich die gleichen wie bei einem MegaAVR, nur „die paar Steuerbits anders verteilt“. Argumente akzeptiert er nur, wenn sie in sein Weltbild passen, alles andere wird entweder ignoriert oder verdreht oder es wird eben einfach mal behauptet, das sei jetzt gar nicht so. Aber es ist korrekt, verbal ausfallend wird er nicht. Dann würde ja auch riskieren, dass die entsprechenden Beiträge gelöscht werden.
be s. schrieb: > Uhu U. schrieb: >> Nö, das heißt int main(int argc, char *argv[]) > Oder eben auch > int main(void){ /* ... */ } > Dies sind die beiden Varianten, die im Standard definiert sind. > Edit: "or in some other implementation-defined manner." Gilt nur im Hosted Environment. Sonst: > In a freestanding environment (in which C program execution may take > place without any benefit of an operating system), the name and type > of the function called at program startup are implementation-defined. Und unabhängig vom Ergebnis-Typ von main(): praktisch jeder Embedded-Compiler kann mit den passenden Optionen den Startup-Code auf wenige Bytes eindampfen, wenn man die entsprechenden Features nicht braucht. Der Unterschied ist halt, dass man in Assembler gleich bei Null anfängt und nichts mehr explizit zu entfernen braucht.
Jörg W. schrieb: > Aber es ist korrekt, verbal ausfallend wird er nicht. Dann würde ja > auch riskieren, dass die entsprechenden Beiträge gelöscht werden. Naja, der andere wohlbekannte Asm-Apologet, der hier als Gast nicht mitdiskutieren darf, ist, was die verbalen Ausfälle angeht, genau das Gegenteil von dem. Und die werden auch nur in Ausnahmefällen gelöscht. Im Gegensatz zu Moby, weiss der aber auch genau, wovon er redet. mfg.
Thomas E. schrieb: > goto ist die Mutter allen Spaghetticodes. ... und in Assembler kaum wegzudenken: Alle BRxx-Varianten, alle JMP-Varianten ...
Moby A. schrieb: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt Das ist schlicht und einfach extremer Unsinn. Ab einer gewissen Grösse hat der Mensch unmöglich den Überblick, um weitgreifend zu optimieren. Der Compiler hingegen kann das. Deine hochgelobte Optimierung auf Assembler-Ebene ist nämlich nicht etwa eine hohe Kunst, wie du es zu verkaufen versuchst, sondern letztlich relativ stupides Handwerk. Passt aber zum Horizont mit Radius null, den du hier zeigst.
Um es zusammenzufassen: Wir haben dir schon lange zugestimmt, dass man mit Assembler auf sehr kleinen Mikrocontrollern bei kleinen Projekten mit wenig Zusatzaufwand etwas besser sein kann als mit C. Das ist dein Anwendungsfall. Du versuchst aber bei jeder Gelegenheit, diese Aussage auch für grössere Projekte zu verallgemeinern, was Quatsch ist. Wenn man diesen Standpunkt dann angreift, dann argumentierst du wiederum mit den Miniprojekten. Dort stimmen wir dir ja wie gesagt zu. Aber nicht bei grösseren Projekten, wofür du auch nie Argumente bringst, sondern eben immer auf die Miniprojekte ausweichst.
Chris D. schrieb: > Moby A. schrieb: >> Richtig. Deshalb steckt in diesem Fall das geringste Potential der >> Verbesserungsmöglichkeiten durch Asm, nämlich Null. >> Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das >> Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße >> übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der >> Asm-Programmierer dieses Potential ob der schieren >> Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig >> die Stunde der Hochsprache. > > Und da hat Moby einfach mal Recht. > > Je mehr Code man hat, desto eher steigen für den Assembler-Programmierer > die Chancen, Optimierungsmöglichkeiten zu übersehen. Ein Compiler tut > das nicht. Der verliert auch nicht den Überblick. Schaut man sich schon > bei kleinen Programmen (4k) an, wo ein Compiler Dinge findet, die er > doppelt nutzen kann, dann ist das schon faszinierend (und teilweise > unfassbar). Da muss man einfach den Hut vor den Compilerjungs ziehen. Es ist doch so, dass auf der einen Seite Moby ständig den Vergleich zwischen Assembler und C für irgendwelche Miniprogramme sucht. Auf der anderen Seite sagen die C-Verfechter, dass C seine Vorteile erst ab einer gewissen Codegröße ausspielt. Ich sehe da eigentlich gar keinen Konflikt. Auch Moby ist ja nach eigenen Worten der Ansicht, dass für größere Programme Hochsprachen durchaus von Vorteil sind, und bei Dingen wie dem TCP/IP-Stack geht er sogar noch einen Schritt weiter und kauft sich dafür für fast den 100fachen Preis eines ATtiy13 gleich ein komplettes Hardwaremodul. Die Frage (an der sich wohl hauptsächlich der Streit entzündet) ist nur: Jonny O. schrieb: > Ab welcher Codegröße / Komplexität lohnt es sich denn nicht mehr ASM > einzusetzen? Mobys Antwort darauf könnte die längst festgefahrene Diskussion evtl. wieder etwas weiterbringen: Nennt er als Grenze bspw. 200 Byte, würde ich (und wahrscheinlich viele andere auch) das sofort akzeptieren und die Diskussion als abgeschlossen betrachten. Mein längstes Programm in AVR-Assembler war etwa 512 Byte groß (ein halbvoller ATtiny15), und für dessen Entwicklung brauchte ich einschließlich Fehlersuche und nachträglicher Ergänzungen etwa 2 Stunden. Den größte Anteil daran hatte nicht das Programmieren selber, sondern das Nachschlagen im Datenblatt nach der Verwendung von ADC, Timer, EEPROM usw. auf dem ATtiny15, den ich vorher noch nicht im Einsatz hatte. Unter diesem Gesichtspunkt wäre ich in C auch nicht arg viel schneller gewesen, so dass die 2 Stunden für mich akzeptabel sind. Ich hatte also bei 512 Byte Codegröße durch die Assemblerprogrammierung kaum Nachteile (allerdings auch keine Vorteile). Nennt Moby hingegen einen deutlich höheren Wert, bspw. 4 KiByte, würden diesen die meisten C-Programmierer (mich eingeschlossen) als zu hoch ansehen. Um zu zeigen, dass diese Grenze dennoch richtig ist, müsste Moby in der Lage sein, in der gleichen Entwicklungszeit und mit gleicher Speicher- und Laufzeiteffizienz ein 4-KiByte-Assemblerprogramm zu schreiben wie ein C-Programmierer ein entsprechendes C-Programm. Und da habe ich so meine Zweifel, ob er das schafft. Einen in diese Richtung abzielenden "Wettbewerb", den ihm Karl Heinz Buchegger in einem anderen Thread anbot, hat er jedenfalls abgelehnt.
Xalu X.: > Auch Moby ist ja nach eigenen Worten der Ansicht, dass für größere Programme > Hochsprachen durchaus von Vorteil sind wirklich? Moby: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt. Das ist das, auf dem er immer rum kaut. Es gibt zwei Möglichkeiten: entweder will er uns alle verarschen, dann macht er das wirklich gut, oder er ist genau so wie er sich gibt. Ich habe mir angewöhnt jemandem, der sich doof stellt, zu glauben. Das deckt dann beide Fälle gleichzeitig ab. Chris D.: > Das hier ist auch "sein" Thread, also kann er hier auch seine Thesen > vertreten wie er möchte. Wir Mods haben nur etwas dagegen, wenn er mit > seiner Asm/AVR-Affinität andere Threads kapert. Ersteres muß man zugeben, es ist sein Thread, aber nur wenn er hier Antworten bekommt, bleibt er auch hier. Beim Zweiten kann ich leider nicht zustimmen, denn genau das fehlt, wenn er wieder einen Thread mit C/C++-Themen mit seinem Assembler- Fundamentalismus flutet. Damit hat er sich hier seinen Ruf kreiert.
:
Bearbeitet durch User
Yalu X. schrieb: > Nennt er als Grenze bspw. 200 Byte, würde ich (und wahrscheinlich viele > andere auch) das sofort akzeptieren und die Diskussion als abgeschlossen > betrachten. Bereits hier habe ich Zweifel. Ein so kurzes Programm, das primär aus dem Setzen von Konfigurationsbits besteht, kann selbst ein simpel gestrickter C-Compiler fast 1:1 in Assembler umwandeln. Schwer vorstellbar, wo überhaupt Optimierungspotential herausschauen soll.
Carl D. schrieb: > Beim Zweiten kann ich leider nicht zustimmen Wenn dir das auffällt: Beitrag melden. Mir ist in letzter Zeit kein entsprechender Thread mehr zu Gesicht bekommen, bei dem wir nicht konsequent gelöscht haben, aber wir sehen natürlich auch nicht jeden Thread an.
Carl D. schrieb: > Xalu X.: >> Auch Moby ist ja nach eigenen Worten der Ansicht, dass für größere Programme >> Hochsprachen durchaus von Vorteil sind > > wirklich? Ja, bspw. hier: Moby A. schrieb: > Der Hammer hat seine Berechtigung wie der Schraubenzieher auch. > Problematisch wirds, wenn das eine Werkzeug vorgibt, die Arbeit des > anderen effizienter tun zu können. 'Arbeit' steht dabei für das > Zielgebiet: Asm für einfache MSR, Hochsprache für große, rechen- und > datenintensive Anwendungen. Moby A. schrieb: >> Und bis du bei einem solchen Betriebssystem die Handoptimierung des >> Codes fertig hast ist die dazu empfohlene Strategie aufgrund neuer >> Implementierungs-Architekturen schon 2 Generationen weiter und du kannst >> von vorne anfangen. > > In der Praxis hast Du angesichts dieser Entwicklung recht: Sich auf eine > übergeordnete (Hochsprachen-)Ebene zu begeben scheint geboten. Moby A. schrieb: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der > Asm-Programmierer dieses Potential ob der schieren > Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig > die Stunde der Hochsprache. Allerdings sind diese Programme aus seiner Sicht keine "typischen 8-Bit-Anwendungen" mehr und liegen somit außerhalb seines Horizonts. Aber statt die komplexeren Programmteile in einer Hochsprache zu programmieren oder als Hochsprachenquellcode irgendwo herunterzuladen (was im Falle des TCP/IP-Stack durchaus möglich wäre), kauft er sich für teures Geld lieber ein fertig programmiertes Hardwaremodul (den XPort Pro). P. M. schrieb: > Yalu X. schrieb: >> Nennt er als Grenze bspw. 200 Byte, würde ich (und wahrscheinlich viele >> andere auch) das sofort akzeptieren und die Diskussion als abgeschlossen >> betrachten. > > Bereits hier habe ich Zweifel. Ein so kurzes Programm, das primär aus > dem Setzen von Konfigurationsbits besteht, kann selbst ein simpel > gestrickter C-Compiler fast 1:1 in Assembler umwandeln. Vollkommen richtig. Hinzu kommt allerdings noch der Code für die BSS- und Stack-Initialisierung, der bei solchen Miniprogrammen oft gar nicht erforderlich ist, sich aber trotzdem in der Codegröße niederschlägt. Natürlich stören diese zusätzlichen ca. 20 Byte außer Moby niemanden, da selbst der kleinste AVR deutlich mehr als 200 Byte Flash hat. Mobys Argument, warum dieser Overhead doch stört: Irgendwann möchte man das Miniprogramm vielleicht erweitern, und dann könnten die 20 Byte doch wertvoll sein. Allerdings kratzt der Code in diesem Fall schon etwa 1 KiByte-Grenze des ATtiny13 und ist damit groß genug, dass der C-Compiler mit hoher Wahrscheinlichkeit an anderer Stelle seine Stärken ausspielen kann.
@Xalu: Du gibst aber zu, das in den aufgezählten Moby-Schnipseln sowohl die eine als auch die andere Richtung als die einzig Wahre bezeichnet wird. O-Ton: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender > Programmgröße > übrigens unbegrenzt. Aber irgendwann kommt der Punkt, an dem der > Asm-Programmierer dieses Potential ob der schieren > Programmgröße/komplexität nicht mehr heben kann- dann schlägt Also: - der Vorteil von ASM beginnt bei der ersten Zeile - er wächst mit der Programmgröße - es gibt keine Obergrenze für ASM Alles klar, oder? Ich gebe zu, er kann geschickt Andere manipulieren. Solange man sich einlullen läst.
das nach
>Aber ...
ignorieren wir?
wie ich oben schon mal geschreiben habe..
ist wie mit Schach:
ich kann die Regeln, theoretisch könnte ich also gegen jeden
Schachcomputer gewinnen..
> das nach >>Aber ... > ignorieren wir? Dann hätte ich einfach weggelassen. Wollte ich aber nicht, denn erst am Stück zeigt sich, daß er in 2 aufeinanderfolgende Sätzen von der "unbegrenzten Begrenztheit" schreibt.
PIC10F200: 375B Flash, 16B Ram Ich wäre ja bereit auf ASM zu wechseln, aber der C Compiler weigert sich einfach den Code so aufzublähen das ich das muß. Ich habe auch überhaupt keinen Ergeiz statt 40% freier Recourcen mittels ASM auf 45% zu kommen. Den gleichen Codeschnipsel kann ich fast unverändert auch für AVR, XMEGA, STM8 und diverse PICs verwenden ohne mir nur ein mal die Frage stellen zu müssen wie der entsprechende ASM Befehlssatz aussieht und welche Register mir zur Verfügung stehen. Die 'reine ASM Lehre' habe ich mir das letze mal bei 8085 & 8051 gegeben. Das ging oft garnicht anders um ein definiertes Timing zu bekommen. Ausserdem konnte ich mir die sündhaft teuren und nicht sehr guten C-Kompiler nicht leisten. Das ist aber 25 Jahre her. Für 30Cent bekomme ich heute einen STM8S003 mit 16 MHz, 8KB flash, 1K Ram der vollgestopft ist mit jeder Menge Hardware die exotische Softwareverenkungen unnötig macht. Ist ja toll wenn man so auf ASM abgeht, mir ist das aber zu fixiert auf eine Controller Familie.
Yalu X. schrieb: > Es ist doch so, dass auf der einen Seite Moby ständig den Vergleich > zwischen Assembler und C für irgendwelche Miniprogramme sucht. Auf der > anderen Seite sagen die C-Verfechter, dass C seine Vorteile erst ab > einer gewissen Codegröße ausspielt. > > Ich sehe da eigentlich gar keinen Konflikt. Bis hierhin ist da ja auch kein Konflikt mehr... > Auch Moby ist ja nach eigenen Worten der Ansicht, dass für größere > Programme Hochsprachen durchaus von Vorteil sind, Das ist allerdings eine ganz neue Aussage von ihm. Zuvor hat er etwas ganz anderes behauptet: Hochsprachenentwicklern ginge es nur um Verschleierung, Verkomplizierung und Ressourcenerschwendung, und so ein Compiler würde nur "unzulängliche grobe C-Bausteine" zusammensetzen. Ein paar Zitate dazu: "Weil eine Hochsprache ein Programm quasi aus Fertigbausteinen zusammensetzt und die Aufgabenstellung damit nur unter Verlusten an Platz und Performance gegenüber der feiner an die Gegebenheiten anpassbaren Asm-Programmierung lösen kann." "Ist nur blöd, wenn der Fehler am System liegt- zur eigentlichen zu entwickelnden Programmlogik immer noch zusätzlich die Suche nach dem besten der groben C-Bausteine samt passender Verkettungsausdrücke hinzukommt." "Die optimale Ausnutzung der Hardware ist aber gerade das was den Vorteil von Asm ausmacht [...] alles hat irgendwo seinen Preis. Der bedeutet im Fall der (bequemeren?) Hochsprachenverwendung immer Platz-und Performancenachteile. Ganz gleich, wie gut ein Compiler sein mag." "Nun, Hochsprachenkonzepte sind allesamt ersponnen." "Ich sag Dir mal was man wirklich nur muss:Die paar Asm-Instructions und seinen Controller richtig kennen- das reicht für ewig." (sic!) "Du nimmst natürlich einen 32-Bit ARM! Dann hast Du Spielraum genug für ineffizientes Programmieren." "Mein Gott, ich verstehs ja. Da hat sich jemand eine großartige Entwicklungsumgebung aufgebaut, jahrelang mit 1000 Seiten Schmökern gepaukt, womöglich studiert und muss sich nun von einem dahergelaufenen Bastler sagen lassen, daß sich eine große Abzahl an typischen Programmieraufgaben mit ein paar Asm-Wortfetzen erschlagen lassen." Insofern sollten wir Moby zu seinem Erkenntnisgewinn beglückwünschen, daß er nach vielen Monaten und mehreren ewig langen Threads endlich eingesehen hat: "Aber irgendwann kommt der Punkt, an dem der Asm-Programmierer dieses Potential ob der schieren Programmgröße/komplexität nicht mehr heben kann- dann schlägt endgültig die Stunde der Hochsprache." Das ist genau das, was ihm zwei Dutzend sehr erfahrene professionelle Entwickler immer wieder mal mit mehr, mal mit weniger Geduld zu erklären versucht haben.
:
Bearbeitet durch User
> Insofern sollten wir Moby zu seinem Erkenntnisgewinn beglückwünschen
Abwarten bis er wieder auftaucht!
:
Bearbeitet durch User
Diese Offenbarung ist tatsächlich neu und bisher weigerte er sich das zu akzeptieren. Mein grösseres Problem ist aber das er meint ein einfacher AVR mit simplen ASM reicht für alles aus. Dabei sagt er selbst, dass er für gewisse Funktionen ein externes Modul anflanscht und dieses dann anspricht. Das auf besagtem Modul ein Cortex-M sitzt und in C oder gar C++ programmiert wurde, hat aber natürlich nichts mit seiner Argumentation zu tun. In einer Parallelwelt würde er argumentieren man brauche doch gar nicht so etwas ineffizientes und kompliziertes wie ein Auto, danach ins Taxi steigen und uns beim wegfahren auslachen.
:
Bearbeitet durch User
Operator S. schrieb: > Mein grösseres Problem ist aber das er meint... Und bestimmt nicht nur deins, denn das ist die Kernaussage dieses Threads ;-) Warum lassen sich professionelle Softwareentwickler von einem Kleinbastler so leicht provozieren? Passt er vielleicht in deren Beuteschema und weckt den Jagdinstinkt? Carl D. schrieb: > Abwarten bis er wieder auftaucht! Die Jagd ist voll im Gange? Jörg W. schrieb: > Einmal in die Enge getrieben, schlägt er wild um sich. Ujujuj, das arme Bastlerchen ;-)
:
Bearbeitet durch User
Witkatz :. schrieb: > Warum lassen sich professionelle Softwareentwickler von einem > Kleinbastler so leicht provozieren? Gut das war falsch formuliert. Insgeheim freue ich mich über jeden seiner Threads, sowohl dieser, wie auch jener des Sensorboards. Es erheitert meinen Tag und befreit die Gedanken, um danach weiter zu arbeiten. Dies meine ich übrigens nicht im ironischen Sinne, sondern ist ernst gemeint. Nun, warum man sich darüber aufregt? Das ist vermutlich gegenstand einiger Doktorarbeiten in der Psychologie. Denn es scheint bereits erwiesen, dass Ings und Infs sich übermässig enervieren können, siehe dazu auch verschiedene Threads im Forum (Warum hier alle so unhöflich sind) oder auch mal einen Artikel über Linus Torvalds sozialverhalten im Internet. Ich muss zugeben das ich mich auch manchmal provozieren lasse. Wichtig ist aber das man das erkennt und im nachhinein darüber lachen kann, oder gar sich Entschuldigen wenns denn ein eigener Fehler war. Im besten Fall ärgert man sich schon im vorherein nicht, aber ohne das Warum zu kennen, wirds schwierig. Ausserdem wäre so manch amüsanter Thread so gar nie entstanden ;-)
Operator S. schrieb: > Diese Offenbarung ist tatsächlich neu und bisher weigerte er sich das zu > akzeptieren. Ganz neu ist sie nicht, sie trat auch schon in früheren Threads zutage. > Mein grösseres Problem ist aber das er meint ein einfacher AVR mit > simplen ASM reicht für alles aus. Genau das ist der Punkt. Und um von seiner These trotz schlagkräftiger Argumente anderer keinen Millimeter abrücken zu müssen, schränkt er einfach das "alles" immer mehr ein. Beispiele: In einem anderen Thread wurde das Thema Arithmetik mit mehr als 8 Bit hervorgebracht, die in C definitiv leichter handzuhaben ist als in AVR-Assembler. Mobys Gegenargument (sinngemäß): Programme, die Berechnungen ausführen, die komplizierter sind als eine 8-Bit-Addition, sind keine typischen 8-Bit-Anwendungen. Sie sind damit für Moby nicht relevant und außerhalb seines Betrachtungsbereichs. In diesem Thread ging es um den TCP/IP-Stack. Der wird von Moby einfach in ein externes Modul ausgelagert und ist damit ebenfalls out-of-scope. Am Schluß besteht "alles" nur noch aus ca. 1% aller µC-Anwendungen, nämlich diejenigen, bei denen Daten von einer einfachen Schnittstelle (bspw. Digital-I/O oder ADC) gelesen, auf einfache Weise verarbeitet (bspw. Entprellung oder Mittelwertbildung) und auf einer anderen einfachen Schnittstelle (bspw. UART) wieder ausgegeben werden. Diese (und nur diese) Aufgaben lassen sich in Assembler tatsächlich fast genauso leicht realisieren wie in C. Dinge wie die Linearisierung von Sensordaten, ein PID-Regler, ein Kalman-Filter oder dergleichen, können i.Allg. ebenfalls sehr gut mit 8-Bit-Controllern wie den AVRs realisiert werden und sind in C immer noch ziemlich leicht zu implementieren. Ihre Programmierung in Assembler erfordert aber deutlich größere Anstrengungen. Anders als für den Rest der Welt sind das für Moby aber keine typischen 8-Bit-Anwendungen. De facto ist es so, dass alles, was in C leichter zu realisieren ist als in AVR-Assembler, für Moby keine typischen 8-Bit-Anwendungen und damit nicht Gegenstand der Diskussion sind. Als typische 8-Bit-Anwendungen und damit als Diskussionsgegenstand bleiben folglich nur die so genannten "Micky-Maus-Progrämmchen" übrig. Trotzdem würde mich nach wie vor interessieren, wo Moby größenmäßig die Grenze der Micky-Maus- ... äh ... der typischen 8-Bit-Anwendungen sieht.
Yalu X. schrieb: > Trotzdem würde mich nach wie vor interessieren, wo Moby größenmäßig die > Grenze der Micky-Maus- ... äh ... der typischen 8-Bit-Anwendungen sieht. ca. 25% der Kapazität eines Attiny13. Damit noch Platz für Erweiterungen bleibt. Nein, ich denke, die Grenze wird erreicht sein, wenn die 32 von ihm fest belegten Register nicht mehr ausreichen. mfg.
Yalu X. schrieb: > De facto ist es so, dass alles, was in C leichter zu realisieren ist als > in AVR-Assembler, für Moby keine typischen 8-Bit-Anwendungen und damit > nicht Gegenstand der Diskussion sind. Das ist doch ziemlich tricky, oder? Wenn man hier die Logikmaschine anwirft, kann man nur zu einem Schluss kommen: "Typische 8-Bit-Anwendungen sind in ASM geschrieben". Denn obige Definition lässt gar keinen anderen Schluß zu.
Frank M. schrieb: > Wenn man hier die Logikmaschine anwirft, kann man nur zu einem Schluss > kommen: > > "Typische 8-Bit-Anwendungen sind in ASM geschrieben". > > Denn obige Definition lässt gar keinen anderen Schluß zu. Eben. Deswegen ist dem Moby ja mit Argumenten auch so schwer beizukommen :)
Frank M. schrieb: > Wenn man hier die Logikmaschine anwirft, kann man nur zu einem Schluss > kommen: Er wirft die Logikmaschine eben gezielt weg. Die Argumentationskette hat immer die Länge 1, so kann man prinzipbedingt keine Widersprüche oder Zirkelschlüsse aufdecken. Diese Diskussionsweise ist durchaus erfolgsversprechend, da der Gegner prinzipiell komplizierter argumentieren muss als man selbst: Man selbst kann immer einen einfachen, "richtigen" Schluss vorbringen, während der Gegner anhand mindestens zwei Argumenten zeigen muss, dass man Unsinn erzählt. Für viele Zuhörer in der Runde mag dies bereits zu viel sein.
:
Bearbeitet durch User
P. M. schrieb: > Er wirft die Logikmaschine eben gezielt weg. Die Argumentationskette hat > immer die Länge 1, Naja, das ist halt in Assembler geschrieben. In Assembler, der Mobys Komplexitätsanforderungen genügt.
Uhu U. schrieb: > Moby A. schrieb: > Auf diesem Feld ist gerade kein Blumentopf zu gewinnen ;-) > > Deswegen meidest du die Antwort auf meine Frage: > > Wozu eigentlich ein Assembler? wenn es ein Hexeditor auch tut. > > wie der Teufel das Weihwasser... Die Frage ist natürlich allenfalls eine praktischer Bequemlichkeit... Ich geh mal davon aus, daß Dir das selbst bewußt ist und der Einwand anderen Zwecken folgt ;-) Sheeva P. schrieb: > Ist die Lebenszeit des Programmierers keine Ressource? Mir scheint dies > die wertvollste Ressource überhaupt zu sein. Absolut. Ich fokussiere mich aber auf die MC-Ressourcen und ggf. Einsparmöglichkeiten bei der puren Hardware-Auswahl. Die Frage des Verhältnisses von Programmier-Zeitbedarf zur MC-Ressourceneinsparung ist trotzdem eine berechtigte. Mindestens mal im Universum typischer 8-Bit MSR Apps lässt sich aber sagen: Die Antwort dürfte höchst individuell ausfallen. Je nach Übung, Vorbereitung, System... was ja auch bei Hochsprache hilfreich ist, nur leider ohne die letztlich erreichbare Asm-Effizienz ;-(
be s. schrieb: > Hier wurde bereits bewiesen, dass C sogar speicherplatzsparender > als Mobys Assembler sein kann: > Beitrag "Re: C versus Assembler->Performance" Und nochmal: Da wird nichts bewiesen. Freilich kann prinzipiell auch jeder ASMler den Flash unnütz füllen. Chris D. schrieb: > allerdings war bei etwa 4-8k Codegröße dann Schluß So. Und nun überlegt Euch einmal, wieviel Millionen MSR Anwendungen sich schon in 1-2KB Asm Code verpacken lassen. > Und da hat Moby einfach mal Recht. Unfassbar. Das muss ich erstmal sacken lassen ;-) > Je mehr Code man hat, desto eher steigen für den Assembler-Programmierer > die Chancen, Optimierungsmöglichkeiten zu übersehen. Ein Compiler tut > das nicht. Nicht unbedingt. Oft folgen die Optimierungsmöglichkeiten von Asm bei der freien Wahl der MC-Ressourcen einem einfachen System, nutzen prinzipielle Schwächen einer Compiler-Lösung aus. Und sie sind bei sagen wir mal bis 10K Code durchaus überschaubar! > bei kleinen Programmen (4k) an, wo ein Compiler Dinge findet, die er > doppelt nutzen kann, dann ist das schon faszinierend (und teilweise > unfassbar). Da muss man einfach den Hut vor den Compilerjungs ziehen. Ja, ganz nett. Aber das reicht nicht, um an gut handoptimiertem Asm vorbeizuziehen! > Ich würde also aus der Praxis heraus behaupten, dass ab einer gewissen > Codegröße der Compiler den Assemblerprogrammierer auch recht locker in > der Codegröße schlägt. Richtig. Weil ab einer bestimmten Projektgröße der Überblick verlorengeht. Trotzdem sind der Möglichkeiten des Asm-Programmierers diesen zu behalten auch nicht gerade wenige.
Frank M. schrieb: > das Mittel der Wahl und alles größer als ATTiny Teufelswerk, was man > nicht braucht. Für jeden Zweck die richtigen Mittel. Die AVR-Reihe bis hoch zum XMega stemmt einen Großteil typischer 8-Bit MSR Apps, wobei die Verwendung von Asm den Einsatzhorizont noch einmal ordentlich ausdehnt. Was ist daran nur so schwer zu verstehen? > Fazit: Moby hats drauf, bewusst zu provozieren. Das macht er aber nicht > offen, sondern sehr verdeckt. Eine Deiner vielen Unterstellungen. Warum willst Du den Fall, daß Asm tatsächlich Vorteile bietet auch partout nicht in Deine Überlegungen einbeziehen? <Beileid> Ist es so schlimm? </Beileid> Jörg W. schrieb: > Einmal in die Enge getrieben, schlägt er wild um sich. Siehe ganz oben > auf dieser Seite, wo er mich des „Märchenerzählers“ bezichtigt, um kurz > danach selbst zu behaupten, die Peripherals eines Xmega seien eigentlich > die gleichen wie bei einem MegaAVR, nur „die paar Steuerbits anders > verteilt“. Wo siehst Du da einen Widerspruch? Genauso ist das. Wie es ausschauen würde wenn ich wild um mich schlüge hast Du hier noch nicht erlebt- das wär auch wenig überzeugend ;-)
P. M. schrieb: > Moby A. schrieb: > Mit jeder Zeile mehr stehen die Chancen von Asm besser, da das > Verbesserungspotential wächst. Das wächst mit zunehmender Programmgröße > übrigens unbegrenzt > > Das ist schlicht und einfach extremer Unsinn. Ab einer gewissen Grösse > hat der Mensch unmöglich den Überblick, um weitgreifend zu optimieren. Du hast einfach nicht bis zum Ende gelesen... > Um es zusammenzufassen: Wir haben dir schon lange zugestimmt, dass > man mit Assembler auf sehr kleinen Mikrocontrollern bei kleinen > Projekten mit wenig Zusatzaufwand etwas besser sein kann als mit C. ... um dann wenigstens das zuzugestehen (wenn auch wieder mit vielerlei Relativierung). Immerhin ;-) > eben immer auf die Miniprojekte ausweichst. Ja. So ein praktisches Miniprojekt verdeutlicht das Prinzip -hier- am besten, ist am ehesten nachvollziehbar. Aber Code ist Code, ob mehr, ob weniger...
Yalu X. schrieb: > bei Dingen wie dem TCP/IP-Stack geht er > sogar noch einen Schritt weiter und kauft sich dafür für fast den > 100fachen Preis eines ATtiy13 gleich ein komplettes Hardwaremodul. Das hast Du aber jetzt schön in Beziehung gesetzt. Hatte ich nicht schon erwähnt daß mein Xport an einem Xmega hängt? > Nennt er als Grenze bspw. 200 Byte, würde ich (und wahrscheinlich viele > andere auch) das sofort akzeptieren Grenzen zu nennen ist inakzeptabel... Wenn mein größtes Asm Projekt 10K erreicht heißt das noch lange nicht daß da nicht noch mehr ginge! > Um zu zeigen, dass diese Grenze dennoch richtig ist, müsste > Moby in der Lage sein, in der gleichen Entwicklungszeit und mit gleicher > Speicher- und Laufzeiteffizienz ein 4-KiByte-Assemblerprogramm zu > schreiben wie ein C-Programmierer ein entsprechendes C-Programm. Es gibt keine "richtige" Grenze sondern nur eine, die von Übung, Vorbereitung, System und konkreter App höchst individuell ausfällt. Die Entwicklungszeit des Asm-Projekts dürfte grob geschätzt länger sein, ja. Aber die Effizienzvorteile von Asm sind auch kein Geschenk... Hatte ich das irgendwo behauptet?
Carl D. schrieb: > Ersteres muß man zugeben, es ist sein Thread, aber nur wenn er hier > Antworten bekommt, bleibt er auch hier. Darauf würde ich mich nicht verlassen, denn > wenn er wieder einen Thread mit > C/C++-Themen mit seinem Assembler- Fundamentalismus flutet. nutzt er nur die Gelegenheit am praktischen Beispiel, die Ineffizienz von C++ nicht nur vom resultierenden Code her, sondern auch die unnütze Komplexität der Programmerstellung selber bloßzustellen. Unvergessen sind mir da manche monströsen Ausdrücke bloß um ein paar Portpins zu beeinflussen. Fundamentalismus schließlich ist etwas anderes: Das wäre dann der Fall würde man die Sinnhaftigkeit einer Programmiersprache von der Anwendung entkoppeln; Vor-und Nachteile der Sprachen ignorieren. Michael K. schrieb: > Ist ja toll wenn man so auf ASM abgeht, mir ist das aber zu fixiert auf > eine Controller Familie Zwischem beidem existiert ein Zusammenhang ;-) Sheeva P. schrieb: > Das ist genau das, was ihm zwei Dutzend > sehr erfahrene professionelle Entwickler immer wieder mal mit mehr, mal > mit weniger Geduld zu erklären versucht haben. Irrtum. Dazu mal ein Tipp: Zähl mal wie oft ich den Ausdruck "für typische 8-Bit'"MSR-Apps verwende. Das hat einen Hintergrund! Darauf und nur darauf beziehe ich die Vorteile von Asm seit jeher! Das fällt auch immer wieder bevorzugt unter den Tisch.
Operator S. schrieb: > Diese Offenbarung ist tatsächlich neu und bisher weigerte er sich > das zu akzeptieren. S.O. > Mein grösseres Problem ist aber das er meint ein einfacher AVR mit > simplen ASM reicht für alles aus. Ach was. Größere Berechnungen und Datenmengen hatte ich hier schon als Gegenindikation genannt. > Dabei sagt er selbst, dass er für > gewisse Funktionen ein externes Modul anflanscht und dieses dann > anspricht. Das auf besagtem Modul ein Cortex-M sitzt und in C oder gar > C++ programmiert wurde, hat aber natürlich nichts mit seiner > Argumentation zu tun. Warum sollte ich das ideologisch beschränkt verweigern? Soll der Cortex-M doch dort seine Berechtigung haben (obwohl ich das jetzt aus eigener Erfahrung nicht bestätigen kann). Der Einsatz externer Module ist, zumindest für mich als Bastler, auch eine Frage von Effizienz- auf einer übergeordneten Ebene quasi. Niemand hat dem Sinn von 32-Bit ARM hier widersprochen, wär auch reichlich blöd bei dem Boom den die gerade erleben. Aber: Das muß bei den Millionen Anwendungen denen ein 8-Bitter genügt nicht nennenswert beeindrucken ;-)
:
Bearbeitet durch User
Operator S. schrieb: > Insgeheim freue ich mich über jeden > seiner Threads, sowohl dieser, wie auch jener des Sensorboards. Es > erheitert meinen Tag und befreit die Gedanken, um danach weiter zu > arbeiten. > Dies meine ich übrigens nicht im ironischen Sinne, sondern ist ernst > gemeint. Da freu ich mich auch. > Nun, warum man sich darüber aufregt? Das ist vermutlich gegenstand > einiger Doktorarbeiten in der Psychologie. Denn es scheint bereits > erwiesen, dass Ings und Infs sich übermässig enervieren können, Ich sehe eher ein gewisses C-Selbstbewußtsein getroffen. Kann doch nicht sein daß man so vieles auch einfacher in Asm erledigen kann! Yalu X. schrieb: > Am Schluß besteht "alles" nur noch aus ca. 1% aller µC-Anwendungen, > nämlich diejenigen, bei denen Daten von einer einfachen Schnittstelle > (bspw. Digital-I/O oder ADC) gelesen, auf einfache Weise verarbeitet > (bspw. Entprellung oder Mittelwertbildung) und auf einer anderen > einfachen Schnittstelle (bspw. UART) wieder ausgegeben werden. Diese > (und nur diese) Aufgaben lassen sich in Assembler tatsächlich fast > genauso leicht realisieren wie in C. Deine 1% würde ich eher denen hier zuordnen (solange tatsächlich 8-bittig verwirklicht): > Dinge wie die Linearisierung von Sensordaten, ein PID-Regler, ein > Kalman-Filter oder dergleichen, können i.Allg. ebenfalls sehr gut mit > 8-Bit-Controllern wie den AVRs realisiert werden Im SmartHome beispielsweise braucht man viele verschiedene Funktionen für Sensor- und Aktordaten. Größere Datenmengen und Berechnungen gibts da sehr wenig. Vielleicht bau ich ja mal einen Quadrocopter. Da nehm ich dann 32-Bit mit Hochsprache, versprochen ;-)
Moby A. schrieb: > Größere Datenmengen und Berechnungen gibts da sehr wenig. Ich weiß ja nicht …
1 | sht21_measure(0xe3, b, 3); |
2 | v = ((uint16_t)b[0] << 8) | b[1]; |
3 | double t = -46.85 + 175.72 * (double)v / 65536.0; |
4 | |
5 | ht21_measure(0xe5, b, 3); |
6 | v = ((uint16_t)b[0] << 8) | (b[1] & 0xfc); |
7 | double h = -6.0 + 125.0 * (double)v / 65536.0; |
8 | |
9 | TRX_PRINTF("SHT-21#1 %5.2f oC, %5.2f %% RH\r\n", t, h); |
Man kann die Berechnung sicher auch irgendwo mit scaled integers durchziehen statt mit float/double, aber wenn ich mit den durch den SHT21 gemessenen Werten für Temperatur und Feuchtigkeit etwas anfangen will, dann muss ich rechnen. Noch schlimmer sieht's bei so einem Luftdrucksensor (MPL1115) aus:
1 | barometer_init(); |
2 | |
3 | uint8_t params[8]; |
4 | barometer_read(4, 8, params); |
5 | |
6 | int a0_int = (params[0] << 8) + params[1]; |
7 | a0 = a0_int / 8.0; |
8 | int b1_int = (params[2] << 8) + params[3]; |
9 | b1 = b1_int / 8192.0; |
10 | int b2_int = (params[4] << 8) + params[5]; |
11 | b2 = b2_int / 16384.0; |
12 | int c12_int = (params[6] << 8) + params[7]; |
13 | c12 = c12_int / (16384.0 * 1024.0); |
14 | |
15 | //…
|
16 | uint8_t results[4]; |
17 | |
18 | barometer_read(0, 4, results); |
19 | unsigned padc = (results[0] << 2) + (results[1] >> 6); |
20 | unsigned tadc = (results[2] << 2) + (results[3] >> 6); |
21 | |
22 | double pcomp = a0 + (b1 + c12 * (double)tadc) |
23 | * (double)padc + b2 * (double)tadc; |
24 | double pressure = pcomp * ((115 - 50) / 1023.0) + 50; |
25 | |
26 | PRINTF("0000: %.1f hPa" NL, pressure * 10); |
Initial muss man sich dort ein paar Kalibrierwerte auslesen, dann muss man bei jeder Messung die interne Temperatur messen zusätzlich zu den Messwerten des Druckaufnehmers, und diese gemäß der Formel im Datenblatt umrechnen. Wie gesagt, über floating point vs. scaled integer würde ich hier nicht diskutieren, geht sicher auch mit letzterem. Aber „keine Berechnungen“? Oder ist jetzt das Messen von Temperatur, Luftdruck und Luftfeuchtigkeit plötzlich „keine typische Aufgabe für einen 8-Bitter“ mehr?
Thomas E. schrieb: > Nein, ich denke, die Grenze wird erreicht sein, wenn die 32 von ihm fest > belegten Register nicht mehr ausreichen. So wird nie eine Grenze erreicht. Asm-Programmierer-System bedingt ;-) Frank M. schrieb: > "Typische 8-Bit-Anwendungen sind in ASM geschrieben". So es der Programmierer einzusetzen weiß und keine der erwähnten Gründe entgegenstehen ist das von Vorteil! P. M. schrieb: > Frank M. schrieb: > Wenn man hier die Logikmaschine anwirft, kann man nur zu einem Schluss > kommen: > > Er wirft die Logikmaschine eben gezielt weg. Die Argumentationskette hat > immer die Länge 1, so kann man prinzipbedingt keine Widersprüche oder > Zirkelschlüsse aufdecken. Diese Diskussionsweise ist durchaus > erfolgsversprechend, da der Gegner prinzipiell komplizierter > argumentieren muss als man selbst: Man selbst kann immer einen > einfachen, "richtigen" Schluss vorbringen, während der Gegner anhand > mindestens zwei Argumenten zeigen muss, dass man Unsinn erzählt. Für > viele Zuhörer in der Runde mag dies bereits zu viel sein. Machts doch nicht wieder (C-Programmierer typisch;-) so kompliziert! Ich habe mir die Mühe gemacht hier ein praktisches Asm-Projektbeispiel mit wenig Funktionalität zur Veranschaulichung reinzustellen. Soll das doch jemand effizienter in C coden. Solange das nicht passiert brauchen wir hier nicht theoretisch mit Logikmaschinen, Argumentationsketten und Zirkelschlüssen herumlamentieren ;-(
Jörg W. schrieb: > Initial muss man sich dort ein paar Kalibrierwerte auslesen, dann muss > man bei jeder Messung die interne Temperatur messen zusätzlich zu den > Messwerten des Druckaufnehmers, und diese gemäß der Formel im Datenblatt > umrechnen. DESHALB sagte ich "sehr wenig"! Ich habe auch einen ähnlichen Kombisensor in meiner Wetterstation mit ähnlichem Procedere. Das ging natürlich auch in Asm, ist aber etwas aufwendig. > Oder ist jetzt das Messen von Temperatur, Luftdruck und Luftfeuchtigkeit > plötzlich „keine typische Aufgabe für einen 8-Bitter“ mehr? Dem umständlichen Messwert-Berechnen kann man übrigens mit vielen einfachen analogen Sensoren für jede der 3 Größen effektiv aus dem Wege gehen...
:
Bearbeitet durch User
Moby A. schrieb: > Dem umständlichen Messwert-Berechnen kann man übrigens mit vielen > einfachen analogen Sensoren für jede der 3 Größen effektiv aus dem Wege > gehen... Warum sollte man? Die Berechnung oben ist wenige Zeilen, und der kleinste Controller, den ich dafür habe, hat sowieso 128 KiB Flash. Das sind ATmega128RFA1, die ich u. a. eben auch wegen der eingebauten Funkschnittstelle nehme. Ersatz durch einen ATtiny* fällt also schon mal aus, denn das Anflanschen irgendwelcher externer Datenübertragung wäre in jedem Falle umständlicher. Die Analogbausteine werden ohnehin kaum genauer sein, der Vorteil der digitalen ist ja gerade, dass sie all ihre Analogverarbeitung on-board direkt auf dem Chip machen können, das minimiert die Störeinflüsse.
Moby A. schrieb: > Uhu U. schrieb: >> Moby A. schrieb: >> Auf diesem Feld ist gerade kein Blumentopf zu gewinnen ;-) >> >> Deswegen meidest du die Antwort auf meine Frage: >> >> Wozu eigentlich ein Assembler? wenn es ein Hexeditor auch tut. >> >> wie der Teufel das Weihwasser... > > Die Frage ist natürlich allenfalls eine praktischer Bequemlichkeit... Aha, wir kommen dem Kern der Sache näher... Der Hex-Editor ist zweifellos unbequemer, als ein Assembler, man kann aber dasselbe damit erreichen, nur mit höherem Aufwand, d.h. auf unbequemerem Weg. Wir können das Modell nach "oben" und nach "unten erweitern. Nach "oben": der C-Compiler ist bequemer, als der ASM; ein Generator, der automatisch beliebige Probleme analysiert und dann eine Software generiert, die genau das macht, was nötig ist, das Problem zu lösen, ist noch viel Bequemer, als ein C-Compiler usw. usf... Nach "unten": Man braucht überhaupt keine Microcontroller, man kann die damit gelösten und die dadurch erst geschaffenen Probleme auch umgehen. Man landet irgendwann auf dem Niveau des primitivst möglichen Organismus, der keine Bedürfnisse mehr hat und nur noch vom evolutionären Druck getrieben ist, an dem er scheitern muss, weil er sich ja nicht weiter entwickeln "will". Durch ständige Weiterentwicklung der Technik wird die relative Distanz des ASM-Puristen zur Comutersteinzeit immer geringer, d.h. seine Arbeitsweise wird immer unbequemer, weil immer unproduktiver - im Geschäftsleben ist das ein Aussterbegrund: der arme ASM-Purist bekommt nicht mehr genug zu fressen und verhungert. Deswegen geht der Trend in Richtung des skizzierten allwissenden Generators, der dem Leuten letztlich alle Arbeit abnimmt. Da beginnt das nächste Problem: was sollen die dann tun, um sich nicht zu langweilen? Den ganzen Tag fressen bringts nicht, davon wird man zu fett. Man wird also den Generator befragen und der generiert möglicherweise diese Antwort:
1 | Baue zum Spaß einen Hexeditor und programmiere damit auf einem fossilen |
2 | Microcontroller ein in 20 Befehlen lösbares Problem deiner Wahl. |
Damit steht der Generatorverwöhnte - der natürlich den Generator nicht im entfernten durchschaut, sondern ihn für eine göttliche Wundermaschine hält - vor dem Problem, die Grundzüge der Computertechnik aus grauer Vorzeit neu erfinden zu müssen. Ganz besonders schwer tut er sich dabei mit dem EOR-Befehl und das gibt uns wiederum einen heißen Tipp, womit wir es hier zu tun haben: Es ist Moby, der zu faul is, sich die Grundzüge unserer Informatik zu rekonstruieren und sich deswegen einfach vom Generator auf die Zeitreise ins frühe 21. Jahrhundert schicken ließ um sich von uns alles erklären zu lassen. Mittlerweile hat ihn aber wieder die alte Bequemlicheit erfasst, zu der er vom Generator erzogen wurde und er will nichts mehr lernen. Außerdem hat der den Trick vergessen, mit dem er die Zeitheimreise antreten kann und nun hockt er hier und dreht auf dem Assembler hohl. Die Moral von der Geschicht: Wenn man der Zeit so viel voraus ist, wie Moby, sollte man ihr nicht hinterher hinken ;-)
Moby A. schrieb: > Thomas E. schrieb: >> Nein, ich denke, die Grenze wird erreicht sein, wenn die 32 von ihm fest >> belegten Register nicht mehr ausreichen. > > So wird nie eine Grenze erreicht. Asm-Programmierer-System bedingt ;-) den Teil solltst nochmal erklären .. der Optimale ASM code verwendet soviele Register wie möglich (also im besten Fall alle..) jegliches "Asm-Programmierer-System" welches ja dazu dient, dir die Übersichtlichkeit oder Erweiterbarkeit oder ... zu verbesser, bedingt aber automatisch dass dein Code nicht Optimal (siehe oben) ist... ps. eigentlich kommt beim Optimalem ASM code, auch erstmal geschwindigkeit vor größe... also erstmal ALLE verfügbaren Resourcen* nutzen, erst wenn diese ausgehen, muss man Resourcen* sparen.. *Moby Resourcen sind gemeint..
Uhu U. schrieb: > Wenn man der Zeit so viel voraus ist, wie Moby, sollte man ihr nicht > hinterher hinken ;-) Herrliche Story, danke!
Moby A. schrieb: > Irrtum. Dazu mal ein Tipp: Zähl mal wie oft ich den Ausdruck "für > typische 8-Bit'"MSR-Apps verwende. Das hat einen Hintergrund! Darauf und > nur darauf beziehe ich die Vorteile von Asm seit jeher! Das fällt auch > immer wieder bevorzugt unter den Tisch. Dann hör jetzt endlch auf um den heisen Brei rum zu reden und zeig endlich eine dieser Anwendungen und zwar eine von DIR (!) und eine mir mehr als 20 Zeilen. Sagen wir mal lockere 2kB hex code. Dokumentiere die Funktionalität so, dass eine eindeutiges Pflichtenheft dabei raus kommt. Ich halte jede Wette das dich jeder C Neuling der sich im Forum herumtreibt deinen code sowohl in Ausführungszeit als auch bzgl. der codegröße um Längen schlägt! Na ja, natürlich kenne jetzt schon deine Antwort... so wie die meisten hier ;-)
Jörg W. schrieb: > Die Analogbausteine werden ohnehin kaum genauer sein, der Vorteil der > digitalen ist ja gerade, dass sie all ihre Analogverarbeitung on-board > direkt auf dem Chip machen können, das minimiert die Störeinflüsse. Schon klar. Dafür benötigen die analogen eben keine langwierigen Berechnungen und langen oft genauso. Keep it simple! Uhu U. schrieb: > Der Hex-Editor ist zweifellos unbequemer, als ein Assembler, man kann > aber dasselbe damit erreichen, nur mit höherem Aufwand, d.h. auf > unbequemerem Weg. Wir können das Modell nach "oben" und nach "unten > erweitern... Nette Story. Nur wieder voll am Thema vorbei ;-) Die Programmentwicklung mit Asm selbst ist heute für 8-Bit MSR eine einfache Sache: Code mit den paar dutzend simplen Instruktionen schreiben, assemblieren und rauf auf den Controller. Keine umständliche Compilerwahl, keine umständlichen C-Konstruktionen, keine "Optimierung" usw. usf. Easy und trotzdem effizient. > Die Moral von der Geschicht: > Wenn man der Zeit so viel voraus ist, wie Moby, sollte man ihr nicht > hinterher hinken ;-) Die Moral ist: Die Controller(sprach)welt nicht in veraltet und neu einteilen sondern in einfach und unnötig kompliziert... Immer schön die Bedürfnisse der App im Auge behalten ;-)
Robert L. schrieb: > So wird nie eine Grenze erreicht. Asm-Programmierer-System bedingt ;-) > > den Teil solltst nochmal erklären .. > der Optimale ASM code verwendet soviele Register wie möglich (also im > besten Fall alle..) Soviele Register wie möglich sollte man in jedem Fall verwenden. Sie langen aber auch für jeden Fall, wenn man ein bischen System in die Registerverwendung bringt. Da ist dann etwas Mitdenken angesagt, wenn das Programm nicht ohnehin sehr klein ist. Gerne erläutere ich Dir mal mein System bei größeren Programmen >1K... > ps. eigentlich kommt beim Optimalem ASM code, auch erstmal > geschwindigkeit vor größe... Das ist natürlich falsch. Wenn Speed keine Rolle spielt wird natürlich zuallererst die Codegröße interessant. Gerade die Größe des Flash ist natürlich ein wesentliches Unterscheidungsmerkmal der Controller (und ihrer Baugröße und des Preises). Schließlich wird man die Taktfrequenz noch auf nötiges Minimum justieren und schon kann man sich an einer optimalen Lösung erfreuen ;-)
Gu. F. schrieb: > Ich halte jede Wette das dich jeder C Neuling der sich im Forum > herumtreibt deinen code sowohl in Ausführungszeit als auch bzgl. der > codegröße um Längen schlägt! Lustig. Aber solang das nicht mal die größten Experten hier mit dem hööööchstproduktiveffizienten C bei überschaubarem Winzigfunktionalitätscode schaffen lehne ich mich mal gaaanz entspannt zurück ;-) P.S. Gerade beim 'ganz' s.o. noch zwei a eingefügt
:
Bearbeitet durch User
>Gerne erläutere ich Dir mal >mein System bei größeren Programmen >1K... ja dann, leg mal los..
>> ps. eigentlich kommt beim Optimalem ASM code, auch erstmal >> geschwindigkeit vor größe... > > Das ist natürlich falsch. Wenn Speed keine Rolle spielt wird natürlich > zuallererst die Codegröße interessant. Gerade die Größe des Flash ist > natürlich ein wesentliches Unterscheidungsmerkmal der Controller (und > ihrer Baugröße und des Preises). Schließlich wird man die Taktfrequenz > noch auf nötiges Minimum justieren und schon kann man sich an einer > optimalen Lösung erfreuen ;-) Ohne die geringste Hoffnung daß der Addressat das versteht: Wenn der Takt so niedrig wie möglich sein soll, dann ist Speed des Codes extrem wichtig. Linear runtergeschriebener Code ohne Schleifen braucht zwar mehr Flash (den ja eine "typische 8-Bit MSR" eh zu 80% leer läßt), durchläuft aber je Meßzyklus weniger Befehle und spart damit Strom. >Jörg W. schrieb: >> Die Analogbausteine werden ohnehin kaum genauer sein, der Vorteil der >> digitalen ist ja gerade, dass sie all ihre Analogverarbeitung >> on-board direkt auf dem Chip machen können, das minimiert die >> Störeinflüsse. > > Schon klar. Dafür benötigen die analogen eben keine langwierigen > Berechnungen und langen oft genauso. > Keep it simple! Ja klar, viel simpler sind dann externe OpAmp-"Gräber". Davon kann man nämlich auch "nix verstehen": Beitrag "Analoger Sensor (LM335) mit Operationsverstärker + AVR Asm-Code"
Carl D. schrieb: > Wenn der Takt so niedrig wie möglich sein soll, dann ist Speed des Codes ... Ich sagte wenn Speed keine Rolle spielt... Dann dreh ich am Takt hinterher... Spielt er DIE Rolle, muß ich i.d.R. mehr Flash in die Hand nehmen. Spielt Stromverbrauch DIE Rolle dann für möglichst wenig Takt genauso. Du erzählst mir da nix Neues. > Ja klar, viel simpler sind dann externe OpAmp-"Gräber" Ja klar, ein OpAmp sind für Dich Gräber und der OpAmp als Verstärker hat was mit Asm zu tun... > Ohne die geringste Hoffnung daß der Addressat das versteht Ohne die geringste Hoffnung daß Du mich verstehen willst ;-)
:
Bearbeitet durch User
Robert L. schrieb: > Gerne erläutere ich Dir mal >mein System bei größeren Programmen >>1K... > > ja dann, leg mal los.. Also, es ging drum daß 32 Register auch bei größeren Projekten nie zur Begrenzung werden. Das "System" schaut bei mir so aus: Für Interrupts aller Art die 6 Pointerregister XL-ZH. Diese werden bei Eintritt Zeit/Flash sparend mit MOVW in R10-R15 gesichert. R9 sichert die Flags. Interruptroutinen kommen möglichst nur mit den Pointerregistern aus. Tun sie das nicht werden die weiteren benötigten Register (ab R16) auf dem Stack gesichert. Anzustrebender Sonderfall (öfter möglich): Die Funktionalität steckt allein in (sich nicht gegenseitig unterbrechenden) Interrupts. Da muß dann nix oder nur wenig gesichert werden! Im Hauptprogramm wird hier nur geschlafen... Ansonsten kommt dieses meist mit allen Registern ab R16 aus. R7-R8 enthält einen Systeminterrupt Counter für Timing-Aufgaben. R0-R6 sind für spezielle Zwecke/Instruktionen reserviert. Weitere Fragen und Einsprüche?
:
Bearbeitet durch User
Moby A. schrieb: > Weitere Fragen und Einsprüche? Ja, warum sollte ich über sowas nachdenken müssen?
:
Bearbeitet durch User
Sven B. schrieb: > Ja, warum sollte ich über sowas nachdenken müssen? Stimmt. Du kannst auch Hochsprache mit all ihren Nachteilen verwenden. Und über andere, künstliche Probleme bei der bestmöglichen Sprachverwendung nachdenken ;-)
Moby A. schrieb: > Stimmt. Du kannst auch Hochsprache mit all ihren Nachteilen verwenden. > Und über andere, künstliche Probleme bei der bestmöglichen > Sprachverwendung nachdenken ;-) Die Geschichte der Menschheit ist voll davon, natürliche Probleme durch künstliche zu ersetzen. Statt zu frieren und Fleisch als Rohkost vom Knochen zu nagen könnte ich in den Wald gehen und Holz schlagen. Das war eine der frühen Stufen beim Ersatz natürlicher Probleme durch künstliche. Mittlerweile wurde freilich das bereits künstliche Beschaffungsproblem vom Holz durch mehrere noch künstlichere ersetzt, nämlich jährlich den Öltank aufzufüllen und die Stromrechnung zu zahlen. Die Nachteile dieser Lösung des Wärme- und Beschaffungsproblems liegen auf der Hand. Ohne auf Nahost-Öl basierte Zivilisation gäbe des die aktuelle Form des Terrorismus nicht. Also meine Damen und Herren: back to the roots, allesamt! Schinken-Original, direkt vom noch schlachtwarmen Schwein genagt. ;-)
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten