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 ...
Wolfgang S. schrieb: > Niedlich, APL. Ich habe hier irgendwo noch einen Kugelkopf rumliegen ... und der Durchmesser ist wievel Meter?
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.
Thomas E. schrieb: > Moby A. schrieb: > Der reicht auch als Demo der Überlegenheit von Assembler. > > Lach. Machen. Nicht lachen ;-)
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 :-(( )
:
Bearbeitet durch User
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 ;-)
:
Bearbeitet durch User
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.
https://www.youtube.com/watch?v=t2nIF2ZO5jw Ähnlichkeiten mit lebenden Personen und Threads sind nicht zufällig und voll beabsichtigt.
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...
:
Bearbeitet durch User
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.
Carl D. schrieb: > Typische 8-Bit-MSR-Projekte nutzen kein 6-Pin-AVR's Die nutzen da alles was ein paar Beine hat ;-)
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...
1 | #include <stdio.h> |
2 | |
3 | int main(void) |
4 | {
|
5 | puts("Hallo Welt!"); |
6 | }
|
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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.
Thomas E. schrieb:
Den mit großem Abstand besten und informativsten Beitrag in diesem
elendig langen endlos Thread.
Vielen Dank dafür !
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 ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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!
P. M. schrieb im Beitrag #4364606:
> Moby...deine Beiträge bekommen durchs Band 3-5 Downvotes.
Na ja, ausgenommen der Eröffnungspost.
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.]
:
Bearbeitet durch Moderator
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
Moby A. schrieb: > Ich denke aber an solche Leute die auf dem Code unmittelbar aufbauen > wollen. Gibts denn welche..?
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.
Moby erinnert mich immer an den schwarzen Ritter aus "Ritter der Kokosnuß".
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. ;-)
Angehängte Dateien:
-
blog_horizontnull.jpg
49 KB
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.
:
Bearbeitet durch Moderator
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.
Karl H. schrieb: > Wieso? Ist einer der beiden verstorben? Moby ja zum Glück nicht, also war's der andere. :)
@ 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Aber darum geht es doch in diesem Thread überhaupt nicht!
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.
Klaus W. schrieb: > Aber darum geht es doch in diesem Thread überhaupt nicht! Ich gebe zu, ein paar Seiten übersprungen zu haben - war im Ausland.
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.
:
Bearbeitet durch User
... und der Lichttechiker schnautzt den Regiseur an dass das Stück ein Reinfall wird, weil er dieser keine Scheinwerfer bauen will.
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 ;-)
Moby A. schrieb: > Schau Jörg, die lieben Unterstellungen wieder! Du hast den Smiley weggelassen. Der war absichtlich da.
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 ;-)
:
Bearbeitet durch User
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.
Karl H. schrieb: > war im Ausland. >>gewünschten Zwischenmasse In der Schweiz? Ich hätte ein ß verwendet, falls die Tastatur das hergibt...
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.
Hmmm, Sisyphos oder doch Prometheus? https://de.wikipedia.org/wiki/Sisyphos https://de.wikipedia.org/wiki/Prometheus#Prometheus-Sage
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 ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Asm auf 8-Bit Controller fürs MSR ist sicher nicht das Ende der Welt. doch, aber das untere.
Klaus W. schrieb: > doch, aber das untere ... Ende der nötigen Komplexität für 8-Bit MSR. Für die hier einfachste Lösung ;-)
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: > Womit verdienst Du Dein Geld? Das solltest Du jetzt schnell selber löschen, denn Du entführst den Thread ;-) Gute Nacht.
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:
1 | sioin: di |
2 | call buffsize |
3 | ei |
4 | and a |
5 | jr z, sioin ; must wait |
6 | |
7 | di ; avoid the race condx |
8 | ld hl, (get_pointer) |
9 | ld a, (hl) |
10 | call incr_ptr |
11 | ld (get_pointer), hl |
12 | ei |
13 | |
14 | ret |
Sparte halt zwei extra Bytes für die Daten. ;-)
:
Bearbeitet durch Moderator
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..
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Moby A. 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. > 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)! Also. Ich fasse für mich presönlich zusammen: wenn ich genau so ein Projektchen habe, das nur mistt, aber weder steuert und noch viel, viel weniger regelt, dann ist Assembler gerade richtig. 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... A. K. schrieb: > PS: Bei dem PL/65 Compiler hat Moby Recht: In C hätte der niemals in die > 2x 4KB ROMs gepasst. Wir sind heute(!) aber fast 40 Jahre weiter... https://books.google.de/books?id=7mDo3ieRWJEC&pg=PA40&lpg=PA40&dq=PL/65+compiler&source=bl&ots=YEoavGmKT-&sig=R4dC1qQFFTqKKsUjWdsTyj1q6OM&hl=de&sa=X&ved=0ahUKEwiXuc2xhbPJAhUIbRQKHYnZCkMQ6AEIODAC#v=onepage&q=PL%2F65%20compiler&f=false https://books.google.de/books?id=CyW_hu4H-u4C&pg=PA43&lpg=PA43&dq=PL/65+compiler&source=bl&ots=cbmuh_LIRA&sig=rSzojLr5oo9oifoiUz9blKRwZmQ&hl=de&sa=X&ved=0ahUKEwiXuc2xhbPJAhUIbRQKHYnZCkMQ6AEIUDAG#v=onepage&q=PL%2F65%20compiler&f=false
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.
A. K. schrieb: > 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. avr-gcc verwendet das an wenigen Stellen, z.B: http://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/lib1funcs.S?revision=219188&view=markup#l1267
1 | DEFUN __mulsidi3 |
2 | set |
3 | skip |
4 | ;; FALLTHRU |
5 | ENDF __mulsidi3 |
6 | |
7 | DEFUN __umulsidi3 |
8 | clt ; skipped |
9 | ... |
Beim Disassemblieren steht natürlich kein "skip" da, sondern CPSE Rn,Rn. Ginge zwar auch mit RJMP, ist aber nun mal so gelöst.
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...
:
Bearbeitet durch User
> 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...
:
Bearbeitet durch User
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 ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Mit Übung, Vorbereitung und System Moby 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 ;-(
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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 ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Ein schlechtes, da störendes Beispiel ist > > Beitrag "Kleines Tiny13 Sensorboard" Lustig. Als ich deinem Link folgte, kam ich auf folgenden, sehr guten Beitrag: Beitrag "Re: Kleines Tiny13 Sensorboard" Vielleicht solltest du mal gute Beiträge beherzigen anstatt über andere zu zetern. Oder kannst du nix mehr lernen?
:
Bearbeitet durch User
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" ;-)
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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
:
Wiederhergestellt durch Moderator
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch Moderator
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]
bit operationen in C sind wirklich nicht so einfach zu realisieren wie in ASM ;)
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.
Sheeva P. schrieb: > sowie der Syntax des zu verwendenden Assemblers Die C-Syntax musst du aber kennen, sonst wird das nix...
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.)
@Johann L. (gjlayde) Benutzerseite >ICH steuere die Registerbelegung per Smartphone-App! Manchmal muss man alle verfügbaren Register ziehen! https://de.wiktionary.org/wiki/alle_Register_ziehen http://www.evangelisch.de/inhalte/85999/14-07-2013/der-organist-von-notre-dame Die hatten schon anno Tobak deutlich mehr als 100 Register, da gabs noch gar keine CPUs, nicht mal Silizium ;-)
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 ;-)
:
Bearbeitet durch User
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.
Moby A. schrieb: > Mir passiert auch vieles nicht, weil ich C nicht verwenden muß ;-) Nicht können ist etwas anderes als nicht 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