Moby A. schrieb: > für ein Urteil zum bürokratischen Aufwand langt ein > Blick in jedes C-Buch. Ja, da siehst Du ganz toll die Beschreibungssprache die sich am englischen Wortschatz und mathematischen Grundbegriffen orientiert um Lesbarkeit und intuitives Verständniss zu fördern. Welch kurzen und eleganten ASM Konstruktionen der Compiler daraus macht kannst Du aber in keinem C Buch lesen. Kann es sein das Dein Kampf mit C bereits bei der englischen Sprache anfängt? Ist jetzt nicht böse gemeint, aber da könnte ich ein klein wenig besser verstehen warum Du C kryptisch findest. Zwei Fremdsprachen auf ein Mal zu lernen ist natürlich schwerer. Andererseits sollte dann auch das AVR Datasheet eine echte Hürde für Dich sein. Moby A. schrieb: > Für ein Urteil des Handlings beim Erarbeiten von > Lösungen langt ein längerer Selbstversuch. Ja genau, und da war für mich nach dem ersten erfolgreich kompiliertem 'HELLO WORLD' Program klar das ich mich mit C ganz wohlfühle. Ja, Asche auf mein Haupt, ohne Informatik Studium bin ich natürlich tatsächlich nicht in der Lage manche Konstruktionen zu verstehen die ein Informatiker völlig selbstverständlich dahinzaubert. Das schöne ist, das ich das meistens auch nicht wissen muß weil es reicht mich an bestimmte Konventionen zu halten und copy / paste Beispiele so lange zu verfeinern bis mich der Schatten einer Ahnung überkommt und es einfach funktioniert. Klar, es gab eine gewisse Frustration bis ich das Zusammenspiel der C toolchain verinnerlicht hatte. Zum einen sind die IDEs heute soweit das ich nur in seltenen Fällen noch tiefer gehen muß, zum anderen muß ich mich ohne C viel tiefer in die Internas der jeweiligen MCU einarbeiten was im Endeffekt viel mehr Zeit kostet. > beim Erarbeiten von Lösungen Eben, Du sagst es Moby. Eine Lösung wird erarbeitet. Einer Lösung ist es aber egal ob noch 10 Bytes mehr frei sind im Ram oder 100Bytes mehr im Flash. Eine Lösung produziert von aussen betrachtet ein Ergebniss. Signale gehen rein, Signale gehen raus. Wenn ein in einer beliebigen Sprache geschriebenes Programm diese verbindlichen Vorgaben erfüllt, dann ist es prinzipiell erstmal ein gutes Programm. Um so besser wenn ich es schnell schreiben konnte, noch besser wenn es auch Jahre später noch ein fremder Programmierer schnell verstehen und ändern kann. 8051 Basic hat selbst fast alle Ressourcen gebraucht. Pascal war kaum für MCUs verfügbar. Bascom-AVR war auf eine MCU Familie beschränkt (ebsenso ASM) C war die erste Sprache die mich weit von der Hardware löst wenn ich das will, mir aber wirklich alle Freiheiten läßt wenn ich es darauf anlege. Ich erlebe gerade ein schönes Beispiel für Licht und Schatten höherer Programmiersprachen. Für eine frisch entwickelte Hardware brauche ich ein steuerndes PC Programm das ein wenig schick ist, also GUI, leicht auf andere Systeme portierbar und durch die späteren Kunden meiner Hardware leicht an eigene Bedürfnisse anpassbar. Ich bin bei Python gelandet und ich hasse es aus tiefstem Herzen. Python + Tk wird laufend kaputtgeändert. Beispiele die unter Python 3.3 noch liefen versagen jetzt Ihren Dienst. Irgendjem gefiel die Syntax nicht und war der Meinung das Dinge die vorher klein geshrieben wurden jetzt groß geschrieben werden müssen, oder einfach anders. Argumente die ich vorher hintereinander wegschreiben konnte müssen nun in einer Tiporgie ganz anders geschreiben werden um genau das gleiche zu tun. Im Netz liegen tausende Beispiele die aber immer nur für eine nicht näher bezeichnete Version funktionieren. Zudem kapier diesen objektorientieren Klassen udn Vererbungs K*ck ehrlich gesagt nicht ganz. So weit so schlecht. Trotz allem habe ich es binnen einer Woche geschafft ein kleines Programm zu schreiben das unter Ausnutzung von extrem mächtigen Bibliotheken, die ich allesamt kein bißchen kapiert habe, mit Schiebereglern und grafischer Echtzeitdarstellung meine Hardware zu steuern. Unter Windows und unter Linux. Wie geil ist das denn ? Natürlich bin ich oft frustriert weil ich nicht wirklich weiß was ich da gerade mache und warum, aber das Ergebniss das ich mit diesem herumgestümper erreiche hätte ich anders nicht erreicht. Das motiviert mich weiterzumachen und mich in diese merkwürdige Sprache hineinzuarbeiten die die Dinge auf eine mir völlig unverständliche Art löst. Irgendwann wird der Groschen fallen und ich werden das was ich heute als überbordende Bürokratie empfinde als nützliche Spracheigenschaften zu schätzen wissen. Die Flinte ins Korn zu werfen und das alles blöd zu finden verurteilt mich dazu auf dem Level zu bleiben auf dem ich heute bin. Ich habe mich mal bei einem studiertem Informatiker darüber ausgeheult das ich Python nicht verstehe. Die Antwort war: 'Niemand versteht Python' Das hat mir echt geholfen.
Michael K. schrieb: > jeweiligen MCU einarbeiten > was im Endeffekt viel mehr Zeit kostet. Das ist aber egal, wie viel Zeit verbraten wird, solange ein Byte RAM/FLASH gespart werden kann. Das ist Mobys beschränkte Welt.
Moby A. schrieb: > Karl H. schrieb: >> Weil es mich ehrlich gesagt überhaupt nicht wirklich interessiert. Du >> weigerst dich ja auch beharrlich auf meinen Vergleichs-Vorschlag >> einzugehen. >> Dabei würde es mich wirklich interessieren, was ein guter Assembler >> Programmierer aus meiner schnell hingeschusterten Heizungssteuerung noch >> rausholen kann. > > Das hatte ich schon befürchtet, daß zur vollständigen Funktionalität > Deines Codes noch einiges fehlt. Nö. Eigentlich fehlt nichts. Nur weil ich sage, dass ich das schnell hingeschustert habe, bedeutet das noch lange nicht, dass sie nicht vollständig wäre. Ich könnte mich rann setzen und ein paar Stellen eleganter schreiben, funktional bringt das keinen Mehrwert. Die Steuerung tut das, was sie tun soll. Und das seit 5 Jahren. >> Du wirst nicht nur mit >> den AVR-Registern auskommen sondern wirst dir ein Konzept zur >> Registerbenutzung überlegen müssen. > > Hatte ich das nicht schon? Du hast so viel von dir gegeben, dass ich schon längst den Überblick verloren habe, was du gesagt hast und was nicht.
Moby A. schrieb: >> Er ist Hobbyprogrammierer und hat den ASM-Befehl EOR vor etwa 4 Jehren >> kennengelernt: > > Erstmalig benötigt. Tatsächlich ist eben eine Teilmenge der > AVR-Instruktionen zumeist ausreichend. Wußtest Du natürlich vorher. Natürlich kann man auch mit dem halben Befehlssatz funktionierende Programme schreiben. Mit Effizienz hat das aber nichts mehr zu tun.
Moby A. schrieb: > Nochmal ganz klar zum Mitschreiben: Ich liefere hier keine Lösungen > für weitere Aufgaben. > Es gilt mein Beispiel zu toppen. Mal angenommen, es gelänge tatsächlich niemandem, dein Programm in C kürzer (auf den Binärcode bezogen) zu schreiben. Was hättest du damit bewiesen? Dass ein ca. 200 Byte großes Programm in Assembler möglicherweise kürzer ist, wenn man in stundenlanger Kleinarbeit jeden einzelnen Befehl so lange dreht und wendet, bis man auch das letzte überflüssige Byte wegoptimiert hat. Nicht mehr und nicht weniger. Wie ich aber früher schon geschrieben habe, interessiert das außer dir kein Huhn auch nur im Allergeringsten, da der ATtiny13 die fünffache Menge Flash-Speicher hat. Deswegen (und wegen deiner ziemlich volatilen Anforderungen an den Programmcode) ist kaum jemand sonderlich motiviert, Arbeit in die Umsetzung in ein C-Programm zu inverstieren. Dein Argument, dass der Code ja vielleicht irgendwann erweitert werden soll, zieht überhaupt nicht. Denn sobald die Code in Richtung 1 KB geht, wirst auch du ihn nicht mehr mit der gleichen Intensität handoptimieren, da der Aufwand dafür mindestens quadratisch mit der Codergröße steigt. Hier wird i.Allg. ein C-Programm größenmäßig gleich gut oder besser, bei der Entwicklungszeit sogar sehr viel besser abschneiden. Wenn deine Aussage also lautet: "Bei Programmen bis ca. 200 Bytes hat die Assembler-Programmierung keine großen Nachteile, aber auch kaum Vorteile." stimme ich (und sicher auch viele andere Diskutanten) dir auch ohne Wettbewerb zu, und wir können die Diskussion beenden. Wenn du aber behauptest: "Assembler bringt auch bei größeren Programmen Vorteile, solange darin keine Arithmetik mit mehr als 8 Bit stattfindet." widerspreche ich (und praktisch alle andere Diskutanten) dir trotz der Einschränkung bei der Arithmetik ganz entschieden. Solltest du an dieser Aussage trotzdem festhalten, liegt es an dir, sie zu beweisen. Das kann dir aber logischerweise nicht mit einem 200-Byte-Progrämmchen gelingen. Solange du diesen Beweis nicht erbracht hast, steht die Aussage eines einzelnen Assembler-Only-Programmierers gegen diejenige von zig Leuten, die Erfahrung in Assembler und C haben. So ist nun mal die Situation und nicht anders. Es hängt jetzt ganz alleine von dir ab, ob sich die Diskussion weiterhin endlos im Kreis dreht, ob vielleicht mal wieder etwas frischer Wind hineinkommt, oder ob wir sie einfach beenden.
Moby A. schrieb: > Meine funktionierenden Projekte darfst Du ernst nehmen. Funktionierende Assembler-Projekt_chen_, aus denen du ableitest, Hochsprachen würden die halbe oder die ganze Software-Welt verderben. Ich will die Studium-Frage nicht nochmals hochkochen, es ging dabei einzig und alleine darum, ob du überhaupt einen minimalen Erfahrungsschatz mitbringst, auf den du deine Ansichten stützt. Die Antwort ist klar: Nein, denn du vergleichst zwar Assembler mit Hochsprachen, kannst aber noch nicht mal eine einzige davon. Du hast somit vermutlich auch noch nie etwas davon gehört, wie Compiler-Optimierung funktioniert oder wo die Flaschenhälse bei heutiger Software-Entwicklung liegen. Kurz: Du bist wirklich nicht qualifiziert, in diesem Thread mitzudiskutieren. Obendrauf, du schaffst es noch nicht mal, in deinem kleinen Bereich richtig Fakten zu liefern. Du kannst das C-Beispiel nicht übersetzen und du quittierst die Untersuchung anderer mit "dazu kann ich jetzt nichts sagen".
Stefan K. schrieb: > Natürlich kann man auch mit dem halben Befehlssatz funktionierende > Programme schreiben. Yep. Moby sollte ich mal der Turing-Maschine widmen. Soweit ich weiss hat dafür noch nie jemand einen vollständigen C-Compiler geschrieben.
Moby A. schrieb: > Robert L. schrieb: >> das ist sinnlos, wir kenne doch schon alle seine Ausreden, warum >> er die ASM version dazu nicht abliefern würde... > > Nochmal ganz klar zum Mitschreiben: Ich liefere hier keine Lösungen > für weitere Aufgaben. Spart Euch die Ablenkungsmanöver und kreativen > Ausreden. Es gilt mein Beispiel zu toppen. Das hat Yalu bereits getan: Beitrag "Re: C versus Assembler->Performance" > Ich möchte ein fertiges Gegenbeispiel, daß ich selbst kompilieren und auf > Funktion testen kann. Das hast Du bekommen, siehe oben. Also spar' Dir die Ablenkungsmanöver und kreativen Ausreden, Du bist an der Reihe.
Gibt's eig. sowas wie eine Forenstatistik über die Bewertungen eines users? Würde mich im Fall Moby mal interessieren.
Moby A. schrieb: > Ich finde ja reichlich schwachsinnig, wie Du ohne Unterlaß [...] permanent > die gleichen dämlichen Unterstellungen machst... > Mit etwas mehr Horizont hättest Du längst erkannt, daß damit nichts > Konstruktives zu erreichen ist. Interessant, was du so von dir gibst. Vor allem diese äusserst konstruktive immer und immer wiederholte Behauptung, die du durch nichts, aber auch gar nichts, belegen kannst: Moby A. schrieb: > Die lassen Deinen fetten C-Code einfach zu schlecht aussehen Hast du überhaupt schon mal einen fetten C-Code gesehen? Bestimmt nicht. Hast du überhaupt schon mal einen hocheffizienten Assembler-Code gesehen? Ganz bestimmt auch nicht. Denn du hast noch nie einen fetten C-Code gesehen. mfg.
A. K. schrieb: > Yep. Moby sollte ich mal der Turing-Maschine widmen. Soweit ich weiss > hat dafür noch nie jemand einen vollständigen C-Compiler geschrieben. Wieso C und nicht TM? Mit GCC kann man inzwischen auch seinen eigenen avr-tm zimmern :-) https://gcc.gnu.org/onlinedocs/gcc-5.2.0/jit/
P. M. schrieb: > Kurz: Du bist wirklich nicht qualifiziert, in diesem Thread > mitzudiskutieren. Moby ist nicht qualifiziert in SEINEM Thread mitzudiskutieren ?
Michael K. schrieb: > Moby ist nicht qualifiziert in SEINEM Thread mitzudiskutieren ? Wo ist dein Problem? Ich könnte hier auch einen Thread über die Stringtheorie anzetteln ohne viel Ahnung davon haben zu müssen.
Johann L. schrieb: > Wieso C und nicht TM? Ich meinte, er solle sich der TM widmen, weil er da schon vorneweg keine Konkurrenz durch C befürchten muss.
Gu. F. schrieb: > Gibt's eig. sowas wie eine Forenstatistik über die Bewertungen eines > users? Würde mich im Fall Moby mal interessieren. Die Bewertungen werden überwiegend nach Sympathie gegeben. Hat mal jemand verschi**en werden alle seine Beiträge schlecht bewertet, auch die guten. Viele machen sich einen Sport daraus alles, wirklich alles von diesem User schlecht zu bewerten. Lächerlich, aber wenn es einem gut tut, bitteschön. Mich würde dann auch die Statistik interessieren wer hier wie viele schlechte Bewertungen gegeben hat und wie viele gute. Gu. F. schrieb: > Wo ist dein Problem? Hochnäsigkeit, ist z.B. ein Problem für mich. Jemanden pauschal die Kompetenz absprechen weil man selber per Definition und Titel automatisch besser ist, ist ein Problem für mich. Sich bevorzugt am basching zu beteiligen statt den Druck rauszunehmen und einen vernünftigen Ton anzuschlagen, ist ein Problem für mich. Persönlich zu werden wenn man mit seinen Argumenten nicht mehr weiterkommt ist ebenfalls ein Problem für mich. Schlechte Bewertungen oder jemanden auf die Füsse zu treten der das meiner Meinung nach verdient hat und das alles unter Klarnamen und für jederman nachvollziehbar: Überhaupt kein Problem für mich.
Michael K. schrieb: > Moby ist nicht qualifiziert in SEINEM Thread mitzudiskutieren ? Ja. Das ist doch auch kein Widerspruch. Du oder ich könnten auch einen Thread eröffnen, um über regelmässig auftretende Probleme der Hälfte der erwachsenen Weltbevölkerung zu diskutieren. Ob wir dazu auch nur einen einzigen konstruktiven Beitrag aus persönlicher Erfahrung beisteuern könnten, wage ich aber sehr zu bezweifeln. mfg.
Michael K. schrieb: > Ich bin bei Python gelandet und ich hasse es aus tiefstem Herzen. > Python + Tk wird laufend kaputtgeändert. Meine uralten Tk- und Tix-Programme laufen bis heute unverändert auf allen Python-Versionen < 3, so daß ich mich über solche Aussagen sehr wundere. Wenn man es schick haben will, benutzt man übrigens lieber Tix als Tk, und wenn es wirklich hübsch werden soll, Qt. Das hat auch den Vorteil, daß man sein Programm relativ leicht auf C++ portieren kann. Und wer modern sein will, baut heute keine Fat-Clients mit GUI mehr, sondern ein Webinterface mit -- zum Beispiel -- Flask. > Beispiele die unter Python 3.3 noch liefen versagen jetzt Ihren Dienst. Die einzige größere Änderung in den letzten Jahren war der Schritt von Python 2.x zu Python 3.x, aber auch diese Änderung ist von überschaubarem Umfang und erfordert, wenn man zuvor sauber programmiert hat, eher wenig Anpassung. Und weil das so überschaubar und einfach ist, kann das sogar automatisiert mit einem kleinen Skript geschehen, das mitgeliefert wird und "2to3.py" heißt. Die Unterschiede zwischen Python 2.x und Python 3.x betreffen meist eher fortgeschrittene und exotische Features, und sind in der Praxis ziemlich überschaubar. Einen guten Überblick über die Änderungen mit Codebeispielen findest Du hier: http://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html > Zudem kapier diesen objektorientieren Klassen udn > Vererbungs K*ck ehrlich gesagt nicht ganz. Das ist bei der Entwicklung von GUI-Software ein echtes Problem, das Du unbedingt angehen solltest, wenn Du so etwas öfter machen willst. Aber keine Sorge, an sich ist das gar nicht so schwer. > Ich habe mich mal bei einem studiertem Informatiker darüber ausgeheult > das ich Python nicht verstehe. Die Antwort war: 'Niemand versteht > Python' Wenn ein studierter Informatiker das nicht versteht, dann hat er seinen Beruf verfehlt -- ich habe schließlich nicht einmal Informatik studiert und, von Perl kommend, Python in knapp einer Woche verstanden. Tatsächlich ist Python nämlich sehr einfach und deswegen nicht nur bei Nicht-Informatikern, sondern auch für als erste Sprache für Grundschüler besonders beliebt. Vor allem in der Finanzwirtschaft wird besonderen Wert die Kontinuität und die Langzeitstabilität von Softwarelösungen gelegt, und auch da erfreut sich Python großer Beliebtheit. Vielleicht magst Du ja einen eigenen Thread aufmachen und dort über Deine Schwierigkeiten und Verständnisprobleme mit Python diskutieren. Es gibt hier außer mir sicher auch noch andere, die Dir dabei gerne helfen.
Thomas E. schrieb: > Du oder ich könnten auch einen Thread eröffnen, um über regelmässig > auftretende Probleme der Hälfte der erwachsenen Weltbevölkerung zu > diskutieren. Ob wir dazu auch nur einen einzigen konstruktiven Beitrag > aus persönlicher Erfahrung beisteuern könnten, wage ich aber sehr zu > bezweifeln. Zu unserem großen Glück hat Andreas hier ein Forum geschaffen in dem jeder diskutieren darf. Ich persönlich spreche ja einigen Teilnehmern die persönliche Kompetenz ab sich in einem öffentlichen Forum mit widersprüchlichen Meinungen und Ansichten auseinanderzusetzen. Die fachliche Kompetenz mag ja teilweise vorhanden sein, aber herje was da oft von sich gegeben wird da kann es einem schon grausen. Damit muß ich aber zurechtkommen, denn das sind die Regeln. Für die harten Fälle gibt es dann den Moderator der eingreift. Stell ich mich jetzt hin und sage: 'Du darfst hier jetzt mal die Klappe halten, denn Deine Fähigkeit wie ein Erwachsener verbal Probleme zu lösen und mit Konflikten umzugehen ist stark verbessererungswürdig' Nein, tue ich nicht, denn das steht mir nicht zu. Ich kann mein eigenes Forum aufmachen und da König spielen.
Gu. F. schrieb: > Gibt's eig. sowas wie eine Forenstatistik über die Bewertungen eines > users? Würde mich im Fall Moby mal interessieren. So gesehen halte ich es für sinnvoller, nicht +1 oder -1 eins beim Drücken der Bewertung zu rechnen, sondern direkt anzuzeigen, wie viele "lesenswert" und "nicht lesenswert" gedrückt haben. Thomas E. schrieb: > Moby A. schrieb: >> Die lassen Deinen fetten C-Code einfach zu schlecht aussehen Langsam glaube ich, Moby vergleicht den (compilierten) ASM-Code mit der Dateigrösse alle c/h-Files.
Sheeva P. schrieb: > Meine uralten Tk- und Tix-Programme laufen bis heute unverändert auf > allen Python-Versionen < 3, so daß ich mich über solche Aussagen sehr > wundere. Wie gesagt, ich weiß das ich ein absoluter Python Stümper bin. Die Problem die ich derzeit noch damit habe liegen mit Sicherheit an mir, aber ich verzeihe mir das, weil ich da ganz am Anfang stehe. Mit meinem kleinen Code habe ich so ziemlich das ganze Sprachkonzept vergewaltigt und das rächt sich nun. Ich kann ja nicht mal genau sagen ob meine Probleme am Python, am TK an PyCharm oder Anaconda liegen. Es sollte auch eher ein Bespiel dafür sein wie das Ergebniss einer sehr schlecht beherrschten Hochsprache trotzdem besser ist als alles was man ohne diese erreicht hätte. Ohne Frust und eine gewisse Verbissenheit lernt man nunmal nichts neues.
Moby A. schrieb: >> Es wird von allen Nutzbytes die Summe >> gebildet und die zwei LSB bits übertragen, richtig? > > Nein, alle 1er Bits werden schlicht gezählt und die zwei > niederwertigsten Bits der Summe dann drangehängt. Das wurde allerdings > erst später im Thread so geändert weil auf Hinweis von Yalu die einfache > Summe etwas witzlos ist. Zu finden später im Projektthread. Danke. Eigentlich wollte ich mich nicht durch den ellenlangen Thread durchkämpfen, aber jetzt sehe ich, dass dort Andere für dich die Anforderungsspezifikation erstellt und fortlaufend verfeinert haben. Es kommt in meinem Code eine triviale Checksummenfunktion hinzu, das macht das den C-Kohl auch nicht fett. Und ich habe jetzt noch den Fehler gesehen, dass ich die Bits in falscher Reihenfolge sende, das ist in der Senderoutine im Handumdrehen geändert. Hab die Änderungen eben ausprobiert - 2% mehr Flashverbrauch also jetzt 18% - ändert nichts an meinem Fazit. Über 80% der Ressourcen eines PIC12F675 liegen bei dieser trivialen Aufgabe brach - trotz C ;-)
Michael K. schrieb: > Jemanden pauschal die Kompetenz absprechen weil man selber per > Definition und Titel automatisch besser ist, ist ein Problem für mich. Du beziehst dich wohl auf mich und ein, zwei meiner Posts. Ich habe dort kein Wort von einem Titel geschrieben, ich habe einzig verlangt, man solle über einen entsprechenden Wissens-/Erfahrungsschatz verfügen - Studium, Berufserfahrung oder meinetwegen auch "nur"* Hobby. Der einzige, der immer wieder mit Titeln kommt, bist eigentlich du. Was die Frage sachlich/nicht sachlich angeht: Auf einer sachlichen Ebene ist der Thread schon längst erledigt. Wir sind uns ja alle einig, und Moby scheint weder fähig noch willens zu sein, unsere gefestigte Position zu widerlegen. Es geht nun wirklich nur noch darum, Moby klarzumachen, wie absurd (und teilweise unsportlich) er sich in dieser Diskussion verhält. ___ * "nur" deshalb, weil man in einem Hobby rein schon stundenmässig kaum so viel Erfahrung aufbauen kann, wie wenn man etwas Vollzeit betreibt.
>etwas Vollzeit betreibt,
nur kurz dazu: Vollzeit als Programmiere, ist oft nur ein "Fließband"
job..
und/oder auch oft sehr Spezialisiert auf irgend ein spezialgebiet..
als Hobby hat man dann doch oft sehr unterschiedliche "Gebiete"..
wer Informatik studiert, wird wohl kaum als Programmierer arbeiten,
sondern als Softwareentwickler(=architekt).. und Programmieren lassen..
:
Bearbeitet durch User
Witkatz :. schrieb: > Hab die Änderungen eben ausprobiert - 2% mehr Flashverbrauch also jetzt > 18% - ändert nichts an meinem Fazit. Über 80% der Ressourcen eines > PIC12F675 liegen bei dieser trivialen Aufgabe brach - trotz C ;-) Das ändert jetzt leider nichts daran, daß ich es nicht nachprüfen und mir keine weiteren Aussagen dazu erlauben kann. Aus meiner Erinnerung an PIC-Asm heraus wär ich allerdings auch schon längst auf C umgestiegen ;-) P. M. schrieb: > Moby scheint weder fähig noch willens zu sein, unsere gefestigte > Position zu widerlegen Sowas kann man sich auch einreden ;-) Du meintest doch kein "gefestigtes" C-Code Beispiel? Natürlich nicht irgend ein Brocken, sondern ein vollständiges, wirklich vergleichbares Programm? WO ist es ???
Moby A. schrieb: > P. M. schrieb: >> Moby scheint weder fähig noch willens zu sein, unsere gefestigte >> Position zu widerlegen > > Sowas kann man sich auch einreden ;-) > Du meintest doch kein "gefestigtes" C-Code Beispiel? > Natürlich nicht irgend ein Brocken, sondern ein vollständiges, wirklich > vergleichbares Programm? WO ist es ??? Na hier: Beitrag "Re: C versus Assembler->Performance"
Moby A. schrieb: > Du meintest doch kein "gefestigtes" C-Code Beispiel? > Natürlich nicht irgend ein Brocken, sondern ein vollständiges, wirklich > vergleichbares Programm? WO ist es ??? Hier ist es:
1 | void main(){ |
2 | |
3 | uint8_t threshold = 89; |
4 | |
5 | uint8_t value_ptr = 0; |
6 | uint8_t last_values[8] = {0, 0, 0, 0, 0, 0, 0, 0}; |
7 | |
8 | ADC_CONFIG |= (1 << ADC_ON); |
9 | UART_CONFIG = ...; // set some bits here |
10 | |
11 | |
12 | while(true){ |
13 | if(ADC_STATUS & (1 << ADC_HAS_NEW_VALUE)){ |
14 | |
15 | // save value into ringbuffer
|
16 | last_values[value_ptr] = ADC_VALUE; |
17 | |
18 | // increase ringbuffer pointer
|
19 | value_ptr ++; |
20 | value_ptr %= 8; |
21 | |
22 | // sum up values in ringbuffer
|
23 | uint16_t sum = 0; |
24 | for(uint8_t i = 0; i < 8; i ++){ |
25 | sum += last_values[i]; |
26 | }
|
27 | |
28 | // check if average in ringbuffer exceeds threshold
|
29 | // if yes, send over uart
|
30 | if(sum / 8 > threshold){ |
31 | UART_DATA = sum / 8; |
32 | UART_CONFIG |= (1 << UART_DO_SEND); |
33 | }
|
34 | |
35 | }
|
36 | }
|
37 | }
|
Ich brauchte in kryptischem, kompliziertem C etwa 5 Minuten, um das Beispiel aufzusetzen. Sollte in Assembler ja auch recht schnell gehen. Also zeig doch mal. Du kannst mit deinen Ansichten noch so recht haben, aber wenn du nichts zeigen kannst, dann wird dir niemand glauben.
Stefan K. schrieb: > Moby A. schrieb: >>> Er ist Hobbyprogrammierer und hat den ASM-Befehl EOR vor etwa 4 Jehren >>> kennengelernt: >> >> Erstmalig benötigt. Tatsächlich ist eben eine Teilmenge der >> AVR-Instruktionen zumeist ausreichend. Wußtest Du natürlich vorher. > > Natürlich kann man auch mit dem halben Befehlssatz funktionierende > Programme schreiben. Mit Effizienz hat das aber nichts mehr zu tun. Man kann sogar C-Programme schreiben, ohne Konstrukte zu verwenden, die man nicht versteht. So Regelsätze wie MISRA, wie auch immer man dazu steht, sind dazu da, Fehlerquellen durch Verbot zu eliminieren. Aber wenn ich z.B. in C++ Templates nicht verstehe, darf ich trotzdem die Vorzüge von überladenen Funktionen benutzen. (Aber nicht in dem Zusammenhang "überladen" absichtlich falsch verstehen wollen!)
Carl D. schrieb: > Man kann sogar C-Programme schreiben, ohne Konstrukte zu verwenden, die > man nicht versteht. So Regelsätze wie MISRA, wie auch immer man dazu > steht, sind dazu da, Fehlerquellen durch Verbot zu eliminieren. > Aber wenn ich z.B. in C++ Templates nicht verstehe, darf ich trotzdem > die Vorzüge von überladenen Funktionen benutzen. Ist IMHO genau der richtige Ansatz, wenn man sich einer Sprache noch nicht mächtig fühlt. Gerade C ist zu 90% "Assembler strukturiert in Syntax". Für die meisten Konstrukte kann man sich die Assembler-Umsetzung eins zu eins denken. C ist auch frei von jeglichen "Black-Box" Konzepten, deren Funktionsweise man erstmal kennen muss, wie z.B. virtuelle Vererbung oder Template Deduction und ihre ganzen Regeln in C++.
Zustimmung. Ich habs vor paar hunderten Beiträgen ja auch schon geschrieben: C ist so nah an der Hardware/ASM wie sonst keine Hochsprache (böse Zungen bezeichnen es nicht umsonst als Makroassembler). Deswegen versteh ich auch nicht wieso er sich C als Feindbild gesucht hat und nicht z.B. Java oder Python, wo man wirklich nicht mehr weiß was die Library/VM/Interpreter genau macht. Naja außer natürlich dass er mit Java und Python wahrscheinlich noch weniger Kontakt hatte als mit C, nämlich 0. Alles, aber wirklich alles spricht dafür, dass er sich das eigene Scheitern schönreden muss.
Carl D. schrieb: > Man kann sogar C-Programme schreiben, ohne Konstrukte zu verwenden, die > man nicht versteht. Den halben Befehlssatz nicht zu kennen ist aber was anderes als ihn nicht zu benutzen.
le x. schrieb: > Alles, aber wirklich alles spricht dafür, dass er sich das eigene > Scheitern schönreden muss. Das dürfte es wohl sein. Leider beobachtet man solche Threads im Forum immer wieder, des öfteren auch in "Ausbildung und Beruf", nicht nur von Moby.
Gu. F. schrieb: > Carl D. schrieb: >> Man kann sogar C-Programme schreiben, ohne Konstrukte zu verwenden, die >> man nicht versteht. > > Den halben Befehlssatz nicht zu kennen ist aber was anderes als ihn > nicht zu benutzen. Hatte ich auch nicht behauptet, oder? Ich wollte vielmehr die Diskrepanz zwischen M.'s Aussagen kommentieren, daß man nicht alle Befehle kennen muß, aber unbenutzte C-Konstrukte schwer auf des Programmieres Seele lasten.
:
Bearbeitet durch User
P. M. schrieb: > Hier ist es: Also wieder nix. Spar Dir diese Art Mühen. Warum scheuen bloß alle die Umsetzung meines bischen Funktionalität, einen schnellen reellen Vergleich, ein schnelles Ende jeglicher Diskussion hier wie der Teufel das Weihwasser ? P. M. schrieb: > Gerade C ist zu 90% "Assembler strukturiert in > Syntax". Für die meisten Konstrukte kann man sich die > Assembler-Umsetzung eins zu eins denken. C mag Asm zwar näher kommen als andere Hochsprachen, aber es ist eben nicht dasselbe ;-) le x. schrieb: > er sich C als Feindbild gesucht Blödsinn. C wurde mir aber hier zu oft als allumfassend überlegene Sprache angepriesen die es definitiv nicht ist. Ein Effizienz-Gegenbeispiel von mir steht zur Begutachtung bereit! le x. schrieb: > Alles, aber wirklich alles spricht dafür, dass er sich das eigene > Scheitern schönreden muss. Da kann ich ja nur lachen. Wirklich. Dafür arbeitet in meiner Umgebung schon zuvieles mit easy Asm... Geschmeidig, smart, effizient. Carl D. schrieb: > Ich wollte vielmehr die Diskrepanz zwischen M.'s Aussagen kommentieren, > daß man nicht alle Befehle kennen muß, aber unbenutzte C-Konstrukte > schwer auf des Programmieres Seele lasten. Kennen sollte man schon alle MC-Instruktionen, auch wenn längst nicht immer alle benötigt werden. Das ist kein Problem, denn der eigentliche Funktionsumfang einer Asm-Instruktion ist simpel. Auf der Seele des C-Programmierers lasten hingegen schon ein paar mehr beachtenswerter Dinge ;-)
:
Bearbeitet durch User
le x. schrieb: > Woher bringt dich denn eigentlich immer zu dieser Annahme, C-Code sei > fett? Mehr Bürokratie. Mehr Schreibbedarf. Mehr Ressourcenverbrauch. Code-Intransparenz, die zu noch mehr Ressourcenverbrauch führen kann. Entgegensteuern lässt sich wieder nur mit erhöhtem Lernaufwand... > Ich dachte deine einzige C-Erfahrung war ein mehr oder weniger > gescheitertes DOS-Programm (also x86). Da ist nichts gescheitert. Aber da ist mir ein Licht aufgegangen ;-) > Hast du dir davon das Assembler-Listing angeschaut und > Verbesserungspotential entdeckt? Nö. Ich hab zwar auch mal ein natives Asm-Programm für'n 486er geschrieben, mich aber in x86er Asm nicht sonderlich vertieft. Wir reden hier von AVR-Asm ! > Deine These mag sich auf Beiträgen von solch Gestalten wie unsren > c-hater, W.S. etc. stützen. Du bist mir auch so ne Gestalt. Wer bist Du, daß Du so über andere redest? Gerade die beiden leisten hier sehr fachlich fundierte Beiträge. Man muß nicht mit allem einer Meinung sein. Bin ich auch nicht. > Weils ins eigene Weltbild passt? Reden wir doch nicht gleich über Weltbilder! Es langt, ein C-Gegenbeispiel zu einer einfachen, fertigen Asm-Vorlage zu liefern!
Moby A. schrieb: > Also wieder nix. Spar Dir diese Art Mühen. > Warum scheuen bloß alle die Umsetzung meines bischen Funktionalität, > einen schnellen reellen Vergleich, ein schnelles Ende jeglicher > Diskussion hier wie der Teufel das Weihwasser ? Das ist doch schon geschehen: Beitrag "Re: C versus Assembler->Performance" > C wurde mir aber hier zu oft als allumfassend überlegene > Sprache angepriesen die es definitiv nicht ist. Du argumentierst gegen etwas, das außer Dir selbst nie jemand behauptet hat. Das nennt man ein Strohmann-Argument, Du kämpfst gegen Windmühlen. > Ein Effizienz-Gegenbeispiel von mir steht zur Begutachtung bereit! Für andere Menschen sind der von ihnen selbst zu betreibende Aufwand und vor allem die selbst aufzuwendende Lebens- und Arbeitszeit wesentlicher, wenn nicht sogar der wichtigste Faktor bei der Beurteilung von Effizienz. Du hingegen beschränkst diesen Begriff auf einen winzig kleinen, ja, den unwichtigsten Teil dessen, und beanspruchst damit eine Definitionshoheit, die Dir nicht zusteht -- und das alles nur, um zu dem Ergebnis zu kommen, welches Dir gerade in den Kram paßt. Da kann ich nur Arnold Vaatz zitieren: "Man vergewissere sich in dem Klassiker "Don Quichote" des 1616 gestorbenen spanischen Schriftstellers Miguel Cervantes der Unwiderlegbarkeit ideologischer Fixierungen durch gegenteilige empirische Erfahrung." In Verbindung mit Deinem Strohmann-Argument und Deinen fiesen Tricks ist diese Beanspruchung der Definitionshoheit zwar von einer bemerkenswerten Dreistigkeit, aber so offensichtlich und lächerlich, daß es schon wieder lustig ist. :-)
Robert L. schrieb: > hier könnte man übrigens gut belegen dass ein C-Compilter besser im > Routinen aussuchen ist als du, aber das willst ja eh nicht wissen.. Viele mathematische Asm- Funktionen, sollten sie wirklich mal gebraucht werden, hab ich aus verschiedenen Quellen im Netz bzw. Büchern und ich denke schon, aus der reichen Auswahl das beste ausgewählt zu haben. Das passt man für ein (m)ein einheitliches Registerschema an und gut ist. A. K. schrieb: > Moby A. schrieb: > Die lassen Deinen fetten C-Code einfach zu schlecht aussehen ;-) > > Diese Wahrnehmungsstörung ... Hey, hier gehts nicht um Wahrnehmung! Hier gehts um Fakten! Michael K. schrieb: > aber da könnte ich ein klein wenig besser > verstehen warum Du C kryptisch findest. Das kannst Du gut verstehen wenn Du Asm- Zeilen mit typischen C-Ausdrücken vergleichst ;-) > Andererseits sollte dann auch das AVR Datasheet eine echte Hürde für > Dich sein. Siehst Du. Ist es aber nicht. Ganz anders gehts mir übrigens mit ARM-Datenblättern, aber das hat einen anderen Hintergrund ;-) > Ja genau, und da war für mich nach dem ersten erfolgreich kompiliertem > 'HELLO WORLD' Program klar das ich mich mit C ganz wohlfühle. Tät mir zur Bestätigung nicht langen. Deshalb wars gleich ein Beispiel aus der Praxis mit echten Aufgaben. > Ja, Asche auf mein Haupt, ohne Informatik Studium bin ich natürlich > tatsächlich nicht in der Lage manche Konstruktionen zu verstehen die ein > Informatiker völlig selbstverständlich dahinzaubert. Genau. C-Ausdrücke können sogar ein Informatik-Studium voraussetzen. Asm nicht. Hast Du gut gesagt. > Klar, es gab eine gewisse Frustration bis ich das Zusammenspiel der C > toolchain verinnerlicht hatte. Konnte ich mir sparen ;-) > zum anderen muß ich > mich ohne C viel tiefer in die Internas der jeweiligen MCU einarbeiten > was im Endeffekt viel mehr Zeit kostet. Leute, die genaue Kenntnis der Interna ist aber gerade das was den Asm-Programmierer zu mehr Effizienz verhilft! Als Bastler der bei seiner Architektur bleiben kann ist das bei simplyAVR kein großes Hindernis. > Einer Lösung ist es aber egal ob noch 10 Bytes mehr frei sind im Ram > oder 100Bytes mehr im Flash. Das summiert sich bei größeren Sachen und kann dann schon den Controller eine Nummer größer erfordern. Und eine Lösung weiß auch nichts von jenen Erweiterungen, die zu ihrer Korrektur oder funktionellen Ergänzungen vielleicht einmal zukünftig erforderlich sind. Da möchte man nicht gleich die Hardware austauschen! > C war die erste Sprache die mich weit von der Hardware löst wenn ich das > will, mir aber wirklich alle Freiheiten läßt wenn ich es darauf anlege. Ja ok, Freiheiten in der Hardware-Auswahl. Die Hochsprache sorgt mit ihrer Ressourcen-Sorglosigkeit aber auch für die Notwendigkeit dieser Auswahl- sprich permanenter Aufrüstung. Schließlich läuft der Umstieg bei hardwarenahem C auch selten unproblematisch. > Für eine frisch entwickelte Hardware brauche ich ein steuerndes PC ... > Unter Windows und unter Linux. > Wie geil ist das denn ? Da freu ich mich für Dich aber wir reden hier von Asm vs. C bei MSR auf 8-Bittern. > Das motiviert mich weiterzumachen und mich in diese merkwürdige Sprache > hineinzuarbeiten die die Dinge auf eine mir völlig unverständliche Art > löst. Irgendwann wird der Groschen fallen Darauf hoffe ich nicht. Ich brauche Gewissheit. Schreibt man mal was in C und kennt Asm zum Vergleich, bekommt man die schnell. > Die Flinte ins Korn zu werfen und das alles blöd zu finden Finde ich nicht. Jeder Zweck hat seine geeigneten Mittel. > verurteilt mich dazu auf dem Level zu bleiben auf dem ich heute bin. Ich sehe mich nicht verurteilt. Ich sehe, daß ich mit Asm auf AVR die effiziente Programmiersprache schlechthin zur einfachsten Problemlösung habe. > Ich habe mich mal bei einem studiertem Informatiker darüber ausgeheult > das ich Python nicht verstehe. Die Antwort war: 'Niemand versteht > Python' > Das hat mir echt geholfen. Freut mich. Danke für den gutgemeinten psychologischen Beistand. Darauf war ich allerdings hier gar nicht aus ;-)
:
Bearbeitet durch User
Sheeva P. schrieb: > Für andere Menschen sind der von ihnen selbst zu betreibende Aufwand und > vor allem die selbst aufzuwendende Lebens- und Arbeitszeit wesentlicher, > wenn nicht sogar der wichtigste Faktor bei der Beurteilung von > Effizienz. Immerhin langte Deine Zeit um als einziger einen Gegenversuch in meinem dafür konzipierten Projekt zu wagen, der dann aber leider leider... na ja lassen wir das. Und sie langt für viele ellenlange Beiträge hier. In der Zeit wär Dein Gegenversuch längst fertig. Wenn auch nicht am Ziel ;-) Karl H. schrieb: > Du hast so viel von dir gegeben, dass ich schon längst den Überblick > verloren habe, was du gesagt hast und was nicht. Da kannst Du mal sehen. Das ist Einsatz. Zuweilen sollte man für eigene Beiträge wissen was schon zur Sprache kam. Das kann ich Dir freilich nicht vorwerfen wenn ich Dein Vollzeit-Engagement im Forum betrachte. Stefan K. schrieb: > Natürlich kann man auch mit dem halben Befehlssatz funktionierende > Programme schreiben. Mit Effizienz hat das aber nichts mehr zu tun. Unfug. Man sollte aber alle Instruktionen im Hinterkopf behalten um ggf. nicht auf Effizienz zu verzichten. Yalu X. schrieb: > Mal angenommen, es gelänge tatsächlich niemandem, dein Programm in C > kürzer (auf den Binärcode bezogen) zu schreiben. Was hättest du damit > bewiesen? > > Dass ein ca. 200 Byte großes Programm in Assembler möglicherweise kürzer > ist, wenn man in stundenlanger Kleinarbeit jeden einzelnen Befehl so > lange dreht und wendet, bis man auch das letzte überflüssige Byte > wegoptimiert hat. Das trieft wieder nur so von Unterstellungen. Das Prinzip, welches diesem Programm zugrundeliegt ist ein universell verwendbares. Da war nicht viel dabei. > Wie ich aber früher schon geschrieben habe, interessiert das außer dir > kein Huhn auch nur im Allergeringsten, da der ATtiny13 die fünffache > Menge Flash-Speicher hat. Deswegen (und wegen deiner ziemlich volatilen > Anforderungen an den Programmcode) ist kaum jemand sonderlich motiviert, > Arbeit in die Umsetzung in ein C-Programm zu inverstieren. Viele "Hühner" interessiert aber hier mir "Einzugackern", daß C alles soviel einfacher und effizienter macht. Bei soviel Expertentum hier sollte die Umsetzung der Funktionalität ein Leichtes sein. Die Anforderungen sind ja nun weitgehend simplifiziert. > Dein Argument, dass der Code ja vielleicht irgendwann erweitert werden > soll, zieht überhaupt nicht. Denn sobald die Code in Richtung 1 KB geht, > wirst auch du ihn nicht mehr mit der gleichen Intensität handoptimieren, > da der Aufwand dafür mindestens quadratisch mit der Codergröße steigt. Was redest Du da. Übung, Vorbereitung, System sag ich da nur! > Hier wird i.Allg. ein C-Programm größenmäßig gleich gut oder besser, bei > der Entwicklungszeit sogar sehr viel besser abschneiden. Das passt dann womöglich nicht mehr hinein. Dann sind wir gleich wieder bei der Notwendigkeit der Hardware-Aufrüstung. Wenn aber die I/O Ausstattung der Platine sonst langt ist das (wahrscheinlich nur für mich ;-) schwer einzusehen. > "Bei Programmen bis ca. 200 Bytes hat die Assembler-Programmierung > keine großen Nachteile, aber auch kaum Vorteile." > > stimme ich (und sicher auch viele andere Diskutanten) dir auch ohne > Wettbewerb zu, und wir können die Diskussion beenden. So lautet sie aber nicht. > Wenn du aber behauptest: > "Assembler bringt auch bei größeren Programmen Vorteile, solange > darin keine Arithmetik mit mehr als 8 Bit stattfindet." Quatsch. Mal doch nicht so schwarz/weiß. Da darf ohne weiteres auch mal 16-Bit (und selten höhere Arithmetik) vorkommen. Aber nochmal: Viele Berechnungen sind eine Kontraindikation für Asm und möglicherweise auch für AVR Verwendung. > steht die Aussage eines > einzelnen Assembler-Only-Programmierers gegen diejenige von zig Leuten, > die Erfahrung in Assembler und C haben. Die bloße Betonung von "Erfahrung" zieht bei mir nicht. P. M. schrieb: > Kurz: Du bist wirklich nicht qualifiziert, in diesem Thread > mitzudiskutieren. Das wirst Du mir nicht verbieten, zumal Dir das > richtig Fakten zu liefern mangels C-Gegenbeispiel nicht gelingt ;-) Michael K. schrieb: > Ohne Frust und eine gewisse Verbissenheit lernt man nunmal nichts neues. Da mag was dran sein. Allerdings ist gerade die absolute Einsteigerphase sehr empfindlich für die Intuition, ob etwas konstruktiv vereinfacht oder unnötig verkompliziert, wenn man Wissen um andere Methoden zuvor schon aufgebaut hat. Da sollte man dann schon ein gewisses Feuer fangen... Mein erstes C-Programm hab ich jedenfalls mit Frust und Verbissenheit zu Ende und Funktion gebracht: Mit der bekannten Erkenntnis.
Hatte eigentlich hier schon jemand eine Erklärung für den Asm-Aufwärtstrend lt. Tiobe-Studie? Ich meine natürlich ohne das Ergebnis selbst in Frage zu stellen !
Moby A. schrieb: > Hatte eigentlich hier schon jemand eine Erklärung für den > Asm-Aufwärtstrend lt. Tiobe-Studie? Wenn man C mal kann muss man eben nicht mehr rumsuchen. Bei Assembler ist das anders, daher fallen die Suchanfragen nach C etc., was zu einem relativen Anstieg für Assembler führt.
Johann L. schrieb: > Wenn man C mal kann muss man eben nicht mehr rumsuchen. Schon mal einen Blick in diverse C-Hilfethreads geworfen ? Wie schauts mit den Suchen nach der passenden Funktion mit der richtigen Aufruf-Syntax in/und einer verwendbaren Library aus? Das allein sollte doch die Suchanfragen schon kräftig treiben. Der ASMler schreibt sich das passende ja meist selbst. Insofern würde ich das schon als steigendes Interesse an Asm deuten. Bei Tiobe heißt es auch ausdrücklich "The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors."
:
Bearbeitet durch User
Moby A. schrieb: > Hatte eigentlich hier schon jemand eine Erklärung für den > Asm-Aufwärtstrend lt. Tiobe-Studie? Ich meine natürlich ohne das > Ergebnis selbst in Frage zu stellen ! Ja ganz am Anfang des Threads hatte ich ja eine Möglichkeit beschrieben: Ein gesteigertes Interesse am Reverse-Engineering und Modifizieren/Häcken von Binärcode. Besonders mit dem ganzen IoT Zeugs wird das ja immer interessanter. Also auch im Zusammenhang von Pentesting usw. Das KÖNNTE einer von MEHREREN Gründen sein. Fallen die noch weitere Möglichkeiten ein?
Moby A. schrieb: > Das summiert sich bei größeren Sachen und kann dann schon den Controller > eine Nummer größer erfordern. Eben nicht, das ist ja der Witz dran. Je größer das Projekt desto mehr kann der Compiler den Hand-Assemblierer übertreffen. Und bei kleinen Projekten ists wurscht.
Moby A. schrieb: > Ich meine natürlich ohne das Ergebnis selbst in Frage zu stellen ! Warum willst du den nicht in Frage stellen? Weil dir's dann nicht mehr in den Kram passt? Es gibt noch zwei, drei andere Beliebtheits-Indizes, die völlig andere Ergebnisse bringen als Tiobe (u. a. taucht dann Assembler gleich gar nicth auf …). Aber selbst für Tiobe, was sollen Schwankungen schon aussagen, wenn der Gesamtwert im unteren einstelligen Prozentbereich liegt? „auf dem Weg nach vorn“ ganz sicher nicht. Das ist doch eher der berühmte Sack Reis, der in China umgefallen ist.
Mit dem Aufwand, dem Einsatz und der Zeit, die für diesen sinnfreien Thread augewändet wurde, hatte man ein richtig gutes Projekt in Hard und Software, Asssembler und/oder C auf die Beine stellen können... Es wäre eine Bereicherung für dieses Forum geworden.
Moby A. schrieb: > Bei Tiobe heißt es auch ausdrücklich > > "The TIOBE Programming Community index is an indicator of the popularity > of programming languages. The index is updated once a month. The ratings > are based on the number of skilled engineers world-wide, courses and > third party vendors." Schon mal daran gedacht von was die wohl leben? Die Bräuchen Clicks! Und wenn sie ein anderes Verfahren benutzen würden, z.B. Umfragen in echten Projekten, dann wäre das extra Arbeit. Mit echtem Personal! So graßen sie Suchmaschinen-API's ab und kommen zu verblüffen blödsinnigen Erkenntnissen. Und ihre Interpretatöre sind kaum besser: C hat viele Anfragen, weil C so kompliziert ist. ASM hat wenig Anfragen, weil ASM-Programmierer allles selber können. Ach! Auch wenn man manchmal den Eindruck hat, daß M. alle nur verarschen will, in Summe hat er vermutlich schlicht nicht alle Kaffeebecher aufgeräumt.
Moby A. schrieb: > Yalu X. schrieb: >> Mal angenommen, es gelänge tatsächlich niemandem, dein Programm in C >> kürzer (auf den Binärcode bezogen) zu schreiben. Was hättest du damit >> bewiesen? >> >> Dass ein ca. 200 Byte großes Programm in Assembler möglicherweise kürzer >> ist, wenn man in stundenlanger Kleinarbeit jeden einzelnen Befehl so >> lange dreht und wendet, bis man auch das letzte überflüssige Byte >> wegoptimiert hat. > > Das trieft wieder nur so von Unterstellungen. Wo habe ich dir da was unterstellt? Moby A. schrieb: >> "Bei Programmen bis ca. 200 Bytes hat die Assembler-Programmierung >> keine großen Nachteile, aber auch kaum Vorteile." >> >> stimme ich (und sicher auch viele andere Diskutanten) dir auch ohne >> Wettbewerb zu, und wir können die Diskussion beenden. > > So lautet sie aber nicht. > >> Wenn du aber behauptest: >> "Assembler bringt auch bei größeren Programmen Vorteile, solange >> darin keine Arithmetik mit mehr als 8 Bit stattfindet." > > Quatsch. > Mal doch nicht so schwarz/weiß. Da darf ohne weiteres auch mal > 16-Bit (und selten höhere Arithmetik) vorkommen. Die Einschränkung auf 8-Bit-Arithmetik habe ich zu deinen Gunsten angehängt. Ohne diese wäre die Aussage erst recht falsch. Aber mach doch mal, um solche Missverständnisse auszuschalten, eine klare Aussage darüber, für welche Sorte von Programmen du Assembler im Vorteil siehst. Dann nehmen wir einfach ein Beispiel eines solchen Programms und diskutieren darüber weiter. Bis jetzt steht als Beispiel – und damit als Diskussionsgrundlage – ein 200-Byte-Programm im Raum, einer Codegröße, bei der es einfach überflüssig ist, über die Vor- und Nachteile von Assembler und C zu diskutieren. Wenn es um größere Programme geht: Einmal behauptest du, dass auch dort Assembler bessr sei. Ein anderes Mal gibst du zu, dass für größere Programme C die richtige Sprache ist. Wieder ein anderes Mal ist Assembler auch für größere Programme gut, aber mit der Einschränkung, dass keine komplizierte Arithmetik erforderlich ist (die natürlich in C überhaupt nicht kompliziert wäre). Ja, was denn nun? Mach doch mal klare Aussagen, dann brauchst du dich hinterher nicht zu beschweren, wenn wir dich falsch verstanden haben. Moby A. schrieb: >> Dein Argument, dass der Code ja vielleicht irgendwann erweitert werden >> soll, zieht überhaupt nicht. Denn sobald die Code in Richtung 1 KB geht, >> wirst auch du ihn nicht mehr mit der gleichen Intensität handoptimieren, >> da der Aufwand dafür mindestens quadratisch mit der Codergröße steigt. > > Was redest Du da. Übung, Vorbereitung, System sag ich da nur! Und nur, weil du in C keine Übung hast, ist C auch für alle anderen schlecht? Komische Logik. Moby A. schrieb: >> Hier wird i.Allg. ein C-Programm größenmäßig gleich gut oder besser, bei >> der Entwicklungszeit sogar sehr viel besser abschneiden. > > Das passt dann womöglich nicht mehr hinein. Dann sind wir gleich wieder > bei der Notwendigkeit der Hardware-Aufrüstung. Wenn aber die I/O > Ausstattung der Platine sonst langt ist das (wahrscheinlich nur für mich > ;-) schwer einzusehen. Naja, also zwischen den 200 Bytes deines Programms und den 1024 Bytes eines ATtiny13 ist ja ein so großer Unterschied, dass da auch ohne Hardwareaufrüstung noch einiges geht. Wenn das trotzdem nicht reicht, gibt es ja auch noch den ATtiny85, den man ohne Änderung der Platine als Ersatz für den ATtiny13 einsetzen kann. Darin hat ein Programm sogar 40mal Platz. Moby A. schrieb: > Hatte eigentlich hier schon jemand eine Erklärung für den > Asm-Aufwärtstrend lt. Tiobe-Studie? Ja, ich habe inzwischen herausgefunden, woher der Sprung kommt. Die Erklärung kommt demnächst. Nur so viel vorab: Mit IoT hat das nichts zu tun, auch nicht mit Mikrocontrollern. Ich hoffe, du wirst nicht zu sehr enttäuscht sein :) Es gibt jetzt übrigens den Index für Dezember, allerdings gehen die Tiobe-Leute in ihrem Kommentar wieder nicht auf das Thema Assembler ein. Wundert dich das nicht?
Carl D. schrieb: > C hat viele Anfragen, weil C so kompliziert ist. > ASM hat wenig Anfragen, weil ASM-Programmierer allles selber können. > > Ach! Wenn man das überträgt, kann man sich in diesem Forum umsehen und sagen: AVRs haben viele Anfragen, weil die Dinger so kompliziert sind. STM32er haben wenig Anfragen, weil es ein Genuss ist, sie zu programmieren. Wobei die STM32er auch langsam komplizierter zu werden scheinen, weil es immer mehr Anfragen diesbezüglich gibt. Was macht ST da bloß? ;-)
Moby A. schrieb: > Also wieder nix. Spar Dir diese Art Mühen. > Warum scheuen bloß alle die Umsetzung meines bischen Funktionalität, > einen schnellen reellen Vergleich, ein schnelles Ende jeglicher > Diskussion hier wie der Teufel das Weihwasser ? Du verdrehst Tatsachen: Die anderen haben geliefert. Du nicht. Du bist jetzt der, der an der Reihe ist, C-Code effizient in Assembler umzusetzen. Dein Herumdrücken sehe ich aber als Eingeständnis, dass du es nicht kannst ;-) Denn Zeit für den Thread hast du ja offensichtlich genügend. Moby A. schrieb: > Mehr Bürokratie. > Mehr Schreibbedarf. > Mehr Ressourcenverbrauch. > Code-Intransparenz, die zu noch mehr Ressourcenverbrauch führen kann. > Entgegensteuern lässt sich wieder nur mit erhöhtem Lernaufwand... Du behauptest, behauptest, behauptest. Jeder dieser Punkte wurde bereits besprochen und widerlegt. Zeig bitte mal für jede deiner Behauptungen ein Beispiel.
P. M. schrieb: > Dein Herumdrücken sehe ich aber als Eingeständnis, dass du es nicht > kannst ;-) Denn Zeit für den Thread hast du ja offensichtlich genügend. Las ihn einfach. Meinst Du, Du kannst ihn zu einem Einlenken bewegen? Mehr als ein ;-) am Satzende wirst Du nicht bekommen. Narzisstische Soziopathen sind so.
Yalu X. schrieb: > Bis jetzt steht als Beispiel – und damit als Diskussionsgrundlage – ein > 200-Byte-Programm im Raum, einer Codegröße, bei der es einfach > überflüssig ist, über die Vor- und Nachteile von Assembler und C zu > diskutieren. Eben. Und deshalb mache ich folgenden Vorschlag: Wir geben Moby Recht, dass ASM bei 200 Byte Codegröße unschlagbar ist. Damit hat dann Moby in seinem Mikrokosmos Recht und der Wahnsinn hört hier auf. Gleichzeitig stellen wir die These auf: Ab 1KB Codegröße ist ASM mit C IMMER schlagbar Wenn Moby mit dieser Regelung nicht einverstanden ist, soll er den Gegenbeweis erbringen. Ich schlage daher einen Programmierwettbewerb für eine typische 8-Bit-Anwendung vor, die dann in der Praxis auch mehr als 1KB Codegröße braucht. Daran können sich ASM- und C-Programmierer beteiligen. Es gewinnt dasjenige Programm, welches in der Summe Flash + Static-Ram-Data den wenigsten Speicherplatz verbraucht. Wie können hier demokratisch abstimmen: Wer dafür ist, gibt diesem Beitrag ein + Wer dagegen ist, gibt diesem Beitrag ein - Ich wünsche schon jetzt allen Beteiligten viel Spaß!
Eddy C. schrieb: > Las ihn einfach. Meinst Du, Du kannst ihn zu einem Einlenken bewegen? Ich denke nicht, nein. Immerhin soll so seine Strategie nicht aufgehen, unangenehme Fragen einfach auszusitzen und mit immer neuen Behauptungen abzulenken.
Frank M. schrieb: > Wer dafür ist, gibt diesem Beitrag ein + Von mir ein +. Allerdings bin ich mit dem Bewertungskriterium: Frank M. schrieb: > Es > gewinnt dasjenige Programm, welches in der Summe Flash + Static-Ram-Data > den wenigsten Speicherplatz verbraucht. ... nicht ganz einverstanden. Es gibt wohl kaum ein Projekt, wo plus minus 30% Flash/RAM eine Rolle spielt. Pro Entwicklerstunde kriegt man locker 100 8-Bitter mit verdoppeltem Speicher. Und das spielt auch nur dann eine Rolle, wenn wir im Bereich von 99%-130% des Speicherverbrauchs des kleineren Controllers sind. Also die einzigen Projekte, wo man jemals "quetschen" würde, sind sehr grosse Stückzahlen, wo das Programm genau eine kritische Grösse erreicht.
:
Bearbeitet durch User
P. M. schrieb: > ... nicht ganz einverstanden. Prinzipiell hast Du natürlich Recht. Aber ich bin bereit, wenigstens auf dieses Moby'sche Argument, was natürlich nicht realitätsnah ist, einzugehen. Oder mache bitte einen anderen Vorschlag für ein objektiv bewertbares Kriterium. Ich finde als Kriterium den Speicherplatz nicht schlecht. Nimm einfach für diesen Wettbewerb an, es würden 100 Millionen der Anwendung verkauft werden und es gäbe dafür die Möglichkeit, einen speziellen AVR herzustellen, der genau auf die Codegröße her optimiert wäre - wobei jede weitere Speicherzelle in der Summe viele hunderttausend Euro (für diese 100 Mio Chips) kosten würde. Dann tritt die Entwicklerzeit in den Hintergrund.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Oder mache bitte einen anderen Vorschlag für ein objektiv bewertbares > Kriterium. Die Erweiterbarkeit sollte IMHO noch gemessen werden. Sobald die Programme fertig sind, kommt noch eine kleine/mittlere Zusatzaufgabe dazu. Beim C-Beispiel wird ja der ADC-Wert gelesen, geglättet und ab einem Schwellenwert per UART gesendet. Das könnte z.B. eine Überwachungsschaltung für ein Gerät sein, die zunächst einfach nur kritische Werte protokolliert. Als nächstes könnte es nun wünscheswert sein, diesen kritischen Wert auch per UART setzen zu können. Als weitere Entwicklungsstufe könnte man dann verlangen, dass ein "kritischer" und ein "gefährlicher" Schwellenwert verwendet werden, wobei beim gefährlichen Schwellenwert eine Schutzschaltung/Sirene/LED aktiviert werden soll, die für eine bestimmte Zeitdauer aktiv ist.
Frank M. schrieb: > Wie willst Du die "messen"? Eben - mit einer Erweiterung, die erst nach Abgabe des ersten Codes beschlossen wird. Kann man z.B. daran messen, wie viel der Code dann wächst oder um wie viele Prozent der alte Code geändert werden musste. Ganz präzise messen kann man es natürlich nicht, aber es dürfte schon eine Hausnummer dabei rauskommen.
Frank M. schrieb: > Aber ich bin bereit, wenigstens auf dieses Moby'sche Argument, > was natürlich nicht realitätsnah ist, einzugehen. Wieso geht überhaupt noch jemand auf Moby ein? Hört Ihr nicht, wie er sich ins Fäustchen lacht, wie er Euch weiter in den Bann zieht und kontrolliert mit seiner theoretisch möglichen Meinung? Gelassenheit ist die Devise und einfach - räusper - nichts mehr schreiben. P. M. schrieb: > Eben - mit einer Erweiterung, die erst nach Abgabe des ersten Codes > beschlossen wird. Kann man z.B. daran messen, wie viel der Code dann > wächst oder um wie viele Prozent der alte Code geändert werden musste. > Ganz präzise messen kann man es natürlich nicht, aber es dürfte schon > eine Hausnummer dabei rauskommen. Lächerlich.
Eddy C. schrieb: > P. M. schrieb: >> Eben - mit einer Erweiterung, die erst nach Abgabe des ersten Codes >> beschlossen wird. Kann man z.B. daran messen, wie viel der Code dann >> wächst oder um wie viele Prozent der alte Code geändert werden musste. >> Ganz präzise messen kann man es natürlich nicht, aber es dürfte schon >> eine Hausnummer dabei rauskommen. > > Lächerlich. Soso. Aber ein konkreter Kritikpunkt oder ein anderer Vorschlag kommt natürlich nicht. Wenn du nicht mitdiskutieren willst, dann lass es, ansonsten sei konstruktiv und bringe Inhalt. Solche Umgangsformen deinerseits sind "lächerlich".
P. M. schrieb: > Aber ein konkreter Kritikpunkt oder ein anderer Vorschlag kommt > natürlich nicht. Das ist doch gerade der Witz! Wobei ich auch schon erfolglos meinen Senf beigesteuert habe .-)
Eddy C. schrieb: > Gelassenheit ist die Devise und einfach - räusper - nichts mehr > schreiben. 100% Ack. War auch die einzig richtige Antwort auf KB
:
Bearbeitet durch User
Johannes O. schrieb: > Das KÖNNTE einer von MEHREREN Gründen sein. Mehr Bedeutung von Asm zum Hacken, Reengineering, Produktnachbau? Richtig. Für sowas ist Asm ja auch sehr nützlich ;-) Jörg W. schrieb: > was sollen Schwankungen schon aussagen, wenn der > Gesamtwert im unteren einstelligen Prozentbereich liegt? „auf dem Weg > nach vorn“ ganz sicher nicht. Das ist doch eher der berühmte Sack Reis, > der in China umgefallen ist. Immerhin ist dieser Trend neu ... Auf Geringfügigkeit hin wegzudiskutieren ist sowas meiner Meinung nach nicht. Wolfgang R. schrieb: > Mit dem Aufwand, dem Einsatz und der Zeit, die für diesen > sinnfreien Thread augewändet wurde "Sinnfrei" ist blanke Überheblichkeit gegenüber allen Diskussionsteilnehmern. Auch ich lerne was, wenn auch weniger über C vs. Asm, als vielmehr über die tausend Wege, seinen Diskussionspartner zu diskreditieren und tausend andere windige Argumente. Das muß aber jetzt nicht überraschen, wenn man so wie ich gegen den Trend bürstet. Vielleicht regt es aber zum Nachdenken an ;-)
Eddy C. schrieb: > Gelassenheit ist die Devise und einfach - räusper - nichts mehr > schreiben. Die Diskussion war streckenweise sehr unterhaltsam. Aber es ist dabei wie beim Boxen. Der Sandsack ist zwar ein miserabler Boxer, hält aber stets länger durch.
:
Bearbeitet durch User
Carl D. schrieb: > Schon mal daran gedacht von was die wohl leben? Die Bräuchen Clicks! Ach. Es sollte denen doch egal sein, welche konkrete Sprachen vorne bzw. auf steigender Trendlinie liegen! Du meinst doch nicht etwa, Tiobe ist ein geheimer Asm-Förderverein? ;-) Yalu X. schrieb: > Wo habe ich dir da was unterstellt? Was ich da in stundenlanger Kleinarbeit täte natürlich. Wenn etwas in stundenlanger Arbeit ausarten kann dann ist das einen PAP oder einen Algorithmus zu erstellen, oder es ist Fehlersuche. Beides nix typisches für Asm... > klare Aussage darüber, für welche Sorte von Programmen du Assembler im > Vorteil siehst. Oft genug geschehen. Aber für Dich nochmal: MSR auf 8-Bit Controllern ohne große Berechnungen und ohne große Datenmengen. Also Millionen Anwendungen. > Dann nehmen wir einfach ein Beispiel eines solchen > Programms und diskutieren darüber weiter. Dann darf ich gleich wieder zur Lektüre meines fix und fertigen Programmbeispiels bitten. Ein hardwareoptimierter Asm-Leckerbissen ;-) > bei der es einfach > überflüssig ist, über die Vor- und Nachteile von Assembler und C zu > diskutieren. Ganz und gar nicht denn es ist just gerade ein von Dir gefordertes Beispiel für MSR-Anwendungen obiger Definition. > Wenn es um größere Programme geht: Einmal behauptest du, dass auch dort > Assembler bessr sei. Ein anderes Mal gibst du zu, dass für größere > Programme C die richtige Sprache ist. Wieder ein anderes Mal ist > Assembler auch für größere Programme gut, aber mit der Einschränkung, > dass keine komplizierte Arithmetik erforderlich ist (die natürlich in C > überhaupt nicht kompliziert wäre). > > Ja, was denn nun? Ja was denn nun! Das hängt von Fall zu Fall ab. Überrascht Dich das? Es wäre vielleicht sinnvoll, Du würdest den vorteilhaften Asm-Einsatzfall nach obiger tausendfach wiederholter Definition schlicht mal zur Kenntnis nehmen. > Und nur, weil du in C keine Übung hast, ist C auch für alle anderen > schlecht? Komische Logik. Du legst mir schon wieder Dinge in den Mund die ich nie behauptet habe. Komische Logik. Nein, eher unredliche Logik. C ist nicht schlecht, aber für viele Situationen (siehe Definition oben) die schlechtere Lösung da sprachtechnisch unnötiger Aufwand. Was ist daran bloß so schwer zu kapieren??? > Naja, also zwischen den 200 Bytes deines Programms und den 1024 Bytes > eines ATtiny13 ist ja ein so großer Unterschied, dass da auch ohne > Hardwareaufrüstung noch einiges geht. Wenn das trotzdem nicht reicht, > gibt es ja auch noch den ATtiny85 Tja siehst Du, darin unterscheiden wir uns. Ich schreie nicht hochsprachenverschwendertypisch gleich nach größerer Hardware, sondern möchte erstmal das vorhandene bestmöglich nutzen. > Ja, ich habe inzwischen herausgefunden, woher der Sprung kommt. Die > Erklärung kommt demnächst. Nur so viel vorab: Mit IoT hat das nichts zu > tun, auch nicht mit Mikrocontrollern. Ich hoffe, du wirst nicht zu sehr > enttäuscht sein :) Da bin ich aber gespannt. Und nein, ich werde keinesfalls enttäuscht sein da sich damit die mir offenkundigen Vorteile von Asm sicher nicht in Luft auflösen ;-)
Chris D. schrieb: > AVRs haben viele Anfragen, weil die Dinger so kompliziert sind. > STM32er haben wenig Anfragen, weil es ein Genuss ist, sie zu > programmieren. Klasse! Es würde mich bald nicht mehr überraschen wenn das hier auch noch mit dem Brustton der Überzeugung verkündet würde ;-) P. M. schrieb: > Du verdrehst Tatsachen: Die anderen haben geliefert. Du nicht. Du bist > jetzt der, der an der Reihe ist, C-Code effizient in Assembler > umzusetzen. Wie war doch gleich nochmal das Stichwort? Tatsachen verdrehen? :-) > Du behauptest, behauptest, behauptest. Was ich behaupte habe ich mit einem Asm Beispiel belegt. Du bist (als C-Profi?) nicht in der Lage, es kürzer und für mich nachprüfbar in C umzusetzen ;-)
Frank M. schrieb: > Ab 1KB Codegröße ist ASM mit C IMMER schlagbar Das halte ich für falsch. Und wir wollen gleich nochmal klarstellen, daß nichts als der Ressourcen-Verbrauch gemeint ist. Bei größeren Sachen fällt dann gerne noch mehr Speed durch Asm an- sprich, man kann mit der Taktfrequenz weiter runtergehen. Mal so am Rande. > Wenn Moby mit dieser Regelung nicht einverstanden ist, soll er den > Gegenbeweis erbringen. Wenn ich mal ein forumtauglichen Code dieser Länge erstelle gerne. Was die wieder zu erwartende Diskussionszerredung dann ergibt kann ich allerdings schon ahnen ;-) > Ich schlage daher einen Programmierwettbewerb ...vor Leider ist dieses schöne Forum jetzt kein Fulltime-Job und Programmierung kein blanker Zeitvertreib für mich. Es muß dann schon eine Lösung sein die viele und auch ich gebrauchen können. Dürfte schwierig werden.
P. M. schrieb: > Frank M. schrieb: > Oder mache bitte einen anderen Vorschlag für ein objektiv bewertbares > Kriterium. > > Die Erweiterbarkeit sollte IMHO noch gemessen werden. Sobald die > Programme fertig sind, kommt noch eine kleine/mittlere Zusatzaufgabe > dazu. Das wirst Du doch nicht etwa als objektiv bewertbares Kriterium betrachten? Meine Herren, ich möchte hier nochmal die Selbstverständlichkeit betonen, daß man auch in Asm sehr hardwareflexibel (I/O Erweiterungsfähigkeit, im Rahmen der bestehenden Architektur natürlich) programmieren kann. Allerdings ist das dann etwas anderes als hochoptimierter Code und man gäbe damit einen zentralen Asm-Vorteil aus der Hand!
Moby A. schrieb: > P. M. schrieb: >> Die Erweiterbarkeit sollte IMHO noch gemessen werden. Sobald die >> Programme fertig sind, kommt noch eine kleine/mittlere Zusatzaufgabe >> dazu. > > Das wirst Du doch nicht etwa als objektiv bewertbares Kriterium > betrachten? Hier muss ich Moby zustimmen. Dass eine Partei in so einem "Wettbewerb" die Aufgabe stellt macht den Wettbewerb fur Farce — unabhängig davon ob es um C vs. ASM geht oder was anderes. Mal abgesehen davon sind die Parteien noch nichtmal über die Bewertungskriterien einig.
Angehängte Dateien:
-
assembler1.png
39 KB -
assembler2.png
23 KB
Hier ist der meiner Meinung nach hautsächliche Grund für den Sprung des Tiobe-Index für Assembler zwischen Juni (0,754%) und Juli 2015 (1,535%): http://board.flatassembler.net/topic.php?t=18023 Dort schlug John vor, als Suchbegriff für die Ermittlung des Index
1 | +"assembly language programming" |
anstelle von
1 | +"assembly programming" |
zu verwenden, weil "assembly" in Verbindung mit "language" mehr Treffer liefert. John sandte eine diesbezüglich eine E-Mail-Anfrage an Tiobe. Diese wurde von Paul beantwortet mit der Zusicherung, er werde den vorgeschlagenen neuen Suchbegriff mit Wirkung ab Mai 2015 zum bestehenden hinzuzufügen. Diesen Information habe ich schon vor ca. einem Monat gefunden, als Moby den "Assembler wieder auf dem Weg nach vorn"-Thread startete. Ich hielt sie damals aber nicht für relevant, da der Sprung ja nicht im Mai, sondern erst zwei Monate Später im Juli stattfand. Als ich heute auf die erneute Anfrage Mobys hin noch einmal etwas rumgegoogelt habe, bin ich auf eine Erklärung dieser Diskrepanz gestoßen. Sie liegt in diesem Spreadsheet auf Google-Docs: https://docs.google.com/spreadsheets/d/1xleffl2fzvcwLFafDaNN0SvqYQ8OiIBu4_-AFThw4Zo/pubhtml?gid=370149219&single=true Da hat jemand sämtliche Tiobe-Daten ab September 2014 zusammengetragen. Die Einträge für Assembler heißen bis einschließlich Mai 2015 "Assembly" und ab Juni 2015 "Assembly language". Johns Vorschlag ist also von Paul nicht wie angekündigt im Mai, sondern erst im Juni umgesetzt worden. Vermutlich hat er die Änderung zwar vor der Veröffentlichung des Juni-Index vorgenommen, aber erst, nachdem die automatische Suchmaschinenabfrage für Juni bereits durchgelaufen war, aber. Das bedeutet, dass die Zahlenwerte für Juni noch nach dem alten System ermittelt wurden, bei der Veröffentlichung auf der Tiobe-Webseite aber bereits der neue Name verwendet wurde. Erst im Juli-Index wurde der neue Suchbegriff auch zahlenmäßig wirksam. Da +"assembly language programming" deutlich mehr Treffer liefert als +"assembly programming", ist der Index für Assembler entsprechend nach oben geschossen. Der Sprung im Juli von 0,754% auf 1,535% entspricht einem Faktor von 2,04. Um zu ermitteln, wieviel von diesem Anstieg durch die Änderung der Suchbegriffe verursacht wurde, müsste man für sämtliche von Tiobe genutzten Suchmaschinen die jeweiligen Trefferzahlen vom Juli kennen, was im Nachhinein natürlich nicht mehr möglich ist. Im Moment liegen die Trefferzahlen für die beiden Suchbegriffe bei google.com, google.de und google.co.in bei 216000 (alt) und 379000 (neu), was einem Faktor von 1,75 entspricht und recht nahe bei den 2,04 liegt. Allerdings sind die von Google angezeigten Trefferzahlen nur grobe Schätzungen, zudem ändern sie sich manchmal innerhalb von ein paar Stunden sehr stark. So lagen bspw. heute Nachmittag die Trefferzahlen bei google.co.in bei 216000 (alt) und 518000 (neu). Das ist ein Faktor von 2,40. Der Mittelwert von 1,75 und 2,40 ist 2,08 und würde den Sprung vollständig erklären. Wenn man jetzt einmal als grobe Schätzung (für eine bessere Schätzung fehlen einfach die Informationen) annimmt, dass die Erweiterung der Suchbegriffe tatsächlich einen Faktor vom 2,08 im Ergebnis bewirken, kann man die Werte im Tiobe-Index von vor Juli 2015 rückwirkend mit diesem Faktor multiplizieren und erhält dann eine Schätzung dafür, wie die Werte ausgefallen wären, wenn diese Suchbegriffe von Anfang an verwendet worden wären. Das Ergebnis ist in assembler1.png zu sehen. Man könnte aber genauso die Werte ab dem Juli 2015 durch 2,08 dividieren und erhält damit den geschätzten Kurvenverlauf für den Fall, dass keine Änderung der Suchbegriffe vorgenommen worden wäre (assembler2.png). In beiden Fällen ist aber der Sprung, auf den Moby so sehr abgefahren ist, verschwunden. Es bleibt ein leichter Anstieg der Kurve seit März 2015, aber der bewegt sich in derselben Größenordnung wie die sonstigen Schwankungen. Vielleicht ist dieser leichte Anstieg auf die Befehlssatzerweiterungen der neuen PC-Prozessoren zurückzuführen, denn jedesmal, wenn eine solche Erweiterung angekündigt wird, entsteht eine Diskussion darüber, ob sie vom Compiler XY bereits unterstützt wird, oder ob sie nur bei der Assemblerprogrammierung nutzbar sind. Dieser durchaus plausible Gedanke stammt von hier (zweiter Beitrag): http://www.0x10cforum.com/forum/post/last/m/4932880/viewthread/4782416-assembly-language-has-risen-into-first-20-languages-tiobe-index Es gibt sicher noch jede Menge weiterer Erklärungen für den leichten Anstieg. Nur der plötzliche Sprung um den Faktor 2 innerhalb eines Monats können sie nicht erklären, weswegen die Gründe woanders gesucht werden mussten. Fazit: Der Sprung hat weder etwas mit IoT noch mit Mobys explodierendem Eifer bei der Assemblerprogrammierung seines ATtiny13 zu tun, sondern ist im Tiobe-eigenen "Messverfahren" begründet. Für diese These spricht auch, dass von Tiobe seit nunmehr 6 Ausgaben des Index kein Kommentar zu dieser Anomalie abgegeben wurde. Leider sind wir damit in der Frage, ob Assembler oder C, wieder exakt so weit wie am Ende des früheren Moby-Threads Beitrag "Kleines Tiny13 Sensorboard" vor zwei Monaten. Der neue, inzwischen über 1100 Beiträge umfassende Thread hier ist also größtenteils für die Katz. Bei der Blockadehaltung von Moby glaube ich auch nicht, dass die Diskussion in den nächsten zwei Monaten (oder auch Jahren ;-)) auch nur einen Millimeter voranschreitet. Vielleicht sollten wir stattdessen unsere Zeit wieder verstärkt dazu nutzen, gute C- und Assemblerprogramme (jeder wie ihm beliebt) zu schreiben :)
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Vielleicht sollten wir stattdessen unsere Zeit wieder verstärkt dazu > nutzen, gute C- und Assemblerprogramme (jeder wie ihm beliebt) zu > schreiben :) Auch wenn's Dich überrascht: Das sehe ich fazitär prinzipiell genauso. Was wohin millimeterweise voranschreitet werden wir ja sehen, spätestens mit der nächsten Asm-Pressemeldung ;-) Danke für die Recherche zu Deiner These.
Moby A. schrieb: > Wie war doch gleich nochmal das Stichwort? > Tatsachen verdrehen? :-) > >> Du behauptest, behauptest, behauptest. > > Was ich behaupte habe ich mit einem Asm Beispiel belegt. Du bist (als > C-Profi?) nicht in der Lage, es kürzer und für mich nachprüfbar in C > umzusetzen ;-) Ja genau, Tatsachen verdrehen: Du verlangst plötzlich, dass ein Assembler-Beispiel kürzer in C umgesetzt wird. Dabei hat nie jemand behauptet, mit C würde man auch kleinste Assembler-Projekte speichermässig schlagen. Die These war schon immer, dass man mit Assembler keine Chance hat gegen höhere Programmiersprachen, sobald die Projekte auch nur etwas grösser werden. Und dass man selbst bei Kleinst-Projekten mit C nie merklich schlechter fährt. Das ist Konsens und das wurde auch mit C-Umsetzungen deiner Projekte belegt. DU hast dann behauptet, das stimme nicht, aber du kannst es nicht belegen.
Moby A. schrieb: > Frank M. schrieb: >> Ab 1KB Codegröße ist ASM mit C IMMER schlagbar > > Das halte ich für falsch. Und wir wollen gleich nochmal klarstellen, > daß nichts als der Ressourcen-Verbrauch gemeint ist. Genau dafür hast Du keinen Beleg. > Bei größeren Sachen > fällt dann gerne noch mehr Speed durch Asm an- sprich, man kann mit der > Taktfrequenz weiter runtergehen. Mal so am Rande. Dafür hast Du ebenso keinen Beleg. Nix als Schwafeln... Du hast nur ein 200-Byte-Programm und willst damit die Welt erklären. Aber so läuft das nicht.
Frank M. schrieb: > Moby A. schrieb: >> Bei größeren Sachen >> fällt dann gerne noch mehr Speed durch Asm an- sprich, man kann mit der >> Taktfrequenz weiter runtergehen. Mal so am Rande. > > Dafür hast Du ebenso keinen Beleg. Nix als Schwafeln... > > Du hast nur ein 200-Byte-Programm und willst damit die Welt erklären. > Aber so läuft das nicht. Zumal laut Datenblatt sich bei halber Taktfrequenz nicht etwa der halbe Stromverbrauch ergibt, sondern etwas mehr. Nur die Rechengeschwindigkeit wird halbiert. Der Energieverbrauch je Befehl steigt aber an. Es ist also besser, schnell etwas auszurechnen und dann schlafen zu gehen, als gemütlich vor sich hin zu bummeln. Oder man benutzt diesen Mehrverbrauch der Moby-Lösung um die "großen Schwächen" des Compilers auszugleichen. Man kommt also den gleichen Stromverbrauch mit weniger Programmierzeit. Wenn man C mental gewachsen ist. (mal sehen, wie der M. hier wieder Zitatfragmente rauspickt. Manche kenn ich jetzt schon)
Moby A. schrieb: > Bei größeren Sachen > fällt dann gerne noch mehr Speed durch Asm an- sprich, man kann mit der > Taktfrequenz weiter runtergehen. Mal so am Rande. Das ist ja genau falsch. Bei grösseren Sachen kann der Compiler über Bereiche hinweg optimieren, wo ein Mensch niemals mehr den Überblick behalten kann. Beispiel: Registerallokation (https://de.wikipedia.org/wiki/Registerzuteilung). Ist NP-vollständig. Sobald also dutzende oder hunderte Variablen in deinem Programm existieren, hast du als Mensch keine Chance mehr, eine bessere Zuweisung zu finden als es der Compiler kann. Sinngemäss gilt das dann auch für Caches. Und bei modernen Rechnern spielt die Musik nunmal im Bereich der Speicherbandbreite und nicht beim Abzählen von Taktzyklen.
:
Bearbeitet durch User
Moby A. schrieb: > Mehr Bürokratie. Das kann ich nur bestätigen. Ich hatte vor 5 Wochen einen Antrag auf Genehmigung zur Erstellung eines C-Programms zum Blinken einer LED gestellt. Dieser wurde vor 3 Wochen wegen zu hohem RAM-Verbrauch abgelehnt. Gleich am nächsten Tag habe ich einen neuen Antrag gestellt, in dem ich diesen Mangel abgestellt habe. Jetzt warte ich schon wieder seit 2 Wochen. Moby A. schrieb: > Mehr Schreibbedarf. Volle Zustimmung. Siehe oben. Moby A. schrieb: > Mehr Ressourcenverbrauch. Daran scheitern auchdie meisten C-Projekte. Das wird statistisch nur nicht erfasst, da sie schon im Vorwege wegen nicht erteilter Genehmigungen scheitern und somit noch nicht als Projekte gelten. Moby A. schrieb: > Code-Intransparenz, die zu noch mehr Ressourcenverbrauch führen kann. Da sprichst du genau den neuralgischen Punkt an. Die Genehmigungsverfahren dauern auch deswegen so lange, da die Sachbearbeiter den kryptischen Code einfach nicht verstehen. Das wird dann wieder versucht durch Vereinfachungen, die mehr Resourcen verschwenden, auszugleichen. Moby A. schrieb: > Entgegensteuern lässt sich wieder nur mit erhöhtem Lernaufwand... Das wird leider nur teilweise getan. Es gibt jede Menge Schulungen für die Sachbearbeiter in den Genehmigungsstellen. Diese werden allerdings zumeist von den Abteilungsleitern belegt, die das erlernte Wissen schon auf dem Weg nach Hause wieder vergessen und es somit nicht an die Sachbearbeiter weitergeben können. C-Programmierung ist, unter allen diesen Aspekten betrachtet, vollkommen sinnlos. Der ganze Hype um diese vollkommen nutzlose Programmiersprache lässt sich meines Erachtens nur dadurch erklären, dass diese Sprache irgendwann einmal in Mode gekommen ist und fast alle Programmierer dieser Mode einfach nur, ohne darüber nachzudenken, hinterher laufen. Da aber eine ganze Industrie mit ihren Lobbyisten dahinter steht, wird sich daran leider nichts ändern. Diese beschäftigen auch Heerscharen von Leuten, die immer wieder Begründungen für den Sinn und die Überlegenheit von Hochsprachen im Allgemeinen und C im Besonderen an den Haaren herbeiziehen. Insbesondere in China ist dabei eine völlig neue Industrie entstanden: Es gab massenhaft Chinesen, die sich alte chinesische Sprichwörter ausdachten, um sich damit ihren kargen Lebensunterhalt zu verdienen. Diese Leute haben den Begründungsbedarf erkannt und arbeiten jetzt alle als Erfinder von fadenscheinigen Begründungen für die Überlegenheit von sinnlosen Hochsprachen. Mit diesen Billigargumenten überschwemmen sie die Märkte in Westeuropa, Japan und den USA. Das ist natürlich etwas, wo die EU einschreiten muss. Hohe Zölle für die fadenscheinigen Begründungen aus China wären das Mindeste. Ein Verbot sämtlicher Hochsprachen, womit man dieser chinesischen Invasion gänzlich das Wasser abdrehen würde, aber das Erstrebenswerte. Leider steht aber eine mächtige Lobby dieser Vernunft entgegen. Ebenso haben die Franzosen schon Widerspruch angekündigt, da sie ihre Sprache auch als Hochsprache unter allen anderen Sprachen empfinden, befürchten sie, dass Französich gleich mit verboten wird. Schliesslich macht die EU, wenn sie schon etwas macht, es ohne Ausnahme gründlich. Daher werden wir uns leider diesem Diktat weiter beugen müssen, mit billigen Chinaimportargumenten alles schön reden und Freischärlern wie Mobin Hood neidvoll hinterher blicken. mfg.
P. M. schrieb: > Ja genau, Tatsachen verdrehen: Du verlangst plötzlich, dass ein > Assembler-Beispiel kürzer in C umgesetzt wird. Ich verlange nichts und schon gar nichts plötzlich. Wer freilich die bessere Effizienz von Asm anzweifelt soll das doch an meinem kleinen Beispiel belegen, für welches ich in Vorleistung gegangen bin. Wenn Du das nun nicht behauptest dann ist ja gut. Frank M. schrieb: > Genau dafür hast Du keinen Beleg. Dafür argumentiere ich aber, ausgehend von meinem Beispiel. Außer verschiedensten Gegenaussagen gab es auch keinen Gegenbeleg. Hattest Du nicht deshalb einen realen Vergleich angeregt ? > Du hast nur ein 200-Byte-Programm und willst damit die Welt erklären. Ich erkläre nicht die Welt, sondern die Verhältnisse bei 8-Bit MSR ohne große Berechnungen und Datenmengen.
Carl D. schrieb: > Zumal laut Datenblatt sich bei halber Taktfrequenz nicht etwa der halbe > Stromverbrauch ergibt, sondern etwas mehr. Nur die Rechengeschwindigkeit > wird halbiert. Der Energieverbrauch je Befehl steigt aber an. Es ist > also besser, schnell etwas auszurechnen und dann schlafen zu gehen, als > gemütlich vor sich hin zu bummeln. Die Reduzierung der Taktfrequenz spart in jedem Fall. Die Nutzung der Sleep-Modi ist unabhängig davon anzuraten. Deshalb lasse ich gern das Hauptprogramm im Sleep-Modus und überlasse die Funktionalität den Interrupts. P. M. schrieb: > Bei grösseren Sachen kann der Compiler über > Bereiche hinweg optimieren, wo ein Mensch niemals mehr den Überblick > behalten kann. Bei größere Berechnungen und Datenmengen. Mein überlegtes, fixes Registerzuordnungssystem ersetzt irgendwelche zu optimierenden Zuordnungen. Übung, Vorbereitung und System hebeln praktisch bis zu einem gewissen Grad irgendwelche Compiler Zuweisungsoptimierungs- Notwendigkeiten aus. > Sinngemäss gilt das dann auch für > Caches. > Und bei modernen Rechnern spielt die Musik nunmal im Bereich der > Speicherbandbreite und nicht beim Abzählen von Taktzyklen. Um die gehts hier aber nicht. @Thomas Eckmann Nette Story. Leider am Thema vorbei.
:
Bearbeitet durch User
Moby A. schrieb: > Die Reduzierung der Taktfrequenz spart in jedem Fall. Nein, nicht in jedem Fall. Da der Stromverbrauch von Mobilgeräten längst ein entscheidendes Thema ist, gibt es auch entsprechende Untersuchungen. Die je nach Randbedingungen(!) zum Ergebnis kommen, dass es effizienter sein kann, kurz aber heftig zu verbrauchen als langsam kriechend wenig. Oder irgendwas zwischendrin. Das liegt auch daran, dass in Chiptechnik jenseits der AVRs nicht nur Umschaltvorgänge zum Verbrauch beitragen, sondern ebenso Leckströme. Und die lassen sich am einfachsten durch partielle Totalabschaltung der Versorgung reduzieren. > Mein überlegtes, fixes Registerzuordnungssystem ersetzt irgendwelche zu > optimierenden Zuordnungen. Eben. Mit dynamische Zuweisungen je nach lokalem Bedarf tun sich Compiler leichter als Programmierer. Wenn die Anzahl Register für statische Zuweisung ausreicht spielt das keine Rolle. Jenseits davon jedoch schon.
:
Bearbeitet durch User
A. K. schrieb: > Das liegt auch daran, dass in Chiptechnik jenseits der AVRs nicht nur > Umschaltvorgänge zum Verbrauch beitragen, sondern ebenso Leckströme. Siehst du auch schon bei den AVRs mit kleineren Strukturen, insbesondere bei etwas höheren Spannungen. Die 3,3-V-Verbrauchskurve eines XmegaA3 kommt ohne Takt schon auf fast 100 µA raus statt nahe 0.
Jörg W. schrieb: > A. K. schrieb: >> Das liegt auch daran, dass in Chiptechnik jenseits der AVRs nicht nur >> Umschaltvorgänge zum Verbrauch beitragen, sondern ebenso Leckströme. > > Siehst du auch schon bei den AVRs mit kleineren Strukturen, insbesondere > bei etwas höheren Spannungen. Die 3,3-V-Verbrauchskurve eines XmegaA3 > kommt ohne Takt schon auf fast 100 µA raus statt nahe 0. Das mit dem Takt/Stromaufnahme war nur ein kleiner Trick von mir, M. ein weiteres Mal zu entlocken, wie weit seine Kenntnisse tatsächlich reichen. Dabei steht das alles in seinem Geliebten Datenblatt. Man muß die Diagramme nur lesen können. Falls es daran Zweifel gibt: Ich hab kein Problem damit, daß jemand was nicht weiß, denn das kann jedem passieren. Nur darf man sich dann nicht als Guru präsentieren.
:
Bearbeitet durch User
A. K. schrieb: > Wenn die Anzahl Register für > statische Zuweisung ausreicht spielt das keine Rolle. Genau so ist es! > Moby A. schrieb: > Die Reduzierung der Taktfrequenz spart in jedem Fall. > > Nein, nicht in jedem Fall. Bei einem gegebenen Controller spart die Reduzierung der Frequenz immer. Carl D. schrieb: > Das mit dem Takt/Stromaufnahme war nur ein kleiner Trick von mir, M. ein > weiteres Mal zu entlocken Du hast mir gar nichts entlockt. Von Dir aber hätte ich fast angenommen, Du empfielst den 4 Ghz Pentium4 als besonderen Stromsparer ;-)
:
Bearbeitet durch User
P. M. schrieb: > Ja genau, Tatsachen verdrehen: Du verlangst plötzlich, dass ein > Assembler-Beispiel kürzer in C umgesetzt wird. Dabei hat nie jemand > behauptet, mit C würde man auch kleinste Assembler-Projekte > speichermässig schlagen. Zumal er sich, wenn man sein "Projekt" mal etwas genauer ansieht, die größtmögliche Mühe gegeben hat, es dem C-Compiler so schwer wie irgend möglich zu machen. Das beweist, daß es ihm nicht gar um einen fairen Vergleich, sondern stattdessen nur um eine Bestätigung seiner kruden Behauptungen geht. Das wird auch durch sein penetrantes Insistieren in diesem Thread einmal mehr bewiesen. Daß mit seinen mühsam Gestrickten ohnehin keine Aussagen über C, sondern allenfalls über den Optimizer des Compilers getroffen werden könnten, ist ihm deswegen auch egal -- und aus demselben Grund hat er, als mein Code kleiner aussah, urplötzlich hektisch neue Anforderungen erfunden. Obwohl er sich vorher ja tagelang zu fein war, sich auf Anforderungen festzulegen und diese sauber auszuformulieren: als er die Möglichkeit dazu hatte, hat er lieber den Schwanz eingekniffen. War aber auch schon doof: da hat er sich extra was zusammengebastelt, nur um seine Überlegenheit zu zeigen, und dann kommt so ein Dahergelaufener und liefert etwas ab, das auf den ersten Blick kleiner aussieht als sein Assembler-Code. Dabei hatte der Arme sich doch so viel Mühe gegeben und anstelle eines üblichen Standardprotokolls eigens ein selbstgefrickeltes 24-Bit-Gerümpel mit kaputter Checksumme abgeliefert. Allein das beweist, daß sein Code im Gegensatz zu seinen Behauptungen noch niemals produktiv genutzt worden sein kann, denn dabei hätte der Fehler auffallen müssen. Dabei war die Sache eigentlich schon gelaufen. Moby hatte seinen Versuch bereits gehabt und ihn grandios vergeigt. Yalu hat in C etwas präsentiert das in jeder nur denkbaren Hinsicht besser war als Mobys Code, vor allem nach Mobys eigenen Kriterien: Beitrag "Re: C versus Assembler->Performance" Es ist daher jeder Versuch überflüssig, über Mobys neues Stöckchen mit seinem "Kleinen Tiny13 Sensorboard" zu springen: selbst wenn sich jemand die Mühe machen und eine bessere C-Implementierung abliefern würde, dann würde er nur dasselbe tun wie gehabt: neue Anforderungen oder ein neues "Projekt" mit nochmals elaborierteren Stolpersteinchen für den Compiler erfinden. Aber nachdem er ja bereits gegen Yalus Code verloren hat, ist jetzt ohnehin erstmal er an der Reihe, seine wirren und inkonsistenten Behauptungen zu belegen -- etwa gegen Deinen Code. Das wird er aber leider gar nicht erst versuchen, denn dabei würde sehr wahrscheinlich herauskommen, daß er es nicht schafft. ;-)
Moby A. schrieb: > Wer freilich die bessere Effizienz von Asm anzweifelt soll das doch an > meinem kleinen Beispiel belegen, für welches ich in Vorleistung > gegangen bin. Das hat Yalu bereits getan: Beitrag "Re: C versus Assembler->Performance" Jetzt bist Du an der Reihe, den Gegenbeweis zu erbringen und Deine Behauptungen zu belegen.
@ Sheeva P. Das hast Du Dir wie immer alles schön zusammenkonstruiert. Da gibts für mich nichts mehr zu kommentieren. Ich weiß ja, daß Du irgendwie von Deiner gescheiterten Nachbildung meines Codes ablenken mußt. Scheinbar hast Du auch nach vielen solchen sich wiederholenden Beiträgen immer noch das Gefühl, daß es nicht langt ;-) Besonders amüsant fand ich dann aber doch > nochmals elaborierteren Stolpersteinchen für den Compiler > erfinden Mensch Junge, wann wirst Du endlich begreifen, daß man da nix erfinden muß?
Moby A. schrieb: > Bei einem gegebenen Controller spart die Reduzierung der Frequenz immer. Nicht, wenn man zwischen „dauernd mit geringem Takt durchwerkeln“ und „mit schnellem Takt alles abklappern, dann schlafen legen“ entscheiden kann. Dann ist letzteres oft (aber eben auch nicht immer) effektiver.
Jörg W. schrieb: > Moby A. schrieb: > Bei einem gegebenen Controller spart die Reduzierung der Frequenz immer. > > Nicht, wenn man zwischen „dauernd mit geringem Takt durchwerkeln“ und > „mit schnellem Takt alles abklappern, dann schlafen legen“ entscheiden > kann. Dann ist letzteres oft (aber eben auch nicht immer) effektiver. Na logo! Wenn man Sleep-Modi einsetzen kann tut man das natürlich und spart noch mehr! Das ändert aber nichts dran daß man mit reduzierter Frequenz defacto immer Energie spart- solange natürlich die Erfüllung der gestellten Aufgabe gewährleistet ist.
Moby A. schrieb: > >> Moby A. schrieb: >> Die Reduzierung der Taktfrequenz spart in jedem Fall. >> >> Nein, nicht in jedem Fall. > > Bei einem gegebenen Controller spart die Reduzierung der Frequenz > immer. > wieder etwas das du einfach so behauptest, und ja, wir wissen es, jemand anderer soll es widerlegen?? wie kommst du auf das? wer schneller rechnet kann länger schlafen.. du senkst den Takt aber soweit ab, dass überhaupt (fast) nie geschlafen wird trotzdem: >Die Nutzung der Sleep-Modi ist unabhängig davon anzuraten. Deshalb lasse >ich gern das Hauptprogramm im Sleep-Modus und überlasse die >Funktionalität den Interrupts. das passt doch sowieso nicht zusammen..
:
Bearbeitet durch User
Moby A. schrieb: > Das ändert aber nichts dran daß man mit reduzierter Frequenz defacto > immer Energie spart Nein, tut es nicht. Aber du begreifst es nicht (oder willst es nicht begreifen), also lassen wir's einfach. Endlosschleifen hatten wir schon genug.
Robert L. schrieb: > wieder etwas das du einfach so behauptest, und ja, wir wissen es, jemand > anderer soll es widerlegen?? Doch, das ist schon richtig. Aber es ist wie bei seinem Assemblerzeugs: er dreht es so hin, wie er es braucht. Ein x-beliebiger Controller mit niedrigerer Taktfrequenz braucht weniger Strom als mit hoher Frequenz. Dem kann man nicht widersprechen. Wir sind nur schon einen Schritt weiter. wir wissen, dass das nicht linear runtergeht. Wir wissen, dass es effektivere Möglichkeiten gibt. Ginge er darauf ein, würde er eingestehen, dass sein optimales Projektchen nicht nur, sondern auch an dieser Stelle nicht optimal ist. Das wird er natürlich weder sich eingestehen, noch wird er es gar zugeben. Deshalb wird er es natürlich jemand anderes widerlegen müssen. Und nach 1000 Beiträgen sind wir keinen Schritt weiter gekommen. mfg.
:
Bearbeitet durch User
Wir sind hier zwar beim Thema Assembler, aber Robert L. schrieb: > Bei einem gegebenen Controller spart die Reduzierung der Frequenz immer. > wieder etwas das du einfach so behauptest, und ja, wir wissen es, jemand > anderer soll es widerlegen?? Das muß niemand widerlegen, denn es stimmt. > wer schneller rechnet kann länger schlafen.. 1. sofern dieses "ereignisgesteuerte" Modell in der konkreten App überhaupt anwendbar ist und 2. die möglichen Sleep-Phasen relativ lang sind und 3. die spezifischen Controller-Hardware Eigenschaften das unterstützen kann das ein Spezial-Fall sein, Ok. Aber das ist von irgend einer Regelhaftigkeit entfernt, wie auch Jörg W.s > Dann ist letzteres oft (aber eben auch nicht immer) effektiver. nahelegt.
Thomas E. schrieb: > Deshalb wird er es natürlich jemand anderes widerlegen müssen. Und nach > 1000 Beiträgen sind wir keinen Schritt weiter gekommen. Das kann ja viele Gründe haben ;-) > Ginge er darauf ein, würde er eingestehen, dass sein optimales > Projektchen nicht nur, sondern auch an dieser Stelle nicht optimal ist. Natürlich ließe sich das leicht bewerkstelligen: Im Hauptprogramm noch ein Sleep und gut ist. Nur zielte mein Projekt jetzt nicht speziell aufs Stromsparen, auch wenn es mit nur 128kHz intern gut darauf vorbereitet ist. Das Hauptprogramm sollte zunächst mal übersichtlicher Ansatzpunkt für Erweiterungen sein.
Wie oft wollt ihr dem Troll noch Futter vor die Füße werfen? Lasst diesen Wal verhungern und gut ist's ....
Gu. F. schrieb: > Wie oft wollt ihr dem Troll noch Futter vor die Füße werfen? > Lasst diesen Wal verhungern und gut ist's .... ja. Moby A. schrieb: > Deshalb lasse ich gern das Hauptprogramm im Sleep-Modus und überlasse die > Funktionalität den Interrupts. Moby A. schrieb: > sofern dieses "ereignisgesteuerte" Modell in der konkreten App > überhaupt anwendbar ist [...] kann das ein Spezial-Fall sein, Ok. Aber das > ist von irgend einer Regelhaftigkeit entfernt Rolle rückwärts und voll auf die Fresse geflogen! mfg.
Ralf G. schrieb: > Thomas E. schrieb: > Seht ihr. > > Ja! Ich tät ja gern endlich endlich mal Beweise für die allumfassende C-Überlegenheit sehen ;-)
Thomas E. schrieb: > voll auf die Fresse geflogen ... ist viel eher die Aussage: Dreht die Taktfrequenz nur genügend auf, umso schneller kann geschlafen werden und umso mehr Energie wird gespart. So ein Mist, warum bringen meine Tinys nur 20 MHz ;-)
Moby A. schrieb: > Natürlich ließe sich das leicht bewerkstelligen: Im Hauptprogramm noch > ein Sleep und gut ist. Nur zielte mein Projekt jetzt nicht speziell aufs > Stromsparen, auch wenn es mit nur 128kHz intern gut darauf vorbereitet > ist. Das Hauptprogramm sollte zunächst mal übersichtlicher Ansatzpunkt > für Erweiterungen sein. Sehr geehrter Herr Moby, in ihrem Beispielprojekt, welches hier als Referenz für ihre Argumentation herangezogen wird, befindet sich allerdings ein Sleep. Sollten sie etwa den Überblick über ihre Kommunikationsstrategie, die mich sehr an das erinnert, was man in Forenbeiträgen allgemein Trollbeiträge nennt? Das ist natürlich nur meine persönliche, subjektive Wahrnehmung und soll keinesfalls einen persönlichen Angriff ihnen gegenüber darstellen, noch soll es die Meinung anderer Forumsteilnehmer widergeben. mfg.
Ralf G. schrieb: > Wenn schon, dann Herr AVR Ich dachte das wäre sein akademischer Grad. Auf die amerikanische Weise dem Namen nachgestellt und er nur resourcensparend, wo immer es geht, das Komma weggelassen hat. mfg.
Thomas E. schrieb: > befindet sich allerdings ein Sleep. Schön, daß das nochmal klargestellt wurde. Da bin ich aber jetzt echt froh ;-) Allerdings ändert Dein Kampf auf dem Nebenkriegsschauplatz "Energiesparen" jetzt nichts an der Überlegenheit von Asm im beschriebenen Einsatzgebiet. Was Kommunikationsstrategien anbetrifft, nun, da ist die Welt hier recht bunt und auch ich habe da eine gewisse persönliche, subjektive Wahrnehmung, die ich aber keinesfalls über andere stellen würde! Konnte ich Deinen Beitrag adäquat beantworten?
Thomas E. schrieb: > Sehr geehrter Herr Moby, Na also, geht doch. ;-) > Sollten sie etwa den Überblick über ihre Kommunikationsstrategie, die > mich sehr an das erinnert, was man in Forenbeiträgen allgemein > Trollbeiträge nennt? Hier allerdings hast zunächst du den Überblick über die Kommunikation verloren, nämlich den über die Grammatik. ;-)
:
Bearbeitet durch User
Thomas E. schrieb: > Sollten sie etwa den Überblick über ihre Kommunikationsstrategie, die > mich sehr an das erinnert, was man in Forenbeiträgen allgemein > Trollbeiträge nennt? Ohje. Da habe ich doch tatsächlich in meinem mimosenkonformen Satz ein "verloren haben" vergessen. Richtig heissen muss es natürlich: Sollten sie etwa den Überblick über ihre Kommunikationsstrategie, die mich sehr an das erinnert, was man in Forenbeiträgen allgemein Trollbeiträge nennt, verloren haben? Ich bitte, diese Nachlässigkeit zu entschuldigen. mfg.
Thomas E. schrieb: > Ohje. Da habe ich doch tatsächlich in meinem mimosenkonformen Satz ein > "verloren haben" vergessen. Yep, und das in ein paar Zeilen. Und da wirfst du Moby vor, den Überblick in den weit über 1000 Beiträgen des Threads verloren zu haben, wovon wohl eine dreistellige Zahl von ihm sind? Sein AVR hat nur 32 Register. Dann ist Schluss. Mehr lässt sich nur aufwändig speichern. Soviel Gedächtnis ist also jenseits seines Zielgebiets. ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Allerdings ändert Dein Kampf auf dem Nebenkriegsschauplatz > "Energiesparen" jetzt nichts an der Überlegenheit von Asm im > beschriebenen Einsatzgebiet. Sehr geehrter Herr Moby AVR, wenn ich die letzten 1149 Beträge Revue passieren lasse, wird in nahezu allen Beträgen nicht das eigentliche Thema dieses Threads behandelt. Nämlich, die von ihnen in der Überschrift triumphal angekündigte Renaissance der Assemblerprogrammierung. Ich lese von ihnen fast ausschliesslich Fakten zur Überlegenheit von Assembler und die Versuche der Mitforisten sie und ihre Ausführungen zu diskreditieren. Da dieser Thread somit ohnehin schon lange, mit einer kurzen Unterbrechung, nicht mehr das Ursprungsthema behandelt, sehe ich durchaus die Möglichkeit auf die anderen Aspekte, der von ihnen häufig genannten Effizienz von Controller-Anwendungen, einzugehen. mfg.
:
Bearbeitet durch User
Thomas E. schrieb: > in der Überschrift triumphal angekündigte, > Renaissance der Assemblerprogrammierung Die Überschrift stammt nicht aus meiner Feder. > sehe ich > durchaus die Möglichkeit auf die anderen Aspekte, der von ihnen häufig > genannten Effizienz von Controller-Anwendungen, einzugehen. Das Recht auf Sichtung verschiedenster Aspekte von was auch immer möchte ich hier niemand absprechen. Mich interessiert hier nur der Aspekt der Effizienz einer Sprache speziell im Vergleich Asm vs. C. Ich bitte das zu entschuldigen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Die Überschrift stammt nicht aus meiner Feder. Sehr geehrter Herr Moby AVR, da sie diese Überschrift aber benutzten und diese nicht als Zitat kennzeichneten, musste ich sehr wohl davon ausgehen, dass diese ihre Meinung darstellt und sie eine, in diese Richtung gehende Diskussion anregen wollten. Moby A. schrieb: > Mich interessiert hier nur der Aspekt der > Effizienz einer Sprache speziell im Vergleich Asm vs. C Dieses geht aber aus der Überschrift nicht hervor. Wenn es von vornherein ihre Absicht war, innerhalb der Forengemeinde ausschliesslich diesen einen, von ihnen genannten Aspekt, zu diskutieren, hätten sie dieses durchaus durch eine eindeutigere Wahl der Überschrift erkennbar machen können. Damit wären ihnen und mir sowie auch anderen Forumsteilnehmern sicherlich einige Missverständnisse erspart geblieben. mfg.
:
Bearbeitet durch User
Thomas E. schrieb: > Damit wären ihnen und mir sowie auch anderen > Forumsteilnehmern sicherlich einige Missverständnisse erspart geblieben. Wenn eine solche Meldung auftaucht und ich als TO sofort die Meinung vertrete, daß die Verlautbarung ob der Asm-Effizienz bei hardwarenahem IOT/MSR ebendiesen plausiblen Hintergrund hat, dann wird bzw. wurde das mangels anderer diskutierter Erklärungen zur klaren Thread Leitlinie, bei der keine Missverständnisse mehr auftreten sollten, aufgetreten sind, jetzt nur vorgetäuscht werden ;-) Als Mod Yalu nun nach >1000 Beiträgen mit (von mir ungeprüfter) Recherche zu einer (mich) überzeugenden Erklärung der Tiobe-Meldung kam, hatte ich mich damit eigentlich abgefunden...
:
Bearbeitet durch User
P. M. schrieb: > Du beziehst dich wohl auf mich und ein, zwei meiner Posts. Auch, aber zu einem sehr viel kleineren Teil als Du vermutest. Die überwiegende Zahl Deiner Aussagen finde ich nicht zu beanstanden. >Auf einer sachlichen Ebene ist der Thread schon längst erledigt. Aber sowas von ... > Es geht nun wirklich nur noch darum, Moby > klarzumachen, wie absurd (und teilweise unsportlich) er sich in dieser > Diskussion verhält. Nein, Dir mag es darum gehen, ich beziehe meinen 'Lustgewinn' hier zu einen großen Teil daraus wie mühelos Moby jeden Versuch abwehrt sich durch so etwas banales wie Fakten beeinflussen zu lassen. Jeder der nur 20% von diesen Thread gelesen hat hätte vollkommen mühelos zu der Einschätzung kommen können das es nichts zwischen Himmel und Erde gibt was Mobys Überzeugung ändern wird. Ich amüsiere mich köstlich darüber das dieser völlig offensichtliche Umstand wirlich so schwer zu verstehen ist. Zum anderen sind es manchmal gerade diejenigen die Moby gute Manieren beibringen wollen die sich am heftigsten danebenbenehmen. (Bezogen auf das was in hitzigen Diskussionen noch als gutes Benehmen durchgeht)
Michael K. schrieb: > Jeder der nur 20% von diesen Thread gelesen hat hätte vollkommen mühelos > zu der Einschätzung kommen können das es nichts zwischen Himmel und Erde > gibt was Mobys Überzeugung ändern wird. Irrtum. Ein kürzeres, funktionierendes C-Gegenbeispiel. Und zwar schon vor den hunderten hiesiger und hunderten Beiträgen meines Projektthreads. Solange das nicht kommt nenne ich meine Überzeugung voller Überzeugung Wissen um Fakten ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Das hast Du Dir wie immer alles schön zusammenkonstruiert. Da gibts für > mich nichts mehr zu kommentieren. Ich weiß ja, daß Du irgendwie von > Deiner gescheiterten Nachbildung meines Codes ablenken mußt. Soso, wahrscheinlich weise ich deswegen so gerne darauf hin. Nachdem Du erst tagelang zu feige warst, die Anforderungen zu formulieren, hast Du als Reaktion auf meinen Code plötzlich feige eine neue Anforderung aus dem Hut gezaubert, die mit C kaum zu erfüllen ist. :-)) Damit hat Deine Reaktion doch schon alles gezeigt, was zu zeigen war. Und zum Glück kann das jeder selbst nachlesen. :-) > Mensch Junge, wann wirst Du endlich begreifen, daß man da nix erfinden > muß? Das hat Yalus Code ja gezeigt. :-) Soll ich Dir den Link nochmal schicken? Du scheinst ja zu einer überaus selektiven Vergeßlichkeit zu neigen.
Moby A. schrieb: > Ich tät ja gern endlich endlich mal Beweise für die allumfassende > C-Überlegenheit sehen ;-) Sowas hat außer Dir doch niemand gesagt, im Gegenteil. Das ist nur eine Strohpuppe von Dir. Warum sollte jemand etwas beweisen, das er nie gesagt hat? Warum sollte jemand etwas beweisen, das Du behauptet hast?
Moby A. schrieb: > Irrtum. Ein kürzeres, funktionierendes C-Gegenbeispiel. Das hast Du längst bekommen: Beitrag "Re: C versus Assembler->Performance"
Sheeva P. schrieb: > neue Anforderung aus dem Hut gezaubert, die mit C kaum zu erfüllen ist. Sorry, zaubern kann ich nicht. Was Du "neue Anforderung" nennst war als essentielles Ressourcenverbrauchs-Merkmal meines Codes längst gegeben. Worin sollten die Codes verglichen werden? Daß etwas mit C nicht zu erfüllen ist war die ganze Zeit meine These, merkst Du das nicht? > Das hat Yalus Code ja gezeigt. :-) Soll ich Dir den Link nochmal > schicken? Du scheinst ja zu einer überaus selektiven Vergeßlichkeit zu > neigen. Um Dir ein letztes Mal den Gefallen zu tun geh ich nochmal drauf ein: 1. War sein Code nicht 1:1 kompatibel zu meinem 2. War sein Code nicht auf Funktion geprüft 3. Gab es das Angebot auf Gleichstand zu werten, welches ich 4. nicht angenommen und angekündigt habe, die vorgestellte Funktionalität zum Thema eines eigenen Projekts zu machen 5. schließlich habe ich erst mein Tiny13 Projekt zum offiziellen Streitvehikel hier und im eigentlichen Projektthread erkoren, mein Entprellbeispiel fand ich auch nicht hinreichend optimiert, es sollte in einem C++ Thread zuvor etwas ganz anderes verdeutlichen. So, nun kannst Du darüber weiter zetern bis Du schwarz wirst und Links ohne Ende anbringen. Ich rate Dir aber eher, Deine Projektruine bewohnbar zu machen und wenigstens zu einem guten Ende zu bringen. Das macht mehr Eindruck.
Gibt es hier sowas wie GOTO 1 ? Dann müsste nicht jeder hier sich die Arbeit machen, immer wieder dasselbe zu schreiben, sondern das Forum würde von selbst wieder von anfangen. Oder ist das vielleicht sogar schon eingebaut?
Ja, eigentlich liegt der Schwarze Ritter entbeint und entarmt (klar bei einem AVR-only-Fan ;-) am Boden und versucht weiter allen Angst einzujagen. Wir sollten es wie im Film machen. Ihn einfach liegen lassen und zum nächsten Abenteuer weiterziehen.
:
Bearbeitet durch User
Carl D. schrieb: > Ja, eigentlich liegt der Schwarze Ritter entbeint und entarmt > (klar bei einem AVR-only-Fan ;-) am Boden und versucht weiter allen > Angst einzujagen. Wir sollten es wie im Film machen. Ihn einfach liegen > lassen und zum nächsten Abenteuer weiterziehen. Wunschfantasien sind schon was Schönes... Meine verrate ich aber nicht ;-) Carl D., gerade Du solltest nicht von Weiterziehen reden... Dafür klebst Du seit langem viel zu sehr an meinen Beiträgen! Zieh ruhig weiter, wenn Du es schaffst ;-)
Michael K. schrieb: >> Es geht nun wirklich nur noch darum, Moby >> klarzumachen, wie absurd (und teilweise unsportlich) er sich in dieser >> Diskussion verhält. > Nein, Dir mag es darum gehen, ich beziehe meinen 'Lustgewinn' hier zu > einen großen Teil daraus wie mühelos Moby jeden Versuch abwehrt sich > durch so etwas banales wie Fakten beeinflussen zu lassen. Die wahre grosse Frage des Threads ist ja eigentlich: Wer ist dieser Moby, und warum lässt er sich wochenlang und in weit über tausend Beiträgen dermassen vorführen?
P. M. schrieb: > Die wahre grosse Frage des Threads ist ... wer hier wen vorführt ;-) Der Gedanke, daß sich Mühelosigkeit aus 'im Recht sein' ergeben könnte scheint für manchen unerreichbar zu sein.
:
Bearbeitet durch User
Moby A. schrieb: > Was Du "neue Anforderung" nennst war als essentielles > Ressourcenverbrauchs-Merkmal meines Codes längst gegeben. Von wegen, Du hast den RAM ja sogar für die Benutzung initialisiert. Und dann soll man ihn nicht benutzen dürfen? Wie lächerlich. > Um Dir ein letztes Mal den Gefallen zu tun geh ich nochmal drauf ein: > > 1. War sein Code nicht 1:1 kompatibel zu meinem > 2. War sein Code nicht auf Funktion geprüft > 3. Gab es das Angebot auf Gleichstand zu werten, welches ich > 4. nicht angenommen und angekündigt habe, die vorgestellte > Funktionalität zum Thema eines eigenen Projekts zu machen > 5. schließlich habe ich erst mein Tiny13 Projekt zum offiziellen > Streitvehikel hier und im eigentlichen Projektthread erkoren, mein > Entprellbeispiel fand ich auch nicht hinreichend optimiert, es sollte in > einem C++ Thread zuvor etwas ganz anderes verdeutlichen. Billige Ausreden, hohles Geschwätz. Aber wenig überraschend. > Ich rate Dir aber eher, Deine Projektruine bewohnbar zu machen Wozu? Dann erfindest Du doch nur wieder neue "Anforderungen". Und daß Dir an einem objektiven Vergleich nichts liegt, habe ich schon bewiesen. :-)
Sheeva P. schrieb: > Billige Ausreden, hohles Geschwätz. Aber wenig überraschend. Ist das jetzt plötzlich alles was Du dazu noch sagen kannst? Mich überrascht das schon. Reichlich billig find ich... Ich bitte daher um Verständnis wenn ich keine weitere Energie mehr in die Beantwortung Sheeva'scher Klagelieder investieren mag ;-(
:
Bearbeitet durch User
>Reichlich billig find ich...
Amüsant ist dein Sturheit zu verstehen, das unter "Effizient" jeder
ausser dir hauptsächlich die nötige Entwicklungszeit betrachtet und
einige Bytes an RAM/Flash mehr oder weniger egal sind.
Du bist der einzige, der nur auf RAM/Flash Verbrauch schielt und dafür
weit längere Entwicklungszeiten in Kauf nimmt.
Moby A. schrieb: > Ich bitte daher um Verständnis wenn ich keine weitere Energie mehr in > die Beantwortung Sheeva'scher Klagelieder investieren mag ;-( Mach das doch mit jedem hier! ;-) Ich wiederhole mich aber gern auch nochmal: Du kannst Deine Aussagen für ein 200-Byte-Programm nicht hochskalieren. Bei 1KB ist schon Ende der Fahnenstange mit ASM. Du hast da auch keinen Gegenbeweis. Ende aus, Micky Maus.
:
Bearbeitet durch Moderator
Das lustige an diesem Tiobe-Index ist ja, dass er, wenn ich mal meine Suchanfragen so betrachte, wohl schlussfolgern müsste, dass C++ und Python sehr beliebte Programmiersprachen seien, während C nur unter „ferner liefen“ rangiert. C++ benutze ich zu selten und muss daher häufiger mal nach was Gugeln, bei Python sind es vor allem die vielen Module im Netz, bei denen sich wohl kaum jemand an alle gut genug erinnern kann, da muss man auch häufiger mal eine Anfrage starten. Das relativ kleine C dagegen, welches ich tagtäglich benutze, kenne ich in- und auswendig, und eine Kopie des C-Standards hat man ja ohnehin auf der Platte rumliegen. Vermutlich wird es vielen anderen ähnlich gehen (und wenn Moby ehrlich ist, wird auch er wohl für seine AVRs kaum in einer Suchmaschine nach “assembly language” nachfragen). Das führt doch das ganze Ding aber komplett ad absurdum in seinem Aussagewert.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Ich bitte daher um Verständnis wenn ich keine weitere Energie mehr in > die Beantwortung Sheeva'scher Klagelieder investieren mag ;-( Wie lustig, da kann einer seine Niederlage und sein eigenes mieses Verhalten nicht ertragen und exkommuniziert mich. :-)
Carl D. schrieb: > Ja, eigentlich liegt der Schwarze Ritter entbeint und entarmt (klar bei > einem AVR-only-Fan ;-) am Boden und versucht weiter allen Angst > einzujagen. Wir sollten es wie im Film machen. Ihn einfach liegen lassen > und zum nächsten Abenteuer weiterziehen. Aus seiner Sicht ist er immer noch Artus ;-)
Gu. F. schrieb: > Carl D. schrieb: >> Ja, eigentlich liegt der Schwarze Ritter entbeint und entarmt (klar bei >> einem AVR-only-Fan ;-) am Boden und versucht weiter allen Angst >> einzujagen. Wir sollten es wie im Film machen. Ihn einfach liegen lassen >> und zum nächsten Abenteuer weiterziehen. > > Aus seiner Sicht ist er immer noch Artus ;-) Aber Artus hatte eine Tafelrunde, nur der Schwarze Ritter war allein ;-)
Sheeva P. schrieb: > Wie lustig, da kann einer seine Niederlage und sein eigenes mieses > Verhalten nicht ertragen und exkommuniziert mich. Das ist nicht seine Niederlage, sondern deine. Der einzige, der sein mieses Verhalten nicht ertragen kann, bis du selbst. Exkommuniziert hast du dich ebenfalls selber. Und lustig ist das auch nicht. Wetten? mfg.
Moby A. schrieb: > Sheeva P. schrieb: >> Billige Ausreden, hohles Geschwätz. Aber wenig überraschend. > > Ist das jetzt plötzlich alles was Du dazu noch sagen kannst? > Mich überrascht das schon. Reichlich billig find ich... Überhaupt nicht billig. Sheeva ist einer derjenigen Personen, die am meisten Inhalt und Argumente zum Thread beigesteuert haben. Inhaltlich konntest du rein gar nichts entgegensetzen, aber du bringst deine (widerlegten) Behauptungen trotzdem immer und immer wieder. Wer den Thread gelesen hat, der weiss, dass die Bezeichnung "billige Ausreden, hohles Geschwätz" für deine Beiträge nicht im geringsten übertrieben ist.
Weil's mich die ganze Zeit schon interessiert, ein bisschen Statistik: Moby hat bis jetzt 261 Beiträge in diesem Faden geschrieben. Alle (!) wurden negativ bewertet. In Summe sind's 1209 downvotes geworden. Am schlechtesten hat der erste Beitrag mit -19 abgeschnitten, die beste Bewertung war eine -1. Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten.
Thomas E. schrieb: > Sheeva P. schrieb: >> Wie lustig, da kann einer seine Niederlage und sein eigenes mieses >> Verhalten nicht ertragen und exkommuniziert mich. > > Das ist nicht seine Niederlage, sondern deine. Der einzige, der sein > mieses Verhalten nicht ertragen kann, bis du selbst. Exkommuniziert hast > du dich ebenfalls selber. Und lustig ist das auch nicht. > > Wetten? Warum sollte ich gegen meine eigenen Erwartung wetten? :-)
Thomas E. schrieb: > Das ist nicht seine Niederlage, sondern deine. Was soll er denn noch tun? Moby ist nicht fähig oder nicht willens, sachlich zu diskutieren. Da darf man irgendwann auch mal persönlich werden und sagen, was man von der Person hält. Wer hier immer noch sachliche Argumente fordert, der ist schon länger fehl am Platz.
Ironiedetektor schon wieder kaputt? Das hält ja keiner aus... mfg. Nein, ich hänge da nicht so ein albernes Strich-Doppelpunkt-Klammer hinter.
:
Bearbeitet durch User
P. M. schrieb: > Sheeva ist einer derjenigen Personen, die am > meisten Inhalt und Argumente zum Thread beigesteuert haben. Danke, aber bitte mach' mich nicht größer, als ich bin. Viele Leute haben hier viel größere Beiträge beigesteuert als ich. P. M. schrieb: > Thomas E. schrieb: >> Das ist nicht seine Niederlage, sondern deine. > > Was soll er denn noch tun? Moby ist nicht fähig oder nicht willens, > sachlich zu diskutieren. Da darf man irgendwann auch mal persönlich > werden und sagen, was man von der Person hält. Wer hier immer noch > sachliche Argumente fordert, der ist schon länger fehl am Platz. Entschuldige, aber ich fürchte, Du hast die Ironietags an Thomas' Beitrag übersehen. :-)
Sheeva P. schrieb: > Entschuldige, aber ich fürchte, Du hast die Ironietags an Thomas' > Beitrag übersehen. :-) Wärs nicht einfacher, den ganzen Thread damit zu versehen, als jeden Beitrag einzeln? Das entspräche auch ganz Mobys Sinn für Sparsamkeit.
:
Bearbeitet durch User
A. K. schrieb: > Das entspräche auch ganz Mobys Sinn für Sparsamkeit. ... zumal jeder extra Beitrag zusätzliches RAM in seinem Rechner belegt.
:
Bearbeitet durch User
Gu. F. schrieb: > Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten. Das Arithmetische Mittel ist gerne mal ungeeignet, den ein einziger Ausreisser kann den ganzen Schnitt versauen oder schönen. Da braucht nur eine einzigen Multimillionär in die Stadt zu ziehen und auf wundersame Weise steigen Durchschmittsvermögen und -einkommen aller. Stabiler sind da z.B. Quantile wie Median (50% Quantil).
Johann L. schrieb: >> Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten. > > Da braucht nur eine einzigen Multimillionär in die Stadt zu ziehen und > auf wundersame Weise steigen Durchschmittsvermögen und -einkommen aller. Auch der Median hat wundersame Effekte. Wenn man der Mittelschicht etwas wegnimmt und es dem Millonär gibt, dann reduziert man die Armut. ;-)
P. M. schrieb: > Die wahre grosse Frage des Threads ist ja eigentlich: Wer ist dieser > Moby, und warum lässt er sich wochenlang und in weit über tausend > Beiträgen dermassen vorführen? Ist er es denn der vorgeführt wird ? Moby hat eine Behauptung aufgestellt die von vornherein Quatsch war. Die Diskussion zu gewinnen war niemals sein Ziel. Sein Ziel ist es uns dazu zu bringen immer verbisserner um den Knochen zu kämpfen den er uns hingeworfen hat. Man KANN Moby nicht umstimmen, weil das überhaut nie vorgesehen war. Jeden der das versucht treibt er wie ein Schaf zur Schlachtbank, d,h, solange bis man aufgibt oder auf den Level persönlicher Beleidigungen herabsteigt. Das ist ein simples kleines Psychospiel. Er bricht von sich aus den Kontakt nicht ab und signalisiert immer wieder das es doch klappen könnte ihn zu besiegen wenn man nur noch etwas am Ball bleibt. Das kann noch Monate so weitergehen. Ich find das ja ganz lustig als Zeitvertreib während ich meinen Cappuccino schlürfe. Ihr könnt nicht gewinnen weil ihr Euch weitestgehend an Diskussionsregeln haltet. Argumentationsketten, Indizien, Fakten, Erfahrungsberichte, verweis auf persönliche Qualifikationen, der ganze Kram. Moby tut das nicht. Er benutzt Worte einfach so wie er sie gerade braucht. Er stellt so schnell neue Behauptungen auf, verdreht so schnell Eure Worte und ignoriert dabei alles was ihm nicht passt, das man so gegen ihn einfach nicht gewinnen kann. Gewinnen kann man das nur auf einer ganz persönlichen Basis, indem man einfach kopfschüttelnd weiterzieht.
Michael K. schrieb: > Ihr könnt nicht gewinnen Michael K. schrieb: > Gewinnen kann man das nur... Doch, ich (und viele andere hier) gewinnen regelmäßig. Ich seh das hier genauso wie den Kurt B. Thread, der momentan leider mit Inaktivität glänzt. Ich beziehe hieraus einen kurzen, wenn auch vergnüglichen Lustgewinn wenn in der Arbeit gerade a weng Luft ist, z.B. weil der Compiler wieder länger braucht oder man auf irgendne Rückmeldung wartet. Ich denke, so gut wie alle die hier schon länger dabei sind wissen genauso wie du, dass der "Gewinn" niemals darin bestehen wird, den Diskussionsgegner von der eigenen Meinung zu überzeugen.
A. K. schrieb: > Johann L. schrieb: >>> Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten. >> >> Da braucht nur eine einzigen Multimillionär in die Stadt zu ziehen und >> auf wundersame Weise steigen Durchschmittsvermögen und -einkommen aller. > > Auch der Median hat wundersame Effekte. Wenn man der Mittelschicht etwas > wegnimmt und es dem Millonär gibt, dann reduziert man die Armut. ;-) Will-Rogers? https://de.wikipedia.org/wiki/Will-Rogers-Phänomen
Michael K. schrieb: > Ihr könnt nicht gewinnen Michael K. schrieb: > Gewinnen kann man das nur... Für einen, der nur andere vorführen will, läßt sich M. aber leicht auf's Glatteis locken und bricht aus regelmäßig ein. Auch wenn er das selber nicht merkt: die anderen stehen im Trockenen! Und als Gegner spielt er einfach einige Gewichtsklassen zu tief.
trotz >Übung, Vorbereitung, System . und der allumfassenden Überlegenheit von ASM kommt dann trotzdem sowas raus: > mein > Entprellbeispiel fand ich auch nicht hinreichend optimiert, .. wie kann denn sowas passieren? (ich dachte mir das ATtiny13 "Projekt" hat neben den 2 analogen Werten, auch 2 digitale??? sind die jetz nicht entprellt ?)
Robert L. schrieb: > (ich dachte mir das ATtiny13 "Projekt" hat neben den 2 analogen Werten, > auch 2 digitale??? sind die jetz nicht entprellt ?) Ja, sind sie nicht. Darf man vermutlich keine mechanischen Taster anschließen. Das steht doch aber alles klar und deutlich lesbar in der Spezif^H^H^H^H^H^H^H^Hm Sourcecode drin.
Johann L. schrieb: > Will-Rogers? Kannte ich bisher nicht, aber grob ähnlich. Aus der Mittelschicht zu nehmen senkt das Medianeinkommen. Dies den Reichen zu geben ist hingegen neutral. Wenn die Armutsgrenze als 50% vom Media definiert ist (relative Armut), dann migrieren durch den sinkenden Median einige aus der Armut in die Mittelschicht, obwohl sie nachher soviel haben wie vorher. Der Grenzfall ist die Marx'sche Prognose von der entfallenden Mittelschicht. Dann liegt der Medien nur knapp über dem Boden und Armut existiert nicht mehr.
:
Bearbeitet durch User
Angehängte Dateien:
-
moby_histo.png
1,6 KB
Johann L. schrieb: > Gu. F. schrieb: >> Im Schnitt hat also jeder Beitrag 4,6 neg. Bewertungen erhalten. > > Das Arithmetische Mittel ist gerne mal ungeeignet, den ein einziger > Ausreisser kann den ganzen Schnitt versauen oder schönen. > > Da braucht nur eine einzigen Multimillionär in die Stadt zu ziehen und > auf wundersame Weise steigen Durchschmittsvermögen und -einkommen aller. > > Stabiler sind da z.B. Quantile wie Median (50% Quantil). Na ja, passt schon ganz gut. Hier noch das Histogram :-)
Jörg W. schrieb: > Das steht doch aber alles klar und deutlich lesbar in > der Spezif^H^H^H^H^H^H^H^Hm Sourcecode drin. *ROFL* Einfach köstlich!
Gu. F. schrieb: > Na ja, passt schon ganz gut. Sagt halt nur nicht viel mehr aus, als dass es ein paar hier gibt, die ihm schätzungsweise aufgrund seines Namens immer eine negative Bewertung geben. Selbst für sowas bekommt er einen Haufen Minuspunkte: Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Ich verstehe Moby so: 1. Er hat ein winziges simples Programm erstellt, dass keine Daten im RAM ablegen muss, weil seine 32 Universalregister dafür ausreichend sind. Nun behauptet er, dass er in ASM für sein Programm keinen RAM benötigt, und definiert diesen Umstand (oder Zustand) als "resourcensparend. Damit hat er für sich Recht. 2. Er behauptet, dass die gleiche Funktionalität - in C geschrieben - RAM benötigen wird. Damit hat er auch Recht, denn jeder C Compiler ist so programmiert und konfiguriert, dass er den RAM verwendet, wenn er im Controller vorhanden ist. Auch damit hat er Recht. 3. Er definiert für diese erwünschte Funktionalität den Umstand "keine Belegung des RAM" als resourcensparend, den Umstand "Benutzung von RAM" als resoucenverschwendend. Damit hat er nach der Subsumption seiner selbst erschaffenen Tatsachen unter seine selbst definierten Begriffe Recht. Ob das aber jemals einen echten Programmierer interessiert ist Moby egal. In seiner Welt ist das eben so. Moby ist begeistert von ASM. Es überkommt ihn ein Hochgefühl, wenn der kleine Tiny genau das macht, was Moby sich wünscht und Moby dabei über jeden Takt, jedes Register und jeden Prozessschritt die absolute Kontrolle behält. Moby ist froh, dass es so eine einfache Sprache wie ASM gibt, weil er für Hochsprachen unzugänglich und unfähig ist, sie zu erlernen. Es ist kaum auszumalen, welchen Hochgefühl den Moby ereilen würde, wenn er mal in C ein richtiges Programm erstellen würde, sehen würde, was der Prozessor wirklich drauf hat, und wie einfach es ist, ihn zu unglaublich komplexen Dingen zu bewegen. Dafür müsste er nur mal seine Fesseln ablegen und überhaupt mal programmieren lernen. Naja, vielleicht in seinem nächsten Leben.
Jörg W. schrieb: > Robert L. schrieb: >> (ich dachte mir das ATtiny13 "Projekt" hat neben den 2 analogen Werten, >> auch 2 digitale??? sind die jetz nicht entprellt ?) > > Ja, sind sie nicht. Darf man vermutlich keine mechanischen Taster > anschließen. Das steht doch aber alles klar und deutlich lesbar in > der Spezif^H^H^H^H^H^H^H^Hm Sourcecode drin. Die Taster müssen natürlich über ein Cortex M0 Shield entprellt werden. so komplizierte Dinge sollte man immer in Spezial-Hardware auslagern.
Carl D. schrieb: > so komplizierte Dinge sollte man immer in Spezial-Hardware auslagern. „keine typische 8-Bit-MSR-Anwendung“
Jörg W. schrieb: > Gu. F. schrieb: >> Na ja, passt schon ganz gut. > > Sagt halt nur nicht viel mehr aus, als dass es ein paar hier gibt, > die ihm schätzungsweise aufgrund seines Namens immer eine negative > Bewertung geben. Selbst für sowas bekommt er einen Haufen Minuspunkte: > > Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Es sagt nicht viel aus wenn einer 260 Beiträgen über 1200 Miese kassiert????
Gu. F. schrieb: > Es sagt nicht viel aus wenn einer 260 Beiträgen über 1200 Miese > kassiert? Es sagt über seine konkreten Beiträge hier gar nichts aus, sondern nur was darüber, dass er sich hinreichend unmöglich gemacht hat mit seinem Auftreten, als dass er eben selbst für eher moderate Beiträge, für die sonst kein Mensch auch nur ansatzweise auf die Idee käme, positive oder negative Bewertungen zu vergeben, Minuspunkte kassiert. Damit ist deine Statistik aber für die Katz', denn sie besagt weiter nichts als dass Moby, egal was er schreibt, niemand hier leiden kann. Das wiederum brauchst du nicht erst mit Zahlenakrobatik zu belegen, das war vermutlich selbst Moby auch so schon klar (er interpretiert das Ergebnis nur als Überlegenheit denn als Niederlage). p.s.: Kauf' dir mal 'ne neue Tastatur, deine Fragezeichentaste prellt.
:
Bearbeitet durch Moderator
Also eins muß man dem Moby wirklich lassen. Er hat dem Forum massig Redewendungen für künftige Threads geliefert. Ich seh schon folgendes Szenario... Anfänger stellt ne Fragen, liefert aber keinerlei Hintergrundinfos (Schaltbilder, Code, Prozessor, usw.) Frage: "Warum geht denn die LED nicht an wenn ich den Taster drücke?" Antwort: "Na das ist halt keine typ. 8-bit MSR Anwendung"* * (Früher stand hier 42 o.s.ä.)
Jörg W. schrieb: > p.s.: Kauf' dir mal 'ne neue Tastatur, deine Fragezeichentaste prellt. "????" ist das international gebräuchliche Zeichen für "Häääää?" ;-)
Jörg W. schrieb: > p.s.: Kauf' dir mal 'ne neue Tastatur, deine Fragezeichentaste prellt. Geht auch per Software: Entprellung: Softwareentprellung ;-)
:
Bearbeitet durch Moderator
Markus M. schrieb: > Dafür müsste er [Moby] nur mal seine Fesseln ablegen und überhaupt > mal programmieren lernen. Naja, vielleicht in seinem nächsten Leben. hehe, in seinem nächsten Leben wird er zu einem eingesparten Nibble.
Jörg W. schrieb: > Carl D. schrieb: >> so komplizierte Dinge sollte man immer in Spezial-Hardware auslagern. > > „keine typische 8-Bit-MSR-Anwendung“ Das besagte Attiny Projektchen ist m.E. keine typische MSR-Anwendung, sondern vielmehr ein simpler Fernwirksender. Bei 3Hz Abtastung kann man sich die Entprellung sparen.
Witkatz :. schrieb: > Bei 3Hz Abtastung kann man sich die Entprellung sparen. Da kommt er nicht drum herum. Denn eine vernünftige Entprellung eliminiert nicht nur das Prellen eines Tasters an sich, sondern filtert auch sehr effektiv Störimpulse aus. Ohne Entprellung würde ein Störimpuls, der zufällig im Abtastmoment auftritt, eine Fehlfunktion auslösen. mfg.
Thomas E. schrieb: > filtert auch sehr effektiv Störimpulse aus. Achso, ich dachte das wäre bei der ausgeklügelten Schaltung in Hardware gelöst. Leider kenne ich nicht den Schaltplan. War da nicht der "Kondensator rechts unten" im Layout für Entstörung, Glättung und EMV Schutz zuständig?
Matthias L. schrieb: > Du bist der einzige, der nur auf RAM/Flash Verbrauch schielt und dafür > weit längere Entwicklungszeiten in Kauf nimmt. Ressourcen- Nachteile sind das, was C mitbringt und das um was es mir hier allein geht. Entwicklungszeiten sind im 8-Bit MSR Bereich eine Sache von Übung, Vorbereitung, System ;-) Frank M. schrieb: > Bei 1KB ist schon Ende der Fahnenstange mit ASM. > Du hast da auch keinen Gegenbeweis. Ende aus, Micky Maus. Da ist noch laaaange kein Ende ;-) Asm-Code selbst jenseits 10K gibts genug. Jörg W. schrieb: > Das relativ kleine C dagegen, welches ich tagtäglich benutze, kenne ich > in- und auswendig, und eine Kopie des C-Standards hat man ja ohnehin > auf der Platte rumliegen. Simply Asm ist noch vieeel kleiner. Da braucht man keinen XYZ-Standard auf der Platte ;-)
Moby A. schrieb: > Da ist noch laaaange kein Ende ;-) Nur eine Behauptung. > Asm-Code selbst jenseits 10K gibts genug. C-Code jenseits 10K gibts noch viel mehr. Soviele Masochisten kann es auch nicht geben.
Sheeva P. schrieb: > Wie lustig, da kann einer seine Niederlage und sein eigenes mieses > Verhalten nicht ertragen und exkommuniziert mich. :-) Du weißt glaub ich auch nicht, zwischen welcher Stimmungslage Du Dich entscheiden sollst: Künstlich belustigt oder empört... Deine langatmigen Rechtfertigungstiraden werden von Deinem Versagen bei einem einfachen C-Programm jedenfalls kaum ablenken. Du solltest Dich mit Deiner Geschichte in einem eigenen Thread über den bösen Moby und seine schlimmen Machenschaften auskotzen ;-) P. M. schrieb: > Wer hier immer noch > sachliche Argumente fordert, der ist schon länger fehl am Platz. Ja, die vermisse ich... Und sie kommen einfach nicht ;-) Erwartet hab ich sie ehrlicherweise nach den Erfahrungen meines Projektthreads aber auch nicht. Robert L. schrieb: > wie kann denn sowas passieren? Tja sowas aber auch... Software ist schon was eigenartiges. Nun ja, daß die Verwendung von Asm vor weniger effektiver Programmierung schützt hat auch niemand behauptet. Ist halt auch keine in den Mund fliegende gebratene Taube. Aber Asm macht den saftigen effizienten Braten erst möglich ;-) Jörg W. schrieb: > Sagt halt nur nicht viel mehr aus, als dass es ein paar hier gibt, > die ihm schätzungsweise aufgrund seines Namens immer eine negative > Bewertung geben. Selbst für sowas bekommt er einen Haufen Minuspunkte: Leute, wer hier Minuspunkte ernst nimmt dem ist nicht mehr zu helfen. Minuspunkte sind das was man vergibt wenn einem keine sachlichen Argumente mehr einfallen. Die sind dann quasi zu einem Mittel unlauterer Kriegsführung verkommen ;-)
Markus M. schrieb: > Moby ist froh, dass es so eine einfache Sprache wie ASM gibt, weil er > für Hochsprachen unzugänglich und unfähig ist, sie zu erlernen. Nö, bin ich nicht. Aber im Hinterkopf ist da so ein lästiger Gedanke: Muß das jetzt wirklich so umständlich und ineffizient programmiert werden oder gehts doch einfacher? > welchen Hochgefühl den Moby ereilen würde Das hab ich schon, wenn ich sehe was selbst so ein kleiner Tiny in Asm zu leisten imstande ist! > sehen würde, was der > Prozessor wirklich drauf hat Glaub mir, daß seh ich mit meinem direkten Blick auf die Hardware am allerbesten ;-) > ihn zu unglaublich > komplexen Dingen zu bewegen Ich weiß nicht was Du Dir darunter so vorstellst aber ich vermute, dafür langt dann kein AVR mehr.
:
Bearbeitet durch User
Carl D. schrieb: > Für einen, der nur andere vorführen will, läßt sich M. aber leicht auf's > Glatteis locken und bricht aus regelmäßig ein. Einbildung ist auch 'ne Bildung, Carl D. Jörg W. schrieb: > Das wiederum brauchst du nicht erst mit Zahlenakrobatik zu belegen, > das war vermutlich selbst Moby auch so schon klar (er interpretiert > das Ergebnis nur als Überlegenheit denn als Niederlage). Hier gehts nicht um Sieg oder Niederlage oder wie was zu interpretieren ist. Mein Projektbeispiel belegt die Effizienz von Asm. Bis heute kam kein Gegenbeweis und er wird auch nicht kommen. Viel einfacher ist es doch, wenn sich die großen Experten hier in Hohn und Spott flüchten und sich darin gegenseitig bestärken. Eine eindrucksvolle Show soll das wohl sein- nur bin ich eher selber belustigt denn beeindruckt ;-)
Moby A. schrieb: > Mein Projektbeispiel belegt die Effizienz von Asm. Bis heute kam > kein Gegenbeweis und er wird auch nicht kommen. Das ist zweimal gelogen. Es wurde nämlich gezeigt, dass man dein Zeug auch effizient in C umsetzen kann. Dass du kaum von deinem Standpunkt abzubringen bist und ihn gleichzeitig kaum belegen kannst, das ist die eine Sache. Dass du jetzt aber noch direkt zum Lügen übergehst, das ist eine andere.
Moby A. schrieb: > Frank M. schrieb: >> Bei 1KB ist schon Ende der Fahnenstange mit ASM. > > Da ist noch laaaange kein Ende ;-) > Asm-Code selbst jenseits 10K gibts genug. Im Gegensatz zu Dir habe ich und einige andere hier bereits Asm-Programme > 10k geschrieben. Und wir wissen auch noch sehr genau, welche Probleme dann bei der Handoptimierung auftreten. Und im Gegensatz zu Dir beherrschen wir zusätzlich zum vollständigen Asm-Instructionset auch C/C++ und können die Vorteile bei Ressourcenverbrauch/Performance und Entwicklungszeit bei größeren Programmen sehr gut einschätzen. Und zu guter letzt kennen viele hier nicht nur AVR, sondern haben schon viele andere Architekturen programmiert und wissen es zu schätzen, wenn beim Umstieg z.B. von einem 68HC11 auf einen AVR nicht der komplette Code neugeschrieben werden muß. Stefan
P. M. schrieb: > Das ist zweimal gelogen. Es wurde nämlich gezeigt, dass man dein Zeug > auch effizient in C umsetzen kann. Unwahrheiten kannte ich bislang nur von der Gegenseite. Auch Du machst mit dieser Behauptung gerade keine Ausnahme. Es sei denn, Du zeigst mir gleich den funktionskompatiblen C-Code zu meinem Tiny13 Projekt... > Dass du kaum von deinem Standpunkt abzubringen bist Die Hoffnung hab ich doch umgekehrt auch nicht. Zuweilen lernt und erfährt man aber was Neues- und sei es nur über die vielfältigsten Psychospielchen hier ;-)
Moby A. schrieb: > Zuweilen lernt und erfährt man aber was Neues- und sei es nur über die > vielfältigsten Psychospielchen hier ;-) Bzgl. "Psychospielchen" kann dir hier eh niemend das Wasser reichen.
P. M. schrieb: > Das ist zweimal gelogen. Also ich kann ja verstehen, daß manche Leute hier mangels anderer Argumente nun alle Register ziehen. Von Lügen zu sprechen ist aber eine ziemlich freche, dreiste, verlogene Veranstaltung- passt aber ins Bild manch anderer Unterstellungen. Was solls. An den Effizienz-Vorteilen, die der Asm-Programmierer ohne große Bürokratie genießen kann ändert das auch nix ;-)
Moby A. schrieb: > P. M. schrieb: >> Das ist zweimal gelogen. > > Also ich kann ja verstehen, daß manche Leute hier mangels anderer > Argumente nun alle Register ziehen. > Von Lügen zu sprechen ist aber eine ziemlich freche, dreiste, verlogene > Veranstaltung- passt aber ins Bild manch anderer Unterstellungen. Also: - Deine Beiträge kriegen durchs Band mindestens 3-5 Downvotes. - Niemand unterstützt deine Behautungen. Moby, wie kannst du da weiterhin so tun, als hätten wir mehr oder weniger eine Aussage-gegen-Aussage-Situation?
Moby A. schrieb: > Also ich kann ja verstehen, daß manche Leute hier mangels anderer > Argumente nun alle Register ziehen. Du hast bis heute nicht zeigen können, dass ein 1KB-Assembler-Programm ressourcen-schonender und effizienter als ein C-Programm ist. Für 200 Byte Mini-Progrämmchen gestehe ich Dir das ja zu. Aber dann ist Ende. Wo sind Deine Projekte, die größer als lächerliche 200 Byte sind? Es gibt sie nicht. Über das Dreirad-Alter sind die meisten hier hinaus. Du hast Dich wahrscheinlich auf einem Dreirädchen festgeklebt.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Es gibt sie nicht. Das würde ich ihm nicht unterstellen. Er will sie uns aber nicht zeigen. Er wird schon wissen, warum.
Jörg W. schrieb: > Er will sie uns aber nicht zeigen. Tja, warum nur? > Er wird schon wissen, warum. Eben. Und ich weiß auch, warum.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Aber im Hinterkopf ist da so ein lästiger Gedanke: > Muß das jetzt wirklich so umständlich und ineffizient programmiert > werden oder gehts doch einfacher? Ja, deswegen mach ich das ja in C und nicht ASM > Das hab ich schon, wenn ich sehe was selbst so ein kleiner Tiny in Asm > zu leisten imstande ist! Du wärst nicht minder erstaunt was der leisten kann wenn Du die gleiche Krücke in C programmierst. Z80 mit 2,5Mhz ist lange her, komm mal drüber weg. https://de.wikipedia.org/wiki/Atmel_AVR >>Durch das auf Hochsprachen wie C ausgelegte Hardware-Design können >>auch Compiler sehr effizienten Code erzeugen Anstatt die Bemühungen von Atmel entsprechend zu würdigen setzt Du den AVR nicht bestimungsgemäß ein und wurstelst da weiterhin mit ASM drin rum. Solltest Du jemals Deine Hemmungen überwinden und C eine echte Chance geben würdest Du wahrscheinlich nie wieder ASM coden wollen. Deine Argumentation wäre dann wohl 'C ist viel besser als [alles andere}' Genauso kompromisslos, genauso engstirnig und genauso falsch. Wir hätten nichts gewonnen, nur das Thread Thema würde sich geringfügig verändern. So, Kaffee ist alle.
P. M. schrieb: > - Deine Beiträge kriegen durchs Band mindestens 3-5 Downvotes. Oh, welch Kriterium ... BIG DISLIKE, sach ich mal.
Stefan K. schrieb: > Im Gegensatz zu Dir habe ich und einige andere hier bereits > Asm-Programme > 10k geschrieben. Wie sich manche Leute gewisser Gegensätze so sicher sein können ;-) Also solltest Du nicht täglich in Asm programmieren behaupte ich jetzt einfach mal, daß Du meinen Codeumfang übers letzte Jahrzehnt so schnell nicht toppst. > Und wir wissen auch noch sehr genau, > welche Probleme dann bei der Handoptimierung auftreten. Wir wissen ganz genau, daß die handoptimierte Anpassung gerade die Effizienz von Asm begründet. So man seine Bausteine entsprechend optimiert zur Verfügung hat = Vorbereitung läuft es oft, über spezifizierte Register-Schnittstellen = System nur aufs gekonnte Zusammenstöpseln = Übung dieser Bausteine hinaus- deshalb ist es auch Unsinn, daß die Komplexität über die Codesize über alle Maßen anwachsen muß. Wenn Du z.B. einen Baustein für UART-Empfangen und Senden hast, ist die Anzahl der genutzten UART-Schnittstellen letztlich wurscht. > Und im Gegensatz > zu Dir beherrschen wir zusätzlich zum vollständigen Asm-Instructionset > auch C/C++ und können die Vorteile bei Ressourcenverbrauch/Performance > und Entwicklungszeit bei größeren Programmen sehr gut einschätzen. Ja ja, bla bla. Den Asm-Vorteil kann ich gut einschätzen- da brauchts auch keine tägliche C/C++ Praxis. Das warum hab ich weiter oben schon mal begründet > Und zu guter letzt kennen viele hier nicht nur AVR, sondern haben schon > viele andere Architekturen programmiert und wissen es zu schätzen, wenn > beim Umstieg z.B. von einem 68HC11 auf einen AVR nicht der komplette > Code neugeschrieben werden muß. Zu guter Letzt benötigt die Beherrschung von Asm auf AVR für typische 8-Bit MSR Aufgaben kein Umherspringen zwischen verschiedenen Architekturen. Mein bescheidenes Hobbyisten-Beileid all jenen, die das aus unterschiedlichsten beruflichen Gründen doch tun müssen.
Also ich hab mal meine AVR-Projekte durchgeblättert und würd gerne von Moby lernen, warum ich mit C eine falsche Entscheidung getroffen habe und warum Assembler hier "ganz klar überlegen" ist. Alle meine AVR-Projekte sind Hobby; ich verwende AVRs von 2KiB bis 16KiB Flash (z.B. ATtiny25, ATtiny2313, ATmega168). Fast keines der Projekte erfüllt die Moby-Bedingung "8-Bit MSR ohne viele Daten und ohne viel Arithmetik"... Nur 2 der Projekte kommen überhaupt in den Dunstkreis des Moby-kriteriums: Projekt 1: PWM-Steller für Ohm'sche Last (ATtiny25) Die Heizung einer Scope-Röhre (6.3V~, 85mA) soll betrieben werden an 9V= ungeregelt, und zwar so, dass die aufgenommene Leistung genauso groß ist wie im Datenblatt der Röhre angegeben, nämlich 6.3*85 mW. Nach dem Einschalten soll die Heizleistung innerhalb mehrerer Sekunden langsam angefahren werden. Ein nicht unwesentlicher Teil des Codes besteht aus der Initialisierung der Hardware wie dem Schreiben von Werte in SFRs. Beispiel
1 | // Initialize Timer0 to make PWM @ F_CPU/256 i.e. ~ 1kHz
|
2 | // Initialize Timer1 to make IRQs @ 125Hz i.e. every 8ms
|
3 | void timers_init (void) |
4 | {
|
5 | // Timer1 in CTC-Mode and prescaled 8
|
6 | TCCR1 = (1 << CTC1) | (1 << CS12); |
7 | |
8 | // PoutputCompare for desired Timer1 frequency
|
9 | OCR1C = (uint8_t) ((uint32_t) F_CPU / IRQS_PER_SECOND / PRESCALE -1); |
10 | OCR1B = 0; |
11 | ...
|
Hier ginge natürlich auch Assembler, aber der Vorteil von
1 | ;; Timer1 in CTC-Mode and prescaled 8 |
2 | LDI r18, (1 << CTC1) | (1 << CS12) |
3 | OUT TCCR1, r18 |
will mit nicht einleuchten. Daher lasse ich im folgenden solche Initialisierungen zur Kürze weg. Der eigentliche Code sieht so aus:
1 | // Ramp up PWM duty cycle
|
2 | bool startup = true; |
3 | |
4 | // Run CPU @ 250kHz (8MHz / 32)
|
5 | CLKPR = (1 << CLKPCE); |
6 | CLKPR = (1 << CLKPS2) | (1 << CLKPS0); |
7 | |
8 | // Initialize hardware
|
9 | ioinit (); |
10 | |
11 | // IRQs are welcome
|
12 | sei(); |
13 | |
14 | // main loop
|
15 | while (1) |
16 | {
|
17 | // Arithmetic mean over 2**PP ADC values
|
18 | const uint8_t PP = 4; |
19 | uint16_t adc = 0; |
20 | |
21 | for (uint8_t i = 0; i < (1 << PP); i++) |
22 | {
|
23 | // Start ADC single shot conversion
|
24 | ADCSRA = (1 << ADSC) | ADC_VAL; |
25 | |
26 | // Wait for ADC to complete
|
27 | while (!(ADCSRA & (1 << ADIF))) |
28 | ;
|
29 | |
30 | // Add the ADC value to adc totals
|
31 | adc += ADC; |
32 | }
|
33 | |
34 | // Divide adc totals by 2**PP to get arithmetik mean
|
35 | adc >>= PP; |
36 | |
37 | // The target's nominal voltage: this is why we are here...
|
38 | #define U_SOLL 6.3 // V
|
39 | |
40 | // These values describe the components on the PCB
|
41 | #define R_HI 35.7 // kOhm // high side resistor R1
|
42 | #define R_LO 9.9 // kOhm // low side resistor R4
|
43 | #define U_REF 5.0 // V // U_REF is Vcc and comes from IC2, an LM2936Z-5
|
44 | #define U_CE 0.75 // V // emitter-collector dropout of transistor T1
|
45 | |
46 | #define ADC_RESOLUTION 1024.0
|
47 | #define PWM_RESOLUTION 256.0
|
48 | |
49 | const int32_t K1 = PWM_RESOLUTION * ADC_RESOLUTION * U_SOLL; |
50 | const int32_t K2 = (R_HI+R_LO)/R_LO * U_REF; |
51 | const int32_t K3 = ADC_RESOLUTION * U_CE; |
52 | const uint32_t K4 = PWM_RESOLUTION; |
53 | |
54 | // Compute value for OCR as 32-bit value from adc
|
55 | int32_t ocr_32; |
56 | |
57 | // Be careful with such computations,
|
58 | // do not shorten out `PWM_RESOLUTION' etc and mind the conditioning!
|
59 | ocr_32 = K1 / (K2 * adc - K3); |
60 | ocr_32 = ocr_32 * ocr_32; |
61 | ocr_32 /= K4; |
62 | |
63 | // Trunk 32-bit ocr value to an 8-bit saturated value
|
64 | uint8_t ocr_8 = ocr_32; |
65 | |
66 | if (ocr_32 >= 256) ocr_8 = 255; |
67 | if (ocr_32 < 0) ocr_8 = 0; |
68 | |
69 | // Read actual OCR value
|
70 | uint8_t ocr = OCR0A; |
71 | |
72 | // Soft start the voltage: rise PWM duty slowly,
|
73 | // i.e. increment it just every 4*8 ms.
|
74 | // In startup *and* countdown timer run dry?
|
75 | if (startup && 0 == count_8ms) |
76 | {
|
77 | // Yes:
|
78 | if (ocr < ocr_8) |
79 | {
|
80 | // OCR did not yet reach desired level of `ocr_8':
|
81 | // increment OCR and refuel the 8 ms countdown timer
|
82 | count_8ms = 4; |
83 | ocr++; |
84 | }
|
85 | else
|
86 | // OCR reached the desired level: startup is over
|
87 | startup = 0; |
88 | }
|
89 | |
90 | // After startup?
|
91 | if (!startup) |
92 | {
|
93 | // Yes:
|
94 | // We react faster to a changing input voltage
|
95 | // Note: changing OCR is still slowed down by the ADC
|
96 | if (ocr > ocr_8) ocr--; |
97 | if (ocr < ocr_8) ocr++; |
98 | }
|
99 | |
100 | // Write the new OCR value
|
101 | // OCR will change by -1, 0 or 1
|
102 | OCR0A = ocr; |
103 | |
104 | // Done
|
105 | wdt_reset(); |
106 | } // main loop |
Das zu schreibende SFR ist OCR0A, und obwohl es nur ein 8-Bit Register
ist, wird zur Berechnung 32-Bit-Multiplikation und -Division benötigt.
Auch hier leuchtet mir nicht ein, warum Assembler überlegen sein soll.
Ausser dem Rumwuchten von 32-Bit Werten und Aufrufen der
Arithmetik-Routinen ist nicht viel zu tun.
@Moby: Warum wäre hier Assembler überlegen? Falls dir ein C-Konstrukt
unklar ist, wird es gerne erklärt.
Projekt 2: SMPS-Controller für einen Voltage-boosted Boost Converter
9V= zu -700V= (ATtiny25).
Im Gegensatz zu Projekt 1 implementiert dieses einfache Progamm einen
Regler (bang-bang). Nach der Initialisierung verweilt das Programm in
einer Endlosschleife; die Arbeit geschieht in einer ISR:1 | ...
|
2 | sleep_enable(); |
3 | set_sleep_mode (SLEEP_MODE_IDLE); |
4 | |
5 | sei(); |
6 | |
7 | while (1) |
8 | sleep_cpu(); |
9 | |
10 | SIGNAL (SIG_OVERFLOW1) |
11 | {
|
12 | if (ACSR & (1 << ACO)) |
13 | {
|
14 | // V_sense < V_BG: Output voltage < -600
|
15 | // Stop PWM, disconnect PortPWM from Timer1, PortPWM = LOW
|
16 | PORT_PWM &= ~(1 << BIT_PWM); |
17 | GTCCR = (1 << PWM1B); |
18 | PORT_LED &= ~(1 << BIT_LED); |
19 | }
|
20 | else
|
21 | {
|
22 | // V too low, i.e. V > -600:
|
23 | // Activate PWM, connect PortPWM to Timer1
|
24 | GTCCR = (1 << PWM1B) | (1 << COM1B0); |
25 | PORT_LED |= (1 << BIT_LED); |
26 | }
|
27 | |
28 | // Reset Watchdog-Timer
|
29 | wdt_reset(); |
30 | }
|
@Moby: Wo wäre in diesem Projekt der Vorteil von Assembler zu suchen? Anmerken möchte ich noch, dass ich des AVR-Assemblers durchaus mächtig bin, was z.B. unabdingbar ist um zu avr-gcc beizutragen.
Moby A. schrieb: > Den Asm-Vorteil kann ich gut einschätzen- da brauchts auch keine > tägliche C/C++ Praxis. „Ich kenne zwar nur eine Seite der Medaille, aber ich kann gut einschätzen, was auf der anderen drauf ist.“ Ja ja, bla bla – um deine Worte zu zitieren. Was machst du eigentlich, wenn Atmel den letzten AVR mal irgendwann abkündigt? Angeln gehen? Rennrad fahren?
:
Bearbeitet durch Moderator
P. M. schrieb: > Also: > - Deine Beiträge kriegen durchs Band mindestens 3-5 Downvotes. > - Niemand unterstützt deine Behautungen. Das wird doch nicht etwa die Begründung für Deine unwahren Behauptungen sein? Frank M. schrieb: > Über das Dreirad-Alter sind die meisten hier hinaus. Du hast Dich > wahrscheinlich auf einem Dreirädchen festgeklebt. Putzig, aber stimmt. Viele Problemstellungen sind schneller und gezielter mit dem Asm-Dreirad als dem großen C-Porsche erreicht ;-) Jörg W. schrieb: > Er will sie uns aber nicht zeigen. Er wird schon wissen, warum. Sicher weiß ich das. Freilich aus anderen Gründen als Du jetzt annimmst ;-) Michael K. schrieb: > Du wärst nicht minder erstaunt was der leisten kann wenn Du die gleiche > Krücke in C programmierst. Jedenfalls weniger als mit Asm. Mit C fehlts schneller an Flash, RAM und Speed. > Anstatt die Bemühungen von Atmel entsprechend zu würdigen setzt Du den > AVR nicht bestimungsgemäß ein Wird das jetzt verfolgt? ;-) > Solltest Du jemals Deine Hemmungen überwinden und C eine echte Chance > geben würdest Du wahrscheinlich nie wieder ASM coden wollen. Wahrscheinlich müsste ich mir das vorhalten lassen wenn ich tatsächlich noch nichts mit C programmiert hätte. Hätte, wohlgemerkt. > Genauso kompromisslos, genauso engstirnig und genauso falsch. Kompromisslos Asm. Richtig. Blick aufs Wesentliche: Nämlich das was zur Erfüllung einer Aufgabe im einfachsten Fall nötig ist. > So, Kaffee ist alle. So, schönen Tag noch allen redlichen und unredlichen Diskutanten.
>Hier ginge natürlich auch Assembler, aber der Vorteil von1 | ;; Timer1 in CTC-Mode and prescaled 8 |
2 | LDI r18, (1 << CTC1) | (1 << CS12) |
3 | OUT TCCR1, r18 |
>will mit nicht einleuchten.
Natürlich nicht. Der leuchtet erst ein, wenn Du alle Überlegenheiten von
ASM nutzt:
1 | ;; Timer1 in CTC-Mode and prescaled 8 |
2 | LDI r18, 41 ;; dezimal zur besseren Übersicht der Bits ;-) |
3 | OUT TCCR1, r18 |
Werner P. schrieb: > kann man das TCCR1 nicht auch irgendwie weg optimieren? Klar. Zum Editieren wars nur schon zuspät:
1 | ;; 41 in $39 schreiben |
2 | LDI r18, 41 |
3 | OUT $39, r18 |
Eindeutig überlegen. EDIT: Ich habe die Kommentare noch optimiert.
Werner P. schrieb: > jetzt stört eigentlich nur noch r18 Das ist doch alles viel zu kompliziert.
1 | 11100010001010011011111100101001
|
mfg.
Moby A. schrieb: >> Im Gegensatz zu Dir habe ich und einige andere hier bereits >> Asm-Programme > 10k geschrieben. > > Wie sich manche Leute gewisser Gegensätze so sicher sein können ;-) > Also solltest Du nicht täglich in Asm programmieren behaupte ich jetzt > einfach mal, daß Du meinen Codeumfang übers letzte Jahrzehnt so schnell > nicht toppst. Da darf ich Dir endlich mal aus vollem Herzen Recht geben. Ich bin unendlich glücklich, daß ich in den letzten 10 Jahren Asm fast ausschliesslich als Compiler-Output gesehen habe. Allerdings darfst Du auch sicher sein, daß mein geschriebener Asm-Codeumfang der letzten 3 Jahrzehnte um ein Vielfaches größer ist als Deiner. >> Und wir wissen auch noch sehr genau, >> welche Probleme dann bei der Handoptimierung auftreten. > > Wir wissen ganz genau, daß die handoptimierte Anpassung gerade die > Effizienz von Asm begründet. So man seine Bausteine entsprechend > optimiert zur Verfügung hat = Vorbereitung läuft es oft, über > spezifizierte Register-Schnittstellen = System nur aufs gekonnte > Zusammenstöpseln Und genau dieses System bringt bei großen Programmen gravierende Nachteile bzgl. Codesize und Effizienz. > Wenn Du z.B. einen Baustein für UART-Empfangen und Senden hast, ist > die Anzahl der genutzten UART-Schnittstellen letztlich wurscht. ... weil Du sie für jeden UART mit neuen Registeradressen kopierst. In C schreibst Du die Funktion einmal und übergibst bei Bedarf den Ptr auf die UART-Register. Wenn Du 5 UARTs im System brauchst, dann ist in C die Funktion nur 1* im Flash, und nicht 5 fast identische Asm-Kopien. >> Und im Gegensatz >> zu Dir beherrschen wir zusätzlich zum vollständigen Asm-Instructionset >> auch C/C++ und können die Vorteile bei Ressourcenverbrauch/Performance >> und Entwicklungszeit bei größeren Programmen sehr gut einschätzen. > > Ja ja, bla bla. Den Asm-Vorteil kann ich gut einschätzen- da brauchts > auch keine tägliche C/C++ Praxis. Das warum hab ich weiter oben schon > mal begründet Das blabla kannst Du Dir gerne im Spiegel sagen. Eben den kannst Du nicht einschätzen, da Du weder C/C++ kennst und zumindest bis vor Kurzem noch nicht einmal den kompletten AVR-Befehssatz benutzen konntest. >> Und zu guter letzt kennen viele hier nicht nur AVR, sondern haben schon >> viele andere Architekturen programmiert und wissen es zu schätzen, wenn >> beim Umstieg z.B. von einem 68HC11 auf einen AVR nicht der komplette >> Code neugeschrieben werden muß. > > Zu guter Letzt benötigt die Beherrschung von Asm auf AVR für typische > 8-Bit MSR Aufgaben kein Umherspringen zwischen verschiedenen > Architekturen. Mein bescheidenes Hobbyisten-Beileid all jenen, die das > aus unterschiedlichsten beruflichen Gründen doch tun müssen. ATmega ist in der End-of-live-Phase, der Preis geht eher wieder hoch, es sind mittlerweile viel performantere 32-Bitter für deutlich weniger Geld zu bekommen. Von den Chips, die ich (in Asm) programmiert habe, ist die Mehrzahl nicht mehr erhältlich. Ich nehme mal an, daß dieses Schicksal Dich beim Atmega in den nächsten 10 Jahren nicht ereilt. Trotzdem hat es wenig mit Effizienz und Sparsamkeit zu tun, für einen Uralt-Chip mehr zu zahlen als für die performantere Nachfolger-Generation. Stefan
Moby A. schrieb: >> Über das Dreirad-Alter sind die meisten hier hinaus. Du hast Dich >> wahrscheinlich auf einem Dreirädchen festgeklebt. > > Putzig, aber stimmt. Viele Problemstellungen sind schneller und > gezielter mit dem Asm-Dreirad als dem großen C-Porsche erreicht ;-) Klar, wenn die Aufgabe nur darin besteht, im Kindergarten einmal um die große Linde zu kurbeln, dann fragt man sich schon, warum man sich die Mühe mit dem Auto fahren lernen machen soll. >> Solltest Du jemals Deine Hemmungen überwinden und C eine echte Chance >> geben würdest Du wahrscheinlich nie wieder ASM coden wollen. > > Wahrscheinlich müsste ich mir das vorhalten lassen wenn ich tatsächlich > noch nichts mit C programmiert hätte. Hätte, wohlgemerkt. Nicht einsteigen. Motor starten. Motor abwürgen. "So ein Scheiss, ich will mein Dreirad wieder". Das ist kein Lernen, das ist Vorurteile festigen.
:
Bearbeitet durch User
Werner P. schrieb: > Matthias L. schrieb: >> LDI r18, 41 > > jetzt stört eigentlich nur noch r18 Das haben wir gleich ;-)
1 | LDI $12, 41 |
2 | OUT $39, $12 |
Absolut Mobyoptimal, klar, selbsterklärend, und nicht durch den globigen C-Compiler völig aufgebläht und langsam. Das sind eindeutig Vorteile von ASM!
:
Bearbeitet durch User
Moby A. schrieb: > Sheeva P. schrieb: >> Wie lustig, da kann einer seine Niederlage und sein eigenes mieses >> Verhalten nicht ertragen und exkommuniziert mich. :-) > > Du weißt glaub ich auch nicht, zwischen welcher Stimmungslage Du Dich > entscheiden sollst: Künstlich belustigt oder empört... > > Deine langatmigen Rechtfertigungstiraden werden von Deinem Versagen bei > einem einfachen C-Programm jedenfalls kaum ablenken. > > Du solltest Dich mit Deiner Geschichte in einem eigenen Thread über den > bösen Moby und seine schlimmen Machenschaften auskotzen ;-) Und schwupps, bin ich wieder ex-exkommuniziert. Und zwar haargenau so, wie es Thomas weise vorhergesagt hatte. Herrlich! :-))
Moby A. schrieb: > Wir wissen ganz genau, daß die handoptimierte Anpassung gerade die > Effizienz von Asm begründet. So man seine Bausteine entsprechend > optimiert zur Verfügung hat = Vorbereitung läuft es oft, über > spezifizierte Register-Schnittstellen = System nur aufs gekonnte > Zusammenstöpseln = Übung dieser Bausteine hinaus- deshalb ist es auch > Unsinn, daß die Komplexität über die Codesize über alle Maßen anwachsen > muß. Wenn Du z.B. einen Baustein für UART-Empfangen und Senden hast, ist > die Anzahl der genutzten UART-Schnittstellen letztlich wurscht. Zusammengefasst: Du schreibst einen ASM Block und kopierst den so oft wie Du den brauchst. Der C Compiler würde jetzt erkennen ob er was wieder benutzen kann oder alles inline macht. Er würde auch je nach Optimierungseinstellung auf Speed oder auf Größe optimieren und zwar innerhalb von Sekunden je nachdem was du gerade möchtest. Kannst Du das unabhängig von der Codegröße auch ? Du sagst zum einen das ASM viel schneller zu lernen ist als C, was m.E. nicht stimmt, und zum anderen sagst Du das ASM nur bei jahrelanger Vorbereitung, also dem Vorhandensein handoptimierter Codeblöcke für unterschiedlichste Aufgaben, seinen Geschwindigeitsvorteil ausspielen kann. Den wiederum willst Du ausspielen indem Du stumpf Blöcke zusammenstöpselst, also etwas tust das Du C vorwirfst. Hab ich das in etwa richtig verstanden ? Moby A. schrieb: > Zu guter Letzt benötigt die Beherrschung von Asm auf AVR für typische > 8-Bit MSR Aufgaben kein Umherspringen zwischen verschiedenen > Architekturen. Genau, solange man bei AVR bleibt muß man nicht zwischen den Architekturen herumspringen. Ja, und Nachts ist es kälter als draussen. > Mein bescheidenes Hobbyisten-Beileid all jenen, die das > aus unterschiedlichsten beruflichen Gründen doch tun müssen. Nicht doch, ist dank C ja kein Problem. Würde mich viel mehr nerven wenn ich bei der immer gleichen beschränkten Krücke bleiben müsste nur weil ich alles neu lernen müsste bei einem Wechsel. > typische 8-Bit MSR Aufgaben Bedeutungen für 'typisch': [1a] einen bestimmten allgemeinen Typ verkörpernd [1b] für einen bestimmten Typ charakteristisch [2] veraltet: als Muster/Vorbild geltend Wenn Du von typischen 8bit MSR Aufgaben sprichst, aber alles was der Rest der Welt als typisch erachtet nicht gelten läßt, welche neue Definition des Wortes 'typisch' setzt Du dann an ? Interessanterweise wird es immer da 'untypisch' wo C gegenüber ASM klare Vorteile hat, auch auf 8bit.
Moby A. schrieb: > Ja ja, bla bla. Den Asm-Vorteil kann ich gut einschätzen- da brauchts > auch keine tägliche C/C++ Praxis. Bla bla. Um die Vor- und Nachteile von zwei oder mehr verschiedenen Optionen einschätzen zu können, muß man sie ausreichend gut kennen um sich ein Urteil bilden zu können. Genau das ist bei Dir aber nicht der Fall, und deswegen kaprizierst Du Dich auf einen winzigen Ausschnitt der Realität, der für die meisten anderen hier vollkommen unerheblich ist, aber leider übersteigt das Deinen Horizont genauso wie C und Assembler. :-)
Moby A. schrieb: > Markus M. schrieb: >> Moby ist froh, dass es so eine einfache Sprache wie ASM gibt, weil er >> für Hochsprachen unzugänglich und unfähig ist, sie zu erlernen. > > Nö, bin ich nicht. Aber im Hinterkopf ist da so ein lästiger Gedanke: > Muß das jetzt wirklich so umständlich und ineffizient programmiert > werden oder gehts doch einfacher? Genau das hatte ich auch im Hinterkopf, als ich von ASM kommend C zu lernen begonnen habe und inzwischen froh bin, meinen eigenen Schweinehund überwunden zu haben. Moby, du kannst hier gar nicht mitreden. Schau dir mal ASM Projekte von Bernhard S. an (ja, der mit den UKW-RDS Gedöns;-) Dieser Mann beherrscht ASM, liefert komplexe Sachen ab, bereichtert die Gemeinde mit guten Projekten. DU prahlst mit deinen 200Byte Gefrickel was von Überlegenheit. Was sollte der Bernhard dann sagen? Nein, er macht sich nicht lächerlich, weil er programmieren kann. Moby A. schrieb: > Zu guter Letzt benötigt die Beherrschung von Asm auf AVR für typische > 8-Bit MSR Aufgaben kein Umherspringen zwischen verschiedenen > Architekturen. Verstehe diese Wortanhäufung nicht. Moby A. schrieb: > Ja ja, bla bla. Den Asm-Vorteil kann ich gut einschätzen- da brauchts > auch keine tägliche C/C++ Praxis. Das warum hab ich weiter oben schon > mal begründet Als Programmierer sollte man doch eigentlich logisch denken können... Moby A. schrieb: > Michael K. schrieb: >> Du wärst nicht minder erstaunt was der leisten kann wenn Du die gleiche >> Krücke in C programmierst. > > Jedenfalls weniger als mit Asm. Mit C fehlts schneller an Flash, RAM und > Speed. Das sagt einer, der noch nie eine Zeile C geschrieben hat. Aussagewert = ??? Lächerlich, einfach nur lächerlich. Und ich behaupte jetzt, dass auch alle deine 200Byte Projektchen in C effektiver zu programmieren sind.
:
Bearbeitet durch User
Michael K. schrieb: > Zusammengefasst: > Du schreibst einen ASM Block und kopierst den so oft wie Du den > brauchst. > Der C Compiler würde jetzt erkennen ob er was wieder benutzen kann oder > alles inline macht. Er würde auch je nach Optimierungseinstellung auf > Speed oder auf Größe optimieren und zwar innerhalb von Sekunden je > nachdem was du gerade möchtest. > Kannst Du das unabhängig von der Codegröße auch ? Das kann er nicht, das versteht er nicht, das will er nicht. Moby hat seine eigene Definition von 'optimal'.
Jörg W. schrieb: > Moby A. schrieb: >> Den Asm-Vorteil kann ich gut einschätzen- da brauchts auch keine >> tägliche C/C++ Praxis. > > „Ich kenne zwar nur eine Seite der Medaille, aber ich kann gut > einschätzen, was auf der anderen drauf ist.“ > > Ja ja, bla bla – um deine Worte zu zitieren. ;-) > Was machst du eigentlich, wenn Atmel den letzten AVR mal irgendwann > abkündigt? Angeln gehen? Rennrad fahren? Den armen Anglern erzählt er dann, wie verschwenderisch das Angeln mit Rute und Rolle ist, wo doch -- mit "Übung, Vorbereitung, System", was außer ihm natürlich niemand hat -- Stock und Zwirn reichen. Und die armen Radfahrer müssen sich dann anhören, wie blöd diese Fahrräder mit Gangschaltung sind, weil er damit mal auf die Nase gefallen ist! ;-)
Markus M. schrieb: > Und ich behaupte jetzt, dass auch alle deine 200Byte Projektchen in C > effektiver zu programmieren sind. Das ist leicht. Gibt ja nur eins. Oh, halt ... leider ohne Spec. also nix wert.
Ralf G. schrieb: > Moby hat seine eigene Definition von 'optimal'. Nicht nur das. Die ist vor allem sehr dynamisch. mfg.
Moby A. schrieb: > Den Asm-Vorteil kann ich gut einschätzen- da brauchts auch keine > tägliche C/C++ Praxis. CP Rn,Rn BRNE $-2 > Moby hat seine eigene Definition von 'optimal'. Das ist nur die böse, in C++ geschriebene Rechtschreibhilfe. Eigentlich sollte es mobtimal heißen.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten