Moby A. schrieb:> Sheeva P. schrieb:>> Aber Assembler ist Spaghetticode by Design; es gibt da schlicht und>> einfach keine Struktur und auch keine Sprachmittel, um das Programm zu>> strukturieren.>> ... sprach der Experte ;-)
Du bist ja doch zuem Erkenntnisgewinn fähig. Diese Hoffnung hatte ich
fast schon verloren gegeben. ;-)
> Du redest auch viel wenn der Tag lang ist, oder?
Nein, manchmal rede ich auch an kurzen Tagen viel und an langen Tagen
wenig, da bin ich absolut flexibel.
> Zeig mal was Konkretes, das man auch ernst nehmen könnte ;-)
Warum denn? Du würdest es doch ohnehin nicht verstehen. Davon abgesehen
bist natürlich zuerst einmal Du an der Reihe, was Ernstzunehmendes zu
zeigen. ;-)
Moby A. schrieb:> Mir kommts vor allem auf Eines an: Keep it simple.
Ach Quatsch, dann würdest Du ja C oder C++ benutzen.
> Wogegen ich mich nur wende ist die These vom besseren C-Code> gegenüber Asm.
Du wendest Dich also gegen etwas, das nie jemand behauptet hat.
Bitte grüß' Dulcinea und Sancho.
Gu. F. schrieb:> Michael K. schrieb:>> Doch doch, ich versteh das Problem schon.>> Du fühlst Dich in Deinem Stolz verletzt und mußt das jetzt unbedingt>> richtigstellen.>> Unmöglich aufzuhören bis Moby sich endlich mit einem Strauß Blumen in>> der Hand bei Dir entschuldigt hat.>> Du bist entweder krank oder Mobys zweit Account. tststs.
Es steht mir als Neuling und Wenig-Leser bzw. -Schreiber hier sicherlich
nicht an, Vorschläge zu machen. Aber wundern wird man sich hoffenlich
noch dürfen. Es wundert mich nämlich, mit welcher Inbrust einerseits auf
schlimmstenfalls thematisch verfehlte Beiträge eines einzelnen
Vielschreibers durch demonstratives Löschen reagiert wird, solche groben
Entgleisungen wie die da oben hingegen kommentarlos toleriert werden.
Und, nein, ich bin weder ein Alias von "Mobi AVR" noch von Michael
Knoelke (bloß um eine weitere vorhersehbaren Giftelei vorwegzunehmen).
Ich fand lediglich seine Beiträge bis hierhin (weiter habe ich bisher
nicht gelesen) ausgesprochen ausgewogen und neutral. Erstaunlich, daß
ausgerechnet das dann offenbar besonders provokant erscheint.
Um nun auch was zum Themal selber zu sagen: Wenn man nach ein wenig
Fortran und PL/I vor zig Jahren seine ersten umfangreicheren
Programmierarbeiten mit Simula 67 und Snobol/Spitbol erledigt hat, dann
kann man über die verbalen Schlachten zwischen Fans von Asm hier und C
dort nur schmunzeln. Dann erinnert man sich nämlich an auch schon lange
zurückliegendes, aber ähnlich verbissenes Geläster von Verfechtern
echter Hochsprachen über diesen schlichten Quasiassembler, der sich als
Hochsprache aufspielt. 1/2 :)
A. K. schrieb:> Also übersichtlicher als so geht's doch kaum:> 1⌈2> 2> 2⌈1> 2> ⌈/1 2 3 4 5 3 8 1 3> 8
Niedlich, APL. Ich habe hier irgendwo noch einen Kugelkopf rumliegen ...
Johann L. schrieb:> und der Durchmesser ist wievel Meter?
Völlig harmlos. Es gibt keine Kleinbuchstaben und viele Operatoren
entstehen durch Übereinanderdruck zweier anderer.
A. K. schrieb:> und viele Operatoren entstehen durch Übereinanderdruck zweier anderer.
So habe ich mit meinem ersten elektromechanischen Druckwerk (im Prinzip
eine „elektrische“ Schreibmaschine, deren Tasten durch Zugmagneten
angesteuert werden konnten) auch die geschweiften Klammern gedruckt. ;-)
Eine eckige Klammer, einen Backspace (der eine ganze Umdrehung der
Motorwelle braucht :), danach eine Spitzklammer (aka. kleiner/größer
als).
:.)
Aber wir sollten wohl besser einen separaten APL-Thread dafür dann
öffnen. Hier geht's ja schließlich darum, dass Assembler jetzt auf
dem Vormarsch ist.
A. K. schrieb:> Wenn er alles abgezogen hat, was er für unnötig oder> viel zu kompliziert hält und was man davon sowieso nicht braucht, dann> passt es auch in die Hälfte rein. So optimiert man Code.
... der dann die gestellte Aufgabe immer noch erfüllt ;-)
Versteh ich nicht! Trollthreads mit echt guten und lustigen Ideen mit
Potential zu entspannter Unterhaltung werden sofort gelöscht und so ein
Scheisdreck (jaja, mit Verlaub und so...) wird hier ewiglich geduldet
:-D Humorloses Volk :-D
Carl D. schrieb:> Alles was M. schreibt ist ein Fakt. Alles was andere schreiben
... überzeugt wenig, wenn's nicht mit Code bewiesen werden kann.
Markus M. schrieb:> Wie ein kleines Kind vom Sandkasten nebenan doch die halbe Welt> beschäftigen kann .... Wieso antwortet ihr überhaupt?
Sandkasten. Gutes Stichwort. Da sitzt eher mancher Sprücheklopfer hier
;-)
Sheeva P. schrieb:> Als ich meinen> Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue> Anforderungen aus dem Hut gezaubert.
Der war gut ;-)
Nackte Panik. Was man da alles rauslesen kann wenn es unbedingt sein
muß...
Nö. Du schimpfst wie ein Rohrspatz, um von Deiner gradios gescheiterten
C-Programmruine, die Du da in meinen Projektthread reingestellt hast
abzulenken. Die ist nun als weithin sichtbares Monument Deiner (Nicht-)
Fähigkeiten zu bewundern.
Also zu meiner Ehre hätte ja gehört, Fehler nicht nur zuzugeben,
sondern ein einmal angefangenes Werk auch mit erhobenem Haupt zu Ende zu
bringen... Das hätte Dir auch keiner abgerissen wenn Du das bekannte
Ziel nicht erreicht hättest. Alle Infos zur Realisierung waren da, keine
der ganz wenigen Fragen blieb unbeantwortet (mit meinem Verweis auf
längst Bekanntes natürlich). Sogar gratis Hardware hatte ich Dir zur
Unterstützung angeboten... Statt dessen höre ich jetzt nur albernste
Ausreden.
Wolfgang S. schrieb:> Ich fand lediglich seine Beiträge bis hierhin (weiter habe ich bisher> nicht gelesen) ausgesprochen ausgewogen und neutral. Erstaunlich, daß> ausgerechnet das dann offenbar besonders provokant erscheint.
Wahrheiten die man nicht zur Kenntnis nehmen will können schon sehr
provokant wirken. Den Ertappten ist dann kein Mittel zu schade, den
Störenfried zur Ruhe zu bringen. Das ist allerdings eine etwas zähe
Angelegenheit, wenn dieser seine Behauptungen mit Code untermauert- und
wird zu einem echten Ärgernis, wenn man dann als großartiger C-Profi
nicht gegenhalten kann. Ertappt halt, das ist echt unangenehm ;-)
Moby A. schrieb:> Sheeva P. schrieb:>> Als ich meinen>> Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue>> Anforderungen aus dem Hut gezaubert.>> Der war gut ;-)
Das ist kein Witz, sondern eine Tatsache. Wenn du deine Anforderungen
klar aufgelistet hättest, wäre schon lange ein C/C++ Programm
rausgehauen worden, das auch deinen Anforderungen entspricht. Ein
ASM-Listing und Frasen wie "das ist doch jeden klar" zählen nicht als
Anfroderung, aber das hast du ja schon im entsprechenden Thread nicht
begreifen wollen. Nachträglich als Anferderung zu definieren, dass kein
RAM, das nicht als Register bezeichnet wird, verwendet werden darf,
zeugt nicht gerade von Fairness.
Moby A. schrieb:> Wahrheiten die man nicht zur Kenntnis nehmen will können schon sehr> provokant wirken. Den Ertappten ist dann kein Mittel zu schade, den> Störenfried zur Ruhe zu bringen.
Das spiegelt eher dein Verhalten wieder, siehe meine Erläuterungen oben
im Beitrag.
Moby A. schrieb:> Das ist allerdings eine etwas zähe> Angelegenheit, wenn dieser seine Behauptungen mit Code untermauert- und> wird zu einem echten Ärgernis, wenn man dann als großartiger C-Profi> nicht gegenhalten kann.
Doch, doch, wir können alle sehr gut gegenhalten, nur haben wir alle
schon lange erkannt, dass dieses Vorhaben nie Früchte tragen wird und
nutzen diesen Umstand, um uns zu amüsieren.
> Carl D. schrieb:>> Alles was M. schreibt ist ein Fakt. Alles was andere schreiben>> ... überzeugt wenig, wenn's nicht mit Code bewiesen werden kann.
Es ist nur unter seriösen Wettstreitern so, daß der, der die Behauptung
aufstellt, sie auch beweisen muß. Und die Ausgangsbehauptung ist:
"ASM ist für 8-Bit-MC-Projekte immer besser"
Un diesen Beweis kann man führen, indem man nachweist, daß daß JEDES
ASM-Projekt besser ist, oder ein nicht-ASM-Projekt schlechter. Ersteres
zählt zu den großen Problemen der Informatik, zweiteres sollte doch für
jemanden, der so überzeugt davon ist, kein Problem sein.
Alternativ kann man natürlich die These auch einfach unbewiesen stehen
lassen, dann ist sie aber auch kein Fakt.
(M.'s Verfahren wird nun wieder sein, einige Posts später Bruchstücke
davon zu zitieren und ins Lächerliche zu ziehen. Aber alle hacken ja nur
auf ihm rum :-(( )
be s. schrieb:> Nachträglich als Anferderung zu definieren, dass kein> RAM, das nicht als Register bezeichnet wird, verwendet werden darf,> zeugt nicht gerade von Fairness.
Unfug. Register hat jeder AVR die gleichen 32 an der Zahl. Im
wertvollen, zusätzlichen SRAM unterscheiden sie sich. Der zählt
selbstverständlich zu den einzusparenden Ressourcen für einen
ordentlichen Vergleich. Das Projektchen ist dermaßen einfach, daß schon
in meinen ersten Beiträgen funktionell eigentlich alles klar war.
Dennoch findet sich im Thread nochmal eine Anforderungs-Liste die alle
Gegebenheiten klarstellt. Ändert aber auch nix... Infos bis zum
Erbrechen, die manche Leute oh Wunder einfach nicht zur Kenntnis nehmen
können. Das muß irgendeine Wahrnehmungsstörung sein ;-(
Nennen wir doch das Kind beim Namen: C bringts (hier und anderswo)
einfach nicht !
> Doch, doch, wir können alle sehr gut gegenhalten
Hab schon besser gelacht. Lustig ist aber, wie einzelne hier immer für
"alle" und "uns" sprechen. Na ja, Gleichgesinnte sollten einfach wieder
und wieder einander versichern und sich trösten, das scheint hier auch
besonders nötig zu sein ;-)
Aber schön, wenn die Unterhaltung auf Gegenseitigkeit beruht, da sind
wir "uns" ja mal einig ;-)
Moby A. schrieb:> Sheeva P. schrieb:>> Als ich meinen>> Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue>> Anforderungen aus dem Hut gezaubert.>> Der war gut ;-)
Das kann ja jeder im besagten Thread nachlesen. :-))
> Nackte Panik. Was man da alles rauslesen kann wenn es unbedingt sein> muß...> Nö. Du schimpfst wie ein Rohrspatz, um von Deiner gradios gescheiterten> C-Programmruine, die Du da in meinen Projektthread reingestellt hast> abzulenken.
Ach, Moby, lernst Du es denn nie? Es wird Dir nicht gelingen, mich zu
provozieren. Das können nur Leute, die ich ernst nehme.
> Die ist nun als weithin sichtbares Monument Deiner (Nicht-)> Fähigkeiten zu bewundern.
Meine Fähigkeiten können andere anhand meines Code beurteilen, ansonsten
gilt weiterhin das bereits Gesagte:
Als ich meinen Code gepostet habe, hast Du geradezu panisch reagiert und
plötzlich neue Anforderungen aus dem Hut gezaubert. Du hast behumst, und
daraufhin habe ich die Sache abgebrochen und mich den schöneren Dingen
in meinem Leben zugewandt. Warum sollte ich weiter denn mit einem
Betrüger spielen? Ich hatte alles bewiesen, was zu beweisen war. :-)
A. K. schrieb:> Moby A. schrieb:> Unfug. Register hat jeder AVR die gleichen 32 an der Zahl.>> Fast jeder.
Ok, fast jeder. Ändert aber jetzt auch nix.
Carl D. schrieb:> Es ist nur unter seriösen Wettstreitern so, daß der, der die Behauptung> aufstellt, sie auch beweisen muß. Und die Ausgangsbehauptung ist:> "ASM ist für 8-Bit-MC-Projekte immer besser"
Wenn Du seriös argumentieren würdest hättest Du zur Kenntnis genommen,
warum ich das Projekt derart positioniert habe: Als von vielen
geforderten Beispielcode, um meine Aussagen in anderen Threads zuvor zu
belegen und die Apostel der C-Überlegenheit Lügen zu strafen.
Bitteschön. Aber es kam ja wie es kommen musste: Außer (z.T. recht
hohlem) Reden nix gewesen ;-)
Moby A. schrieb:> Dennoch findet sich im Thread nochmal eine Anforderungs-Liste die alle> Gegebenheiten klarstellt.
Hallo Moby,
könntest Du bitte die Stelle im Thread zeigen. Ich finde nichts.
Vielleicht sehe ich vor lauter Bäume den Wald nicht.
Danke
A. K. schrieb:> Moby A. schrieb:> Unfug. Register hat jeder AVR die gleichen 32 an der Zahl.>> Fast jeder.
Ok, fast jeder. Ändert aber jetzt auch nix.
Carl D. schrieb:> Es ist nur unter seriösen Wettstreitern so, daß der, der die Behauptung> aufstellt, sie auch beweisen muß. Und die Ausgangsbehauptung ist:> "ASM ist für 8-Bit-MC-Projekte immer besser"
Wenn Du seriös argumentieren würdest hättest Du zur Kenntnis genommen,
warum ich das Projekt derart positioniert habe: Als von vielen
geforderten Beispielcode, um meine Aussagen in anderen Threads zuvor zu
belegen und die Apostel der C-Überlegenheit Lügen zu strafen.
Bitteschön. Aber es kam ja wie es kommen musste: Außer (z.T. recht
hohlem) Reden nix gewesen ;-)
Sheeva P. schrieb:> Ich hatte alles bewiesen, was zu beweisen war
Solange Du an diesen Quatsch glauben magst tu es doch. Bleibt Dir zur
Rechtfertigung wohl nichts anderes übrig... Aber glaub mir, da hab ich
schon überzeugendere Vorstellungen erlebt ;-)
Werner P. schrieb:> Hallo Moby,>> könntest Du
Nein, Moby kann nicht.
Die explizite Funktions-Liste darfst Du selber finden.
Und nein, da steht nix von SRAM.
Das war wie minimaler Flash-Verbrauch = Teil der MC-Ressourcen als
selbstverständlich für einen anständigen Vergleich vorausgesetzt...
Weil sich daran manche C-Gemüter entzünden scheint es DER Pferdefuß von
C zu sein ;-)
Moby A. schrieb:> be s. schrieb:>> Nachträglich als Anferderung zu definieren, dass kein>> RAM, das nicht als Register bezeichnet wird, verwendet werden darf,>> zeugt nicht gerade von Fairness.>> Unfug. [...]> Nennen wir doch das Kind beim Namen: C bringts (hier und anderswo)> einfach nicht !
Du selbst bist es, der es (hier und anderswo) nicht bringt. Deswegen
bist Du auch mit einer so einfachen Sprache wie C schon dermaßen
überfordert, daß Du schon nach einem einzigen aufgegeben hast. Aber
anstatt nun zuzugeben, daß nur Du selbst zu faul oder zu unfähig warst,
beschuldigst Du einfach die Programmiersprache und arbeitest Deinen Neid
an ihren Nutzern ab...
Schon klar: wenn Du nicht schwimmen kannst, ist die Badehose schuld. :-)
> Aber schön, wenn die Unterhaltung auf Gegenseitigkeit beruht, da sind> wir "uns" ja mal einig ;-)
Soweit es mich betrifft, muß es "Ihr" und "Euch" heißen; an Deinem "wir"
oder "uns" möchte ich mich ausdrücklich ausschließen. Danke.
Moby A. schrieb:> A. K. schrieb:>> Moby A. schrieb:>> Unfug. Register hat jeder AVR die gleichen 32 an der Zahl.>>>> Fast jeder.>> Ok, fast jeder. Ändert aber jetzt auch nix.Fast nix.
> könntest Du bitte die Stelle im Thread zeigen. Ich finde nichts.> Vielleicht sehe ich vor lauter Bäume den Wald nicht.
Hies es nicht:
Keiner hat vor ein eindeutige Projektanforderung zu schreiben.
Sheeva P. schrieb:> Deswegen> bist Du auch mit einer so einfachen Sprache wie C schon dermaßen> überfordert, daß Du schon nach einem einzigen aufgegeben hast.
"Überforderung" hatte ich gerade in irgend einem anderen Zusammenhang im
Gedächtnis ;-)
Na ja "aufgeben" würde ich das nicht nennen- eher die Rückkehr ins
bewährt-Einfache! Mit dem C-Programm hab ich mir derart einen
abgebrochen daß ich bis Ende meiner Tage kuriert bin. Immerhin, ich habs
vollständig bis zur fehlerfreien Endversion durchgezogen ;-)
> Danke.
Bitte.
@ Sheeva Plug (sheevaplug)
>Schon klar: wenn Du nicht schwimmen kannst, ist die Badehose schuld. :-)
Wieso Badehose? Moby ist nackt, wie Gott ihn schuf! Also
programmiertechnisch gesehen ist er noch im ASM-Paradies, er hat noch
nicht vom Baum der Hochsprachenerkenntnis genascht (C) und somit wurde
er auch noch nicht aus dem Paradies vertrieben! Der Glückliche! Der hast
sich nicht vom Weibe (Ada?) verführen lassen!
Amen!
Moby A. schrieb:> Na ja "aufgeben" würde ich das nicht nennen- eher die Rückkehr ins> bewährt-Einfache! Mit dem C-Programm hab ich mir derart einen> abgebrochen daß ich bis Ende meiner Tage kuriert bin. Immerhin, ich habs> vollständig bis zur fehlerfreien Endversion durchgezogen ;-)
Hallo Moby,
dann existiert ja ein von Dir erstelltes und lauffähiges C-Programm.
Wäre nett wenn Du den Source zur Verfügung stellst.
Grüße, Werner
> Moby A. schrieb:>> A. K. schrieb:>>> Moby A. schrieb:>>> Unfug. Register hat jeder AVR die gleichen 32 an der Zahl.>>>>>> Fast jeder.>>>> Ok, fast jeder. Ändert aber jetzt auch nix.>> Fast nix.
Typische 8-Bit-MSR-Projekte nutzen kein 6-Pin-AVR's.
Da funktioniert ja der Register-Allokator nicht mehr.
Falk B. schrieb:> er hat noch> nicht vom Baum der Hochsprachenerkenntnis genascht (C)
Genau so wie beschrieben ;-)
Also "Naschen" ist dann doch was anderes,
der sperrige umständliche C-Blähcode lag mir schwer im Magen.
Werner P. schrieb:> Hallo Moby,>> dann existiert ja ein von Dir erstelltes und lauffähiges C-Programm.> Wäre nett wenn Du den Source zur Verfügung stellst.>> Grüße, Werner
Hallo Werner,
hast Du die Funktionsliste schon gefunden oder stellst Du hier nur
rhetorische Testfragen?
Grüße, Moby
Moby A. schrieb:> Werner P. schrieb:>> Hallo Moby,>>>> dann existiert ja ein von Dir erstelltes und lauffähiges C-Programm.>> Wäre nett wenn Du den Source zur Verfügung stellst.>>>> Grüße, Werner>> Hallo Werner,>> hast Du die Funktionsliste schon gefunden oder stellst Du hier nur> rhetorische Testfragen?>> Grüße, Moby
Hallo Moby,
nein, habe ich noch nicht gefunden. Kein Wunder bei der Länge des
Threads ;-)
Der C-Code wäre von Vorteil da ich in C und nicht in ASM programmiere.
Grüße, Werner
PS: Ich habe nicht die Absicht rhetorische Fragen zu stellen. Mich
interessiert einfach nur der C-Code.
Werner P. schrieb:> Mich> interessiert einfach nur der C-Code
Ich denk mal da hast Du gerade was falsch verstanden !?
Es handelt sich nicht um C-Code für mein Tiny13 Projekt worauf ich
selber warte sondern meinen ersten und einzigen (war was für PC
DOS-Kommandozeile). Dafür wirst Du Dich jetzt weniger interessieren...
Moby A. schrieb:> Werner P. schrieb:>> Mich>> interessiert einfach nur der C-Code>> Ich denk mal da hast Du gerade was falsch verstanden !?> Es handelt sich nicht um C-Code für mein Tiny13 Projekt worauf ich> selber warte sondern meinen ersten und einzigen (war was für PC> DOS-Kommandozeile). Dafür wirst Du Dich jetzt weniger interessieren...
ah, ok.
Moby A. schrieb:>> Robert L. schrieb:>> und JA man Programmiert ja absichtlich "Moby"-Ineffizient..>> du bist nur der einzige der damit ein Problem hat ;-)>> S.O. Beweisen bitte ;-)>
??
ich schreib
dass ich absichtlich! mehr speicher (Flash, RAM..) verbrauche als
unbedingt (theoritisch) notwendig wäre
und ich soll jetzt beweisen, dass du ein Problem damit hast??
...
Moby A. schrieb:>Mit dem C-Programm hab ich mir derart einen>abgebrochen daß ich bis Ende meiner Tage kuriert bin. Immerhin, ich habs>vollständig bis zur fehlerfreien Endversion durchgezogen ;-)
Du meinst sicher sowas...
Moby A. schrieb:> Mit dem C-Programm hab ich mir derart einen> abgebrochen daß ich bis Ende meiner Tage kuriert bin.
Das scheint hier das eigendliche Problem zu sein.
Viele Grüße, Stefan
Und Assembler scheint auch nur deshalb leidlich zu funktionieren, weil
Du die Teile des Befehlssatzes, die Du nicht verstehst, einfach
ausblendest.
"Effizient programmieren" ist bei Dir nur ein Synonym für "Ich
programmiere nur das, was ich bereits kann". Denn natürlich ist Lernen
immer mit Aufwand verbunden, der beim ersten Projekt noch nicht wieder
reingeholt wird - und dieses damit "ineffizient" macht.
Stefan
Falk B. schrieb:> @ Sheeva Plug (sheevaplug)>>>Schon klar: wenn Du nicht schwimmen kannst, ist die Badehose schuld. :-)>> Wieso Badehose? Moby ist nackt, wie Gott ihn schuf! Also> programmiertechnisch gesehen ist er noch im ASM-Paradies, er hat noch> nicht vom Baum der Hochsprachenerkenntnis genascht (C) und somit wurde> er auch noch nicht aus dem Paradies vertrieben! Der Glückliche! Der hast> sich nicht vom Weibe (Ada?) verführen lassen!>> Amen!
Hätte ich denn schreiben sollen, daß dann die Sackhaare schuld sind? Das
ist hier ja wohl immer noch ein Familienforum!
Moby A. schrieb:> Ich denk mal da hast Du gerade was falsch verstanden !?> Es handelt sich nicht um C-Code für mein Tiny13 Projekt worauf ich> selber warte sondern meinen ersten und einzigen (war was für PC> DOS-Kommandozeile). Dafür wirst Du Dich jetzt weniger interessieren...
Ach, da haben wir ja dein eigentliches Problem.
Du bist seit zig Jahren festgefahren in deinem Handeln, bist außerdem
schon ein wenig älter, da fällt das Lernen nicht mehr ganz so leicht.
Irgendwann hast du dann doch mal beschlossen dir dieses ominöse "C", von
dem alle sprechen, doch mal genauer anzuschauen.
Du hast also bisl lustlos irgendwo quergelesen, irgendwie dein Programm
durch den Compiler gekriegt, und plötzlich - ging nix!
Hinten und vorne keinen Plan was du da eigentlich machst hast du mit der
Fehlersuche begonnen und wärst fast daran verzweifelt.
Daraufhin hast du dann beschlossen, dieses C abgrundtief zu hassen. So
ein unleserlicher, fehlerträchtiger Rotz!
Aber halt: es gibt Millionen Leute da draussen, die seit geraumer Zeit
Millionen von funktionierenden, wartbaren C-Programmen schreiben.
Das passt nicht ganz ins Weltbild, denn nichts ist so schwer wie sich
einzugestehen, dass man selbst an einer Hürde gescheitert ist die viele
andere locker gepackt haben.
Also werden diese erfolgreichen Programmierer kurzerhand zu
fehlgeleiteten Wesen erklärt. Arme, verirrte Wanderer oder Masochisten
die einzig deswegen in C programmieren weil sie nie das Glück hatten,
das Assembler-Licht zu sehen.
Weißt du Moby,
du erinnerst mich an mich selbst bevor ich studiert hatte.
Ich hatte ein wenig in QBasic (unter Win3.1) herumgespielt.
Ums kurz zu machen: ich hatte von Tuten und Blasen keine Ahnung, hielt
mich aber für den größten Hacker weil ich die Übungen im
Informatikunterricht immer am schnellsten erledigt hatte.
Dann im Studium wurde ich mit diesem kryptischen C konfrontiert. Und
weißt du was? Ich hab genauso reagiert wie du. Was hab ich geschimpft,
dass wir diese anachronistische, kryptische Uraltsprache lernen mussten!
Nicht mal die Farbe der Kommandozeilenausgabe kann man mit einem simplen
"COLOR 1, 2" umstellen! Von den dummen Pointern garnicht zu reden!
Meinen Kommilitonen hab ich die ganze Zeit erzählt wie toll und einfach
das doch alles in QBasic wäre.
Was war ich für ein unwissender, launischer, kleiner Junge...
Aber irgendwann hatts Klick gemacht. Mir blieb auch garnichts anders
übrig, mussten wir doch die Übungen des Dozenten abgeben.
Und als ich mit den AVR anfing hab ich nur deswegen C benutzt weil ja
schon rudimentäre Kenntnisse vorhanden waren.
Allerdings hatte ich bei diesen privaten Projekten echtes Interesse an
der Umsetzung, was man von den Uni-Übungen nicht behaupten konnte.
Deswegen ging das Lernen dann fast wie von alleine.
Mittlerweile verdiene ich seit Jahren meine Brötchen damit.
Auch privat kommt C auf AVR und ARM zum Einsatz.
Auf dem PC ist aber C++ oder, bei kleinen Helferlein, Python das Mittel
der Wahl.
Für jedes Problem das richtige Werkzeug.
Erst jetzt kann ich eigentlich beurteilen wie unwissend ich damals war,
und darüber lachen.
C hat schon eine gewissen Lernkurve, das stimmt. Als Laie gibt es dort
100 Wege, dir selbst ins Knie zu schießen.
Aber nicht ohne Grund hat es sich einfach durchgesetzt. Einer davon ist
die hardware-nähe bei gleichzeitig relativ hoher Abstraktion.
Der Compiler hat, wenn man ihm nicht vorsätzlich Steine in den Weg legt,
immer die Möglichkeit optimalen ASM-Code zu erzeugen. Und trotzdem hat
man die Bequemlichkeit von Datenstrukturen, Funktionen, muss sich nicht
um Register kümmern...
Aber um das Beurteilen zu können muss man mal über den Tellerrand
geschaut haben...
Moby A. schrieb:> Ich denk mal da hast Du gerade was falsch verstanden !?> Es handelt sich nicht um C-Code für mein Tiny13 Projekt worauf ich> selber warte sondern meinen ersten und einzigen (war was für PC> DOS-Kommandozeile).
Dann zeig doch den mal her. Vermutlich werden wir dann verstehen, warum
du C so schrecklich findest...
A. K. schrieb:> Wenn er alles abgezogen hat, was er für unnötig oder> viel zu kompliziert hält und was man davon sowieso nicht braucht, dann> passt es auch in die Hälfte rein. So optimiert man Code.
Wenn es denn stimmt das es keine nützliche Funktionalität enthält ist
das tatsächlich die beste Art Code zu optimieren.
Übrigens vollkommen Sprachenunabhängig.
Moby A. schrieb:> Selbst die 10-15% gehen mir ja schon runter wie Öl ;-)
Bei 250% für Entwicklung und Wartung fallen mir aber spontan nicht so
viele Anwendungen ein wo das auch im gewerblichen Maßstab noch tragfähig
ist.
Na ja, irgendeine Raumsonde auf dem Weg zu anderen Planeten, da kommt es
schon auf jedes Bit an.
Moby A. schrieb:>> Das haben wir dich schon mehrmals gebeten, aber mehr als das Ding>> mit dem Tiny13 bekommen wir ja nicht zu sehen.> Der reicht auch als Demo der Überlegenheit von Assembler.
Immer das gleiche.
Über Glauben läßt sich nicht diskutieren, denn wenn es Beweise gäbe
bräuchte es doch keinen Glauben mehr.
Deswegen diskutieren Wissenschaftler und Gläubige metzeln sich
gegenseitig weg. So wie in diesem Thread.
Moby A. schrieb:> Unfug. Register hat jeder AVR die gleichen 32 an der Zahl. Im> wertvollen, zusätzlichen SRAM unterscheiden sie sich. Der zählt> selbstverständlich zu den einzusparenden Ressourcen für einen> ordentlichen Vergleich.
Kannst du eigentlich einen vernünftigen Grund für das "Einsparen" dieser
"wertvollen Resourcen nennen"? Aber nicht den, dass du es geil findest,
unter dein Porgramm "RAM-Verbrauch 0" zu schreiben.
Die Frage musst du nicht wirklich beantworten.
Aber etwas interessiert mich doch:
Warum verschwendest du in deinem Projekt wertvolle Resourcen damit, dass
du den Stack auf den Default-Wert initialisierst und das RAM durchgehend
auf 0 setzt? Das kostet dich wertvolle Rechenzeit, unnötig Strom und
belegt wertvollen Flash-Speicher.
Warum belegst du jeden Interruptvektor mit einem Sprungbefehl, obwohl du
die hinteren gar nicht benutzt? Warum beginnt dein Programm nicht direkt
nach dem letzten Vektor, der von dir benutzten Interrupts? Du
verschwendest massiv wertvolle Resourcen. Flash-Speicher, den du für
Erweiterungen nicht mehr nutzen kannst.
Warum wird ein Register in deiner Initialisierung zweimal mit dem
gleichen Wert beschrieben, anstatt die Initialisierungen so anzuordnen,
dass die SFRs, die den gleichen Wert erhalten, direkt hintereinander
stehen? Welch eine Verschwendung an Flash-Speicher und Rechenzeit.
Nur mal die ersten Kleinigkeiten, die mir in deinem "hoch effizenten"
Programm so aufgefallen sind, ohne den Rest weiter angesehen zu haben.
Ich dachte, nur C-Compiler machen diese stereotypen
Univeralinitialisierungen, ungeachtet dessen, ob man sie wirklich
braucht, um ordentlich Resourcen zu verschwenden, damit der
Programmierer danach damit angeben kann, was für lange Programme er
geschrieben hat.
Assembler-Programmierer dagegen haben ihren Controller voll im Griff und
lassen nur das ausführen, was nötig ist. Höchstmögliche Effizienz eben
und "Keep is simple".
Und noch was:
Warum trampelst du in deiner Hauptprgramm-Schleife nur auf der Stelle,
anstatt die Interrupts zu pollen? Das geht viel schneller, als jedesmal
den üblichen Overhead eines Interrupt-Request abarbeiten zu lassen. Das
ist auch kürzer und spart wiederum Flash-Speicher. Und - und das ist
natürlich der besondere Nutzen davon: Es wird nichts mehr auf den Stack
geschrieben! Dein RAM-"Verbrauch" ist jetzt tatsächlich 0. Die wertvolle
Resource wird gar nicht angetastet.
Ausserdem könntest du das Programm dann bei Adresse 0 starten lassen und
du würdest noch einmal Flash einsparen, anstatt diese Resource auch
sinnlos zu verschwenden und die Erweiterungsmöglichkeiten
einzuschränken.
mfg.
Cyblord -. schrieb:> Treffer und versenkt würde ich sagen.
Sehe ich auch so. Allerdings wird das wohl mit einem einzigen Begriff
von Tisch gewischt werden, der heist:
Erweiterbarkeit!
Gu. F. schrieb:> Erweiterbarkeit!
Dann ziehen ihm diesen Zahn:
Da das Verhalten des Programms durch Internet-Polling deterministisch
ist, lassen sich die Register, die sonst exklusiv in einer ISR
vorgehalten werden müssen, flexibel verwenden, was der Erweiterbarkeit
sogar noch zu Gute kommt.
mfg.
Thomas E. schrieb:
[...]
Einen großen Teil dieser Optimierungen hatte ich schon im Originalthread
angemerkt, aber da kamen dann die üblichen Ausflüchte, wie z.B. RAM muß
man initialisieren weil man das ja für Erweiterungen benötigt. Und das
mehrfache Ladens der selben Konstante ins gleiche Register zeigt die
"Überlegenheit" des selbsternannt "mittelmäßigen
Assembler-Programmieres" beim Einsparen von Flash-Zellen und Takt-Zyklen
über stupide Compiler.
Michael K. schrieb:> Bei 250% für Entwicklung und Wartung fallen mir aber spontan nicht so> viele Anwendungen ein wo das auch im gewerblichen Maßstab noch tragfähig> ist.> Na ja, irgendeine Raumsonde auf dem Weg zu anderen Planeten, da kommt es> schon auf jedes Bit an.
Im Umfeld der zivilen und militärischen Raum- und Luftfahrt scheint vor
allem die Hochsprache Ada besonders beliebt zu sein:
http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
Thomas E. schrieb:> Warum verschwendest du in deinem Projekt wertvolle Resourcen damit, dass> du den Stack auf den Default-Wert initialisierst und das RAM durchgehend> auf 0 setzt? Das kostet dich wertvolle Rechenzeit, unnötig Strom und> belegt wertvollen Flash-Speicher.
Das wurde im Projekt-Thread beantwortet.
> Warum belegst du jeden Interruptvektor mit einem Sprungbefehl, obwohl du> die hinteren gar nicht benutzt? Warum beginnt dein Programm nicht direkt> nach dem letzten Vektor, der von dir benutzten Interrupts? Du> verschwendest massiv wertvolle Resourcen. Flash-Speicher, den du für> Erweiterungen nicht mehr nutzen kannst.
Das wurde im Projekt-Thread beantwortet.
> Nur mal die ersten Kleinigkeiten, die mir in deinem "hoch effizenten"> Programm so aufgefallen sind, ohne den Rest weiter angesehen zu haben.
Vieles ist bereits auf Erweiterungen ausgerichtet. Ohne diese könnte man
sicher dieses und jenes einsparen- wozu dann aber Einsparen wenn der
freie Speicher ohnehin nicht mehr genutzt werden könnte? Zu einem
vollständigen, erweiterungsfähigen Programm gehört genau das was Du dort
codiert siehst!
Du siehst, Deine schrecklich herbeikonstruierte Sichtweise bricht
kurzerhand in sich zusammen.
Ist ja furchtbar nett, daß Du an der Verbesserung des Asm-Codes solchen
Anteil nimmst. Dabei wäre die entscheidende Aufgabe gewesen, das
Programm mit C zu toppen. Glaubst Du, daß Du Dich daran jetzt auf diese
Weise vorbeigemogelt hast? Und vergiss nicht, mein Asm-Programm stellt
noch nicht mal den Anspruch, die Lösung in Perfektion zu sein. Ich sehe
mich ja nur als durchschnittlichen Asm Programmierer ;-)
Cyblord -. schrieb:> Treffer und versenkt würde ich sagen.
Besser Du verschwindest mit Deiner Wahrnehmung in Versenkung ;-)
Thomas E. schrieb:> Da das Verhalten des Programms durch Internet-Polling deterministisch> ist, lassen sich die Register, die sonst exklusiv in einer ISR> vorgehalten werden müssen, flexibel verwenden, was der Erweiterbarkeit> sogar noch zu Gute kommt.
Dieses Vorgehen mag nicht sinnlos sein, meine Hintergedanken waren aber
andere:
-> Das Hauptprogramm freihalten als übersichtliche
Erweiterungsmöglichkeit
-> Alle Funktionalität im Interrupt kapseln für die Übersicht
-> Bei ungenutztem Hauptprogramm könnte dort energiesparend geschlafen
werden
Carl D. schrieb:> Einen großen Teil dieser Optimierungen hatte ich schon im Originalthread> angemerkt, aber da kamen dann die üblichen Ausflüchte,
Meine sogenannten "Ausflüchte" habe ich umfassend begründet.
Und vergiss doch bitte nicht eines, siehe Zitat
Moby A. schrieb:> dem beiliegenden> Quelltext (T13.asm) entnehmen, der für ASM-Fans (und solche die es> werden möchten) zur Verschlimmbesserung/Erweiterung beiliegt
Das ist ja das schöne an Software ;-)
Moby A. schrieb:> Das wurde im Projekt-Thread beantwortet.
Das werde ich bestimmt nicht querlesen.
Moby A. schrieb:> Vieles ist bereits auf Erweiterungen ausgerichtet.
Dummes Geschwafel.
Allein deine Vektortabelle ist eines Assembler-Programmierers absolut
unwürdig.
Du setzt auf jeden nicht benutzten Vektor einen jump auf eine ISR, in
der dann ein reti steht. Das reti gehört aber direkt auf den Vektor.
Du argumentierst, ... Überlies das.
Du schwafelst hier von der Effizienz deines Assembler-Programms
gegenüber C-Programmen. Dabei machst du genau die Sachen, die einen
kleinen C-Code unnötig aufblähen. Nämlich das Durchnullen des gesamten
RAM, obwohl es nicht nötig ist und das Anlegen einer kompletten
Vektortabelle mit jump auf eine Bad Interrupt-ISR. DAS, ich wiederhole,
DAS ist ziemlich genau DAS, was ein Progrämmchen, wie das in deinem
"Projekt" um die ominösen 10-20% größer macht. Den eigentlichen
Funktionscode bekommt ein richtiger Assembler-Programmierer evtl.
effektiver hin. Wobei effektiver nicht unbedingt kürzer ist.
Moby A. schrieb:> wozu dann aber Einsparen wenn der> freie Speicher ohnehin nicht mehr genutzt werden könnte?
Warum soll man den nicht nutzen können? Du kannst den nicht nutzen, weil
du nicht programmieren kannst und überhaupt nicht in der Lage bist, die
Möglichkeiten eines Makro-Assemblers auszunutzen.
Moby A. schrieb:> Ist ja furchtbar nett, daß Du an der Verbesserung des Asm-Codes solchen> Anteil nimmst.
Im nehme da keinen Anteil dran. Ich zeige nur auf, dass du unfähig bist,
das, von dem du hier ständig schwafelst, auch umzusetzen.
Moby A. schrieb:> Dabei wäre die entscheidende Aufgabe gewesen, das> Programm mit C zu toppen. Glaubst Du, daß Du Dich daran jetzt auf diese> Weise vorbeigemogelt hast?
Wessen Aufgabe? Meine? Wo ist das C-Programm?
Ich werde einen Teufel tun und dein Assembler-Zeugs auseinander
friemeln.
Moby A. schrieb:> Und vergiss nicht, mein Asm-Programm stellt> noch nicht mal den Anspruch, die Lösung in Perfektion zu sein. Ich sehe> mich ja nur als durchschnittlichen Asm Programmierer
Du bist bei weitem nicht einmal das. Bei dir wäre eigentlich in der
gesamten Assembler-Zunft kollektives Fremdschämen angesagt. Allerdings
müsste man dich dafür ernst nehmen.
Um dir noch mal ein von dir hoch geschätztes Beispiel aus dem richtigen
Leben zu geben:
Du schwafelst davon, dass ein Fußgänger 100m schneller bewältigen kann
als ein Radfahrer. Dabei schwadronierst hier rum als wärest du Usain
Bolt, bist aber tatsächlich nicht einmal in der Lage, eine alte Oma mit
ihrem Rollator zu überholen.
mfg.
Thomas E. schrieb:> Das werde ich bestimmt nicht querlesen.
Und ich werde die rhetorische Frage bestimmt nicht zum 10001. Mal
beantworten.
> Dummes Geschwafel.
Deines würde ich so bezeichnen.
> Du setzt auf jeden nicht benutzten Vektor einen jump auf eine ISR, in> der dann ein reti steht. Das reti gehört aber direkt auf den Vektor.
Könnte man. Für erweiterte Interrupts wird aber wieder der Jump fällig.
Und mehr Speicher kostet es auch nicht.
> Du schwafelst hier von der Effizienz deines Assembler-Programms> gegenüber C-Programmen.> Im nehme da keinen Anteil dran. Ich zeige nur auf, dass du unfähig bist,> das, von dem du hier ständig schwafelst, auch umzusetzen.
Du gibtst hier den großen Experten, bist aber selber unfähig, ein
besseres C-Programm zu erstellen oder auch nur anzudeuten, wieso es
ressourcen- sparender als die von mir umgesetzte Asm-Lösung sein
könnte.
> Warum soll man den nicht nutzen können?
'Können' war hier falsch, konnte es nicht mehr korrigieren.
'Würde" sollte es heißen. Man würde den zusätzlichen Speicher nicht
nutzen, wenn der Code in Deinem Sinne schon auf Minimum zurechtgestutzt
wäre.
Ich denke aber an solche Leute die auf dem Code unmittelbar aufbauen
wollen.
Das werde ich aber jetzt vermutlich nicht in Deinen Kopf bekommen ;-(
Alles unwichtige Mätzchen was Du hier glaubst verbessern zu müssen.
> Um dir noch mal ein von dir hoch geschätztes Beispiel aus dem richtigen> Leben zu geben:
Spare Dir solche Vergleiche. Die sind in den seltensten Fällen gelungen.
Und noch eine Bitte: Sofern es noch Verbesserungsvorschläge für meinen
Code gibt mache die in meinem Projekt-Thread. Aber keine Augenwischerei
mit Verschönerungen der Optik sondern möglichst etwas Substanzielles.
Also so recht viel konstruktiver Gegenwind für Asm kommt ja nun nicht
mehr.
Vielleicht sollte ich die Rolle von Assembler mal etwas bildlich
verdeutlichen:
Wenn auf der Bühne der Controller in Aktion ist sitzen die
Assembler-Programmierer am dichtesten dran. Sie sehen jedes noch so
kleine Detail im 8-Bit Controller plastisch vor sich. Sie kennen die
Bedürfnisse ihrer geplanten App. Nun fällt es leicht, beides optimal
miteinander zu kombinieren!
Die C-Programmierer sitzen weiter weg. Zwischen ihnen und der Bühne
befindet sich der fette Compiler. Der behindert den Blick. Ein paar
konstruktiv bedingte Gucklöcher gibts zwar- aber der Programmierer muß
sich letztlich über die Compiler-Bauer sein Tun mit dem Controller mehr
oder minder effektiv vermitteln lassen. Die Hochsprache dazu muß man
kennen. Vor-und Nachteile der einzelnen Hochsprach-Konstruktionen muß
man kennen. Die vielen Stellschrauben des Compilers, den Code vielleicht
doch noch etwas besser zu optimieren muß man kennen. Und dann beim
Niederschreiben bloß keine Syntaxfehler! Bei den komplexen Ausdrücken ja
kein Zeichen vergessen!
Bürokratie wohin das Auge blickt.
Im Interesse schneller, zweitbester Lösungen kann man sich nun in dieses
Abhängigkeitsdickicht begeben. Oder, man liebt den klaren Blick auf die
Controller-Realitäten, nutzt ihn und erstellt die beste Lösung!
Moby A. schrieb:> Du gibtst hier den großen Experten
Ach, Moby.
Auch wenn es schon ein paar Jahre her ist, aber ich habe jahrelang
Bildverarbeitungsroutinen auf DSP implementiert. Das ist die
Königsklasse der Programmierung. In Assembler.
Aber irgendwann wird man vom Fortschritt überholt, der da heisst:
Schnellere Prozessoren und, noch viel wichtiger, mehr RAM. Dann bringt
es einfach irgendwann nichts mehr, es nicht in C(++) zu machen. Denn
auch die Compiler werden besser. Und wenn ein Compiler mit seinen Libs
erstmal auf eine bestimmte Hardware zugeschnitten ist, kannst du als
Assembler-Friggler einpacken. Das ist jetzt durchaus eine
Experten-Einsicht.
[Polemik entfernt - Mod.]
Moby A. schrieb:> Du gibtst hier den großen Experten,
Vielleicht ist er es? Einige Leute hier haben selbst viel Erfahrung in
Assembler. Aber eben nicht nur in Assembler. Programmiersprachen sind
Werkzeuge und auch im Werkzeugkasten ist es von Nutzen, wenn er nicht
nur Hämmer enthält. Man sucht sich das zum Problem passende Werkzeug.
Das kann auch Assembler sein - aber heute eher in kleinen Häppchen wo es
sich wirklich lohnt, nicht im ganzen Programm.
Ein Problem, dass du bei Compilern siehst, ist Intransparenz. Du siehst
nicht, was geschieht. Aber ausgerechnet C ist eine der transparentesten
Sprachen, was die Abbildung von Quellcode auf den Maschinencode angeht.
Mit etwas Erfahrung kriegt man eine Nase dafür, wie aufwändig der
entstehende Code ist. Diese Eigenschaft hatte C früher den Ruf
eingebracht, ein besserer Assembler zu sein.
Allein - Transparenz ist kein Wert an sich. Ich hatte oben scherzhalber
APL aufgeführt, weil das so ziemlich das Gegenteil davon ist. Abgesehen
vom Autor des Interpreters hat da niemand eine Ahnung, wie das das
intern wirklich abläuft und wie es optimiert wird. Der Abstand zwischen
Quellcode und dem Ablauf auf Maschinenebene ist immens. Das führt auch
zu einer anderen Denkweise beim Programmieren. Man hat nicht so sehr den
sequentiellen Ablauf und den Fluss einzelner Worte eines Programmes vor
Augen, sondern denkt in komplexen Datenwolken.
Deshalb gehört es eigentlich zum guten Ton, angehende Informatiker mit
verschiedenen Prinzipien der Programmiersprachen zu konfrontieren. Also
keine Scheinvielfalt prinzipiell ähnlicher Sprachen wie C/Pascal/FORTRAN
kennen zu lernen, sondern (früher) auch mal an Prolog zu schnuppern.
Allein schon um zu sehen, dass man sich Programmierung auch anders
ausdenken kann als ablaufgesteuert und skalar.
Ist zwar Mobys Thread, wenn aber
Moby A. schrieb:> Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle> Entwicklung im TIOBE-Programmierindex:
nach nicht mal zwanzig Minuten
Karl H. schrieb:> Wenn letztes Jahr von 100 Programmierern gerade 1 in Assembler> programmiert hat und heuer sind es 2, dann ist das auch ein Zuwachs von> 100%. Ist immer noch unter ferner liefen und völlig uninteressant.
alles gesagt ist und jetzt sowieso alles gelöscht wird, kann man da
nicht einfach dicht machen? Wir warten einfach eine Woche, dann gibt's
eine neue Statistik und ein neues Thema: "Assembler wieder auf dem Weg
nach hinten".
Moby A. schrieb:> Ohne diese könnte man> sicher dieses und jenes einsparen- wozu dann aber Einsparen wenn der> freie Speicher ohnehin nicht mehr genutzt werden könnte?
Daß Du diese Erkenntnis noch bekommst, hätte ich nicht mehr zu hoffen
gewagt!
Gruß, Stefan
Stefan K. schrieb:> Moby A. schrieb:>> Ohne diese könnte man>> sicher dieses und jenes einsparen- wozu dann aber Einsparen wenn der>> freie Speicher ohnehin nicht mehr genutzt werden könnte?>> Daß Du diese Erkenntnis noch bekommst, hätte ich nicht mehr zu hoffen> gewagt!>> Gruß, Stefan
Ich auch nicht. Was soll dann dieses bescheuerte Argument, dass C 10%
mehr Speicher braucht?
Moby A. schrieb:> Also so recht viel konstruktiver Gegenwind für Asm kommt ja nun nicht> mehr.
Und genau das liebe ich so an Deinen Beiträgen.
Ich gebe zu das mich das früher manchmal aufgeregt hat wie jemand ganz
einfach alles wegblendet was ihm nicht gefällt, so tut als hätte nichts
davon stattgefunden und einfach wieder an einem Punkt weitermacht den
man vor 300 Seiten Diskussion überwunden geglaubt hatte.
Mittlerweile finde ich das sehr erfrischend.
Es führt mir vor Augen wie vollkommen hoffnungslos der Versuch ist
jemanden zu überzeugen der sich einfach fest vorgenommen hat keinen
Millimeter von seiner Überzeugung abzuweichen.
Wer es geschafft hat einen Deiner ASM Threads durchzuhalten ohne
medizinischen Beistand zu benötigen dem kann in keinem Internetforum
mehr was schlimmes passieren.
Ein wenig bist Du wie ein Boxer, der manches blockt und manchem tänzelnd
ausweicht. Treffer werden mit einem Grinsen quittiert, weil es ja
garnicht wehgetan hat. Da kann der andere 100 Mal besser sein, Du hast
einfach die Ausdauer für 1000 Runden. Da kannst zwar nicht siegen, bist
aber unbesiegbar weil Du einfach nicht am Boden bleibst egal wie hart Du
getroffen wirst.
Diversen Leuten wird jetzt wieder der Kamm schwellen wie man das so
sehen kann, aber genau das macht ja den Unterhaltungswert dieses Threads
aus.
Es wäre tatsächlich ein spannendes Experiment wenn jemand mit
unterdurchschnittlichen C Kenntnissen und einem gut optimierenden
Compiler Deinen Code toppen würde.
Es würde mit Sicherheit alles mögliche passieren, aber niemals nie nicht
würdest Du Deine Überzeugung ändern.
Das alles ist in etwa so sinnvoll wie 1000 Argumente für gutes Wetter in
den Sturm zu brüllen.
Sheeva P. schrieb:> Moby A. schrieb:>> Ich denke aber an solche Leute die auf dem Code unmittelbar aufbauen>> wollen.>> Gibts denn welche..?
Nein, es gibt keine. Er ist auf seinen ach so tollen Sensorboards, die
er hier angeboten hat, sitzengeblieben. Kein Mensch wollte eins haben.
Kein Mensch wollte seine unleserliche und unverständliche Software
benutzen - geschweige denn erweitern.
Stefan K. schrieb:> Daß Du diese Erkenntnis noch bekommst, hätte ich nicht mehr zu hoffen> gewagt!
Wenn Du und Sven B. sie denn verstanden hättet ;-)
Sheeva P. schrieb:> Gibts denn welche..?
Bestimmt. Gemeint war aber nicht Dein großartiges C-Werk ;-)
Frank M. schrieb:> Kein Mensch wollte seine unleserliche und unverständliche Software> benutzen - geschweige denn erweitern.
Du darfst halt nicht immer nur von Dir auf andere schließen ;-)
Michael K. schrieb:> Du hast> einfach die Ausdauer für 1000 Runden.
Nein Michael. Ich habe Recht: Asm hat seine Vorteile bei hardwarenahem
8-Bit MSR.
> Da kannst zwar nicht siegen
Das kann bei der Übermacht von C hier gar kein Ziel sein. Meine Ziele
sind längst erreicht- als erfolgreiche Asm-Projekte allemal.
> Es wäre tatsächlich ein spannendes Experiment wenn jemand mit> unterdurchschnittlichen C Kenntnissen und einem gut optimierenden> Compiler Deinen Code toppen würde.
Das ist nicht passiert und wird nicht passieren, siehe erste Antwort.
> Es würde mit Sicherheit alles mögliche passieren, aber niemals nie nicht> würdest Du Deine Überzeugung ändern.
Irrtum. Hatte ich aber auch schon öfter gesagt.
> Das alles ist in etwa so sinnvoll wie 1000 Argumente für gutes Wetter in> den Sturm zu brüllen.
Genau. C-Argumente gegen den Sturm von superfluid-anpassungfähigem
Simply Asm. In dem sind die Seeleute des schwerfälligen C-Frachters mit
den dicken Büchern hier hoffnungslos untergegangen, sofern sie sich
nicht schnell noch auf die Inseln von Satire, Sarkasmus und persönlicher
Beleidigung retten konnten ;-)
Michael K. schrieb:> aber niemals nie nicht würdest Du Deine Überzeugung ändern.
Hatten wir doch schon. Es werden dann einfach nachträglich die
Anforderungen geändert, bis sein Weltbild wieder passt.
Moby A. schrieb:> superfluid-anpassungfähigem Simply Asm
"superfluid" ist in etwa "überflüssig"?
Und da behaupten hier Leute, du wärst nicht lernfähig...
A. K. schrieb:> Man sucht sich das zum Problem passende Werkzeug.> Das kann auch Assembler sein
Für 8-Bit Controller MSR. Genau. So schauts aus.
Deine restlichen Ausführungen klingen ja durchaus plausibel, allein
meine Wahrnehmung, daß zu vieles mit zunächst mühsam zu erlernenden
Werkzeugen zu kompliziert gelöst wird, werde ich damit auch nicht los.
> sondern denkt in komplexen Datenwolken
Na meinetwegen. Wo aber keine komplexen Datenwolken sind benötigt es
auch kein passendes Werkzeug.
> Allein schon um zu sehen, dass man sich Programmierung auch anders> ausdenken kann als ablaufgesteuert und skalar.
Ich behaupte, das ist und bleibt der intuitivere Zugang.
Andere behaupten, es gäbe bessere. Das nehme ich gerne zur Ķenntnis.
Verlieren wir doch aber bitte nicht stets das (meinige) Ziel aus den
Augen:
- Acht Bit Controller Messen Steuern und Regeln! -
Millionen Anwendungsfälle. Millionen Einsatzfälle für Asm.
Jörg W. schrieb:> Es werden dann einfach nachträglich die> Anforderungen geändert, bis sein Weltbild wieder passt
Falsch. Ich ändere nichts nachträglich, sondern setze das Wissen, was
MC-Ressourcen sind und eine Vorstellung von echtem Vergleich
diesbezüglich einfach voraus. Mit echtem Code gehts auch nicht um
Weltbilder. Faktenbasierteres als die Fakten zu Codesize, RAM-Verbrauch
(und ggf Speed) gibts einfach nicht.
Moby A. schrieb:> Falsch.
Ach, Moby. Du merkst es nicht einmal.
Wenn du an einem fairen Vergleich interessiert wärst, würdest du dich
mal für irgendein Projekt hinsetzen, verbal alle Anforderungen auf
einen Zettel schreiben (die dann auch nicht nachträglich ergänzt
werden dürfen, auch nicht mit Begründungen wie „das macht man doch
aber immer so!“ und dergleichen), und danach das Projekt genau danach
umsetzen und dir parallel von anderen eine Umsetzung des Projekts mit
den Mitteln ihrer Wahl machen lassen. Mögliches Erweiterungspotenzial
gehört dabei natürlich genauso in die Liste der Anforderungen hinein
und darf nicht einfach hinterher postuliert werden.
Das ist dir mehrmals angeboten worden, darauf würden sich hier einige
Leute durchaus einlassen. Machst du aber nicht, sondern du beharrst
darauf, dass der Vergleich ausschließlich an diesem einen vorliegenden
Muster zu erfolgen hat, und die Anforderungen werden immer so weiter
„verfeinert“, dass die Schnittmenge aus allen Anforderungen am Ende
nur durch genau dieses eine Exemplar von Realisierung erfüllt werden
kann.
Darauf hat einfach keiner mehr Bock. Wir alle wissen, was wir können
(und bei vielen hier gehören diverse Dialekte von Assembler mit dazu,
nicht nur der eine, den du gerade zufällig beherrschst), und wir lassen
dir deinen Glauben, du wärest der größte Programmierer aller Zeiten,
naja, oder wenigstens der zweitgrößte. ;-)
Moby A. schrieb:> allein meine Wahrnehmung
Das wirds wohl sein.
Ich wollte noch mehr schreiben, habe es aber wegen akuter
Wiederholungsgefahr gelöscht...
EDIT, eins noch:
mein neues Stimmgerät für den Bass basiert auf einem 32-Bit ARM. Und das
Ding ist echt mal brauchbar. Garantiert haben die das nicht mit
Assembler geschrieben:
http://www.tcelectronic.com/de/polytune-clip/
Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde
ich niemals mehr mit 8-Bit uC und Assembler anfangen.
Moby A. schrieb:> Verlieren wir doch aber bitte nicht stets das (meinige) Ziel aus den> Augen:> - Acht Bit Controller Messen Steuern und Regeln! -> Millionen Anwendungsfälle. Millionen Einsatzfälle für Asm.
Hör jetzt endlich mal auf mit dem Blödsinn. In diesem Punkt haben wir
dir schon lange zugestimmt: Ja, auf kleinsten Controllern kann Assembler
ein vernünftiges Werkzeug sein. Dann verallgemeinerst du aber wieder auf
grössere Projekte und Prozessoren. Das ist natürlich falsch und wenn
dann ein paar Argumente gegen deine Position kommen, dann krebst du
wieder auf 8-Bit-MSR zurück. Dieses hin und zurück geht nun über 300+
Beiträge...
Ralf G. schrieb:> Karl H. schrieb:>> Wenn letztes Jahr von 100 Programmierern gerade 1 in Assembler>> programmiert hat und heuer sind es 2, dann ist das auch ein Zuwachs von>> 100%. Ist immer noch unter ferner liefen und völlig uninteressant.>> alles gesagt ist und jetzt sowieso alles gelöscht wird, kann man da> nicht einfach dicht machen? Wir warten einfach eine Woche, dann gibt's> eine neue Statistik und ein neues Thema: "Assembler wieder auf dem Weg> nach hinten".
Wieso? Ist einer der beiden verstorben? Mein Beileid.
@ Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
>dir deinen Glauben, du wärest der größte Programmierer aller Zeiten,>naja, oder wenigstens der zweitgrößte. ;-)
Der GröPaZ! ER ist wieder da!
:-=(
Lothar M. schrieb:> Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde> ich niemals mehr mit 8-Bit uC und Assembler anfangen.
Wobei das natürlich projektmäßig eher kein Kleingerät ist, denn da
wird garantiert eine FFT drin laufen, um aus dem ankommenden Krach
die dominierende Frequenz zu ermitteln. Kann man auch auf'm AVR
machen, macht aber auf einem größeren Prozessor mehr Spaß.
Für einen ATtiny10, benutzt als jumper-einstellbare Taktquelle,
schreib' ich die paar Zeilen auch im Assembler runter. Das ist aber
als Programmieraufgabe ein Mickeymouseprojekt. Früher hätte man dafür
einen 555 genommen und über Jumper Widerstände ausgewählt, heute braucht
man halt nur noch zwei Bauteile für sowas (den Controller und den
obligatorischen 100-nF-Kerko).
Frank M. schrieb:> Sheeva P. schrieb:>> Moby A. schrieb:>>> Ich denke aber an solche Leute die auf dem Code unmittelbar aufbauen>>> wollen.>>>> Gibts denn welche..?>> Nein, es gibt keine. Er ist auf seinen ach so tollen Sensorboards, die> er hier angeboten hat, sitzengeblieben. Kein Mensch wollte eins haben.> Kein Mensch wollte seine unleserliche und unverständliche Software> benutzen - geschweige denn erweitern.
Erweitern?
Was willst du da erweitern?
Der Code ist so dermassen auf 2 ADC Eingänge und 2 Digitale Eingänge
hingeschustert, das Protokoll ist so dermassen auf genau diese
Konstellation hingearbeitet, dass man da nichts erweitern kann. Hat man
nicht genau diese Anforderungen, dann bleibt nichts anderes übrig, als
den Code komplett neu zu machen.
Soviel zum Thema, dass Mobby auch ein Erweiterungen bzw.
Weiterverwengung denkt.
Eines muss man ihm lassen: In seiner Routine zieht er alle Register. Er
weiss genau, dass in C alles was nicht in Bytes, Words oder DWords
abgehandelt wird eher unhandlich ist. Eine 24 Bit Arithmetik ist in C
nun mal ein Krampf, das geht in Assembler besser. Was er aber nicht wahr
haben will, und das hat er ja schon oft genug unter Beweis gestellt, das
ist das seine Sicht der Dinge für die Mehrzahl der Leute ziemlich
uninteressant ist. Von so einem Sensorboard will man Routinen, bei denen
man einfach konfigurieren kann wieviele analogen und wieviele digitalen
Eingänge man haben will und welche Pins das jeweils sein sollen. Genauso
wie man den Protokollaufbau einfach spezifizieren können möchte. So
etwas wäre für einen Weiterverwender brauchbar. Nur: genau das spielt
sein Code nicht. Der ist noch nicht mal bei der einfachsten Änderung der
Anforderungen irgendwie einfach modifizierbar. Und damit für alle
anderen ausser ihn völlig uninteressant.
Was ihn allerdings nicht daran hindert, dieses Faktum zu ignorieren und
darauf hinzuweisem, dass man genau diese Konstallation in C nicht
kleiner hinkriegt. Womit er sogar recht hat. Nur wie gesagt interessiert
das eigentlich nicht, denn im Zweifel hab ich lieber eine Codebasis, die
ich auf meine Bedürfnisse anpassen kann als eine die ich komplett neu
schreiben muss, wenn ich nicht genau die vom Autor vorgegebenen
Anforderungen habe. Selbst wenn dann der Code ein paar Bytes länger ist
und ein paar Taktzyklen mehr braucht.
Moby A. schrieb:> Irrtum. Hatte ich aber auch schon öfter gesagt.
Ja, das hast Du, nur sagst Du mal dieses und dann wieder jenes.
Was gerade das Kriterium ist und was aus der Wertung fällt ändert sich
nach Wind und Wellenschlag. Verbindliche Kriterien gibt es nicht,
vielmehr werden die jederzeit so angepasst das Du in deiner Wahrnehmung
im Recht bleibst.
Das darfst aber immer nur Du, denn Dein Standpunkt ist immer die
absolute Wahrheit, auch wenn er sich wie ein Gummiband in alle
Richtungen dehnt.
Ich glaube Dir das Du das ganz anders siehst, aber den Rest des Forums
treibt das zur Weißglut.
Moby A. schrieb:> Asm hat seine Vorteile bei hardwarenahem> 8-Bit MSR.
Ja, und C hat die auch und beide haben auch Nachteile.
Moby A. schrieb:> Faktenbasierteres als die Fakten zu Codesize, RAM-Verbrauch> (und ggf Speed) gibts einfach nicht.
Stimmt, nur das Du Fakten scheust wie der Teufel das Weihwasser.
Du behauptest was immer Du willst und nennst das dann Fakten.
Es sind aber nur Behauptungen eines Menschen der nur eine Seite kennt.
Du behauptest aber man müsse nur eine Seite kennen um alle Seiten
bewerten zu können.
Du wirfts C Verschwendung vor und verschwendest selber viel mehr.
Bei Dir sind es aber Erweiterungsmöglichkeiten.
Du singst ein Loblied auf die Lösung die auf den Punkt hin entwickelt
wird, stopfst Deinen Code aber mit unsinnigem voll wegen
Erweiterbarkeit.
Angesprochen darauf das komplett neuer ASM Code fällig wird bei
zusätzlichen Sensoren zählt plötzlich die Erweiterbarkeit nichts mehr
weil das müsse man sich vorher überlegen.
Das ist ein absolut irrer Amoklauf durch alles was unreife Kommunikation
ausmacht. Dementsprechend wirst Du behandelt.
Ich will Dich nicht ändern und das könnte ich auch nicht.
Ich finde es auch sehr unterhaltsam mitanzusehen wie aus einer
technischen Diskussion ein Schlagabtausch wird, dann blanker Hass, dann
völlige Resignation.
Jeder der hier schreibt verändert sich dabei, nur Du bleibst seit 100
Threads genau so wie Du bist.
Das ist irgendwie schade das da gar keine Entwicklung mehr stattfindet.
Jörg W. schrieb:> Lothar M. schrieb:>> Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde>> ich niemals mehr mit 8-Bit uC und Assembler anfangen.> Wobei das natürlich projektmäßig eher kein Kleingerät ist
Nein, sicher nicht. Aber es zeigt eben, dass wir heute in 2015 leben.
Und dass man das Projekt dort nicht mit maximalem Aufwand in die
Programmierung in den kleinsten am Markt verfügbaren uC reinprügelt.
Sondern "einfach" einen nimmt, der ausreichend leistungsfähig ist, und
dann auf eine Softwareplattform setzt, die portierbar und tendenziell
abstrakt ist.
Das ist "Messen, Steuern und Regeln heute"...
Moby A. schrieb:> Faktenbasierteres als die Fakten zu Codesize, RAM-Verbrauch (und ggf> Speed) gibts einfach nicht.
Doch: Marktzahlen und Produkteinführungstermine. Was nützt das schönste
und optimierteste Gerät, wenn es 2 Jahre zu spät am Markt ist?
Moby A. schrieb:> Ich behaupte, das ist und bleibt der intuitivere Zugang.> Andere behaupten, es gäbe bessere. Das nehme ich gerne zur Ķenntnis.> Verlieren wir doch aber bitte nicht stets das (meinige) Ziel aus den> Augen:> - Acht Bit Controller Messen Steuern und Regeln! -> Millionen Anwendungsfälle. Millionen Einsatzfälle für Asm.
Eher ein paar die arithmetisch einfach genug sind, dass man sie in Asm
problemlos abhandeln kann.
Aber wir können gerne einen Vergleich machen. Wir beide programmieren
einen PID Regler. Das ist im Bereich 'Regeln' ein absoluter
Standardfall. Wir könnten zb ein umgekehrtes Pendel balanzieren.
Ach ja - das geht nicht. Ich vergass. Der AVR hat ja keinen PID Opcode
und mit 8 Bit Arithmetik kommt man da auch nicht durch.
Und ausserdem hast du mit deiner Zeit bessere zu tun, als dir die
Nachmittage um die Ohren zu schlagen, dafür eine saubere Lösung zu
bringen. Da hab ich es dann um einiges besser, denn ich brauch dafür
höchstens ein paar Stunden (und das ist aus dem Bauch heraus schon recht
hoch gegriffen). Mir ist nämlich genau wie dir meine Freizeit etwas
wert. Und genau deshalb mach ich das in C.
Moby A. schrieb:> Deine restlichen Ausführungen klingen ja durchaus plausibel, allein> meine Wahrnehmung, daß zu vieles mit zunächst mühsam zu erlernenden> Werkzeugen zu kompliziert gelöst wird, werde ich damit auch nicht los.
Das wäre immer noch nicht das Problem, so lange man sich darüber bewusst
ist, dass das Ausmass dieser "Mühsal" individuell recht unterschiedlich
ausgeprägt ist. Ein jeder hat in seinem individuellen Abstand sein Brett
vor dem Kopf. Aber erst durch den missionarischen Eifer, dies zum Ende
der Welt zu definieren, wird es zum Problem.
Karl H. schrieb:> Der Code ist so dermassen auf 2 ADC Eingänge und 2 Digitale Eingänge> hingeschustert, das Protokoll ist so dermassen auf genau diese> Konstellation hingearbeitet, dass man da nichts erweitern kann.
Ganz davon abgesehen, dass (wenn man /RESET noch in seiner Funktion
belassen will) sowieso bloß noch maximal ein Pin an dem Teil frei
wäre. Ein 8-Pinner hat eben nur fünf frei benutzbare Pins.
Dahingehend ist die Anforderung „darf keinen wertvollen RAM brauchen,
damit noch Platz für Erweiterungen ist“ ja völlig absurd, zumal
Register in einem Prozessor wohl immer teurer sind als RAM (Ausnahme:
Z8, bei dem gab es keinen Unterschied zwischen RAM und Registern).
Moby A. schrieb:> Na meinetwegen. Wo aber keine komplexen Datenwolken sind benötigt es> auch kein passendes Werkzeug.
Klar. Man kann auch mit einem Satz Feilen aus Stahl das benötigte
Werkstück herausholen. Aber mit Drehbank, Fräse und Ständerbohrmaschine
gehts dann eben doch in den meisten Fällen einfacher. Und auch klar: man
muss lernen damit umzugehen. Selbst wenn man dann in einigen Fällen doch
noch an einzelnen Stellen mit der Feile drüber geht um Grate zu
entfernen.
Du argumentierst hier wie jemand, der sich mit Feile und
Gewindeschneider seine 3 benötigten Schrauben selbst hergestellt hat.
Das ist super für dich und du kannst auch die benötigte und ausreichende
M4.857 Schraube damit herstellen (wenn du das Gewinde selbst feilst).
Aber die Verallgemeinerung, damit den Aufbau einer kompletten Halle mit
händisch selbstgefertigen Schrauben zu bewerkstelligen, die zieht eben
nicht.
Karl H. schrieb:> Eines muss man ihm lassen: In seiner Routine zieht er alle Register. Er> weiss genau, dass in C alles was nicht in Bytes, Words oder DWords> abgehandelt wird eher unhandlich ist.
Au weia, damit hast du wieder Stoff für weitere 100 Sinnlosbeiträge
geliefert.
Jörg W. schrieb:> Register in einem Prozessor wohl immer teurer sind als RAM (Ausnahme:> Z8, bei dem gab es keinen Unterschied zwischen RAM und Registern).
Die Zugriffspfade (Ports) machen den Hauptunterschied im Aufwand aus.
Auf RAM kann immer nur einer zugreifen, auf Register meist mehrere. Ein
AVR kann pro Takt 2 Register lesen und eines schreiben. Aber pro Takt
kann er nur ein RAM-Byte entweder lesen oder schreiben. Das ist beim Z8
nicht anders (oder früher beim TIs TMS9900), was Folgen für die Laufzeit
der Befehle hat.
Gu. F. schrieb:> Karl H. schrieb:>> Eines muss man ihm lassen: In seiner Routine zieht er alle Register. Er>> weiss genau, dass in C alles was nicht in Bytes, Words oder DWords>> abgehandelt wird eher unhandlich ist.>> Au weia, damit hast du wieder Stoff für weitere 100 Sinnlosbeiträge> geliefert.
Ist mir klar.
Auf der anderen Seite sehe ich die Sache tatsächlich so.
Karl H. schrieb:> Gu. F. schrieb:>> Karl H. schrieb:>>> Eines muss man ihm lassen: In seiner Routine zieht er alle Register. Er>>> weiss genau, dass in C alles was nicht in Bytes, Words oder DWords>>> abgehandelt wird eher unhandlich ist.>>>> Au weia, damit hast du wieder Stoff für weitere 100 Sinnlosbeiträge>> geliefert.>> Ist mir klar.> Auf der anderen Seite sehe ich die Sache tatsächlich so.
Der springende Punkt ist doch, dass man für ganz spezifische Einzelfälle
immer genau darauf zugeschnittene Produkte händisch fertigen kann. Ich
kann, wenn ich gut bin, nicht nur M3 M4 M5 etc. Schrauben machen,
sondern auch alle gewünschten Zwischenmasse. Kann ich tun. Nur darf ich
mich nicht wundern, dass niemand die aufwändig hergestellte M3.8729
Schrauben im Baumarkt kauft und die im Regal verrotten. Jahrhundertelang
hat sich jeder Werkzeugbauer seine Schrauben mit genau den Massen die er
gebraucht hat selbst gefertigt, bis es dann den englischen
Eisenbahnbauern zu bunt geworden ist und sie standardisierte Schrauben
eingführt haben. Der Vorteil war, dass Lokomotiven plötzlich in allen
Werkstätten reparierbar wurden, selbst wenn manche Schrauben ein wenig
überdimensioniert waren. Die industrielle Revolution hatte begonnen.
Moby A. schrieb:> Wenn auf der Bühne der Controller in Aktion ist sitzen die> Assembler-Programmierer am dichtesten dran. Sie sehen jedes noch> so kleine Detail
Moby sitzt gerne so nah dran, dass er die Haare an den Beinen der
Tänzerinnen sieht, aber von der Choreographie nix mitbekommt :-)
Johann L. schrieb:> Moby A. schrieb:>> Wenn auf der Bühne der Controller in Aktion ist sitzen die>> Assembler-Programmierer am dichtesten dran. Sie sehen jedes noch>> so kleine Detail>> Moby sitzt gerne so nah dran, dass er die Haare an den Beinen der> Tänzerinnen sieht, aber von der Choreographie nix mitbekommt :-)
Ich wollte mir auch schon zu diesem Thema etwas ausdenken, aber deines
ist schöner.
Meines wäre in die Richtung gegangen, dass sich der Regisseur nicht um
jeden Kleinscheiss selbst kümmert sondern dafür seine Leute hat. Der
Regisseur hat den Überblick und sagt seinem Bühnenbildner nur, wo er
einen Baum hin haben will. Aber er geht nicht selbst in den Fundus. Er
beurteilt das Bühnenbild in seiner Gesamtwirkung aber welche Firma die
Lacke liefert ist ihm egal. Er beurteilt die Kostüme aber er schneidert
sie nicht selbst. Er sagt dem Lichttechiker, wo er einen Spot hinhaben
will, aber kletter nicht selbst zur Montage hoch.
Genau das ist das was ihm noch fehlt: Das loslassen können von der
Detailkontrolle. Kann ich beim Bau einer Hundehütte mich noch um jede
Kleinigkeit selbst kümmern, so geht das für einen Architekten bei einem
Wohnblock nicht mehr.
Jörg W. schrieb:> Machst du aber nicht, sondern du beharrst> darauf, dass der Vergleich ausschließlich an diesem einen vorliegenden> Muster zu erfolgen hat,
welcher ganz allein einen Sinn ergibt.
> Das ist dir mehrmals angeboten worden, darauf würden sich hier einige> Leute durchaus einlassen.
Ich glaube nicht mehr an den Weihnachtsmann ;-)
Ich nehme aber zur Kenntnis, daß das Mantra "Anforderungsliste" für die
wiederholte Auflistung von längst Bekanntem und einfachster
Funktionalität jener Nothaltegriff ist, der als Ausrede für unsere
C-Freunde unabdingbar ist um nicht in der Flut guter Argumente und
Fakten pro ASM den Halt zu verlieren ;-)
Jörg W. schrieb:> wir lassen> dir deinen Glauben, du wärest der größte Programmierer aller Zeiten
Schau Jörg, die lieben Unterstellungen wieder!
Ich hatte zwar mehrfach von "durchschnittlichem Asm Programmierer"
gesprochen aber als so behauptetem Glauben schauts eben viel besser aus,
oder? Nein, dahinter steckt aber was anderes: Meine Beharrlichkeit,
Asm-Code im Ressourcenverbrauch bei 8-Bit MSR vor C zu sehen zeugt
weniger von Glauben denn von der Wahrheit ;-)
Hier!! ... Schon wieder! ...
Sowas meinte ich mit meiner Belobigung, die vorgestern gelöscht wurde:
Moby A. schrieb:> Ich glaube nicht mehr an den Weihnachtsmann ;-)> Ich nehme aber zur Kenntnis, daß das Mantra "Anforderungsliste" für die> wiederholte Auflistung von längst Bekanntem und einfachster> Funktionalität jener Nothaltegriff ist, der als Ausrede für unsere> C-Freunde unabdingbar ist um nicht in der Flut guter Argumente und> Fakten pro ASM den Halt zu verlieren ;-)
----------
Ihr Beitrag im Forum "Offtopic" wurde gelöscht.
Betreff: Re: Assembler wieder auf dem Weg nach vorn
Datum: 25.11.2015 21:07
Text des gelöschten Beitrags:
==============================================
Moby A. schrieb:> Vielleicht sollte ich die Rolle von Assembler mal etwas bildlich> verdeutlichen:>> Wenn auf der Bühne der Controller in Aktion ist [... u.s.w. u.s.f.]
Es ist unglaublich, wie du /[..selbst gelöscht..]/ trotzdem so excellent
ausgedrückt auf den Bildschirm bringst.
----------
Moby A. schrieb:> um nicht in der Flut guter Argumente und Fakten pro ASM
Software ohne Dokumentation/Anforderungsliste ist Müll.
Software, bei der man diese durch Analyse des Quelltextes erst
herausfinden muss, ist auch Müll.
Software, bei der man die Funktionsweise erst durch ständiges
Referenzieren des Datenblatts/UserGuides herausfinden kann, ist
ebenfalls Müll.
Und das ist auch bei Trivialsoftware wie Deinem Assembler"projekt" der
Fall.
Lothar M. schrieb:> Und wenn schon solche Kleingeräte mit 32-Rechnern ankommen, dann würde> ich niemals mehr mit 8-Bit uC und Assembler anfangen.
Was interessieren mich die Gründe des Herstellers diesen Gerätes
(vielleicht hat er gute, Berechnungen vielleicht?) wenn 8-Bit MSR ganz
offensichtlich einfacher mit AVR/ASM-Power gelöst ist (siehe mein
Projektchen)!
P. M. schrieb:> In diesem Punkt haben wir> dir schon lange zugestimmt: Ja, auf kleinsten Controllern kann Assembler> ein vernünftiges Werkzeug sein. Dann verallgemeinerst du aber wieder auf> grössere Projekte und Prozessoren.
Und auch Du unterstellst schon wieder, daß ich auf entsprechend
daten/berechnungsintensive Projekte und große Prozessoren
verallgemeinere.
Dabei hatte ich das wiederholt klargestellt.
Es ist aber erfreulich, hier Asm als "vernünftiges" Werkzeug bezeichnet
zu sehen- auch wenn ich die Obergrenze weit höher ziehen würde. Ich
finde dabei könnte man es jetzt belassen ;-)
Karl H. schrieb:> Erweitern?> Was willst du da erweitern?> Der Code ist so dermassen auf 2 ADC Eingänge und 2 Digitale Eingänge> hingeschustert, das Protokoll ist so dermassen auf genau diese> Konstellation hingearbeitet, dass man da nichts erweitern kann. Hat man> nicht genau diese Anforderungen, dann bleibt nichts anderes übrig, als> den Code komplett neu zu machen.
Das habe ich nun auch bis zum Erbrechen erläutert worin die
Erweiterungsmöglichkeiten bestehen. Sage bitte jetzt nicht, diese wären
nicht sinnvoll. Ansonsten nimm bitte hin, daß dies eine Hard/Software
angepasste und optimierte und demzufolge auch so effiziente Lösung
ist. Damit chancenlos mit C zu toppen!
> denn im Zweifel hab ich lieber eine Codebasis, die> ich auf meine Bedürfnisse anpassen kann als eine die ich komplett neu> schreiben muss, wenn ich nicht genau die vom Autor vorgegebenen> Anforderungen habe. Selbst wenn dann der Code ein paar Bytes länger ist> und ein paar Taktzyklen mehr braucht.
Schön und gut. Mach das doch. Asm lässt auch flexibler formulieren!
Bei einfachem 8-Bit MSR auf AVR kommt aber noch eines hinzu: Sooo
kompliziert ist das alles nicht, sogar mal eben komplett neuen Code
für eine andere I/O-Ausstattung zu erstellen wenns meinem Anspruch
zufolge so kompakt-optimiert und C-furchtlos bleiben soll.
Ich hoffe Du wolltest mir mit Deinem Beitrag nicht wieder eine "Brücke"
bauen und ich hab sie jetzt zum Einsturz gebracht ;-)
Moby A. schrieb:> Schön und gut. Mach das doch. Asm lässt auch flexibler formulieren!
Irgendwie scheinst du den Sinn einer Codesammlung zur Verfügungstellung
allgemeiner Lösungen für alle nicht verstanden zu haben.
Michael K. schrieb:> Was gerade das Kriterium ist und was aus der Wertung fällt ändert sich> nach Wind und Wellenschlag. Verbindliche Kriterien gibt es nicht,> vielmehr werden die jederzeit so angepasst das Du in deiner Wahrnehmung> im Recht bleibst.
Unsinn. Alles klar, alles verbindlich. Längst. Ich kann aber unter den
herrschenden Umständen hier verstehen wenn es manchem sehr schwer fällt,
ein Verständnis des Begriffs "Controller-Ressourcen" zu entwickeln...
Das ist alles eine sehr sehr komplexe Angelegenheit (oder sagen wir
besser: sie wird zu dieser gemacht ;-) Teil jenes Gummibands mit dem ich
mich konfrontiert sehe. Treibt mich aber nicht zur Weißglut. Der Mensch
wird halt erfinderisch wenn Offensichtliches doch noch irgendwie
vernebelt werden soll.
> Du behauptest was immer Du willst und nennst das dann Fakten.
Ich behaupte, was mein Code benötigt. Das sind Fakten.
Wer bietet weniger?
> Du wirfts C Verschwendung vor und verschwendest selber viel mehr.> stopfst Deinen Code aber mit unsinnigem voll
Ach wirklich? Dazu müsste es ja erstmal eine C-Lösung geben. Nur wird
die nie kommen weil sie BESSER nie kommen kann. Was mancher hier
(ich kanns gar nicht ernst nehmen) als Verschwendung bezeichnet gehört
für mich schlicht zu einem ordentlichen und erweiterungs-vorbereiteten
Programm. Der Strohhalm "Verschwendung" ist noch nichtmal ein
ernstzunehmender Strohhalm, sondern als Vorwurf dermaßen abstrus, daß es
höchstens noch als weichgekochte Nudel durchgeht ;-)
Aber prima Ablenkungstaktik, wenns doch eigentlich um besseren C-Code
gehen sollte. Nutzt die Gunst der Stunde! Mein Code ist so unsinnig
vollgepackt- ein Leichtes für jede mittelmäßige C-Lösung ;-))
> Das ist ein absolut irrer Amoklauf durch alles was unreife Kommunikation> ausmacht. Dementsprechend wirst Du behandelt.
Wie ein anonymer Moby hier behandelt wird interessiert mich nicht.
Der Amoklauf ergibt sich aus der Frechheit, wie ein durchschnittlicher
Asm-Programmierer hier manchen C-ler vorführt ;-)
> technischen Diskussion ein Schlagabtausch wird, dann blanker Hass, dann> völlige Resignation.
Na ich hoffe Du verortest blanken Hass und völlige Resignation jetzt
nicht auf meiner Seite. Wär nämlich weit gefehlt ;-)
Karl H. schrieb:> Irgendwie scheinst du den Sinn einer Codesammlung zur Verfügungstellung> allgemeiner Lösungen für alle nicht verstanden zu haben.
Humor hast Du ;-)
Da verschlägts mir jetzt ausnahmsweise mal wirklich die Sprache!
Die Lösung muß also "allgemein" sein. So so.
Moby A. schrieb:> Karl H. schrieb:>> Irgendwie scheinst du den Sinn einer Codesammlung zur Verfügungstellung>> allgemeiner Lösungen für alle nicht verstanden zu haben.>> Humor hast Du ;-)> Da verschlägts mir jetzt ausnahmsweise mal wirklich die Sprache!> Die Lösung muß also "allgemein" sein. So so.
Ergänzung: Ich hatte das ein meinem Projektthread sogar schon mal
scherzhaft vermutet:
Moby A. schrieb:> Offensichtlich enthalten die Forenregeln aber den neuen Passus:> "Projekte müssen für jedermann auch ohne Mühe und Vorkenntnis verwend-> und einfachst an alle Situationen anpassbar sein".
Nie im Leben hätte ich mir vorstellen können, daß so schnell draus Ernst
wird ;-)
Lothar M. schrieb:> Nein, sicher nicht. Aber es zeigt eben, dass wir heute in 2015 leben.
Was interessiert mich die Jahreszahl wenn ich die einfachste Lösung
will!
> Und dass man das Projekt dort nicht mit maximalem Aufwand in die> Programmierung in den kleinsten am Markt verfügbaren uC reinprügelt.
Von Reinprügeln kann gar keine Rede sein.
> Sondern "einfach" einen nimmt, der ausreichend leistungsfähig ist, und> dann auf eine Softwareplattform setzt, die portierbar und tendenziell> abstrakt ist.
Genau. Der PC wird schließlich auch alle paar Jahre aufgerüstet (um
unter dem Strich weiter die gleichen Aufgaben zu bearbeiten wie zuvor).
>> Faktenbasierteres als die Fakten zu Codesize, RAM-Verbrauch (und ggf>> Speed) gibts einfach nicht.> Doch: Marktzahlen und Produkteinführungstermine. Was nützt das schönste> und optimierteste Gerät, wenn es 2 Jahre zu spät am Markt ist?
Da geb ich Dir Recht. Andererseits bedeutet das aber oft nur: Schnelle
Quantität geht vor Qualität. Reift ja beim Kunden.
Rufus Τ. F. schrieb:> Software, bei der man die Funktionsweise erst durch ständiges> Referenzieren des Datenblatts/UserGuides herausfinden kann, ist> ebenfalls Müll.
Ziemlich allgemeines Statement ... bei einem Bildbetrachter stimme ich
dem zu, bei einem CAD-System schon weniger und bei einem Compiler gar
nicht ...
Matthias L. schrieb:> Karl H. schrieb:>> war im Ausland.>>>>gewünschten Zwischenmasse>>> In der Schweiz? Ich hätte ein ß verwendet, falls die Tastatur das> hergibt...
Weiter weg. China
A. K. schrieb:> Ein jeder hat in seinem individuellen Abstand sein Brett> vor dem Kopf. Aber erst durch den missionarischen Eifer, dies zum Ende> der Welt zu definieren, wird es zum Problem.
Asm auf 8-Bit Controller fürs MSR ist sicher nicht das Ende der Welt.
Aber in seinem Bereich optimal.
Jörg W. schrieb:> Dahingehend ist die Anforderung „darf keinen wertvollen RAM brauchen,> damit noch Platz für Erweiterungen ist“ ja völlig absurd, zumal> Register in einem Prozessor wohl immer teurer sind als RAM (Ausnahme:> Z8, bei dem gab es keinen Unterschied zwischen RAM und Registern).
Suchst Du schon wieder nach Ausreden?
Die Anforderung "Kein RAM" kommt Erweiterungen natürlich zugute!
Stell Dir eine umfangreiche Vorverarbeitung der Messwerte vor.
Vielleicht mit History und statistischer Auswertung.
Der eigentliche Grund für die Forderung ist aber ein ganz anderer:
Flash und SRAM sind variable MC-Ressourcen und das geniale C mit der
Kompetenz tausender Compiler-Bauer soll bei gleicher Funktionalität nur
wie behauptet zeigen, daß es damit besser umgehen kann!
Rufus Τ. F. schrieb:> Software, bei der man die Funktionsweise erst durch ständiges> Referenzieren des Datenblatts/UserGuides herausfinden kann, ist> ebenfalls Müll.
Du sollst keine Funktions- weise herausfinden sondern schlicht die
simple, schon mit dem ersten Diagramm und erst recht mit der zugehörigen
Beschreibung bzw. Kommentierung im Quelltext eindeutige Funktion ganz
nach Lust und Laune, aber ressourcensparender in C nachbauen.
P.S. Mir ist klar, daß ich mit dieser Formulierung jetzt auf gewisse
andere Architekturmerkmale meiner Software (wie zuvor verlangt)
verzichte. So stur ist der Esel gar nicht, obwohl er natürlich weiß, daß
der Schwierigkeitsgrad für die C-Lösung damit nur unmerklich sinkt ;-)
gähn.. wird langweilig hier..
@Moby: kannst nicht einfach irgendeine Erweiterung einbauen, in dein
"Projekt" ? (und veröffentlichen) damit wir mal was neues zum
Diskudieren haben..
1-Wire Slave Simiulieren, wäre z.B. interessant...
oder du traust dich endlich dein xmega projekt herzuzeigen?
Sven B. schrieb:> Ziemlich allgemeines Statement ... bei einem Bildbetrachter stimme ich> dem zu, bei einem CAD-System schon weniger und bei einem Compiler gar> nicht ...
Du hättest erkennen können, daß wir hier vom Quelltext reden.
Moby A. schrieb:> Du sollst keine Funktions- weise herausfinden sondern schlicht die> simple, schon mit dem ersten Diagramm und erst recht mit der zugehörigen> Beschreibung bzw. Kommentierung im Quelltext eindeutige Funktion ganz> nach Lust und Laune, aber ressourcensparender in C nachbauen.
Kind, ich verdiene mir seit über 25 Jahren mein Geld mit
Softwareentwicklung, und ich habe Unmengen an fremdem Quelltext
angesehen.
Zeug, das so aussieht wie Deins, überfliege ich bestenfalls und dann
landets in der Tonne. Das ist ein Muster ohne Wert. Selbst wenn es das
tun sollte, was Du behauptest, was es tut, ist es de facto
undokumentiertes Gefrickel.
Eine "eindeutige Funktion" ist da weder beschrieben noch der
Kommentierung im Quelltext entnehmbar. Die existiert nur in Deiner
Vorstellung.
Robert L. schrieb:> gähn.. wird langweilig hier..
So durch die Blume hab ich ja Recht erhalten, ganz offen kann das
natürlich niemand zugeben. Somit ist glaub ich vorläufig alles gesagt
;-)
> @Moby: kannst nicht einfach irgendeine Erweiterung einbauen
Nein, aber sollte wieder eine Meldung zu Asm mit meinen persönlichen
Erfahrungen deckungsgleich sein bring ich das gern wieder in die
Diskussion ein!
> 1-Wire Slave Simiulieren, wäre z.B. interessant...
brauch ich persönlich aber nicht.
> oder du traust dich endlich dein xmega projekt herzuzeigen?
Falls Du meine Haussteuerungs-Zentrale meinst hatte ich das aus
verständlichen Gründen schon abgelehnt. Wird aber bestimmt weitere
Asm-Codes von mir geben, um die effiziente Asm-Programmierung hier
zusammen mit anderen hochzuhalten! Falls ihnen K.H. nicht wieder
mangelnde "Allgemeinheit für alle" abspricht ;-)
Rufus Τ. F. schrieb:> Kind, ich verdiene mir seit über 25 Jahren mein Geld mit> Softwareentwicklung, und ich habe Unmengen an fremdem Quelltext> angesehen.
Aus dem Alter bin ich raus ;-)
> Zeug, das so aussieht wie Deins, überfliege ich bestenfalls und dann> landets in der Tonne. Das ist ein Muster ohne Wert
... weils C keine Chance lässt ;-)
> Selbst wenn es das> tun sollte, was Du behauptest, was es tut
Schon diese Formulierung offenbart jetzt mehr als Du vielleicht sagen
möchtest.
> Eine "eindeutige Funktion" ist da weder beschrieben noch der> Kommentierung im Quelltext entnehmbar. Die existiert nur in Deiner> Vorstellung.
Sagen wir mal so: Natürlich trau ich Dir die "Erkenntnis" der Funktion
zu. Vermutlich sogar ohne Worte, allein aus dem Diagramm abgelesen. Du
willst nichts zur Kenntnis nehmen. Das ist leider Gottes schon alles.
Rufus Τ. F. schrieb:> Zeug, das so aussieht wie Deins, überfliege ich bestenfalls und dann> landets in der Tonne. Das ist ein Muster ohne Wert. Selbst wenn es das> tun sollte, was Du behauptest, was es tut, ist es de facto> undokumentiertes Gefrickel.>> Eine "eindeutige Funktion" ist da weder beschrieben noch der> Kommentierung im Quelltext entnehmbar. Die existiert nur in Deiner> Vorstellung.
100% ACK.
Moby-Code hat mir das unvergessliche Erlebnis beschert, seinen ASM-Code
Bit für Bit und Befehl für Befehl aufdröseln zu müssen, um erahnen zu
können, was seine kryptischen Kommentare vielleicht bedeuten könnten.
Beitrag "Re: C versus Assembler->Performance"
Und das ging nicht nur mir so sondern auch Yalu, einem der hellsten
Köpfe hier
Beitrag "Re: C versus Assembler->Performance"
Johann L. schrieb:> Und das ging nicht nur mir so sondern auch Yalu, einem der hellsten> Köpfe hier
Tja, ihr seid eben alle noch schlechter als ein „mittelmäßiger
ASM-Programmierer“. :-)
Wenn ich mir überlege, was für einen Sche*** man seinerzeit alles so
auf dem Z80 zusammengestrickt hat, wird mir heute noch schlecht. Da
ist ein AVR ja harmlos, dank Harvard fällt selstmodifizierender Code
praktisch von selbst aus. ;-)
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
>Wenn ich mir überlege, was für einen Sche*** man seinerzeit alles so>auf dem Z80 zusammengestrickt hat, wird mir heute noch schlecht.
Wir waren jung, wild und schmerzfrei! ;-)
> Da>ist ein AVR ja harmlos, dank Harvard fällt selstmodifizierender Code>praktisch von selbst aus. ;-)
Auf dem Amiga mit 68000 ging das problemlos, aber solche Stunts hab ich
trotzdem nicht gemacht. Kugelfisch essen ist sinnvoller!
Jörg W. schrieb:> Tja, ihr seid eben alle noch schlechter als ein> „mittelmäßiger ASM-Programmierer“. :-)
Eher „8-Bit-MSR-Überlauf-brauch-ich-nicht-AVR-only-ASM-Programmierer“
Falk B. schrieb:> aber solche Stunts hab ich trotzdem nicht gemacht.
War auf dem Z80 gang und gäbe (auch im CP/M-Code selbst).
Beispiel:
1
buffsize:
2
;; return size of ring buffer
3
ld hl, b_start
4
put_pointer equ $ - 2
5
ld de, b_start
6
get_pointer equ $ - 2
7
and a
8
sbc hl, de
9
jp p, bfsz1
10
;; negative amount -> add size; ring buffer
11
ld de, b_end - b_start
12
add hl, de
13
bfsz1: ld a, l
14
ret
[Anm.: JP P,xx = "Jump if Plus"]
[Anm.2: AND A war ein gängiger Befehl zum Löschen des Carry-Flags]
Man beachte die labels "put_pointer" und "get_pointer". Die zeigen
auf den Direktoperanden des vorhergehenden LD RR,NN-Befehls.
Benutzt wurden diese dann als ganz normale Variablen:
Moby A. schrieb:> Robert L. schrieb:>> gähn.. wird langweilig hier..>> So durch die Blume hab ich ja Recht erhalten, ganz offen kann das> natürlich niemand zugeben. Somit ist glaub ich vorläufig alles gesagt> ;-)
nein, hast nu nicht,
und ja es wurde schon alles gesagt (ausser das was man hier nicht sagen
darf, weil es sonst eine persönliche Beleidigung wäre, und vermutlich
glöscht würde..)
und langweilig ist es,weil nur immer nur die selben "Argumente"
wiederholst..
>>> @Moby: kannst nicht einfach irgendeine Erweiterung einbauen>> Nein, aber sollte wieder eine Meldung zu Asm mit meinen persönlichen> Erfahrungen deckungsgleich sein bring ich das gern wieder in die> Diskussion ein!>
du hast unmengen speicher und flash "gespart" damit du dann KEINE
erweiterung einbaust..
>> 1-Wire Slave Simiulieren, wäre z.B. interessant...>> brauch ich persönlich aber nicht.>
und?
>> oder du traust dich endlich dein xmega projekt herzuzeigen?>> Falls Du meine Haussteuerungs-Zentrale meinst hatte ich das aus> verständlichen Gründen schon abgelehnt.
nein hast du nicht
>Wird aber bestimmt weitere> Asm-Codes von mir geben, um die effiziente Asm-Programmierung hier> zusammen mit anderen hochzuhalten!
hast du noch nie
> Falls ihnen K.H. nicht wieder> mangelnde "Allgemeinheit für alle" abspricht ;-)
ein größeres Projekt, besteht ja, auch bei dir: aus (vielen)
"Erweiterungen" (grobe Blöcke)
die ja wohl wiederverwendbar (für andere größere Projekte) sind..
sonst müsstest ja jedesmal alles neu schreiben..
deshalb ist deine Angst ja unbegründet..
Jörg W. schrieb:> Sparte halt zwei extra Bytes für die Daten. ;-)
Auch mit Harvard kann man Spässe treiben. Sinngemäss wäre das hier
möglich, bei PIC/AVR lohnt es aber aufgrund des steiferen Befehlsformats
nicht:
entry0: clc ; entrypoint mit C=0
.byte opcode(LDA ZP)
entry1: sec ; entrypoint mit C=1
Der LDA befehl dient hier nur dazu, den SEC zu maskieren. Arbeitet also
als 1-oder 2-Byte SKIP Befehl. Sowas in der Art hatte beispielsweise der
8KB PL/65 Compiler für den 6502 systematisch verwendet um jeweils 1 Byte
einzusparen. Konnte man aber sicherlich analog auch bei 8080/Z80 finden.
Besonders fies ist das beim Disassemblieren. Was aber auch dadurch nicht
leichter wurde, dass Strings als Parameter nicht umständlich mit
expliziter Adresse übergeben wurden, sondern implizit über den Program
Counter:
jsr puts
.byte 'Hallo Wel', 't'+$80
Diese Variante kann sich auch beim AVR lohnen.
PS: Bei dem PL/65 Compiler hat Moby Recht: In C hätte der niemals in die
2x 4KB ROMs gepasst.
Warum in aller Welt "diskutieren" gestandene Männer mit einem Subjekt
wie Moby? Früher (tm) hätte man ihn einfach ausgelacht und links liegen
gelassen. Helfersyndrom?
Fühlt ihr euch durch Mobys "Argumente" zur Diskussion oder gar
Verteidigung eures Standpunkts herausgefordert? Arme Irre gibt es
Millionen auf dieser Welt und man wird keinen von ihnen schlau machen.
Johann L. schrieb:> 100% ACK.>> Moby-Code hat mir das unvergessliche Erlebnis beschert, seinen ASM-Code> Bit für Bit und Befehl für Befehl aufdröseln zu müssen, um erahnen zu> können,
Wenn Du nur soviel sagen kannst solltest Du besser erstmal frühere
Erfolge auf Asm-Gebiet unerwähnt lassen.
Neben vielen erheiternden Momenten hier macht mich eine solche Äußerung
von einem erklärtermaßen erfahrenen Asm-Programmierer eher nachdenklich,
fast traurig. Ich kann mir das nur so erklären:
- Du willst nicht oder
- Du kannst nicht
Ist Deine letzte Beschäftigung mit AVR-Assembler vielleicht schon länger
her?
So wie Du Dich darstellst bzw. dargestellt wirst solltest Du meinen Code
bisherigen Umfanges nackt ohne weitere Worte lesen können, allenfalls
mit einer kurzen Beschreibung um was es geht...
Ich meine, worüber reden wir hier eigenlich?
Über die Organisation einer Mondlandung oder über einen kleinen
ACHT-BIT-Controller mit ein paar Registern, ein paar Vorschriften wie
dessen Steuerregister zu füllen sind und ein paar Dutzend simpler
Instruktionen?
Nun war noch nichtmal verlangt, meinen Projektcode wirklich zu
verstehen.
Zur Funktions-Nachbildung in einem C-Programm langt die kurze
Beschreibung.
Aber wenn man ängstlich ist und um sein C-Effizienzergebnis besorgt,
dann kann ich schon verstehen daß man fordert, ihn verstehen zu
können...
Da muß ich aber sagen: Sorry. Ein Asm-Kurs war nicht inklusive ;-)
Lothar M. schrieb:> Wir sind heute(!) aber fast 40 Jahre weiter...
Vor 40 Jahren funktionierte ein Hammer so wie heute auch.
Alt/Neu ist längst keine Aussage über Sinnvoll/Unsinnig.
> Ich habe aber keine solche Projektchen. Und falls doch, dann mache ich> die mit der selben Toolchain mit der ich die richtigen Projekte auch> mache...
... und bleibst damit mehr oder weniger weit von der möglichen
Asm-Effizienz entfernt. Und, hast viel Zeit investieren müssen das Ganze
irgendwann mal zu erlernen und zu beherrschen. Aber OK, solange es
Projekte gibt die davon wirklich profitieren...
> Da muß ich aber sagen: Sorry. Ein Asm-Kurs war nicht inklusive ;-)
Der war gut!
Sehe schon in der Zeitung mit den Großen Lettern:
"AVR-GCC Entwicklung muß eingestellt werden!
Moby-AVR verweigert Georg Johann Lay den Assembler-Kurs!"
Falk B. schrieb:> Fühlt ihr euch durch Mobys "Argumente" zur Diskussion oder gar> Verteidigung eures Standpunkts herausgefordert?
Ein frustriertes "Subjekt" Falk (ich spare mir weitere beleidigende
Untertöne) hat sich an der Diskussion um Fakten, wie in meinem
Projektchen dargestellt, fachlich gar nicht beteiligt. Vielleicht dank
seiner Einsicht um die Schwächen von C ?
Carl D. schrieb:> Moby-AVR verweigert Georg Johann Lay den Assembler-Kurs!
Davon würde ich nicht zu träumen wagen ;-)
Speziell von ihm bin ich aber enttäuscht.
Sage ich jetzt ohne Smiley.
> Vielleicht dank seiner Einsicht um die Schwächen von C ?
Oder vielleicht weil außer dir niemand an dem interessiert ist, was dir
als Fakten vorschwebt?
Bestimmt komisch, wenn man als einziger Geisterfahrer unterwegs ist...
Klaus W. schrieb:> Oder vielleicht weil außer dir niemand an dem interessiert ist, was dir> als Fakten vorschwebt?
Flash- und SRAM Verbrauch sind Fakten.
Asm ist in dieser Disziplin besser.
Das interessiert mich.
Für wen anderes wichtiger ist soll es anders lösen.
Aber nicht obigen Fakten widersprechen.
Moby A. schrieb:> Flash- und SRAM Verbrauch sind Fakten.> Asm ist in dieser Disziplin besser.> Das interessiert mich.
Das Wichtigste fehlt:
Die Entwicklungszeit. Du da ist jeder Sprache vor ASM. Und das
interessiert alle anderen.
Matthias L. schrieb:> Das Wichtigste fehlt:>> Die Entwicklungszeit.
Genau.
Natürlich kann man ein Haus bauen, indem man die Ziegelsteine aus
einzelnen Sandkörnern zusammenklebt. Da bekommt jeder Ziegelstein genau
die richtige Form und die richtigen Abmessungen und kann so
beispielsweise für Kabel o.ä. schon vor dem Mauern der Wand mit den
richtigen Schlitzen, oder für Steckdosen, Lichtschalter o.ä. mit den
richtigen Löchern versehen werden.
Aber das macht niemand.
Rufus Τ. F. schrieb:> Natürlich kann man ein Haus bauen, indem man die Ziegelsteine aus> einzelnen Sandkörnern zusammenklebt.
Und nicht vergessen: die oberen 2 Stockwerke sind für Erweiterungen
reserviert und dürfen erst mal nicht bewohnt werden. Und jedem, der am
Haus vobeiläuft unbedingt erklären, wie wichtig dieser Leerstand ist.
Carl D. schrieb:> er am Haus vobeiläuft unbedingt erklären
Tut ja keiner. Das Grundstück bleibt leer, weil Moby immernoch am ersten
Zeigelsteil ist. Dafür wurde kein Milligramm Ton zuviel angerührt
Rufus Τ. F. schrieb:> Natürlich kann man ein Haus bauen, indem man die Ziegelsteine aus> einzelnen Sandkörnern zusammenklebt. Da bekommt jeder Ziegelstein genau> die richtige Form und die richtigen Abmessungen
Prima. Ein Vorzug von Asm ist damit gut beschrieben.
Mit Übung, Vorbereitung und System kann auch das Haus durchaus
ansehnlich werden.
Matthias L. schrieb:> Das Wichtigste fehlt:>> Die Entwicklungszeit. Du da ist jeder Sprache vor ASM. Und das> interessiert alle anderen.
Mit Übung, Vorbereitung und System kann auch die Entwicklungszeit
durchaus im Rahmen bleiben.
Matthias L. schrieb:> Tut ja keiner. Das Grundstück bleibt leer, weil Moby immernoch am ersten> Zeigelsteil ist.
Nein, Moby hat fertig. Der C-ler ist noch am Lernen und
Auseinandersetzen mit seinem Werkzeug ;-)
Carl D. schrieb:> Und nicht vergessen: die oberen 2 Stockwerke sind für Erweiterungen> reserviert und dürfen erst mal nicht bewohnt werden. Und jedem, der am> Haus vobeiläuft unbedingt erklären, wie wichtig dieser Leerstand ist.
Das muß man glaub ich nicht erklären. Das Platzangebot zieht als
Werbeargument von ganz alleine ;-)
Moby A. schrieb:> Mit Übung, Vorbereitung und SystemMoby A. schrieb:> Nein, Moby hat fertig. Der C-ler
Wie kommst du eigentlich darauf, dass das hier der Kampf des einsamen
Rächers der Mnemonic gegen die C-dioten ist?
Dieser Thread ist der erfolglose Versuch einiger Leute mit vernünftigen
Argumenten mit einem Phrasendrescher zu diskutieren. Insofern hast du
also gewonnen.
Ist aber ein Pyrrhussieg, weil dich niemand mehr ernst nimmt.
mfg.
Moby A. schrieb:> Mit Übung, Vorbereitung und System kann auch das Haus durchaus> ansehnlich werden.
Das Problem hierbei ist die viel zu kurze typische Lebenserwartung des
Menschen. Kaum jemand, der sich ein Haus bauen möchte, ist bereit, dafür
die Bauzeit des Kölner Doms hinzunehmen.
Außer dem hier oft beschworenen "ASMler".
Thomas E. schrieb:> Ist aber ein Pyrrhussieg, weil dich niemand mehr ernst nimmt.
Das ist dem Moby egal, denn mit jedem Beitrag hier brnigen wir
"Assembler weiter auf dem Wag nach vorne".
Und da die Häufigheit der Verwendung von Assembler locker im Rauschen
untergeht, hat jeder ASM-Pups einen gewaltigen Hebel was wie
"Popularität" von Assembler angeht.
Also schön weiter pupsen...
Rufus Τ. F. schrieb:> Kaum jemand, der sich ein Haus bauen möchte, ist bereit, dafür> die Bauzeit des Kölner Doms hinzunehmen.
Genau an dieser Stelle hakt der Vergleich, was die zeitliche Dimension
angeht.
Wenn man sich es genau beschaut geht auch gar nicht soviel Zeit in die
eigentliche Implementierung. Die meiste Überlegung benötigt ein solider
Programmablauf-Plan unter Einbeziehung der vorhandenen Peripherie. Das
wär in Hochsprache auch nichts anderes.
Sandkorn/Ziegelstein ist eigentlich auch nicht das richtige
Größenunterschied. Ich hatte Asm vs. C hinsichtlich
Hardware-Anpassungsfähigkeit mal mit Ziegel- vs. Hohlblockstein
verglichen. Passt für meinen Geschmack besser.
Thomas E. schrieb:> mit einem Phrasendrescher zu diskutieren
Fakten-Drescher! Fakten-Drescher! Fakten-Dresche, die mit eigenem Code
belegt ist. Das gibt der Provokation gewisser Leute ja gerade die
entscheidende Würze ;-)
Die war genau dann erfolgreich, wenn nur noch Unterstellungen,
Lächerlichmachen und Beleidigungen zurückkommem.
Johann L. schrieb:> Und da die Häufigheit der Verwendung von Assembler locker im Rauschen> untergeht,
Klare Übertreibung. Selbst in C muß nach wie vor drauf zurückgegriffen
werden, auch wenn C der große Standard bleibt. Gerade deshalb fand ich
aber die Meldung von der Asm-Entwicklung im Tiobe-Programmierindex so
bemerkenswert!
Ein redlicher professioneller Programmierer sollte das nicht so abfällig
abtun ;-(
Karl H. schrieb:> Irgendwie scheinst du den Sinn einer Codesammlung zur Verfügungstellung> allgemeiner Lösungen für alle nicht verstanden zu haben.
Deshalb schrieb ich ja hier:
Beitrag "Re: C versus Assembler->Performance"
--------------------------------------------------------------------
"Dann ist das Programm für 99,9% der typischen Anwender sinnlos.
Damit erfüllt es weder den Anspruch einer Weiterverwendung, noch hat es
etwas in der Codesammlung zu suchen, da für die Allgemeinheit
unbrauchbar. Ich plädiere daher dafür, dass ein Mod es aus der
Codesammlung verschiebt."
--------------------------------------------------------------------
Leider ist es heute noch unter Codesammlung zu finden, obwohl es
darunter nichts zu suchen hat. Es ist und bleibt für andere User
unbrauchbar.
Frank M. schrieb:> Leider ist es heute noch unter Codesammlung zu finden, obwohl es> darunter nichts zu suchen hat. Es ist und bleibt für andere User> unbrauchbar.
Unbrauchbar ist Deine Art, von Deinen auf die Interessen der
Allgemeinheit zu schließen.
@ Frank M. (ukw) Benutzerseite
>Leider ist es heute noch unter Codesammlung zu finden, obwohl es>darunter nichts zu suchen hat. Es ist und bleibt für andere User>unbrauchbar.
Nicht ist unnütz, es kann auch als schlechtes Beispiel dienen. ;-)
Falk B. schrieb:> Nicht ist unnütz, es kann auch als schlechtes Beispiel dienen. ;-)
So wie Dein Auftreten hier, meinst Du?
Ein schlechtes, da störendes Beispiel ist
Beitrag "Kleines Tiny13 Sensorboard"
nur für die, die gern die allumfassende Überlegenheit von Hochsprachen
propagieren ;-)
Johann L. schrieb:> Vielleicht solltest du mal gute Beiträge beherzigen
Ohne hier nochmal das Thema "Anforderungsspezifikation" für ein
einfaches Projektchen durchzukauen: Keine "Spezifikation" der Welt hätte
dazu geführt, daß eine bessere C-Lösung das Licht ebendieser erblickt.
Davon abgesehen: Beherzigen tu ich gerne was. Es hilft aber alles
nichts, es muß mich überzeugen.
Zum Beispiel überzeugt mich, was ich irgendwo von einem Mod gelesen
habe: Wenn in einem Thread zuviele Du/Dir/Deine vorkommen, sich die
Diskussion also vom Fachlichen komplett ins Persönliche verlagert ist
der Zeitpunkt gekommen, einen Thread zu beenden. Ich muß sagen, die
Logik kann ich nachvollziehen...
Schließlich hätte ich noch etwas was Du beherzigen solltest:
Johann L. schrieb:> mit jedem Beitrag hier brnigen wir> "Assembler weiter auf dem Wag nach vorne"
;-)
Frank M. schrieb:> Leider ist es heute noch unter Codesammlung zu finden, obwohl es> darunter nichts zu suchen hat.
Naja, das trifft sicher auf einen nicht ganz kleinen Anteil der
Codesammlung zu. Es kann ja einfach jeder für sich entscheiden,
ob ihm das nützlich genug wäre für einen Nachnutzung.
Johann L. schrieb:
> mit jedem Beitrag hier brnigen wir> "Assembler weiter auf dem Wag nach vorne"
Der TIOBE-Index wertet "Suchanfragen an Suchmaschinen" aus.
Da "hilft" keine Diskussion um ASM, sondern nur direktes Suchen.
Und da man hier ja mit genügend Nutzlosem zum Thema ASM versorgt wird,
will davon garnicht mehr.
Moby freut sich also zu früh auf den noch größeren Sieg seiner "Fakten"
in der nächsten Ausgabe dieser "wertvollen" Statistik.
Und die anderen fahren weiter als wäre nichts gewesen und nur einer
weiß, daß in De (und AT, ...) inzwischen auf Linksverkehr umgestellt
wurde.
Moby A. schrieb:> Thomas E. schrieb:>> mit einem Phrasendrescher zu diskutieren>> Fakten-Drescher!
Nee, Phrasendrescher, Thomas hat schon Recht.
> Ein redlicher professioneller Programmierer sollte das nicht so abfällig> abtun ;-(
Daß ausgerechnet Du Dich nach Deinen miesen Betrügereien und
Verdrehungen noch traust, von Redlichkeit zu sprechen, ist der absolute
Hohn.
Moby A. schrieb:> Der eigentliche Grund für die Forderung ist aber ein ganz anderer:> Flash und SRAM sind variable MC-Ressourcen und das geniale C mit der> Kompetenz tausender Compiler-Bauer soll bei gleicher Funktionalität nur> wie behauptet zeigen, daß es damit besser umgehen kann!
Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein
ganz anderer:
Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung
eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man
keinen Krüppel-Code schreiben will), dieser befindet sich traditionell
ebenfalls im RAM.
Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne
Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu
gewinnen...
Moby A. schrieb:> das geniale C mit der Kompetenz tausender Compiler-Bauer
Und diesen Sarkasmus spar dir mal lieber du trauriges Würstchen
(Beleidigung intended).
Jeder der aktiv an einem Compiler mitgewirkt hat hat wahrscheinlich ein
zigfaches deiner bescheidenen ASM-Kenntnisse.
Da solltest echt mal lieber haushalten.
*Ich sage bewusst "ohne Klimmzüge". Denn dank den genialen
Compilerbauern ist C heute hinreichend flexibel um Klimmzüge zu
ermöglichen, die einen RAM bei kleinen Projektchen nicht zwingend
vorraussetzen. (Z.B. die Möglichkeit, automatische Variablen in
Registern zu parken)
Moby A. schrieb:> Rufus Τ. F. schrieb:>> Natürlich kann man ein Haus bauen, indem man die Ziegelsteine aus>> einzelnen Sandkörnern zusammenklebt. Da bekommt jeder Ziegelstein genau>> die richtige Form und die richtigen Abmessungen>> Prima. Ein Vorzug von Asm ist damit gut beschrieben.> Mit Übung, Vorbereitung und System kann auch das Haus durchaus> ansehnlich werden.
Damit ist Mobys Welt/Horizont doch eindeutig beschrieben.
Jede weitere Diskussion ist in meinen Augen hinfällig.
Sheeva P. schrieb:> nach Deinen miesen Betrügereien
Du hast Dich ganz einfach selbst betrogen.
Man sollte schon selber wissen, was man wann in Angriff nimmt. Dir fehlt
auch die Einsicht in die Unmöglichkeit der Aufgabe. Nun bin natürlich
ich schuld. Schau mal mit offenen Augen, wieviel unter der Gürtellinie
ich dafür einstecken musste.
Gu. F. schrieb im Beitrag #4368556:
> Rufus Τ. F. schrieb:> Womit verdienst Du Dein Geld?>> Trollen
Für Deine Trollerei gäbs keinen Cent ;-)
So, nun können sich die "getroffenen Hunde" mal richtig ausheulen und
gegenseitig die Wunden lecken. Ich denke zum Thema ist hier alles
gesagt.
Daß ich nicht auf fast jede Äußerung, und sei sie noch so sehr mit
Verdrehungen, Unterstellungen und Ablenkungsmanövern gespickt
eingegangen bin, kann mir niemand vorwerfen. Gegenseitiges Rumzicken ist
aber jetzt von meinem Zeitbudget nicht mehr gedeckt ;-)
Moby
Moby A. schrieb:> Johann L. schrieb:>> Vielleicht solltest du mal gute Beiträge beherzigen>> Ohne hier nochmal das Thema "Anforderungsspezifikation" für ein> einfaches Projektchen durchzukauen: Keine "Spezifikation" der Welt hätte> dazu geführt, daß eine bessere C-Lösung das Licht ebendieser erblickt.
Da Du es nicht probiert hast, kannst Du das nicht wissen. Im Gegenteil
hast Du das mit allen unfairen Mitteln und miesen Tricks behindert.
Als Du oben von Redlichkeit gefaselt hast, bin ich vor Lachen fast
erstickt!
> Davon abgesehen: Beherzigen tu ich gerne was.
Nö.
> Es hilft aber alles nichts, es muß mich überzeugen.
Da Du gar nicht überzeugt werden willst und das mit allen unfairen
Mitteln und miesen Tricks behinderst, ist das nutzlos. Ansonsten würdest
Du uns ja einen fairen, ergebnisoffenen Wettbewerb liefern. Aber dazu
bist Du offenbar zu feige. Wahrscheinlich weißt Du selbst, daß Du dabei
nur verlieren kannst, weil Dein Assemblercode so schlecht ist. Viel
Gegacker um nichts also, aber das ist man von Dir ja gewohnt. ;-)
le x. schrieb:> Moby A. schrieb:>> Flash und SRAM sind variable MC-Ressourcen und das geniale C mit der>> Kompetenz tausender Compiler-Bauer soll bei gleicher Funktionalität nur>> wie behauptet zeigen, daß es damit besser umgehen kann!>> Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein> ganz anderer:> Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung> eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man> keinen Krüppel-Code schreiben will), dieser befindet sich traditionell> ebenfalls im RAM.>> Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne> Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu> gewinnen...
Viel lustiger ist ja, wie es zu dieser Anforderung gekommen ist. Er
hatte sich offensichtlich und deutlich erkennbar ja schon die
größtmögliche Mühe gegeben, es einem Compiler so schwer wie nur möglich
zu machen -- und als bereits mein erster hingerotzter C-Versuch deutlich
kleiner aussah als sein Assembler-Gefrickel, hat er die Sache mit dem
RAM erfunden.
Wie gesagt: er ist nichts weiter als ein Falschspieler und weder an
einem fairen, offenen Wettbewerb noch an einem Erkenntnisgewinn
interessiert.
Warum kann man sich hier eigentlich nicht einfach darauf einigen, dass
einfache Projekte (sagen wir bis 500 Zeilen) in Assembler gegebenenfalls
einfacher lösbar sind und komplexere in Hochsprache, z.B. C? Und ja,
Teile davon dürfen auch gerne in Assembler programmiert sein.
Wenn jemand Freude an Assembler-Programmierung hat, C64, Z80, PIC,
Resourcenmangel, Zeitüberschuss, ja freilich, warum nicht.
Der Großteil der Leserschaft wird die "bessere" Programmiersprache aber
anhand von Eigenschaften wie Zeitersparnis, Wartbarkeit, Komplexität,
Fehlerträchtigkeit... beurteilen.
Moby, las' uns doch einen Blick auf einen Deiner 10000-Zeiler in
Assembler werfen oder nenne zumindest eines, dann können wir darauf
basierend weiterdiskutieren.
Grüße,
Christian <- Der PIC-Controller Zeit seines Lebens nur in
Assembler programmiert hat ("wir hatten ja nichts")
> einfache Projekte (sagen wir bis 500 Zeilen) in Assembler> gegebenenfalls einfacher lösbar sind
Es könnte aber auch so sein, daß 500 Zeilen Assembler 50 Zeilen C
entsprechen. Und kleine Projekte auch mit C-Bloat locker in die kleinste
HW passen.
Und ganz besonders, daß niemand hier vorschreibt, nur noch in C zu
programmieren, sonder eher das Umgekehrte passiert.
PS: mein erster Versuch einen AVR zu programmieren, war auch in ASM. Hat
funktioniert und dann wollte ich das Ganze in C haben, was nicht
funktionierte. Nur war ich mir sicher (nach 20 Jahren C und 10 Jahren
C++ auf diversem >= PC), daß es möglich sein mußte. Statt Flinte ins
Korn werfen, einfach mal durchbeißen und rausfinden was man falsch
gemacht hat. Muß man nicht, aber daß andere deshalb nicht dürfen sollen?
PPS: Schade daß Moby's letzte Entgleisungen gelöscht wurden. Die hätten
dokumentiert, warum Verständnis für seinen Standpunkt nur schwer
Aufkommen kann.
Moby A. schrieb:> Ich denke zum Thema ist hier alles gesagt.
Das denk ich auch. Schon lange. Aber sehr wahrscheinlich noch nicht von
Jedem...
Und auf diese kuriose Art wird dieser Thread locker auch noch die 1000er
Marke knacken. Wetten?
Eddy C. schrieb:> Warum kann man sich hier eigentlich nicht einfach darauf einigen, dass> einfache Projekte (sagen wir bis 500 Zeilen) in Assembler gegebenenfalls> einfacher lösbar sind und komplexere in Hochsprache, z.B. C?
Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C.
> Der Großteil der Leserschaft wird die "bessere" Programmiersprache aber> anhand von Eigenschaften wie Zeitersparnis, Wartbarkeit, Komplexität,> Fehlerträchtigkeit... beurteilen.
Diese Kategorien sind für Moby vollkommen unwichtig.
> Moby, las' uns doch einen Blick auf einen Deiner 10000-Zeiler in> Assembler werfen oder nenne zumindest eines, dann können wir darauf> basierend weiterdiskutieren.
Das wird er aus Angst, nach seinen eigenen willkürlichen Kriterien
besiegt zu werden, natürlich nicht tun.
Sheeva P. schrieb:> Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C.
Das ist genauso Unsinn wie Mobys Ideolgie.
Ist aber hier trotzdem (oder deswegen) eine angemessene Aussage.
Klaus W. schrieb:> Sheeva P. schrieb:>> Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C.>> Das ist genauso Unsinn wie Mobys Ideolgie.
Das glaube ich nicht, Tim. ;-) In Assembler bedarf es genauer Kenntnis
der Hardware (zB. byte order) und ihres Befehlssatzes, sowie der Syntax
des zu verwendenden Assemblers. Schon für eine schlichte Addition in
Assembler muß ich wissen, was es mit Carry-, Sign-, Zero- und
Overflow-Flags auf sich hat, aufpassen, daß ich keine unterschiedlichen
Datentypen (signed und unsigned) addiere, ... In C nimmt mir das alles
mein Compiler ab.
Allerdings hänge ich da keiner Ideologie an und bin für sachliche
Argumente natürlich jederzeit offen. Wenn Dir also ein Problem einfällt,
das sich mit Assembler einfacher lösen läßt als in C: zeig her, und ich
widerrufe. ;-)
Carl D. schrieb:> Es könnte aber auch so sein, daß 500 Zeilen Assembler 50 Zeilen C> entsprechen. Und kleine Projekte auch mit C-Bloat locker in die kleinste> HW passen.
Ja, absolut richtig! Mit "gegebenenfalls" wollte ich lediglich eine
Pauschalisierung verhindern und meinte eine Wahrscheinlichkeit von nicht
höher als 5%, wenn die Makros bereitliegen und Copypasta angerichtet
ist.
Je kleiner das Projekt, umso höher die Wahrscheinlichkeit, dass es
komplett in Assembler implementiert wird.
Je jünger der Entwickler ("fang' ich doch mal mit Assembler an"), umso
höher die Wahrscheinlichkeit, dass er noch nie was anderes programmiert
hat. Somit sind gefühlte 50% aller Einsteiger überzeugte
Assemblerprogrammierer ("ASM rulez!")
> Somit sind gefühlte 50% aller Einsteiger überzeugte> Assemblerprogrammierer ("ASM rulez!")
Früher (Anfang der 80er) waren es bestimmt 100%. Aber nicht aus
Überzeugung, sondern aus Mangel an kaufbaren Compilern.
[Ironie]Wenn man das Grundlage nimmt, dann ist zu prognostizieren, daß
2050 niemand mehr Assembler benutzen wird. Somit handelt es sich beim
Titel dieses Threads nur um ein Aufbäumen vor dem Untergang.[/Ironie]
Moby A. schrieb:> Wolfgang S. schrieb:>> Ich fand lediglich seine Beiträge bis hierhin (weiter habe ich bisher>> nicht gelesen) ausgesprochen ausgewogen und neutral. Erstaunlich, daß>> ausgerechnet das dann offenbar besonders provokant erscheint.>> Wahrheiten die man nicht zur Kenntnis nehmen will können schon sehr> provokant wirken.
Mit "seine Beiträge" meinte ich nicht Deine Beiträge, sorry, das hast Du
mißverstanden. Ich ärgerte mich nur über den Mob, bei dem einzelne
Figuren mindestens so viel missionarischen Eifer zeigen wie Du und,
augenscheinlich im Schutz der Masse, auch auf jeden eindreschen, der
nicht eifrig mitdrischt. Also z.B. auf Michael K. Allein dies wäre für
mich ein Grund, mich von solchen Diskussionen fernzuhalten - sie machen
nicht mal Spaß. :(
Mit der Einschränkung doch noch kurz was zum Thema.
Ich teile das Vergnügen am Herumbosseln auf Instruktionssatzebene an
Kleinstsystemen, sehe das aber vorwiegend als eine Art Ausgleichssport.
Andere Leute lösen Kreuzworträtsel, spielen Strategiespiele, joggen oder
unterhalten sich sonstwie, ohne sich zu rechtfertigen, daß sie nicht den
Bus nehmen oder sich vorhalten zu lassen, daß ein Computer das doch sehr
viel schneller könnte. Abgesehen hilft es auch, nicht ganz die
Bodenhaftung zu verlieren.
Auch meine grundsätzliche Einschätzung, daß der Informatik als
Fachrichtung die schnelle Weiterentwicklung der Hardware nicht wirklich
gut getan hat, daß dadurch viele langfristig wünschenswerte
Entwicklungen abgebrochen oder aufgeschoben wurden und daß wir
mittelfristig in eine Komplexitätsfalle laufen, führt eher noch weiter
weg von der Vorstellung, daß man Prozessoren auf ISP-Ebene händisch
programmiert. Das, was Dir hier oft genug vorgehalten wird, daß Compiler
besser und vor allem billiger und schneller optimieren können als
Menschen, trifft zu, da ginge aber IMHO noch eine Menge mehr.
le x. schrieb:> Indem du also die Nutzung des RAMs verbietest
Da er allerdings Interrupts benutzt, benutzt er auch RAM. Ein Polling
der Moby-IRQs wurde natürlich auch als Unsinn abgetan. Dabei bliebe
damit das RAM wirklich unberührt.
Sein "Projekt" ist nach seiner Aussage eine Vorlage für Anfänger.
Deswegen hat er den nahezu gleichen Overhead eingebaut, wie es ein
C-Compiler tut. Und auch die Interrupts. Dadurch können seine
Asm-Schäflein den Code mühelos erweitern.
Und der arme Anfänger packt den leeren RAM bis zum Rand voll, dann kommt
der erste Moby-Interrupt und zerschiesst ihm seine Daten.
Das passiert einem Fortgeschrittenen natürlich nicht. Der braucht aber
auch kein Moby-Asm.
mfg.
Winfried J. schrieb:> bit operationen in C sind wirklich nicht so einfach zu> realisieren wie in ASM
Auf welchen Assembler bzw. Hardware beziehst du dich?
In C gibt es immerhin AND, OR, XOR, NOT und bitweise Schiebeoperationen.
Auf einem AVR um konstanten Offset zu schieben ohne eine lahmarschige
Schleife herzunehmen ist m.E. nicht per se offensichtlich. Insbesondere
wenn mehr als 1 Maschinenwort zu behandeln ist. (Was Moby qua "8-Bit MSR
ohne Überlauf" ja bereits ausgeschlossen hat).
Natürlich gibt es Instruktionen, die von C aus verwendet werden müssen,
aber in C nicht beschreibbar sind. Für AVR sind das z.B. SEI, CLI, NOP,
WDR, SLEEP, etc.
Das ist aber einfach per Inline-Assembler handhabbar.
Und das die C-Sprachdesigner die Möglichkeit von (Inline-)Assembler
vorgesehen haben, ist keine Schwäche von C, sondern eine Stärke. Zum
Glück hatten sie nicht wie manch anderer -- der die Welt gerne in
"C-ler" und "ASM-ler" unterteilt (welches Chromosom codiert eigentlich
für diese Eigenschaft?) -- "X-ler" Mauern im Kopf.
Uhu U. schrieb:> Sheeva P. schrieb:>> sowie der Syntax des zu verwendenden Assemblers>> Die C-Syntax musst du aber kennen, sonst wird das nix...
Da hat man dann aber was gelernt, was man vom AVR auf x86 mitnehmen
kann. Z.B. um bei einem "Hello C-World" nicht völlig zu verzweifeln.
Und:
Neuem wird immer zunächst mit Skepsis begegnet.
Das ist gut, sollte aber nicht zum Dauerzustand werden, sobald das
individuelle Kosten/Nutzenverhältnis es zulässt.
Nein, das ist nicht von mir. Das ist unser TO zum Thema "muß mein Haus
komplett automatisiert sein".
Ich schalte mein Licht immer noch selber ein, aber überlasse dem
Compiler die Registerbelegung. Ist das nicht krass?
Carl D. schrieb:> Ich schalte mein Licht immer noch selber ein, aber überlasse dem> Compiler die Registerbelegung. Ist das nicht krass?
Woaaah! Steinzeit!
ICH steuere die Registerbelegung per Smartphone-App!
Sheeva P. schrieb:> Klaus W. schrieb:>> Sheeva P. schrieb:>>> Es gibt kein Problem, das in Assembler einfacher lösbar wäre als in C.>>>> Das ist genauso Unsinn wie Mobys Ideolgie.>> Das glaube ich nicht, Tim. ;-) In Assembler bedarf es genauer Kenntnis> der Hardware (zB. byte order) und ihres Befehlssatzes, sowie der Syntax> des zu verwendenden Assemblers. Schon für eine schlichte Addition in> Assembler muß ich wissen, was es mit Carry-, Sign-, Zero- und> Overflow-Flags auf sich hat, aufpassen, daß ich keine unterschiedlichen> Datentypen (signed und unsigned) addiere, ... In C nimmt mir das alles> mein Compiler ab.
Das was du jetzt anbringst, mag stimmen.
Aber die Ausage "Es gibt kein Problem, das in Assembler einfacher lösbar
wäre als in C." hat doch damit nichts zu tun und ist unabhängig davon
falsch.
Wenn es sehr maschinennah wird, ist Assembler natürlich einfacher.
Daß das nur bei wenigen Programmen (und wenn bei größeren dann nur in
einem kleinen Teil von denen) so ist, steht auf einem anderen Blatt.
(Abgesehen davon bin ich kein Tim.)
Klaus W. schrieb:> Aber die Ausage "Es gibt kein Problem, das in Assembler einfacher lösbar> wäre als in C." hat doch damit nichts zu tun und ist unabhängig davon> falsch.>> Wenn es sehr maschinennah wird, ist Assembler natürlich einfacher.
Mit "add" und "adc" habe ich das doch sogar schon auf der Ebene
einzelner Instruktionen gezeigt. Warum sollte meine Aussage also falsch
sein?
> (Abgesehen davon bin ich kein Tim.)https://de.wikipedia.org/wiki/H%C3%B6r_mal,_wer_da_h%C3%A4mmert#Al_und_Tool_Time
Klaus W. schrieb:> Aber die Ausage "Es gibt kein Problem, das in Assembler einfacher lösbar> wäre als in C." hat doch damit nichts zu tun und ist unabhängig davon> falsch.
Kommt drauf an. Wenn man den Prozessor direkt steuern muss, dann kommt
man nicht um Assembler herum. Aber zählt das dann noch als eigentliche
Programmierung, oder hat das dann nicht eher den Charakter von
Steuerbefehlen - anstatt an ein Peripherie-Gerät halt direkt an den
Prozessor.
Bei allem, was nicht zur direkten Steuerung des Prozessors dient,
stimmt die Aussage IMHO. Bin aber offen für ein Gegenbeispiel.
Für die Fähigkeit einen Thread zu kreieren und am Leben zu erhalten der
sich seit vielen 100 Beiträgen nur im Keis dreht, sollte Moby einen
Preis bekommen.
Im Ernst, er bleibt am Ball, kommentiert fast alles was inhaltlich zu
kommentieren ist und hält dabei die Provokation permanent aufrecht so
daß der Thread wächst und wächst und wächst.
Als Kommunikationsexperiment wirklich recht aussergewöhnlich.
Inhaltlich ist das natürlich alles nur noch mäßig interessant und
relativ ermüdent.
Eine gehobene Form des Clickbaiting.
Ganz spannend wenn man sich nicht zu sehr von dem belanglosem Thema
ablenken lässt um das es vordergründig geht.
Michael K. schrieb:> Für die Fähigkeit einen Thread zu kreieren und am Leben zu erhalten der> sich seit vielen 100 Beiträgen nur im Keis dreht, sollte Moby einen> Preis bekommen.> Im Ernst, er bleibt am Ball, kommentiert fast alles was inhaltlich zu> kommentieren ist und hält dabei die Provokation permanent aufrecht so> daß der Thread wächst und wächst und wächst.
Was das angeht, hat Moby seinen Meister noch lange nicht gefunden.
Der unangefochtete Bait-König ist zweifellos Kurt. Dessen Bait-fu ist
so progrediert, dass es einen schon gruselt.
Und ja, ab einem bestimmten Punkt taugen solche Threads nicht mehr zur
Wissensvermittlung und weder als Belustigung noch als Ärgernis, sondern
nur noch als Psychogramm der jeweiligen Stars.
Johann L. schrieb:> Und ja, ab einem bestimmten Punkt taugen solche Threads nicht mehr zur> Wissensvermittlung und weder als Belustigung noch als Ärgernis, sondern> nur noch als Psychogramm der jeweiligen Stars.
In der Tat kratze ich mich seit längerem am Kopf betreffend der Frage,
warum ich in so einem Thread eigentlich noch mitdiskutiere. Über
weiteste Strecken war er ja weder sachlich noch rhetorisch interessant.
Moby hat sachlich keine Argumente und rhetorisch beschränkt er sich auf
das konsequente ignorieren oder belächeln von Gegenargumenten.
P. M. schrieb:> Moby hat sachlich keine Argumente und rhetorisch beschränkt er sich auf> das konsequente ignorieren oder belächeln von Gegenargumenten.
Nö, er bekommt das Kunststück fertig, sämtliche Gegenargumente für
sich als Gewinn zu verbuchen. ;-)
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
>> Moby hat sachlich keine Argumente und rhetorisch beschränkt er sich auf>> das konsequente ignorieren oder belächeln von Gegenargumenten.>Nö, er bekommt das Kunststück fertig, sämtliche Gegenargumente für>sich als Gewinn zu verbuchen. ;-)
Ein Meister des Jiu Jitsu!
https://de.wikipedia.org/wiki/Jiu_Jitsu
"Ziel des Jiu Jitsu ist es, einen Angreifer – ungeachtet dessen, ob er
bewaffnet ist oder nicht – möglichst effizient unschädlich zu machen.
Dies kann durch Schlag-, Tritt-, Stoß-, Wurf-, Hebel- und Würgetechniken
geschehen, indem der Angreifer unter Kontrolle gebracht oder
kampfunfähig gemacht wird. Dabei soll beim Jiu Jitsu nicht Kraft gegen
Kraft aufgewendet werden, sondern – nach dem Prinzip „Siegen durch
Nachgeben“ – so viel wie möglich der Kraft des Angreifers gegen ihn
selbst verwendet werden."
Ein überaus interessantes Konzept! Auch im verbalen Schlagabtausch!
Jörg W. schrieb:> P. M. schrieb:>> Moby hat sachlich keine Argumente und rhetorisch beschränkt er sich auf>> das konsequente ignorieren oder belächeln von Gegenargumenten.>> Nö, er bekommt das Kunststück fertig, sämtliche Gegenargumente für> sich als Gewinn zu verbuchen. ;-)
Vielleicht, weil diese Gegenargumente tatsächlich keine sind ?
P. M. schrieb:> Moby hat sachlich keine Argumente
Für den Ressourcenvorteil von Asm? Genügend. Inklusive Beispiel.
Kann man natürlich "konsequent ignorieren" und "belächeln" ;-)
Moby A. schrieb:> P. M. schrieb:>> Moby hat sachlich keine Argumente>> Für den Ressourcenvorteil von Asm? Genügend. Inklusive Beispiel.> Kann man natürlich "konsequent ignorieren" und "belächeln" ;-)
Deine Diskussionstechnik nennt man "Bullshitting": Eine Aussage selbst
dann immer und immer wieder vorbringen, wenn völlig klar ist, dass sie
falsch ist oder nicht begründet werden kann. In der blinden Hoffnung,
dass man irgendwann als "Sieger" aus der Diskussion hervor geht, weil
man am lautesten/längsten schreit.
P. M. schrieb:> Eine Aussage selbst> dann immer und immer wieder vorbringen, wenn völlig klar ist, dass sie> falsch ist oder nicht begründet werden kann.
Dann liefere doch ein kürzeres C-Beispiel!
Kannst Du nicht, kann niemand. Ist halt Asm ;-)
> Deine Diskussionstechnik nennt man "Bullshitting"
Das Wort hatte ich für manchen Beitrag hier auch schon im Sinn ;-)
Carl D. schrieb:> Schade daß Moby's letzte Entgleisungen gelöscht wurden. Die hätten> dokumentiert, warum Verständnis für seinen Standpunkt nur schwer> Aufkommen kann.
Schade Carl, daß Du zum Instrumentarium psychologischer Kriegführung nun
auch noch Unwahrheiten hinzufügst. Muß das sein?
le x. schrieb:> Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein> ganz anderer:> Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung> eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man> keinen Krüppel-Code schreiben will), dieser befindet sich traditionell> ebenfalls im RAM.
Jetzt schon ;-)
> Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne> Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu> gewinnen...
Ist das ein Problem von Asm?
> *Ich sage bewusst "ohne Klimmzüge". Denn dank den genialen> Compilerbauern ist C heute hinreichend flexibel um Klimmzüge zu> ermöglichen, die einen RAM bei kleinen Projektchen nicht zwingend> vorraussetzen. (Z.B. die Möglichkeit, automatische Variablen in> Registern zu parken)
Ach so? Wo bleibt dann die C-Version?
"Klimmzüge" sind vielleicht nicht nur für diese nötig ;-)
Moby A. schrieb:> Dann liefere doch ein kürzeres C-Beispiel!
Nochmal (ein letztes Mal von mir): solange dein „Anforderungskatalog“
letztlich immer weiter so zurechtgebogen wird, dass er ausschließlich
von einer einzigen existierenden Implementierung erfüllt wird(*), dann
gibt es da nichts zu vergleichen. Es müsste ja dann jemand in der
Lage sein, ein Programm zu schreiben, welches der Compiler exakt 1:1
so umsetzt, wie es jetzt bereits geschehen ist. (Sollte es dabei aus
Versehen wirklich kürzer geworden sein, würdest du ja sofort wieder
argumentieren, dass das, was der hypothetische Compiler weggelassen
hat, ein wesentliches Feature der bestehenden Implementierung gewesen
sei. BTDT.)
(*) Letztlich liegt dies ja schon in der Aussage begründet, dass
einzig die existierende Implementierung die vollständige Beschreibung
der „Anforderungen“ wäre.
Das ist in dieser Form sinnlos, und jedem anderen Vorschlag, ein
Projekt von einer vollständigen (!) (verbalen) Liste der Anforderungen
her “from scratch” in beiden Varianten neu anzugehen, stehst du
grundsätzlich ablehnend gegenüber.
Damit hat sich die Sache doch einfach erledigt: du willst nicht, und
alle anderen wollen auch nicht – nicht zu deinen Bedingungen.
Thomas E. schrieb:> Sein "Projekt" ist nach seiner Aussage eine Vorlage für Anfänger.> Deswegen hat er den nahezu gleichen Overhead eingebaut, wie es ein> C-Compiler tut. Und auch die Interrupts. Dadurch können seine> Asm-Schäflein den Code mühelos erweitern.
Der pure Anfänger wird sich sicher noch nicht mit dem Erweitern
beschäftigen. Es soll aber auch Personen geben, die über dieses Stadium
hinaus sind...
> Und der arme Anfänger packt den leeren RAM bis zum Rand voll, dann kommt> der erste Moby-Interrupt und zerschiesst ihm seine Daten.
... und sich an meinen freundlichen Hinweis erinnern werden, daß der
vorhandene Timer-Interrupt dann seine Register zu sichern hat, wenn
Hauptprogramm und weitere Interrupts genutzt werden.
> Das passiert einem Fortgeschrittenen natürlich nicht. Der braucht aber> auch kein Moby-Asm.
Mir passiert auch vieles nicht, weil ich C nicht verwenden muß ;-)
Moby A. schrieb:> P. M. schrieb:>> Eine Aussage selbst>> dann immer und immer wieder vorbringen, wenn völlig klar ist, dass sie>> falsch ist oder nicht begründet werden kann.>> Dann liefere doch ein kürzeres C-Beispiel!> Kannst Du nicht, kann niemand. Ist halt Asm ;-)
Genau das ist Bullshitting: Obwohl die Diskussion dieses Thema mehr als
genügend abhandelt, und zwar im Konsens aller Teilnehmer (ausser dir),
hast du doch wieder die Frechheit, so zu tun, als hätte noch überhaupt
niemand deinen Punkt widerlegen können. Immer in der blinden Hoffnung,
durch Ermüdung des Gegners doch noch mit dem letzten Wort als Sieger aus
der Diskussion hervorzugehen oder zumindest keinen Gesichtsverlust
eingestehen zu müssen.
Jörg W. schrieb:> (*) Letztlich liegt dies ja schon in der Aussage begründet, dass> einzig die existierende Implementierung die vollständige Beschreibung> der „Anforderungen“ wäre.
Nett. Dadurch kann Moby-ASM auch keine Fehler anthalten und ist die
erste intrinsisch sichere Programmiersprache: Es ist UNMÖGLICH mit
Moby-ASM einen Fehler zu machen.
Programmierer aller Kontinente, verneigt euch vor Moby!
Jörg W. schrieb:> solange dein „Anforderungskatalog“> letztlich immer weiter so zurechtgebogen wird, dass er ausschließlich> von einer einzigen existierenden Implementierung erfüllt wird...
Nun, zur Güte hatte ich doch längst schon zugestanden, es langt, die
beschriebene Programmfunktion = den Output nachzubilden.
Aber weißt Du was? Selbst das ist für C zu hoch, wenn Flash/Ram-Bedarf
meines Programms getoppt werden soll. Ich bin mir aber nicht nur darüber
im Klaren, daß dies für C unmöglich ist sondern denke auch, daß mangels
(farbenprächtig dokumentierter) Eingeständnis-Fähigkeit der C-Fraktion
hier früher oder später doch wieder Streit um Belanglosigkeiten an den
Haaren herbeigezogen wird ;-)
Das ist zwar ein Kampf gegen viele Windmühlen hier- freilich, das geb
ich ja zu, er macht Spaß!
P. M. schrieb:> die Frechheit, so zu tun,
... daß mein Programm nach wie vor die Überlegenheit von Asm
dokumentiert!
Sooo ein Pech aber auch ;-)
>wenn Flash/Ram-Bedarf meines Programms getoppt werden soll.
Das Wichtigste fehlt wieder: Die Entwicklungszeit. Zumindest für alle
ausser Dir.
>Streit um Belanglosigkeiten an den Haaren herbeigezogen wird ;-)
Wie zB die Entwicklungszeit?
Thread beobachten
Seitenaufteilung abschalten