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