Johann L. schrieb: > Ein nicht unwesentlicher Teil des Codes besteht aus der Initialisierung Darin könnte ein Grund liegen, warum in diesem Fall Asm nicht viel rausholt. Auch das zweite Progrämmchen ist viel zu kurz dafür. Das sind allerdings nur grobe Vermutungen. Genauso wie ich glaube: Das eine oder andere Byte'chen wird man dennoch aus dem Flash und dem SRAM (!) erübrigen können. Nutz doch die Zeit besser, um das bischen Funktionalität meines Projekts zu codieren. Das kann ich sofort vergleichen... Frank M. schrieb: > Moby A. schrieb: >> Da ist noch laaaange kein Ende ;-) > > Nur eine Behauptung. Du meine Güte, sitze gerade an einem Projektchen welches wieder mal die 1K Grenze gesprengt hat- was ist das bloß für ein Unsinn, die sinnvolle Möglichkeit dessen in Frage zu stellen ;-( Wenn hier schon niemand fähig ist, einen 200 Byte Code ein für alle Mal vergleichbar und Diskussions-beendend in C zu schreiben, was werde ich dann erst bei einem fünfmal so großen Projekt erwarten dürfen? Da werden dann schlußendlich wieder nur "Experten" sein, die ihr Expertentum in erster Linie mit Lächerlichmachen, Hohn und Spott beweisen ;-)
Markus M. schrieb: > DU prahlst mit deinen 200Byte Gefrickel was von > Überlegenheit. Hier prahlt niemand, sondern da zeigt jemand die Schwächen von C auf. ;-) > Verstehe diese Wortanhäufung nicht. Ich verstehe die Notwendigkeit häufiger Architekturwechsel auch nicht ;-) > Und ich behaupte jetzt, dass auch alle deine 200Byte Projektchen in C > effektiver zu programmieren sind. Na ja, ich kann warten. Hoffentlich warte ich nicht umsonst ;-)
Was genau willst du eigentlich? Die Frage ist Ernst gemeint (also kein ;-) )! Ich persönlich mag C ja auch nicht (überhaupt nicht). Schreibe normalerweise in Pascal. (hab C64, Amiga500 und 80x86 in ASM Programmiert.. aber nur "Kinderkram",..) Grundsätzlich wäre ich der ERSTE der lieber nicht in C schreiben würde.. Aber man nimmt dann eben das geringste übel.. Mich konntest bisher noch nicht davon überzeugen dass ich irgend eine Vorteil durch ASM am AVR hätte. Vorallem nicht ASM-Only.. Du bist also zumindest mal ein schlechter "Lehrer"/Verkäufer.. Ich Persönlich glaub aber auch, dass es hier garnicht um ASM vs. C oder ASM vs. Hochsprache. geht. Sondern um "Code von anderen Wiederverwenden" vs. alles "Selber schreiben wollen"..
:
Bearbeitet durch User
Moby A. schrieb: > Du meine Güte, sitze gerade an einem Projektchen welches wieder mal die > 1K Grenze gesprengt hat- was ist das bloß für ein Unsinn, die sinnvolle > Möglichkeit dessen in Frage zu stellen ;-( Natürlich glaube ich, dass Du ASM-Code von 1KB Größe zusammentackern kannst. Aber wie kommst Du auf den abstrusen Gedanken, ein adäquates C-Programm wäre hier schlechter? Du hast weder ein entsprechendes C-Programm vorzuweisen noch kannst Du in C programmieren. Ich nenne das anmaßend. Nur Behauptungen, nichts dahinter.
Frank M. schrieb: > Nur Behauptungen, nichts dahinter. Das war schon vor 1248 Posts vorher der Fall. PS: Ist mir klar, dass dieser Post sinnlos ist, ich wollte nur unbedingt den 1250. Post hier schreiben. Zum Glück hat sich dadurch das Niveau nicht nenneswert geändert...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ist mir klar, dass dieser Post sinnlos ist, ich wollte nur unbedingt > den 1250. Post hier schreiben. Sieh lieber zu das du die Kiddis wieder zum schlafen bekommst, die haben schon wieder die Verdunkelungsvorhänge runter gerissen und politisieren laut nebendrann. Namaste
Lothar M. schrieb: > Zum Glück hat sich dadurch das Niveau > nicht nenneswert geändert... Nun ja, den Beitrag würde ich als vergleichsweise hoch einordnen.
Moby A. schrieb: > Hier prahlt niemand, sondern da zeigt jemand die Schwächen von C auf. Und baut genau diese oft kritisierten Schwächen in seinen Asm-Code ein. Diesen nennt er dann auch noch einen Leckerbissen. Da würde nicht einmal der Hund rangehen. Moby A. schrieb: > Na ja, ich kann warten. Hoffentlich warte ich nicht umsonst Du hast doch schon lange ein C-Programm bekommen. Auf ein weiteres wirst du ewig warten. mfg.
Moby A. schrieb: >> DU prahlst mit deinen 200Byte Gefrickel was von >> Überlegenheit. > Hier prahlt niemand, sondern da zeigt jemand die Schwächen von C auf. Die Schwäche von C ist also kein 200Byte ASM Programm toppen zu können das ganz ohne RAM auskommt ? (Lassen wir das mal als Hypothese so stehen) Also ist die Schwäche von C bei einer MCU die extra für Hochsprachen optimiert wurde diese dafür vorgesehenen Ressourcen auch tatsächlich zu benutzen ? Moby A. schrieb: >> Und ich behaupte jetzt, dass auch alle deine 200Byte Projektchen in C >> effektiver zu programmieren sind. > Na ja, ich kann warten. Hoffentlich warte ich nicht umsonst ;-) Ich denke schon. Sobald das C Konstrukt nur ein byte braucht das Dein ASM nicht braucht wirst Du das als Niederlage werten. Selbst wenn das C Programm in 50% der Zeit geschrieben ist und nichts und niemand je diese Ressourcen nutzen wird die Du frei lässt. Dann wirst Du behaupten das diese 'klare Überlegenheit' von ASM natürlich auch für Programme gilt die 1000 mal so groß sind. Selbst wenn das C Konstrukt in allen Belangen kleiner, schneller und sparsamer ist als Dein ASM wirst Du eine Argumentation finden das dieses ein 'untypischer' Sonderfall ist oder sinnloserweise irgendwelche Verrenkungen unternommen werden müssen nur weil Du das in ASM auch so machst, der C Compiler aber keinen Sinn darin sieht. Z.B. wirst Du argumentieren das ein hochoptimierender Keil / IAR o.ä. im Gegensatz zu ASM viel Geld kostet. Entweder das oder Du ignorierst einfach alles was da an Beweisen rüberkommt und machst an irgendeinem Nebenschauplatz weiter als wäre nichts gewesen. Mal nebenbei: Mir ist aus Deinen Threads klar geworden das Du eine Zermürbetaktik fährst. Es kommen so lange die gleichen Plattitüden bis endlich alle aufgegeben haben mit jemanden diskutieren zu wollen dem es vollauf reicht das letze Wort zu haben und dem nichts zu platt ist dafür. Es würde mich diebisch freuen wenn wir diesmal den längeren Atem beweisen und Du irgendwann einfach keine Lust mehr hast. Ehrlich gesagt reche ich uns da keine großen Chancen aus denn Du bist was das angeht wirklich so eine Art Gesamtkunstwerk. Einen Versuch ist es allemal wert. So, nur um den Wertbewerb 'meiste Smileys pro Thread' aufzunehmen: ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) Dir auch noch einen schönen Tag. Michael
Moby A. schrieb: > Du meine Güte, sitze gerade an einem Projektchen welches wieder mal die > 1K Grenze gesprengt hat- was ist das bloß für ein Unsinn, die sinnvolle > Möglichkeit dessen in Frage zu stellen ;-( Wow, welchen mc benutzt Du? Je nachdem sind also schon wertvolle 25% / 12% ... 3% Flash belegt. Höchste Zeit, sich dringend Gedanken um den nächsten Optimierungslevel zu machen. Wo ist überhaupt die Sammelstelle für all das unbenutzte Flash? Ich hätte auch noch ne ganze Menge davon abzugeben.
Glaubt eig. irgend jemand an diese ominösen "Projektchen"? Geschrieben von jemand, dessen einziges "Projektchen" das die Welt kennt aus 20 Zeilen Micky Maus besteht?
Stefan K. schrieb: > Wo ist überhaupt die Sammelstelle für all das unbenutzte Flash? Da werden ein paar Ready-To-Use Ethernetmodule angeflanscht. Dann kann er das als Home-Cloud benutzen, um weniger Resourcen auf der Festplatte in seinem PC zu verschwenden. mfg.
Gu. F. schrieb: > Glaubt eig. irgend jemand an diese ominösen "Projektchen"? Warum nicht? Er hat uns doch weiter oben erklärt, wie das abläuft: sowie irgendwas seine Möglichkeiten übersteigt (wie eben eine IP-Anbindung), wird das dazugekauft. Ansonsten muss man doch nur hinreichend viel Masochismus mitbringen, um größere Mengen Assemblercode zusammenzuhacken. Dass dieser dann noch „optimal“ ist, das glaubt allerdings wirklich nur Moby selbst.
Jörg W. schrieb: > Warum nicht? Er hat uns doch weiter oben erklärt, wie das abläuft: > sowie irgendwas seine Möglichkeiten übersteigt (wie eben eine > IP-Anbindung), wird das dazugekauft. Auch diese hat noch keiner gesehen. Nur Behauptungen.
Gu. F. schrieb: > Auch diese hat noch keiner gesehen. Dich hat hier auch noch keiner gesehen, trotzdem existierst du offensichtlich.
Jörg W. schrieb: > Gu. F. schrieb: >> Auch diese hat noch keiner gesehen. > > Dich hat hier auch noch keiner gesehen, trotzdem existierst du > offensichtlich. Was willst du mir denn damit sagen? Ich reise hier nicht die Klappe auf und gebe seit 1200 Beiträgen mit meinen tollen >10k ASM Projektchen an. Das tut nur Moby. Also ist er in der Pflicht das auch zu belegen sonst ist er unglaubwürdig. Ich muss nix beweisen.
:
Bearbeitet durch User
Gu. F. schrieb: > Was willst du mir denn damit sagen? Dass du nicht jedes seiner Worte anzweifeln musst. „in dubio pro reo“ darfst du auch gelten lassen, wenn du dein Gegenüber nicht sonderlich leiden kannst.
Moby A. schrieb: > Manches ist jedenfalls trivialer als man denkt ;-) Ich weiss sowieso nicht, wie man auf den absurden Gedanken kommen kann, der (sehr repetitive) Prozess der Compilierung/Assemblierung auf unterster Ebene könne von einem Menschen effizienter durchgeführt werden als von einem Computerprogramm. Vermutlich liegt es daran, dass Moby mit seinem beschränkten Horizont diese Aufgabe als kreativ ansieht, während wir wissen, dass es rein mechanistisch ist.
P. M. schrieb: > Ich weiss sowieso nicht, wie man auf den absurden Gedanken kommen kann, > der (sehr repetitive) Prozess der Compilierung/Assemblierung auf > unterster Ebene könne von einem Menschen effizienter durchgeführt werden > als von einem Computerprogramm. Den Output seiner Werkzeuge zu hinterfragen ist prinzipiell ja kein schlechter Gedanke. Ich kann mich erinnern, wie ich das erste Mal das Compiler-Ergebnis für den externen Speicherzugriff eines 8051 gesehen habe. Das war unendlich umständlich und hat sich vor allem für jedes externe Byte wiederholt. Der gcc für AVR ist aber mittlerweile eine ganz andere Liga, dem macht man händisch kaum noch was vor, vor allem bei komplexeren Strukturen. Was nicht zuletzt an dem für C optimierten Hardwaredesign liegt. Gruß, Stefan
P. M. schrieb: > Vermutlich liegt es daran, dass Moby mit seinem beschränkten Horizont > diese Aufgabe als kreativ ansieht, während wir wissen, dass es rein > mechanistisch ist. Vielleicht ist ja mit Deinem Horizont ja was nicht in Ordnung ;-) Frank M. schrieb: > Aber wie kommst Du auf den abstrusen Gedanken, ein adäquates > C-Programm wäre hier schlechter? Du hast weder ein entsprechendes > C-Programm vorzuweisen Wie kommst Du auf den abstrusen Gedanken daß ich ein C-Programm vorweisen müsste? Wenn, dann kommt hier mal von mir ein optimiertes 1K Asm Programm... Doch wofür? Was dann von C-Seite folgt würde wieder nur gähnende Leere sein. Die Reaktionen kann ich hier schon jetzt wunderbar studieren.
Stefan K. schrieb: > Der gcc für AVR ist aber mittlerweile eine ganz andere Liga, dem macht > man händisch kaum noch was vor Köstlich. Das küre ich schon jetzt zum Witz des Tages und empfehle Dir, mal ein paar Problemthreads zum gcc durchzugehen und Dich an dessen Beschränktheiten zu laben. Besser soll ja der IAR sein- für ne Stange Geld natürlich.
Moby A. schrieb: > Vielleicht ist ja mit Deinem Horizont ja was nicht in Ordnung ;-) Erfahrung in 10 Jahren Hobby/Studium/Beruf: Sehr viel C, viel C++, AVR-Assembler, MIPS-Assembler, VHDL, Softwareentwicklung für Supercomputer, Skriptsprachen fürs Web. Und du? Ein paar Hobby-Projekte in Assembler, Ende der Fahnenstange. Moby A. schrieb: > Wie kommst Du auf den abstrusen Gedanken daß ich ein C-Programm > vorweisen müsste? Weil DU derjenige bist, der eine Minderheiten-Meinung vertritt. Wer etwas behauptet, das vom grössten Teil der Diskussionsteilnehmer abgelehnt wird, der hat nunmal die Beweislast, ob er will oder nicht. Wenn du auch nur ein kleines Interesse daran hättest, die Diskussion für dich zu entscheiden, dann hättest du den Beweis schon lange angetreten.
>optimiertes 1K Asm Programm hat du aber keines.. beantworte doch mal die Frage: Beitrag "Re: Assembler wieder auf dem Weg nach vorn" anstelle immer wieder das selbe zu wiederholen..
:
Bearbeitet durch User
P. M. schrieb: > Und du? Ein paar Hobby-Projekte > in Assembler, Ende der Fahnenstange. Die muß nicht da zu Ende sein wo Du meinst. Deine Auflistung von Erfahrungen interessiert hier & mich wenig. Deine Mittel mich zu "überzeugen" waren bislang ziemlich arg auf diverse unredliche Psychospielchen begrenzt. Du hättest besser Psychologe werden sollen, wobei es mir dann um die armen Patienten leid täte ;-)
Moby A. schrieb: > Deine Auflistung von Erfahrungen interessiert hier & mich wenig. Siehst Du. Und Deine Definition von Effizienz (Ram/Flash-Verbrauch) interessiert ausser Dir eben "hier & alle wenig" bis garnicht. Auch wenn Du es weiter ignorierst: Wir verstehen unter Effizienz zu grossen Teilen die Entwicklungszeit. Danach kommt RAM und Flash.
Moby A. schrieb: > Wie kommst Du auf den abstrusen Gedanken daß ich ein C-Programm > vorweisen müsste? Wie kommst du auf den abstrusen Gedanken, dass hier irgendjemand anders ein C-Programm vorweisen müsste? Du stellst eine Behauptung auf, dann wäre es an dir, den Beweis dafür zu liefern. Bis zu irgendeinem Beweis bleibt es einfach nur eine Behauptung.
Jörg W. schrieb: > Bis zu irgendeinem Beweis bleibt es einfach nur eine > Behauptung. Ach ... Schön das von dir zu hören. Könnte er doch im Geheimen alle seine Projektchen wirklich realisiert haben :-)
P. M. schrieb: > Ich weiss sowieso nicht, wie man auf den absurden Gedanken kommen kann, > der (sehr repetitive) Prozess der Compilierung/Assemblierung auf > unterster Ebene könne von einem Menschen effizienter durchgeführt werden > als von einem Computerprogramm. Auf das ging er natürlich wieder garned ein... Aber hier hat P.M. natürlich recht. Das Groß der Entwicklungszeit bei ASM geht ja nicht für Kreatives Arbeiten (welchen Algorithmus muss ich anwenden? Welche Rechenoperation muss ich durchführen?) drauf sondern für stumpfe Fleissarbeit (welche der mit der gegebenen Architektur verfügbaren Instruktionen muss ich auf welche Weise kombinieren, um eine 16-Bit-Signed Multiplikation durchzuführen. Da kann man noch so viel ÜVS (Übung/Vorbereitung/System) haben, das ÜVS des Comlilers wird immer besser sein, in einem Bruchteil der Zeit. Und mit jeder Codezeile die das Projekt wächst wird das ÜVS des Compilers übermächtiger, bis unser menschlicher Assembler irgendwann nur noch staunen kann, was da abgeht. Spätestens mit Features wie LTO wird der Mensch sowas von abgehängt. Technologische Singularität im kleinen Rahmen, sozusagen ;-) Der BreakEven wird aber schon viel eher erreicht. Ich würde, je nach Problemstellung, eine niedrihe 3-stellige Zahl als Codegröße (Flash) schätzen. Ohne massive Handoptimierung und Tricksereien seitens des Menschen denk ich aber dass bei ~100 Byte der Compiler auch in 95% der Fälle gewinnt.
le x. schrieb: > um eine 16-Bit-Signed Multiplikation Das ist doch aber keine typische 8bit MSR Anwendung.
Matthias L. schrieb: > Siehst Du. Und Deine Definition von Effizienz (Ram/Flash-Verbrauch) > interessiert ausser Dir eben "hier & alle wenig" bis garnicht. Genau, deswegen diskutieren wir darüber seit >1200 Beiträgen. Weil uns das überhaupt nicht kümmert ! Streng genommen hat Moby bereits ein 200Byte Programm 'geliefert' Wenn es Dir sooo wichtig ist dann analysiere den Kram, mach eine Softwarespezifikation daraus und schreibe etwas in C das das gleiche tut. Dann vergleichen wir den ASM Code und Moby lacht sich krumm weil bei 200Byte wohl tatsächlich ASM gewinnen wird. Nicht das das ein Kriterium gegen C wäre, aber nach Mobys Maßstäben kann ASM bei dieser Größe fast nur gewinnen. Damit hast Du Dich dann auf genau das Glatteis begeben von dem behauptet wurde das Moby regelmäßig darauf einbricht. Sieh es ein, er ist Dir überlegen wenn es darum geht ein Falle auszulegen und dann geduldig darauf zu warten das jemand reintappt. Um aus dieser Endlosschleife herauszukommen müsste man eine Aufgabe definieren die eine gegebene Hardware knackig ausnutzt. Ringbuffer, gleitender Mittelwert, Berechnungen >8bit, sowas in der Art. Es darf dann nur nicht die Begründung kommen das das ja keine typische Anwendung wäre. Beide Parteien (oder mehr, wenn noch jemand Fortran, Cobol, Pascal, LUA etc. beisteuern will) setzen das dann um und vergleichen wie schnell sie fertig sind und was an Ressourcen verbraucht wird. Wird keiner machen, weil, weil, weil .... Damit bleibt das hier ein rein theoretischer Schlagabtausch von einigem Unterhaltungswert.
le x. schrieb: > Spätestens mit Features wie LTO wird der Mensch sowas von abgehängt. Moby braucht keine LTO, da er keinen Linker verwendet und immer alles zusammen übersetzt. Und da seine Programme klein genug sind hat er den vollen Durchblick und macht ETO.
:
Bearbeitet durch User
Michael K. schrieb: > Wenn es Dir sooo wichtig ist dann analysiere den Kram, mach eine > Softwarespezifikation daraus und schreibe etwas in C das das gleiche > tut. Haben wir doch schon versucht: sowie du etwas findest, was man besser machen könnte, verstößt es doch sofort automatisch gegen seine Bedingungen, denn die Bedingungen sind einfach so gestaltet, dass sie nur von exakt seiner Assembler-Implementierung erfüllt werden. Jegliche Abweichung davon ist nicht etwa dann der „Gewinner“, sondern wird zum Fehler deklariert. Aus genau diesem Grunde gibt es auch niemanden, der dieses Spiel jetzt noch mitspielen würde.
Michael K. schrieb: > Streng genommen hat Moby bereits ein 200Byte Programm 'geliefert' > Wenn es Dir sooo wichtig ist dann analysiere den Kram, mach eine > Softwarespezifikation daraus und schreibe etwas in C das das gleiche > tut. jo, das ist richtig. Aber da erwarte ich die Spec von Moby. Es soll ja sein ASM Programm in C geschrieben werden. Also Moby; schreib doch mal. Aber jetzt bitte keine Verweise auf irgendwelche, nicht zusammenhängende, Thread Beiträge. Hier und jetzt. Kann ja nicht so schwer sein.
ja, man müsste eine neue Aufgabe definieren eine die auch moby "braucht" wenn er jetzt zufällig in nächster Zeit ein größeres Projekt vor hat (so in die richtug 1kByte) könnte das doch Vorstellen (also die geplante hardware und die Ziele des "Projektes" ;-)
Jörg W. schrieb: > Aus genau diesem Grunde gibt es auch niemanden, der dieses Spiel jetzt > noch mitspielen würde. Finde ich aber ganz schön clever für jemanden der ständig für blöd gehalten wird. Ich kann mich nur wiederholen (wie wir alle): Moby hat nicht vor sich schlagen zu lassen und deswegen sind die Rahmenbedingungen so definiert das das auch nicht passiert. Trotzdem könnte 'man mal' seine 200 Byte in C nachstellen so das man tatsächlich über beide ASM Codes vergleichen kann. Klar, das wird garnichts ändern, das wissen wir beide. Es wäre aber unterhaltsam und darum geht es doch hier eigentlich, oder ?
Werner P. schrieb: > jo, das ist richtig. Aber da erwarte ich die Spec von Moby. Es soll ja > sein ASM Programm in C geschrieben werden. Hatten wir auch schon mehrfach. Lehnt er ab mit der Begründung die paar Zeilen solten doch für einen gestandenen Programmierer kein Thema sein.
Michael K. schrieb: > Moby hat nicht vor sich schlagen zu lassen und deswegen sind die > Rahmenbedingungen so definiert das das auch nicht passiert. So ist es.
Moby A. schrieb: > Deine Auflistung von Erfahrungen interessiert hier & mich wenig. Fakt ist einfach, dass ich und die meisten anderen Diskussionsteilnehmer ihre Aussagen auf jahrelange Erfahrung mit verschiedensten Sprachen und Plattformen stützen, während du gerademal hobbymässig etwas Assembler betreibst. Versetz dich mal von aussen in die Situation: Zehn Profis sind sich einig, bloss ein Hobbyist hat eine andere Meinung, wer hat da in den allermeisten Fällen wohl recht? P. M. schrieb: > Moby A. schrieb: >> Manches ist jedenfalls trivialer als man denkt ;-) > > Ich weiss sowieso nicht, wie man auf den absurden Gedanken kommen kann, > der (sehr repetitive) Prozess der Compilierung/Assemblierung auf > unterster Ebene könne von einem Menschen effizienter durchgeführt werden > als von einem Computerprogramm. ...aber nimm doch dazu mal Stellung, anstatt zu persönlichen Angriffen überzugehen.
Moby A. schrieb: >> Der gcc für AVR ist aber mittlerweile eine ganz andere Liga, dem macht >> man händisch kaum noch was vor > > Köstlich. Das küre ich schon jetzt zum Witz des Tages und empfehle Dir, > mal ein paar Problemthreads zum gcc durchzugehen und Dich an dessen > Beschränktheiten zu laben. Besser soll ja der IAR sein- für ne Stange > Geld natürlich. Ja, mach das. Machen ja alle anderen mit jedem Deiner Beiträge auch so. Welche Probleme meinst Du bitte konkret? Kannst Du auch nur eines davon nachvollziehen? Hast Du dafür das nötige C-Wissen? Gerade beim Programmieren ist es eine gute Idee, die Beschränktheit zuallererst bei sich selbst zu suchen. Stefan
:
Bearbeitet durch User
Michael K. schrieb: > Genau, deswegen diskutieren wir darüber seit >1200 Beiträgen. > Weil uns das überhaupt nicht kümmert ! Du hattest doch schon ganz richtig geschrieben, worum es geht: Michael K. schrieb: > Es kommen so lange die gleichen Plattitüden bis endlich alle aufgegeben > haben mit jemanden diskutieren zu wollen dem es vollauf reicht das letze > Wort zu haben und dem nichts zu platt ist dafür. > Es würde mich diebisch freuen wenn wir diesmal den längeren Atem > beweisen und Du irgendwann einfach keine Lust mehr hast. > Ehrlich gesagt reche ich uns da keine großen Chancen aus denn Du bist > was das angeht wirklich so eine Art Gesamtkunstwerk. > Einen Versuch ist es allemal wert. Und natürlich auch darum: Michael K. schrieb: > So, nur um den Wertbewerb 'meiste Smileys pro Thread' aufzunehmen: > ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) Ich nehme jetzt mal den Wettbewerb "meiste 'nicht lesenswert' pro Beitrag" auf und bitte für diesen Beitrag um freundliche Unterstützung. mfg.
Michael K. schrieb: > Trotzdem könnte 'man mal' seine 200 Byte in C nachstellen so das man > tatsächlich über beide ASM Codes vergleichen kann. nönö, zu einfach darf das Programm auch nicht sein, damit Assembler vorteilhaft sein könnte, wie uns Moby unlängst gelehrt hat (es geht um 2 knokrete Mini-Projekte in C, die bereits lange vor dieser Diskussion fertig waren): Moby A. schrieb: > Johann L. schrieb: >> Ein nicht unwesentlicher Teil des Codes besteht aus der Initialisierung > > Darin könnte ein Grund liegen, warum in diesem Fall Asm nicht viel > rausholt. > Auch das zweite Progrämmchen ist viel zu kurz dafür. Das sind allerdings > nur grobe Vermutungen. Genauso wie ich glaube: Das eine oder andere > Byte'chen wird man dennoch aus dem Flash und dem SRAM (!) erübrigen > können. Warum um alles in der Welt sollt es einen VORTEIL bringen, da ein "Bytechen" einzusparen? Bereits vor der Implementierung hätte ich dir sagen könne, dass mit Assembler einige "Bytechen" hätten gespart werden können. Aber was ist der MEHRWERT davon? Ne handvoll Byte einsparen und dafür irgende blöde Registernummer falsch zu schreiben, weil die Division inline auszuführen 12 Byte Flash spart? Und dann die Röhrenheizung durchzuschmoren und der Röhre auf den Grabstein meisseln "Aber der mobysierte Code war 12 Bytes kürzer!"?
Johann L. schrieb: > nönö, zu einfach darf das Programm auch nicht sein, damit Assembler > vorteilhaft sein könnte, wie uns Moby unlängst gelehrt hat Nein, nicht unlängst. Das Thema hatten wir schon mal. Da ging es ausgehend von einer Instruktion um die Entwicklung des Einsparpotentials mit zunehmender Codesize... Johann L. schrieb: > Warum um alles in der Welt sollt es einen VORTEIL bringen, da ein > "Bytechen" einzusparen? Bereits vor der Implementierung hätte ich dir > sagen könne, dass mit Assembler einige "Bytechen" hätten gespart werden > können. Aber was ist der MEHRWERT davon? Bei den beiden Mickymaus Programmen von Dir? Wenig Einsparung bedeutet resourcenmäßig wenig Vorteile. Da könnte ich nur noch die allgemeine Bürokratie von C-.Programmierung ins Feld führen. Schau Dir aber Art und Größenklasse meines 200er Codes an. Da sieht die Welt schon anders aus. Und meine Prognose bis mal bis mindestens 10K wäre, daß diese für C nicht besser wird ;-) Johann L. schrieb: > dafür irgende blöde Registernummer falsch > zu schreiben, Was bitte? Eine Registernummer bei einem gegebenen, durchdachten Registersystem falsch schreiben? Lächerlich. Da sind Fehler in C-Ausdrücken ja tausendmal wahrscheinlicher ;-)
Moby A. schrieb: > Wenig Einsparung bedeutet resourcenmäßig wenig Vorteile. Und was bringt Dir die Einsparung des restlichen 80% Flashs Deines Tiny13? Meinst Du, der verbraucht dadurch jetzt nur noch 20% des Stroms? Du hast den Tiny für 100% eingekauft und Du zahlst auch 100% davon - egal, wie groß oder wie klein Dein Programm ist. Du tust auch nix für die Umwelt, wenn Du ein Byte einsparst... also warum geilst Du Dich daran so auf? > Da könnte ich nur noch die allgemeine Bürokratie von C-.Programmierung > ins Feld führen. Schau Dir aber Art und Größenklasse meines 200er Codes > an. Dein 200er Code hat keine Klasse, sondern ist und bleibt ein Micky-Maus-Programm, welches andere in einer ruhigen Minute mal so nebenbei zusammenhacken - wenn sie es denn brauchen. Aber sie brauchen es nicht. Du bist der einzige. > Da sieht die Welt schon anders aus. Und meine Prognose bis mal bis > mindestens 10K wäre, daß diese für C nicht besser wird ;-) Deine Prognose ist und bleibt falsch.
:
Bearbeitet durch Moderator
P. M. schrieb: > ...aber nimm doch dazu mal Stellung, anstatt zu persönlichen Angriffen > überzugehen. Da beschwert sich genau der Richtige. Stefan K. schrieb: > Allerdings darfst Du > auch sicher sein, daß mein geschriebener Asm-Codeumfang der letzten 3 > Jahrzehnte um ein Vielfaches größer ist als Deiner. w.z.b.w. > Und genau dieses System bringt bei großen Programmen gravierende > Nachteile bzgl. Codesize und Effizienz. Reden wir mal nicht von "großen" Programmen. Nämlich solchen, die Codegrößen von 1-100K nur vom Hörensagen kennen. Die sind mal auf jeden Fall Domäne von Asm. Ich meine für den, der entsprechend Übung, Vorbereitung, System mitbringt. Die allermeiste Sensor/Aktor-Knoten Software benötigt (in Asm) gar noch weniger! > ... weil Du sie für jeden UART mit neuen Registeradressen kopierst. In C > schreibst Du die Funktion einmal und übergibst bei Bedarf den Ptr auf > die UART-Register. Wenn Du 5 UARTs im System brauchst, dann ist in C die > Funktion nur 1* im Flash, und nicht 5 fast identische Asm-Kopien. Papperlapapp. Vielleicht soll ja die UART-Funktion mehr und spezifischeres tun als nur einen Standardbuffer einlesen. Da ist C Null im Vorteil, bringt statt dessen aber seine Ressourcen-Nachteile mit. > ATmega ist in der End-of-live-Phase, der Preis geht eher wieder hoch, es > sind mittlerweile viel performantere 32-Bitter für deutlich weniger Geld > zu bekommen. Mit dem Thema hast Du jetzt den Richtigen erwischt. Ich predige seit Jahren das ewige Leben der einfachen 8-Bitter. Die sollten nach den Prognosen gewisser Künstler hier längst verschwunden sein. Deine 32-Bit Performance kannst Du Dir sonstwohin schmieren, wenn der 8-Bitter die konkrete App locker mit seiner 8-Bit Power viel einfacher löst. Sollte der AVR nicht mehr erhältlich und die Vorräte aufgebraucht sein gehts halt mit einem anderen einfachen 8-Bitter weiter. Angeln kommt für mich nicht in Frage, vor allem nicht im kompliziert-dickflüssigen 32-Bit Teich ;-)
:
Bearbeitet durch User
So, jetzt ist es raus: Moby ist in Wirklichkeit Frauke Petry: http://www.spiegel.de/netzwelt/web/soziale-medien-demokratie-knalleffekt-ersetzt-erkenntnis-kolumne-a-1066848.html
Moby A. schrieb: > 1-100K mal sind es 1K mal 10K und jetzt 100K Moby A. schrieb: > Übung, Vorbereitung, System ich kanns nicht mehr hören! ich habe hier z.B. ein Programm (eines von vielen) für einen Atmega328. UART, RFM22B, ADC und ein paar Taster sowie Leds, Relais und OLED Display. Locker unter 32K. Komplett in C. Das möchte ich mal in ASM sehen.
Moby A. schrieb: > Reden wir mal nicht von "großen" Programmen. Nämlich solchen, die > Codegrößen von 1-100K nur vom Hörensagen kennen. Die sind mal auf jeden > Fall Domäne von Asm. Prust .... Mist alles voller Bier.
Robert L. schrieb: > Was genau willst du eigentlich? Daß mich jemand von den C-Vorteilen überzeugt ;-) > Du bist also zumindest mal ein schlechter "Lehrer"/Verkäufer.. Um Himmels Willen. Den Anspruch hab ich sicher nicht. Schau Dir den Tiobe-Index und die Position von Hochsprachen wie C darin an. Allerdings, hier gehen sämtliche Rechnerklassen ein. Für 8-Bit MSR behaupte ich aber aus eigener Erfahrung, daß direktes Asm hier sinnvoller ist als irgendwelche abstrakten Träumereien wie etwa C++. C selber steht auf diesem unheilvollen Weg weg vom Hardware-Verständnis und damit der Chance auf hochoptimierten Code irgendwo in der Mitte... > Sondern um "Code von anderen Wiederverwenden" vs. alles "Selber > schreiben wollen".. Klar. Das Library-Konzept von C insbesondere mit der Riesen-Code Auswahl könnte neidisch machen, vor allem wenn eine Lib komplexe Funktionalität mitbringt die man just gerade selber braucht. Der Vorteil wird allerdings erkauft mit oft langwieriger Suche nach dem Richtigen, der Inkaufnahme evt. enthaltener Fehler und sowieso der ganzen C-Bürokratie. Bei Asm könnte ich aber genauso (zumindest beim AVR) Massen fertigen Asm-Codes nutzen. Wenn der ASM'ler das Meiste dennoch selber schreibt dann wegen der Code-Effizienz und der bestmöglichen Anpassbarkeit an die Situation. SimplyAVR machts möglich. Oft gilt auch: Ehe ich den Fremdcode verstehe mach ichs lieber gleich selber.
Werner P. schrieb: > Moby A. schrieb: >> 1-100K > mal sind es 1K mal 10K und jetzt 100K Wenn mir nicht bald jemand beweist warum effizientes Asm in den genannten Größenordnungen schlechter als C abschneiden muß sinds bald 1M ;-) > ich kanns nicht mehr hören! Das ist aber der Schlüssel für die Asm-Effizienz in diesen Programmgrößen. > ich habe hier z.B. ein Programm (eines von vielen) für einen Atmega328. > UART, RFM22B, ADC und ein paar Taster sowie Leds, Relais und OLED > Display. > > Locker unter 32K. Komplett in C. Das möchte ich mal in ASM sehen. Locker unter 32K? Da muß ich schon schmunzeln, obwohl ich jetzt nur die genannten Stichworte kenne...
Matthias L. schrieb: > Selten soviel Blödsinn am Stück gelesen Ist auch selten, daß solche Sätze viel Überzeugungskraft mitbringen ;-) Frank M. schrieb: > Und was bringt Dir die Einsparung des restlichen 80% Flashs Deines > Tiny13? Meinst Du, der verbraucht dadurch jetzt nur noch 20% des Stroms? > Du hast den Tiny für 100% eingekauft und Du zahlst auch 100% davon - > egal, wie groß oder wie klein Dein Programm ist. Du tust auch nix für > die Umwelt, wenn Du ein Byte einsparst... also warum geilst Du Dich > daran so auf? Unterschlägst Du gerade wieder mein Erweiterbarkeits-Argument oder kommt mir das nur so vor? Achso, Du meinst ja der Code/ das Projekt wär mit nichts und garnichts erweiterbar und für niemand brauchbar ;-) Jörg W. schrieb: > Wie kommst du auf den abstrusen Gedanken, dass hier irgendjemand > anders ein C-Programm vorweisen müsste? Wer behauptet, daß C soviel effizienter wäre kann das anhand meiner fertigen Projekt Vorlage nachweisen- so einfach ist das.
:
Bearbeitet durch User
Moby A. schrieb: > Wenn mir nicht bald jemand beweist warum effizientes Asm in den > genannten Größenordnungen schlechter als C abschneiden muß sinds bald > 1M ;-) Du stellst doch Behauptungen auf, also musst du das schon beweisen, was du da erzählst. >> Locker unter 32K. Komplett in C. Das möchte ich mal in ASM sehen. > > Locker unter 32K? Da muß ich schon schmunzeln, obwohl ich jetzt nur die > genannten Stichworte kenne... Weil nicht sein kann, was nicht sein darf?
Moby A. schrieb: > Jörg W. schrieb: >> Wie kommst du auf den abstrusen Gedanken, dass hier irgendjemand >> anders ein C-Programm vorweisen müsste? > > Wer behauptet, daß C soviel effizienter wäre kann das anhand meiner > fertigen Projekt Vorlage nachweisen- so einfach ist das. Moment mal: du behauptest hier die ganze Zeit alles Mögliche und glaubst nun, irgendjemand wäre dir einen Gegenbeweis schuldig.
Moby A. schrieb: > Unterschlägst Du gerade wieder mein Erweiterbarkeits-Argument oder kommt > mir das nur so vor? Achso, Du meinst ja der Code/ das Projekt wär mit > nichts und garnichts erweiterbar und für niemand brauchbar ;-) Ich unterschlage gar nichts. Du hast noch keine Erweiterung gezeigt. Also gibt es auch keine.
Angehängte Dateien:
-
images.jpg
6,3 KB
Moby A. schrieb: > Wer behauptet, daß C soviel effizienter wäre kann das anhand meiner > fertigen Projekt Vorlage nachweisen- so einfach ist das. Jörg W. schrieb: > Du stellst doch Behauptungen auf, also musst du das schon beweisen, > was du da erzählst.
Angehängte Dateien:
-
assembly_1_.jpg
170 KB
Stefan K. schrieb: > Hast Du dafür das nötige C-Wissen? Nö. Zuweilen kann man sich aber durchaus auf die Kompetenz anderer Forums-Teilnehmer verlassen. Wenn sich deren Erfahrung manchmal noch mit der eigenen deckt umso mehr. Jörg W. schrieb: > Er will sie uns aber nicht zeigen. Er wird schon wissen, warum. Hatte gerade das Vergnügen kurz was im Code meines drittgrößten Asm-Projekts zu ändern und häng mal ein Bild vom Assembliervorgang an, um redlichen Zweiflern an 10K Asm-Codesize zumindest etwas Wind aus den Segeln zu nehmen. Ich gebe aber zu bedenken, die Grafik könnte vom betrügerischen Moby manipuliert sein ;-) Frank M. schrieb: > Ich unterschlage gar nichts. Du hast noch keine Erweiterung gezeigt. > Also gibt es auch keine. Nun mal Klartext Frank: Du hast auch behauptet, das Projekt wäre nicht und für niemand erweiterungsfähig. Was natürlich blanker Unsinn ist. Ein paar Anregungen hatte ich schon gegeben. Die Logik "es gibt keine Erweiterung, also ist es nicht erweiterbar" ist schon selten dämlich und eigentlich keiner Erwiederung wert.
Moby A. schrieb: > und häng mal ein Bild vom Assembliervorgang an, um redlichen Zweiflern > an 10K Asm-Codesize zumindest etwas Wind aus den Segeln zu nehmen. Bildformate nicht gelesen? Dass du 10 K Code zusammenbekommst, hatte ich nicht angezweifelt. Was wir allerdings anzweifeln ist, dass dieser noch die gleiche Codedichte aufweist wie dein Mini-Beispiel.
Moby A. schrieb: > Nun mal Klartext Frank: Du hast auch behauptet, das Projekt wäre nicht > und für niemand erweiterungsfähig. Was natürlich blanker Unsinn ist. Karl Heinz hat es Dir im anderen Thread bewiesen, dass Du keinen weiteren Sensor anhängen kannst, ohne den Code komplett neu zu schreiben. Das reicht mir vollkommen: Der Code ist nicht erweiterbar. Jörg W. schrieb: > Was wir allerdings anzweifeln ist, dass dieser noch die gleiche > Codedichte aufweist wie dein Mini-Beispiel. Eben. Wie oft muss man das noch wiederholen? Moby stellt sich hier offenbar bewusst dämlich.
Moby A. schrieb: > Johann L. schrieb: >> Warum um alles in der Welt sollt es einen VORTEIL bringen, da ein >> "Bytechen" einzusparen? Bereits vor der Implementierung hätte ich dir >> sagen könne, dass mit Assembler einige "Bytechen" hätten gespart werden >> können. Aber was ist der MEHRWERT davon? > > Bei den beiden Mickymaus Programmen von Dir? Jetzt muss ich doch wieder grinsen: Nachdem du dich bei deinem 200-Byte-Progrämmchen vehement gegen die Aussage gewehrt hast, es sei ein Mickymausprogramm, bezeichnest du jetzt deinerseits die Programme von Johann so. Im ersten von Johanns Programmen steckt aber mindestens doppelt so viel Funktionalität wie in deinem Programm. Wenn Johanns Programm eine Mickymaus ist, dann ist dein Programm ein Mickymäuschen. Es wird dir auch nie und nimmer gelingen, Johanns Programm mit nur 200 Byte in Assembler umzuschreiben. Offensichtlich hast du dich von dem kompakten, übersichtlichen Quellcode des C-Programms täuschen lassen, der natürlich deutlich kürzer und einfacher als dein langatmiger, unstrukturierter Assemblerrattenschwanz ist. Was du hier endlich einmal selber erfahren durftest: In höheren Programmiersprachen lassen sich im Gegensatz zu Assembler auch komplexere Berechnungen und Abläufe einfach und übersichtlich darstellen.
Frank M. schrieb: > dass Du keinen weiteren Sensor anhängen kannst, ohne den Code komplett > neu zu schreiben Auch mit anderen Erweiterungen sieht es dürftig aus: es ist gerade mal noch ein freier Pin da, über den man vielleicht einen Aktor bedienen könnte. Und für diese ominösen Erweiterungen muss dann extra der komplette RAM (abzüglich Stack) frei gehalten werden? Eigentlich wäre ein AT90S1200 für Moby das geeignetste Bauteil gewesen. Wo kein RAM ist, kann man auch keinen verschwenden. :-)
Frank M. schrieb: > Karl Heinz hat es Dir im anderen Thread bewiesen, dass Du keinen > weiteren Sensor anhängen kannst, ohne den Code komplett neu zu > schreiben. Das reicht mir vollkommen: Der Code ist nicht erweiterbar. Es hätte keines Beweises bedurft daß die Hardware nur für die entsprechende Sensorbestückung ausgelegt ist. Entsprechend ist der Code ausgelegt und entsprechend wurde er optimiert. Hör doch auf mit dem Quatsch. Erweiterbarkeit umfasst doch nicht nur die Anzahl der Sensoren ;-( Jörg W. schrieb: > Und für diese ominösen Erweiterungen muss dann extra der > komplette RAM (abzüglich Stack) frei gehalten werden? Unsinn. Diese Effizienz soll C mal nachmachen. Ansonsten bietet der RAM noch genügend Einsatzmöglichkeiten die von zusätzlicher Funktionalität genutzt werden können. Du stellst Dich ja jetzt fast genauso dumm wie Frank M. ;-( Jörg W. schrieb: > Was wir allerdings anzweifeln ist, dass dieser noch die gleiche > Codedichte aufweist wie dein Mini-Beispiel. Daran ist jetzt leider nichts zu ändern. Ich denke, die Codedichte läßt bei größeren Programmen auf jeden Fall etwas nach. Ich hatte ja schon vom Zusammenstöpseln verschiedener fertiger Funktionsbausteine gesprochen. Das geht, auch im Interesse zu wahrender Übersicht, nur mit gewissen Verlusten. Die Bausteine selber sind in ihrer Vielzahl aber sehr kompakt- in Summe dürfte das trotzdem die C-Effizienz in den Schatten stellen, da bin ich sicher. Egal was ich hier aber veröffentlichen würde- wenn auf C-Seite keiner in der Lage und willens ist, selbst einen 200-Byte Code nachzuprogrammieren fehlt ein C-Äquivalent zum Vergleich. Das letzte (natürlich wohlbehütete!) Schlupfloch für die C-Protagonisten, weil es dann tatsächlich bei Aussage gegen Aussage bleibt ;-) Das ist mir aber wurscht und wird mich nicht davon abbringen, meine Überzeugung solange zu vertreten, solange ein Gegenbeweis von C-Seite (wohlweislich) ausbleibt- es könnte ja zum Desaster ausarten (siehe Sheeva Plug). Ok, morgen kanns weiter gehen wenn immer noch Klärungsbedarf besteht ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Die Bausteine selber > sind in ihrer Vielzahl aber sehr kompakt- in Summe dürfte das trotzdem > die C-Effizienz in den Schatten stellen, da bin ich sicher. Eben nicht. Du kannst per Hand/Kopf maximal über diesen Baustein optimieren. Der Compiler kann immer über das gesamte Programm optimieren. Da kommt keiner per Hand/Kopf mehr mit. >Egal was ich > hier aber veröffentlichen würde- wenn auf C-Seite keiner in der Lage und > willens ist, selbst einen 200-Byte Code nachzuprogrammieren fehlt ein > C-Äquivalent zum Vergleich. Du hast ein paar Zeilen ASM veröffentlich. Aber keine Beschreibung was getan werden soll. Wir werden das ASM nicht ausnanderfriemeln um zu sehen, welches Bit wohin geschubst wird. Das sollte vorher feststehen. Aber diese Beschreibung deines Programmes, was es aus Sicht des Anwenders tut, lieferst Du nicht. => Einzige Erklärung, Du hast Angst, das es dann besser geht. Bisher ist ja nur die von Dir gepostete ASM-COde-Reihenfolge "optimal". Alternative neue Aufgaben, wo sich einige beteiligen würden, scheitert ja bei Dir an der Annahme/Mitdiskussion zu einer in Text beschriebenen Aufgabenstellung.. Auch davon gab es viele. Die nimmst Du nicht an, weil: - es angeblich kein "typsches 8bit MSR" ist - Du Angst hast, das C besser wird - Du nicht soviel Zeit hast/willst, während in C einfach for/while/.. hingeschrieben wird
Moby A. schrieb: > Hatte gerade das Vergnügen kurz was im Code meines drittgrößten > Asm-Projekts zu ändern und häng mal ein Bild vom Assembliervorgang an, Hmm, du hast für das Projekt einen ATxmega128A4U genommen, weil der nächstkleinere ATxmega64A4U zu wenig RAM hat. Von der Flash-Größe hätte sogar ein ATxmega16A4U locker gereicht (sogar mit etlichen freien KB für Erweiterungen ;-)). Vom dem riesigen Flash-Speicher des ATxmega128A4U sind laut Screenshot gerade einmal 7,8% belegt. Da will es mir irgendwie nicht so richtig einleuchten, warum du auf Teufel-komm-raus versuchst, Flash-Bytes einzusparen. Moby A. schrieb: > Ich denke, die Codedichte läßt bei größeren Programmen auf jeden Fall > etwas nach. Siehst du, und bei C bleibt die Codedichte auch bei größeren Programmen konstant. Moby A. schrieb: > in Summe dürfte das trotzdem die C-Effizienz in den Schatten stellen, > da bin ich sicher. Ich nicht. Da du aber einen öffentlichen Vergleich strikt ablehnst, muss das wohl jeder für sich selbst heraus finden. Ich für meinen Teil habe es schon getan, mit dem Ergebnis, dass bei Programmen dieser Größenordnung C ganz klar im Vorteil ist.
Werner P. schrieb: > Locker unter 32K. Komplett in C. Das möchte ich mal in ASM sehen. Kein Problem. Musst nur gcc -Os -S laufen lassen. ;-)
:
Bearbeitet durch User
> Ich denke, die Codedichte läßt bei größeren Programmen auf jeden Fall > etwas nach. Ich hatte ja schon vom Zusammenstöpseln verschiedener > fertiger Funktionsbausteine gesprochen. Das geht, auch im Interesse zu > wahrender Übersicht, nur mit gewissen Verlusten. Genau so ein stupides Zusammenstöpsel kann man auch bei so Compilern wie BASCOM, LunaXYZ, ... beobachten. Wenn da eine Variable nicht zweimal hintereinander in ein Register geladen wird, dann nennt sich das "Optimizer". (BTW, deshalb haben die auch kein "volatile") Man mag sich das nicht vorstellen können, aber man darf es doch mal ausprobieren, aber ein moderner Compiler ist von einer solchen "Macro-Textverarbeitung" meilenweit weg. Nur man muß eben anschauen. Bei M.'s Assembler-Code hatten wir ja schon das Vergnügen und das war weder lesbar noch hochoptimiert. Und vom geprießenen "Baukastensystem" war auch nichts zu sehen. Ist aber eh egal, denn die Anforderung des Miniprogramms war ja, den exakten Bytestream der ASM-Lösung per gcc zu erzeugen. Entsprechende PROGMEM Konstanten sowie ein adaptiertes Linkerscript sollten das möglich machen.
Moby A. schrieb: > Es hätte keines Beweises bedurft daß die Hardware nur für die > entsprechende Sensorbestückung ausgelegt ist. Entsprechend ist der Code > ausgelegt und entsprechend wurde er optimiert. Ah ja, aber dafür muss der komplette RAM dann freigehalten werden (und sogar noch ausgenullt, was nichtmal ein C-Compiler fabrizieren würde – der initialisiert nämlich nur das, was gebraucht wird)? > Quatsch. > Unsinn. > Du stellst Dich ja jetzt fast genauso dumm Aha. Lassen wir's.
A. K. schrieb: > Kein Problem. Musst nur gcc -Os -S laufen lassen. ;-) ich war zu faul nachzusehen. Der Atmega328 hat 32K Flash. Von daher meine Aussage "locker unter 32K" Es sind ca. 12K Grüße
Moby A. schrieb: > Für 8-Bit MSR > behaupte ich aber aus eigener Erfahrung, daß direktes Asm hier > sinnvoller ist als irgendwelche abstrakten Träumereien wie etwa C++. Jaja, das behauptest du gerne, das wissen wir. Aber aufgrund welcher Erfahrung? Ein paar Hobby-Projekte in Assembler, aber noch nie C/C++ programmiert? Und du konntest bisher auch noch nie zeigen, wie Assembler effizienter oder einfacher sein soll, du behauptest es einfach. Ich habe dich vor einigen Beiträgen gefragt, wie du auf die Idee kommst, der Mensch könne die mechanistische Arbeit des Assemblierens/Compilierens besser ausführen, als ein Computerprogramm. Leider kriegt man von dir auf solche fachlichen Fragen prinzipiell keine Antworten.
Werner P. schrieb: > Es sind ca. 12K ;-) Ich habe gerade mal bei mir das größte zufällig noch herumliegende ELF-File in meinen AVR-Projekten gesucht. Ist ein BASIC-Interpreter für einen ATmega128 (plus externen RAM, schließlich soll der Nutzer ja auch ein bisschen BASIC eingeben können), den ich vor 8 Jahren mal als Fingerübung gezimmert habe. In erster Linie war die Motivation, die Portierungen von byacc und flex auf den AVR auf diese Weise zu testen, d. h. die komplette lexikalische Analyse ist als lex-Code geschrieben, der Parser als yacc-Code. Gleitkomma-Arithmetik ist auch mit dabei. Das ELF-File bringt es auf weniger als 30 K Flash und 730 Byte statischen RAM-Verbrauch. Beruflich habe ich durchaus auch deutlich größeres gebaut, aber ich denke, dass ist schon ein nettes Beispiel von Hobby-Programmierung.
:
Bearbeitet durch Moderator
Naja, haarscharf die Kante des Mega32 kratzend kann ich schon bieten. Mehr als 32K gab es damals nur in Form des Mega128er und wenn ich zu viel Debugging einschaltete passte es nicht mehr. Eigentlich eine typische Moby-Aufgabe, weil Heizungssteuerung. In C++ programmiert, mit einem kleine RTOS mit drin, einem RS485 Master, etlichen Sensoren verschiedenen Typs, Tastatur, LCD-Anzeige, RTC, DCF77, I2C-EEPROM, ... Und eher auf Struktur und Flexibilität als auf Platz geschrieben. Was Moby freuen wird: Das RTOS ist komplett in Assembler (nicht von mir) und der RS485-Slave ein Tiny2313 auch in Asm (von mir).
:
Bearbeitet durch User
A. K. schrieb: > Mehr als 32K gab es .... > ... in C++ programmiert Hättest Du statt dem bürokratischem C++ das einfach mit Übung/System/Vorbereitung (TM) komplett in ASM gemacht, hätte ein Tiny gereicht. Allerdings wärst Du wohl eher in Rente, als das es fertig wäre.
Matthias L. schrieb: > Allerdings wärst Du wohl eher in Rente, als das es fertig wäre. Nö, das wär schon gegangen. Nicht so schnell und weniger leicht adaptierbar, aber ich habe auch ganz gut Übung in Assembler, wenngleich damals nicht AVR. Klar, länger gedauert hätte es schon und es wäre nicht in gleicher Weise aufgebaut gewesen. Aber so war es mein erstes AVR Projekt und neben dem eigentlichen Zweck auch Experimentierfeld, um zu sehen, was damit geht, und wie. Ist seither aber durchaus produktiv. Mit IoT-Erweiterung. Ist halt schön, wenn das Interface eines Temperatursensors davon unabhängig ist, ob es sich um einen DS18x20 oder einen LM335 handelt. In C++ trivial. Und wenn man in 0.1° Schritten rechnen oder 32-Bit Date/Time-Werte vergleichen kann ohne sich einen abzubrechen. ;-) Wo ich schon ein RTOS drin hatte, hatte ich da auch mit Software-Strukturen experimentiert. So gibt es eine Task, die nur dazu da ist, die Konsistenz des Zustands zu überprüfen, also ob die Werte und Zustände zueinander passen, Sensorwerte nicht zu alt sind etc.
:
Bearbeitet durch User
A. K. schrieb: > RS485-Slave ein Tiny2313 auch in Asm (von mir Super. Und wieviel RAM und Flash hast du gespart? mfg.
Thomas E. schrieb: > Super. Und wieviel RAM und Flash hast du gespart? Keine Ahnung, weil es beim Slave nie eine C Version gab. Das war, wie schon geschrieben, mein erstes AVR Projekt und ich wollte beides ausprobieren. High-Level im Master und Asm im Slave. Dieser Teil des Projekts wäre in C vermutlich nicht so sehr viel schneller fertig gewesen, wenn man davon absieht, dass es dann gemeinsamen Code mit dem Master gegeben hätte. Alles recht einfach aufgebaut und geradeaus. Das Programm vom Slave: ATtiny2313 memory use summary [bytes]: Segment Begin End Code Data Used Size Use% --------------------------------------------------------------- [.cseg] 0x000000 0x00053c 1258 82 1340 2048 65.4% [.dseg] 0x000060 0x0000c0 0 96 96 128 75.0% [.eseg] 0x000000 0x000000 0 0 0 128 0.0% Wenns interessiert siehe Anhang. Drin ist der RS485-Slave, ein DS18x20, ein serielles Interface zu einer damals schon alten Conrad Funkuhr, ein LCD-Display, paar Schalter. Das RAM dient nur als UART-Puffer und Stackspace.
:
Bearbeitet durch User
A. K. schrieb: > Keine Ahnung, weil es beim Slave nie eine C Version gab. Was? Das erkennt man doch auch so. Das ist Effizienz, wie sie nur mit Assembler möglich ist. Ich denke, mit dem dicken C-Compiler mit seiner ganzen Resourcenverschwendung wäre die Küche kalt, weil du immer noch auf den 8313 warten würdest. mfg.
Moby A. schrieb: > Werner P. schrieb: >> Moby A. schrieb: >>> 1-100K >> mal sind es 1K mal 10K und jetzt 100K > > Wenn mir nicht bald jemand beweist warum effizientes Asm in den > genannten Größenordnungen schlechter als C abschneiden muß sinds bald > 1M ;-) Das würden wir sogar gerne. Alleine es scheitert an dir, weil du dich standhaft weigerst, einmal ein etwas größeres Programm in Assembler zu formulieren, während wir dir hier die C Version auf die Schnelle zusammenkloppen. Angebote gabs genug. Einzig und alleine du weigerst dich, den Beweis anzutreten, dass du auch das noch kürzer und vor allen Dingen mit weniger Fehlern hinkriegst.
Thomas E. schrieb: > Was? Das erkennt man doch auch so. Das ist Effizienz, wie sie nur mit > Assembler möglich ist. Wäre in C mit Sicherheit grösser gewesen, allzumal im RAM. Aber ob im RAM nun 96 Bytes UART-Puffer liegen weil halt genug da ist, oder 64 Bytes, das wäre egal gewesen. Ich hätte mich damals aber nicht getraut, von vorneherein davon auszugehen, dass der Code in C in 2KB passt. Dass er deutlich länger wäre ist sicher, denn die Beschränkung auf Register als Speicher ist dem Compiler nicht gegeben, und das kostet recht viel.
:
Bearbeitet durch User
Moby A. schrieb: > etwas nach. Ich hatte ja schon vom Zusammenstöpseln verschiedener > fertiger Funktionsbausteine gesprochen. Das geht, auch im Interesse zu > wahrender Übersicht, nur mit gewissen Verlusten. Die Bausteine selber > sind in ihrer Vielzahl aber sehr kompakt- Nichts anderes macht der Compiler. NUr dass er sich dann den ganzen Abschnitt noch einmal vornimmt und eine entsprechende Optimierung drüber laufen lässt. Und das schneller und zuverlässiger und mit weniger logischen Fehlern, als du als Mensch das jemals könntest. > in Summe dürfte das trotzdem > die C-Effizienz in den Schatten stellen, da bin ich sicher. Deine Sicherheit trügt. Die Praxis sagt nämlich etwas anderes. Sie sagt unter anderem auch, dass die Diskrepanz immer größer wird, je größer der Code wird. Bei winzigsten Programmen hat man mit Assembler je nach konkreter Aufgabenstellung einen Vorteil. Aber das relativiert sich sehr schnell und die Hochsprachen setzen zum Überholvorgang an. Ab da wird dann der Abstand rasch immer größer und ist selbst von geübtem Assembler Programmierern nicht mehr zu schliessen.
Karl H. schrieb: > Die Praxis sagt nämlich etwas anderes. Sie sagt > unter anderem auch, dass die Diskrepanz immer größer wird, je größer der > Code wird. Bei winzigsten Programmen hat man mit Assembler je nach > konkreter Aufgabenstellung einen Vorteil. Aber das relativiert sich sehr > schnell und die Hochsprachen setzen zum Überholvorgang an. Ich hab echt Respekt vor eurer Engelsgedult, aber ist euch wirklich nicht klar dass das schon gefühlte 300 mal angeführt wurde? Glaubt ihr wirklich eine echte Diskussion zu führen?
@A.K.
Du Ast ja auch richtig viel gespart, denn nach der Befehlsstatistik am
Ende des Listings werden viele Befehle garnicht benutzt. Die zu ihrer
Ausführung notwendigen Schaltelemente werden somit für eine spätere
Verwendung in einen Programm mit komplementärem Befehlspektrum geschont.
Dank ASM hat man volle Kontrolle darüber, welch Befehle benutzt werden.
Auch werden die Register R20..23 als Notfallreserve aufgespart.
Vorbildlich! Dafür gibt es den goldenen Wal am Bande!
Leider suggeriert aber die Verwendung von 5x! EOR, daß es sich hier um
keine typische MSR-Anwendung handelt.
Nein, MSR hat nichts mit Messen oder Steuern oder Regeln zu tun. Das
bedeutet Moby-Spart-Register. Damit ist auch klar, warum kein anderer zu
etwas Kompatiblem imstande wäre.
{$Scherz.off}
Wenn man erst sieht mit welchen fiesen ASM-Tricks ein Compiler die
Mehrfachnutzung von Code machen kann, z.B. bei -mcall-prologues. Sowas
get auch per Hand, aber wer kann da schon den Überblick behalten.
> Glaubt ihr wirklich eine echte Diskussion zu führen?
Nö, aber solange es Spaß macht. Wenn's mich anödet, dann lass ich's
sein, aber solange der Herausforderer immer wieder zappelt ...
:
Bearbeitet durch User
Yalu X. schrieb: > Moby A. schrieb: >> Johann L. schrieb: >>> Warum um alles in der Welt sollt es einen VORTEIL bringen, da ein >>> "Bytechen" einzusparen? Bereits vor der Implementierung hätte ich dir >>> sagen könne, dass mit Assembler einige "Bytechen" hätten gespart werden >>> können. Aber was ist der MEHRWERT davon? >> >> Bei den beiden Mickymaus Programmen von Dir? > > Jetzt muss ich doch wieder grinsen: > > Nachdem du dich bei deinem 200-Byte-Progrämmchen vehement gegen die > Aussage gewehrt hast, es sei ein Mickymausprogramm, bezeichnest du jetzt > deinerseits die Programme von Johann so. Na diese beiden Programme sind ja auch vom MiMo-Typ — eben weil sie die einzigen sind, die (annähernd) das Moby-Kriterium erfüllen. Alle anderen meiner Programme für 2KiB AVR (und drüber eh) wollte ich echt nicht in Assembler tippseln weils eben NIX bringt. > Im ersten von Johanns Programmen steckt aber mindestens doppelt so viel > Funktionalität wie in deinem Programm. Wenn Johanns Programm eine > Mickymaus ist, dann ist dein Programm ein Mickymäuschen. Es wird dir > auch nie und nimmer gelingen, Johanns Programm mit nur 200 Byte in > Assembler umzuschreiben. Das erste Programm erzeugt ca. 500 Bytes Binärcode (bei netto 100 LOC), ist eben viel SFR-Geraffel und auch 32-Bit Arithmetik. Und ja, das ginge in Assembler kleiner, aber keinesfalls in 200 Bytes. Und die 32-Bit Division inline zu kopieren, um ein paar grottige Bytes Code zu sparen, das macht Moby bestimmt Spaß... > Offensichtlich hast du dich von dem kompakten, übersichtlichen Quellcode > des C-Programms täuschen lassen, der natürlich deutlich kürzer und > einfacher als dein langatmiger, unstrukturierter Assemblerrattenschwanz > ist. > > Was du hier endlich einmal selber erfahren durftest: > > In höheren Programmiersprachen lassen sich im Gegensatz zu Assembler > auch komplexere Berechnungen und Abläufe einfach und übersichtlich > darstellen.
A. K. schrieb: > Thomas E. schrieb: >> Super. Und wieviel RAM und Flash hast du gespart? > > Wenns interessiert siehe Anhang. Drin ist der RS485-Slave, ein DS18x20, > ein serielles Interface zu einer damals schon alten Conrad Funkuhr, ein > LCD-Display, paar Schalter. Das RAM dient nur als UART-Puffer und > Stackspace. Du meine Güte, was hast du alleine mit deinen überflüssigen Kommentaren an Resourcen verschwendet. Weist du nicht dass man für evtl. Erweiterungen die Tastatur schonen muß?
Michael K. schrieb: > Streng genommen hat Moby bereits ein 200Byte Programm 'geliefert' Bitte entschuldige, aber welches der beidem "Programme" meinst Du denn? Jenes, das Yalu nach Mobys eigenen Kriterien so viel besser gelöst hat? Oder meinst Du seine offensichtlich böswillig konstruierte Falle? Ist aber auch wirklich blöd für den armen Moby. Erst bricht er sich einen ab um eine Falle zu konstruieren, die den Compiler möglichst alt aussehen läßt. Dann scheint einer hinein zu tappen, und dessen Kompilat sieht viel kleiner aus als seine ausgeklügelte Falle... sapperlot! >>Und er kommt zu dem Ergebnis: "Nur ein Traum war das Erlebnis. Weil", so schließt er messerscharf, "nicht sein kann, was nicht sein darf.<< (Christian Morgenstern, "Die unmögliche Tatsache") Also gerät der arme Moby in Panik und erfindet neue Anforderungen, von denen er nun aber ganz sicher ist, daß sie vom Compiler nicht erfüllt werden können. Menno! Nun reitet er bis zum Wundbrand auf seiner Falle herum -- aber was bleibt ihm auch anderes übrig? Und gleichzeitig versucht er sich an meinem Code abzuarbeiten, weil er trotz meiner ausdrücklichen Hinweise offensichtlich immer noch nicht kapiert hat, daß er nur ein Honigtöpfchen war, in das er mit großer Geste hineingefallen ist. Menno!! Die Moral von der Geschicht': je mehr Aufwand man treibt, um anderen eine Falle zu stellen, desto blöder ist es, selbst hinein zu fallen. Menno!!1! Gehuldigt sei dem Gewinner des Smileywettbewerbs: *ROFLMAO!*
Moby A. schrieb: > Reden wir mal nicht von "großen" Programmen. Nämlich solchen, die > Codegrößen von 1-100K nur vom Hörensagen kennen. Die sind mal auf jeden > Fall Domäne von Asm. Ich meine für den, der entsprechend Übung, > Vorbereitung, System mitbringt. Sind "Übung" und "Vorbereitung" nicht genau jener ressourcenverschwendende Overhead, den Du C immer vorwirfst? Für winzige Miniaturprogrämmchens, von denen Du hier faselst, brauch ich in C weder Übung, noch Vorbereitung. Das hack' ich einfach 'runter und hab' dann mehr Zeit zum Knutschen.
Gu. F. schrieb: > Glaubt ihr wirklich eine echte Diskussion zu führen? Nein, aber hast du mal versucht die Zeugen Jehovas an der Haustür zu überzeugten Satanisten zu bequatschen ? Das muß man als sportlichen Wettkampf sehen. Natürlich macht das überhaupt keinen Sinn, das ist so eine Art Brainjogging. Sheeva P. schrieb: > Also gerät der arme > Moby in Panik und erfindet neue Anforderungen Ich denke Du täuscht Dich. Moby hat vor langer Zeit jegliche Diskussions-Konventionen über Board geworfen. Er muß nicht in Panik geraten, er muß nichts beweisen, er behauptet einfach was er will, wann er will und ignoriert alles was seine Kreise stört. Ob er das wirklich alles glaubt, uns nur veräppelt, im realen Leben Bankensoftware in Cobol programmiert oder eine übergewichtige Friseuse aus Castrop Rauxel mit einem Hang zu Kreuzworträtseln und ASM ist werden wir wohl nie herausfinden. Ich finde das alles hochgradig lustig. Tschuldigung, aber auch Deine / Eure Verbissenheit finde ich recht erheiternd. Es macht wirklich keinen Sinn mit ihm zu diskutieren, nicht bei diesem Thema. Da kann man jetzt vor Wut die Tapeten von der Wand kratzen oder in sich hineinlächeln wie viele bunte Vögel diese Welt doch zu bieten hat. Stellenweise hat dieser Thread wirklich lehrreiche Dinge zu Tage gefördert, wozu ich unter anderem auch teilweise Deine Beiträge zähle. Die ganze Aufregung das er das einfach nicht einsieht ist aber verschwendete Energie. Diese Wut führt nur dazu das man sich selbst zu Äusserungen hinreissen läßt die nicht ganz sauber sind. Vor allem glaube ich eines. Wenn man mit einem Typen wie Moby beim Bier zusammensitzen würde währe man wahrscheinlich baff erstaunt wie vielschichtig und reflektiert der über unterscheidlichste Dinge reden kann. Die Forenfigur Moby ist eine Kreation des Menschen der dahinter verborgen bleibt. Dazu dient diese Figur und sie folgt einem Drehbuch. Sich darüber aufzuregen ist als würde ich Gerd Fröbe persönlich übelnehmen das er als Goldfinger 007 töten wollte.
Michael K. schrieb: > Wenn man mit einem Typen wie Moby beim Bier zusammensitzen würde währe > man wahrscheinlich baff erstaunt wie vielschichtig und reflektiert der > über unterscheidlichste Dinge reden kann. Das könnte ich mir auch gut vorstellen.
Michael K. schrieb: > Sheeva P. schrieb: >> Also gerät der arme >> Moby in Panik und erfindet neue Anforderungen > > Ich denke Du täuscht Dich. > Moby hat vor langer Zeit jegliche Diskussions-Konventionen über Board > geworfen. Er muß nicht in Panik geraten, er muß nichts beweisen, er > behauptet einfach was er will, wann er will und ignoriert alles was > seine Kreise stört. Diese These hast Du wiederholt geäußert, und einerseits bin ich durchaus geneigt, Dir darin zuzustimmen. Andererseits paßt es aber nicht ganz ins Bild, daß er so reagiert hat wie geschehen. Er hätte meinen Code zuerst testen und dann danach reagieren können. Dann wäre ihm sofort aufgefallen, daß der Code nicht funktionierte. Das hat er aber nicht getan, sondern sich stattdessen die Blöße gegeben, sofort und zuerst die neue Anforderung aus dem Hütchen zu zaubern und danach erst auszuprobieren, ob mein Code wirklich tut, was er denn tun sollte. Sicher hätte er das auch getan, wenn mein Honigtöpfchen im Vergleich nicht gar so klein gewesen wäre, oder wenn er gleich hätte sehen können, daß es nicht funktioniert. Daß mein Code so unlesbar ist und so viele ungebräuchliche Konstrukte nutzt, ist ja nun kein Zufall. g Obendrein scheint mir die Tatsache, daß er manchmal ziemlich wild um sich beißt, wenn er sich in die Enge getrieben sieht, darauf hinzuweisen, daß ihm durchaus etwas an der Sache liegt. Jedoch vermute ich, daß er C ganz passabel beherrscht und recht gut weiß, was so ein C-Compiler kann, denn sonst hätte er seine Falle nicht so ausgefeilt konstruiert. Insofern bin ich hinsichtlich Deiner These etwas unschlüssig -- aber das gehört ja zu dem, was die Geschichte so unterhaltsam macht. g > Stellenweise hat dieser Thread wirklich lehrreiche Dinge zu Tage > gefördert, wozu ich unter anderem auch teilweise Deine Beiträge zähle. Danke -- ich hoffe, nicht nur als Sozialstudie! g
Hmm, so einmal am Tag über die neuen Posts in diesem Thread gehen ist schon amüsant. Auf der einen Seite Moby, der davon überzeugt ist, das man mit Lochkarten näher an der Maschine ist und deswegen immer effizienter arbeiten kann gegen den Rest, der weiß, daß man mit mit Tastatur und Bildschirm praktisch immer im Vorteil ist....
:
Bearbeitet durch User
Michael K. schrieb: > Vor allem glaube ich eines. > Wenn man mit einem Typen wie Moby beim Bier zusammensitzen würde währe > man wahrscheinlich baff erstaunt wie vielschichtig und reflektiert der > über unterscheidlichste Dinge reden kann. Brrr die Vorstelltung find ich grad gruselig. Der wird sicher nicht auf Knopfdruck zum besten Kumpel. Wer sich mit Lügen und derart arrogant (wenn auch sehr unterschwellig) solche Garbenkämpfe liefert ist am Abend in der Kneipe immer noch der selbe Typ Mensch.
A. K. schrieb: > ein DS18x20, > ein serielles Interface zu einer damals schon alten Conrad Funkuhr, ein > LCD-Display, lol alles was du nicht selber kannst, hast du also in externe Hardware ausgelagert... ;-) ps. warum braucht C eigentlich (per se?) mehr speicher? sollte es nicht (durch "lokale variablen", bessere ausnützen der register usw) für C viel einfacher sein, speicher mehrfach (stack usw.) zu verwenden.. (und eben nur so kurz wie möglich zu reservieren)
Robert L. schrieb: > ps. warum braucht C eigentlich (per se?) mehr speicher? Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu suchen, für die man komplett und ausschlieslich mit den Registern der CPU durchkommt. Speicher braucht er dann nur für den Returnstack. Das ist in C ein bisschen schwer zu realisieren. Man könnte zwar mittels 'register' den Compiler auffordern, bestimmte Variablen in bestimmte Register zu legen, aber das ist ein 2-schneidiges Schwert, sobald irgendwelche System Library Aufrufe dazukommen, die von dieser Reservierung nichts wissen.
Robert L. schrieb: > alles was du nicht selber kannst, hast du also in externe Hardware > ausgelagert... Stimmt. ;-) > ps. warum braucht C eigentlich (per se?) mehr speicher? Tut es nicht. Nur zeigt grad das Beispiel meines gestern geposteten Asm-Codes die Grenzen der üblichen Compiler. Der Compiler wird Variablen nicht über die Grenzen von Funktionen hinaus in Registern platzieren. Grad bei Prozessoren mit vielen Registern, wie AVR, kann das einen erheblichen Unterschied ausmachen. Da aber die Anzahl Register begrenzt ist, ist es auch die Anzahl darin platzierbarer Variablen. Bei kleinen Programmen ist das kein Problem. Bei grossen und bei oft signifikant veränderten Programmen eignet sich diese Programmiertechnik weniger. Man könnte natürlich auch einen optimierenden Compiler bauen, der globale Registerplatzierung effizient nutzt, wenn ihm das sinnvoll erscheint. Ein solcher Compiler könnte auch bei kleinen Programmen locker mithalten. Nur müsste man dann immer alles zusammen übersetzen, sämtliche Libraries eingeschlossen. Das ist bei kleinen Programmen nur problemlos möglich, wenn der Quellcode der Libraries vorliegt, und bei grossen Programmen nicht praktikabel.
:
Bearbeitet durch User
A. K. schrieb: > Der Compiler wird Variablen > nicht über die Grenzen von Funktionen hinaus in Registern platzieren. ok, ich dachte mir es gibt vielleicht sowas wie "fastcall" https://de.wikipedia.org/wiki/Aufrufkonvention#Register_.28FastCall.29 gerade bei einer CPU mit so viel (pseudo-?) Registern wäre es doch hilfreich..
Robert L. schrieb: > ich dachte mir es gibt vielleicht sowas wie "fastcall" Bei Architekturen mit ausreichender Anzahl Register werden Parameter üblicherweise in Registern übergeben, soweit möglich. Bei AVR ebenfalls. Diese fastcall Methode ist also Stand der Technik. Das x86 ABI, aus dem man fastcall kennt, geht allerdings auf Zeiten vor ANSI-C zurück, und ohne Parameterdeklaration gibts bei der routinemässigen Übergabe in Registern kleine Probleme. Bei dem was ich grad schrieb geht es aber nicht um die Übergabe von Parametern, sondern um statische/globale Variablen.
:
Bearbeitet durch User
Karl H. schrieb: > Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu > suchen, für die man komplett und ausschlieslich mit den Registern der > CPU durchkommt. Speicher braucht er dann nur für den Returnstack. Ja. Und andere Aufgaben sind keine typischen 8bit MSR Anwendungen und werden per externem IC beigefügt.
Bernhard M. schrieb: > Hmm, so einmal am Tag über die neuen Posts in diesem Thread gehen ist > schon amüsant. Ja, es sind ein paar gute Kolumnisten dabei.
Karl H. schrieb: > Robert L. schrieb: > >> ps. warum braucht C eigentlich (per se?) mehr speicher? > > Weil einer von Mobys 'Tricks' darin besteht, sich nur Aufgaben zu > suchen, für die man komplett und ausschlieslich mit den Registern der > CPU durchkommt. Speicher braucht er dann nur für den Returnstack. So ist es, weswegen er ja auch nur solche Mickymausanwendungen für einem Vergleich zur Verfügung stellt. Wenn man sich nämlich einmal die etwas größere Applikation von Moby anschaut (für deren Programmierung Assembler seiner Ansicht nach ja ebenfalls nur Vorteile bringen soll), stellt man fest, diese sehr wohl RAM benutzt und davon nicht einmal wenig, nämlich 5415 Byte, s. dieser Beitrag: Moby A. schrieb: > 10K Asm-Codesize Eine solch intensive Speichernutzung entsteht meist dadurch, dass man größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler keine Vorteile bietet. Anders als in Assembler hat man aber in C die Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von 8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder 12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden. Wenn man wie Moby darauf erpicht ist, immer den jeweils kleinstmöglichen Controller einzusetzen, sehe ich hier gute Chancen, mit der Verwendung von C-Bitfields den ATxmega128A4U durch einen ATxmega64A4U mit halb soviel Speicher (4096 Byte RAM) zu ersetzen. Dadurch wird das Binary des Programms zwar etwas länger und langsamer, aber Flash-Speicher steht bei diesen Controllern sowieso im Überfluss zur Verfügung, und auch die Laufzeiteffizienz dürfte bei dieser Anwendung nicht die entscheidende Rolle spielen. Natürlich könnte man dasselbe auch in Assembler tun, allerdings erfordert das viel zusätzlichen Programmieraufwand, zudem wird das Programm durch die komplizierteren Elementzugriffe unübersichtlich und schlecht wartbar. In C hingegen hat man durch die Verwendung von Bitfields praktisch überhaupt keinen zusätzlichen Entwicklungsaufwand, da man im Wesentlichen nur die Datenstruktur(en) etwas anders deklarieren muss. Die Zugriffe auf Elemente mit "krummen" Bitzahlen werden vom Compiler automatisch erzeugt und unterscheiden sich im Quellcode überhaupt nicht von gewöhnlichen Elementzugriffen. Deswegen würde ich sagen, dass bei datenintensiven Anwendungen wie Mobys Haussteuerung C nicht nur bzgl. der Entwicklungszeit sondern auch des RAM-Verbrauchs klare Vorteile bietet.
Naja, prinzipiell geht das alles in ASM ja auch, insofern kann man nicht sagen daß C weniger Speicher braucht. Nur ist der Programmieraufwand inklusive Fehleranfälligkeit in ASM natürlich drastisch höher, wenn man so geizig programmiert. Per Definition ist es dann aber keine typische Anwendung mehr :-)
Yalu X. schrieb: > Hmm, du hast für das Projekt einen ATxmega128A4U genommen, weil der > nächstkleinere ATxmega64A4U zu wenig RAM hat. Von der Flash-Größe hätte > sogar ein ATxmega16A4U locker gereicht (sogar mit etlichen freien KB für > Erweiterungen ;-)). Was ist denn das für ein altkluger Vorwurf... Da handelt es sich um Code für meine SmartHome-Zentrale. Da wird ständig erweitert, die ist niemals fertig. Wie dumm, bei solch absehbarer Zukunft am falschen Ende zu sparen. Ganz anders sieht das z.B. bei Sensor-Aktor Knoten und kleinen dezentralen Steuerungen aus. Halt weiteren Millionen 8-Bit MSR Anwendungen. Yalu X. schrieb: > Siehst du, und bei C bleibt die Codedichte auch bei größeren Programmen > konstant. Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter bleibt. Die etwas nachlassende Codedichte geht im Wesentlichen auf die notwendige Gliederung des Codes zurück, um bei größeren Projekten den Überblick zu behalten. In einem finalen Schritt könnte man das freilich vieles zusammenlegen. Frank M. schrieb: > Moby A. schrieb: >> Frank M. schrieb: >>> Ab 1KB Codegröße ist ASM mit C IMMER schlagbar >> >> Das halte ich für falsch. Und wir wollen gleich nochmal klarstellen, >> daß nichts als der Ressourcen-Verbrauch gemeint ist. > > Genau dafür hast Du keinen Beleg. Hast Du denn einen Beleg für Deine Behauptung ? Wie man schön sieht handelt es sich bei mangelnden Vergleichsmöglichkeiten hier um ein Totschlagargument, mit dem kein Blumentopf zu gewinnen ist. Um da weiterzukommen und mal einen Anfang zu machen habe ich mich für meine Behauptung um eine simple, aber vollständige Asm-App zum Vergleich bemüht: Beitrag "Kleines Tiny13 Sensorboard" Wie zu erwarten kam natürlich nichts besseres. Die meisten werden hier trotz anderslautender Heuchelei wissen, daß man sich mit dem Versuch nur in die Nesseln setzen kann. Denn wenn manche Profis hier nur halb so viel C-Experte sind wie sie tun wär das längst fertig ;-) @Mod: Die Beantwortung von Beiträgen wird ohne funktionierende Aufteilung bei langen Threads immer zäher. Ist das Absicht? ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Die Beantwortung von Beiträgen wird ohne funktionierende > Aufteilung bei langen Threads immer zäher. Nach welchen Kriterien willst du aufteilen? "Sinnvoll" und "nicht sinnvoll"?
:
Bearbeitet durch User
Klaus W. schrieb: > Nach welchen Kriterien willst du aufteilen? > "Sinnvoll" und "nicht sinnvoll"? Du meinst "Sinnvoll" so wie Dein Beitrag gerade? Immer wieder beeindruckend, was manche "Profis" hier so draufhaben ;-(
:
Bearbeitet durch User
Moby A. schrieb: > Hast Du denn einen Beleg für Deine Behauptung ? > Wie man schön sieht handelt es sich bei mangelnden > Vergleichsmöglichkeiten hier um ein Totschlagargument, mit dem kein > Blumentopf zu gewinnen ist. Moby FALSCH!!! Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich zurück mit Falschaussagen Beitrag "Re: C versus Assembler->Performance"
also wenn man als ASM Programmierer etwas lernt, dann offensichtlich c&p
Moby A. schrieb: > Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter > bleibt. Die etwas nachlassende Codedichte geht im Wesentlichen auf die > notwendige Gliederung des Codes zurück, um bei größeren Projekten den > Überblick zu behalten. Und eben deswegen ist die Code auch nicht dichter als in C. Ganz im Gegenteil: Der vom C-Compiler erzeugte Assemblercode braucht nicht übersichtlich zu sein, deswegen darf der Compiler gerne etwas mehr optimieren (und tut das auch) als du es mit Rücksicht auf die Übersichtlichkeit tun würdest. > In einem finalen Schritt könnte man das freilich vieles zusammenlegen. Was aber rein hypothetisch ist, da der finale Schritt nie stattfinden wird, wie du ja selbst schreibst: Moby A. schrieb: > Da handelt es sich um Code für meine SmartHome-Zentrale. > Da wird ständig erweitert, die ist niemals fertig. In C muss man für so etwas nicht bis zum finalen Schritt warten, weil mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit verbunden ist.
>>>> Ab 1KB Codegröße ist ASM mit C IMMER schlagbar >>> Das halte ich für falsch. >> Genau dafür hast Du keinen Beleg. > Hast Du denn einen Beleg für Deine Behauptung ? > ... > Beitrag "Kleines Tiny13 Sensorboard" Zurück auf los! Yalu X. schrieb: > In C muss man Dafür muss man erst C lernen. Oder als Workaround sich ASM schön reden.
:
Bearbeitet durch User
Yalu X. schrieb: > größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal > in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler > keine Vorteile bietet. Anders als in Assembler hat man aber in C die > Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger > zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von > 8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder > 12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden. Nicht nur das. Ich habe auch die Möglichkeit, schnell und einfach die komplette Datenorganisation zu ändern, wenn sich im Laufe der Zeit die Anforderungen ändern oder erweitert werden muss. In Assembler artet so ein Unterfangen regelmässig in einen mittleren Albtraum aus. Und ja, ich weiss durchaus wovon ich da spreche, hab ich schon gemacht - würde ich nie wieder tun.
Karl H. schrieb: > wenn sich im Laufe der Zeit die > Anforderungen ändern oder erweitert werden Du hast vorher nur nicht genügend Vorbereitung Planung und Übung gemacht.
Moby A. schrieb: > Egal was ich > hier aber veröffentlichen würde- wenn auf C-Seite keiner in der Lage und > willens ist, selbst einen 200-Byte Code nachzuprogrammieren fehlt ein > C-Äquivalent zum Vergleich. Ich werde Dir jetzt mal vorführen, warum Deine Argumentation Schwachsinn ist. Situation A =========== - Moby legt ein 200Byte-Programm vor - Moby sagt: "Solange kein C-Programmierer ein äquivalentes C-Programm vorlegt, ist mein Programm in ASM das optimalste Programm der Welt!" - Keiner hat Lust, Mobys Programm in allen Einzelheiten zu verstehen (weils Zeit kostet) und alle verlieren auch sämtliche Lust, weil Moby plötzlich nachschiebt, als er seine Felle schwimmen sieht: "Das Programm darf KEIN RAM nutzen!". Auch hat keiner Lust, da Arbeit reinzustecken, weil keiner es braucht - Moby schreit: "Aha, ihr könnt es nicht! ASM ist also BESSER!" Soweit so gut. Jetzt drehe ich den Spieß rum: Situation B =========== - N.N. legt ein C-Programm vor mit 1KB Binärgröße - N.N. sagt: "Solange kein ASM-Programmierer ein äquivalentes ASM-Programm vorlegt, ist mein Programm in C das optimalste Programm der Welt!" - Moby sagt: "Nee, habe ich keine Lust, weil ichs nicht brauche". - N.N. schreit: "Aha, Du kannst es nicht! C ist also BESSER!" Würdest du so einen Scheiß akzeptieren? Ich kann Dir hunderte von C-Programmen hier präsentieren, wo Du überhaupt nicht in der Lage wärest, diese in ASM nachzugrogrammieren. Aber nur um zu sagen: "C ist besser als ASM"? Bestimmt nicht. Weil diese Argumentation Schwachsinn ist.
:
Bearbeitet durch Moderator
Frank M. schrieb: > - Keiner hat Lust, Mobys Programm in allen Einzelheiten zu verstehen > (weils Zeit kostet) Eigentlich nicht. Yalu hat mich da wieder auf ein paar Ideen gebracht, wie man den Compiler für seine Sensorboard Aufgabenstellung mit dem kruden Übertragungformat zu seinem Nutzen einspannen könnte. Und auch die Sache mit den Register-Variablen würde man IMHO in den Griff kriegen (avr-gcc unterstützt ja noch das 'register' Schlüsselwort und Library Aufrufe sind nicht notwendig) Nur hab ich deswegen keine Lust dazu, weil sich Moby konsequent in der umgekehrten Richtung weigert, aus einer etwas umfangreicheren Vorgabe in absehbarer Zeit ein entsprechendes ASM-Programm zu schreiben. Also genau dein Szenario B, nur das ich etwas größer angesetzt hätte als lediglich 1K, damit die Diskrepanz so richtig schön zum tragen kommt :-) Ich versteh natürlich, dass er da nicht 3 Wochen jeden Tag 3 bis 4 Stunden über dem Code brüten will, um den Flash Verbrauch wieder um 3 Bytes zu drücken. Aber auf der anderen Seite ist genau das die Lektion, um die es geht: Erstens interessiert das keinen, ob das Programm 3 Bytes kürzer ist oder nicht, solange es in den Flash passt und zweitens ist genau das Argument, das Moby immer wieder bringt ("Ich hab mit meiner Zeit besseres zu tun") genau eines der Argumente, warum Hochsprachen meistens die bessere Wahl sind - eben weil wir mit unserer Zeit besseres zu tun haben, als 3 Bytes im Flash nachzujagen.
:
Bearbeitet durch User
Moby A. schrieb: > Ändert aber nix dran daß der C-Ressourcenverbrauch deutlich schlechter > bleibt. Hör jetzt bitte mal auf mit dem Unsinn, das ist wirklich nur noch lächerlich und keiner Diskussion mehr würdig. Sollte man nach dermassen viel Widerspruch von deutlich erfahreneren Leuten ja irgendwann kapieren, findest du nicht? Markus M. schrieb: > Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich > zurück mit Falschaussagen Am Anfang war Moby einfach stur und uneinsichtig, dann begann er, Argumente und Fakten ganz zu ignorieren und mittlerweile ist er sogar zu Lügen und Falschaussagen übergegangen.
Markus M. schrieb: > Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich > zurück mit Falschaussagen Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt gezeigt wurde nicht geschlagen und ist nicht zu schlagen. Höchstens in gewissen Wunschfantasien ;-) Speziell Dein Beitrag dazu war bislang überschaubar und fachlich: nicht vorhanden. Yalu X. schrieb: > In C muss man für so etwas nicht bis zum finalen Schritt warten, weil > mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher > Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit > verbunden ist. Auch ohne "finale Schritte" bleibt Asm Code effizienter. Wenn großartige Datenstrukturen zu optimieren, also mit umfangreichen, verschiedenen Datenmengen umzugehen wäre dann mag die Welt anders ausschauen. Karl H. schrieb: > Yalu X. schrieb: > > größere Arrays von Datenstrukturen benötigt. Diese sind zunächst einmal > in Assembler gleich groß wie in C, weswegen in diesem Punkt Assembler > keine Vorteile bietet. Anders als in Assembler hat man aber in C die > Möglichkeit, Datenstrukturen ohne großen Aufwand mittels Bitfields enger > zu packen, wenn die einzelnen Elemente nicht den vollen Wertebereich von > 8- oder 16-Bit-Variablen ausfüllen. Dadurch können auch 4-, 10- oder > 12-Bit-Werte mit minimalem Overhead im Speicher abgelegt werden. > > Nicht nur das. Ich habe auch die Möglichkeit, schnell und einfach die > komplette Datenorganisation zu ändern, wenn sich im Laufe der Zeit die > Anforderungen ändern oder erweitert werden muss. In Assembler artet so > ein Unterfangen regelmässig in einen mittleren Albtraum aus. Und ja, ich > weiss durchaus wovon ich da spreche, hab ich schon gemacht - würde ich > nie wieder tun. Diese Möglichkeiten sind ja schön und gut- aber s.o.
Moby A. schrieb: > Markus M. schrieb: >> Der Beweis wurde schon vor einigen MONATEN erbracht, also halte dich >> zurück mit Falschaussagen > > Nichts wurde erbracht. Optimierter Asm-Code wie in meinem Projekt > gezeigt wurde nicht geschlagen und ist nicht zu schlagen. Das ist wieder eine glatte Lüge/Falschaussage:
1 | Mobys Asm-Code Yalus C-Code |
2 | ————————————————————————————————————————————————— |
3 | Flash-Verbrauch 266 256 |
4 | RAM-Verbrauch¹ 6 + 1 GPIOR 9 |
5 | Stack-Verbrauch 2 4 |
6 | Quellcodezeilen² 143 91 |
7 | Quellcodezeichen³ 1614 1707 |
8 | ————————————————————————————————————————————————— |
9 | ¹) ohne Stack |
10 | ²) ohne Leer- und Kommentarzeilen |
11 | ³) ohne Kommentare, Leerraum und Zeilenvorschübe |
12 | |
13 | Compiler: GCC 4.7.4 |
14 | Assembler/Linker: Binutils 2.25.1 |
15 | C-Standardbibliothek: AVR-Libc 1.8.1 |
Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code braucht weniger RAM und weniger Codezeichen.
Matthias L. schrieb: > Karl H. schrieb: > wenn sich im Laufe der Zeit die > Anforderungen ändern oder erweitert werden > > Du hast vorher nur nicht genügend Vorbereitung Planung und Übung > gemacht. Da ist was dran. Zumindest bei Projekten < 10K ;-) Frank M. schrieb: > - Moby sagt: "Nee, habe ich keine Lust, weil ichs nicht brauche". Genau da liegt der Fehler in Deinem Szenario: Wenn Moby wie die C-Sturköpfe hier darauf besteht, daß sein Code sparender wär und für sich ein KnowHow wie manche hier in Anspruch nimmt wird er sich gefälligst auf den Hosenboden setzen und es beweisen. Ansonsten sieht er seine Thesen selbstverständlich nicht für bewiesen an. Genauso schauts hier aus: Aussage gegen Aussage. Frank M. schrieb: > Ich kann Dir hunderte von C-Programmen hier präsentieren, wo Du > überhaupt nicht in der Lage wärest, diese in ASM nachzugrogrammieren. Programme aus dem hinlänglich umrissenen Einsatzbereich lassen sich jederzeit besser in Asm coden. Umgekehrt könnte ich Dir viele Asm-Programme präsentieren. Aber Du scheiterst ja mit Deinem Anspruch auch schon an meinen kleinsten "Projektchen" ;-) > Aber nur um zu sagen: "C ist besser als ASM"? Bestimmt nicht. Weil diese > Argumentation Schwachsinn ist. Stimmt. Allgemein "C ist besser als Asm" wäre Schwachsinn. Bei 8-Bit MSR (ohne große Berechnungen und Datenmengen) ist Asm besser. Dabei bleibt es. Wer anderes behauptet darf das tun, wer mich aber wiederlegen will kommt an der C-Codierung meiner entsprechend optimierten Beispiele nicht vorbei!
P. M. schrieb: > Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code > braucht weniger RAM und weniger Codezeichen. Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu halten ist hatte ich weiter oben bereits das Nötige gesagt. Karl H. schrieb: > Eigentlich nicht. Yalu hat mich da wieder auf ein paar Ideen gebracht, > wie man den Compiler für seine Sensorboard Aufgabenstellung mit dem > kruden Übertragungformat zu seinem Nutzen einspannen könnte. Na dann mal los. Mal sehen was für ein leichtverständlicher Code dabei rauskommt ;-) > Nur hab ich deswegen keine Lust dazu Ach sooo... Wird nun wohl doch nix ;-( Na ja so ein Vollzeit-Forumsmensch hat auch wenig Zeit. Verstehe ich. Dann sollte man sich mit kruden Thesen zur C-Überlegenheit aber zumindest etwas zurückhalten bzw. sie nicht für bewiesen erklären.
:
Bearbeitet durch User
Moby A. schrieb: > Genau da liegt der Fehler in Deinem Szenario: Wenn Moby wie die > C-Sturköpfe hier darauf besteht, daß sein Code sparender wär und für > sich ein KnowHow wie manche hier in Anspruch nimmt wird er sich > gefälligst auf den Hosenboden setzen und es beweisen. Ansonsten sieht > er seine Thesen selbstverständlich nicht für bewiesen an. Genauso > schauts hier aus: Aussage gegen Aussage. Ich brauche also hier nur ein C-Programm zu posten mit 1KB Binärcode und dann darf ich behaupten, dass C besser ist als ASM und Du würdest dann versuchen, es in ASM besser zu schaffen? Habe ich das richtig verstanden? Klasse!
Moby A. schrieb: > Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu > halten ist hatte ich weiter oben bereits das Nötige gesagt. Genau: du hast im Anschluss die von Yalu vorgelegte Lösung mal wieder als irrelevant wegdiskutiert und irgendwelche Details deiner Implementierung nachträglich zum unbedingt vorhanden sein müssenden Feature erklärt. Damit kannst du dir deine Welt natürlich irgendwie schönreden, nur glaubt dir das mittlerweile keiner mehr. Yalus Code war nun für genau die Klasse Mickymausprogramme, in denen du sonst noch deine Domäne siehst (die du gleich mal großzügig auf 10 K und mehr an Code ausdehnst), und selbst dort hat er dich in weiten Teilen (wenn auch nicht in allen) nach deinen Maßstäben schlagen können (weniger Flash, mehr RAM). Lass mal, ist ein unterhaltsamer Thread, wir wissen, dass du von deiner Meinung nicht abzubringen bist, nicht einmal durch Beweise.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Bei 8-Bit MSR > (ohne große Berechnungen und Datenmengen) ist Asm besser. Dabei bleibt > es. Nein, das ist schon für sich falsch, wie Yalu gezeigt hat - nochmals, weils so schön ist:
1 | Mobys Asm-Code Yalus C-Code |
2 | ————————————————————————————————————————————————— |
3 | Flash-Verbrauch 266 256 |
4 | RAM-Verbrauch¹ 6 + 1 GPIOR 9 |
5 | Stack-Verbrauch 2 4 |
6 | Quellcodezeilen² 143 91 |
7 | Quellcodezeichen³ 1614 1707 |
8 | ————————————————————————————————————————————————— |
9 | ¹) ohne Stack |
10 | ²) ohne Leer- und Kommentarzeilen |
11 | ³) ohne Kommentare, Leerraum und Zeilenvorschübe |
12 | |
13 | Compiler: GCC 4.7.4 |
14 | Assembler/Linker: Binutils 2.25.1 |
15 | C-Standardbibliothek: AVR-Libc 1.8.1 |
Moby A. schrieb: > P. M. schrieb: >> Yalus Code braucht weniger Flash und weniger Codezeilen, dein Code >> braucht weniger RAM und weniger Codezeichen. > > Darauf darfst auch Du gerne weiter herumreiten- zu dem was davon zu > halten ist hatte ich weiter oben bereits das Nötige gesagt. Ja, du hast viel dazu gesagt und zeigst damit gleich selbst, dass Assembler nur unter vielen, vielen Bedingungen besser ist als C. Selbst im 8-Bit-MSR-Bereich.
Moby A. schrieb: > Da handelt es sich um Code für meine SmartHome-Zentrale. > Da wird ständig erweitert, die ist niemals fertig. Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU leider nicht Codekompatibel ist. Als Workaround kann man dann auch was richtig großes nehmen und den AVR darauf komplett emulieren. Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C ?
P. M. schrieb: > Nein, das ist schon für sich falsch, wie Yalu gezeigt hat - nochmals, > weils so schön ist: Bitte jeden Tag neu posten, vielleicht liest es Moby ja mal :-)
Moby A. schrieb: > Yalu X. schrieb: >> In C muss man für so etwas nicht bis zum finalen Schritt warten, weil >> mit der Optimierung der Datenstrukturen so gut wie kein zusätzlicher >> Aufwand und überhaupt keine Einschränkung der Übersichtlichkeit >> verbunden ist. > > Auch ohne "finale Schritte" bleibt Asm Code effizienter. Nein. Vielleicht bei einigen von dir ausgewählten Mickymausprogrammen mit speziell dafür von dir hin"optimierten" Anforderungen. Aber definitiv nicht bei deinem 10K-Programm, auf das ich mich bezog. Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler- als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat (und davon gibt es hier im Forum viele), wird dies bestätigen. Da du selbst aber nicht zu dieser Personengruppe gehörst, bleibt deine Behauptung einfach nur eine Behauptung, die du ohne jegliche Grundlage in die Welt hinausposaunst. Die Vehemenz und die Ausdauer, mit der du dies tust, ändert an dieser Tatsache nicht das geringste.
Michael K. schrieb: > Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome > Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU > leider nicht Codekompatibel ist. Ja eben. Absolute Sackgasse. Ich persönlich freue mich dass es noch etwas anderes als AVR gibt und es macht mir außerordentlichen Spaß, zu sehen, wie einfach doch (portabel geschriebene) C-Programme auf komplett andere Prozessorfamilien angepasst werden können. Mobys ASM Smarthome-Projekt ist dann einfach nur noch für die Tonne. > Als Workaround kann man dann auch was richtig großes nehmen und den AVR > darauf komplett emulieren. Ja klar, schon heutzutage kann man komplette Sinclair Spectrum Computer von 1982 mittlerweile auf einem STM32F429 Discovery für ein paar Euro emulieren. Sogar die Spiele laufen 1:1. :-) Aber da Moby ja für jedes kleine MickyMaus-Problem auch einen eigenen µC einsetzt, muss er wahrscheinlich erst Tausende von ATTinys emulieren, bis er das Licht im Wohnzimmer anschalten kann ;-) > Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C > ? Den kann sich Moby dann verkneifen.
Michael K. schrieb: > Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome > Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU > leider nicht Codekompatibel ist. Ist doch kein Problem. Aus dem Thread "CP/M auf AVR" machen wir "AVR auf ARM" oder "AVR auf JS" und die Assenbler-Sause kann weiter gehen. Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen lassen: - M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander pappen kann. - -> das ist doch der Vorwurf an Compiler. - M.: man muß am Ende eben optimieren. - M.:(2 Posts später) auch ohne Optimierung ist ASM schneller Wie er's braucht und ohne jede Scham beim Lügen. Jeman mit dem man eben nicht ein Bier trinken gehen will.
Carl D. schrieb: > Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen > lassen: > - M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander > pappen kann. > - -> das ist doch der Vorwurf an Compiler. > - M.: man muß am Ende eben optimieren. > - M.:(2 Posts später) auch ohne Optimierung ist ASM schneller Japp, genau das macht er schon den ganzen Thread hindurch. Er wechselt ständig von einem (Schein-)Argument zum nächsten. Dass diese in keinster Weise zusammen passen, hat er entweder nicht gemerkt, oder es ist ihm egal.
Yalu X. schrieb: > Vielleicht bei einigen von dir ausgewählten Mickymausprogrammen Ich schlage vor nutzlose Programme die kein RAM benutzen, keiner braucht und max. 200 bytes groß sind zu Ehren unseres AVR Spar Königs künftig MobyMausProgramme zu nennen.
Jetzt ist Schluss mit diesem unsäglichen hin und her. Jetzt kommt der Beweis: Damit nicht nur ausgwiesene Assembler-Koryphäen und C-Experten diese Codes verstehen, sondern auch Anfänger etwas mitnehmen können, habe ich ein sehr einfaches <10K-Beispiel gewählt: Eine blinkende LED, Blinkfrequenz ca. 2Hz. Die vorgegebene Hardware: Atmega88 LED sowie das übliche Vogelfutter Das C-Programm: Takt: 1MHz, intern
1 | #ifndef F_CPU
|
2 | #error F_CPU not defined.
|
3 | #endif
|
4 | |
5 | #include <avr/io.h> |
6 | #include <avr/interrupt.h> |
7 | |
8 | volatile char jobflag; |
9 | |
10 | int main(void) |
11 | {
|
12 | char count = 0; |
13 | TCCR0A = (1 << WGM01); |
14 | TCCR0B = (1 << CS02) | (1 << CS00); |
15 | TIMSK0 = (1 << OCIE0A); |
16 | OCR0A = 60; |
17 | DDRB = (1 << 1); |
18 | sei(); |
19 | while(1) |
20 | {
|
21 | if(jobflag) |
22 | {
|
23 | jobflag = 0; |
24 | count++; |
25 | count %= 4; |
26 | if(!count) PINB |= (1 << 1); |
27 | }
|
28 | }
|
29 | }
|
30 | |
31 | ISR(TIMER0_COMPA_vect) |
32 | {
|
33 | jobflag = 1; |
34 | }
|
Statistik: Resourcenverbrauch: Flash: 164 Bytes RAM: 1 Byte + Stack E²PROM 0 Register: einige Fortgeschrittene oder besser: Entwicklungszeit: <= 10 Min. Frustfaktor: keiner Kenntnisvoraussetzungen: hoch Anfänger: Entwicklungszeit: Mit Karl-Heinz' geduldiger Hilfe in einem Thread mit 93 Beiträgen(davon 17 gelöscht) und hilfreichen Tips wie "Kauf dir ein C-Buch" oder Hinweisen in Form rhetorischer Fragen wie " Hast du kein Google", dreimal der Antwort "42", einem deftigen Anschiss von c-hater und einem aufmunternden Gedicht von Paul: 1 Woche Frustfaktor zu Anfang keiner, voller Elan Freundin: stinksauer Frustfaktor: hoch Freundin: Schluss gemacht Frustfaktor: noch höher Frustfaktor: nach dem Anschiss von c-hater stark suizidgefährdet Frustfaktor: nach dem Gedicht von Paul ging das dann wieder Lernnotwendigkeit: sehr hoch Das Assembler-Programm: Takt: 16KHz, ja Kilohertz! Taktflankenschonende und stromsparende 16KHz 128KHz intern, Clockprescaler 8
1 | sbi $04,1 |
2 | sbi $03,1 |
Statistik: Resourcenverbrauch: Flash: 4 Bytes RAM: 0, kein Stack E²PROM 0 Register: 0 Fortgeschrittene: Entwicklungszeit < 1 Min. Frustfaktor keiner Kenntnisvoraussetzungen: egal Anfänger: Entwicklungszeit <= 1 Min. Frustfaktor: keiner Freundin: hat sie gar nicht mitgekriegt Frustfaktor: 0 Lernnotwendigkeit: sehr gering, da aus dem Instruction Set nur eine einzige Anweisung verwendet wird. Alle anderen Anweisungen des Atmega88 werden geschont und können später gelernt werden. Also dann, wenn man sie braucht. Resultat: Resourcenverbrauch, also das einzige, was wirklich zählt: Flash: 164 Bytes / 4 Bytes = Faktor 41 oder 4100% RAM und Register werden vom Assembler-Programm gar nicht verwendet. Das einzige, wo der C-Compiler mithalten kann, ist der E²PROM-Verbrauch. Im C-Programm steckt sicher noch Optimierungspotenzial. Das Assembler-Programm dagegen ist unoptimierbar. Das C-Programm muss für jeden anderen Controller neu kompiliert werden. Der Opcode des Asm-Programms kann auf alle Atmega und Attiny einfach so draufgeflasht werden. Einzige Voraussetzung ist, dass sie Pin-Toggle mit den PIN-Registern können. Manchmal blinken sie etwas schneller oder langsamer. Aber das läst sich hervorragend als RAM-Größen-Indikator verwenden. Das sind die Fakten. mfg.
Frank M. schrieb: > Habe ich das richtig verstanden? Klasse! Das hast Du natürlich so verstanden wie Du es brauchst. Hab ich aber nicht anders erwartet ;-) Jörg W. schrieb: > Genau: du hast im Anschluss die von Yalu vorgelegte Lösung mal wieder > als irrelevant wegdiskutiert und irgendwelche Details deiner > Implementierung nachträglich zum unbedingt vorhanden sein müssenden > Feature erklärt. Nimm einfach das zur Kenntnis was ich dazu weiter oben schon gesagt habe. Ansonsten: Warte auf den entsprechenden Projektthread. Das Thema ist nicht abgeschlossen. > Lass mal, ist ein unterhaltsamer Thread, wir wissen, dass du von deiner > Meinung nicht abzubringen bist, nicht einmal durch Beweise. Doch: Mit einer besseren Lösung als mein entsprechend optimiertes Asm-Projekt. Michael K. schrieb: > Ich sehe schon wie nach Ende der AVR Lebensdauer 10 Jahre ASM Smarthome > Entwicklung in die Tonne fliegen weil die nächste in Frage kommende MCU > leider nicht Codekompatibel ist. Meinst Du? Das bestreite ich. Mein älteres, immer noch in Betrieb befindliches Home-Control System läuft ja schon mit einem Mega128, in verschiedenen Ausbauphasen seit 10 Jahren. Von den AVRs hab ich genügend auf Lager. Und, schonmal in den ersten 2016er Reichelt Katalog geschaut? Da gibts noch den Z80 ;-) > Wie das dann wohl mit dem Ressourcenverbrauch aussieht im Vergleich zu C > ? Blöd. Aber der Fall wird nicht eintreten. Yalu X. schrieb: > Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler- > als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat > (und davon gibt es hier im Forum viele), wird dies bestätigen. Wer den gleichen Funktionsumfang tatsächlich zweimal kodiert (wer würde das tun?) und den Asm-Code mit Übung, Vorbereitung und System zu optimieren weiß würde das nicht bestätigen. Die meisten aber programmieren ohnehin nur in C. Frank M. schrieb: > muss er wahrscheinlich erst Tausende von ATTinys emulieren, > bis er das Licht im Wohnzimmer anschalten kann ;-) Tatsächlich sind es drei Controller: Die M128 Hauptsteuerung kontrolliert die Stromzuführung, ein alter Xmega32 schaltet vorort zwischen Licht/Beamer Betrieb um und in der eigentlichen Lampe steckt noch ein helligkeitsgesteuerter Tiny ;-)
Moby A. schrieb: > Yalu X. schrieb: >> Glaub's mir, es ist so, und jeder der schon einmal sowohl ein Assembler- >> als auch ein C-Programm mit deutlich mehr als 200 Bytes geschrieben hat >> (und davon gibt es hier im Forum viele), wird dies bestätigen. > > Wer den gleichen Funktionsumfang tatsächlich zweimal kodiert (wer > würde das tun?) und den Asm-Code mit Übung, Vorbereitung und System zu > optimieren weiß würde das nicht bestätigen. Doch.
Thomas E. schrieb: > Jetzt ist Schluss mit diesem unsäglichen hin und her. > > Jetzt kommt der Beweis: > .... Mist. Ausgerechnet heute ist die weiße Fahne in der Wäsche.
Thomas E. schrieb: > Jetzt kommt der Beweis: > ... > Das sind die Fakten. Ja ganz nett wie Du Dich den Vorteilen von Asm annäherst, wenn auch ein ganz klein wenig übertrieben ;-) Carl D. schrieb: > Aber eigentlich sollte man die Diskussion mit einem so unfairen Typen > lassen: Was Du unfair nennst ist in Wirklichkeit nur Dein Mangel an Argumenten. Im übrigen, warum lässt Du die Diskussion nicht einfach? > - M.: ASM ist besser, weil man so Codeblöcke aus dem Fundus aneinander > pappen kann. - -> das ist doch der Vorwurf an Compiler. Quatsch. > - M.: man muß am Ende eben optimieren. Hat niemand behauptet. > Wie er's braucht und ohne jede Scham beim Lügen. Die fehlt mir zum Beispiel bei Dir. Du wirst mich aber selbst damit nicht beirren. Kein Wunder, daß Du so keine Punkte machst und rumjammerst.
Yalu X. schrieb: > Doch. Nö. So ein Mist: Wieder Aussage gegen Aussage. Probiers nochmal mit dem überlegenen Erfahrungsschatz, einer Portion Lächerlichmachen oder auf die harte Tour: Der Vorwurf der Lüge kommt immer gut ;-(
@Moby: Mist, weil du deine letzten zwei Beiträge so schnell hintereinander gepostet hast, habe ich dein Jubiläum verpasst. Trotzdem nachträglich herzlichen Glückwunsch zu deinem
1 | 333 000 000 |
2 | 3 3 0 0 0 0 |
3 | 3 0 0 0 0 |
4 | 33 0 0 0 0 |
5 | 3 0 0 0 0 |
6 | 3 3 0 0 0 0 |
7 | 333 000 000 -sten Beitrag |
in diesem Thread :) Das muss dir erst mal jemand nachmachen. (Inzwischen sind es sogar schon 301). Spätestens bei 500 hast du ganz sicher alle hier von ASM überzeugt.
Yalu X. schrieb: > Trotzdem nachträglich herzlichen Glückwunsch. Du überrascht mich. Mit einem Glückwunsch zu irgendwelchen Beitragszahlen hab ich nicht gerechnet. Mir tuts bloß um die armen Minuspunktbewerter leid die hier soviel zu tun haben :-) Ich will Dich aber auch mal überraschen: Nämlich damit daß mir Beitragszahlen relativ schnuppe sind. Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an Effizienz gewinne... Ich geb die Hoffnung aber nicht auf ;-)
Moby A. schrieb: > wenn auch ein ganz klein wenig übertrieben Was ist denn daran übertrieben? Willst du etwa von der mangelnden Effienz in deinem Code ablenken? Ich benutze nicht einmal die Register! Und schummele auch nicht beim RAM! Und ich habe den C-Code zum Vergleich zum beigefügt! Das sind Fakten, denen nicht widersprochen werden kann. mfg.
Moby A. schrieb: > daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an > Effizienz gewinne. Das könntest du, wenn du es nur wölltest – allerdings wahrscheinlich nicht so sehr in deinem Sinne. Du würdest deine Entwicklungszeit nämlich schätzungsweise zehnteln können, und dennoch passt das alles noch ins gleiche Device rein. Davon abgesehen, mit nur wenigen Cent mehr (ATtiny25 oder 45 statt 13) bekämst du eine in vielerlei Hinsicht schönere Hardware zusätzlich zu mehr Platz geboten (wir hatten gerade erst das Thema Messung der Batteriespannung mit dem ADC ohne zusätzliche äußere Beschaltung, das geht mit dem 13 nicht, mit dem 25 schon). Da du ja dann massig Zeit gewonnen hättest, könntest du den nun gewonnenen Platz sogar mit weiteren Features beleben. :-) Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz gewiss die letzten, die dir bei entsprechenden Fragen dann nicht genauso zur Seite stehen würden, wie wir das mit jedem anderen tun. Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der gewillt ist, was zu lernen, die Sachen erklärt.
Moby A. schrieb: > ein helligkeitsgesteuerter Tiny Du hast einen helligkeitsgesteuerten Tiny? Wow! Meine sind überhaupt nicht beleuchtet. mfg.
Ich kenne nur diese „helligkeitsgesteurten“ alten sowjetischen ICs. :)
Kinder, streitet Euch doch nimmer... Mir kommt das vor wie der Streit um den Bart des Kaisers. Wie man zum Ziel kommt kann an sich ganz interessant sein, aber, mir ist es ehrlich gesagt bei normalen, im Ablauf nicht superkritischen Kriterien konformen Applikationen eigentlich ziemlich wurscht wieviel Resourcen innerhalb eines vernünftigen Rahmens verbraucht werden solange allen Erfordernissen Geltung gegeben wurde und das uC Programm die gestellten Anforderungen einwandfrei erfüllt. Bei den modernen uC braucht man doch mit den Resourcen wirklich nicht mehr soo knausrig sein. Die Computersprache wurde ja nur für den Menschen erfunden und für den Mikroprozessor sind alles was über Maschinensprache hinaus geht, sowieso nur Hieroglyphen. Es ist ja beeindruckend wenn man alles mit den internen Register erledigen kann. Aber, does anybody really care very much? Ohne Moby hier auf die Füße steigen zu wollen. Wenn dem uC von seinem Erzeuger RAM gegeben worden ist, dann soll man es ruhig verwenden. Da ich oft nur wenig Zeit habe möchte ich möglichst schnell ans Ziel kommen. In C kann ich das viel besser wie in ASM, weil ich dort eben erschreckend rostig bin und es nur in Extremfällen in inline einsetze. Um ganz ehrlich zu sein, mir liegt ASM überhaupt nicht. Abgesehen davon ist für mich die Wiederverwendung von funktionierenden Funktionen in C einfacher und die Portierung von funktionierenden Code auf andere uC viel einfacher. Trotz aller (zu Tode diskutierten) nachgesagten Mängel der Sprache kommt man doch in C praktisch meist trotzdem ganz gut zurecht. Was ist schon perfekt in dieser Welt? In C fühlt man sich immer nahe genug an der Hardware und das reicht mir. Für wirklich komplizierte Anwendungen (Stacks) müssen natürlich andere Maßstäbe angelegt werden und ist der Domain für wirkliche Experten. Letzten Endes zählt nur die Erfüllung aller gesetzten Aufgaben mit vernünftigen Aufwand. Ehrlich gesagt finde ich man sollte diesen Thread hier ganz sanft und leise einschlafen lassen. Aber wie bei uns das Sprichwort sagt: "Opinions are like as...les, everybody's got one". So belassen wir es besser bei dem gesagten... Grüße aus dem verschneiten Alberta, Gerhard
M.: > Hat niemand behauptet. Das werden aber die gefùhlt 50 Zeugen ganz anders sehen, Herr Miemand! M.: > Mich interessiert doch tatsächlich das Thema Und von der Sorte gibt's hier viele. Nur wenn man sich ernsthaft für den Vergleich interessiert, dann braucht man zwei Dinge zum vergleichen. Wer sich nur über das Funktionieren der ASM-Version freut, dem fehlt die Vergleichsgrundlage. In C ist das einfacher. Da hat man nämlich auch die ASM-Version vorliegen (ja, oh Wunder, der Compiler erzeugt ASM-Code, den dann ein Assembler verlautbar für den kleinen AVR macht) und kann schnell feststellen, ob man da händisch noch viel rausholen kann. Setzt aber Mehrsprachigkeit voraus.
Jörg W. schrieb: > Ich kenne nur diese „helligkeitsgesteurten“ alten sowjetischen ICs. Wenn man ein EPROM falsch herum in den Programmiersockel steckt und das Programmiergerät genügend Puste hat, leuchten die auch. Erst weiss, dann rot, dann schwarz. Aber ein Tiny hat ja ga kein EPROM und beheizt wird er auch nicht. mfg.
Jörg W. schrieb: > Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz > gewiss die letzten, die dir bei entsprechenden Fragen dann nicht > genauso zur Seite stehen würden, wie wir das mit jedem anderen tun. > Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der > gewillt ist, was zu lernen, die Sachen erklärt. Zumal man ihm ja eigentlich gar nicht mehr so viel erklären müsste. Die AVR Hardware kennt er ja in und auswendig. Und Hand aufs Herz. So schwer ist ein
1 | DDRD = 0xFF |
dann auch wieder nicht zu verstehen. Links steht das Ziel, rechts was in dieses Ziel hinein soll. Was rechts stehen muss, weiss er ja. Das kennt er zur Genüge. Welches Register links stehen muss, die kennt er auch alle. Nur sollte man sich von der direkten Angabe von Hex-werten gerade bei der Konfiguration von Registern trennen, auch wenn man das in C selbstverständlich genausogut machen kann. Und trennen sollte man sich auch davon, die genau Kontrolle über diese Operation auf Registerebene zu verlangen. 0xFF landet im Register DDRD. Punkt. Wie das genau funktioniert ist Sache des Compilers. Will ich gar nicht wissen. Genausowenig wie ich wissen will, ob ich dafür einen OUT oder einen STS brauche. Das der Compiler da nicht übertreibt, und aus dem ein Monster macht, sondern genau dasselbe erzeugt, was auch Assembler Programmierer benutzen würde, davon kann man sich natürlich im Listing überzeugen. Aber nach dem 20 mal überzeugen, gibt man das einfach auf. weil der Compiler immer die vernünftigste Lösung generiert hat.
:
Bearbeitet durch User
Jörg W. schrieb: > Das ist ja aber das Gegenteil von „helligkeitsgesteuert“. Ja sicher. Das ist das Steuerelement. mfg.
Thomas E. schrieb: > Das ist das Steuerelement. Nur schade, dass man es nach jedem Steuervorgang ersetzen muss. :-)
Jörg W. schrieb: > Thomas E. schrieb: >> Das ist das Steuerelement. > > Nur schade, dass man es nach jedem Steuervorgang ersetzen muss. :-) Oh, und ich dachte schon, man stellt so OTP Speicher her...
Jörg W. schrieb: > Nur schade, dass man es nach jedem Steuervorgang ersetzen muss. Ja, das ist richtig. Das hat man aber hauptsächlich als Bombenzünder benutzt. Da relativiert sich der Nachteil. mfg.
:
Bearbeitet durch User
Gerhard O. schrieb: > Oh, und ich dachte schon, man stellt so OTP Speicher her... Nein. Aber auf diese Weise kann man OTPs löschen: OTE. mfg.
Thomas E. schrieb: > Das hat man aber hauptsächlich als Bombenzünder benutzt. Mensch, jetzt hast du diesen friedlichen Thread bei allein Drei-Buchstaben-Agenturen auftauchen lassen!
Thomas, War die Geschichte von Dir mit dem EPROM vielleicht nur ein Ablenkungsmanöver?
Jörg W. schrieb: > Mensch, jetzt hast du diesen friedlichen Thread bei allein > Drei-Buchstaben-Agenturen auftauchen lassen! Ich meinte Arschbomben. mfg. Hoffentlich kam das jetzt noch rechtzeitig.
Thomas E. schrieb: > Moby A. schrieb: >> ein helligkeitsgesteuerter Tiny > > Du hast einen helligkeitsgesteuerten Tiny? Da hab' ich doch glatt was vom "heiligkeitsgesteuerten Shiny" gelesen.
Moby A. schrieb: >> Wie er's braucht und ohne jede Scham beim Lügen. > > Die fehlt mir zum Beispiel bei Dir. Hör jetzt einfach mal auf mit dem Blödsinn. Du hast keine Argumente, du gehst nicht auf Gegenargumente ein, du verdrehst Aussagen, du tischst Lügen auf. Du bist zwar mittlerweile dazu über gegangen, deinen Gegnern das selbe zu unterstellen, aber das ist einfach Quatsch. Oder hast du das Gefühl, die Diskussionsteilnehmer würden sich das gegenseitig einfach so durchgehen lassen? Warum ist hier wohl alle-gegen-einen? Weil die Sache umstritten ist? Oder doch eher, weil wir aus welchen Gründen auch immer einfach Spass an einem Fast-Troll wie dir haben?
Langsam frage ich mich wie viele flames notwendig sind diesen war den politischen gleichzusetzen und ihn zu sperren sowie Fortsetzungen zu untersagen. an Sinnlosigkeit stellt und Resuorcenverschwendung sowie Beleidigungen hält er locker mit jedem Politthread mit. Namamste
:
Bearbeitet durch User
Wir brauchen einen Ersatz für den gesperrten Witz Thread ;-)
Thomas E. schrieb: > Das sind Fakten, denen nicht widersprochen werden kann Sagen wir mal so: Dein Asm Code wirkt etwas unflexibel ;-) Jörg W. schrieb: > Du würdest deine Entwicklungszeit > nämlich schätzungsweise zehnteln können, und dennoch passt das > alles noch ins gleiche Device rein. Sicher. Siichchcher. Sagte schon Hausmeister Krause! > Aber wie gesagt, das müsstest du schon wollen. Wir wären hier ganz > gewiss die letzten, die dir bei entsprechenden Fragen dann nicht > genauso zur Seite stehen würden, wie wir das mit jedem anderen tun. > Schau' dir mal an, mit welcher Engelsgeduld ein Karl Heinz jedem, der > gewillt ist, was zu lernen, die Sachen erklärt. Ganz hervorragend! Bitte weiter so! Kann man nicht hoch genug einschätzen! Ich selbst bin allerdings mit dem AVR, programmiert in Asm rundumst zufrieden und muß Problemstellungen nicht unbedingt komplizierter lösen als nötig. Gerhard O. schrieb: > Letzten Endes zählt nur die Erfüllung aller gesetzten Aufgaben mit > vernünftigen Aufwand. Das sehe ich auch so (mit AVR/ASM gegeben). Carl D. schrieb: > Nur wenn man sich ernsthaft für den Vergleich interessiert, dann > braucht man zwei Dinge zum vergleichen. Tatsächlich? Waren wir nicht schon soweit? Warum reite ich dann so auf der Notwendigkeit entsprechenden Vergleichsmaterials für meinen Projektcode herum? Der nicht kommt? Von den vielen großen C Experten hier für die das ein Leichtes sein könnte? > Wer sich nur über das > Funktionieren der ASM-Version freut, dem fehlt die Vergleichsgrundlage. Manchmal hat man, hab ich, auch Tomaten auf den Augen. Das betrifft aber weniger die Asm-Implementierung als vielmehr die grundsätzliche Herangehensweise an ein Problem, da wär kein Unterschied zu C. > In C ist das einfacher. Da hat man nämlich auch die ASM-Version > vorliegen (ja, oh Wunder, der Compiler erzeugt ASM-Code, den dann ein > Assembler verlautbar für den kleinen AVR macht) und kann schnell > feststellen, ob man da händisch noch viel rausholen kann. Setzt aber > Mehrsprachigkeit voraus. Wieviel Prozent der C-Programmierer dem resultierenden Asm-Code wohl noch Beachtung schenken?
Thomas E. schrieb: > Wenn man ein EPROM falsch herum in den Programmiersockel steckt und das > Programmiergerät genügend Puste hat, leuchten die auch. Erst weiss, dann > rot, dann schwarz. Aber ein Tiny hat ja ga kein EPROM und beheizt wird > er auch nicht. Logischer Fehler. Setzen. Sechs. Von Selbst-Leuchten war ja hier schon mal gar nicht die Rede ;-) Karl H. schrieb: > Und Hand aufs Herz. So schwer ist ein DDRD = 0xFF > dann auch wieder nicht zu verstehen. Das ist ja zuckersüß... Jo mei, wenn die C-Zeilen Welt immer so schön simpel wär ;-) > Genausowenig wie ich wissen will, ob ich dafür einen OUT > oder einen STS brauche. DAS will ich auch nicht. Entweder (meistens) weiß ich das sowieso und wenn nicht probiert man einfach erstmal OUT. Der Assembler meckert schon... Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr helfen... Winfried J. schrieb: > an ... Beleidigungen > hält er locker mit jedem Politthread mit. Meintest Du die Tausend Beleidigungen mir gegenüber oder meine Beleidigung der C-Fraktion, daß Asm-Code manchmal besser wär? Erstere sollte man nicht so in die Goldwaage legen. Die sind immer ein Ausdruck des 'Nicht mehr weiter Wissens' ;-) Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht ja nicht. Ich hoffe das bessert sich wieder!
Moby A. schrieb: > Wieviel Prozent der C-Programmierer dem resultierenden Asm-Code wohl > noch Beachtung schenken? Oh, den schau ich mir immer an wenn die Performance zu wünschen übrig lässt, mir die Ressourcen ausgehen oder trotz korrektem C das Kompilat einen Fehler enthält. Also eigentlich nie.
Moby A. schrieb: > Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den > Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir > mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr > helfen... "Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn helfen? Hilfst Du irgend jemandem im Forum, wenn er ein ASM-Problem hat? Ich lese hier nur selbstdarstellende Beiträge von Dir. P.S. Dir ist sowieso nicht zu helfen.
@ Moby wir beide haben zumindest gemein die Verachtung Anderer auf uns zu ziehen weil wir unseren jeweiligen Standpunkt konsequent vertreten. Deinen Standpunkt volle Programmablaufkontrolle auch die zeitliche durch direkte ASM Programmierung zu erreiche teile ich im übrigen auch. dies hat jedoch seinen Preis: Maschinennahe Programmierung erschwert die Übersichtlichkeit. Das lässt sich mit Macros zwar verbessern. Trotzdem bleibt es aufwendig. Die Effizienz des erzeugten Codes hängt im hohen Maße vom komplex logischen vermögen des Programmierers mit gleichzeitig hohem Abstraktionsvermögen ab. Hier bieten Hochsprachen Arbeitserleichterungen für den Programmierer. Zum Preis des Verstehens des vom Compiler erzeugten ASM durch den Hochsprachen Programmierer. Die Codeeffizienz eines lausigen Hochsprachenprogrammierers ist sicher noch größer als die eines mittelmäßigen ASM Fetischisten Nachdem HW heute billiger als SW-Entwicklungszeit (Programmiererlohn) ist ist ausgereizte ASM Programmierung schlicht zu teuer. Im Übrigen empfinde ich Hochsprachen bequemer und nutze sie im Bewusstsein, dass ich nicht jedes Byte kenne, welches der Compiler daraus bastelt, oder den genauen Ablauf einer Interpreterfunktion nicht kenne. Einen Blick in den erzeugten Compiler-Code oder eine Interpreterroutine ist allemal lehrreich. Namaste
Moby A. schrieb: > Ich selbst bin allerdings mit dem AVR, programmiert in Asm rundumst > zufrieden Moby A. schrieb: > Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, > daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an > Effizienz gewinne... Aha.
Moby A. schrieb: > Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, > daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an > Effizienz gewinne... Moby, da hilft nur Übung, Vorbereitung, System.
Moby A. schrieb: > Sagen wir mal so: Dein Asm Code wirkt etwas unflexibel Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken? Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich aus diesem nur einen einzigen Befehl verwende. Von der Kompaktheit des Codes und dem flankenschonenden und stromsparenden Takt ganz zu schweigen. Das Programm ist in jeder erdenklicher Weise höchstoptimiert und stellt somit Krone der Programmierkunst dar. Das ist die ideale Effizienz. Das sind die unwidersprochenen Fakten! mfg.
Und Moby macht einfach weiter, als wäre nichts gewesen. Obwohl Yalu in einem Beispiel nun wirklich UNZWEIFELHAFT nachgewiesen hat, dass man Assembler sogar bei Mini-Programmen mit C schlagen kann. Einfach nochmals, für die Nachwelt, damit nie jemand auf die Idee kommen wird, Moby's Theorien hätten auch nur ein Quäntchen Bedeutung:
1 | Mobys Asm-Code Yalus C-Code |
2 | ————————————————————————————————————————————————— |
3 | Flash-Verbrauch 266 256 |
4 | RAM-Verbrauch¹ 6 + 1 GPIOR 9 |
5 | Stack-Verbrauch 2 4 |
6 | Quellcodezeilen² 143 91 |
7 | Quellcodezeichen³ 1614 1707 |
8 | ————————————————————————————————————————————————— |
9 | ¹) ohne Stack |
10 | ²) ohne Leer- und Kommentarzeilen |
11 | ³) ohne Kommentare, Leerraum und Zeilenvorschübe |
12 | |
13 | Compiler: GCC 4.7.4 |
14 | Assembler/Linker: Binutils 2.25.1 |
15 | C-Standardbibliothek: AVR-Libc 1.8.1 |
Moby A. schrieb: > Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht > ja nicht. Wozu Gegenargumente? Haben wir hier in den letzten Tagen ein einziges Argument von Dir gesehen?
Moby A. schrieb: > Ok, allzu ergiebig war die fachliche (Gegenargument-)Ausbeute über Nacht > ja nicht. Ich hoffe das bessert sich wieder! - Obwohl du als Hobbyist gegen eine ganze Horde an erfahrenen Profis antrittst, - obwohl ein halbes Forum deiner Einzelmeinung geschlossen widerspricht, - obwohl du keine deiner Behauptungen belegen konntest, - obwohl klare Gegenbeweise gegen deine Thesen bestehen, - obwohl du einen Teil des Diskussionsgegenstands (Programmiersprache C) nicht mal kennst, => benimmst du dich immer noch so, als wärst du im Recht und die anderen auf dem Holzweg.
P. M. schrieb: ————————————————————————————————————————————————— > Flash-Verbrauch 266 256 > RAM-Verbrauch¹ 6 + 1 GPIOR 9 > Stack-Verbrauch 2 4 > Quellcodezeilen² 143 91 > Quellcodezeichen³ 1614 1707 > ————————————————————————————————————————————————— > ¹) ohne Stack > ²) ohne Leer- und Kommentarzeilen > ³) ohne Kommentare, Leerraum und Zeilenvorschübe > > Compiler: GCC 4.7.4 > Assembler/Linker: Binutils 2.25.1 > C-Standardbibliothek: AVR-Libc 1.8.1 Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert.
le x. schrieb: > Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features > bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert. Ein echter Nachteil von C. Durch die bessere Lesbarkeit können auch untalentierte Programmierer nun guten Code schreiben was langfristig zu schlechteren Programmierern führt. (Im Sinne von ASM Verständniss) Zudem werden die Produktzyken kürzer weil gute Produkte schneller entwickelt sind. Die Menschen gewöhnen sich daran das fette Features schnell und zahlreich zu etabieren sind und schrauben ihre Erwartungshaltung ständig höher. Das wiederum ist ein echtes Ressourcen / Umweltproblem. Nur durch kurzlebige Modeerscheinungen wie Hochsprachen ist es überhaupt möglich geworden ständig neue MCUs auf den Markt zu werfen. Hardcore ASM Götter würden freiwillig nicht so schnell wechseln. Dadurch das nun viele etwas können was vorher wenigen vorbehalten war wird auch die Bezahlung schlechter. Hochsprachen sind ausserdem eine Bedrohung für Frieden und Freiheit. Weder flächendeckende Kommunikationsüberwachung, noch Gesichtserkennung, Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät wäre in der Form denkbar. Hochsprachenprogrammierer sind Diener des Bösen. Zwangsläufig wird die Gesellschaft sich davon befreien müssen indem selbige nach nordkoreanischem Vorbild umerzogen werden. Innovative deutsche Unternehmen haben das bereits erkannt und gerade noch rechtzeitig ihren Betrieb eingestellt (Addison Wessley, Data Becker) [Die heutige Bücherverbrennung wird Ihnen präsentiert von: O'Reilly)
Michael K. schrieb: > le x. schrieb: > Ein echter Nachteil von C. > Durch die bessere Lesbarkeit können auch untalentierte Programmierer nun > guten Code schreiben was langfristig zu schlechteren Programmierern > führt. > [...] > Das wiederum ist ein echtes Ressourcen / Umweltproblem. > [...] > Hochsprachen sind ausserdem eine Bedrohung für Frieden und Freiheit. > Weder flächendeckende Kommunikationsüberwachung, noch Gesichtserkennung, > Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät > wäre in der Form denkbar. > [...] Rettet die Welt, Programmiert ASM :^)
Michael K. schrieb: > Dadurch das nun viele etwas können was vorher wenigen vorbehalten war > wird auch die Bezahlung schlechter. Zum Glück trifft das nicht auf die echten ASM-only-Programmierer zu. Diese Helden, die sich ihren Fokus nicht durch die Verlockungen der Hochsprachen-Sirenen haben verwässern lassen, sind heute in der Industrie gefragte Experten, die locker mit dem Doppelten eines Durchschnittsgehalts rechnen dürfen. Gruß, Stefan
Michael K. schrieb: > Zudem werden die Produktzyken kürzer weil gute Produkte schneller > entwickelt sind. Eben. In Assembler programmiert würde Microsoft nicht immer wieder die Benutzeroberfläche auf den Kopf stellen und die Hälfte aller Knöpfe neu verteilen. Es wäre eine Wohltat für viele Anwender. ;-)
:
Bearbeitet durch User
Stefan K. schrieb: > sind heute in der > Industrie gefragte Experten, die locker mit dem Doppelten eines > Durchschnittsgehalts rechnen dürfen. Dafür aber die 10-fache Entwicklungszeit benötigen und somit locker das zwanzigfache pro Programm verdienen. Asm-Effizienz in höchster Vollendung. mfg.
A. K. schrieb: > Eben. In Assembler programmiert würde Microsoft nicht immer wieder die > Benutzeroberfläche auf den Kopf stellen und die Hälfte aller Knöpfe neu > verteilen. Es wäre eine Wohltat für viele Anwender. ;-) Womit wir uns auch mal um den Blödsinn der hochauflösenden Farbmonitore kümmern sollten. Eingabefelder und Schieberegler sind seit Win 10 bei meinem billigst Notebook fast nicht zu erkennen. So ein Problem hatte ich auf meinem C64 mit dem Bernsteinmonitor nie. Dieser ganze neumodische Schnickschnack hat doch mit diesem Tesla angefangen und seiner Schnapsidee alle Haushalte zu bestromen. Seit dem nur noch Hektik, Zeitdruck und arbeiten bis spät in die Nacht. Probleme lösen die wir ohne Computer garnicht hätten. Vorher: Rentervorsorge? Ich bitte Dich, bei der Lebenserwartung ? Schlafen wenn die Sonne untergeht, aufstehn wenn der Hahn kräht. Moby hat das zugrunde liegende Problem gut erkannt, er setzt nur viel zu spät an. Die Kontrolle hätten wir behalten wenn wir nie von den Bäumen runtergekommen wären. Ach was sage ich da, der Molch war doch in unserer Evolution die glücklichste aller Daseinsformen. Kein Stress und zu blöd sich Sorgen darum zu machen das man gefressen werden könnte. Ressourcenverbrauch ? Da schneidet der Molch aber um Welten besser ab. Wenn ich sehe was wir mit unserm ach so tollen Gehirn anstellen das weit überdurchschnittlich viel Energie verbraucht, so ist dieser Thread das beste Beispiel dafür das der Molch uns da klar überlegen ist.
Frank M. schrieb: > Moby A. schrieb: >> Aber vielen Dank K.H. für Deine Hilfsbereitschaft. Ich meine, den >> Charakterzug weiß ich ja durchaus zu schätzen. Allein, Du würdest mir >> mit einem besseren Vergleichscode zu meinem Projekt wesentlich mehr >> helfen... > > "Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn > helfen? Hilfst Du irgend jemandem im Forum, wenn er ein ASM-Problem > hat? Das wiederrum ist interessanterweise eine Eigenschaft, die er mit den restlichen Assembler-über-alles Verfechtern teilt. Wenn es um ein Assembler Problem geht, glänzen sie so gut wie fast immer .... durch Abwesenheit.
le x. schrieb: > Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features > bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert. @P.M.: Kannst du das bitte in das täglich zu wiederholende Posting (Murmeltier) mit aufnehmen? Danke.
Michael K. schrieb: > Drohnen, Marschflugkörper oder sonstiges moderne militärische Fluggerät > wäre in der Form denkbar. Der erste Marschflugkörper kam völlig ohne Programm aus. Der hatte keinen einzigen Transistor drin, vielleicht nicht einmal Röhren.
:
Bearbeitet durch User
A. K. schrieb: > vielleicht nicht einmal Röhren. oh doch der wurde über einen Funkleitstrahl analog auf Kurs gehalten https://de.wikipedia.org/wiki/Präzisionsgelenkte_Munition#Flugbahnlenkung besser noch hier https://de.wikipedia.org/wiki/Fieseler_Fi_103#Zielf.C3.BChrung auch interessant in diesem zusammenhang https://de.wikipedia.org/wiki/Fritz_X Namaste
:
Bearbeitet durch User
Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden. A.K. ist vom Glauben abgefallen: Beitrag "Re: Eigenes Dev. Board für vintage CPU bauen" A. K. schrieb: > Ausserdem kann man beim 1802 leichter als irgendwo sonst auf total > überflüssige Hochsprachen wie Makro-Assembler verzichten und direkt in > Hex programmieren. Liest sich in kurzer Zeit fast genauso gut wie > normaler Assembler. A.K. es ist noch nicht zu spät. Kehre zurück auf den Pfad der Tugend und schwöre ab den falschen Propheten.
Michael K. schrieb: > Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden. > A.K. ist vom Glauben abgefallen: Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-)
Frank M. schrieb: > Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der > Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht > flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-) Ging mir ähnlich beim 6502: Der Apple hatte in seinem Monitor-ROM zwar einen einfachen Disassembler, aber keinen Assembler. Bei typischen 8-Bit-Anwendungen tippte man deswegen das Programm einfach als Hexcodes ein und überprüfte anschließend deren Richtigkeit mit dem Disassembler. Innerhalb kurzer Zeit kannte ich die Hexcodes für 90% der Befehle auswendig, den selten genutzten Rest¹ musste ich halt nachschlagen. Da ich irgendwann aber auch nichttypische 8-Bit-Anwendungen (d.h. mit mehr als 200 Bytes) programmieren wollte, kaufte mir dann aber doch einen Assembler. Selbst die komplizierteren 16-Bit-Opcodes des 68000 konnte man sich gut merken, da sie größtenteils nach einem einheitlichen Schema aufgebaut sind. Da die Quell- und Zieladdressierungsart und -register von rechts her jeweils als 3-Bit-Gruppen kodiert sind, nutzte man statt der hexadezimalen die oktale Schreibweise. Auch damit hatte ich einige Progrämmchen geschrieben, die ich aber nicht als "typische 16-Bit- Anwendungen" bezeichnen würde ;-) ———————————— ¹) Nein, Moby, der EOR-Befehl zählte nicht zu diesem Rest, der war unter den 90% häufig genutzten Befehlen ;-)
Frank M. schrieb: > Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der > Opcodes als Hex-Zahlen erstellt. Mit ein wenig Übung geht das recht > flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-) Ist aber bei 8080-Code einfacher als bei optimiertem Z80-Code. Die Rechnerei der relativen Sprünge ist ziemlich umständlich. Das ist das schöne am 1802, der hat zwar kurze Sprünge, aber ohne umständliche Rechnung. Da wird bloss das untere Byte der Programmadresse ersetzt. Gegenüber der Oktalcodierung von 8080 besteht zudem der Vorteil, dass etliche Befehle hexcodiert aufgebaut sind. Also 4-Bit Opcode und 4-Bit Registernummer. Einfacher gehts nicht.
:
Bearbeitet durch User
A. K. schrieb: > Die Rechnerei der relativen Sprünge ist ziemlich umständlich. Das stimmt, aber die absoluten des 8080 gab's ja trotzdem noch, insofern erstmal kein Nachteil. Habe aber inzwischen fast alle vergessen. Kann mich nur noch an AF und 21 xx xx erinnern. ;)
Einen kleinen Nachteil der Hex-Programmierung des 1802 muss ich aber noch erwähnen: Nirgends hat man so viel Sex wie in 1802 Assembler Programmierung. In Hex verschwindet der völlig aus den Augen. http://www.atarimagazines.com/computeii/issue3/page52.php
:
Bearbeitet durch User
Karl H. schrieb: > Und Hand aufs Herz. So schwer ist ein DDRD = 0xFF > dann auch wieder nicht zu verstehen. Hmmm lass mal überlegen... Moby A. schrieb: > Das ist kryptischer Kauderwelsch für Eingeweihte. > Dessen Studium ist für 8-Bit MSR überflüssig ;-)
le x. schrieb: > P. M. schrieb: > ————————————————————————————————————————————————— >> Flash-Verbrauch 266 256 >> RAM-Verbrauch¹ 6 + 1 GPIOR 9 >> Stack-Verbrauch 2 4 >> Quellcodezeilen² 143 91 >> Quellcodezeichen³ 1614 1707 >> ————————————————————————————————————————————————— > > Man sollte vielleicht noch erwähnen dass Yalu's Lösung mehr Features > bietet, wirklich erweiterbar ist und besser lesbar/dokumentiert. Schon erstaunlich was man aus -10 Bytes alles herausholen kann ;-)
Frank M. schrieb: > Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der > Opcodes als Hex-Zahlen erstellt. Na gut, dann muß ich beichten das ich das beim 8085 ebenso gemacht habe. Man hatte ja keinen Vergleich und hat sich deswegen über jeden Befehl gefreut der ausgeführt wurde. Aus heutiger Sicht so spannend wie Lack beim trocknen zuzusehen. Der 8031 war dagegen wie Balsam auf meine wunde Seele. Timer, Ram, Uart alles in einem Chip. Nur noch Eprom und A/D Latch ran und es lief (naja + ein paar Bauteile) Das war so schön, ich hätte weinen können. Der 8751 war mein größter Schatz und sein Gewicht in Gold wert. 4K on Chip ! Der brutale Wahnsinn. Der 8085 endete quasi sofort als Türstopper. Heute empfinde ich das als Zumutung wenn ich mehr als 30Cent ausgeben muß für so eine kleine Gurke und dann auch noch mehr brauche als zwei Kerkos um damit was zu machen. Flash, ISP, OCD sind so selbstverständlich das ich erst solche Threads brauche um mich an all die Klimmzüge und Leiden zu erinnern die damals selbstverständlich waren. Warum man die Hardwaresegnungen der 'neuen Zeit' mitnimmt aber sich softwaremäßig (ASM) nicht weiterentwickelt kann ich persönlich nicht nachvollziehen.
Frank M. schrieb: > Michael K. schrieb: >> Ich muß einen schnöden Verrat an unseren C Prinzipien vermelden. >> A.K. ist vom Glauben abgefallen: > > Wieso? Ich hab in den 80ern auch Z80-Programme direkt durch Eingabe der > Opcodes als Hex-Zahlen erstellt. Was seid ihr denn für Wappler? :-) Mein erster Z80 Eigenbau bekam sein erstes Programm
1 | 0xxxxx 0x76 HALT |
indem ich mit Drahtbrücken im EEPROM Sockel den Befehl direkt am Datenbus gesteckt habe. Der Chip Select Adressdecoder war noch nicht fertig :-) Ich war stolz wie nachbars Lumpi, als das (geschenkte) Phillips Voltmeter am Halt Pin den Zeiger nicht bewegte, während es bei einem gesteckten
1 | 0xxxxx 0x00 NOP |
brav mit einem Ausschlag die 5V vermeldete. > Mit ein wenig Übung geht das recht > flüssig. Assembler? Quatsch, Luxus, den man nicht braucht :-) Ja doch das ging schon. Das einzige bei dem ich am Anfang immer Probleme hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie?
:
Bearbeitet durch User
Michael K. schrieb: > Heute empfinde ich das als Zumutung wenn ich mehr als 30Cent ausgeben > muß für so eine kleine Gurke und dann auch noch mehr brauche als zwei > Kerkos um damit was zu machen. Vor allen Dingen kein potentes Netzteil mehr :-) Mit einem nackten Z80, bisschen Kleinkram rundum und eben das übliche (EPROM, RAM, 8255, 8251), war man mit einem 1A Netzteil auf der 5V Schiene nicht wirklich krass überdimensioniert. :-)
:
Bearbeitet durch User
Karl H. schrieb: > 0x0000 0x76 HALT Muss das nicht
1 | 0000H 076H HALT |
heißen? ;-) Nein, einen EPROM hatte ich schon zu Anfang. Allerdings natürlich keinen LA, mit dem man die Verdrahtungsfehler hätte suchen können, nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und Adressbus). Zum schrittweisen Durchschalten hab' ich mir dann eine kleine Hardwaremimik gezimmert, die nach je einem Befehl immer wieder /WAIT gezogen hat. Nach ein oder zwei Stunden war dann der Kurzschluss auf einem der Busse gefunden. Das Lösen des Henne-und-Ei-Problems für die ersten EPROMs benötigte allerdings einen in Hardware gezimmerten Eprommer. Wehe dem, man hatte sich bei einem der Bytes beim Eingeben vertan, dann musste man von vorn anfangen. Computergesteuerten Eprommer habe ich dann erst später gebaut. Passend zum Thema des Threads: dessen Bediensoftware wurde in Turbo-Pascal geschrieben. Dadurch ließ sich doch einiges an Bedien-Komfort mit vertretbarem Aufwand erreichen, was ich mir hätte bei reiner Assemblerprogrammierung nicht antun wollen. Nur die innerste Schleife habe ich nach dem initialen Funktionstest dann in Inline-Assembler nachprogrammiert, damit er schnell genug wurde.
Karl H. schrieb: > Was seid ihr denn für Wappler? :-) Moment ..... https://de.wiktionary.org/wiki/Wappler Aha ! Karl H. schrieb: > Das einzige bei dem ich am Anfang immer Probleme > hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie? Da hilft nur: Übung, Vorbereitung, System
Jörg W. schrieb: > Karl H. schrieb: >> 0x0000 0x76 HALT > > Muss das nicht > >
1 | 0000H 076H HALT |
> > heißen? ;-) Mea Culpa. Da hat wohl die C-Bürokratie die Oberhand gewonnen. > Nein, einen EPROM hatte ich schon zu Anfang. Allerdings natürlich > keinen LA, War ja auch unbezahlbar für einen Studenten. Die 100 Mark wurden lieber in ein paar kB Speicher investiert. > mit dem man die Verdrahtungsfehler hätte suchen können, > nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und > Adressbus). Nobel. Ich hatte Glück. Meinen Z80 konnte ich mit einer LED (und einem Durchgangsprüfer, gebaut aus einem alten Texas Instruments Akkufach + LED + 220 Ohm + Draht) in Betrieb nehmen und verifizieren, dass er funktioniert. > Das Lösen des Henne-und-Ei-Problems für die ersten EPROMs benötigte > allerdings einen in Hardware gezimmerten Eprommer. :-) Das war ein echtes Problem. In der mc gab es einen Eprommer, der im Prinzip nur ein Schieberegister war. An sich super. Nur, wie ansteuern, wenn der Rechner noch nicht läuft. Ein Kumpel mit einem TRS80 hat mir dann aus der Patsche geholfen. > erst später gebaut. Passend zum Thema des Threads: dessen > Bediensoftware wurde in Turbo-Pascal geschrieben. Das hatte wohl jeder. D.h. sofern er sich ein Floppy Laufwerk leisten konnte und unter der Hand ein CP/M irgendwo herbekam :-)
Karl H. schrieb: > D.h. sofern er sich ein Floppy Laufwerk leisten konnte Welch ein Luxus. Dump über die serielle Schnittstelle auf ein 1200er Modem und die frequenzmodulierten Daten mit einem Kassettenrekorder aufgezeichnet. Das war cool. mfg.
:
Bearbeitet durch User
Karl H. schrieb: > Mea Culpa. Da hat wohl die C-Bürokratie die Oberhand gewonnen. Ja, da kannst du sehen, wohin diese Bürokratie noch führt! >> nur einen einfachen Busanalysator (7-Segment-Anzeigen für Daten- und >> Adressbus). > > Nobel. Die Anzeigebaugruppe wurde auch am Primitiv-Eprommer genutzt. Sie bestand aus einer VQD30: http://www.pollin.de/shop/dt/MDY3OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LED_Display_VQD30.html einem BCD-7-Segment-Decoder (U40511, der hat auch die Hex-Zahlen korrekt angezeigt) und Multiplexern, mit denen reihum die Busse abgefragt wurden. >> erst später gebaut. Passend zum Thema des Threads: dessen >> Bediensoftware wurde in Turbo-Pascal geschrieben. > > Das hatte wohl jeder. D.h. sofern er sich ein Floppy Laufwerk leisten > konnte und unter der Hand ein CP/M irgendwo herbekam :-) Naja, Software war in der DDR kein Problem :), die wurde ja auch ganz offiziell von robotron als Clone vertrieben. Beliebt war die CP/A genannte Version des Instituts für Informatik an der Akademie der Wissenschaften. Irgendwoher bekam man da auch ein Turbo-Pasal, auf welchen Wegen die genau von Diskette zu Diskette gefunden haben, hat damals hier keinen interessiert … Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB), sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte.
Jörg W. schrieb: > Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB), > sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte. Krösus :-) Ich hatte mir als Österreicher in München 2 Floppy Laufwerke erstanden. Haben ein Schweine-Geld gekostet. Da kriegst heute einen ganzen PC drum, und dann bleibt noch was übrig. Mann war ich sauer, als mir beim Basteln das Krokoklemmenkabel abgeschnippt ist. Blöderweise war es die GND-Leitung und das freie Ende fiel auf die 230V Phase. Und vorbei wars mit den Laufwerken ... und dem VT100 ... und überhaupt dem meisten in der als Gehäuse benutzen Holzkiste. Eines der Laufwerke konnte ich noch retten, in dem ich auf einem defekten IC (war irgendeine Gatter-Sache) einen weiteren IC huckepack aufgeklebt und mit Fädeldraht angeschlossen habe. Aber das 2.te machte keinen Mucks mehr. :-) Und ich brings trotzdem nicht übers Herz, den 30 Jahre alten Krempel zu entsorgen. :-)
:
Bearbeitet durch User
Karl H. schrieb: > Und ich brings trotzdem nicht übers Herz, den 30 Jahre alten Krempel zu > entsorgen. Moby auch nicht ;-)
Thomas E. schrieb: > Karl H. schrieb: >> D.h. sofern er sich ein Floppy Laufwerk leisten konnte > > Welch ein Luxus. > > Dump über die serielle Schnittstelle auf ein 1200er Modem und die > frequenzmodulierten Daten mit einem Kassettenrekorder aufgezeichnet. > Das war cool. Das war auch schon so ziemlich das einzige, was ich nie gemacht habe. Hätte mit meinem 300 Baud Eigenbau Akustikkoppler auch nicht so wahnsinnig toll funktioniert. Obwohl - wieso hab ich das eigentlich nie ausprobiert?
Karl H. schrieb: >> Diskettenlaufwerk hatte ich erst sehr spät, aber massig RAM (384 KiB), >> sodass ich zwei „RAM-Floppies“ von 120 und 200 KB hatte. > > Krösus :-) Zusammengestoppelt. Schließlich kamen die Dinger initial aus dem ZMD in Dresden ;), es sind noch welche dabei, die nicht mit dem später offiziellen Etikett „U2164“ versehen sind, sondern „U264“. Es sind aber auch auf der zweiten Platine offizielle Erfurter ICs drauf, die es dann später preiswert als so genannte Bastlerware (2. Wahl) gab. Aufgrund der vielen völlig verschiedenen Bauteile funktionierten allerdings die „gängigen“ RAS-CAS-Ansteuerschaltungen auf der Basis irgendwelcher Gatterlaufzeiten nicht bei diesem Mix. Ich bin erst glücklich geworden, als ich einen definierten RAS-CAS-Versatz mit dem vierfachen CPU-Takt (der zugleich Videotakt war) und einem Schieberegister eingebaut hatte. Danach liefen die dRAMs stabil. Das Desaster mit dem runtergefallen Kabel ist natürlich tragisch. In solch trauriger Dimension ist es mir zum Glück erspart geblieben.
Thomas E. schrieb: > Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken? > > Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich > aus diesem nur einen einzigen Befehl verwende. Von der Kompaktheit des > Codes und dem flankenschonenden und stromsparenden Takt ganz zu > schweigen. > > Das Programm ist in jeder erdenklicher Weise höchstoptimiert und stellt > somit Krone der Programmierkunst dar. > > Das ist die ideale Effizienz. Das sind die unwidersprochenen Fakten! Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können. Damit hättest Du sogar den Mikrocontroller gespart!
Sheeva P. schrieb: > Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier > Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können. > Damit hättest Du sogar den Mikrocontroller gespart! ist aber nicht 8Bit MSR konform.
Thread beobachten
Seitenaufteilung abschalten