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.
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.
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?
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 GRINSMoby 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
..
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 :-)
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!
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
returnwert/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.
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.
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.
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)
- 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?
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 ;-(
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.)
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.
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.
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"
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.
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 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.
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.
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 ;-)
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 ;-)
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... ;-)
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.
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.
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.
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.
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...
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.
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...
... 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 ;-)
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.
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")
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...");
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.
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.
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..
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.
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.
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.
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:
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.
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
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
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
>>>>>>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.
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 ;-)
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 ;-)
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!
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 ;-)
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.
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?
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
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
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...
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
