le x. schrieb: > Über ein Array von ADC-Messwerten (10 Bit) iterieren und den kleinsten > Wert heraussuchen. Das ist doch kein 8bit MSR. Ausserdem kann man sowas als externes Modul dazukaufen.
Moby A. schrieb: > Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen > werde. Das hat niemand erwartet. Von nichts kommt einfach nichts. Das ist jedem hier klar. > Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die > bloße Register-Initialisierung noch nicht die großen Unterschiede > bringt. Nur geht es nicht nur um die blosse Registerinitialisierung. Aber das kannst du ja auch nicht wissen. > Eher ist da der bürokratische Aufwand, veranschaulicht im > Quelltext interessant. Den Quelltext wirst du nicht zu sehen bekommen. Wozu auch? Verstehst es ja ohnehin nicht. > Immerhin hast Du den in Deinem Nonsens-Beispiel gut herausgearbeitet Nonsens nennst du das jetzt. Mal sehen, was als nächstes kommt, um von deinen Unzulänglichkeiten, effizienten Asm-Code zu produzieren, abzulenken. Dieser Code funktioniert. Er macht exakt das, was er soll. Und das mit absoluter Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Da kommst du mit deinem Dödelprogramm nur nicht im entferntesten heran. Das ärgert dich natürlich. [deletia] mfg.
:
Bearbeitet durch Moderator
Moby A. schrieb: > P. M. schrieb: > >> Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst >> erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich >> weitgehend einig > > ... daß sich Assembler im umrissenen Einsatzgebiet nicht schlagen lässt, > meinst Du? Die C-Koryphäen schleichen wie Katzen um den heißen Brei > meines Projekts und keiner traut sich. Woran es allerdings nicht fehlt > ist allerlei Smalltalk und Ausreden so wie diese hier: > >> kann sie auf einschlägige Erfahrung >> verweisen > >> Wobei sie natürlich definiert, was >> widerlegt heisst > > Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar: > Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität. > Am Ende siegt aber dann doch die Angst ;-) Ja Moby. Die C-Koryphäen sind mit ihrem Latein nun am Ende. Dafür sind aber wissenschaftliche Einrichtungen an deutschen Hochschulen und Universitäten auf dein geniales Schaffen aufmerksam geworden und widmen nun ihre Forschungen in deine Richtung. Außerdem munkelt man in Fachkreisen, dass dein genialer Code verfilmt werden soll. Bekannte Kurzfilmkoryphäen schlagen sich um das Drehbuch, welches nur 5 Seiten hat! Die Filmmusik wird der geniale A.S. Melchior komponieren. Er kommt mit nur 5 Tönen und 2 Instrumenten aus. Koreographen arbeiten mit Hochdruck an einem Ballett, in dem nur dein Code Einbeinigen getanzt von wird. Eine ganz große C-Koryphäe wird sich deinen Code sogar auf sein bestes Stück tätowieren lassen. Von der Länge passt er zum Glück! Alter, du bist mein Held. Mit so einer wahnsinns Portion Selbstüberschätzung lebt es sich doch einfach prima. Nur leider interessiert dein Code hier niemand mehr. Warum wohl? Denk mal darüber nach.
:
Bearbeitet durch User
Moby A. schrieb: > Mir > gehts nur um den Vergleich von Asm vs. C. Warum? Bist du nicht mehr glücklich mit Asm? Für dich und deine Anwendungen ist doch ASM genau das Richtige. Du beherrscht es, dein Programm läuft und der Hochsprachenlernaufwand lohnt dafür wirklich nicht. Ähm, worum geht es in dem Thread noch mal?
Witkatz :. schrieb: > Ähm, worum geht es in dem Thread noch mal? „Assembler auf dem Weg nach vorn“ – auch wenn es halt nur durch eine andere Wortwahl bei den Suchbegriffen ist. ;-)
Jörg W. schrieb: >> Ähm, worum geht es in dem Thread noch mal? > > „Assembler auf dem Weg nach vorn“ – auch wenn es halt nur durch eine > andere Wortwahl bei den Suchbegriffen ist. ;-) Ach ja, danke. Assembler, ach was waren das für entschleunigte Zeiten... ;-) Ich glaube, heute ist das was für Puristen und man muss es einfach lieben, so wie Naked Bikes und Oldtimer. Vielleicht ist an der Statistik wirklich was dran und es deutet sich ein nostalgischer Modetrend für Assembler und vergessene CPU's an?
:
Bearbeitet durch User
Angehängte Dateien:
-
asMusical.jpg
61 KB
Markus M. schrieb: > Koreographen arbeiten mit Hochdruck an einem Ballett, in dem nur dein > Code Einbeinigen getanzt von wird. Hamburg ist bereit. mfg.
Witkatz :. schrieb: > Warum? Bist du nicht mehr glücklich mit Asm? Für dich und deine > Anwendungen ist doch ASM genau das Richtige. Du beherrscht es, dein > Programm läuft und der Hochsprachenlernaufwand lohnt dafür wirklich > nicht. > > Ähm, worum geht es in dem Thread noch mal? Warum sollte bloß ich damit glücklich werden? Warum sollte ich meine Aussage nicht mit Code beweisen dürfen? Thomas E. schrieb: > Da kommst du mit deinem Dödelprogramm nur nicht im entferntesten heran. > Das ärgert dich natürlich. Warum denn? Das würde ja zumindest mal den gleichen Funktionsumfang voraussetzen. Da bist Du weit entfernt von ;-) Markus M. schrieb: > Nur leider interessiert dein Code hier niemand mehr. > Warum wohl? Denk mal darüber nach. Weil er sich mit C nicht toppen läßt vielleicht? Thomas E. schrieb: > Hamburg ist bereit. Klasse! Witkatz :. schrieb: > Vielleicht ist an der Statistik wirklich was dran und es deutet sich ein > nostalgischer Modetrend für Assembler und vergessene CPU's an? Dafür wurde eine halbwegs plausible Erklärung längst geliefert! Markus M. schrieb: > Ja Moby. Die C-Koryphäen sind mit ihrem Latein nun am Ende. Dafür sind > aber wissenschaftliche Einrichtungen an deutschen Hochschulen und > Universitäten auf dein geniales Schaffen aufmerksam geworden und widmen > nun ihre Forschungen in deine Richtung. Du übertreibst meine Ambitionen. So wie Übertreibung hier eines der beliebtesten Stilmittel gedemütigter C-Koryphäen ist ;-) Wieder mal nur Lächerlich-Machen statt harter Fakten. Der oft frequentierte Notausgang aus der Manege ;-)
le x. schrieb: > Allerdings ist die C-Zeile aber auch vielfach mächtiger. Aber die Komplexität der Ausdrücke! Aber die Kryptizität der Ausdrücke! > Wie bewertest du also "Bürokratie"? Anzahl der Zeilen? Anzahl der > Spalten? Anzahl der Zeichen? Bürokratie= Gesamtheit des Sprachumfangs, Regeln, Vorschriften, Typen, Operatoren, Deklarationen usw. > Oder war "Bürokratie" bei dir das Angeben-müssen von Datentypen? > Nun, dieses "Argument" hab ich dir ja schon mal demontiert. Demontage? Was für ein großes Wort für dieses überflüssigste aller überflüssigen Konstrukte! Mein absoluter Liebling: Der Cast-Operator! Von der Abbildung konkreter Projekt-Notwendigkeiten soweit entfernt wie eine Galaxie im Dark Field. > Und, das Format heutiger Bildschirme im Hinterkopf, was machst du > eigentlich mit dem ganzen Platz links und rechts vom Listing?! Vermutlich fühlst Du Dich schlecht wenn da nix mehr zu lesen ist. Ist das eine unangenehme Leere? In Asm passen ggf. noch schöne Kommentare hin!
Moby deine Kommentare über C hören sich so ähnlich an wie: Feuer zu machen mit einem Feuerzeug ist so Komplexität und Kryptisch da kann man an einem Regler die Flammengröße einstellen und man muss noch auf einen Knopf drücken und kann sich sooo schnell verbrennen. Ich bleibe bei meinem Feuerstein, da hab ich die Funkenbildung noch selbst im Griff.
P. M. schrieb: > Ich identifiziere mindestens 5 Punkte in diesem Satz, die lang und breit > widerlegt wurden. Wo in der Fachwelt nun wirklich keine Zweifel mehr > bestehen. Cool, wie Du für die Fachwelt sprichst. Cool, wie Du mir die Fachwelt um die Ohren haust. Leider seh ich für den umrissenen Einsatzbereich rein gar nichts widerlegt! > Du hingegen erfindest ein absurdes Netz an Bedingungen, die erfüllt sein > müssen Erfüllt sein muß gar nichts außer von 100% Funktion. Schon mal gar nicht im Hobby. Darum gehts hier aber nicht. > Merkst du eigentlich nicht, wie dumm und > hinderlich das für dich selbst ist? Ganz und gar nicht. Die Arbeit und das praktische Ergebnis meiner Projekte beweisen mir jeden Tag das Gegenteil ;-)
Markus M. schrieb: > Ich bleibe bei meinem Feuerstein, da hab ich die Funkenbildung noch > selbst im Griff. Ich bleibe bei dem was für die konkrete Aufgabenstellung am einfachsten ist. Das kann ggf. auch eine Blink-LED sein ;-) > M oby's > S imply > R esults
Carl D. schrieb: > Wenn ich jetzt verraten würde, daß ich für MSR-Anwendungen im > Hausbereiche gerade JavaScript und Lua evaluiere, dann würde ich auf den > ASM-Scheiterhaufen geführt werden. Aber so hab ich Web und Logging und > graphische Verknüpfung (node-red) und das alles Dank V8-Engine in > Compiler-Speed. Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt bist? Für MSR-Anwendungen im Hausbereich? Wenn aber etwas schnell fertig werden soll und Du mit Lua vertraut bist- warum nicht. Das berührt die Diskussion Asm vs. Hochsprache in punkto Ressourceneinsparung und Effizienz aber in keinster Weise. Jonny O. schrieb: > Ich glaube du unterschätzt den Begriff "MSR" erheblich. Nein. Ich rede hier von 8-Bit MSR für datenarme und weniger rechenintensive Anwendungen. Das es da viel mehr + anspruchsvolleres und auch die Berechtigung für Hochspracheneinsatz (ggf. auf höherbittigen MCs) gibt streitet doch niemand ab ! > Jedenfalls ist > die Reglungstechnik eine Wissenschaft für sich und der Komplexitätsgrad > kann bei weitem "kleine Tiny-Sachen" übersteigen. Durchaus auch im > Hobbybereich. Im Hobbybereich? Aber sicher. Fürs SmartHome reicht 8-Bit MSR aber locker aus. Wenn in Zukunft mehr Intelligenz in die If/Then Abläufe reinkommt möglicherweise nicht mehr. Aber die IOT Auswertung soll sich ja dann längst auf Servern im Netz abspielen. MSR in Sensor/Aktorknoten wird sich nicht wesentlich ändern. > Ich denke du stellst dir unter MSR immer etwas Simples vor. Das mag hie > aber es gibt viele Anwendungen, da ist ein Cortex > sinnig. Kein Thema.
Moby A. schrieb: > Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt > bist? ... Moby A. schrieb: > Aber die IOT Auswertung soll sich ja dann längst auf Servern im Netz > abspielen. Jaja, die noch mehr Stromschluckende Hardware GRINS Moby A. schrieb: > Ich rede hier von 8-Bit MSR für datenarme und weniger > rechenintensive Anwendungen. Und wieso sollte man für solche Anwendungen überhaupt sich die Mühe machen das in Assembler mit maximaler Effizienz zu gestalten? KOPFSCHÜTTEL Ich habe immer noch nicht verstanden wieso ich Assembler lernen sollte, wo ich doch schon C kann.
Moby A. schrieb: > Warum sollte bloß ich damit glücklich werden? > Warum sollte ich meine Aussage nicht mit Code beweisen dürfen? Deine Aussage ist einzig und allein, dass man für eine simple Steuerungsaufgabe keine Hochsprache lernen muss. Dein Code funktioniert und du hast es bewiesen. Warum reicht dir das nicht?
Markus M. schrieb: > Moby A. schrieb: >> Womit Du vermutlich auf stromschluckende, größere Hardware festgelegt >> bist? Jaja, schönes Argument den Stromverbrauch anzuführen aber im gleichen Zuge auf Gedeih und Verderb bei einer uralten Architektur zu bleiben. Auf eine Hardware festgelegt bist auch nur Du mit Deinem ASM Gefriggel. Moby A. schrieb: > Mein absoluter Liebling: Der Cast-Operator! Von der Abbildung konkreter > Projekt-Notwendigkeiten soweit entfernt wie eine Galaxie im Dark Field. [Zitat] Castings dienen dazu, die Bedeutung von Daten anders zu interpretieren, bzw. der Programmiersprache zu sagen, dass man sich bewusst ist, was man da eigentlich tut. https://www.proggen.org/doku.php?id=c:cast [Zitat Ende] Wäre vieleicht doch mal ganz gut für Dich ein C Anfänger Tutorial durchzuarbeiten. Du würdest dann erkennen können das in genau solchen Dingen die großen Vorteile einer dich unterstützenden Hochsprache bestehen. Vergiss das, DU würdest das in 100 Jahren nicht erkennen können. Moby A. schrieb: > Nein. Ich rede hier von 8-Bit MSR für datenarme und weniger > rechenintensive Anwendungen. Das es da viel mehr + anspruchsvolleres und > auch die Berechtigung für Hochspracheneinsatz (ggf. auf höherbittigen > MCs) gibt streitet doch niemand ab ! Also besteht die Effizienz von ASM darin das die Erweiterbarkeit da aufhört wo ich auf Grund einer veränderten Problemstellung einen Messwert direkt im Knoten verarbeiten müsste. Die Effizient von ASM ist also dadurch gegeben das ich popelige Messwerte an einen Server übermitteln muss damit der mir die Berechnungen ausführt und zurückschickt. Meine Güte ist das armseelig. Welche verschrobenen Ansichten Du doch hast was unter MSR zu verstehen ist. MÜR (Messen, Übermitteln, Steuern) würde es wohl mehr treffen. Deine Effizienz besteht doch nur darin die Finger von allem zu lassen was einen gewissen Komplexitätsgrad überschreitet. Das nennst Du dann Übung, Vorbereitung, System, frei nach dem Motto: Sei Schlau, bleib Dumm. Damit bist die die Katzenberger der MCU Programmierung. Bravo!
>Übung, Vorbereitung, System,
der Satz ist sowas von Inhaltslos..
kennt jemand irgenwas, wo man das nicht braucht?
sogar für den Gang aufs Klo braucht man Übung, Vorbereitung, und System
..
:
Bearbeitet durch User
Markus M. schrieb: > Jaja, die noch mehr Stromschluckende Hardware GRINS Serverhardware in irgend einem Rechenzentrum muß mich doch zu Hause nicht interessieren! Davon abgesehen, von zukünftiger Datenauswertung war die Rede. > Moby A. schrieb: > Ich rede hier von 8-Bit MSR für datenarme und weniger > rechenintensive Anwendungen. > > Und wieso sollte man für solche Anwendungen überhaupt sich die Mühe > machen das in Assembler mit maximaler Effizienz zu gestalten? > KOPFSCHÜTTEL Gleichfalls Kopfschüttel. Wozu sollte man sich dazu die C-Bürokratie aufbürden? Daß Asm mehr Effizienz liefert ist da nur ein Zusatz-Bonus ;-) > Ich habe immer noch nicht verstanden wieso ich Assembler lernen sollte, > wo ich doch schon C kann. Nun, in diesem Fall bleib doch bei C. Ist ja auch nicht alles schlecht dran ;-)
Robert L. schrieb: > Übung, Vorbereitung, System, > > der Satz ist sowas von Inhaltslos.. Was damit in Zusammenhang mit Asm gemeint ist hab ich hinreichend erläutert. Das trieft nur so vor Inhalt ;-) Witkatz :. schrieb: > Deine Aussage ist einzig und allein, dass man für eine simple > Steuerungsaufgabe keine Hochsprache lernen muss. Dein Code funktioniert > und du hast es bewiesen. Prima. Und gaaanz so simpel braucht die MSR Aufgabe nicht zu sein ;-) Michael K. schrieb: > Also besteht die Effizienz von ASM darin das die Erweiterbarkeit da > aufhört wo ich auf Grund einer veränderten Problemstellung einen > Messwert direkt im Knoten verarbeiten müsste. Asm begrenzt Erweiterbarkeit in keinster Weise, kann sich auf eine gegebene Hardware aber auch optimal einstellen. > Die Effizient von ASM ist also dadurch gegeben das ich popelige > Messwerte an einen Server übermitteln muss damit der mir die > Berechnungen ausführt und zurückschickt. Da hab ich von der Zukunft des IOT geredet. Aktor/Sensor Hard/Software und einfache MSR Steuerungen nehmen sich sonst nichts. > Meine Güte ist das armseelig. Wie Du meine Aussagen zur Kenntnis nimmst, ja. > Deine Effizienz besteht doch nur darin die Finger von allem zu lassen > was einen gewissen Komplexitätsgrad überschreitet. Richtig. Z.B. bürokratisches C und 32-Bit Controller- beides unnötig, übertrieben und umständlich für typische 8-Bit MSR Anwendungen! > Sei Schlau, bleib Dumm. Falsch. Sei schlau, machs simpel :-)
:
Bearbeitet durch User
Karl H. schrieb: > Das was du unter 'typisch' verstehst, ist es eben für die meisten > anderen nicht. Nochmal: Typische 8-Bit MSR Anwendungen verarbeiten ein paar Dutzend max. 16 bittiger Messwerte und benötigen mit Asm keine 32 Bit Power, weil sie nicht rechen- und datenintensiv sind. Fürs SmartHome als einem typischen Einsatzort hab ich hier noch keine typischen Gegenbeispiele gehört ;-) > völlig egal, ob das Programm im Flash 18 oder doch 21% belegt oder > nicht. Ob das im konkreten Fall egal ist weiß ich nicht. Je mehr Reserven für Erweiterungen desto besser. Mit Effizienz und Ressourcensparung beginnt man besser immer bei Null und nicht irgendwo im Projekt!
:
Bearbeitet durch User
Moby A. schrieb: > P. M. schrieb: >> Dann zeig doch mal eine R-Anwendung in Assembler... :-D > > Da gibts nix zum Lachen, sonst würd ich jetzt im Kalten sitzen ;-) > An eine Regelung zur Raumtemperatur müssen keine hohen Anforderungen > gestellt werden- wenn man's denn richtig macht. Haha...auch hier sieht man wieder dein begrenztes Weltbild: Hat der Moby eine einfache 2-Punkt-Regelung für seine Heizung gebastelt und das genügt bereits als Beweis, dass Assembler für R völlig ausreicht. Moby A. schrieb: >> Deine Effizienz besteht doch nur darin die Finger von allem zu lassen >> was einen gewissen Komplexitätsgrad überschreitet. > > Richtig. Z.B. bürokratisches C und 32-Bit Controller- beides unnötig, > übertrieben und umständlich für typische 8-Bit MSR Anwendungen! Zu umständlich für dich, weil du es nicht kannst. Alle anderen profitieren von massiv effizienterer Entwicklung. Der ganze Thread dient dir doch eigentlich nur dazu, deinen begrenzten Fähigkeiten- und Wissensstand schönzureden. Moby A. schrieb: > Cool, wie Du für die Fachwelt sprichst. > Cool, wie Du mir die Fachwelt um die Ohren haust. > Leider seh ich für den umrissenen Einsatzbereich rein gar nichts > widerlegt! Fakt ist, dass ich mit Software (in C/C++) Geld verdiene und du nicht. Dass ich eine komplette Ausbildung darin habe und du nicht. Dass dies auch für die anderen Leute gilt, die dir widersprechen. Ich mag dieses Argument normalerweise nicht so, aber hier muss man einfach mal feststellen: Der hat keine Ahnung, der versteht noch nicht mal die Grundlagen des besprochenen Themas.
Moby A. schrieb: > Du optimierst? In Asm? Na bravo- genau das mach ich ja auch! Ach so? > Bei größeren Programmen verschenkt man weniger Potential als Du hier > vorgibst- wenn man nämlich vorhandenes, effizientes Codematerial nur > miteinander verknüpft. Meine Verschwendung bei größeren Programmen für > mehr Übersicht besteht im wesentlichen nur darin, daß ich die > enthaltenen sequentiell abzuarbeitenden Bausteine in Form einer > Call-Liste aufrufe, die sich auch leicht abändern lässt. Das ist doch keine Optimierung! Das ist Speicher- und Rechenzeitverschwendung! Ich versuch mal ein Beispiel: Man möchte einen Mittelwert bilden, z.B. aus verschiedenen Messungen vom ADC. Nehmen wir mal für den Anfang zwei Messungen. Da steht dann ziemlich am Anfang in einer C-Datei:
1 | #define ANZAHL 2
|
Dann kommt eine Funktion die irgendwas Interessantes macht und am Ende steht dort:
1 | return wert / ANZAHL; |
Zur Erklärung des kryptischen C-Codes: 'define' gibt's in Assembler auch. Hat die gleiche Bedeutung. Dort heißt es allerdings (kürzer und hochoptimiert) nur 'def'. Die andere Zeile ins Deutsche übersetzt: Kehre mit dem Ergebnis der Berechnung 'wert' geteilt durch 'ANZAHL' zurück. Für 'return' gilt das gleiche wie oben. Heißt in Assembler stromsparend 'ret'. Nur: Wo ist jetzt das Ergebnis? Natüüürlich: Dazu gibt es einen Hinweis als Kommentar am Anfang der Funktion, wo alle verwendeten Register dokumentiert sind und welche für Datenüber- und -rückgabe verwendet werden. (Eventuell auch noch der Hinweis auf die Verwendung des Stacks.) Was für ein Schreibaufwand ;-) Die Assembler-Zeile vor dem 'ret' ist ganz einfach. Einmal nach rechts schieben - fertig! (Ich verrate dir mal was: Das kennt der Compiler. Das macht der genauso!) Nun stellt sich im Laborversuch heraus: Nur zwei Werte sind zur Mittelwertberechnung zu wenig, man müsste es mal mit vier probieren (Okay, kein Problem, eine Zeile dazu). Mist. Besser wären drei! Noch geiler wäre es vielleicht, nur Differenzen zu messen. Oops, da werden die Zahlen ja negativ ... Zumindest wird das niemals eine Funktion für die Codesammlung! [ Geht jetzt weit am Thema vorbei: Das wäre ein Fall für C++ :-) ] Gleichzeitig kann die Definition 'ANZAHL' hervorragend beim Einlesen der Messwerte verwendet werden :) Wie von Zauberhand erstellt der Compiler daraus den optimalen Assembler-Code. > In einem > finalen Schritt könnte man die Funktionalität zusammenfassen, darunter > leidet aber die Übersicht mehr als daß es der gesparte Flashspeicher > wert ist. Siehst Du, dass ist Optimierung! So macht das der Compiler! ----- Ich weiß, ist gegen eine Wand geredet. Ich hab' das aber mal gebraucht ;-)
Moby A. schrieb: > Cool, wie Du für die Fachwelt sprichst. Das steht ihm als Fachmann auch zu. > Cool, wie Du mir die Fachwelt um die Ohren haust. Das steht ihm als Fachmann auch zu. Moby A. schrieb: > Nochmal: Typische 8-Bit MSR Anwendungen verarbeiten ein paar Dutzend > max. 16 bittiger Messwerte In deinem Piffelprojekt werden doch gar keine Daten verarbeitet, sondern nur aufgenommen und weitergereicht. Von Dutzenden ganz zu schweigen. Messen beinhaltet nicht nur das Auslesen eines Wertes, sondern auch eine Verarbeitung. Die findet dort aber nicht statt. Eine Steuerung findet an der Stelle auch nicht statt. Das Thema Regelung hatten wir ja schon. Dein Projektchen ist also überhaupt keine "MSR"-Anwendung, sondern eine " "-Anwendung. Im Grunde nichts anderes als ein popeliger Datenlogger. Du trägst nur dick auf und wirfst mit Begriffen um dich, von denen du nicht das geringste verstehst. Wie ein Esoteriker. Es werden einfach Dinge behauptet und wenn es um den Nachweis geht, wird gekniffen. mfg.
P. M. schrieb: > Ich mag dieses > Argument normalerweise nicht so, aber hier muss man einfach mal > feststellen: Der hat keine Ahnung, der versteht noch nicht mal die > Grundlagen des besprochenen Themas. Da muss ich P.M. zustimmen. Das Problem ist doch, wer wenig weiß der weiß in der Regel nicht DASS er wenig weiß. Erst mit größerem Wissen über ein Fachgebiet kann man oft erst beurteilen wie es sich mit dem eigenen Wissensstand verhält, wo man Defizite hat. Außerdem erkennt man Probleme wo der Ungebildete sich denkt "Ist doch alles kein Problem!". Sehr schön ist das in diesem Thread zu beobachten: Beitrag "LED-Matrix | Einfachste methode für animationen?" Der TO hat dort augenscheinlich so wenig Ahnung von der Materie dass er garnicht weiß was er sich da vorgenommen hat. Deswegen immer wieder der Wunsch nach einer "einfachen Lösung ohne Programmieren". In der PRaxis führt dass dann dazu (im Beruf oft erlebt) dass die Wenig-Wisser kräftig auf den Putz hauen und die Fachmänner eher ruhig im Hintergrund über die Machbarkeit nachdenken. Ich habe gelernt: wenn mir jemand kommt mit "Ist doch ganz einfach..." oder "da muss man doch nur..." ist Vorsicht geboten! Auf diesen Thread bezogen: du Moby, lebst in so einer kleinen Welt dass du nicht ansatzweise erkennen kannst wie wenig du eigentlich weißt. Vielleicht nicht ganz unpassend: https://de.wikipedia.org/wiki/H%C3%B6hlengleichnis
P. M. schrieb: > Ich mag dieses > Argument normalerweise nicht so, aber hier muss man einfach mal > feststellen: Der hat keine Ahnung, der versteht noch nicht mal die > Grundlagen des besprochenen Themas. Hehe.. Ja der Ton wird etwas rauher. Aber es war zu erwarten. Es stimmt auch. Moby "Projekt" liest ein ADC und sendet in irgendwohin. Das kann man als "Messen" durchgehen lassen. Von MSR ist das weit entfernt. Ebenso ein 2/3-Punktregler. Ein richtiger Regler ist was völlig anderes. Und eine Datenverarbeitung findet auch nicht statt... Aber natürlich irrt nicht der eine Geisterfahrer, sondern die Entgegenkommenden...
Matthias L. schrieb: > Von MSR ist das weit entfernt. Nicht nur das: Es ist auch nur in dieser speziellen Konstellation nutzbar und daher für alle anderen User außer Moby selbst wertlos.
Karl H. schrieb: > Moby A. schrieb: > > Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen > Win-PC, die nur noch GHz Prozessoren stemmen. > > Das was ein heutiger PC im Hintergrund noch alles mit erledigt, kannst > du dir doch gar nicht vorstellen. Du auch nicht. Und mit der Gültigkeit meiner Aussage hat das auch wenig zu tun.
Moby A. schrieb: > Und mit der Gültigkeit meiner Aussage hat das auch wenig zu tun. Gültigkeit welcher Aussage? Wie gesagt: Du extrapolierst von 200 Byte auf 10KB. Das ist kompletter Unsinn. Nein: Dein Dreirad fährt NICHT 200 km/h - auch wenn Moby draufsitzt und Prrrmmmm Prrrrmmm macht.
Frank M. schrieb: > Dein Dreirad fährt NICHT 200 km/h Insbesondere wird es eben auch nicht in die Lage versetzt, 200 km/h zu fahren, indem man einfach das Treten beherrscht und dann „nur noch“ ausreichend schnell treten muss.
Moby A. schrieb: > Du auch nicht. Doch. Das kann er. Und ich kann das auch. Genauso wie das auch viele andere hier können. mfg.
le x. schrieb: > Ich habe gelernt: wenn mir jemand kommt mit "Ist doch ganz einfach..." > oder "da muss man doch nur..." ist Vorsicht geboten! Woher kennst du meinen Ex-Chef?
Matthias L. schrieb: > Hehe.. Ja der Ton wird etwas rauher. Man muss einfach mal. Ich mag es eigentlich nicht, in einer Diskussion laut oder unfreundlich zu werden. Aber es muss einfach mal gezeigt werden, dass wir hier nicht mehr ein Fachgespräch führen, sondern uns mit einem quengelnden Kind herumschlagen. Und da werden die Eltern ja auch mal etwas lauter :-) Und Moby, ich bin jederzeit dir zu verraten, auf welche Erfahrungen sich meine Aussagen stützen und ich bin auch jederzeit bereit, dir ein paar Tipps betreffend der Effizienz von C zu geben. Schreib einfach ne PN.
:
Bearbeitet durch User
Karl H. schrieb: "Du extrapolierst aus einer simplen Aufgabe, die du mit ein paar Anweisungen erledigen kannst auf das Verhalten von größeren Programmen. Und genau das ist nicht zulässig. Denn die zu bearbeitende Komplexität steigt nicht linear sondern mindestens exponentiell" Nein. Das lässt sich pauschal unabhängig jedweder konkreter Anwendung so nicht sagen. "Genau deshalb sind grosse Systeme auch so schwer zu schreiben, weil es mit jedem zusätzlichen Subsystem immer schwieriger wird, die Querverbinden und Verflechtungen im Auge zu behalten." Das ist solange richtig wie zusätzliche Subsysteme mehr Querverbindungen, Verflechtungen, Nebenwirkungen mitbringen. Allerdings gibt es wirksame Gegenmittel: Kapselung, funktionelle Gliederung, einheitliche Interfaces. Kurzum: System beim System-Aufbau. Die Notwendigkeit strukturierter Hochsprachen lässt sich so weit hinauszögern, weit noch aus dem 8-Bit MSR Bereich hinaus.
:
Bearbeitet durch User
Moby A. schrieb: > hinauszögern Hinauszögern trifft es gut. Ja, man kommt lange darum herum, aber es wird extrem mühsam und ineffizient. Moby A. schrieb: > Nein. Das lässt sich pauschal unabhängig jedweder konkreter Anwendung so > nicht sagen. Sagt wer? Sagt jemand, der gerade mal ein paar kleine 8-Bit-Projektchen durchgezogen und noch nie einen Code mit mehr als ein paar hundert Zeilen gesehen hat.
Moby A. schrieb: > Das ist solange richtig wie zusätzliche Subsysteme mehr > Querverbindungen, Verflechtungen, Nebenwirkungen mitbringen. Allerdings > gibt es wirksame Gegenmittel: Kapselung, funktionelle Gliederung, > einheitliche Interfaces. Kurzum: System beim System-Aufbau. Du solltest dich in Berlin bei BER bewerben. Jemanden wie dich können sie dort brauchen. Also jemanden mit System.
Frank M. schrieb: > Nein: Dein Dreirad fährt NICHT 200 km/h - auch wenn Moby draufsitzt und > Prrrmmmm Prrrrmmm macht. Das muß es auch nicht, das ist ja der Witz ;-) P. M. schrieb: > Aber es muss einfach mal gezeigt > werden, dass wir hier nicht mehr ein Fachgespräch führen, sondern uns > mit einem quengelnden Kind herumschlagen. Und da werden die Eltern ja > auch mal etwas lauter :-) Solange Diskussionen so herablassend in Überlegenheitsmanier geführt werden hab ich es besonders leicht ;-) Anders wäre der Fall wenn die angeblichen "Eltern" ihre Elternschaft mal mit besserer C-Codierung meines Projekts unter Beweis stellen würden! > Und Moby, ich bin jederzeit dir zu verraten, auf welche Erfahrungen sich > meine Aussagen stützen und ich bin auch jederzeit bereit, dir ein paar > Tipps betreffend der Effizienz von C zu geben. Gib Dir selber mal ein paar Tipps, wie sich mein Projekt in C doch noch sparender umsetzen lässt ;-)
Moby A. schrieb: > Solange Diskussionen so herablassend in Überlegenheitsmanier geführt > werden hab ich es besonders leicht ;-) Naja, wenn ein Hobbyist, der kein C kann, gegenüber 5-10 professionellen Entwicklern so überzeugt die Überlegenheit von Assembler gegenüber Hochsprachen predigt und gegen jegliche Argumente resistent ist, dann muss man einfach mal die Autoritätskeule auspacken. Und wie jetzt, du hast es leicht? Konntest du bisher irgend jemand von deinem Standpunkt überzeugen?
Moby A. schrieb: > Bürokratie= Gesamtheit des Sprachumfangs, Regeln, Vorschriften, Typen, > Operatoren, Deklarationen usw. Im Prinzip also alles was Moby nicht versteht. Komisch nur dass es genau (alle - 1) sonst verstehen.
P. M. schrieb: > Naja, wenn ein Hobbyist, der kein C kann, gegenüber 5-10 professionellen > Entwicklern so überzeugt die Überlegenheit von Assembler gegenüber > Hochsprachen predigt und gegen jegliche Argumente resistent ist, dann > muss man einfach mal die Autoritätskeule auspacken. Pack aus was Du willst... Wenn Du meinst, es könnte als "Argument" gebraucht werden. Eine Predigt ist für mich übrigens etwas, was nicht mit Code belegt ist ;-)
Moby A. schrieb: > Eine Predigt ist für mich übrigens etwas, was nicht mit Code belegt ist > ;-) Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber C, aber du kannst es nicht durch Code belegen.
Um mal wieder bisl produktiv zu werden: Im Sensorboard-Thread wurde ja mal versucht, die Anforderungen an die Software zusammenzufassen. Du hast dich damals sehr unkooperativ gezeigt, trotzdem bitte ich dich nochmal, die dortige Lsite kurz durchzusehen und falsche Anforderungen aufzuzeigen oder sogar zu korrigieren. Hier der anscheinend letzte Stand dieser Anforderungsliste:
1 | - Der Prozessor soll den internen 128kHz Takt verwenden |
2 | - es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4) |
3 | und AINP-CHANNEL2 (entspricht PB3) eingelesen werden (1) |
4 | - die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen werden |
5 | - das Einlesen soll im free-running Modus des ADC stattfinden, jeder |
6 | Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2) |
7 | - es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1) |
8 | und DINP2-LOW (entspricht PB5) eingelesen werden |
9 | - das Einlesen soll unmittelbar vor der Datenübertragung erfolgen |
10 | - es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte, versandt werden |
11 | - das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden |
12 | - ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK |
13 | (entspricht PB2) ausgegeben werden |
14 | - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden |
15 | durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden) |
16 | - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits |
17 | - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits |
18 | - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits |
19 | - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits |
20 | - Bit 20: DINP1-LOW |
21 | - Bit 21: DINP2-LOW |
22 | - Bits 22-23: Checksumme über das Datentelegram |
23 | - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in |
24 | einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird |
25 | - das Telegram soll alle 320 ms wiederholt werden; der genaue Wert |
26 | ist unkritisch |
27 | - Das Telegram soll eine Bit-Zykluszeit von ca. 10 ms haben, also 80 ms |
28 | pro Byte |
29 | - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen |
30 | - das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben |
31 | - es ist nur 1 Timerinterrupt zu verweden, andere Interrupts sind für |
32 | Erweiterungszecke reserviert |
Ich hab hierzu 2 Fragen, die ich oben gekennzeichnet habe: 1) Soll 8 mal AINP-CHANNEL1 und dann 8 mal AINP-CHANNEL2 eingelesen werden oder soll dies im Wechsel geschehen? 2) Soll zwischen den 8 Messpunkten gewartet werden (z.B. im nächsten Timer-Interrupt) oder soll eine Messung gestartet werden, sobald der ADC wieder frei ist? Kannst du dazu bitte was sagen?
sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen von Moby eh schon verloren.
P. M. schrieb: > Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler > sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber > C, aber du kannst es nicht durch Code belegen. Das behaupte ich, ja. Ausgehend von meinem existenten Code. Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen. Soweit waren wir schon ;-) le x. schrieb: > Um mal wieder bisl produktiv zu werden: Prima. > Kannst du dazu bitte was sagen? Gerne. Heute abend. Auch wenn es sinnlos ist. Obwohl längst alles dazu gesagt wurde ;-(
Werner P. schrieb: > sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen > von Moby eh schon verloren. SO IST ES !
Moby A. schrieb: > P. M. schrieb: >> Also genau das, was du die ganze Zeit machst. Du behauptest, Assembler >> sei auch für Projekte jenseits von 1 kB oder 10 kB überlegen gegenüber >> C, aber du kannst es nicht durch Code belegen. > > Das behaupte ich, ja. Ausgehend von meinem existenten Code. Wie gross ist er denn, der Code? > Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen. Soweit > waren wir schon ;-) Eine ganze Industrie, die für schwachbrüstige Mikrocontroller wie auch für High-Performance-Anwendungen weitestgehend C und nicht Assembler verwendet, ist wohl Beweis genug, dass C gegenüber Assembler keine nennenswerten Effizienznachteile hat.
Moby A. schrieb: > Werner P. schrieb: >> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen >> von Moby eh schon verloren. > > SO IST ES ! Was für eine schwachsinnige Aussage.
Robert L. schrieb: > der Satz ist sowas von Inhaltslos.. > kennt jemand irgenwas, wo man das nicht braucht? > > sogar für den Gang aufs Klo braucht man Übung, Vorbereitung, und System > .. Das beschreibt Mobys Horizont schon sehr gut ;-)
Werner P. schrieb: > sobald Du auch nur ein Byte SRAM "verschwendest" Wobei natürlich das Abarbeiten von Interrupts (die Stack belegen) keine Verschwendung ist, auch wenn man die Aufgabe selbstverständlich ganz ohne solche genauso lösen könnte. Merke: Moby legt fest, welcher Verbrauch „Verschwendung“ ist und welcher nicht. Flash, der für das Initialisieren nicht benutzten RAMs verplempert wird, ist beispielsweise keine, aber SRAM statt Registern zu belegen, ist per definitionem eine solche (obwohl doppelt so viel SRAM da ist wie Register, letztere als teurer sind). Vielleicht sollte er ja mal bei Atmel nachfragen, ob er den nicht benutzten RAM auch zurückgeben darf gegen ein wenig Rabatt. :) Moby A. schrieb: > Die Gegenseite kann ihre Behauptung >1K (?) auch nicht belegen. Nur deshalb, weil du dich ja nicht auf einen solchen Vergleich einlässt. Vorgeschlagen hatte Karl Heinz dir einen, und nein, der war ohne irgendeinen „Heimvorteil“, sprich eine bereits existierende Implementierung in C. Oder meinst du etwa, wir müssten dann auch noch das zugehörige Assemblerprogramm schreiben? Wie stellst du dir dieses „belegen“ denn sonst vor? (OK, jetzt geh' ich mal wieder Ressourcen verplempern, dafür werde ich ja schließlich bezahlt.)
:
Bearbeitet durch Moderator
mal den moby fragen ob er mir kann sagen wenn wir etwas SRAM verwenden es das selbe ist wie verschwenden ;-)
Moby A. schrieb: > Werner P. schrieb: >> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen >> von Moby eh schon verloren. > > SO IST ES ! Definiere genauer RAM-Verbrauch. Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen. Gruß, Stefan
Matthias L. schrieb: > Was für eine schwachsinnige Aussage. ... besonders für den, der diese Aufgabe nicht lösen kann ;-) Es geht hier ja nicht darum, Ressourcen da wo nötig nicht in Anspruch zu nehmen. Aber es geht darum, ob C im Bedarf an Asm herabkommt. Wird der Code des durchschnittlichen Asm-Programmierers Moby gar unterboten, wird sich hier kein Moby der Welt mehr hinstellen und C prinzipiell mangelnde Effizienz vorwerfen!
Moby A. schrieb: > Es geht hier ja nicht darum, Ressourcen da wo nötig nicht in Anspruch zu > nehmen. also darf jetzt SRAM verwendet werden oder nicht? Bitte ein Ja oder ein Nein.
Stefan K. schrieb: > Definiere genauer RAM-Verbrauch. > Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen. Weiter oben stand schon mal das Ergebnis der Assemblierung. Das ist auch in meinem Code zu besichtigen. So, weiter gehts am Abend!
Jörg W. schrieb: >> sobald Du auch nur ein Byte SRAM "verschwendest" > > Wobei natürlich das Abarbeiten von Interrupts (die Stack belegen) Wie der oben aufgeführte AT90S1200 zeigt, kann man auch ohne RAM mit Interrupts arbeiten.
:
Bearbeitet durch User
A. K. schrieb: > Wie der oben aufgeführte AT90S1200 zeigt, kann man auch ohne RAM mit > Interrupts arbeiten. Aber nur, wenn man einen separaten Stack hat. Sein ATtiny13 braucht dagegen schon RAM dafür. ;-) (War's nicht der i8008, der auch nur einen Hardwarestack hatte? Der ist evolutionsmäßig an mir vorbeigegangen.)
A. K. schrieb: > Wie der oben aufgeführte AT89S1200 zeigt, kann man auch ohne RAM mit > Interrupts arbeiten. und? dann kommt Moby und sagt: Es muss ein Attiny13 sein.
Moby A. schrieb: >> Definiere genauer RAM-Verbrauch. >> Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen. > > Weiter oben stand schon mal das Ergebnis der Assemblierung. Das ist auch > in meinem Code zu besichtigen. Den Begriff Definition kannst Du im Duden nachschlagen.
Stefan K. schrieb: > > Definiere genauer RAM-Verbrauch. > Dieses Programm ist auch in ASM ohne RAM definitiv nicht zu machen. > > Gruß, Stefan Doch, natürlich geht das und dazu braucht an keinen μC mit Hardwarestack. Man muß lediglich auf Interrupts verzichten, was bei den oben zu findenden Specs kein Problem ist. Einen Timer kann man auch pollen, ADC genauso -> Stack ist unnötig, Register sichern ist unnötig, RAM initialisieren ist unnötig, ... Nur können muß man halt und damit meine ich nicht die Maschinenbefehlsketten, sonder das darüber liegende Schema. "Problemorientiert" nennt sich diese Ebene auch und damit sind nicht 8-Bit-Register-Beschränktheits-Probleme gemeint. PS: mal sehen in welchen Schipsel der Text von M. wieder "freundlich" herabgelassen wird.
Carl D. schrieb: > Doch, natürlich geht das und dazu braucht an keinen μC mit > Hardwarestack. Man muß lediglich auf Interrupts verzichten Klar geht das, verletzt aber die Spezifikation: le x. schrieb: > - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen Das erinnert mich an mein Betriebspraktikum (schon eine Weile her), wo die Forderung die genau umgekehrte war: keinen Timer-ISR und auch keinen Timerwert verwenden. Der Entwicklungsleiter hatte wohl mal schlechte Erfahrungen mit Interrupts gemacht und meinte, der Timer wird durch Störungen fehlgetriggert. Die Folge war, daß alle if-else-Zweige einer sehr komplexen Regelung mit nop-Schleifen auf gleiche Länge getrimmt wurden. Diese Steuerungen wurden dann später übrigens in Planierraupen eingebaut ... Gruß, Stefan
Stefan K. schrieb: > Diese Steuerungen wurden dann später übrigens in Planierraupen eingebaut > ... Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten gegeben. ;-)
Moby A. schrieb: > Werner P. schrieb: >> sobald Du auch nur ein Byte SRAM "verschwendest" hast in den Augen >> von Moby eh schon verloren. > > SO IST ES ! Dann skalieren wir das mal hoch, wie Moby es gern macht: Ein 200Byte-Programm darf KEIN RAM verbrauchen. Daraus folgt zwingend nach Mobys Skalierungsregeln: Ein 10KB-Programm darf KEIN RAM verbrauchen. Dein angeblich existententes Haus-und-Hof-10-KB-Programm, braucht das eigentlich RAM? Ich bin mir sicher, dass es RAM braucht. Du bist also ein Lügner. Achja: Damit ein Interrupt einen RETI machen kann, muss es die Rücksprungadresse vom Stack aus dem RAM holen. Also: Dein 200Byte-Programm verbraucht RAM! Und schon wieder eine Lüge.
Carl D. schrieb: > Man muß lediglich auf Interrupts verzichten[...] > [...]Nur können muß man halt und damit meine ich nicht die > Maschinenbefehlsketten, sonder das darüber liegende Schema. Das hatten wir ja schon. Für das, was er nicht kann, hat er dann wieder irgendeine Ausrede. mfg.
Thomas E. schrieb: > Für das, was er nicht kann, hat er dann wieder irgendeine Ausrede. Oder es wird zugekauft. :)
Jörg W. schrieb: > Thomas E. schrieb: >> Für das, was er nicht kann, hat er dann wieder irgendeine Ausrede. > > Oder es wird zugekauft. :) für Moby kein Problem. Bei so viel "Übung, Vorbereitung, und System"
Frank M. schrieb: > Und schon wieder eine Lüge. Moby operiert recht systematisch mit verdrehter Wahrheit, das ist so.
Thomas E. schrieb: > Das hatten wir ja schon. Für das, was er nicht kann, hat er dann wieder > irgendeine Ausrede. So ist es. Die Forderung "Kein RAM!" kam ja auch erst später hinzu, als Yalu ihm schon vorgeführt hatte, dass es effizienter und kleiner in C geht. Da hat er einfach mal so die Spielregeln geändert. Und genau deshalb will das hier auch keiner nachprogrammieren. Er wird sofort die wieder die Spielregeln ändern, zum Beispiel so: "Das C-Programm muss in ASM geschrieben sein!" Er ist einfach ein schlechter Verlierer - nichts weiter.
Jörg W. schrieb: > Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten > gegeben. ;-) Ja, das hatte mich damals sehr "beeindruckt" ... Was ich damals gelernt habe: die alten Hasen haben zwar viel Wissen, oft aber auch viele (Vor-)Urteile, die vor ein paar Jahren sicher sinnvoll waren, mittlerweile aber so nicht mehr stimmen. Gruß, Stefan
Frank M. schrieb: > So ist es. Die Forderung "Kein RAM!" kam ja auch erst später hinzu, als > Yalu ihm schon vorgeführt hatte, dass es effizienter und kleiner in C > geht. Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da, um gebraucht zu werden, das hat nichts aber auch gar nichts mit Ineffizienz zu tun.
P. M. schrieb: > Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da, > um gebraucht zu werden, das hat nichts aber auch gar nichts mit > Ineffizienz zu tun. Erstens das und zweitens ist es ja nur Zufall, dass er kein RAM braucht. Das Micky-Maus-Programm ist halt so lächerlich klein, dass alles in Register passt. Bei einem etwas größeren Programm klappt das schon nicht mehr. An 0 Byte RAM festzumachen, dass ASM C überlegen ist, ist einfach nur lächerlich. Aber hier wiederholen sich nur noch die Argumente und man kann nur noch den Kopf schütteln. Ich klinke mich daher nun aus diesem Thread aus und kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys Provokationen zu reagieren. Soll der Troll sich doch mit sich selbst hier unterhalten. Selbst ein Kleinkind ist vernünftiger als dieses Balg.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Soll der Troll sich doch mit sich selbst hier unterhalten. Selbst ein > Kleinkind ist vernünftiger als dieses Balg. Das ist schon länger klar, ja. Mich interessiert eigentlich einzig und alleine noch, wer hinter dieser Person steckt. Meint er das wirklich ernst oder ist er doch irgendwie ein Troll?
P. M. schrieb: > Meint er das wirklich ernst Na klar. Als Hobbyprogrammierer kann er das ja auch. ;-)
P. M. schrieb: > Meint er das wirklich ernst oder ist er doch irgendwie ein Troll? Das ist mir scheissegal. Es ist auch schnurz, denn überzeugen kann ihn sowieso niemand. Da ist mir eine Betonwand, der ich gut zurede, lieber. Und daher jetzt für mich EOD.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Ich klinke mich daher nun aus diesem Thread aus und > kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys > Provokationen zu reagieren. Das widerum seh ich anders. Ich habe hier viele vergnügliche Stunden verbracht und hoffe das geht noch eine Weile so, wenigstens bis zu meinem Urlaub ;-) Ich schäme mich zwar ein wenig für meine niederen Instinkte, aber das hier trifft es doch recht anschaulich: P. M. schrieb: > (Zugegeben, so ein bisschen Spass macht es schon - wie früher wenn man > den Klassendepp mit seinen absurden Ansichten noch ein bisschen > aufgezogen hat.) Aber mal abwarten ob ich heute Abend irgendwelche Bestätigungen in Punkto Anforderungsliste kriege. Ich glaub zwar nicht so recht dran, denn daran ist ja schon der Sensorboard-Thread gescheitert. Aber wenn was kommt probier ich vielleicht ein bischen rum, was mit Compiler/Linkerflags so alles drin ist. Und wenn es nur dazu dient die nächste Ausrede zu hören ;-)
Stefan K. schrieb: > Jörg W. schrieb: >> Ach, du warst das. :) Die Geschichte hattest du schon mal zum besten >> gegeben. ;-) > > Ja, das hatte mich damals sehr "beeindruckt" ... > > Was ich damals gelernt habe: die alten Hasen haben zwar viel Wissen, oft > aber auch viele (Vor-)Urteile, die vor ein paar Jahren sicher sinnvoll > waren, mittlerweile aber so nicht mehr stimmen. Ein alter Hund lernt keine neuen Tricks mehr. :-) Stimmt schon was du da sagst. Da muss ich mich auch an der Nase nehmen. Viele Dinge mach ich heute so, weil ich sie 'schon immer' so gemacht habe, weil ich die Technik dazu gut kenne und oft erfolgreich angewendet habe. Was man eben im Schlaf beherrscht, kommt immer wieder gerne zum Einsatz. Oft entscheidet auch das Bauchgefühl anhand von Analogien.
le x. schrieb: > Ich habe hier viele vergnügliche Stunden verbracht Ein schönes vorweihnachtliches Thema. Erinnert an den Buch-Thread. Einer weiss und kann alles und alle anderen sind zu doof. mfg.
Frank M. schrieb: > P. M. schrieb: >> Und die Forderung ist so dermassen lächerlich. RAM ist schliesslich da, >> um gebraucht zu werden, das hat nichts aber auch gar nichts mit >> Ineffizienz zu tun. > > Erstens das und zweitens ist es ja nur Zufall, dass er kein RAM > braucht. Das Micky-Maus-Programm ist halt so lächerlich klein, dass > alles in Register passt. Bei einem etwas größeren Programm klappt das > schon nicht mehr. Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern, so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist auch nicht mehr gross rum rechnen. Was machst du mit dem übrig gebliebenem RAM? Öhmmmmm. > An 0 Byte RAM festzumachen, dass ASM C überlegen ist, ist einfach nur > lächerlich. Wenn man den Compiler anweist, die Variablen in Register zu legen, würde man wahrscheinlich auch das noch wegkriegen. Aber ich hab jetzt ehrlich gesagt Yalus Programm noch gar nicht gesehen, was er da eigentlich alles gemacht hat.
:
Bearbeitet durch User
Karl H. schrieb: > Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern, > so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die > Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist > auch nicht mehr gross rum rechnen. Was machst du mit dem übrig > gebliebenem RAM? Öhmmmmm. jo, es wird auch langweilig hier. Moby bringt nichts Neues. Wiederholt sich nur und beharrt auf seiner Meinung. Den SRAM hat er eh voll verschwendet. Er schreibt ihn ja am Anfang seines Programms mit Nullen voll. Warum auch immer. Jeder findet seinen Meister. Ich bin mir sicher dass es genügend C-Profis gibt die das ASM-Programm von Moby toppen. Auch wenn er das nicht glauben mag. Was solls. Wenns ihn freut ;-)
Er lernt das kryptische Zeichen "^" auswendig. Kann also noch dauern. ..
:
Bearbeitet durch User
Karl H. schrieb: > Aber ich hab jetzt ehrlich > gesagt Yalus Programm noch gar nicht gesehen, was er da eigentlich alles > gemacht hat. Bitteschön: Beitrag "Re: C versus Assembler->Performance"
Hier bricht ja jetzt die nackte Panik aus ;-) Frank M. schrieb: > Ich bin mir sicher, dass es RAM braucht. Du bist also ein Lügner. > Achja: Damit ein Interrupt einen RETI machen kann, muss es die > Rücksprungadresse vom Stack aus dem RAM holen. > Dein 200Byte-Programm verbraucht RAM! > > Und schon wieder eine Lüge. Oh, da schlägt ja einer wild um sich ;-) Daß mein Projekt RAM in Gestalt des Stackbedarfs eines Interrupt-Calls benötigt erschließt sich natürlich aus dem Programmcode. Aber nur für Kenner ;-) Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur Verfügung = 1 Unterprogramm-Ebene. Frank M. schrieb: > Ich klinke mich daher nun aus diesem Thread aus und > kann nur noch jedem raten, das auch zu machen und nicht mehr auf Mobys > Provokationen zu reagieren. Gut so Frank. Du machst das einzig Richtige. Deine Provokationen sind ja auch weitgehend verpufft ;-)
Ne der missioniert gerade: Beitrag "Re: Heim Automatisierungswahn" Wobei er ein BLE-Module entdeckt hat, auf dem ein M0 mit 128k Flash und 16k RAM werkelt, auf dem ein sicher nicht in ASM geschriebener BASIC-Interperter läuft. Wichtig ist eben eins: keine irgendwie erkennbare C-Bürokratie. Aber noch besser sind kleine AVR Boards, die per proprietären Drahtprotokoll plaudern. Sagt er.
Werner P. schrieb: > Ich bin mir sicher dass es genügend > C-Profis gibt die das ASM-Programm von Moby toppen. Auch wenn er das > nicht glauben mag. Ob Du's glaubst oder nicht- mich würde das freuen. Aber Du hast Recht, dran glauben mag ich nicht. Jörg W. schrieb: > Merke: Moby legt fest, welcher > Verbrauch „Verschwendung“ ist und welcher nicht. Nein. Moby legt nur fest, daß zu einem sinnvollen Ressourcen-Vergleich natürlich das SRAM gehört. ;-) le x. schrieb: > Ich schäme mich zwar ein wenig für meine niederen Instinkte Das ehrt Dich. Wenigstens einer der's mal ehrlich zugibt ;-) le x. schrieb: > Aber mal abwarten ob ich heute Abend irgendwelche Bestätigungen in > Punkto Anforderungsliste kriege. Selbstverständlich. Setz mich gleich nochmal dran. > Ich glaub zwar nicht so recht dran, denn daran ist ja schon der > Sensorboard-Thread gescheitert. Aber wenn was kommt probier ich > vielleicht ein bischen rum, was mit Compiler/Linkerflags so alles drin > ist. Ja, das fürchte ich auch: Mehr als ein bischen Rumprobieren kommt nicht bei raus. Ich denke, das haben in der Zwischenzeit schon ganz andere gemacht ;-) > Und wenn es nur dazu dient die nächste Ausrede zu hören ;-) Wenn Du es nicht schaffst ist meiner Meinung nach Streit vorprogrammiert. Ich bin schon gespannt worüber. Denn eines wird auf Biegen und Brechen erstmal nicht passieren: Daß die C-Seite die unbestreitbaren Vorteile von Asm eingesteht ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Daß mein Projekt RAM in Gestalt des Stackbedarfs eines Interrupt-Calls > benötigt erschließt sich natürlich aus dem Programmcode. Aber nur für > Kenner ;-) > > Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem > C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den > Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur > Verfügung = 1 Unterprogramm-Ebene. D.h. es kann möglich sein, ein dem Assemblerprogramm gleichwertiges Programm in C zu schreiben, wenn der Compiler den identischen Assembler output erzeugt, bzw. exact die gleichen Bytes ins Flash gebrannt werden. Alles andere ist eine Verletzung der Spezifikation. Damit geht ein besseres Programm per Definition nicht. Der Thread ist somit beendet. Bitte schliessen.
Moby A. schrieb: > Ganz klar: Durch die Hintertür des Stackverbrauchs wird auch dem > C-Programm nicht erlaubt, sich an der Ressource RAM zu bedienen. Für den > Stack stehen wie meinem Asm-Programm nicht mehr als 2 RAM-Bytes zur > Verfügung = 1 Unterprogramm-Ebene. Was ist das für ein unsinniger Mikrocontroller? Selbst lausigste kleinste PIC hat 2 Stack-Ebenen. Und warum etwas "sparen", was man schon gekauft und bezahlt hat? Man kann sich auch selber geißeln. Es ist so schön, wenn der Schmerz wieder nachlässt... Bernhard M. schrieb: > Der Thread ist somit beendet. > Bitte schliessen. Neineinein! Dann verliere ich die 2000er-Wette. Auch wenns nur ums "Recht haben" geht... ;-)
:
Bearbeitet durch Moderator
Moby A. schrieb: > Daß die C-Seite die unbestreitbaren Vorteile von Asm eingesteht Dazu musst du aber ein Programm zeigen, dass die Vorteile auch nutzt. So, wie ich das in meinem genialen Programm gemacht habe. Es macht exakt das, was es soll. Nicht mehr und nicht weniger. Und das mit absoluter Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran. mfg.
:
Bearbeitet durch User
Bernhard M. schrieb: > Alles andere ist eine Verletzung der Spezifikation. So ist es. Ist es schlechter, hat Moby gewonnen, ist es besser, dann fehlt ihm irgendein Feature, welches nachträglich als wesentlich erklärt wird. Da die „Spezifikation“ ja nur im „selbsterklärenden Assemblerprogramm“ besteht, ist das doch auch völlig logisch, oder? > Der Thread ist somit beendet. Nein, schließlich ist Assembler ja „auf dem Weg nach vorn“. :-) Ich habe gestern ein Buch über Assembler-Programmierung geschenkt bekommen. In seinem Vorwort enthält es den Absatz:
1 | When writing a book on the assembly language of a processor, we know in |
2 | advance that it will not register in posterity. By its very nature, an assembly |
3 | language has the same life expectancy as the processor it supports perhaps 20 |
4 | years at best. What's more, this type of programming is obviously not used for the |
5 | development of software projects and so is of little consequence. (*) |
Man würde sich wünschen, Moby würde den gleichen Realismus an den Tag legen wie der Autor dieses Buches. ;-) (*) Für die, die des Englischen nicht ganz so mächtig sind: Wenn man ein Buch über Assembler-Programmierung eines bestimmten Prozessors schreibt, ist von vornherein klar, dass es nicht für die Ewigkeit bestimmt ist. Prinzipbedingt hat die Assemblersprache die gleiche Lebenserwartung wie der durch sie unterstützte Prozessor, vielleicht maximal 20 Jahre. Jedoch wird diese Art von Programmierung nicht für die Entwicklung von Softwareprojekten genutzt, sodass das keine großartigen Konsequenzen nach sich zieht.
:
Bearbeitet durch Moderator
Carl D. schrieb: > Ne der missioniert gerade: Irrtum Carl D. Ich bin mit ganzem Einsatz wieder hier bei meinem Lieblingsthema. Lass mal das BLE-Modul. Das interessiert hier nicht! Karl H. schrieb: > Vor allen Dingen. Was willst du da an dem Tiny 13 noch gross erweitern, > so dass das RAM voll wird? Die Pins sind alle aufgebraucht. Die > Messwerte kannst du, so wie die Rechnerei ineinander geschachtelt ist > auch nicht mehr gross rum rechnen. Was machst du mit dem übrig > gebliebenem RAM? Öhmmmmm. Du warst beim Lesen meines Projekt-Threads eben auch nicht aufmerksam. Das will ich Dir aber keinesfalls vorwerfen, da Dein Zeiteinsatz bei den vielen Hilfe-Threads in jedem Falle höher zu bewerten ist. Ja, was macht man mit zusätzlichem Platz? Warum bist Du da jetzt plötzlich so einsilbig einfallslos? Stell Dir eine Messwert-Vorabauswertung vor, bevor die Daten auf die Reise gehen. Garniert vielleicht mit einen kleinen History. Da kann man u.U. jedes Bytchen gebrauchen. Die Main ist noch frei. Idealer Erweiterungspunkt, um Funktionalität wunderbar unabhängig von der periodischen Datenausgabe mit vielleicht ein paar Unterprogrammebenen einzuziehen. Du weißt natürlich selbst, daß es mir nicht darum geht, vorhandene Ressourcen ungenutzt zu lassen. Natürlich. Natürlich weißt Du, daß es nur um den prinzipiellen Ressourcenvergleich C vs. Asm geht bei bitteschön gleich(st)er Vergleichs-Funktionalität geht... Natürlich K.H. Gibs halt mal zu ;-) Ist halt für einen überforderten C-Profi schwierig, bei diesen Schwierigkeiten nicht in konstruierte Nebenkriegs- Schauplätze und Plänkeleien abzugleiten. Immerhin bleibst Du im zweiten KnowHow Vergleich unter den steil emporragenden C-Koryphäen, der hier so hintergründig mitläuft überzeugend- da Du der Versuchung widerstehst, das zwar tröstende, erheiternde, ablenkende- aber eigentlich doch so dumme und entlarvende Hohn/ Spott/ Beileidigungs/ Betrugsvorwurf- Spielchen mitzuspielen. Respekt. > Wenn man den Compiler anweist, die Variablen in Register zu legen, würde > man wahrscheinlich auch das noch wegkriegen. Ich bin doch eigentlich sooo gutmütig und großzügig: Die Möglichkeit massierten Registereinsatzes hab ich für C doch offengelassen. Auch wenns im Vergleich zu den meinigen 11 von 32 Registern dann natürlich nicht schön ausschaut und, wenn nicht den faktischen, so aber zumindest den moralischen Sieg kostet ;-)
Jörg W. schrieb: > hat Moby gewonnen, Ja. Dann hat er aber nur eine Schlacht gewonnen. Den Krieg hab längst ich gewonnen. Mit meinem absolut genialen Programm. Es macht exakt das, was es soll. Nicht mehr und nicht weniger. Und das mit absoluter Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Da kommt er mit seinem Dödelprogramm nicht im entferntesten heran. mfg.
Lothar M. schrieb: > Was ist das für ein unsinniger Mikrocontroller? Selbst lausigste > kleinste PIC hat 2 Stack-Ebenen. Aber nicht im RAM. ;-)
Thomas E. schrieb: > Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran. Und Du mit Deiner Rumpffunktionalität nicht im Entferntesten an die Arbeitsresultate meines Projekts. Hattest Du das noch nicht bemerkt? Es spricht momentan nicht gerade für Dich, daß Du so unterschiedliche Funktionalität unbedingt im Ressourcenverbrauch vergleichen willst. Also mir wär das peinlich ;-) Bernhard M. schrieb: > D.h. es kann möglich sein, ein dem Assemblerprogramm gleichwertiges > Programm in C zu schreiben, wenn der Compiler den identischen Assembler > output erzeugt, bzw. exact die gleichen Bytes ins Flash gebrannt werden. > Alles andere ist eine Verletzung der Spezifikation. So eine Aussage wär mir auch peinlich... > Der Thread ist somit beendet. (*) > Bitte schliessen. (*) Wegen Überforderung des C-Compilers. Schnell weg damit. Aus dem Auge, aus dem Sinn.
So liebe Leute, auch wenns gerade so einen Spaß macht mich an dem hilflosen Herumrudern mancher Akteure hier zu laben- ich schau nochmal auf mein Programm wegen der -hochtrabend so genannten - "Spezifikation" ... Fortsetzung folgt.
Moby A. schrieb: > Und Du mit Deiner Rumpffunktionalität nicht im Entferntesten an die > Arbeitsresultate meines Projekts. Hattest Du das noch nicht bemerkt? > Es spricht momentan nicht gerade für Dich, daß Du so unterschiedliche > Funktionalität unbedingt im Ressourcenverbrauch vergleichen willst. Welch ein Ausbruch, um von der eigenen Unzulänglichkeit abzulenken. Ich will gar nichts vergleichen. Mein geniales Programm lässt sich mit nichts vergleichen. Das Beste gewinnt jeden Vergleich. Und dieses Programm ist sogar das absolut Beste. Es macht exakt das, was es soll. Nicht mehr und nicht weniger. Und das mit absoluter Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Da kommst du mit deinem Dödelprogramm nicht im entferntesten heran. mfg.
Moby A. schrieb: > So eine Aussage wär mir auch peinlich.. Ich habe nur alle Deine Aussagen knapp zusammengefasst.
Angehängte Dateien:
-
T13OUT.jpg
150 KB
So, also nochmal: le x. schrieb: > Hier der anscheinend letzte Stand dieser Anforderungsliste: > - Der Prozessor soll den internen 128kHz Takt verwenden OK. > - es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4) > und AINP-CHANNEL2 (entspricht PB3) eingelesen werden (1) OK. Die zu verwendende Referenzspannung wird für jeden Kanal einzeln in Form einer Konstante vorgegeben! > - die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen > werden Natürlich. Wir wollen doch nix "verschwenden" ;-) > - das Einlesen soll im free-running Modus des ADC stattfinden Im Interesse der Interrupt-Einsparung wärs gut. Kann man aber auch manuell starten/im ADC-Int auslesen. Aber Stackbeschränkung (s.u.) beachten! > jeder Wert wird 8mal gelesen und daraus ein Mittelwert gebildet (2) Richtig. > - es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1) > und DINP2-LOW (entspricht PB5) eingelesen werden Richtig. > - das Einlesen soll unmittelbar vor der Datenübertragung erfolgen Ja. Wär echt sinnvoll, daß die nächste Datenausgabe aktuelle Werte enthält... > - es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte, > versandt werden > - das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden > - ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK > (entspricht PB2) ausgegeben werden OK. > - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden > durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden) > - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits > - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits > - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits > - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits > - Bit 20: DINP1-LOW > - Bit 21: DINP2-LOW Ok. > - Bits 22-23: Checksumme über das Datentelegram > - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in > einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird Bit22= Bit 0 der Summe, Bit23= Bit 1 der Summe > - das Telegram soll alle 320 ms wiederholt werden; der genaue Wert > ist unkritisch > - Das Telegram soll eine Bit-Zykluszeit von ca. 10 ms haben, also 80 ms > pro Byte Genau. 80ms Pause zwischendurch dienen der Synchronisierung. Siehe Diagramm! Dort ist dann auch zu sehen, daß das letzte Datenbit auf PB0 in der Pause stehenbleibt. > - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen > - das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben Die letzten 2 Punkte hatte ich schon zum Abschuß freigegeben. Wär natürlich schön, der Anwender könnte auf dieser Architektur aufbauend einfachst erweitern, ohne daß die unabhängige Ausgabe-Funktionalität gestört würde (dann mit entsprechender TimerInt-Registersicherung). > - es ist nur 1 Timerinterrupt zu verwenden, andere Interrupts sind für > Erweiterungszecke reserviert Siehe auch Stack-Beschränkung! > 1) Soll 8 mal AINP-CHANNEL1 und dann 8 mal AINP-CHANNEL2 eingelesen > werden oder soll dies im Wechsel geschehen? Ist doch wurscht. > 2) Soll zwischen den 8 Messpunkten gewartet werden (z.B. im nächsten > Timer-Interrupt) oder soll eine Messung gestartet werden, sobald der ADC > wieder frei ist? Was willst Du da starten? Der ADC läuft doch Free Running... Wenn Du den schön regelmäßig ausliest hast Du immer aktuelle Werte. Mit einer anderen Lösung muss in jedem Fall eines sichergestellt sein: Die Datenausgabe enthält den Durchschnitt von 8 aktuellen Messungen! Und zum Abschluß das Wichtigste: Für den faktischen Sieg soll a) die Datenausgabe stimmen (was ich sehr schnell mit der .hex prüfen kann) b) kein Byte Flash mehr verbraucht werden c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt werden. Alles klar? Wenn nicht, bitte fragen. Anbei auch nochmal das aktuelle Programm.
Moby A. schrieb: > a) die Datenausgabe stimmen (was ich sehr schnell mit der .hex prüfen > kann) > b) kein Byte Flash mehr verbraucht werden > c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt > werden. Ich dachte, wir sprechen von Programmen jeglicher Grösse, aber ich sehe bei dir nur ein Mickymausprogramm... Bevor wir darüber sprechen, sollten wir uns über sinnvolle Vorgaben und daraus folgend eine sinnvolle Architektur unterhalten. Denn die beinhaltet dein Programm nicht. Und: Die obige Anforderungsliste ist alleine schon kryptischer als das zugehörige C-Programm.
P. M. schrieb: > Ich dachte, wir sprechen von Programmen jeglicher Grösse, aber ich sehe > bei dir nur ein Mickymausprogramm... > > Bevor wir darüber sprechen, sollten wir uns über sinnvolle Vorgaben > und daraus folgend eine sinnvolle Architektur unterhalten. Denn die > beinhaltet dein Programm nicht. > > Und: Die obige Anforderungsliste ist alleine schon kryptischer als das > zugehörige C-Programm. Schon klar. Die Ausreden gehen gleich wieder los- und woher wußte ich nur, daß ausgerechnet Du den Anfang machst ;-) Deine Vorstellungen von "sinnvoller Architektur" kannst Du woanders einbringen. Hier gehts nur darum, die beschriebene, sehr einfache Funktionalität kürzestmöglich umzusetzen. Toi toi toi...
Gerhard O. schrieb: > http://www.zoe-online.org/dateien/Einblick_02_11.jpg > > Seufz... Ja, die Aufgabe ist für C nicht einfach ;-( Dieses verdammt sperrige Sprachinstrumentatium !
:
Bearbeitet durch User
Moby A. schrieb: > Schon klar. > Die Ausreden gehen gleich wieder los- und woher wußte ich nur, daß > ausgerechnet Du den Anfang machst ;-) > > Deine Vorstellungen von "sinnvoller Architektur" kannst Du woanders > einbringen. Hier gehts nur darum, die beschriebene, sehr einfache > Funktionalität kürzestmöglich umzusetzen. Die Kernaussage der meisten Diskussionsteilnehmer ist: "C verbraucht selbst bei kleinsten Programm in der Regel (wenn überhaupt) nicht wesentlich mehr Resourcen als ein hochoptimiertes Assembler-Programm UND ab mittelgrossen Programmen ist es durch Assembler nicht mehr zu schlagen." Und du kommst her, und verlangst, diese Behauptung zu beweisen, indem eine C-Umsetzung deines Mickymausprogramms kein Byte mehr brauchen darf als deine Assembler-Version? Absurd.
... es ist unglaublich mit welcher Geduld mit Moby diskutiert wird... Jetzt habe ich mir fast den ganzen Abend lang die Texte gelesen, manchmal amüsiert, dann wieder gelangweilt und dann wieder hoch erstaunt ob einer extremen Ignoranz (von Seiten Moby). Ich habe lange Jahre programmiert, den C64 in Assembler, einen Schneider CPC, mein erster ganzer Stolz, einen Commodore PC1 (mit einem wahnwitzig schnellen 8088 CPU 4,7MHZ ... langsamer ging es auf PC Basis nie). Die habe ich der Effizienz wegen noch in Maschinensprache programmiert, wobei beim Schneider CPC und dem PC1 schon auch Turbo Pascal eingesetzt wurde (und auch zu diesen Zeiten gab es schon die Glaubenskriege um die Sprache). Zunehmend (mit leistungsfähigeren Teilen) wurde Maschinensprache immer seltener (und mein letztes großes Projekt - irgendwann Anfang der 80er - war ein Texteditor der den maximalen Speicher Segementgrenzen hinweg verwenden konnte. DA war auf den damals langsamen Kisten Pascal und C zu langsam dafür). Ich hatte DOS gleichzeitig gehasst und geliebt. Mein erster Controller war ein 8048 und den musste ich mangels vorhandenem Compiler in Maschinensprache programmieren. Auf Controllerebene das letzte große Projekt in (reiner) Maschinensprache war ein Logger, der über Temperatureinwirkung über der Zeit ein bestimme Qualitätsaussage zu einem Produkt machen mußte. Was für ein Grauen !!!! Das Gerätchen mußte über serielle Schnittstelle eine klare Aussage in Gleitkommadarstellung machen. Bei der Verrechnung der Daten mußte ein Logartihmus programmiert werden. !!!! Sowas ... in Maschinensprache ... will ich nie mehr machen müssen! Vllt. war ich "besser" als ein Compiler (aber ich wage das mal zu bezweifeln). Jeder hier (außer wohl Moby) weiß, wann er welche Sprache einsetzt und wann er (wenn es halt nicht mehr anderst geht) wirklich Maschinensprache einsetzt. Bei den heutigen Controllern, bei denen nicht mehr die Leistungsfähigkeit des Controllers den Preis desselbigen bestimmt, sondern die Absatzzahlen, müssen - glücklichweise - nicht mit jedem Byte gegeizt werden damit etwas läuft. Wie hier schon oft erwähnt: Entwicklungszeiten sind mit ganz großers Sicherheit in Assembler länger (wenn es nicht gerade Trivialprogramme sind). Hier schreiben Koryphäen ihres Fachs wie Jörg Wunsch (um einen einzigen mal zu nennen), dem ich ungesehen fast jedes Wort glaube was er schreibt und ich wundere mich sehr, woher sie die Geduld und die Motivation genommen haben sich mit Moby auseinander zu setzen. Ich gebe zu, dass mich Maschinensprache auch heute noch reitzt und ich das auch immer wieder mal zum Spaß anpacke und ich mich drüber freue mit wie wenig Code man etwas anstellen kann. Auch zum Lehren wie das Ding das man da programmiert denn eigentlich wirklch funktioniert, zum Zeigen, dass man eine Subtraktion durch eine Addition mit mit dem Komplement bewerkstelligt werden kann ist es super. Fürs Schreiben von kompletten Appliationen jedoch nicht. Meine Hochachtung gilt hier all denjenigen Experten, die sich mit Moby auseinandergesetzt haben und es wohl auch weiter tun werden (allerdings müssten sie wissen, dass es aus cli(); while(1); sei(); kein Entrinnen gibt, das Wiedereinschalten der Interrupts nie stattfindet und sich in der while-Schleife die "Diskussion" (es ist keine) mit Moby wiederfindet. Gute Nacht allen, die vllt. noch lesen !
P. M. schrieb: > ab mittelgrossen Programmen An die Vorstellung eines 1-10K Asm Programms und die Annahme, jemand würde das in C neu formulieren wage ich gar nicht erst zu denken, wenn sich schon bei 200 Bytes jeder C'ler hier die Zähne ausbeißt. Damit bleibts bei Aussage gegen Aussage. P. M. schrieb: > Und du kommst her, und verlangst, diese Behauptung zu beweisen, indem > eine C-Umsetzung deines Mickymausprogramms kein Byte mehr brauchen darf > als deine Assembler-Version? Absurd. Absurd wäre wohl die Annahme, daß Du das schaffst. Mit Übung, Vorbereitung und System lassen auch noch viel größere Asm-Programme C im Ressourcenverbrauch im Regen stehen, da summieren sich die Einspareffekte noch. Irgendwann setzt dann mal die Übersicht sinnvolle Grenzen- aber weit über dem hinaus, was Experten wie Du vielleicht für möglich halten.
Angehängte Dateien:
-
image.jpeg
61 KB
Ralph S. schrieb: > (allerdings > müssten sie wissen, dass es aus > > cli(); > while(1); > sei(); >kein entrinnen gibt... Was seid ihr doch für Nachteulen;-) P.S. Den Arduino Watchdog müßt Ihr entschuldigen, konnte keinen für den AVR finden...
:
Bearbeitet durch User
... lach, ich geb mich geschlagen .... mit dem Wachhund... (ob ich jetzt fieberhaft nach einem AVR OHNE WDT suchen soll? Vllt. findet sich ja noch irgendwo ein altes Exemplar bei dem das nicht implementiert ist.... bevor jetzt jemand kommt: Reset-Taste zählt nicht)
Ralph S. schrieb: > ... lach, ich geb mich geschlagen .... mit dem Wachhund... > > (ob ich jetzt fieberhaft nach einem AVR OHNE WDT suchen soll? Vllt. > findet sich ja noch irgendwo ein altes Exemplar bei dem das nicht > implementiert ist.... bevor jetzt jemand kommt: Reset-Taste zählt nicht) Ganz so war das doch nicht gemeint.;-)
Ralph S. schrieb: > ... es ist unglaublich mit welcher Geduld mit Moby diskutiert > wird... Diese Energie wird nun wohlweislich nicht in eine C-Version meines simplen Projekts gesteckt- und damit in den einzig möglichen, reellen Vergleich. Das gibt doch zu denken... Interessant auch, was Du alles als Diskussion bezeichnest ;-) > Fürs Schreiben von kompletten Appliationen jedoch nicht. Für so einen kleinen AVR ist das bei 8-Bit MSR kein Problem. Nur keinen Elefanten aus ner kleinen Maus machen ... > in der while-Schleife die "Diskussion" (es ist > keine) mit Moby wiederfindet. Die While-Schleife läuft so ab: - Moby beschreibt und zeigt die Effizienz von Asm. - die Cler erkennen diese (manchmal nur versteckt an) - da aber nicht sein kann was nicht sein darf: Attacke! (alle Mittel sind recht) Goto 1 ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Die While-Schleife läuft so ab: > - Moby beschreibt und zeigt die Effizienz von Asm. Guten Morgen Moby, wann schnallst due endlich, dass Effizienz nicht nur Flash- und SRAM Verbrauch bedeuten, sondern die hier bereits in aller Länge und Breite dargelegten anderen Faktoren beinhaltet!!! > - die Cler erkennen diese (manchmal nur versteckt an) Die "Cler" hier kennen sich meist alle viel besser und tiefer mit ASM aus als du. Und jeder weiß, wann und warum die eine oder die andere Art des Programmierens für ihn sinnvoller und effektiver ist. Dein "sehr spezieller" Datenlogger loggt zumindest keinen hinter dem kalten OPfen hervor. Bei einem Projekt, f+r dass das Gehirn wenigstens warmläuft sähe das sicher anders aus. > - da aber nicht sein kann was nicht sein darf: Attacke! > (alle Mittel sind recht) Das stimmt allerdings. Besser wäre es, das Thema von nun an zu ignorieren, weil es so sinnlos ist. Es ist scheißegal, ob das Programm 3 Byte größer oder kleiner ist, 4 Byte SRAM belegt oder nicht. Und DAS ist der Punkt, den du beharrlich verteidigst. Leider für den Restderwelt grundsätzlich bedeutungslos. Vlt. erschlägt ja auch jemand den ganzen Müll hier mit einem C Programm das tatsächlich kürzer ist, und dich damit mit deinen eigenen Waffen -nein, Dogmen.
Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu haben ist Moby irgendwie wirklich verzweifelt.... Nicht dass du anscheinend wirklich ausgeblendet hast, dass dein erstes ultimatives Programm verloren hast, du predigst von Planung, Ordnung, Blabla und hast immer fehlerhaften Code gepostet (Wie auch immer das passieren kann) Du ignorierst Gegenfragen. Das Argument der potentiellen Erweiterbarkeit deiner Projekte ist inzwischen kaum noch zu hören. DAS war ja dein Argument manisch Ram und Flash zu sparen - als Karl Heinz mal fragte, was genau an 1 kB Flash an Erweiterungen im Raum stehen könnten hat man natürlich nix gehört. Wenn dein Sensor eine Kennlinie bekommen muss, passt die nicht rein. Wenn du die Kennlinie berechnen könntest, wäre es keine typische 8 bit Anwendung... sic. Inzwischen ist das aber auch im Hintergrund. Jetzt ist deine neue Sau ein Stack der keiner ist.... Wie wäre es mit einem Remi? Deinen Code als inline asm in einem C Programm? Dass du nur ein einziges, künstlich konstruiertes Eisen im Feuer hast (was ja trotz Planung verbuggt war) und dieses Eisen wirklich nur seiner selbst willen von dir hochgehalten wird blendest du wirklich aus? Selbst um eine Aussage zu untermauern wie 'bis 1kB ist händischer asm Code einem c Code in puncto Flash/Ram Verbrauch bzw Geschwindigkeit überlegen' wäre etwas mehr als eine statistische Ausnahme angesagt. Mach doch mal bei einem angebotenen Vergleich mit. Gerade diejenigen die es dir angeboten haben sind faire Leute, die dich nicht wegen etwaiger Fehler zerreißen werden. Es lesen viele mit, die sich bestimmt auch als Hobbyisten zu Assembler bekehren lassen würden. Du würdest dir einen Namen machen. Also jetzt nicht nur als Witzfigur.
Moby A. schrieb: > Also mir wär das peinlich ;-) Ich habe nicht das Gefühl das Dir noch irgendwas peinlich ist.
Frage (an die Allgemeinheit) zu dem ADC und Durchschnitt.. moby macht ja aus den 8 Werten einen Durchschnitt, der dann aber auch wieder nur 10 bit hat.. ich hab es bei meinem Helligkeitssensor so gemacht, dass ich einfach 10 Werte addiere. in der Hoffnug dadurch einen höhere genauigkeit zu erhalten (vorallem bei dämmerung) (also ungefähr 13Bit) ist das unrealistisch? sind die (nur) 10Bit schon unrealistisch? warum moby hier einen durchschnitt rechnet, verstehe ich nicht, gehts hier um Falschmessungen die dann nur 1/8 ins ergebnis einfließen sollen? muss man das machen? konnte bei mir jetzt nicht feststellen dass da auch mal was falsch gemessen wird.. würde man dann nicht 10 Werte messen und min und max weglassen? einen Durchschnittüber die Zeit (300ms) will moby eh nicht (bzw ist es ihm egal? die doku ist hier sehr "mager")
:
Bearbeitet durch User
Markus M. schrieb: > Es ist scheißegal, ob das Programm 3 > Byte größer oder kleiner ist, 4 Byte SRAM belegt oder nicht. Für Moby eben nicht. diese 3 Byte Flash und 4 Byte RAM sind sein Notnagel, sein letzter Strohhalm. C ist ausgelegt für die Benutzung eines Stacks und der AVR ist ausgelegt für C. Trotzdem führt er immer wieder den Stackverbrauch als DAS Kriterium, als die härteste aller Anforderungen an. Weil er weiß dass er damit jedem Compiler massive Knüppel zwischen die Beine wirft. Da könnte das Programm tausendmal schneller implementiert, tausendmal besser lesbar und tausendmal besser erweiterbar sein. 1 Byte Stack (ne sorry, 3 - denn Moby braucht ja auch 2) und du hast verloren. Das ist so wie wenn du gegen Usain Bolt im Sprint antrittst, ihm aber Arme und Beine zusammenbindest. Du kannst dich nachher vielleicht gut fühlen, aber die Aussagekraft so eines Experimentes kann man wohl bestreiten... Ich zitier mich mal selbst: le x. schrieb: > Der wirklich eigentlichen Grund für diese Forderung ist wirklich ein > ganz anderer: > Du weist natürlich, dass die Sprache C ausgelegt ist für die Nutzung > eines RAMs. C ist außerdem massiv auf einen Stack angewiesen (wenn man > keinen Krüppel-Code schreiben will), dieser befindet sich traditionell > ebenfalls im RAM. > > Indem du also die Nutzung des RAMs verbietest ist die Aufgabe also ohne > Klimmzüge* nicht mehr lösbar. Auch eine Möglichkeit einen "Vergleich" zu > gewinnen...
Moby A. schrieb: > Diese Energie wird nun wohlweislich nicht in eine C-Version meines > simplen Projekts gesteckt- und damit in den einzig möglichen, reellen > Vergleich. Das gibt doch zu denken... Warum auch. Braucht man 20B weniger Flash aber 1Byte mehr SRAM -> Verloren Braucht man kein SRAM aber 1Byte mehr Flash -> Verloren Braucht man weniger Flash UND weniger SRAM -> Verloren Für den dritten Fall wirst Du Dir dann irgendwas ausdenken was jetzt ganz plötzlich ein unglaublich wichtiges Kriterium ist. Nutzloses RAM zu initialisieren oder auf einem Bein zu hüpfen und dabei wie ein Huhn zu gackern oder sonst was. Zur Not muß die Zeichenlänge des Quellcodes herhalten oder der RAM Verbrauch des Compiler auf dem Entwicklungssystem oder wie viele Mausclicks man braucht um die IDE zu starten. Dir wird schon was einfallen was man als völlig hirnrissiges Argument mißbrauchen kann. le x. schrieb: > Hier der anscheinend letzte Stand dieser Anforderungsliste: Super. Eine Checksumme die so schwach ist das ich würfeln kann ob die Werte wirklich stimmen. Völlig ineinander verwurstelte Daten die ich am Zielsystem erst wieder auseinandernehmen muß um was damit machen zu können. Eine synchrone unidirektionale Punkt zu Punkt Verbindung bei der im Zeitlupentempo Daten übermittelt werde statt ein vernünftiger Feldbuss mit Master / Slave Protokoll und starker CRC. RS485, Lin, Can, DALI, herje es gibt so viel Busse die alle mehr können als dieser Unfug. Wenigstens eine Manchester Codierung für Gleichspannungsfreie Datenübertragung mit Impulsübertragern und Taktrückgewinnung aus den Daten hätte man doch machen können um irgendwas sinnvolles bei einem proprietären Bus zu machen. Den Teil wo die Entprellung der digitalen IOs stattfindet oder die Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden können. Mit Verlaub. Das ist vollkommener Müll. Warum sollte man sich die Mühe geben so einen sinnlosen Kram zu programmieren der unzuverlässige Daten erhebt und auf eine unflexible und unzuverlässige Art übermittelt. Die unterste Schmerzgrenze für Sensor / Aktor Knoten sehe ich bei adressierbaren Master / Slave Feldbussen mit min. 16 Teilnehmern.
Michael K. schrieb: > Den Teil wo die Entprellung der digitalen IOs stattfindet oder die > Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden > können. Das ist keine typische 8bit MSR Anwendung. >Master / Slave Protokoll und starker CRC. >RS485, Lin, Can, DALI Das verbraucht alles RAM und Flash. => Wird ausgelagert.
Matthias L. schrieb: > Michael K. schrieb: >> Den Teil wo die Entprellung der digitalen IOs stattfindet oder die >> Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden >> können. > > Das ist keine typische 8bit MSR Anwendung. Damit treibt Moby die ganzen Anfänger ins 32bit Lager. Die lesen was für Moby typische 8bit Anwendungen sind nehmen lieber gleich einen STM32. Matthias L. schrieb: >>Master / Slave Protokoll und starker CRC. >>RS485, Lin, Can, DALI > Das verbraucht alles RAM und Flash. => Wird ausgelagert. Das was wirklich völlig sinnloser Flash und Ram Verbrauch ist nennt Moby eine typische 8bit MSR Anwendung. Nach meinem Empfinden das nicht mehr als ein 8bit MSR 'Hello World' Das primitivste Grundgerüst eines Programmes das nicht mehr kann als zu zeigen das man prinzipiell ein Programm zum laufen bekommt.
Moby A. schrieb: > Die While-Schleife läuft so ab: > - Moby beschreibt und zeigt die Effizienz von Asm. > - die Cler erkennen diese (manchmal nur versteckt an) > - da aber nicht sein kann was nicht sein darf: Attacke! > (alle Mittel sind recht) > > Goto 1 ;-) Falsch.
1 | #define PHRASENDRESCHERMODUS 0
|
2 | #define IMMER_AN 0
|
3 | |
4 | while(PHRASENDRESCHERMODUS==IMMER_AN)printf("Mit Uebung, Vorbereitung und System..."); |
mfg.
:
Bearbeitet durch User
Moby A. schrieb: > b) kein Byte Flash mehr verbraucht werden Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und komplett versagt?
Moby A. schrieb: > An die Vorstellung eines 1-10K Asm Programms und die Annahme, jemand > würde das in C neu formulieren wage ich gar nicht erst zu denken, wenn > sich schon bei 200 Bytes jeder C'ler hier die Zähne ausbeißt. > Damit bleibts bei Aussage gegen Aussage. Andersrum: Du weisst haargenau, dass du nur bei so einem Miniprogramm eine Chance hast. Kein Mensch schreibt in nützlicher Frist ein 10kB+ Assembler-Programm, das einen guten C-Compiler schlägt. Und nur beim Mini-Programm kann man darauf hoffen, dass ein kleiner (fixer) C-Overhead den Speicher-Verbrauch doch noch um die entscheidenden* paar Bytes hin die Höhe treibt. * "Entscheidend" im Mobyschen Sinn, nicht nach sinnvollen Designkriterien.
>in nützlicher Frist
Hier fehlt auch das (*). Denn das ist bei jedem (ausser Moby) eine
wichtige Ressource.
Moby A. schrieb: > Also mir wär das peinlich ;-) > > > So eine Aussage wär mir auch peinlich... Also da muß ich mich schon wundern. Bis jetzt war dir doch echt nix zu peinlich. Z.B. das hier Moby A. schrieb: > Mach Dir > lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau > gestellten Assembler-Überlegenheit zu begegnen ist ;-)
>> in der Hoffnug dadurch einen höhere genauigkeit zu erhalten (vorallem >> bei dämmerung) (also ungefähr 13Bit) >> ist das unrealistisch? Ja Schaust du letzten Beitrag unter 2 (Seitenaufteilung). Da bin ich darauf eingegangen und habe Fotos beigefügt von dem was geht. Ist aber keine typische Anwendung für kleine AVRs :-) braucht zu viele Resourcen :-) 12 BIT bei 256 Werten kannst du in der Praxis erwarten, mehr ist nicht drin.
>12 BIT bei 256 Werten
12bit ist grösser 8bit. Und 256 ist auch grösser 8bit
=> keine typische 8bit Anwendung.
@Bernd Noll danke es ist zwar Seite 5 und nicht 2 und man kann sowas auf verlinken Beitrag "Re: Assembler wieder auf dem Weg nach vorn" aber hat mir schonmal sehr geholfen.
:
Bearbeitet durch User
Johann L. schrieb: > Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm > findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und > komplett versagt? Nein, keinesfalls. Wurde ja schon gemacht. Das, was die dann kürzere Lösung notwendigerweise weggelassen hat, wird zum zwingend notwendigen Feature der anderen Implementierung erklärt. Das ist ja in seinem Sinne durchaus folgerichtig, denn es gibt ja keinerlei „offizielle“ Spec außer der bestehenden Implementierung. Damit ist es völlig klar, dass jegliche alternative Implementierung bei ihm keine Chance hat. Selbst eine Implementierung in C müsste notwendigerweise exakt den gleichen Assemblercode liefern, um akzeptiert zu werden.
Jörg W. schrieb: > Das ist ja > in seinem Sinne durchaus folgerichtig, denn es gibt ja keinerlei > „offizielle“ Spec außer der bestehenden Implementierung. Wobei es mittlerweile ja eine vom ihm gereviewede und kommentierte Spec gibt. Von dem her müsste das jetzt als "offiziell" gelten.
Moby hat doch geschrieben
> c) kein weiteres SRAM ab 60H und höchstens 2 Byte vom Stack benötigt
Damit dürfte klar sein dass das C Programm keinen SRAM verwenden darf.
Ausser 2 Bytes vom Stack.
Ergo: Wenn das C-Programm kleiner ist (Flash) und keinen SRAM verbraucht
hast gewonnen.
Ausser Moby fällt dann wieder was ein ;-)
Matthias L. schrieb: >>12 BIT bei 256 Werten > > 12bit ist grösser 8bit. Und 256 ist auch grösser 8bit 256 Werte passen in 8 Bits. Nicht aber der Wert 256. ;-)
Moby A. schrieb: > Gerhard O. schrieb: >> http://www.zoe-online.org/dateien/Einblick_02_11.jpg >> >> Seufz... > > Ja, die Aufgabe ist für C nicht einfach ;-( > Dieses verdammt sperrige Sprachinstrumentatium ! Mit Verlaub, Du hast Dich verlaufen. Und daß Du mit einigem rhetorischen Geschick die Horden, die Dir hier ausführlichst widersprachen, zunehmend aufs Glatteis geführt hast*), macht es nicht besser. Vergiss den TIOBE-Index. Man muß nicht dieses alte Goebbels-Zitat (->http://www.statistik.baden-wuerttemberg.de/Veroeffentl/Monatshefte/PDF/Beitrag04_11_11.pdf) bemühen ("Glaube keiner Statistik ..."), um zu begreifen, daß bloße Popularität auch im Bereich der Programmiersprachen kein vernünftiges Kriterium für irgendwas ist. Abgesehen davon erkennten diejenigen, die diesen schlechten Spruch klopfen, erfahrungsgemäß eine gefälschte Statistik nicht mal dann, wenn sie sie in die Nase bisse. Wenn ich anfangs noch eine gewisse Sympathie den Ansatz und das Motiv betreffend hatte, das ich bzgl. Deines Anliegens zu erkennen glaubte, nämlich den Ansatz, gegen den Trend mit modernen Mitteln minimalistische Lösungen zu erkunden, so sehe ich inzwischen, daß dafür offenbar entweder die Kenntnisse oder das Interesse fehlen, oder beides. Was Du und nicht nur Du nämlich übersiehst und was in den beiden obigen Bemerkungen herauskommt ist der Glaube, daß mit ASM hier und C dort sich gewissermaßen komplementäre Ansätze gegenüberstünden, deren Vorzüge es auszufechten gelte. Wenn man sich aber die Entwicklung der Programmiersprachen der letzten rund fünfzig Jahre betrachtet, beginnend mit Autocoder https://en.wikipedia.org/wiki/Autocoder (ca 1950), Fortran (ca 1957), Algol (1958), Lisp (1958), Snobol (1962), PL/I (1964), APL (1965), Simula (1967), Prolog (1972), ML (1972), C (1973), Haskell (1990), Rust (2010), usw. so sieht man, daß C keineswegs die abstrakte, abgehobene, sperrige Programmiersprache darstellt, die Du darin zu sehen glaubst, sondern eine späte Regression, eine Rückkehr (fast) zu der Sprachebene des Assembler, wenn man aber auf die Erfahrung mit Sprachdesign, Compilerbau und Codegenerierung für Sprachen wie PL/I, Algol, Algol68, Lisp oder Fortran zurückblicken kann. Was man halt macht, wenn man eine PDP11 geschenkt bekommt und damit ein kleines OS portieren (i.e. reimplementieren) möchte, ohne auf den Komfort einer vernünftigen Programmiersprache verzichten zu müssen. Money quote aus http://www.bell-labs.com/usr/dmr/www/chist.html "...and we regretted losing the advantages of writing programs in a language above the level of assembler, such as ease of writing and clarity of understanding". Mein Hauptkritikpunkt an C ist der unterbelichtete Preprocessor. Ein Assembler, mit dem ich vor 'zig Jahren in einem größeren Projekt gearbeitet habe, konnte in der Makrophase erheblich mehr als der C preprocessor heute, so daß sich auf Basis dessen durchaus Kontrollstrukturen oder kleinere DSL bauen ließen. Mein Ansatz, hätte ich auf dem Gebiet irgendwelche Aktien, wäre zu untersuchen, ob sich z.B. ein runtimelibfreies Rust soweit abspecken läßt, daß sich damit auch Plattformen unterhalb des üblichen 32+-Bit-Geraffels als Targent verwenden lassen. Das wäre aber Dickbrettbohren, weil auch das im Moment gegen den allgemeinen Trend geht und mit einer Menge Arbeit verbunden. *) Rhetorisches 101: ignoriere eisern alle guten Gegenargumente, dann werden Deine Widersacher im weiteren Verlauf zunehmend auch die schlechten Argumente durchprobieren. Du hattest aber in dem Moment verloren, als Du Dich geweigert hast, eine abstrakte, vernünftige und abschließende Spezifikation einer Aufgabenstellung zu formulieren, anhand deren man verschiedene Implementationsansätze vergleichen könnte. Der Rest ist nur noch davon ablenkendes Geplänkel.
>vernünftige und >abschließende Spezifikation einer Aufgabenstellung diese müsste aber alle Behauptungen von Moby beinhalten, also auch z.b. vorallem die angebliche einfache Erweiterbarkeit, müsste irgendwie "getestet" werden (ohne konkretes Beispiel wird das nicht gehen..) die "Einfachheit" ansich von ASM (es müsste also definiert werden, was "Einfach" ist..) welche Resourcen wie wichtig sind: also wer "gewonnen" hat wenn die (dann erweiterte) Version 1 Byte mehr RAM, die andere dafür 1 Byte mehr Flash braucht.. und man müsste definieren, was denn mit dieser "Aufgabenstellung" bezweickt werden soll, und ob das mit der "Aufgabenstellung" überhaupt möglich ist..
:
Bearbeitet durch User
Jörg W. schrieb: > Ich habe gestern ein Buch über Assembler-Programmierung geschenkt > bekommen. Gratuliere. > In seinem Vorwort enthält es den Absatz: > ... By its very nature, an assembly language has the same life > expectancy as the processor it supports perhaps 20 years at best. An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig. Eine Lebensdauer über ein halbes Menschenleben dürfte es eher treffen. Mit gut gelagerten Reserven allemal. Ansonsten ist die Feststellung unter einem weiteren Gesichtspunkt irrelevant: Egal ob mit Asm oder Hochsprache- ob viele kommerzielle Produkte (heutzutage und vor allem zukünftig bei beschleunigter IT-Entwicklung) auch noch in >20 Jahre unverändert Verwendung finden werden ist doch seeeehr zweifelhaft.
Moby A. schrieb: > An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig. Deine Selbstüberschätzung ist einfach unübertroffen. :-)
ich glaube der denkt nicht wenn er schreibt. Das sind nur Reflexe.
Wolfgang S. schrieb: > so sieht man, daß C keineswegs die abstrakte, abgehobene, sperrige > Programmiersprache darstellt, die Du darin zu sehen glaubst, sondern > eine späte Regression, eine Rückkehr (fast) zu der Sprachebene des > Assembler, wenn man aber auf die Erfahrung mit Sprachdesign, Compilerbau > und Codegenerierung für Sprachen wie PL/I, Algol, Algol68, Lisp oder > Fortran Na ja gemessen an den anderen heißen Kandidaten (für andere, z.T. viel größere Systeme) schon. Das interessiert aber hier jetzt herzlich wenig. > Du hattest aber in dem Moment > verloren, als Du Dich geweigert hast, eine abstrakte, vernünftige und > abschließende Spezifikation einer Aufgabenstellung zu formulieren, > anhand deren man verschiedene Implementationsansätze vergleichen könnte. Und ich sage Dir: Ich könnte noch 100 abstrakte, vernünftige und abschließende Spezifikationen der Aufgabenstellung formulieren und es würde an einem nichts ändern: Ein erfolgreicher C-Nachbauer findet sich nicht. Kann sich nicht finden. Asm bleibt C gegenüber bei 8-Bit MSR eben für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit Übung, Vorbereitung und System drangeht ;-) An der Ausrede für ein derart kleines, höchstdokumentiertes Projektchen, der C-Nachbau würde an einer Spezifikation scheitern, kann ich mich nur regelmäßig belustigen. So, gerade keine Zeit, in der Nacht dann wieder. Vielen Dank für die weiter zahlreichenden Rückmeldungen.
Werner P. schrieb: > ich glaube der denkt nicht wenn er schreibt. Das sind nur Reflexe. Hab auch schon an ELIZA gedacht.
Moby A. schrieb: > Asm bleibt C gegenüber bei 8-Bit MSR eben > für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit > Übung, Vorbereitung und System drangeht ;-) Ich folgere mal daraus: "Wenn man NICHT mit ÜVS rangeht ist ASM gegenüber C NICHT überlegen." Der selbe Satz, aber ohne die beiden Negierungen: "Ohne ÜVS ist ASM gegenüber C unterlegen." Jetzt bringen wir mal ÜVS auf beide Seiten ins Spiel, d.h. der ASM-Programmierer und der C-Programmierer benützen jetzt ÜVS. Dann wird daraus: "Mit ÜVS ist ASM gegenüber C mit ÜVS unterlegen." Oder, salopp ausgedrückt: Der ASM-Programmierer muss sich ganz schön ins Zeug legen (ÜVS) um mit einem systemlosen C-Programmierer mitzuhalten. Gibt sich der C-ler aber auch ein wenig Mühe (also jetzt auch ÜVS) kann der ASM-ler einpacken, denn dieser ist ja schon am Limit. Nichts anderes predigen wir dir ja auch schon die ganze Zeit. Find ich Prima dass der Thread doch noch zu einem Ergebnis gekommen ist das beide Seiten so unterschreiben können!
Moby A. schrieb: > An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig. Deine Meinung? Also dieses wackelige Ding, dessen gesamtes Fundament aus ein bisschen Assemblerprogrammierung besteht? Dieses Machwerk, in das du kein Wissen von erfahrenen Leuten einfliessen lässt? Ja, diese Meinung muss ja Gewicht haben.
le x. schrieb: >> für viele viele KB Code im Prinzip überlegen: Nämlich dann, wenn man mit >> Übung, Vorbereitung und System drangeht ;-) > > Ich folgere mal daraus: > "Wenn man NICHT mit ÜVS rangeht ist ASM gegenüber C NICHT überlegen." Diese Schlussfolgerung ist unzulässig.
A. K. schrieb: > Diese Schlussfolgerung ist unzulässig. Wo liegt mein Denkfehler? Pseudocode:
1 | WENN (ÜVS == TRUE) |
2 | DANN (ASM > C) |
Darf ich für den (nicht explizit vorhandenen) SONST-Pfad nicht (ASM < C) annehmen? (OK, eigentlich ASM <= C)
le x. schrieb: > Wo liegt mein Denkfehler? Dass die abstrakte Maschine namens „Moby AVR“ nicht nach den Regeln der Logik arbeitet.
Du hast die Zeile 42 überlesen.
if (das_passt_mir_nicht_in_den_kram) printf("verloren");
EDIT: Damit Moby das versteht. Kann das jemand nach ASM übersetzen?
le x. schrieb: > - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden > durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden) > - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits > - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits > - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits > - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits > - Bit 20: DINP1-LOW > - Bit 21: DINP2-LOW > - Bits 22-23: Checksumme über das Datentelegram > - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in > einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird Das ist in C auch nur eine einfache Zuweisung, bei dem man sich einfach den passenden Datentyp anlegt:
1 | typedef union { |
2 | uint32_t u32Val; |
3 | uint8_t u8Val[4]; |
4 | struct { |
5 | uint8_t uAdc1; |
6 | uint8_t uAdc2; |
7 | uint8_t uAdc12:2; |
8 | uint8_t uAdc22:2; |
9 | uint8_t bPin1:1; |
10 | uint8_t bPin2:1; |
11 | uint8_t uCRC:2; |
12 | };
|
13 | } tVal; |
14 | |
15 | // Das Demo mit 2 Arten der CRC Berechnung:
|
16 | void SetVal(tVal* aVal, uint16_t uAdc1, uint16_t uAdc2, uint8_t bP1, uint8_t bP2) |
17 | {
|
18 | // die Werte bestücken
|
19 | aVal->uAdc1 = uAdc1 & 0xFF; |
20 | aVal->uAdc2 = uAdc2 & 0xFF; |
21 | aVal->uAdc12 = (uAdc1 >> 8) & 0x03; |
22 | aVal->uAdc22 = (uAdc2 >> 8) & 0x03; |
23 | aVal->bPin1 = bP1 ? 1 : 0; |
24 | aVal->bPin2 = bP2 ? 1 : 0; |
25 | uint16_t iCRC = 0; |
26 | // CRC Berechnen anhand Tabelle:
|
27 | const uint8_t CRCTAB[] = {0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4}; |
28 | iCRC = CRCTAB[aVal->u8Val[0] & 0x0F]; |
29 | iCRC += CRCTAB[(aVal->u8Val[0] >> 4) & 0x0F]; |
30 | iCRC += CRCTAB[aVal->u8Val[1] & 0x0F]; |
31 | iCRC += CRCTAB[(aVal->u8Val[1] >> 4) & 0x0F]; |
32 | iCRC += CRCTAB[aVal->u8Val[2] & 0x0F]; |
33 | iCRC += CRCTAB[(aVal->u8Val[2] >> 4) & 0x03]; |
34 | aVal->uCRC = iCRC % 4; |
35 | // CRC Berechnen mit einer Schleife:
|
36 | iCRC = 0; |
37 | for (uint16_t i = 0; i <= 21; i++) { |
38 | if ((aVal->u32Val >> i) & 1) |
39 | iCRC++; |
40 | }
|
41 | aVal->uCRC = iCRC % 4; |
42 | }
|
Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle Schnittstelle. PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.
:
Bearbeitet durch User
le x. schrieb: > A. K. schrieb: >> Diese Schlussfolgerung ist unzulässig. > > Wo liegt mein Denkfehler? https://de.wikipedia.org/wiki/Kontraposition
Operator S. schrieb: > le x. schrieb: >> A. K. schrieb: >>> Diese Schlussfolgerung ist unzulässig. >> >> Wo liegt mein Denkfehler? > > https://de.wikipedia.org/wiki/Kontraposition Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird wohl nix...
le x. schrieb: > Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird > wohl nix... In C würde man ja zum Beenden der Endlosschleife einfach ein
1 | break; |
schreiben. ;-)
le x. schrieb: > Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird > wohl nix... Beenden? Aber... was soll ich dann mit meiner ganzen frei werdenden Zeit machen? Und Moby erst!
Markus M. schrieb: > PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. VERLOREN! Der Code DARF nicht auf einem mc ausserhalb von Mobys Universum laufen! Gruß, Stefan
Werner P. schrieb: > EDIT: Damit Moby das versteht. Kann das jemand nach ASM übersetzen?
1 | db MSG 'verloren' |
2 | |
3 | Loop: |
4 | LDI Z, MSG |
5 | CALL Sende_String_in_Z |
6 | JMP Loop |
>PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR.
Wie ineffizient ist das denn
Matthias L. schrieb: > Wie ineffizient ist das denn Das ist egal. Auf einem STM32 laufen keine typischen 8-Bit-MSR-Anwendungen. mfg.
Operator S. schrieb: > Beenden? Aber... was soll ich dann mit meiner ganzen frei werdenden Zeit > machen? Und Moby erst! Endlich C lernen.
le x. schrieb: > Darf ich für den (nicht explizit vorhandenen) SONST-Pfad nicht (ASM < C) > annehmen? Aus einer falschen Prämisse folgt nichts. Bei WENN a DANN b: a:true dann b:true a:false dann b:any
Matthias L. schrieb: > Werner P. schrieb: >> EDIT: Damit Moby das versteht. Kann das jemand nach ASM übersetzen? > >
1 | > db MSG 'verloren' |
2 | > |
3 | > Loop: |
4 | > LDI Z, MSG |
5 | > CALL Sende_String_in_Z |
6 | > JMP Loop |
7 | > |
> > > > >>PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. > > Wie ineffizient ist das denn Falsch, muß auf Tiny13 laufen und der braucht kein CALL, weil RCALL +-2k abdeckt und hat es deshalb auch nicht. Ob Moby es kennt? Bei entsprechender ÜVS (oder war es ÜSV?) kann man auch auf xMega ohne CALL auskommen. Man muß ja nur Caller und Callee richtig positionieren. Zudem: CALL braucht 4 Bytes statt den zweien des RCALL's. Damit werden der Nachwelt wertvolle unbenutzte Flash-Zellen vorenthalten. Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung" untersucht, dann kommen unbenützte Speicherbereiche schlecht weg.
:
Bearbeitet durch User
Gu. F. schrieb: > Endlich C lernen. Das würde er gerne. Hat er auch schon probiert. Aber C lässt sich von ihm nicht lernen. Programmiersprachen haben auch ihren Stolz. mfg.
Carl D. schrieb: > Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung" > untersucht, dann kommen unbenützte Speicherbereiche schlecht weg. Hihi genau. Und dank diesem Thread hier steht das auch ganz oben.
Matthias L. schrieb: > Carl D. schrieb: >> Wenn mal jemand unter Unweltschutzaspekten den Begriff "Verschwendung" >> untersucht, dann kommen unbenützte Speicherbereiche schlecht weg. > > Hihi genau. Und dank diesem Thread hier steht das auch ganz oben. War ja nicht extrem ernst gemeint. Aber etwas nutzlos zu produzieren, damit einer sich daran aufgeilt es nicht zu benutzen, ist doch leicht schräg, oder?
le x. schrieb: > Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird > wohl nix.. Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott. Ob mich daß bei Deinem Logik-Verständnis weiter oben überraschen sollte? Na dann wenigstens Dankeschön für die (letzte) Live-Demo der Sinnlosigkeit jeglicher wiederholter "Spezifikation". Oder? Markus M. schrieb: > Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle > Schnittstelle. > > PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige Bruchwerk aber noch nirgendwo. Von konkreten Ressourcenverbrauchs-Fakten ganz zu schweigen. Eine klassische serielle Schnittstelle wird von meinem Code auch nicht bedient. P. M. schrieb: > Also dieses wackelige Ding Langsam machst Du mit Deinen kompetenten Beobachtungen Carl D. Konkurrenz... Mein Code steht bombenfest, bewährt sich längst in der Praxis- aber Du machst mir nicht den Eindruck, daß Du Dich damit jemals befasst hast undoder ihn überhaupt verstehst. :-( > kein Wissen von erfahrenen Leuten einfliessen lässt Lass das mal in Deine C-Fassung einfließen. Da werd ich aber lange warten. Dann dann zeigt sich schnell wer hier wen belehren müsste ;-)
Moby A. schrieb: > Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott. Unglaublich! :-) Da hängt er schon seit einer Ewigkeit in den Seilen und trotzdem kommt immer sowas wie 'Hat ja gar nicht weh getan!'. Da wird der Kampf sicherlich über 2000 Runden gehen. Wobei...: Der Ringrichter wettet auf den Verlauf des Kampfes?! ;-/
Clemens M. schrieb: > Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu > haben ist Moby irgendwie wirklich verzweifelt.... Du solltest besser am RAM-Bedarf eines C-Compilers verzweifeln. Scheint ja ein fetter Pferdefuß des fetten C zu sein. Beim ganzen Rest Deiner konstruierten Jammerei erinnerst Du mich an einen gewissen Sheeva ;-) Michael K. schrieb: > Nutzloses RAM zu initialisieren Kein Problem Michael. Das und die Sleep Geschichte wird noch rausgestrichen! Für den Vergleich hier ist das überflüssig. Da wird der Volkszorn der Trolle, Stänkerer und verkrachten C-Existenzen zwar hier wieder hochkochen, jeder einigermaßen neutrale und rationale Beobachter wird mir aber zugestehen, daß nur gleiche mit gleicher Funktionalität verglichen werden sollte und eine Ram- bzw. Sleep Initialisierung nicht auf der Agenda äh "Spezifikation" steht. Macht dann nach Adam Riese weniger als 200 Bytes verbrauchter Flash ;-) > Mit Verlaub. > Das ist vollkommener Müll. Du meinst weil klar ist, daß man es in C nicht kürzer gebacken bekommt? > Die unterste Schmerzgrenze für Sensor Aktor Knoten sehe ich bei > adressierbaren Master Slave Feldbussen mit min. 16 Teilnehmern. Bist Du von der Industrie? Dann wär mir alles klar. So einer muß die überteuerten Preise dort irgendwie rechtfertigen. Schenk Dir das. Geht alles viel simpler, viel billiger ;-)
Ralf G. schrieb: > Unglaublich! ... sind meistens Dinge, deren Zustandekommen man falsch einschätzt ;-)
A. K. schrieb: > Hab auch schon an ELIZA gedacht. Da ist was dran ;-) So wie ein großer Teil der C-Überzeugungstäter hier konstant weg von den unangenehmen Fakten meines Projekts driftet müssen diese Leute konstant auch wieder zurück zu den wunden Punkten (=Ressourcenverbrauch) geführt werden. Da brauchts Eliza-gleiche Geduld ;-) Johann L. schrieb: > Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm > findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und > komplett versagt? Wer wird denn hier von Versagen reden? Der Vorteil simpler Codierung ohne viel Bürokratie bleibt Asm dann immer noch. Nur die Ressourcen-Geschichte hätte sich dann (für mich) erledigt. Du redest da aber von Wunschträumen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > le x. schrieb: >> Tja schade, ich da wollt ich den Thread friedlich beenden, aber das wird >> wohl nix.. > > Das heißt, Du wirfst nach wenigen Stunden schon das Handtuch? Oh Gott. > Ob mich daß bei Deinem Logik-Verständnis weiter oben überraschen sollte? > Na dann wenigstens Dankeschön für die (letzte) Live-Demo der > Sinnlosigkeit jeglicher wiederholter "Spezifikation". Oder? > > Markus M. schrieb: >> >> PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. > > Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige > Bruchwerk aber noch nirgendwo. Von konkreten Ressourcenverbrauchs-Fakten > ganz zu schweigen. Eine klassische serielle Schnittstelle wird von > meinem Code auch nicht bedient. > > P. M. schrieb: >> Also dieses wackelige Ding > > Langsam machst Du mit Deinen kompetenten Beobachtungen Carl D. > Konkurrenz... > Mein Code steht bombenfest, bewährt sich längst in der Praxis- aber Du > machst mir nicht den Eindruck, daß Du Dich damit jemals befasst hast > undoder ihn überhaupt verstehst. :-( > >> kein Wissen von erfahrenen Leuten einfliessen lässt > > Lass das mal in Deine C-Fassung einfließen. Da werd ich aber lange > warten. Dann dann zeigt sich schnell wer hier wen belehren müsste ;-) Moby, falls du das Theater hier selber ernst nehmen solltest.: Du bist der Einzige! Ja, DER EINZIGE. Welche Motivation sollte ein Leser hier haben, in seiner Freizeit ein Programm zu schreiben, welches er niemals für irgend etwas einsetzen wird? Ja, warum sollte er das wohl tun? Nur um über deine Stöckchen zu springen? Deinen Ego Trip weiter anzuheizen? Du bietest weder eine spannende Herausforderung noch sinnvolle Regeln. Dein beabsichtigter Ram-und-Flash Kontest ist wenig Anspruchsvoll, um nicht zu sagen einfach nur lächerlich. Du scheinst das nicht zu merken - als Einziger. Ich und auch kein anderer möchten dir den Erfolg deines privates Projektes und seine Funktion in Abrede stellen. Es ist und bleibt ein tolles Gefühl, selbst etwas auf die Beine gestellt und zum Laufen gebracht zu haben. Doch stellt sich dann niemand hin und schwört auf die Überlegenheit seiner Programmiermethode. Wenn du Interesse an einer vergleichenden Betrachtung gehabt hättest, wärest du den Bitten nach den Specs deines Projektes mit mehr Eifer nachgekommen und hättest nicht auf deinen ASM Code verwiesen. Wissen wir denn, ob der deine Specs überhaupt erfüllt? In der Schule haben wir gelernt, dass jede Aufgabe über die Aufgabenstellung formuliert wird. Je klarer die ist, umso weniger Streit gibt es bei der Interpretation der Ergebnisse. Lange Rede.. Wenn du wirklich Interesse hast, dann komm mit etwas vernünftigen, etwas worüber sich die sach- und fachliche Auseinandersetzung für alle Seiten hier lohnt. Deinen Kinderspielchen sind hier alle schon längst erwachsen. Mir scheint es, als ob selbst die fachliche Beurteilung der hier schon gebotenen Lösungen oder Teillösungen deinen Horizont meilenweit überschreitet. Zu keinem Ansatz hast du jemals Stellung bezogen. Warum sollte also jemand etwas liefern? Wozu? Du erwartest nur die nackte Programmgröße. Ich habe den Eindruck, dass du damit im falschen Forum gelandet bist. Wenn du das gleich wieder als Resignation vor der Aufgabe, Versagen der C-Fraktion, Üblegenheit deiner Progammierkunst oder dergleichen interpretieren wirst,.. es ist alles nur in deinem Kopf so.. ..und ich programmiere auch fast alles in ASM - noch, weil ich mehr und mehr von der Überlegenheit von C überzeugt bin und es deshalb lerne.
Nachdem ich die Antwort auf alle möglichen Fragen gefunden habe, hat man einfach die Fragen geändert... Nachdem ich alle Lösungen zu einem Problem gefunden habe, hat man das Problem geändert. Nachdem es keine Probleme mehr gab ... bin ich wieder zur Maschinensprache zurück gekehrt ( smile nein, bin ich nicht grundsätzlich ). Das wäre jetzt so, als würde man mir sagen: Hey, schreibe absichtlich wieder schier unwartbare Programme. Witzig ist schlicht: alte Programmteile (egal ob in Pascal, Delphi oder C) wie bspw. Interpolationsfunktionen, "Linearisierungen" von NTC Widerständen, Funktionsparser konnte ich von meinen uralten zum Teil aus C/PM Zeiten stammende Routinen relativ gut nach C portieren. Die meisten Assemblerfunktionen nicht (okay, in Wirklichkeit war mir der Aufwand zu groß und ich habs lieber neu geschrieben). Es ist für mich sowas von unglaublich, dass man sich auf das Niveau von Herrn M. herunterziehen lässt und seine "Anforderungsliste" übernimmt wo es doch hunderttausende Vorzüge einer höheren Sprache (egal welche) gegenüber ASM gibt. Wie kann man nur so verbohrt sein, seine "Lieblingssprache" auf so extrem wenige (und sorry, wirklich relativ triviale) Anwendungen zu begrenzen? Die Welt... besteht nicht nur aus (von Herrn M. definierten) 8 Bit Anwendungen. Ein bestes Beispiel: ich bin hoch fasziniert von einem Mitglied hier, der einen Softwaresynthesizer auf einem ATmega (und das in meiner Meinung nach guten Qualität) hinbekommen hat (ehrliche Hochachtung hierfür). Viele Teile des Syntesizers sind in C geschrieben und nur die wirklich zeitkritischen in Assembler. Ich war/bin wirklich davon fasziniert. Dieses Teil Lehrlingen gezeigt können diese meine Faszination (eigentlich zu Recht) nicht verstehen: "Herr xyz, das ist ja schön und gut, aber auf unseren STM Nucleoboards benötigt es hierfür keine Maschinensprache). Was erwiedert man einer solchen Aussage? Nichts, denn sie haben schlicht recht. Würde ich ein Spielzeug entwerfen, dass ich was weiß wieviele 1000 mal verkaufen würde, würde der Preis vllt. eine Rolle spielen und deshalb wohl hierfür ein AVR eingesetzt werden, aber selbst in diesem Falle ist der Hauptanteil in C geschrieben. Ich würde gerne mal einen Softwaresynthesizer von Herrn M. sehen, der komplett in ASM gemacht ist !!! Hier wird extrem viel ohne Beweise behauptet und jetzt lasse ich mich auf das gleiche ein: Ich erkenne an, dass ASM so viel flexibler und einfacher ist, wenn Herr M. einen Syntesizer schreibt (das sind jetzt Specs) die: - min. 4 stimmige unterschiedliche Instrumente spielen können - eine Mididatei die auf einem PC in ein beliebiges proprietäres Format gewandelt werden dürfen und einem AVR über ein Nachladen von einer SD Karte zugeführt werden - der Rauschabstand nicht kleiner als 50 dB betragen darf (ich hoffe dass Herr M. weiß was das ist) Ich (und das nehme ich mir heraus weil ICH und nicht Herr M. die Specs bestimmt) äußere: das ist eine 8 Bit Anwendung weil es auf einer 8 Bit MCU läuft ! ASM hat gewonnen, wenn er dieses in 3 Wochen zum Laufen gebracht hat ! Ich verschärfe jetzt nicht in dem ich verlange, dass er den Code den er erstellt hat nun auf einer anderen Plattform zum Laufen bringt (denn ich will den auf AVR funktionierenden Code nicht nach STM32 portieren, glaube aber, dass ich wohl doch in der Lage wäre das auch auf einem Nucleo hin zu bekommen). ( ich glaube ich kann jetzt schon ein höhnisches Gelächter von Herrn M. hören und ich glaube ich kann auch schon die Gebetsmühlenartig vorgetragenen unsinnigen "Argumente" und "Forderungen" hören ). Was ich wirklich nicht glauben kann ist, dass ich mich hinreisen lasse und hier einen Kommentar schreibe. Aber irgendwie ist das wie mit der Maschinensprache: Manche Dinge faszinieren ohne wirklich erkennbaren Grund ... und hier ist es die Ignoranz). Wenn Herr M. kein "Projekt" (ich sage mal, dass eine Minisensorplatine einfach kein "Projekt" ist) veröffentlichen will (weil uns das ja angeblich nicht "interessiert"), dann soll er doch mal wenigstens erzählen, welches seiner Projekte, die er ja schon erarbeitet hat, 10 KByte groß sind (Hex-File) und was die jetzt alles in allem können ! Was .... wurde denn in so großer Menge schon realisiert und in welcher Zeit? Warum richten sich die "Diskutanten" nach den Anforderungen von Herrn M., warum stellen sie nicht ihre eigenen Specs ? Hier im Forum wimmelt es nur so von wirklichen Schätzen bei denen sich manche Programmierer in C das Hirn verrenkt haben (smile, "nur" um etwas in den nächstkleineren Controller zu bekommen)... Ich will sehen wie Herr M. das schafft. Immer dann, wenn gerechnet werden muß, immer dann wenn floating point ins Spiel kommt, spätestens dann wird es mit ASM kritisch. Gute Nacht
Markus M. schrieb: > ..und ich programmiere auch fast alles in ASM - noch, weil ich mehr und > mehr von der Überlegenheit von C überzeugt bin und es deshalb lerne. ... es geht nicht darum, was "überlegen" ist, es geht darum, mit welchem Aufwand ein Problem bewältigt werden kann. Entwicklerzeit = Aufwand. Eliminiert ein geringerer Hardwarepreis einen höheren Entwickleraufwand, wird eine preiswertere Hardware verwendet, ansonsten eben nicht ! Preis Reichelt (okay, nicht WIRKLICH zwingend Bezugsquelle Nr. 1): ATtiny13 SOIC (1k Byte Flash / 64 Byte RAM) => 0,86 Euro ATtiny85 SOIC (8k Byte Flash / 512 Byte RAM) => 1,30 Euro Um wieviel länger darf ich da entwickeln, dass da noch etwas in den Tiny13 passt ?
Also ehrlich, wäre es nicht mal an der Zeit mal an die frische Luft zu gehen und einzuatmen und die schöne Natur zu bewundern. Mal Schifahren zu gehen oder Eislaufen, oder sonst irgendetwas, aber nur nicht mit der Elektronik verbunden. Da bekommt dann gleich eine andere Einstellung. Wenn man den ganzen Tag vor dem Monitor sitzt, verblödet man doch fast und frisst sich leicht in einer Furche fest. Gut gemeint, Gerhard
Moby A. schrieb: > Der Vorteil simpler Codierung > ohne viel Bürokratie bleibt Asm dann immer noch. Nur die > Ressourcen-Geschichte hätte sich dann (für mich) erledigt. Du redest da > aber von Wunschträumen ;-) Der Vorteil der simplen Codierung ist für dich, dass du deine simplen Programme auch ohne eine Hochsprache zu lernen gebacken bekommst. Moby A. schrieb: > So wie ein großer Teil der C-Überzeugungstäter hier konstant weg von den > unangenehmen Fakten meines Projekts driftet müssen diese Leute konstant > auch wieder zurück zu den wunden Punkten (=Ressourcenverbrauch) geführt > werden. Unangenehm ist lediglich dein infantiles Getue, weil nun nienamd mehr mit dir spielen will. Der Resourcenverbrauch in C ist in erster Line von dem abhängig, der vor dem Rechner sitzt. Das ist in ASM nicht anders. Falls du dir den Gefallen tust, und mal bischen C lernen würdest, wäre das deine erste Erkenntnis. Ich habe übrigens mal ähnlich verbockt auf C geschimpft. Grund war mein Frust über die "kryptische Syntax". Ja, sicher wäre es einfacher gewesen, ich hätte vor 30 Jahren damit begonnen. Stattdessen gab es da auch für mich Z80 in ASM und OP-Code. Das erste, was ich nach dem Kompilieren meiner C-Versuche mache, ist das Untersuchen der ASM Ausgabe des Compilers. Und ehrlich, ich war überrascht wie kurz und elegant der Compiler übersetzt. Tut er es mal nicht, dann hat das seinen Grund im Quellcode. Er sieht dann etwas, was ich übersehen, oder zumindest anders gemeint habe. Aber mit ÜVS wird das ASM Listing immer kürzer und knackiger.
Gerhard O. schrieb: > Mal Schifahren zu gehen oder Eislaufen Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf gefallen dabei. :o/ Ich bevorzuge doch lieber Fortbewegungsmittel mit ordentlichen Bremsen. :) Viele Grüße nach Kanada, ist vermutlich kühler dort als hier.
Ralph S. schrieb: > Die Welt... besteht nicht nur aus (von Herrn M. definierten) 8 Bit > Anwendungen. Da hast Du doch Recht! Nur für diese rede ich aber hier. Es sind aber immer noch Millionen... Z.B. im großen Feld Smart Home. Markus M. schrieb: > Du bist der Einzige! > Ja, DER EINZIGE. Und Du meinst, eine solche Feststellung hätte irgend einen Wert als fachliches Argument? Mich beeindruckt das nicht, das Ablenkungs-Theater von der von mir demonstrierten Asm-Effizienz hat aber einen gewissen Unterhaltungswert ;-) > Welche Motivation sollte ein Leser hier haben, in seiner Freizeit ein > Programm zu schreiben, welches er niemals für irgend etwas einsetzen > wird? Ja, warum sollte er das wohl tun? "Programm" ist erstens schonmal arg übertrieben. Zweitens muß das niemand tun. Wer aber meinen Aussagen zu den Ressourcenvorteilen von Asm überzeugend wiedersprechen will wird nicht umhinkommen, dies an meinem bereits fertigen Projektchen durch die Fakten einer C-Fassung zu belegen. So ein 200 Byte-Kaliber sollte für die behauptet hochexpertiösen Protagonisten hochproduktiven C's wirklich kein Problem sein ;-)
Jörg W. schrieb: > Gerhard O. schrieb: >> Mal Schifahren zu gehen oder Eislaufen > > Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf > gefallen dabei. :o/ Eislaufen ist heimtückischer wie Schifahren. Beim Schifahren hat man viel mehr Möglichkeiten zur Korrektur. > > Ich bevorzuge doch lieber Fortbewegungsmittel mit ordentlichen Bremsen. Da hast Du auch wieder recht. > :) > > Viele Grüße nach Kanada, ist vermutlich kühler dort als hier. Nicht zu schlimm. Nur -6 Grad im Augenblick obwohl es in ein paar Tagen sehr viel kühler werden soll(-20). Mit dem ganzen Schnee ist einer weihnachtlichen Stimmung nichts im Wege gelegt. Schnee in den Bergen ist reichlich und die Schifahrer sind Happy. Viele Grüße nach D, Gerhard
Markus M. schrieb: > Der Vorteil der simplen Codierung ist für dich, dass du deine simplen > Programme auch ohne eine Hochsprache zu lernen gebacken bekommst. So simpel sind offensichtlich selbst 200 Byte Asm Programme nicht, sonst hätten wir längst eine reelle C-Vergleichsmöglichkeit auf dem Tisch ;-) Und ja doch, Asm ist simpel! Da gibts bei 8-Bit MSR keinerlei Veranlassung auf Umständlicheres und Bürokratischeres und Komplexeres zu wechseln! Das spricht für Asm! > Unangenehm ist lediglich dein infantiles Getue, weil nun nienamd mehr > mit dir spielen will. Asm ist vergleichsweise infantil im Vergleich zu C. Man kann auch sagen simpler ;-) > Der Resourcenverbrauch in C ist in erster Line von dem abhängig, der vor > dem Rechner sitzt. Das ist in ASM nicht anders. Klar gibts auch diese Abhängikeit. Die interessiert hier aber nicht. Hier gehts um objektive Mängel von Hochsprache. Dokumentiert in sovielen C-Problemthreads. Um mal einen aktuellen aufzugreifen: Beitrag "Einstieg in C - komische Fragen" > Falls du dir den Gefallen tust, und mal bischen C lernen würdest, wäre > das deine erste Erkenntnis. Die ersten "Erkenntnisse" sind in obigem Thread wunderschön beschrieben. Ich komm geradezu ins Schwärmen ;-) > Das erste, was ich nach dem Kompilieren meiner C-Versuche mache, ist das > Untersuchen der ASM Ausgabe des Compilers. Das brauch ich nicht. Das hab ich zum Glück selber in der Hand. > Und ehrlich, ich war > überrascht wie kurz und elegant der Compiler übersetzt. Tut er es mal > nicht, dann hat das seinen Grund im Quellcode. Eleganz käme frühestens dann zum Tragen, wenn die Anzahl der Register nicht mehr ausreicht. Das ist mit Übung, Vorbereitung und System noch für viele viele KB AVR Code bei 8-Bit MSR kein Thema! > Aber mit ÜVS wird das > ASM Listing immer kürzer und knackiger. Nur leider nicht so knackig wie mit pure Asm ;-) Von den vielen richtig zu bedienenden Stell- und Optimierschrauben in C ganz abgesehen.
Moby A. schrieb: > So ein 200 Byte-Kaliber sollte für > die behauptet hochexpertiösen Protagonisten hochproduktiven C's wirklich > kein Problem sein ;-) Ist es auch nicht. Aber die beschäftigen sich lieber mit ernsthafteren Sachen. Und "Resourcenverbrauch" verstehen die/wir nicht als Flashverbrauch. Denn Flash verbraucht nicht. Er ist nach wie vor vorhanden. Und je besser er genutzt wird, um so besser ist die Resourcennutzung. Und um die geht es. Die Resourcen "Flash" und "SRAM" durch maximale Kastration der Programme nur unzureichend zu nutzen, stellt eine reine Resourcenverschwendung da. Warum möchtest du einen professionellen Softwareersteller dazu bewegen? Das Ergebnis wird weder besser noch schlechter, wenn es 2 Byte mehr oder weniger Speicher belegt. Das ist der Punkt!
Markus M. schrieb: > Die Resourcen "Flash" und "SRAM" durch maximale Kastration der Programme > nur unzureichend zu nutzen, stellt eine reine Resourcenverschwendung da. Du hast nicht verstanden, daß es mir um die prinzipiellen Vorteile von Asm geht. Was konkret wie in der Praxis genutzt werden kann steht auf einem anderen Blatt. Wenn Asm aber weniger Ressourcen erfordert (mit ÜVS) ist das doch nur gut. Wenn die Programmierung mit der bloßen Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC geschehen kann umso besser. > Warum möchtest du einen professionellen Softwareersteller dazu bewegen? Irrtum. Ich möchte eigentlich selber überzeugt werden. Das ist hier aber momentan auf einem ganz ganz schlechten Weg ;-)
Moby A. schrieb: > Asm ist vergleichsweise infantil im Vergleich zu C. > Man kann auch sagen simpler ;-) Das darf und kann nur jemand beurteilen, das beide Sprachen beherrscht. Schon aus meiner Sicht ist deine Aussage falsch.
Moby A. schrieb: > Wenn die Programmierung mit der bloßen > Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC > geschehen kann umso besser. Und genau das macht der C-Kompiler. Je nach Optimierungsstufe mal mit Schwerpunkt Codelänge oder Ausführungsgeschwindigkeit. Moby A. schrieb: >> Warum möchtest du einen professionellen Softwareersteller dazu bewegen? > > Irrtum. Ich möchte eigentlich selber überzeugt werden. Das ist hier > aber momentan auf einem ganz ganz schlechten Weg ;-) Daran ist dein bisherriges Verhalten nicht ganz unursächlich. Mein Rat: lerne ein bischen C und überzeug dich selbst. Dass du hier professionelle Hilfe bekommen kanst, weißt du sicherlich auch. Du wirst sehen, welch wunderbar kurzen und knackigen Code der Compiler produziert bzw produzieren kann. Damit kannst du deine ASM Kenntnisse sogar noch weiter ausbauen. Und der Aufwand, das Programm nach deinen Wünschen umzugestalten ist weitaus geringer als auf ASM Ebene. Das ist für mich ein entscheidender Vorteil. Diesen bezahlst du aber keineswegs mit mehr Overhead oder ähnlichem. Vlt bringst du ja auch C nur in irgend einer Hinsicht mit Bascom in Verbindung und beziehst daraus deine Vorurteile(?)
Markus M. schrieb: > Das darf und kann nur jemand beurteilen, das beide Sprachen beherrscht. Das kannst Du gern so festlegen. Mit C durfte ich durchaus schon intensiv Bekanntschaft schließen. Viel aussagekräftiger sind aber entsprechende Problemthreads hier, wo mit viel Erfahrung noch jeder Haken der Hochsprache zum Vorschein kam. Du mußt doch nicht glauben, daß die Vorteile von C (z.B.beim Rechnen, beim Handling größerer Datenmengen) mit Nix erkauft werden... Die allerbeste Beurteilung der C-"Vorzüge" aber ist, daß sich hier bislang keiner der sonst so sprachgewaltigen Experten imstande sieht, ein kleinwenig Funktionalität in C zu coden. Natürlich weiß ich warum ;-) Mit "lerne ein bischen C" hast Du bei mir keine Chance. Da will ich schon mehr sehen!
:
Bearbeitet durch User
Jörg W. schrieb: > Moby A. schrieb: > An dieser Stelle verschätzt sich der Autor meiner Meinung nach gewaltig. > > Deine Selbstüberschätzung ist einfach unübertroffen. :-) Sollte mich das jetzt von irgendwas überzeugen? Warum gehst Du nicht darauf ein was ich sagte? Vielleicht, weils richtig war ? ;-)
Moby A. schrieb: > Wenn die Programmierung mit der bloßen > Anwendung eines simplen Instruktionssatzes und dem Datenblatt des MC > geschehen kann umso besser. Noch was.. Geht es um das initialisieren der Peripherie, das setzen von Registern, das Hin- und Herschieben von Registerinhalten, um Bitmanipulationen, dann nehmen sich C und Hand-ASM nichts. Wenn dem Controller aber eswas "Grips" eingehaucht werden soll, wenn Berechnungen, die über einfachste Additionen hinausgehen implementiert werden sollen, wenn skalierbare Datenstrukturen angelegt werden müssen, Statemaschinen her müssen, oder das Programm einfach nur sehr umfangreich wird, dann ist der Compiler in jeder Beziehung besser. Ihn zu schlagen würde - wenn es überhaupt möglich wäre - einen enormen Zeitaufwand verursachen. Ich sehe in ASM mittlerweile keinerlei Vorteile mehr. Vertrau dem Kompiler, kontrolliere seinen Output. Du wirst sehen, der verarscht dich nicht und macht auch nicht heimlich Dinge die du nicht willst.
Jörg W. schrieb: > Selbst eine Implementierung in C müsste > notwendigerweise exakt den gleichen Assemblercode liefern, um akzeptiert > zu werden. Wie kommst Du auf diesen ausgemachten Blödsinn? Hinter solchen Aussagen scheint doch die nackte Angst durch: Wenn wir unseren C-Compiler nicht zum gleichen Asm-Output bewegen können haben wir verloren!!! ;-)
Moby A. schrieb: > Natürlich weiß ich warum > ;-) > > Mit "lerne ein bischen C" hast Du bei mir keine Chance. > Da will ich schon mehr sehen! Mit dieser Einstellung wirtst du das niemals sehen. Moby A. schrieb: > Du > mußt doch nicht glauben, daß die Vorteile von C (z.B.beim Rechnen, beim > Handling größerer Datenmengen) mit Nix erkauft werden... Geglaubt wird in der Kirche ;-) Die Vorteile werden nicht "erkauft". Sie resultieren aus der Fähigkeit des Compilers, den "Überblick" auch bei noch-so-großen Datenmengen nicht zu verlieren und jederzeit in wenigen Sekunden ein optimales Ergebnis zu liefern. Moby A. schrieb: > Die allerbeste Beurteilung der C-"Vorzüge" aber ist, daß sich hier > bislang keiner der sonst so sprachgewaltigen Experten imstande sieht, > ein kleinwenig Funktionalität in C zu coden. Natürlich weiß ich warum > ;-) Nein, du glaubst es nur zu wissen. Warum das so ist, habe ich oben dargestellt, und viele andere versuchen dir das auch klar zu machen. N8
Markus M. schrieb: > Geht es um das initialisieren der Peripherie, das setzen von Registern, > das Hin- und Herschieben von Registerinhalten, um Bitmanipulationen, > dann nehmen sich C und Hand-ASM nichts. Das ist richtig. Das hatte ich ein paar Hundert Beiträge weiter oben auch schon festgestellt. > Wenn dem Controller aber eswas "Grips" eingehaucht werden soll, wenn > Berechnungen, die über einfachste Additionen hinausgehen implementiert > werden sollen, wenn skalierbare Datenstrukturen angelegt werden müssen, > Statemaschinen her müssen, oder das Programm einfach nur sehr > umfangreich wird, dann ist der Compiler in jeder Beziehung besser Das ist ebenfalls richtig. Das hatte ich ein paar Hundert Beiträge weiter oben ebenfalls schon festgestellt. > Ich sehe in ASM mittlerweile keinerlei Vorteile > mehr. Das ist falsch. Denn Du unterschlägst mal eben Millionen MSR-Anwendungen, die eben keine aufwendigen Berechnungen und Datenstrukturen enthalten. > Vertrau dem Kompiler, kontrolliere seinen Output. Du wirst sehen, > der verarscht dich nicht und macht auch nicht heimlich Dinge die du > nicht willst. Dazu gilt es aber eine Bürokratie und Ineffizienz in Kauf zu nehmen, die für obige Anwendungen nicht zwingend sind.
Moby A. schrieb: > Klar gibts auch diese Abhängikeit. > Die interessiert hier aber nicht. > Hier gehts um objektive Mängel von Hochsprache. > Dokumentiert in sovielen C-Problemthreads. > Um mal einen aktuellen aufzugreifen: Ach Moby.. Diese Abhängigkeit ist _das Entscheidende!_ Und sie ist der Grund für die sog. "Problemthreads"!! Sie resultieren nicht aus Unzulänglichkeiten des Compilers oder der Sprache C! Na klar hat man als Anfänger noch nicht den Überblick über alles!! Ja, das ist in ASM alles einfacher, weil da kein Compiler zwischengeschaltet ist. Mit zunehmenden Lernerfolg wird man aber auf genau diese "Probleme" sensibilisiert. Das Denken nimmt einem der Compiler nicht auch noch ab! Und so weit, dass der Compiler weiß was der Mensch davor gemeint hat, oder gar Kommentare liest, soweit sind wir noch nicht! Was erwartest du eigentlich?
Moby A. schrieb: > Dazu gilt es aber eine Bürokratie und Ineffizienz in Kauf zu nehmen, die > für obige Anwendungen nicht zwingend sind. Beweise das an konkreten Beispielen und stelle die Nachteile in jeglicher Hinsicht nachvollziehbar dar. Definiere den Begriff Nachteil, bewerte ihn in jeglicher Hinsicht. Beweise, dass C überflüssigen Code produziert. Belege die "Bürokratie" entsprechend mit Codebeispielen. ..oder schweige zu diesem Thema für immer.
Moby A. schrieb: > Das ist falsch. > Denn Du unterschlägst mal eben Millionen MSR-Anwendungen, die eben keine > aufwendigen Berechnungen und Datenstrukturen enthalten. Millionen... Nenn uns doch bitte mal zehn.
Markus M. schrieb: > Beweise das an konkreten Beispielen und stelle die Nachteile in > jeglicher Hinsicht nachvollziehbar dar. Du kannst gerne an meinem fertigen Beispiel Deine besseren C-Verbrauchsfakten demonstrieren ;-) > Beweise, dass C überflüssigen Code produziert. Obiges gelingt 1000 C-Experten nicht ;-) > Belege die "Bürokratie" entsprechend mit Codebeispielen. Dafür brauchts nichtmal Beispiele. Dafür langt schon ein Blick ins dicke C-Buch ;-) > ..oder schweige zu diesem Thema für immer. Das könnte Dir so passen ;-) Nichtsdestotrotz wünsch ich Dir maximalen Erfolg mit Deinem C. So, jetzt kannst Du guten Gewissens schlafen gehen. Du hast alles versucht ;-)
Kinder, Kinder! Wenn ihr so weitermacht, dann schafft Ihr es bald ins Guiness Book of Records zu kommen... https://en.m.wikipedia.org/wiki/Guinness_World_Records
Moby A. schrieb: > Jörg W. schrieb: >> Selbst eine Implementierung in C müsste >> notwendigerweise exakt den gleichen Assemblercode liefern, um akzeptiert >> zu werden. > > Wie kommst Du auf diesen ausgemachten Blödsinn? > Hinter solchen Aussagen scheint doch die nackte Angst durch: Wenn wir > unseren C-Compiler nicht zum gleichen Asm-Output bewegen können haben > wir verloren!!! ;-) Nö, ein gewisser Moby hat es genau so geschrieben. Das ist der Nachteil schriftlicher Statements. Sie können jederzeit zu 100% rekonstruiert werden. Das mit der nackten Angst (vor was auch immer) trifft eher dich. > Obiges gelingt 1000 C-Experten nicht ;-) Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu korrigieren. Das ist nämlich dein eigentliches Problem: ein zementiertes Weltbild, zumindest beim Thema "Programmieren von MobySpartRam-Anwendungen". Andere machen das nur, wenn es knapp wird.
:
Bearbeitet durch User
Wie schafft ihr es eigentlich hier im Forum nächtelang Tinte zu verspritzen und dann am nächsten Morgen algorithmische Höchstleistungen zu leisten? Ich könnte das nicht.
Ralph S. schrieb: > Das wäre jetzt so, als würde man mir sagen: Hey, schreibe absichtlich > wieder schier unwartbare Programme. Da fehlt Dir einfach ÜVS ;-) > Wie kann man nur so verbohrt sein, seine > "Lieblingssprache" auf so extrem wenige (und sorry, wirklich relativ > triviale) Anwendungen zu begrenzen? Mein Beispiel ist zwar trivial, aber offensichtlich immer noch zu kompliziert. Größere Asm-Programme aus meiner Feder hätten erst recht keine Chance auf Vergleich- als einzig möglicher Beweismöglichkeit. > Ich würde gerne mal einen Softwaresynthesizer von Herrn M. sehen, der > komplett in ASM gemacht ist !!! Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und rechenintensiv ist. Damit ziemlich ungeeignet für Asm. > Ich verschärfe jetzt nicht in dem ich verlange, dass er den Code den er > erstellt hat nun auf einer anderen Plattform zum Laufen bringt (denn ich > will den auf AVR funktionierenden Code nicht nach STM32 portieren, > glaube aber, dass ich wohl doch in der Lage wäre das auch auf einem > Nucleo hin zu bekommen). Ich brauch meine Anwendungen nicht portieren. Da langt ein AVR auf ewig. Vor allem wegen Asm ;-) > ( ich glaube ich kann jetzt schon ein höhnisches Gelächter von Herrn M. > hören und ich glaube ich kann auch schon die Gebetsmühlenartig > vorgetragenen unsinnigen "Argumente" und "Forderungen" hören ). Was Du so alles hörst. Für Beiträge wie den Deinigen sollte ich mir wirklich mal ein Eliza-Programm zulegen, welches die Rahmenbedingungen meiner Aussagen für alle Neuankömmlinge permanent wiederholt. > Immer dann, wenn gerechnet werden muß, immer dann wenn floating point > ins Spiel kommt, spätestens dann wird es mit ASM kritisch. Ja ja, das Rechnen wieder... Hatte ich schon gesagt, daß mich bislang Floating Point und ähnliche schlimme mathematische Dinge verschont haben? Daß mir mein Smart Home automatisch zu Diensten ist muß irgend einen anderen Hintergrund haben ;-)
Moby A. schrieb: > Da fehlt Dir einfach ÜVS ;-) Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen! Wie soll man da am anderen Ende der Welt noch mitkommen...
Carl D. schrieb: > Nö, ein gewisser Moby hat es genau so geschrieben. Na das zeig mir mal! Da bin ich aber jetzt gespannt! Ich glaub ja Du willst mir irgendeine Deiner Aussagen oder Interpretationen unterschieben ;-) > Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu > korrigieren. Ach so? Für viele windelweich faktenlose Beiträge hier langts aber? Dabei hab ich doch gehört, daß C so hochproduktiv sein soll... Ach stimmt ja: Ich bin ja der Einzige und die Gegenseite hat diese große Erfahrung. Oh, daraufhin muß ich wohl umdenken... Was glaubst Du eigentlich korrigieren zu müssen? Ein funktions-äquivalenter C-Entwurf ist verlangt. Du wärst freilich der Letzte von dem ich das erwarten könnte. Stimmts?
Gerhard O. schrieb: > Moby A. schrieb: > Da fehlt Dir einfach ÜVS ;-) > > Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen! Übung. Vorbereitung. System. > Wie soll man da am anderen Ende der Welt noch mitkommen... Da wird das Diskussionsthema auch nicht so relevant sein. Hier gehts um deutsche Gründlichkeit ;-) Wo bitte lauscht Du denn gerade?
Moby A. schrieb: > Gerhard O. schrieb: >> Moby A. schrieb: >> Da fehlt Dir einfach ÜVS ;-) >> >> Was bedeutet denn ÜVS schon wieder - Ihr mit euren Abkürzungen! > > Übung. Vorbereitung. System. > >> Wie soll man da am anderen Ende der Welt noch mitkommen... > > Da wird das Diskussionsthema auch nicht so relevant sein. Hier gehts um > deutsche Gründlichkeit ;-) > Wo bitte lauscht Du denn gerade? Hallo Moby, Danke für die Erklärung. Ich lausche ganz aus der Ferne im Land der Holzfäller und Maple Syrup. Edmonton, Alberta, Canada Gruß, Gerhard P.S. Wer behauptet, daß wir in Kanada nicht gründlich sind?
:
Bearbeitet durch User
Gerhard O. schrieb: > Edmonton, Alberta, Canada Interessant. Lohnt sich denn die Reise dorthin ? (frage ich mal als potentieller Tourist). Was interessiert Dich denn am Thema Asm vs. C ?
Moby A. schrieb: > Gerhard O. schrieb: >> Edmonton, Alberta, Canada > > Interessant. > Lohnt sich denn die Reise dorthin ? (frage ich mal als potentieller > Tourist). > > Was interessiert Dich denn am Thema Asm vs. C ? Ganz ohne Frage. Wenn Du die Natur liebst, vor den Bären keine Angst hast(;-))und Dir die Abwesenheit von vielen Menschenansammlungen nichts ausmacht, kannst Du bei uns viel erleben. Ich verbringe meine Ferien meistens in den Rockys an der Westküste mit Bergwandern und finde es immer sehr erholsam. An sich findet man auch in kanadischen Städten Sehenswerten, nur kann ich Edmonton zur Zeit nicht empfehlen weil bei uns zur Zeit zu viel gebaut wird. British Columbia gefällt mir sehr gut. Die Gegend um Vancouver ist recht toll. Man kann viel unternehmen. Die Berggegend dort ist sehr beeindruckend. Die Nachbarschaft zwischen Pazifischem Gewässer und den vollbewaldeten Küsten schafft viele photogenische Momente. Was interessiert mich am Thema? Ich liebe die embedded uC Technik und bin beruflich und Hobbymäßig erwas damit vorbelastet. ASM mag ich weniger und verwende es nur in kleinen homöopathischen Dosen und nur wenn unbedingt notwendig. Abgesehen davon befasse ich mich mehr mit PICs und nur ganz wenig mit AVRs. Bin also in Deinen Augen ein hoffnungsloser C Programmierer;-) Was soll ich zum Thread sagen? Ich finde es ist halt schon viel digitale Tinte verbraucht worden... Naja, wenn Du mich jetzt in die Ecke drängst, muß ich Eure Standhaftigkeit und Gelassenheit bewundern. Mir persönlich ist es innerhalb vernünftiger Grenzen eigentlich Wurscht wieviel Resourcen ein Programm vebraucht solange die Vorgaben einwandfrei erfüllt werden. Auf der Ebene des Mikroprozessors ist jedes Programm ganz gleich wie es erstellt worden ist, nur Maschinensprache und das arme Würstchen muß den Stuss den wir alle irgendwann schreiben, stur und sklavenhaft abarbeiten. Wenn Mikros nur sprechen könnten... In dem Sinne, noch eine gute Nacht, Gerhard
:
Bearbeitet durch User
Besten Dank Gerhard für den touristischen Einblick in Deine Gegend. Die kann es glaub ich mit meinem Bayern aufnehmen ;-) Gute Nacht aus D
Moby A. schrieb: > Besten Dank Gerhard für den touristischen Einblick in Deine Gegend. Die > kann es glaub ich mit meinem Bayern aufnehmen ;-) > > Gute Nacht aus D Du bist aus Bayern? Von wo ungefähr? Die Chiemseegegend kenne ich noch gut von früher her und auch Rosenheim mit dem großen K dort. Ich bin von über der Grenze her, die Stadt mit der alten Festung und seiner Heldenorgel die man auch gut über der Grenze in Bayern hört. Guten Abend aus C
:
Bearbeitet durch User
Jörg W. schrieb: >> Mal Schifahren zu gehen oder Eislaufen > > Hab ich letztens probiert. Bin ziemlich blöd auf den Hinterkopf > gefallen dabei. :o/ Da hat es wohl an Übung, Vorbereitung und System gefehlt...
:
Bearbeitet durch User
A. K. schrieb: (Eislaufen) > Da hat es wohl an Übung, Vorbereitung und System gefehlt... Ja, ganz sicher. :-)
Moby A. schrieb: >> Belege die "Bürokratie" entsprechend mit Codebeispielen. > > Dafür brauchts nichtmal Beispiele. Dafür langt schon ein Blick ins dicke > C-Buch ;-) Hmm, die Assembler Handbücher sind meist dicker als der C-Standard, und man braucht für jede Prozessorfamilie ein neues... D.h. also Assembler ist viel bürokratischer als C - stimmt aus meiner Erfahrung.
Moby A. schrieb: > Größere Asm-Programme aus meiner Feder hätten erst recht > keine Chance auf Vergleich- als einzig möglicher Beweismöglichkeit. Oh man, hätten, könnten, würden, ... alles klar ;-)
Moby A. schrieb: > Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig > kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und > rechenintensiv ist. Damit ziemlich ungeeignet für Asm. (Ironie an) Wenn ASM doch ach so überlegen ist, dann kann es doch für gar nichts ungeeignet sein (Ironie wieder aus)
Thread beobachten
Seitenaufteilung abschalten
