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.
Okay, Moby sagt uns also ganz offiziell:
Jede Software die man kaufen kann (unabhängig vom Preis ?) ist einem
selbst programmieren mit ASM vorzuziehen.
Muß daran liegen das kein Preis der Welt es rechtfertigt sich das in ASM
anzutun.
Man kann alles in ASM schreiben solange es nicht komplex (Definition ?),
datenintensiv (Definition ?) und rechenintensiv (Definition ?) ist.
Für jeden anderen Fall muß man dann eine zweite Programmiersprache
lernen und alles wegwerfen was man bisher in ASM dazu geschrieben hat.
Ja, lieber Moby, das ist so ungefähr die Einschätzung der großen
Mehrheit hier. Dann liegen wir doch garnicht so weit auseinander.
Was wir nur einfach nicht verstehen können ist warum man die
Beherrschung eines Werkzeuges bis ins Detail perfektionieren soll das
versagt sobald die Aufgabe größer wird, wenn man statt dessen die
gleiche Arbeit in ein Werkzeg stecken kann das auch große Aufgaben
stemmt.
In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten
möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen
läßt.
Laß uns diesen Müll doch mal entsorgen und ein tiny Sensorboard mit
einem vernünftigen Feldbuss definieren und einer Meßwertaufbereitung die
diesen Namen auch verdient. Einer wirklich tyischen 8bit MSR Aufgabe
eben.
Das setzt eine jede Fraktion in Ihrer bevorzugten Programmierspache um
und wir schauen mal wie dann das Ergebniss aussieht.
Jaja, ich weiß, kein Argument kann die Vorteile von ASM tangieren.
Deswegen wird auf gefährliche Argumente ja von Dir auch prinzipiell
nicht geantwortet.
Leider ist der einzige Vorteil von ASM nur noch das Du nichts anderes
kannst. Das ist aber etwas was nur Du ändern kannst.
Gerhard O. schrieb:> Wenn Mikros nur sprechen könnten...
Gottlob (darf ich als Atheist sagen!) quasseln die eben nicht soviel
Unsinn wie ihre Programmierer.
Bin froh, daß wenigstens die µC die Klappe halten.
Moby A. 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>> 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 SummeMoby A. schrieb:> 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.
Mich würde brennend interessieren, wie Du diese 2 Punkte von Dir
verifizierte Anforderung in dem Kryptischen und Komplexen Assembler
umsetzen würdest. Ich habe bereits dies in C umgesetzt, also darf ich
doch auch von Dir erwarten dass Du mit einer konkreten Lösung diese
Teilaufgabe auch als Gegenpart in Assembler zur Schau darstellst.
Schließlich bist du ja einverstanden gewesen mit den Spezifikationen.
Hier mein Code:
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Wenn Du mal hier den Teil erstellst, dann können wir auch gerne den Rest
der Anforderung auch umsetzen (in C / ASM).
Da Du ein Meister von Ausreden bist kann ich wohl nichts erwarten,
schade :-(
Lothar M. schrieb:> Leute, durchhalten! Zusammen wir schaffen das! ;-)> Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Eben deswegen hängen wir uns doch richtig rein.
Lothar, das machen wir nur für Dich.
Ich gönne Moby außerdem nicht das letzte Wort.
Ach Jungs,
ihr könnt machen was ihr wollt. Dem Moby interessiert das alles nicht.
Zusammenfassung:
Moby hat ein ASM Programm auf einem Tiny13.
Die Anforderungen stehen mittlerweile fest.
Nur sein Programm zählt. Nix mit Ausgabe an serieller Schnittstelle,
Fedlbus, anderer MC usw.
Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein
SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus
der ISR.
Nicht mehr und nicht weniger. Ihr könnt schreiben was ihr wollt. Er wird
sich immer auf sein ASM Programm beziehen.
>Gewonnen habt ihr ...
ja, wenn jemand ein C-Programm schreiben würde, dass ... usw. usw.
erfüllt, hätte man Gewonnen
wie weiter oben schon festgestellt wurde,
heißt das im Umkehrschluss nicht dass wenn keiner mitmacht, Moby
gewinnt..
Werner P. schrieb:> Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein> SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus> der ISR.
Ich lache mich immer schlapp wenn ich "SRAM" lese.
Beim STM32 habe ich 64KB CCM RAM und nach einiges an BACKUP-RAM. Also
brauche ich da den SRAM niemals belegen GRINS
Lothar M. schrieb:> Leute, durchhalten! Zusammen wir schaffen das! ;-)> Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn"Ralf G. schrieb:> Wobei...: Der Ringrichter wettet auf den Verlauf des Kampfes?! ;-/
Robert L. schrieb:> Moby> gewinnt..
ehrlich gesagt ist mir das Sch...egal ob Moby gewinnt oder nicht.
Der Typ hat sowas von einen beschränkten Horizont. Labert laufend von
ÜVS und wie toll ASM ist. Kreischt wie ein kleines Kind: "Du darfst kein
SRAM verwenden!". usw. usw.
Kindergarten halt.
Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer
sein Programm locker in 30 Minuten programmiert. Klar wird dann SRAM
verwendet und eventuell mehr Flash.
ABER WEM INTERESSIERT DAS?
EDIT: Aber irgendwie lustig ist der Thread schon ;-)
Werner P. schrieb:> Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer> sein Programm locker in 30 Minuten programmiert. Klar wird dann SRAM> verwendet und eventuell mehr Flash.
Meine Rede.
Ich behaupte sogar, dass 10-15min realistischer sind.
Den größten Aufwand drüfte das Heraussuchen der ADC- und Timer-Register
aus dem Datenblatt sein und das aufpriemeln der Bits.
Allerdings wird im ersten Schuss zwangsläufig RAM benutzt, ja mei, ist
halt so, und eventuell ein paar Bytes mehr Flash.
Könnte man alles trotzdem irgendwie hinpfuschen. Der gcc gibt einem ja
viele Möglichkeiten:
- Den StartUp-Code könnte man weglassen oder anpassen, RAM muss ja
keiner initialisiert werden, denn SP kann man zur Not selbst
initialisieren.
- die main() deklariert man als "os_main"
- die ISR deklariert man "naked"
- dann gibts noch den "register"-qualifier
- und wenn man mal die Doku durcharbeitet findet man bestimmt noch mehr
Ansatzpunkte um den Compiler in die gewünschte Richtung zu zwingen
Aber das hat dann halt wirklich nur noch sportlichen Wert, Aussagekraft
über Vor- oder Nachteile hätte so ein Programm dann nicht mehr.
Man hätte dann wirklich nur gezeigt dass die Erfinder von C und die
Entwickler des gcc genug Flexibilität vorgesehen haben um jede noch so
abstruse Forderung erfüllen zu können.
Wenn ich aber die geforderte Funktion in 10min umsetzen kann, jeder den
Code sofort versteht und dafür nur 5% mehr Flash/RAM verbraucht werden
als bei der hochoptimierten, alle Kniffe nutzenden , nicht mehr
erweiterbaren ASM-Lösung wär das für mich schon ein Punkt für die
C-Lösung.
Und ich vermute mal, für 99% der Anwesenden hier auch.
>ehrlich gesagt ist mir das Sch...egal ob Moby gewinnt oder nicht.
also mir nicht
ich fände das Super wenn er Gewinnen würde und allen hier aufzeigen
würde wie es Richtig geht..
wenn er sein git/svn repository von seiner SmartHome Zentrale (read
only) zur Verfügung stellen würde..
wo man sieht wie er Schritt für Schritt, mit System um Eleganz und Top
dokumentiert das Programm erweitert hat..
Wie einfach und übersichtlich dort alles ist, wie jedes Byte Flash 3 mal
umgedreht wurde und jedes byte RAM soweit möglich eingespart wurde..
Moby A. schrieb:>> 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?
Faktenlose Beiträge? Ich denke wir haben dir aus allen denkbaren
Perspektiven erklärt und belegt, was Sache ist. Du überliest es aber
geflissentlich, oder erfindest neue Argumente, warum es nicht gelten
soll. Neue Fakten braucht es da nicht mehr, es geht einzig und alleine
noch darum, dir zu zeigen, wie absurd deine Haltung ist. Und ja, den
Klassendepp mit seinen Ideen noch ein wenig aufziehen ist halt
unterhaltsam :-)
le x. schrieb:> Und ich vermute mal, für 99% der Anwesenden hier auch.
genau so ist es. Nur einer rafft das halt nicht.
Eigentlich war ja der Thread: Assembler wieder auf dem Weg nach vorn
von mir aus ist Assembler auf dem Weg nach vorn. Kann mir nur nicht
vorstellen dass im professionellen Bereich von C hin zu ASM gegangen
wird. Und selbst im Hobbybereich kann ich es mir nur schwer vorstellen.
Aber das ist jetzt meine Meinung.
Einen AVR und fast jeden anderen MC kann ich in C und oft auch in
anderen Hochsprachen programmieren. Ist doch toll. Jeder sucht sich
seine Sprache aus.
Früher hat mich C auch abgeschreckt. Aber mittlerweile finde ich C
einfach nur gut.
Aber jedem das womit er glücklich wird.
Moby A. schrieb:> Für viele windelweich faktenlose Beiträge hier langts aber?> Dabei hab ich doch gehört, daß C so hochproduktiv sein soll...
Deine Behauptung vom fetten C ist und bleibt deine private,
vorgefertigte Meinung, möge ÜVS mit dir sein. Wie viele C Umsetzungen
brauchst du, um sie zu überdenken?
Ich hänge noch mal mein PIC12F675 XC8 FREE Projektchen an. Ich habe es
an deine allerneueste Anforderungsliste angepasst mit dem Ergebnis: das
Compilat hat 198 Maschinenbefehle - auf einer archaischen MCU, die: nach
allgemeiner Lehrmeinung für C ungeeignet ist, nur ein Arbeitsregister,
35 Instruktionen, zerkluftete Achitektur und noch nichtmal freilaufende
ADC hat. Also müsste es mit deiner ÜVS ein klacks sein, das Projekt auf
einer modernen AVR MCU in <100 Befehlen zu implementieren. Sonst schicke
ich dein Projekt an die Mythbuster ;-)
Matthias L. schrieb:>>> 200Bytes => Verloren
Je nee ist klar.
Gegen einen so meilenhoch überlegenen Gegner zu verlieren ist doch keine
Schande. Jetzt gibt doch bitte endlich dem Moby seinen verdienten
ÜVS-Orden!
Witkatz :. schrieb:> Jetzt gibt doch bitte endlich dem Moby seinen verdienten> ÜVS-Orden!
Nicht bevor Lothar seine Wette gewonnen hat.
Bis dahin zählt jeder Beitrag, auch Mobys.
Geht ja zum Glück schon lange nicht mehr um Inhalte.
Zur Not Verteile ich etwas Katzenfutter auf der Tastatur um die letzten
Beiträge voll zu bekommen.
Inhaltsärmer als ÜVS kann das auch nicht mehr sein.
Michael K. schrieb:> Geht ja zum Glück schon lange nicht mehr um Inhalte.
Ja siicher! Es geht immer nur um "Assembler wieder auf dem Weg nach
vorn"
Ausserdem ist das Wachstum dieses inhaltslosen Threads ein
unwiderlegbarer Beweis für die Expansion des Universum.
Also in dem Sinne. Möge ÜVS mit Dir sein!
Moby A. schrieb:> 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.
Beziehst du dich bei deinen fetten Behauptungen auf die fette SPRACHE C
im fetten Allgemeinen oder auf eine bestimmte fette C-Implementation
vulgo: fetter C-Compiler?
Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE
Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code,
d.h. dass es fett UNMÖGLICH ist, mit einem hypotetischen fetten
C-Compiler besser als mit fettem Assembler zu sein?
Falls du dich auf eine fette KONKRETE IMPLEMENTATION beziehst wie
fett-gcc, so liefert ein damit fett compiliertes fettes Programm nur
eine fette UNTERGRENZE für die fette Effizient von C, aber KEINE
OBERGRENZE derselben — und das auch nur für den fetten Fall eines
bestimmten fetten C-Programms, das mit einer bestimmten fetten Version
eines bestimmten fetten Compilers mit bestimmten fetten Optionen
übersetzt wurde.
Gehts dir also um fettes fette Compiler-Bashing?
Oder um fettes Bashing einer fetten Sprache und dem fetten Nachweis,
dass die fette Effizienz NIEMALS über einer bestimmten fetten Grenze
liegen kann?
Musst fett entschuldigen, wenn ich fett ein paar fetts vergessen hab...
Johann L. schrieb:> Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE> Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code,> d.h. dass es fett UNMÖGLICH ist, mit einem hypotetischen fetten> C-Compiler besser als mit fettem Assembler zu sein?
Um die Diskussion zu gewinnen, müsste Moby genau das tun. Er müsste
nachweisen, dass compiliertes C nicht effizienter sein kann als direkt
in Assembler geschriebener Code. Oder dass es zumindest für eine gewisse
Klasse an Problemen keine solchen gibt.
Ich 'jammer' noch mal. Obwohl es wahrscheinlich nur Moby schafft in
meinem post unfassbar weit oben auf gejammer zu schließen.
Du bist ja extrem stolz auf dein Programm. Geschenkt. Ist ein schönes
Programm - per inline asm auch in c portierbar. Glückwünsch.
Angenommen es würde wirklich jemand den von dir gewünschten Wettkampf,
genau DIESES Ding in c "besser" zu programmieren, was genau sollte da
raus kommen? Du hast EINEN Pfeil im Köcher. Dein sagenumwobenes
Programm. Um damit auf eine generelle Aussage wie "....die allgemeinen
Vorteile von asm...." zu kommen, musst du wenigstens noch einen zweiten
Treffer landen. Karl Heinz hat die ein Angebot unterbreitet, was dir
augenscheinlich Angst gemacht hat.
Weil das fast jeder versteht und dein Programm so unbedeutend für die
Sache ist, kannst du dir deine Tastatur kaputt hacken in dem Thread.
Wenn es dir ein gutes Gefühl gibt und irgendwie terapeutischen Nutzen
hat sei es dir gegönnt.
Aber ich -hoffe- du bist dir selber im klaren, dass du nicht auf der
Gewinnerstrasse bist. Weder mit deinen Resultaten, noch mit deiner
Argumentation (wenn ich deine posts mal so nennen mag)
Folgendes zu sagen würde bestimmt jeder akzeptieren:
-Einen Mini Code bis maximal 1 kB kann man händisch in asm noch besser
optimieren als in c. Wenn man viel Erfahrung hat wohlgemerkt. Wenn viel
Interrupt Last dazu kommt vielleicht noch besser. Das Resultat in c ist
dafür recht problemlos portierbar.
-Es macht zugegeben aber auch Spaß als Hobby solange Bits zu schubsen
bis man selber zufrieden ist und mit Papier und Bleistift Computer zu
spielen. Es macht aber auch Spaß als Hobby eine abstraktere Codierung zu
wählen und sich stattdessen um Algorithmen und Mathematik zu kümmern.
-Von einem minimalistischen Code auf eine allgemeine Aussage zu kommen
asm sei c überlegen ist Schwachsinn.
-Ich kann mit meiner asm Codebasis auch größere Projekte zusammendübeln.
Ich muss aber auch eingestehen, dass eine Maschine dabei den Überblick
besser waren kann und eine Maschine dabei die Planung und Vorbereitung
variabel halten kann...was schnell zum Vorteil gereicht.
Ich glaube aber auch, dass ich nach Monaten oder Jahren der Benutzung
von c auch DORT eine gewisse Codebasis anhäufe auf die ich dann
zurückgreifen kann....... Kannste dir doch bestimmt irgendwie vortellen
oder?
-Die verschwenderische Programmierung auf dem PC, die z.B. Adobe
hinbekommt ist lästig nervig und steht auf einem ganz anderen Blatt und
hat gar nix mit dem diskutierten Problem uc zu tun. Die ist bescheuert
und nervt wohl fast jeden. Auch wenn die Programmierer in den Branchen
bestimmt erklären können dass das modern und zudem egal ist.
Das Visual Studio was du zum asm Programmieren benutzt ist z.B. auch so
ein Software gau.
-(...)
Ich hoffe du nimmst dich in Wahrheit nicht so ernst wie du tust und
glaubst dein krudes Geschreibe wirklich. Dann hast du irgendwie ein
Logik Problem. Oder sonst irgendein Problem.
Was spricht dagegen deine Windmühlen mal rational zu betrachten wie oben
skizziert?
Habe noch mal quer gelesen und möchte dir zugestehen, dass du
tatsächlich unter irgendwas pathologischem leidest.
Selektive Wahrnehmung wäre so was. Lies noch mal nach: viele warten
sicher noch auf Antworten auf gechriebene Punkte.
Johann L. schrieb:> Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE> Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code
Was interessiert mich hier jede denkbare C-Umsetzung?
Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation.
Vom Ressourcen-Bedarf her und mit der fetten C-Bürokratie, die ja wohl
immer zur Anwendung kommen muß erst recht.
Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage
wiederspricht und ich mich reuevoll korrigieren muß.
Drehe nur ein bischen an den tausend kleinen optimierenden
C-Stellschrauben, dann sollte daß doch fett klappen, oder?
Fett eingeschüchtert in der Ecke kauernd hast Du mich schon ;-)
> Musst fett entschuldigen, wenn ich fett ein paar fetts vergessen hab
Kein Problem. C hat sicher noch andere fette Pferdefüße, die mir gerade
nicht in den Sinn kommen oder noch gar nicht bekannt sind ;-)
Mit fetten Grüßen!
Clemens M. schrieb:> Habe noch mal quer gelesen und möchte dir zugestehen, dass du> tatsächlich unter irgendwas pathologischem leidest.
Kenn ich schon. Läuft wieder der Beleidigungsschiene.
Da bin ich aber inzwischen dermaßen von was abgehärtet... ;-)
> Selektive Wahrnehmung wäre so was.
Wenn Du das pathologisch nennst ist es ein Massenphänomen.
Dich natürlich ausgeschlossen ;-)
> Lies noch mal nach: viele warten> sicher noch auf Antworten auf gechriebene Punkte.
Natürlich Clemens. In der Nacht hab ich wieder Zeit zur netten
Unterhaltung. Also bis bald!
Moby A. schrieb:> Johann L. schrieb:>> Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE>> Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code>> Was interessiert mich hier jede denkbare C-Umsetzung?> Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation.
Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE
C-Umsetzung.
> Vom Ressourcen-Bedarf her und mit der fetten C-Bürokratie,> die ja wohl immer zur Anwendung kommen muß erst recht.
Nein, C als Sprache kennt weder Flash noch Register noch Stack oder
Schalter.
> Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage> wiederspricht und ich mich reuevoll korrigieren muß.
Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine
C-Implementation, und die darf ich wählen wie ich will?
Oder geht's dir nur um Compiler-Bashing?
D.h. du hast mal — ohen C zu können — irgend nen Text von einen
C-Compiler übersetzt bekommen, und dann nen Blutsturz bekommen weil der
2 Bytes mehr verbraucht hat?
> Drehe nur ein bischen an den tausend kleinen optimierenden> C-Stellschrauben,
C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler.
Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln?
Nee eine Beleidigungsschiene ist das nicht. Soll es jedenfalls nicht.
Da du aber ganz offensichtlich fast 2000 Posts gar nicht wirklich
Argumente oder Programm(e!) austauschen willst dachte ich, dass du etwas
Galgenhumor bei deinen Kollegen in diesem Thread erwartest.
Und, ja, du hast eine mir fast unangenehme Ader, taub und blind zu sein
wenns dem Vorteil gereicht.
Du bist aber schon technisch interessiert? Also nicht dass du irgendwie
deine Bachelor Arbeit in Psychologie schreibst während wir hier
Serverplatz verbrauchen.
>Dich natürlich ausgeschlossen ;-)
Erklär mir doch mal wo ich dir Unrecht tue oder einfach Aussagen
ignoriere. Was sagst du zu meinen Konsens-Stichpunkten?
Moby A. schrieb:> Was interessiert mich hier jede denkbare C-Umsetzung?> Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation.
Also, hopp, beweis es! Komm! Beweis es! Beweis es oder höre auf mit
solche Behauptungen!
Ach Leute, hört halt auf diesen asm Troll mit unendlich Futter zu
versorgen.
Seit 2000 Seiten hat unser Moby
- gerade mal ein Projektchen mit gut 20 Zeilen gezeigt. Der Rest ist
Angeberei.
- offensichtlich keine Ahnung von C und einem C compiler.
- rudimentäre bis wenig Kenntnisse in Asm (Stichwort EOR ;-) )
- alle chancen was zu lernen verpasst
- alle Angebote zu einem fairen Vergleich aus Angst zu verlieren
abgeblockt
- sich mit bescheuerten Argumenten lächerlich gemacht (Stichwort ÜVS)
- keine Ahnung wie lächerlich er sich bisher gemacht hat (das ist wohl
das komischste am Thread)
- sich hundert mal selber widersprochen
- immer wieder jemand gefunden der ihn offensichtlich ernst nimmt (warum
auch immer)
- die mit Abstand meisten downvotes in diesem Forum kassiert ;-)
Gu. F. schrieb:> Seit 2000 Seiten
Nein, noch nicht ganz.... ;-)
> Seit 2000 Seiten hat unser Moby> ... grausig lange Aufzählung ...
Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist
keinen müden Cent billiger. Und der braucht auch nicht weniger Strom.
Und er ist auch nicht leichter.
Das Einzige, was passiert, ist dass die hocheffiziente und RAM-sparende
Appliktation ein halbes Jahr zu spät an den Markt kommt und sie dann
keiner mehr will.
> - immer wieder jemand gefunden der ihn offensichtlich ernst nimmt> (warum auch immer)
Ist ja klar: keiner kann die 1886 Posts alle lesen und so erkennen, dass
Alles, schlicht Alles schon einmal gesagt wurde...
Moby A. schrieb:> Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage> wiederspricht.
Hab ich doch längst, s.o. Mein Fazit:
Mit ÜVS bleibt C bei kleinen 8bit Aufgaben genauso schlank wie ASM!
So! Das schreibst du jetzt 100 mal reuevoll ab - und zwar mit printf!
Wenn mit ÜVS sowas raus kommt :
> 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.> Den Teil wo die Entprellung der digitalen IOs stattfindet oder die> Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden> können.
dann möchte ich bitte sofort gegen ÜVS geimpft werden.
Scheint den kognitiven Fähigkeiten ziemlich übel mitzuspielen.
Lothar M. schrieb:> Ist ja klar: keiner kann die 1886 Posts alle lesen und so erkennen, dass> Alles, schlicht Alles schon einmal gesagt wurde...
... nur noch nicht von jedem.
Ja, auch das wurde schon gesagt :-)
Lothar M. schrieb:> Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist> keinen müden Cent billiger. Und der braucht auch nicht weniger Strom.> Und er ist auch nicht leichter.
Vielleicht liegt es Moby ja da dran:
In einem bekannten ASM seine Frickelprogrämmchen stur nach ÜVS
schreiben,
händisch durchorgeln, "optimieren", eindampfen etc.
Nach dieser Optmierung wird dann Atmel angeschrieben und ein Tiny 9,85
bestellt. Die Codegrösse ist dann ja bekannt.
Bei echter Stückzahl gehen die bei Atmel bestimmt drauf ein ;)
>Bei echter Stückzahl gehen die bei Atmel bestimmt drauf ein ;)
Ja. Sie verkaufen im einen Tiny13 mit anderer ID, wo im Atmel-Studio
jeder Zugriff auf auf FLASH-Zellen über Adresse 9,85k geblockt wird mit
er Info:
"Zugriff nicht möglich, da gespart mit ÜVS"
Markus M. schrieb:> Oder mit reduziertem ASM Befehlssatz die mittels ÜVS ermittelt wurden.
Gerade der Verzicht auf EOR könnte einige Gatter in der ALU einsparen.
Carl D. schrieb:> Gerade der Verzicht auf EOR könnte einige Gatter in der ALU einsparen.
Aber nicht viele. Weil identisch mit Addition ohne Übertrag.
Beim Multiplier lohnt es eher, aber den hat sein geliebter 13er ohnehin
nicht. Oder den halben Registersatz indem etwas mehr billiges RAM
genutzt und teure Register einspart werden.
Matthias L. schrieb:> im Atmel-Studio> jeder Zugriff auf auf FLASH-Zellen über Adresse 9,85k geblockt wird
Kann man das nicht mit einem ÜVS Fuse regeln? Beim Abschalten des ÜVS
Fuse müssen aber unbedingt Schockbilder vor der fetten Bürokratie
warnen.
Warum Übung, Vorbereitung und System Assembler so stark machen können
und ihn viele C-Programme vom Ressourcenbedarf her schlagen lassen wird
wohl manchem Comedian im Thread über mir auf ewig verschlossen bleiben.
Da wird lieber weiter mit C auf den Controller eingeprügelt bis wieder
mal dessen Schuhgröße oder gar gleich die ganze Architektur gewechselt
werden muß. Das ist natürlich insofern komfortabel als C angeblich so
schön portabel ist... um sich dann mit kleinen Hardwareänderungen und
dem Neulernen einer Architektur, dem Anpassen der Entwicklungsumgebung
und den Tausend Optimieroptionen die Nächte um die Ohren zu schlagen ;-)
Gerhard O. schrieb:> Du bist aus Bayern? Von wo ungefähr?
Von dort wo der Inn wieder Deine alte Heimat berührt ;-)
Moby A. schrieb:> Da wird lieber weiter mit C auf den Controller eingeprügelt bis wieder> mal dessen Schuhgröße oder gar gleich die ganze Architektur gewechselt> werden muß. Das ist natürlich insofern komfortabel als C angeblich so> schön portabel ist... um sich dann mit kleinen Hardwareänderungen und> dem Neulernen einer Architektur, dem Anpassen der Entwicklungsumgebung> und den Tausend Optimieroptionen die Nächte um die Ohren zu schlagen ;-)
Wo hast du das denn her? Aus der Bildzeitung? Das zeigt nur, daß Du
allen Unsinn nachplapperst und keine Ahnung hast....
Im übrigen wunderts mich, daß jemand, der von Assembler so überzeugt
ist, eine IDE zum Entwickeln benutzt...
Bernhard M. schrieb:> Hmm, die Assembler Handbücher sind meist dicker als der C-Standard, und> man braucht für jede Prozessorfamilie ein neues...
Die Auflistung aller Instruktionen ist schnell erledigt, deren
Verständnis auch. Kein Vergleich mit C.
Wenn man dann bei 8-Bit MSR Apps bei seiner Architektur bleiben kann
dann auch wegen Asm.
Michael K. schrieb:> Jede Software die man kaufen kann (unabhängig vom Preis ?) ist einem> selbst programmieren mit ASM vorzuziehen.
Das Selbstprogrammieren mit Asm macht zunächst mal auf kleinen 8-Bit
Controllern Sinn! Dort gibts auch wenig zu kaufen.
> Was wir nur einfach nicht verstehen können ist warum man die> Beherrschung eines Werkzeuges bis ins Detail perfektionieren soll das> versagt sobald die Aufgabe größer wird
Mit ÜVS versagt Asm bei 8-Bit MSR Aufgaben so schnell nicht.
> In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten> möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen> läßt.
So edel optimiert muß Software auf einem kleinen Controller aber
ausschauen! Sparsamer Verbrauch, Kapselung der Funktionalität, einfache
Erweiterbarkeit.
> Laß uns diesen Müll doch mal entsorgen
Müll ist, was Du statt dessen für die Aufgabe, die mein kleines
Sensorboard erfüllen soll vorschlägst:
> tiny Sensorboard> mit einem vernünftigen Feldbuss definieren und einer Meßwertaufbereitung> die diesen Namen auch verdient.
Völlig unnützer Aufwand. So überdimensioniert bürokratisch wie
bücherfüllendes C gegenüber Asm ;-)
Markus M. schrieb:> Mich würde brennend interessieren> Wenn Du mal hier den Teil erstellst
Ist ja nett. Ich habe für meinen Teil und für diesen Thread genug
erstellt. Weitere Mühen lohnen eher nicht, wenn ich das Ergebnis des
Threads so betrachte.
Nun will ich für meine Vorlage kürzeren C-Code sehen den ich kompilieren
und testen kann.
> Da Du ein Meister von Ausreden bist
Ja ja, die lieben Ausreden.
Ich komm mir wie ein Kämpfer gegen einen übermächtigen C- Drachen vor,
dessen Köpfe voller Ausreden ständig nachwachsen. Mein scharfes
Laserschwert in Form fertigen, für jeden nachvollziehbaren Codes kann
ich gar nicht so schnell schwingen ;-)
Werner P. schrieb:> Ach Jungs,>> ihr könnt machen was ihr wollt. Dem Moby interessiert das alles nicht.>> Zusammenfassung:>> Moby hat ein ASM Programm auf einem Tiny13.> Die Anforderungen stehen mittlerweile fest.>> Nur sein Programm zählt. Nix mit Ausgabe an serieller Schnittstelle,> Fedlbus, anderer MC usw.>> Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein> SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus> der ISR.>> Nicht mehr und nicht weniger. Ihr könnt schreiben was ihr wollt. Er wird> sich immer auf sein ASM Programm beziehen.
Hey, da hat einer die Situation ja seeehr klar erkannt!
Genau. Ich beziehe mich auf harte Fakten! Die gilt es jetzt zu schlagen
und nicht darum, irgendwelchen Fantasien nachzuhängen ;-)
Moby A. schrieb:> Die Auflistung aller Instruktionen ist schnell erledigt, deren> Verständnis auch. Kein Vergleich mit C.
Die Auflistung der C Schlüsselworte und Operatoren ist dreimal so
schnell erledigt.
Moby A. schrieb:> Ich beziehe mich auf harte Fakten!
Auch Fakten, die dir nicht in den Kram passen?
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"Moby A. schrieb:> Ich komm mir wie ein Kämpfer gegen einen übermächtigen C- Drachen vor,> dessen Köpfe voller Ausreden ständig nachwachsen. Mein scharfes> Laserschwert...Moby A. schrieb:> Die gilt es jetzt zu schlagen> und nicht darum, irgendwelchen Fantasien nachzuhängen
Also was denn jetzt. Erst fantasierst du dir was über C zusammen und
dann willst du doch nicht Fantasien nachhängen...
So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer noch
nicht warum man mit C die Architektur wechseln müsste. Kein AVR kann da
zu klein sein, selbst wenn ich C-Anfänger bin. Es gibt also schlichtweg
keinen Grund die Architektur zu wechseln, egal ob Assembler oder C (bei
8-bit MSR mit SÜV). Damit fällt doch auch dieser pathologische Sparzwang
weg.
Ich programmiere schon mein ganzes Leben lang Assember (ESER-Rechner,
Z80, 8086, 68000) und auch C (+ diverse andere schöne Hochsprachen). Bei
Robotron haben wir in den 80ern mal versucht einen "16 auf 8 bit"
Crossassembler zu entwickeln, weil die Ressourcen beschränkt waren. Aber
so ein Gewese wie Moby hier veranstaltet...
kopfschüttel
Markus M. schrieb:> Ich lache mich immer schlapp wenn ich "SRAM" lese.>> Beim STM32 habe ich 64KB CCM RAM und nach einiges an BACKUP-RAM. Also> brauche ich da den SRAM niemals belegen GRINS
Ich muß auch grinsen: Wenn ich für (alle) Apps den einfachen,
unkomplizierten AVR nehmen kann!
Werner P. schrieb:> Der Typ hat sowas von einen beschränkten Horizont.
Beschränkt sind eher die Möglichkeiten, mit C effizientem Asm-Code bei
8-Bit MSR Konkurrenz zu machen ;-)
> "Du darfst kein> SRAM verwenden!". usw. usw.
Zu dumm daß es zu den zu vergleichenden Ressourcen gehört! Ich versteh
Deinen Frust.
> Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer> sein Programm locker in 30 Minuten programmiert.
Na dann mal los. Viel Funktionalität ist ja nicht (zu vergleichen).
> ABER WEM INTERESSIERT DAS?
Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher
abgeneigt ;-)
> EDIT: Aber irgendwie lustig ist der Thread schon ;-)
Na das ist doch auch schon was.
Ein bischen Schmiermittel braucht jedes ernste Leben.
Moby A. schrieb:> Wenn man dann bei 8-Bit MSR Apps bei seiner Architektur bleiben kann> dann auch wegen Asm.
Da hast Du wohl "kann" und "muss" verwechselt ;-)
Moby A. schrieb:> Kapselung der Funktionalität
bedeutet bei Dir:
für jeden Hühnerschiss einen anderen mc.
Das definiert der Rest der Welt irgendwie anders!
Moby A. schrieb:> Markus M. schrieb:>> Mich würde brennend interessieren>> Wenn Du mal hier den Teil erstellst>> Ist ja nett. Ich habe für meinen Teil und für diesen Thread genug> erstellt. Weitere Mühen lohnen eher nicht, wenn ich das Ergebnis des> Threads so betrachte.> Nun will ich für meine Vorlage kürzeren C-Code sehen den ich kompilieren> und testen kann.>
Mein Code lässt sich kompilieren, also nutze den.
Moby A. schrieb:> Ich muß auch grinsen: Wenn ich für (alle) Apps den einfachen,> unkomplizierten AVR nehmen kann!
(Alle) Apps, die es in Deinem Weltbild gibt, meintest Du wohl?
So wie Du hier über C und neue Architekturen redest, so haben die Leute
im Mittelalter übers Lesen und Schreiben geredet ... völlig
überflüssiger neumodischer Kram ;-)
Jay W. schrieb:> So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer> noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR> kann da zu klein sein
Hast Du eine Ahnung!
> Damit fällt doch auch dieser> pathologische Sparzwang weg.
Hier gehts nicht um Sparzwang oder Verschwendungssucht.
> Bei> Robotron haben wir in den 80ern mal versucht einen "16 auf 8 bit"> Crossassembler zu entwickeln, weil die Ressourcen beschränkt waren.
Interessant. Ich hab mit dem KC87 angefangen ;-)
> Aber> so ein Gewese wie Moby hier veranstaltet...
Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was
mich persönlich sehr interessiert. Danke für Deinen Beitrag, der dieses
Thema aber leider verfehlt ;-(
Moby A. schrieb:> Gerhard O. schrieb:>> Du bist aus Bayern? Von wo ungefähr?>> Von dort wo der Inn wieder Deine alte Heimat berührt ;-)
Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein
Österreicher...
Gerhard
Moby A. schrieb:> Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm,
Das "C vs." lass bitte weg. Solange du in Hochsprachen keinen Fuß auf
den Boden kriegst, sind es nichts als deine Fantasiewelten.
Es geht immer noch um "Assembler wieder auf dem Weg nach vorn" und
nichts anderes.
Moby A. schrieb:> Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was> mich persönlich sehr interessiert.
Das stimmt nicht. Du versucht aus einem eingeschränkten
Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist,
mit Verlaub, blödsinnig.
Stefan K. schrieb:> völlig> überflüssiger neumodischer Kram ;-)
... im Bereich 8-Bit MSR allemal.
Das schlimmste ist die unnötige Bürokratie.
Dieser hochgradig umständliche Aufwand.
Das würde ich von der Priorität her fast noch über den gesteigerten
Ressourcenbedarf setzen ;-)
le x. schrieb:> Meine Rede.> Ich behaupte
Schwing mal keine großen Reden sondern mach Dich an die Arbeit, wenn
> 10-15min realistischer sind.
...
> Allerdings wird im ersten Schuss zwangsläufig RAM benutzt, ja mei, ist> halt so, und eventuell ein paar Bytes mehr Flash.
Also. Vergleich verloren.
> Könnte man alles trotzdem irgendwie hinpfuschen.
Du sagst es. Mit C eine einzige Rumpfuscherei
> jede noch so> abstruse Forderung erfüllen
Logo. Beim Vergleich des Ressourcenbedarfs ist der Vergleich der
Ressourcen eine abstruse Forderung.
> nicht mehr> erweiterbaren ASM-Lösung
Erzähl keinen Müll. Die ist mit zusätzlicher Funktionalität wunderbar
erweiterbar und auch schon entsprechend vorbereitet.
> Und ich vermute mal, für 99% der Anwesenden hier auch
Sprich mal nicht für ein Publikum was Du im Rücken wähnst sondern allein
für Dich.
P. M. schrieb:> Faktenlose Beiträge? Ich denke wir haben dir aus allen denkbaren> Perspektiven erklärt
Du solltest Deine Perspektiven nicht mit Fakten verwechseln.
> belegt, was Sache ist
Belege geschehen mit Fakten und nix anderem, schon gar nicht mit
Perspektiven.
> es geht einzig und alleine> noch darum, dir zu zeigen, wie absurd deine Haltung ist
Schon klar. Die Mühe von harten Fakten wär jetzt auch zuviel verlangt.
Da könntest Du mal "zeigen". Mit Deinem behaupteten Wissensstand ein
Klacks ;-)
> Klassendepp
Ohne Beleidigung gehts nicht mehr.
Ein Beleg für Dein Scheitern ;-)
Moby A. schrieb:> Werner P. schrieb:>> Der Typ hat sowas von einen beschränkten Horizont.>> Beschränkt sind eher die Möglichkeiten, mit C effizientem Asm-Code bei> 8-Bit MSR Konkurrenz zu machen ;-)
was ist da beschränkt? Nur weil Du in ASM ein paar Bytes weniger
verbrauchst. Wenn es Dir was bringt, gerne. ich spare lieber Zeit und
kann mich wichtigeren Dingen widmen während du noch mit ÜSV beschäftigt
bist.
>>> "Du darfst kein>> SRAM verwenden!". usw. usw.>> Zu dumm daß es zu den zu vergleichenden Ressourcen gehört! Ich versteh> Deinen Frust.>
Ich bin nicht frustriert. Warum auch.
>> Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer>> sein Programm locker in 30 Minuten programmiert.>> Na dann mal los. Viel Funktionalität ist ja nicht (zu vergleichen).>
Nix dann mal los. Wozu?
>> ABER WEM INTERESSIERT DAS?>> Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher> abgeneigt ;-)>
ich verliere/verschwende nur ungern Zeit. Von daher verwende ich
Hochsprachen.
Moby A. schrieb:> Beim Vergleich des Ressourcenbedarfs ist der Vergleich der> Ressourcen eine abstruse Forderung.
Seit fast 2000 Beträgen versuchen wir dir das klarzumachen. Schön, dass
du das endlich eingesehen hast.
Dafür bekommst du jetzt auch mal ein "lebenswert".
mfg.
Witkatz :. schrieb:> Gerhard O. schrieb:>> Dann bist Du ja schon fast ein>> Österreicher...>> Ich hab's irgendwie geahnt ;-)
Das war aber nicht sehr nett;-)
Moby A. schrieb:> Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was> mich persönlich sehr interessiert.
Nen Scheißdreck tust du.
Am Anfang des Threads konnte man noch den Eindruck haben dass du dir die
Beiträge wirklich durchliest. Da bist du noch mehr oder weniger drauf
eingegangen.
Aber ab den letzten ca. 1000 Beiträgen kommen von dir nur noch
inhaltslose Phrasen.
Da machen sich Leute die Mühe und Verfassen technisch fundierte
Beiträge, versuchen die Vor- und Nachteile von Sprachkonstrukten (z.B.
Datentypen) zu erleutern oder dir die Funktionsweise eines Compilers zu
erklären, stecken echt viel Zeit rein und du - du gehst entweder
garnicht drauf ein, oder holst entweder die Bürokratie- die ÜSV- oder
die Verschwender-Keule raus.
Völlig egal um was es geht. Man hat nicht mehr das Gefühl dass du dir
die Beiträge durchliest. Du bist nur noch am Phrasendreschen,
inhaltsloses Geschwurbel, zufällig aneinandergereiht.
Gib also nicht den Interessierten. Es geht nur noch ums letzte Wort.
Irgendwer erwähnte ELIZA: wenns nicht so traurig wär, man könnts echt
meinen...
Witkatz :. schrieb:> Ich hänge noch mal mein PIC12F675 XC8 FREE Projektchen an. Ich habe es> an deine allerneueste Anforderungsliste angepasst
Nett von Dir, aber Dein PIC Code hilft gerade nicht weiter. Hatte ich
dazu nicht schon ausführlich Stellung genommen?
Nochmal im Klartext: Spart Euch weitere Codebrocken.
So viel Funktionalität hat enthalten meine <200 Bytes Flash nicht.
Michael K. schrieb:> Geht ja zum Glück schon lange nicht mehr um Inhalte.
Du meinst, bei Dir?
Ja, der Eindruck drängt sich auf.
Aber kein Wunder wenns mit C nicht zu stemmen ist ;-)
Ich habe Verständnis.
Moby A. schrieb:> Nett von Dir, aber Dein PIC Code hilft gerade nicht weiter. Hatte ich> dazu nicht schon ausführlich Stellung genommen?>> So viel Funktionalität hat enthalten meine <200 Bytes Flash nicht.
Doch, mein Code hat volle Funktionalität bei 198 PIC Maschinenbefehlen.
Ich kann doch nichts dafür, dass du über C nur schwafeln kannst, aber
noch nicht mal in der Lage bist C zu buchstabieren.
> Nochmal im Klartext: Spart Euch weitere Codebrocken.
Ja wie denn jetzt, wirfst du schon die Flinte in den Korn?
Gerhard O. schrieb:> Das war aber nicht sehr nett;-)
Das war auch eines der ernstzunehmenden Argumente hier ;-)
le x. schrieb:> Da machen sich Leute die Mühe und Verfassen technisch fundierte> Beiträge, versuchen die Vor- und Nachteile von Sprachkonstrukten (z.B.> Datentypen) zu erleutern oder dir die Funktionsweise eines Compilers zu> erklären, stecken echt viel Zeit rein und du - du gehst entweder> garnicht drauf ein, oder holst entweder die Bürokratie- die ÜSV- oder> die Verschwender-Keule raus.
Du begreifst es nicht.
Ich möchte nichts erklärt haben, ich möchte überzeugt werden. Mit
Fakten. Dafür hab ich ein fix und fertiges Projekt eingebracht. Also
bitte, kein
> inhaltsloses Geschwurbel, zufällig aneinandergereiht.
sondern eine bessere C-Fassung meines Projekts bitte!
Das müsstest Du in 10-15 min noch vor dem Schlafengehen schaffen ;-)
Moby A. schrieb:> Jay W. schrieb:>> So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer>> noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR>> kann da zu klein sein>> Hast Du eine Ahnung!>
Welches deiner Programme hat den bis jetzt nicht in einen 8-bit AVR
gepasst? Die "C"-Kompilate passen dann auch rein.
>> Damit fällt doch auch dieser>> pathologische Sparzwang weg.>> Hier gehts nicht um Sparzwang oder Verschwendungssucht.>
"Wer mehr als 2 Byte SRAM oder 1 Byte mehr an Flash verbraucht, hat
verloren." Wie würdest du das bezeichnen? Redest du nicht immer von
"fettem C" ?
Die wichtigste Ressource im Leben eines Menschen ist die "Zeit". Da du
dein Tinysensorboardprogramm immer noch optimierst, würde ich glattweg
behaupten, dass du deine Lebenszeit verschwendest. Schade.
Assembler zu beherrschen und zu wissen, wann man ihn am besten
einsetzt, sind die Tugenden eines Programmierers, nicht das sture
Beharren auf der Sprache.
> Danke für Deinen Beitrag, der dieses Thema aber leider verfehlt ;-(
Ich bin zerknirscht. :-(
Manche Tellerränder scheinen ziemlich hoch zu sein.
Wißt Ihr wieviele tolle Projekte man in der Zeitspanne, die dieser
Thread schon konsumiert hat, hätte durchziehen können?
Durchschnittliche Beitragsschreib- und Denkdauer ca 5 min. Macht also
10Kh oder 400 Mannstunden. Was hätte man also in dieser Zeitspanne alles
schaffen können...
Schade!
Zieht die Bremsen an, bevor der Zug unanhaltbar wird.
Gruß,
Gerhard
Witkatz :. schrieb:> Gerhard O. schrieb:>> Zieht die Bremsen an, bevor der Zug unanhaltbar wird.>> Wir sind gerade bei 1933, es dauert nicht mehr lang.
Und was passiert dann?
Witkatz :. schrieb:> Gerhard O. schrieb:>>> Wir sind gerade bei 1933, es dauert nicht mehr lang.>>>> Und was passiert dann?>> Nichts ist eindeutiger als eine Zweideutigkeit? ;-)> Nö, es geht um Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Ja, fast hätte ich es vergessen. Ich dachte schon er meinte Wiley Coyote
aus Braunau...
Gerhard O. schrieb:> Witkatz :. schrieb:>>>> Wir sind gerade bei 1933, es dauert nicht mehr lang.>> Und was passiert dann?
Nach Stanislaw Lem in seinen "Sterntagebüchern" hat die Information dann
die kritische Masse erreicht und wird zu Materie, sich dabei selbst
auslöschend.
Chaos!
Gerhard O. schrieb:> Was hätte man also in dieser Zeitspanne alles> schaffen können...
ein etwas komplexeres ASM Programm ;-)
bald 1945. dann ist Schluss mit lustig
Moby A. schrieb:> Ich möchte nichts erklärt haben, ich möchte überzeugt werden.
... das ist schlichtweg eines: G E L O G E N
... egal wie oft Sie das wiederholen !
Sie möchten hier nur eines: Sich unglaublich darüber amüsieren, wieviele
Menschen Ihnen ob ihren absoluten zensiert Beiträgen auf den Leim
gehen.
Jemand, der überzeugt werden mag, macht sich Gedanken. Sie ... haben das
Denken schon seit längerer Zeit schlicht eingestellt !
Gerhard O. schrieb:> Moby A. schrieb:>> Gerhard O. schrieb:>>> Du bist aus Bayern? Von wo ungefähr?>>>> Von dort wo der Inn wieder Deine alte Heimat berührt ;-)>> Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein> Österreicher...>> Gerhard
Ein Bayer, der nach eigenen Angaben als ersten Computer einen
"Heimcomputer" der frühen 80er der Firma Robotron bediente. Klingt ja
völlig ungelogen.
Clemens M. schrieb:> Nee eine Beleidigungsschiene ist das nicht.> Erklär mir doch mal wo ich dir Unrecht tue
Ich weiß gar nicht, wie ich Dir bei soviel zur Schau gestellten
Hilflosigkeit noch helfen kann. ;-(
Überhaupt bitte ich um Verständnis, daß ich mich lieber mit dem
eigentlichen Thema beschäftige:
Johann L. schrieb:> Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE> C-Umsetzung.
Falsch. Nur
1. Mit Übung, Vorbereitung, System.
2. Für den 8-Bit MC Bereich.
3. Bei wenig Rechnerei und nicht allzuviel Daten!
4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache.
> Nein, C als Sprache kennt weder Flash noch Register noch Stack oder> Schalter.
Was man für effizienten Code aber kennen sollte!
C selbst liefert ein Vielfaches an Begrifflichkeiten (hatte ich alles
schon hundert Mal aufgezählt)
> Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine> C-Implementation, und die darf ich wählen wie ich will?
Du sollst von meiner Funktionsbeschreibung auf ein C-Programm kommen
> Oder geht's dir nur um Compiler-Bashing?
Nein. Ich weiß in Compilern steckt einiges KnowHow und viel Arbeit. Es
gibt viele Einsatzgebiete wo C eingesetzt werden kann. Mal sinnvollere,
mal weniger sinnvolle. Zu letzteren zählt 8-Bit MSR.
> dann nen Blutsturz bekommen weil der> 2 Bytes mehr verbraucht hat?
Spar Dir die Poesie.
Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels
nach ;-)
> C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler.
Nun stellst Du Dich auch noch dumm. Du weißt natürlich, daß der
resultierende Code hier im Fokus steht.
> Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln?
Keinen.
Moby A. schrieb:> Falsch. Nur> 1. Mit Übung, Vorbereitung, System.> 2. Für den 8-Bit MC Bereich.> 3. Bei wenig Rechnerei und nicht allzuviel Daten!> 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache.
Irgendwas fehlt hier doch.
Ach ja: MSR
Bitte, gern geschehen.
P. M. schrieb:> Moby A. schrieb:> Was interessiert mich hier jede denkbare C-Umsetzung?> Asm ist in jedem Fall deutlich magerer> Also, hopp, beweis es! Komm! Beweis es!
Mein Code liegt vor. Beweise Du jetzt weniger Aufwand mit C. Laß Dich
nicht von den übergroß drohenden Zielen unnötig Angst machen: 197 Bytes
Flash und 2 Bytes auf dem Stack ;-)
Schaffst Du das nicht sag ich trotzdem Dankeschön.
Lothar M. schrieb:> Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist> keinen müden Cent billiger. Und der braucht auch nicht weniger Strom.> Und er ist auch nicht leichter.
Du hast ein "Und" vergessen:
- Und um das alles gehts hier gar nicht!
> Das Einzige, was passiert, ist dass die hocheffiziente und RAM-sparende> Appliktation ein halbes Jahr zu spät an den Markt kommt und sie dann> keiner mehr will.
Ein Argument in einer Firma- bei einem weniger Asm- geeigneten Projekt!
Witkatz :. schrieb:> Die Auflistung der C Schlüsselworte und Operatoren
... wird wohl kaum für prsktische C-Programmierung ausreichen ;-)
> Also was denn jetzt. Erst fantasierst du dir was über C zusammen
Ach woher denn. Da kommt mir z.B. gleich wieder
Beitrag "Einstieg in C - komische Fragen"
in den Sinn. Hilfe! Hilfe!
Klaus W. schrieb:> Irgendwas fehlt hier doch.>> Ach ja: MSR>> Bitte, gern geschehen.
Ist ja eh das meiste.
Wolltest Du mir nicht noch was nachliefern?
Wo überall im SmartHome Asm und 8Bit nicht reichen?
Stefan K. schrieb:> Moby A. schrieb:> Kapselung der Funktionalität>> bedeutet bei Dir:> für jeden Hühnerschiss einen anderen mc. Das definiert der Rest der Welt> irgendwie anders!
Vermutlich beherrscht Du Asm nicht insoweit als daß Du die
Funktionskapselung in meinem Code erkennen konntest ;-)
Was die vielen MC's angeht: Der MC muß sich dort befinden wo er im
SmartHome für Sensor/Aktorknoten auch gebraucht wird. Mit der
allumfassenden 32 Bit Zentral-CPU gewinnst Du da keinen Blumentopf.
Markus M. schrieb:> Mein Code lässt sich kompilieren
... ist aber keine vollständige 1:1 Umsetzung meines Projekts. Merke:
Die .hex soll dann gleich in meine Tiny13-Zielhardware ;-)
Gerhard O. schrieb:> Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein> Österreicher...>> Gerhard
Aber nur fast :-)
Das aber doppelt:
Von der Grenznähe und vom "östlichen" her ;-)
Jay W. schrieb:> Das stimmt nicht. Du versucht aus einem eingeschränkten> Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist,> mit Verlaub, blödsinnig.
Der eingeschränkte Anwendungsbereich der einen lässt Platz frei für die
andere. Was ist daran blödsinnig?
Witkatz :. schrieb:> Moby A. schrieb:> Beschränkt sind eher die Möglichkeiten, mit C..>> Für dich auf jeden Fall. Es ist eine andere Welt.
Und eine Welt ohne jeden Reiz im 8-Bit MSR Bereich!
Gerhard O. schrieb:> Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein> Österreicher...>> Gerhard
Aber nur fast :-)
Das aber doppelt:
Von der Grenznähe und vom "östlichen" her ;-)
Jay W. schrieb:> Das stimmt nicht. Du versucht aus einem eingeschränkten> Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist,> mit Verlaub, blödsinnig.
Der eingeschränkte Anwendungsbereich der einen lässt Platz frei für die
andere. Was ist daran blödsinnig?
Witkatz :. schrieb:> Moby A. schrieb:> Beschränkt sind eher die Möglichkeiten, mit C..>> Für dich auf jeden Fall. Es ist eine andere Welt.
Und eine Welt ohne jeden Reiz im 8-Bit MSR Bereich!
Thomas E. schrieb:> Dafür bekommst du jetzt auch mal ein "lebenswert".
Kannst Du behalten. Lese/zitiere lieber richtig.
Jay W. schrieb:> Welches deiner Programme hat den bis jetzt nicht in einen 8-bit AVR> gepasst? Die "C"-Kompilate passen dann auch rein.> Damit fällt doch auch dieser> pathologische Sparzwang weg.
Möglicherweise. Hier und da.
Was in jedem Fall weg fällt ist die C-Bürokratie.
> "Wer mehr als 2 Byte SRAM oder 1 Byte mehr an Flash verbraucht, hat> verloren." Wie würdest du das bezeichnen? Redest du nicht immer von> "fettem C" ?
Tja Du darfst nicht vergessen, daß wir hier nur von einem <200 Byte
Projektchen reden und noch lange nicht ausgemacht ist wieviel ein
C-Projekt mehr verbraten würde! Hat ja keiner den Mumm, die angeblichen
"15" Minuten zu erübrigen ;-)
> Die wichtigste Ressource im Leben eines Menschen ist die "Zeit". Da du> dein Tinysensorboardprogramm immer noch optimierst, würde ich glattweg> behaupten, dass du deine Lebenszeit verschwendest.
Da optimier ich gar nix. Nur für den Vergleich hier streiche ich hier
und da noch zusammen ;-)
> Assembler zu beherrschen und zu wissen, wann man ihn am besten einsetzt,> sind die Tugenden eines Programmierers, nicht das sture Beharren auf der> Sprache.
Die Tugend besteht immer darin, welche Lösung den geringsten Aufwand
macht. Dazu zählt auch das zu beherrschende Sprachinstrumentarium.
> Ich bin zerknirscht. :-( Manche Tellerränder scheinen ziemlich hoch zu> sein.
Hab auch den Eindruck ;-)
Gerhard O. schrieb:> Zieht die Bremsen an, bevor der Zug unanhaltbar wird.
Gerhard, was fachlich nicht klärt geht fließend ins Entertainment über.
Mach Dir keine Sorgen. Ich hab Spaß dran.
Sheeva P. schrieb:> Moby A. schrieb:> Ich habe Verständnis.>> Wie das? Dazu bedürfte es schließlich eines Verstandes.
Zu Bedeutenderem reichts bei Dir wohl nicht mehr?
Genügend Verstand hätte auch Umsetzung meines Projekts durch einen
C-Programmierer benötigt ;-)
Ralph S. schrieb:> Moby A. schrieb:> Ich möchte nichts erklärt haben, ich möchte überzeugt werden.>> ... das ist schlichtweg eines: G E L O G E N>> ... egal wie oft Sie das wiederholen !>> Sie möchten hier nur eines: Sich unglaublich darüber amüsieren, wieviele> Menschen Ihnen ob ihren absoluten zensiert Beiträgen auf den Leim gehen.>> Jemand, der überzeugt werden mag, macht sich Gedanken. Sie ... haben das> Denken schon seit längerer Zeit schlicht eingestellt !
Für meinen Geschmack schreist Du hier recht wirr durch die Gegend. Ein
untrügliches Anzeichen,wenn sich einer nicht mehr unter Kontrolle hat.
Wenn Du meinst, mir auf den "Leim" zu gehen dann mach das Naheliegende:
Bleib fern. Ein gutgemeinter Ratschlag.
Carl D. schrieb:> Ein Bayer, der nach eigenen Angaben als ersten Computer einen> "Heimcomputer" der frühen 80er der Firma Robotron bediente. Klingt ja> völlig ungelogen.
Tja Carl D. Deine kombinatorischen Fähigkeiten sind wohl auch nicht mehr
das was sie mal waren... Meine Person ist hier aber nicht das Thema, sie
gestaltet es höchstens mit.
So, damit sollten alle wichtigen Beiträge des Tages passend quittiert
sein. Hab die nächsten Tage nicht mehr ganz soviel Zeit. Harte C Fakten
zu meinem Projekt sind vermutlich ohnehin nicht mehr zu erwarten und
wenn, dann bitte ich um Fortsetzung in meinem Projekt-Thread:
Beitrag "Kleines Tiny13 Sensorboard"
Gute Nacht und Danke für die rege Beteiligung ;-)
>Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher>abgeneigt ;-)
Muhaha! Das ist doch mal ein nettes Zitat. Suche mal oben nach Karl
Heinz Vorschlag und ergötze dich wie du dich da rauswindest.
Moby A. schrieb:> Die Auflistung aller Instruktionen ist schnell erledigt, deren> Verständnis auch. Kein Vergleich mit C.
Richtig heist der Satz:
"Die Auflistung aller mir bekannten Instruktionen ist schnell
erledigt, deren Verständnis auch. Kein Vergleich mit C."
Moby A. schrieb:> Das schlimmste ist die unnötige Bürokratie.> Dieser hochgradig umständliche Aufwand.
Gibts eig. einen Grund warum du ständig deine persönlichen Defizite
herausstellst? Wenn du das bischen C Syntax wirklich nicht verstehst
dann sollte dir das eher peinlich sein.
Das schickt man als Rohdaten an den PC und rechnet in Excel. So bleibt
die Reinheit des 8-Bit Glaubens bewahrt und man muss sich nicht mit
fetter Bürokratie rumärgern.
Moby A. schrieb:>> In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten>> möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen>> läßt.>> So edel optimiert muß Software auf einem kleinen Controller aber> ausschauen! Sparsamer Verbrauch, Kapselung der Funktionalität, einfache> Erweiterbarkeit.
Edel Optimiert ?
Das ist dilletantisches Gemurkse bereits beim Grundkonzept.
Wo ist denn Dein ÜVS beim Systemkonzept gewesen ?
Ich bitte Dich, eine synchrone serielle Schnittstelle bei der ich eine
Taktleitung mitschleppen muß ?
Nicht Bus fähig, nicht adresserbar und schnarchlangsam ?
Weder gibt diese verpfuschte Umsetzung jemals vernünftige Datenraten
her, noch werden die Übertragungsfehler sicher detektiert.
Die AD Wandlung misst irgendwas in abhängigkeit der jeweiligen Chips
weil die für genaue Messungen notwendige Kalibrierung nicht stattfindet.
Da kannst Du ruhig 10bit übertragen, das ist trotzdem Schrott mit
begrenzter Aussage.
Keine Entprellung der Inputs ?
Das ist gröbster, dämlichster Pfusch und ist eher ~edel_optimiert, wenn
Du weist was ich meine.
>> Mit Verlaub.>> Das ist vollkommener Müll.> Du meinst weil klar ist, daß man es in C nicht kürzer gebacken bekommt?
Nein, weil Du ja wirklich überhaupt keinen Plan hast wovon Du das
faselst. Das beschränkt sich ja nicht auf Hochsprachen, das sieht bei
Konzeption und Hardware genauso traurig aus.
>> 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 ;-)
Im Gegensatz zu Dir habe ich Systeme in Industrie und Luftfahrt
konzeptioniert und gebaut. Ich kenne sowohl die Theorie als auch die
Praxis die einen Feldbus zum Feldbus macht und warum man gut daran tut
alles was ein paar Meter überbrücken muß störsicher auszulegen.
Dein Kram ist weder billig noch simpel.
Von jedem Knoten eine separate Leitung zum Master legen zu müssen und
für jeden Knoten auf dem Master eigene Ports zu blockieren ist alles
andere als billig und simpel.
Das ist einfach nur dumm und zeugt davon das Du überhaupt nicht in der
Lage bist Konzepte zu verstehen die über Deinen winzigen Tellerrand
hinausgehen.
Dazu verwendest Du die MCU Familie die wohl das schlechteste Preis
Leistungs Verhältniss hat das man derzeit finden kann.
Wenn Du wirklich 10% so clever wärst wie Du glaubst dann wärst Du in der
Lage mit einer fast identischen Hardware, ohne Zusatzkosten einen
Adressierbaren Sensorknoten zu bauen der einen bidirektionalen 1Draht
Bus besitzt, in der Anwendung reprogrammierbar ist und mit einem
kalibrierten AD, entprellten IOs (ja, auch Ausgängen) zuverlässigge
Daten erhebt und die auf Anforderung des Masters mit einer
zuverlässiggen CRC Summe überträgt.
Du hingegen stümperst Dir hahnebüchenden Kram zusammen und nennst das
edel optimiert mit ÜVS.
Zu Ahnungslos zu sein sowas vernünftig umzusetzen kann ich ja noch
akzeptieren, aber zu blöd auch nur ansatzweise zu verstehen was man da
eigentlich in der Summe alles verbockt hat und darauf auch noch stolz zu
sein ist wirklich eine ganz eigene Kategorie.
Ich lege normalerweise nicht so den Finger in die Wunde, aber Deine
Borniertheit schreit ja geradezu danach.
Wenn ich die Codes mir so vergleiche:
Moby:
https://www.mikrocontroller.net/attachment/highlight/277428
Witzkatz:
https://www.mikrocontroller.net/attachment/highlight/277579
Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch
verstehen.
Da werden irgend welche Zahlenwerte in Register geschrieben, ohne
Datenblatt zu wälzen ist es schwer.
Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht
mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten
angesagt.
Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt
die Bits gezeigt die gesetzt werden.
Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das
C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch
wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich
auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann
was gleichbedeutend mit RAM Verbrauch ist.
Daher ist es einfach nur einseitig gedacht "ich brauche kein SRAM" -
obwohl die Register wohl auch SRAM sind. Oder was sind Register denn
sonst?
Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe
angeht: 24 Bit senden, mit 80 ms Pause ???
Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je
nach Auslastung des Programmes des Master Boardes wohl auch nicht so
leicht ist. Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B.
STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur
Synchronisation und kann problemlos mit 9600 Baud geschehen.
Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext
mit übertragen, die von der Gegenstelle gezeigt werden!
Das wäre flexieben, aber so es ist nur eine Krücke/Krampf.
Markus M. schrieb:> Unterm Strich ist der Speicherverbrauch> wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich> auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann> was gleichbedeutend mit RAM Verbrauch ist.
Egal, Moby macht hier die Regeln was eine "Ressource" ist.
- SRAM ist natürlich die Wichtigste, die Kostbarste. Denn mit ihr steht
und fällt die Möglichkeit, seinen Code mit C zu schlagen.
- Erweiterbarkeit, Lesbarkeit, Entwicklungszeit, Testbarkeit,
Portierbarkeit, Wiederverwendbarkeit, Skalierbarkeit dagegen sind
unwichtig. Diese Ressourcen sind billig und müssen daher auch nicht
geschont werden
- insbesondere die Entwicklungszeit ist völlig vernachläsigbar da
Menschen ja über unbegrenzt Freizeit/Lebenszeit verfügen
Moby A. schrieb:> Vermutlich beherrscht Du Asm nicht insoweit als daß Du die> Funktionskapselung in meinem Code erkennen konntest ;-)
Ach ja? Von Dir kann ich das noch nicht mal als Beleidigung auffassen.
Ein hingepfuschtes Frickelprogramm, eine proprietäre serielle
Übertragung in Morsegeschwindigkeit, den kompletten Befehlssatz eines
Anfängerprocessors auch nach Jahren noch nicht vollständig drauf, ASM
bedeutet AVR, weil Dein Horizont knapp davor aufhört ...
Das Einzige, was an Dir wirklich bewundernswert ist, wie Du mit so wenig
Wissen den Mund dermassen voll nehmen kannst.
Markus M. schrieb:> Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch> verstehen.
Dir fehlt ganz eindeutig ÜVS!
Leute, nur noch 33 Beiträge, dann gibt Lothar uns ein Bier aus! :-)
(Oder hatte ich ihn da falsch verstanden? ;)
Markus M. schrieb:> Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je> nach Auslastung des Programmes des Master Boardes wohl auch nicht so> leicht ist.
Ich sag dir, ich würde bares Geld dafür zahlen, den XMega-Code des
Masters sehen zu dürfen.
Insbesondere wie er mehrere Sensorboard-Daten einliest und dieses krude
Protokoll parst während im Hintergrund die Regelung weiterläuft würde
mich echt interessieren.
A. K. schrieb:> Markus M. schrieb:>> Oder was sind Register denn sonst?>> Multiported SRAM. Erheblich teurer als normales SRAM.
PS: Cores mit Akkumulator statt grossem Registersatz sind in dieser
Hinsicht billiger als AVR. Bei Tiny10&Co hat Atmel deshalb den halben
Registersatz weggelassen und lieber ein paar Bytes RAM implementiert.
Dumdideididel die Katz hat die Fidel und die Kuh springt über den Mond.
Einer kleiner Sprung für die Kuh, ein großer Sprung für die Kuhheit.
So, noch 32 Beiträge.
Moby Code:
https://www.mikrocontroller.net/attachment/highlight/277428
Ist ein Spaghetticode ohne erkennbare Struktur, dafür braucht er
wirklich ÜVS, denn sonst könnte er das niemals zu hin bekommen
Witzkatz Code:
https://www.mikrocontroller.net/attachment/highlight/277579
hingegen ist klar strukturiert, ordentliche Bezeichner und unterteilt in
Funktionen mit den einzelnen Aufgaben und somit:
- Wartbarer
- leichter zu erweitern
- leichter anpassbar auf andere Anforderungen
- direkt mit der Spezifikation vergleichbar
> parst während im Hintergrund die Regelung weiterläuft wü
Macht ein extra Hardwarechip, natürlich dazugekauft. Da kein typisches
8bit MSR.
>lieber ein paar Bytes RAM implementiert.
Gut für Moby, kann mehr von der gekauften Ressource nicht verwendet
werden.
Markus M. schrieb:> Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das> C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch> wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich> auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann> was gleichbedeutend mit RAM Verbrauch ist.
Damit blendet er sich selbst. Die RAM-"Einsparung" dient der angeblichen
"Erweiterungsmöglichkeit". Dazu muss der Erweiterer nur einige Register
auf dem Stack sichern.
Wenn also eine Anzahl, sagen wir mal 5, von Registern als Speicher für
globale Variablen benutzt werden, müssen diese von der Erweiterung auf
dem Stack gesichert werden. Das bedeutet, dass immer 5 Byte RAM
"verloren" gehen.
Würde man die Variablen, wie jeder mit Hirn versehene Programmierer das
tut, im RAM anlegen, gingen für die Erweiterbarkeit auch 5 Byte RAM
"verloren".
Was ist der Unterschied für die RAM-Auslastung?
Ausser, dass man sich daran aufgeilen und den grossen Macker spielen
kann, leider gar keiner. Sondern
Überheblichkeit,
Verbohrtheit und
Selbstüberschätzung.
Aber abgerechnet wird zum Schluss. Und dann werden solche unsinnigen
Spielereien schonungslos aufgedeckt. Programmierung ist nämlich kein
Voodoo-Zauber.
@Moby: Mir und den meisten anderen ist klar, dass du das nicht
verstehst.
mfg.
le x. schrieb:> Egal, Moby macht hier die Regeln was eine "Ressource" ist.> - SRAM ist natürlich die Wichtigste, die Kostbarste.
Biete 1k SRAM (garantiert unbenutzt) gegen 1 Monat Lebenszeit.
Wer macht mit?
Markus M. schrieb:> Jörg W. schrieb:>> dann gibt Lothar uns ein Bier aus!>> Jedem Forumteilnehmer?>> Man das gibt ja ne Riesenparty.
Juhuu, dann hatte der Thread ja doch einen Sinn :-)
Jörg W. schrieb:> Leute, nur noch 33 Beiträge, dann gibt Lothar uns ein Bier aus! :-)> (Oder hatte ich ihn da falsch verstanden? ;)
Dann macht mal langsam, ich darf mein Bier erst nächsten Montag
aufmachen. Es ist noch nicht "reif"...
http://www.bergbier.de/brauereibesichtigung.html
>Dann macht mal langsam, ich darf mein Bier erst nächsten Montag>aufmachen. Es ist noch nicht "reif"...>http://www.bergbier.de/brauereibesichtigung.html
Das wirft doch zwangsläufig den notwendigen Vergleich des Ballmer Peak
bei asm oder c-Kodierung auf!
Hat da schon jemand Erfahrungen?
Du hast folgendes behauptet:
> Moby A. schrieb:>> Was interessiert mich hier jede denkbare C-Umsetzung?>> Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation.
Das sollst du jetzt bitteschön endlich mal beweisen.
Moby A. schrieb:> Mein Code liegt vor. Beweise Du jetzt weniger Aufwand mit C.
Nein, dein Code beweist in keiner Weise, dass "Asm in jedem Fall
deutlich magerer" ist. Die Beweislast liegt nun klar bei dir. Du hast
die Behauptung aufgestellt, du musst sie also auch beweisen.
Moby A. schrieb:> Johann L. schrieb:>> Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE>> C-Umsetzung.>> Falsch. Nur> 1. Mit Übung, Vorbereitung, System.> 2. Für den 8-Bit MC Bereich.> 3. Bei wenig Rechnerei und nicht allzuviel Daten!> 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache.
Unter diesen engen Bedingungen soll ASM also immer effizienter als C
sein? Zusammen mit folgender Aussage
Moby A. schrieb:> Asm-Programmierung ist durchschnittlich aufwendiger, aber je nach Übung,> Vorbereitung und System. Dafür kommt mehr Effizienz bei raus. Allein um> diesen Punkt geht es mir aber- und zwar bis hoch zu 1M
frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur
wenige simple Berechnungen durchgeführt werden. Wie viele Daten
verarbeitet werden, spielt nahezu keine Rolle. In erster Linie wird mehr
RAM benötigt, Programmspeicher nur für das Arraygedöhns und eventuale
Initialisierungen.
>Moby A. schrieb:>Allein um diesen Punkt geht es mir aber- und zwar bis hoch zu 1M
Das hatte ich noch gar nicht gelesen.
Wenns so ist, dann sollten wir aber einen Vergleich definieren für einen
Code >> 10kBytes Flash. Und zwar mit einer Textaufgabe als Start.
be s. schrieb:> frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur> wenige simple Berechnungen durchgeführt werden.
Na, Übung, Vorbereitung, System. Halt von allem genügend. :-)
Moby A. schrieb:> Johann L. schrieb:>> Nein, C als Sprache kennt weder Flash noch Register noch Stack oder>> Schalter.>> Was man für effizienten Code aber kennen sollte!
Eine C-Implementation (Compiler) muss solche Konzepte kennen. Aber C
als Sprache braucht von Flash nichts zu wissen. Es ist ja noch nicht
mal klar, ob eine bestimmte Hardware überhaupt Flash hat!
C beschreibt nur Eigenschaften die ein konformer Code haben muss, es
macht keine Aussagen darüber, wie das erreicht werden darf!
Beispiel: Wenn in einem C-Programm "a = b + 1" steht, dann bedeutet das
weder, dass es im erzeugten Code eine Variable namens "a" geben muss,
noch dass es eine Variable "b" geben muss, noch dass es irgendwo im Code
eine Sequenz gibt, die "1" auf irgendwas addiert.
Eine bestimmte C-Implementation (C-Compiler) darf das so machen, ist
aber nicht gezwungen das zu tun.
Und du (und viele andere hier) haben immer noch nicht verstanden, dass
ein bestimmtes C-Programm, das mit einem bestimmten C-Compiler übersetzt
worden ist, nur eine Obergrenze für den von C mindestens
erforderlichen Resourcenverbrauch ergibt.
Was du hier behauptest sind Untergrenzen für den Verbrauch, und dass
dieses Minimum, egal von welchem C-Compiler erzeugt, immer größer ist
als der Verbrauch des von dir vorgelegten Codes.
Vielleicht solltest du dir erst mal den Unterschied zwischen Maximum und
Minimum, zwischen Obergrenze und Untergrenze klar machen?
> C selbst liefert ein Vielfaches an Begrifflichkeiten> (hatte ich alles schon hundert Mal aufgezählt)
C kennt weder den begriff "Bürokratie" noch "Flash" noch "Register".
Aber vielleicht hab ich ja auch was überlesen, und du bist so großzügig,
uns die Stellen im C-Standard aufzuzeigen.
>> Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine>> C-Implementation, und die darf ich wählen wie ich will?>> Du sollst von meiner Funktionsbeschreibung auf ein C-Programm kommen
Und wie willst du von einem C-Programm auf einen Resourcenverbrauch
kommen, ohne eine C-Implementation (vulgo: Compiler) zu haben?
>>> Oder geht's dir nur um Compiler-Bashing?>> Nein. Ich weiß in Compilern steckt einiges KnowHow und viel Arbeit. Es> gibt viele Einsatzgebiete wo C eingesetzt werden kann. Mal sinnvollere,> mal weniger sinnvolle. Zu letzteren zählt 8-Bit MSR.>>> dann nen Blutsturz bekommen weil der 2 Bytes mehr verbraucht hat?>> Spar Dir die Poesie.> Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels> nach ;-)
Wenn das C-Programm deine Spezifikation erfüllt, und dein Asm-Programm
ebenfalls, dann stellt dieses Asm-Programm eine konforme Umsetzung des
C-Codes dar. Mithin wäre dein Asm-Code eine obere Grenze für den
Resourcenverbrauch eines optimalen C-Compilers.
Oder sind deine Programme bewusst so geschrieben, dass sie nicht als
C-Programm formuliert werden können?
>> C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler.>> Nun stellst Du Dich auch noch dumm. Du weißt natürlich, daß der> resultierende Code hier im Fokus steht.
Dafür brauchen wir aber einen Compiler. Welchen sollen wir da nehmen?
>> Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln?>> Keinen.
Moby A. schrieb:> Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels> nach
Wir hatten das alles schon. Du behauptest ständig, Assembler
(meinetwegen mit ÜVS, also: aufwändiger Bürokratie) sei C überlegen.
Statt Deine eigenen Behauptungen zu belegen, wie das unter Erwachsenen
üblich ist, forderst Du, andere sollen Deine Behauptungen widerlegen...
:-)
Das hat Yalu dann getan und Dir unwiderlegbar bewiesen, daß sein
C-Compiler sogar bei solch winzigen Popelprojektchen besseren Code
produziert als Du, was für Yalu, für seinen Compiler, gegen Deine
Fähigkeiten als Programmierer spricht und Dein Geblubber eindeutig
widerlegt. :-)
Daraufhin hast Du plötzlich ein neues Popelprojektchen aus Deinem
Hütchen gezaubert, bei dem Du Dir offensichtlich die größte Mühe gegeben
hast, dem Compiler möglichst viele Fallen zu stellen. Und als mein
Honigtöpfchen dann trotzdem kleiner aussah, mußtest Du auf einmal
panisch die neue Anforderung "darf kein SRAM benutzen" erfinden.
Und genauso würde es wieder laufen, wenn jemand einen C-Code abliefert,
der Dein Sensorprojektchen schlägt: entweder erfindest Du eine neue
Anforderung oder Du kommst gleich mit einem neuen Popelprojektchen um
die Kurve. Been there, done that, got the t-shirt.
Solche Betrügereien sagen ja vor allem etwas über die hohle Frucht, die
sie offensichtlich nötig hat. Und sie sind ein Beweis dafür, daß Du
nicht einmal selbst an Dein dummes Gelaber glaubst. :-)
Sheeva P. schrieb:> Und genauso würde es wieder laufen, wenn jemand einen C-Code abliefert,> der Dein Sensorprojektchen schlägt: entweder erfindest Du eine neue> Anforderung oder Du kommst gleich mit einem neuen Popelprojektchen um> die Kurve.
Glaub ich nicht, dann könnte er sich gleich hier abmelden. ;-)
Außerdem: Sind euch denn die Slimeys, mit denen er fast jede seiner
Aussagen abschließt, verborgen geblieben? ;-)
Der Mann mag Slimeys! ;-)
Könnte man ihm nicht einen C-Compiler bauen, der anstatt des Semikolon
einen Sliley frisst? So als kleines Leckerli um ihn den Einstieg zu
versüßen ;-)
Moby A. schrieb:>> Mein Code lässt sich kompilieren>> ... ist aber keine vollständige 1:1 Umsetzung meines Projekts. Merke:> Die .hex
Wenn du nach C-Umsetzung deines ADC Klackers fragst, bekommst du genau
das - eine C-Umsetzung in edelstem C verfasst. Du darfst sie im Ganzen
oder die einzelnen Routinen davon gerne auf der µC Plattform deiner Wahl
mit dem Compiler deiner Wahl verwenden.
Eine .hex Datei ist kein C-Projekt. Aber das kannst du nicht verstehen,
weil das ein Satz mit C ist.
Also jetzt ein Quiz für Moby und alle, die es werden möchten:
In welcher Programmiersprache ist eine C-Umsetzung verfasst,
A. ist es A,
B. oder B
C. oder vielleicht C?
Als Hauptgewinn winkt 1k freien RAM auf einem attiny13.
Witkatz :. schrieb:> Eine .hex Datei ist kein> C-Projekt.
Schau einer an. Na sowas.
Aber vielleicht ein eindeutiger Ausdruck der manchem hier klarmacht, daß
eine vollständige Umsetzung statt irgendwelcher Bruchstücke gewünscht
ist?
Moby A. schrieb:> Aber vielleicht ein eindeutiger Ausdruck der manchem hier klarmacht, daß> eine vollständige Umsetzung statt irgendwelcher Bruchstücke gewünscht> ist?
Da du ja der erfahrenste von uns allen bist, macht es schon Sinn, das du
die Vorgaben machst.
In den fast 2000 Beiträgen ist doch nunmehr nachlesbar bewiesen, dass
weder Assembler auf dem Vormarsch ist, noch das es C, oft selbst als
Makroassembler verschrien, gelingt, dermaßen schlechten Code zu
generieren wie Moby.
Im Gegenteil, durch sparsame und sinnvolle Verwendung der zur Verfügung
stehenden Ressourcen, enstehen wart- und erweiterbare Anwendungen, die
nur wenig mehr an Ressourcen verwenden. Und das bereits ab einer
Codegröße von wenigen Byte.
Auch das Verwenden von Worthülsen wie SÜV, VSÜ, ÜVS, SVÜ, VÜS und ÜSV
ändert nichts an diesem Ergebnis.
Die Selbstdemontage des einsamen Protagonisten war vollumfänglich und
seiner Sache hat er eher einen Bärendienst erwiesen.
Vielleicht kann dieser Thread ja nun geschlossen werden, bevor Lem recht
behält. ;-)
Robert L. schrieb:> fällte sowas noch unter 8-bit MSR:> Heizkurve berechnen> PI(D) Regler
Für eine reine Raumtemperaturregelung (habe Fernheizung) nicht nötig.
> Dimmkurve für led berechnen
Man kann auch ne Wissenschaft draus machen ;-)
> RMS (Strom/Spannung/(Blind-)Leistung usw.)
Wo fallen da große Berechnungen an? Für Blindleistungs-Berechnung?
Das mag ja für Spezialfälle interessant sein- für alle anderen gibts 10€
Fertiggeräte ;-)
Bei mir hab ich eine einzige selbstgebaute Strommessung im Einsatz: Die
misst den Strom bei einem billigen Heizungs-Stellglied zur Feststellung
des Endanschlags. Und was soll ich Dir sagen: Das geht locker auch mit
Asm. Entsprechende Sensoren sind einfach auszuwerten.
> NTC/PTC Kennlinien
Bei fertigen Temperatursensoren unnötig.
> Sonnenstand berechnen
Da schau ich aus dem Fenster ;-)
> ?
Hab ich mich auch gefragt...
Nein im Ernst, daß (Spezial-) Anwendungen mit erhöhtem Rechen- und
Datenverwaltungsbedarf den Einsatz einer Hochsprache (und ggf. stärkerer
Controller ) rechtfertigen können hatte ich doch nicht ausgeschlossen!
Jay W. schrieb:> dermaßen schlechten Code zu> generieren wie Moby.
Der ließe sich nur mit besserem toppen. Scheint aber nicht so einfach zu
sein ;-)
Michael K. schrieb:> Ich gönne Moby außerdem nicht das letzte Wort
Das letzte Wort spricht Stand heute immer noch mein ungeschlagenes
Asm-Projekt ;-)
Mensch Leute, nun reißt Euch mal am Riemen!
Dermaßen schlechten Code muß doch hier jeder kürzer in C hinbekommen!
Besonders die großen Sprücheklopfer, denen trau ich das am ehesten zu
;-)
Rufus Τ. F. schrieb:> Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will,> muss> sich das hier ansehen:>> Beitrag "Fast JPEG decoder on AT(x)mega"
Was heißt hier wahnwitzig?
In erster Linie ist es möglich!
Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-)
Moby A. schrieb:> Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-)
Gut, dazu zähle ich jetzt nicht, aber es gibt schon interessanten Code.
Auch gelegentlich in ASM.
Den habe ich hier aber noch nicht gesehen :-)
Mist, zu spät :-/
Gut, dann ist dies hier eben der 2001. Beitrag :)
Damit hat Lothar seine Wette grandios gewonnen. Gratulation!
Ich freue mich schon riesig auf das Bier, das er Gerüchten zufolge
ausgeben will :)
Da auch ich nicht mit leeren Händen zur Party kommen möchte, habe ich
eine C-Portierung von Mobys sensationellem 8-Bit-MSR-Assemblerprogramm
mitgebracht, von der sich jeder, der heute bis 24 Uhr einen Beitrag in
diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D
Das Programm entspricht exakt der von lex_91 zusammengefassten und von
Moby bestätigten bzw. ergänzten Spezifikation:
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Kleine Anmerkung an Moby:
Die Bits in deinem Zeitdiagramm stimmen nicht mit deinen aktuellen
textuellen Anforderungen überein. Es stammt wohl von deiner ersten
Programmversion mit der seltsamen Prüfsumme und der umgekehrten
Bitreihenfolge bei der Datenübertragung.
Das Einlesen, die Auswertung und das Versenden der Messdaten findet
komplett im Timerinterrupthandler statt. Das Hauptprogramm läuft nach
der Initialisierungm der I/O-Register in eine leere Endlosschleife. Der
Gesamtablauf ist also praktisch genauso wie bei Mobys Assemblerprogramm.
Auch die Konfiguration des Timers und des ADC habe ich von dort
übernommen, nur mit etwas mehr Symbolik bei den Registerinhalten.
Nach diesen Erläuterungen zur Spezifikation
Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
habe ich die RAM-Initialisierung und den Sleep weggelassen. Für den
Vergleich habe ich auch in Mobys Assemblerprogramm die entsprechenden
Passagen entfernt, was dessen Codegröße um 16 Bytes verringert. Wenn es
gewünscht wird, rüste ich gerne auch eine C-Variante mit Sleep und
RAM-Initialisierung nach.
Quellcode und Hexfile liegen bei, auf dass sie von Moby zerissen werden
mögen (keine Angst, ich habe noch eine Kopie davon) und damit er seine
Spezifikation noch einmal "überarbeiten" kann ;-)
Das Programm wird gebaut mit
Mobys Programm hat noch einen kleinen Fehler: Die Register A1LO1, A1H,
A2LO2 und A2HO3 werden anfangs nicht mit 0 initialisiert, weswegen der
jeweils erste übertragene ADC-Mittelwert für jeden Kanal falsch sein
kann. Ich habe die dafür erforderlichen Befehle (2 CLR und 1 MOVW)
hinzugefügt, wodurch sein Programm wieder um 6 Bytes wächst.
Hier sind die Ergebnisse des Vergleichs:
1
Speicherverbrauch in Bytes
2
3
Mobys ASM Yalus C
4
——————————————————————————————————
5
Flash 206 158
6
SRAM (Stack) 2 2
7
——————————————————————————————————
Ein Teil der eingesparten Flash-Bytes kommt daher, dass in meinem
C-Programm der normalerweise für die ungenutzten Interruptvektoren
vorgesehene Platz mit Programmcode belegt wird. Tut man dies auch bei
Mobys Programm, verringert sich dessen Flash-Bedarf um 18 Bytes auf 188
Bytes, was aber immer noch deutlich über den 158 Bytes des C-Codes
liegt.
Insgesamt hat der Compiler eine recht gute Arbeit abgeliefert: Beim
Durchsehen des erzeugten Assemblercodes sind mir auf Anhieb nur drei
Stellen mit Optimierungsbedarf aufgefallen, bei denen jeweils ein
Registertransfer (MOV bzw. MOVW) eingespart werden könnte. Das würde das
Programm von 158 auf 152 Bytes verkürzen, was aber nicht einmal 4%
ausmacht .
Ich habe das C-Programm auf einen ATtiny13 geladen und für verschiedene
Spannungen und Logikpegel an den Analogeingängen bzw. an PB1 mit dem
Oszilloskop das Takt- und Datensignal überprüft. Sowohl das Timing (im
Rahmen der Genauigkeit des internen RC-Oszillators) als auch die
übertragenen Bits stimmten mit den Vorgaben und auch mit Mobys Programm
überein. Nur den PB5-Eingang habe ich nicht getestet, weil ich dazu den
Reset-Eingang hätte wegfusen müssen. Aber das Programm wird ja sowieso
von Moby noch auf Herz und Nieren geprüft werden :)
***********************************************************************
Es ist also tatsächlich möglich, Mobys Assembleranwendung deutlich
ressourcensparender in C zu schreiben. Damit bietet C nicht nur bei
großen Programmen, sondern sogar bei solchen Miniprogrammen (in Mobys
Sprache "typische 8-Bit-MSR-Anwendungen") klare Vorteile.
***********************************************************************
Natürlich hat Moby das längst geahnt (oder sogar gewusst?) und schon
einmal entsprechend vorgebaut:
Moby A. schrieb:> 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.
Ok, die Ressourcenfrage hat sich nun erledigt.
Als einzige Vorteile von Assembler gegenüber C bleiben also die simple
Codierung und die geringere "Bürokratie". Beide Kriterien lassen sich
aber leider weder klar definieren noch objektiv messen, weswegen sich
bzgl. dieser Punkte am besten jeder sein eigenes Bild macht.
Ein paar Gedankenanstöße hierzu:
1. Simple Codierung
Man vergleiche die Interrupthandler der beiden Programme miteinander:
Obwohl im Wesentlichen beide dasselbe tun, ist die C-Version sehr viel
kompakter. So ist bspw.
1
sum.all+=ADC;
und
1
sum.all/=8;
zur Berechnung des Mittelwerts meiner Meinung nach nicht nur leichter zu
schreiben, sondern auch besser zu verstehen als
1
in r16,ADCL
2
in r17,ADCH
3
add A1LO1,r16
4
adc A1H,r17
und
1
lsr A1H
2
ror A1LO1
3
lsr A1H
4
ror A1LO1
5
lsr A1H
6
ror A1LO1
Hinzu kommen die leichteren Konfigurationsmöglichkeiten. In Mobys Code
kann man immerhin die Spannungsreferenzen für die beiden ADC-Kanäle
getrennt voneinander einstellen (auch wenn ich anfangs nicht ganz
nachvollziehen konnte, woher dieser "magische" Wert $c0 kommt, den man
für die interne Referenz angeben muss ;-)).
In C ist es aber ein Leichtes, auch die komplette Pinbelegung und die
Taktfrequenz der Datenübertragung konfigurierbar zu machen. Einiges
davon ginge sicher auch in Assembler, aber schon die Übersetzung von
Portnummern in die entsprechenden ADC-Kanäle durch den Compiler bzw.
Assembler – in C ganz geradlinig mit einem Compilezeit-Array als
Look-Up-Tabelle möglich – dürfte in Assembler schon einige Verrenkungen
erfordern.
Das Schöne dabei: Der Compiler ändert bei einer Umkonfiguration nicht
einfach nur ein paar Operanden der generierten Maschinenbefehle, wie
dies beim Assembler der Fall wäre, sondern optimiert – je nach Wahl der
Konfigurationsparameter – den Code durch Weglassen unnötiger Befehle
oder gar geschicktes Umschreiben ganzer Befehlssequenzen. In Assembler
erfordert so etwas meist Handarbeit, was nicht nur Zeit kostet, sondern
auch eine potentielle Fehlerquelle darstellt.
Zugegebermaßen gibt es auch in meinem C-Code ein paar Stellen, die man,
wenn man nicht unbedingt jedes einzelne Flash-Byte umdrehen muss, auch
etwas klarer gestalten hätte können. Ich hoffe, dass die Kommentar den
Ablauf trotzdem halbwegs verständlich machen.
2. Bürokratie
Bürokratie hat ja etwas mit Verwaltungswahn zu tun. Anders als in C
obliegt in Assembler die Verwaltung der einzelnen Register und des
Datenspeichers komplett dem Programmierer.
Einige der Register haben eine feste Funktion und sind deswegen von Moby
mit Namen (SIC, A1LO1, A2LO2 usw.) versehen worden. Aber was ist mit den
Registern R16, R17 und R18? Die Bedeutung dieser Register ändert sich
ständig, weswegen keine sinnvollen Namen vergeben werden können. Ohne
Namen ist aber bspw. nur schwer zu erkennen, das der Registerinhalt von
R18 in Zeile 98 eine 14 Zeilen früher angelegte Kopie von SIC ist. Jeder
temporären Variable ein eigenes benamstes Register zuzuordnen geht aber
auch nicht, weil sonst die 32 Register ganz schnell aufgebraucht sind.
Wenn man nicht sorgfältig Buch darüber führt, von wo bis wo im Code
jedes Register welchen Inhalt hat, wird man ziemlich schnell im Chaos
versinken. Diese Buchführung wird durch die vielen assemblertypischen
Kreuz- und Quersprünge noch zusätzlich erschwert.
Wenn man dann nicht nur Register, sondern auch noch Statusflags zur
Übertragung von Informationen über weite Strecken innerhalb des
Programms nutzt, ist die Buchführung durch den Programmierer kaum mehr
praktikabel, da die Änderungen der Statusflags durch die entsprechenden
Befehle meist implizit erfolgt, was schnell einmal übersehen wird.
In diese Falle ist trotz ÜVS sogar der Meister höchstpersönlich getappt,
als er eins seiner anderen Miniprogrämmchen schnell mal um ein paar
scheinbar triviale Dinge erweitern wollte, wodurch halt zufälligerweise
einer der hinzugefügten Befehle an ungünstiger Stelle das Carryflag
überschrieb:
Beitrag "Re: C versus Assembler->Performance"
Und was geschieht, wenn das Programm trotz aller Vorbereitung am Ende
doch etwas datenintensiver wird und man gerne ein paar Variablen von
"guten" Registern (R16 bis R31) in die weniger guten (R0 bis R15 mit
eingeschränkten Adressierungsarten) oder gar ins RAM verlagern möchte?
Oder der 8-Bit-Wertebereich stellt sich für eine Variable als zu knapp
heraus, und man möchte stattdessen mit 16-Bit-Werten in Registerpaaren
arbeiten? In C sind das alles keine großen Herausforderungen, in
Assembler hingegen läuft das ganz schnell auf das Neuschreiben ganzer
Codepassagen hinaus.
In höheren Programmiersprachen ist für solche Buchhaltertätigkeiten ganz
klar der Compiler zuständig, der auch bei komplexen Programmen nie den
Überblick verliert. Natürlich muss der Programmierer den Compiler dabei
mit ein paar Informationen unterstützen, was wohl das ist, was Moby als
Bürokratie empfindet. Dass man all diese Information bei der Assembler-
Progammierung ebenfalls vorhalten muss (statt im Quellcode eben auf
einem Blatt Papier, das gerne verloren geht oder gar im Kopf, der sie
nach ein paar Wochen vergisst), ist ihm wohl nicht bewusst.
Anders als in anderen höheren Programmiersprachen kann man – sofern man
das möchte – in C die Verwaltungsaebeit des Compilers in vielfältiger
weise beeinflussen, um mehr Effizienz des Programms zu erzielen.
So gibt es im obigen C-Programm einige explizite Registerzuordnungen für
globale Variablen. Diese sind aber nur Mobys unsinniger Anforderung nach
null RAM-Verbrauch geschuldet und würden bei dieser Anwendung (und den
allermeisten anderen ebenfalls) weggelassen werden, da sie nur ganz
selten einen wirklichen Nutzen bringen.
Normalerweise macht sich der C-Programmierer keine Gedanken darüber, in
welchen RAM-Zellen oder Registern Variablen abgelegt werden und wann
sich mehrere temporäre Variablen ein Register teilen, weil es einfach
viel zu viel Bürokratie wäre, über das alles im Detail Bescheid wissen
zu müssen ;-)
3. Weitere Kriterien
Moby, dir fallen doch ganz neben dem Ressourcenverbrauch, der simplen
Codierung und der Bürokratie, in denen ASM nun ja doch nicht ganz so gut
abschneidet, noch weitere (am besten messbare) Kriterien ein, die man
zum Vergleich zwischen Assembler und C heranziehen könnte. Das würde mal
wieder etwas neuen Schwung in die Diskussion bringen, so dass der Thread
auch nach dem Überschreiten der 2000er-Grenze unterhaltsam bleibt.
Ich bin auf deine neuen Argumente schon gespannt wie ein Flitzebogen ;-)
Moby A. schrieb:> Jay W. schrieb:>> dermaßen schlechten Code zu generieren wie Moby.>> Der ließe sich nur mit besserem toppen. Scheint aber nicht so einfach zu> sein ;-)
Moby, diese Aussage ist eine rabulistische Meisterleistung. Chapeau!
Mittlerweile hat Yalu nun auch den endgültigen Beweis erbracht. Für
seine Leistung und seinen Langmut gebührt ihm meine höchste Anerkennung.
Wahnsinn!
Der Moby ist ja wieder da, also poste ich das nochmal...
Wenn ich die Codes mir so vergleiche:
Moby:
https://www.mikrocontroller.net/attachment/highlight/277428
Ist ein Spaghetticode ohne erkennbare Struktur, dafür braucht er
wirklich ÜVS, denn sonst könnte er das niemals hin bekommen
Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch
verstehen.
Da werden irgend welche Zahlenwerte in Register geschrieben, ohne
Datenblatt zu wälzen ist es schwer.
Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht
mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten
angesagt.
Witzkatz Code:
https://www.mikrocontroller.net/attachment/highlight/277579
Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt
die Bits gezeigt die gesetzt werden.
hingegen ist klar strukturiert, ordentliche Bezeichner und unterteilt in
Funktionen mit den einzelnen Aufgaben und somit:
- Wartbarer
- leichter zu erweitern
- leichter anpassbar auf andere Anforderungen
- direkt mit der Spezifikation vergleichbar
- einzelne Anschnitte der Spezifikation in Funktionen gepackt, womit
eine Änderung der Spezifikation leichter umsetzbar ist.
Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das
C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch
wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich
auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann
was gleichbedeutend mit RAM Verbrauch ist.
Daher ist es einfach nur einseitig gedacht "ich brauche kein SRAM" -
obwohl die Register wohl auch SRAM sind. Oder was sind Register denn
sonst?
Wie schon mal von mir geschrieben: ein STM32 hat CCM RAM, also kann ich
problemlos alles, incl. Stack dort drin laufen lassen und es wird KEIN
SRAM benutzt. Und wenn ich einen externen DataFlash anschließe und das
Programm in den RAM lade, braucht es auch kein FLASH mehr (das geht z.B.
mit Cypress µC). Somit, Moby deine Anforderungen sind einfach nur
Blödsinn.
Und der Preis vom schlechtesten Spagetti Code hast du allemal gewonnen.
Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe
angeht: 24 Bit senden, mit 80 ms Pause ???
Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je
nach Auslastung des Programms des Master Boards wohl auch nicht so
leicht ist. Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B.
STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur
Synchronisation und kann problemlos mit 9600 Baud geschehen.
Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext
mit übertragen, die von der Gegenstelle gezeigt werden!
Das wäre flexibel, aber so es ist nur eine Krücke/Krampf.
Jay W. schrieb:> Vielleicht kann dieser Thread ja nun geschlossen werden, bevor Lem recht> behält. ;-)
Nö. Bevor die C-Fraktion sich vollends blamiert ;-)
Michael K. schrieb:> Ich bitte Dich, eine synchrone serielle Schnittstelle bei der ich eine> Taktleitung mitschleppen muß ?
Das möchte ich mal aus Deinem Plädoyer für eine kompliziertere,
umständlichere Lösung herausgreifen: Du checkst offensichtlich nicht,
daß diese Taktleitung a) einer easy Auswertung dient und b) einen nicht
genau bekannten/schwankenden MC-Takt wie er nunmal von einem internen
Osc geliefert wird zur Verwendung ermöglicht. Ansonsten ist meine Lösung
für die gegebene Sensorausstattung fast ideal optimiert und simpel. So
muß das ausschauen!
Markus M. schrieb:> Wenn ich die Codes mir so vergleiche:> Moby:> https://www.mikrocontroller.net/attachment/highlight/277428>> Witzkatz:> https://www.mikrocontroller.net/attachment/highlight/277579>> Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch> verstehen.
Da wären AVR-Asm Kenntnisse angebracht ;-)
> Da werden irgend welche Zahlenwerte in Register geschrieben, ohne> Datenblatt zu wälzen ist es schwer.
Für einen ASMler gehört zur optimalen Controller-Anpassung immer das
Datenblatt in die Hand.
> Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht> mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten> angesagt.
Ein Label im funktionsführenden (Timer-) System-Interrupt.
> Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt> die Bits gezeigt die gesetzt werden.
Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist
professionelles Vorgehen.
> Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das> C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch> wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich> auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann> was gleichbedeutend mit RAM Verbrauch ist.
Könnte man meinen. Den gleichen Registersatz R0-32 hat aber jederAVR.
Im zusätzlichen RAM unterscheiden sie sich. Der soll gespart werden. Den
Registersatz hatte ich für C nicht verboten zu nutzen. Auch wenn mehr
als 11 genutzte Register dann vergleichsmäßig sehr unschön rüberkommen
;-)
> Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe> angeht: 24 Bit senden, mit 80 ms Pause ???> Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je> nach Auslastung des Programmes des Master Boardes wohl auch nicht so> leicht ist.
Die Pause dient der Synchronisierung und macht die einfache Auswertung
erst möglich. Ein Beispiel ist in meinem Projekt enthalten!
> Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B.> STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur> Synchronisation und kann problemlos mit 9600 Baud geschehen.
Aber nicht mit Tiny13 ohne UART. Der langt für die Aufgabe aber genauso.
Eine UART setzt auch noch einen hinreichend genauen Systemtakt voraus.
> Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext> mit übertragen, die von der Gegenstelle gezeigt werden!
Man könnte vieles und jenes. Die gestellte Aufgabe wird aber erfüllt.
> aber so es ist nur eine Krücke/Krampf.
Aber so ist es die optimale Umsetzung der Aufgabenstellung mit viiel
Platz übrig für Erweiterungen ;-)
Yalu X. schrieb:> Ok, die Ressourcenfrage hat sich nun erledigt.
Na schaun mer mal. Morgen hab ich etwas Zeit Deinen Code praktisch zu
prüfen. Würd mich freuen wenn er weiteren Streit erübrigen würde.
> Ich bin auf deine neuen Argumente schon gespannt wie ein Flitzebogen ;-)
Bekommst Du ;-)
Danke für's Erste.
Rufus Τ. F. schrieb:> Es ist --wie jedes Assemblerprogramm-- praktisch unwartbar.
Wie hab ich bloß die letzten 20 Jahre überstanden ;-)
Jay W. schrieb:> Für> seine Leistung und seinen Langmut gebührt ihm meine höchste Anerkennung.> Wahnsinn!
Es hätte, wenn meine realisierte Funktion tatsächlich 1:1 abgebildet
wird, auch lang genug dazu gebraucht. Wahnsinn ;-)
Moby A. schrieb:> Da wären AVR-Asm Kenntnisse angebracht ;-)Moby A. schrieb:> Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist> professionelles Vorgehen.
Wieso sollte ich nun unbedingt den Dialikt vom AVR lernen?
Der nächste schreibt ein PIC ASM Code, der nächste MIPS und wieder einer
Renesas.
Jedes mal irgend ein µC spezifischen Code lernen, damit ich das von
fremden Leuten verzapfte verstehe?
Ne danke. Ich bleib bei C.
Das ist so ähnlich wenn es elektronische Datenblätter in Chinesisch,
Russisch, Französisch, Italienisch, Hebräisch usw. gäbe.
Aber zum Glück sind alle englisch und ein jeder Weltweit braucht nur
Englisch lernen!
Moby A. schrieb:>> Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt>> die Bits gezeigt die gesetzt werden.>> Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist> professionelles Vorgehen.
Das ist mal wieder dein übliches Geblubber.
Ein Datenblatt brauche ich für Prozessorspezifisches.
In deinem Gewusel braucht man es aber auch für triviale Sachen, wie
elementare Operationen über mehrere Anweisungen, wo man in jeder
vernünftigen Sprache etwas lesbares hinschreibt.
Wobei man natürlich auch in ASM mehr oder weniger klar ausdrücken kann;
ebenso wie ein Depp natürlich auch in anderen Sprachen unlesbares
Kauderwelsch schreibt.
Nur ist es in Hochsprache halt leichter und schneller, sauberen
Quelltext zu schreiben - der auch dank eines Compilers noch effizient
ist.
Würde dich lesbarer Quelltext interessieren, würdest du entweder
schöneres ASM hinschreiben, oder gleich etwas anderes nehmen.
Aber jeder wie er will, ich muß mit deinen Quelltexten ja nichts machen.
Moby A. schrieb:> Rufus Τ. F. schrieb:>> Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will,>> muss sich das hier ansehen:>>>> Beitrag "Fast JPEG decoder on AT(x)mega">> Was heißt hier wahnwitzig?> In erster Linie ist es möglich!
Ja klar ist sowas möglich, warum sollte sowas nicht möglich sein?
> Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-)
So ein Projekt ist beachtlich. Unbegreiflich für mich ist jedoch, warum
man es so implementiert, dass die Wiederverwendbarkeit stark
eingeschränkt ist (Atmel-Assembler) und es insbesondere unmöglich ist,
den Code von C aus zu verwenden.
Das ist doch überaus kurzsichtig. Vor allem weil es kein Mehraufwand
gewesen wäre, Wiederverwendbarkeit zu bieten.
Wenn man sich schon solche Arbeit macht, warum dann nicht so
programmieren, dass es möglichst vielseitig verwendbar ist?
Mir steht da echt der Mund offen ... nämlich wegen der dargebotenen
Kurzsichtigkeit.
Yalu X. schrieb:> Hier sind die Ergebnisse des Vergleichs:>> Speicherverbrauch in Bytes>> Mobys ASM Yalus C> ——————————————————————————————————> Flash 206 158> SRAM (Stack) 2 2> ——————————————————————————————————
Herrlich, im Ring heist das K.O. auf ganzer Linie.
Ich sehe Moby aber schon wieder das Maul aufreisen wegen ......... nun
ja wegen was wohl?
Nun ihm wird schon was einfallen.
Johann L. schrieb:> Mir steht da echt der Mund offen ... nämlich wegen der dargebotenen> Kurzsichtigkeit.
Ich sehe solche Ansätze eher in der Tradition jeder Spinner, die sich
zusammen mit möglichst vielen anderen Leuten in eine Telefonzelle
quetschen. Kann Spass machen und man ist hinterher stolz. Aber um
telefonieren geht es dabei üblicherweise nicht.
Gu. F. schrieb:> Yalu X. schrieb:>> Hier sind die Ergebnisse des Vergleichs:>>>> Speicherverbrauch in Bytes>>>> Mobys ASM Yalus C>> ——————————————————————————————————>> Flash 206 158>> SRAM (Stack) 2 2>> ——————————————————————————————————>> Herrlich, im Ring heist das K.O. auf ganzer Linie.> Ich sehe Moby aber schon wieder das Maul aufreisen wegen ......... nun> ja wegen was wohl?> Nun ihm wird schon was einfallen.
Hab es doch gesagt: Jeder findet seinen Meister.
Ich vermute: Yalu hat mehr ÜVS benötigt.
Yalu X. schrieb:> Das Programm wird gebaut mit>> avr-gcc-4.7.4 -mmcu=attiny13 -Os -nostdlib -o sensorboard sensorboard.c
Wie geht das denn nun am einfachsten?
Code einfach in ein Studio-Projekt für Tiny13 reinkopieren und Solution
builden/assemblieren wie bei Asm ist ja hier nicht.
Entsprechendes für ein GCC-Projekt erzeugt nur Fehlermeldungen.
Hilfe! Möchte für eine einfache .hex Erstellung nicht gleich im
C-Optionschaos versinken ;-(
Moby A. schrieb:> Wie geht das denn nun am einfachsten?
Debian installieren und das darin enthaltene Paket gcc-avr installieren.
Der ist zwar 4.7.2, liefert aber auch 158 Bytes ab. in Yalus
Kommandzeile ändert sich dann nur ebendiese Versionsnummer.
Ok, das ist natürlich hauptsächlich dann am einfachsten, wenn man
sowieso schon so eine Kiste rumliegen hat. ;-)
Gu. F. schrieb:> Setzt die hin und fang endlich an zu lernen.
Ganz sicher werd ich das jetzt nicht durcharbeiten nur um eine .hex
eines C-Codes zu erstellen ;-)
Einfach heißt: Code reinladen, compilieren, .hex!
A. K. schrieb:> Debian installieren und das darin enthaltene Paket gcc-avr installieren.
Köstlich. Genau das werd ich jetzt...
Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus
Code. Das wär schade.
Moby A. schrieb:> Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus> Code. Das wär schade.
Ich fand das toteinfach. Ich musste einfach nur Yalus Kommandozeile
ausführen. Der Rest war schon da.
Wenn du natürlich noch nicht einmal einen Compiler auf der Kiste hast,
dann wird es wirklich schwierig, den Compiler zu starten und somit
völlig unmöglich, deinen Forderungen nachzukommen. Aber das gilt
umgekehrt auch, weil meine Debian-Kiste mit deinem Asm-Quellcode genauso
über Kreuz liegt.
A. K. schrieb:> Wenn du natürlich noch nicht einmal einen Compiler auf der Kiste hast,
Wer sagt das? Mein Studio7 enthält einen. Ich kann problemlos ein
GCC-Projekt erstellen.
> Aber das gilt> umgekehrt auch, weil meine Debian-Kiste mit deinem Asm-Quellcode genauso> über Kreuz liegt.
Warum sollte sich mein Asm-Code dort nicht genauso assemblieren lassen
wie er auf dem Bildschirm erscheint?
Moby A. schrieb:> Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus> Code.
Ich habe doch extra für dich, auch weil du es so gefordert hast, das
Hex-File angehängt. Das schiebst du auf die gleiche Weise auf den
Controller wie du es mit mit deinen sonstigen Programmen tust.
Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt
nicht nur deine, sondern auch meine Fähigkeiten.
Moby A. schrieb:> Wer sagt das? Mein Studio7 enthält einen. Ich kann problemlos ein> GCC-Projekt erstellen.
Weshalb weigerst du dich dann, das zu tun?
> Warum sollte sich mein Asm-Code dort nicht genauso assemblieren lassen> wie er auf dem Bildschirm erscheint?
Weil auf genannter Debian-Kiste kein Assembler von Atmel drauf ist und
der GNU Assembler eine völlig andere Quellcode-Notation verwendet.
Yalu X. schrieb:> Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt> nicht nur deine, sondern auch meine Fähigkeiten.
Zuviel Bürokratie? ;-)
Yalu X. schrieb:> das> Hex-File angehängt.
Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da
wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern
hergestellt.
> Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt> nicht nur deine, sondern auch meine Fähigkeiten.
Klasse.
Das spricht für C ;-)
A. K. schrieb:> Weshalb weigerst du dich dann, das zu tun?
Wer sagt das ich mich weigere?
Von Fehlermeldungen bei der Projekterstellung / Buildvorgang hatte ich
doch schon gesprochen, oder?
Moby A. schrieb:> Das spricht für C ;-)
Yalu verwendet möglicherweise nicht das anerkannte Monster an
Bürokratie, das Atmel mit dem Studio 7 in die Welt gesetzt hat. Du
jedoch scheinst mit überbordender Bürokratie diesmal ausnahmsweise keine
Probleme zu haben. Denn so einen fetten Klops auf die Kiste zu wuchten,
bloss um einen ATtiny13 zu füttern, das spottet jeder Beschreibung.
A. K. schrieb:> Du> jedoch scheinst mit überbordender Bürokratie diesmal ausnahmsweise keine> Probleme zu haben.
Die Projekterstellung/Assemblierung selber ist wie beschrieben
ausgesprochen einfach.
> Denn so einen fetten Klops auf die Kiste zu wuchten,> bloss um einen ATtiny13 zu füttern, das spottet jeder Beschreibung.
Da spottet gar nichts denn damit wird nicht nur ein Tiny13 versorgt ;-)
Moby A. schrieb:> Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da> wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern> hergestellt.
Tut es auch der Asm-Output vom Compiler?
A. K. schrieb:> Tut es auch der Asm-Output vom Compiler?
Das ist wenigstens mal ein Angebot. Danke.
Freilich hätte ich dessen Erstellung schon gern selbst in der Hand.
Morgen schau ich erstmal was die .hex in meiner Hardware so treibt.
A. K. schrieb:> Und nochmal als Disassembly, mit C Quellcode zwischenrein gemixt.
OK. Prima.
Die Einarbeitung in Linux kommt allein für diese Geschichte hier nicht
in Frage.
Moby A. schrieb:> Die Einarbeitung in Linux kommt allein für diese Geschichte hier nicht> in Frage.
Wär wohl auch nicht nötig. Wahrscheinlich lässt sich im Studio
enthaltene GCC auch direkt per Kommandozeile aufrufen - wenn man weiss
wie. Aber das ist mir zu viel Bürokratie.
Gu. F. schrieb:> Nun ihm wird schon was einfallen.
Schon geschehen:
Moby A. schrieb:> Wie geht das denn nun am einfachsten?Moby A. schrieb:> Hilfe! Möchte für eine einfache .hex Erstellung nicht gleich im> C-Optionschaos versinkenMoby A. schrieb:> Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus> Code.Moby A. schrieb:> Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da> wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern> hergestellt.
Einfach nur erbärmlich.
mfg.
Thomas E. schrieb:> Einfach nur erbärmlich.
Alles berechtigte Einwände und Fragen für jemanden der die Wissenschaft
"C" bisher nicht nötig hatte. Erbärmlich ist eher Deine (fehlende)
Antwort darauf ;-)
Moby A. schrieb:> Yalu X. schrieb:>> das>> Hex-File angehängt.>> Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da> wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern> hergestellt.
Du glaubst also, ich schummle, und das Hex-File stammt in Wirklichkeit
von einem Assemblerprogramm, das ich in mühevoller Arbeit mit viel ÜVS
von Hand geschrieben habe?
Und A. K. unterstützt mich auch noch bei meiner Schummelei, indem er
einen angeblichen Asm-Output des Compiler postet, den er in Wirklichkeit
von mir zusammen mit einem Barscheck zugesandt bekommen hat?
Die beiden Compiler-Versionen erzeugen übrigens exakt den gleichen Code,
die Asm-Outputs unterscheiden sich nur in der nicht relevanten letzten
Zeile:
Bitte zu den Programmanforderungen hinzufügen:
- muß von jeden V..horst, der keinen Bock hat sich damit zu befassen von
Sourcecode aus direkt in den ATtiny13 geflashed werden können.
Was hatte irgendwer schon mal geschrieben: er wird neue Anforderungen
finden, die das C-Programm nicht erfüllt.
Carl D. schrieb:> - muß von jeden V..horst, der keinen Bock hat sich damit zu befassen von> Sourcecode aus direkt in den ATtiny13 geflashed werden können.
Einfaches Handling ist auch ein Aspekt der Bürokratie. Asm bietet das. C
wie wir gesehen haben nicht.
> Was hatte irgendwer schon mal geschrieben: er wird neue Anforderungen> finden, die das C-Programm nicht erfüllt.
Solche Vorhersagen kannst Du in der Pfeife rauchen. Beschäftige Dich mit
dem was hier eigentliches Thema ist, dann siehst Du auch für die Zukunft
klarer. Und wenn ein
Carl D. schrieb:> nicht“Gast“ schrieb:>> Warte nur, bis Moby hier aufschlägt. Der weiß wirklich Bescheid, was man>> so alles auf einen Atmel braucht. ;)>> Dann werde ich sofort von Jörg W.'s Angebot Gebrauch machen, ihn> rausbekamen zu lassen.
beweist er nur, das oberste Level an Ratlosigkeit erreicht zu haben.
Auch wenn die kleine Unsicherheit im entscheidenden Wort noch etwas Raum
zur Hoffnung lässt ;-)
Blöd auch daß Jörg Wort gehalten hat. Danke!
Und zu "Bürokratie":
Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu
kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt
ab.
Yalu X. schrieb:> Die beiden Compiler-Versionen erzeugen übrigens exakt den gleichen Code,> die Asm-Outputs unterscheiden sich nur in der nicht relevanten letzten> Zeile:>> $ diff sensorboard-yalu.s sensorboard-ak.s> 138c138> < .ident "GCC: (GNU) 4.7.4"> --->> .ident "GCC: (GNU) 4.7.2"
Yalu, du weißt ja schon um die Kryptischen DIFF ausgaben verstehen zu
können man einige Wochen Einarbeitungszeit benötigt.
Das ist viel zu komplex und bürokratisch.
Und wehe Du hast auch noch den DIFF umgeschrieben ....
Yalu X. schrieb:> Du glaubst also, ich schummle, und das Hex-File stammt in Wirklichkeit> von einem Assemblerprogramm, das ich in mühevoller Arbeit mit viel ÜVS> von Hand geschrieben habe?
Nein. Das glaube ich nicht.
Trotzdem wird es doch wohl legitim sein zu verlangen, daß ich Deinen C
Code selbst nachvollziehen kann.
Interessant wär mal der hier schon oft erwähnte Aspekt der
Entwicklungszeit: Etwa von Beitrag 1 dieses Threads an? Oder gar von
noch früher? (meinen Projektthread gibts ja schon ne ganze Weile)
;-)
Carl D. schrieb:> Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu> kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt> ab.
Du wirst mir sicher gleich sagen, wo das in der AtmelStudio- Software
bloß "einzutippen" ist. Zeig Deinen "Interlekt" mal ;-)
Markus M. schrieb:> Start > Ausführen > CMD.EXE
Na probiers mal. Was dann wohl kommt???
Ich hoffe doch schon, daß ein MS Windows und ein fettes 7er Studio
auslangen ;-)
Tipp: Du hast
Yalu X. schrieb:> Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt> nicht nur deine, sondern auch meine Fähigkeiten.
überlesen ;-)
Robert L. schrieb:> projekt anlegen> code rein kopieren> ja, man bekommt einen fehler> -> checkbox für nostdlib suchen> -> optimierung hoch stellen> schon gehts..
Danke Robert. Das schau ich mir nochmal an.
be s. schrieb:> frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur> wenige simple Berechnungen durchgeführt werden.
Die Sorge möchte ich Dir nehmen.
1M war etwas ironisch gemeint ;-)
le x. schrieb:> - SRAM ist natürlich die Wichtigste, die Kostbarste. Denn mit ihr steht> und fällt die Möglichkeit, seinen Code mit C zu schlagen.
Na vielleicht stimmt das ja gar nicht ?
Morgen sehen wir weiter.
Man Leute, gestern wäre das hier bei 1985 fast eingeschlafen.. Jetzt
stehts bei 2047..
Und Yalu hat nochmal bewiesen, was ausser Moby alle wussten.
Sodann: Grossartig und Skoll:
>der heute bis 24 Uhr einen Beitrag in>diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D
bleibt nur noch eins zu sagen:
Matthias L. schrieb:> Man Leute, gestern wäre das hier bei 1985 fast eingeschlafen..> Jetzt stehts bei 2047..
Ich hatte die Hoffnung, dass da bei 2000 nochmal Schwung in die Sache
kommt... ;-)
Yalu X. schrieb:> Damit hat Lothar seine Wette grandios gewonnen. Gratulation!
War ja einfach...
> Ich freue mich schon riesig auf das Bier, das er Gerüchten zufolge> ausgeben will :)
Du darfst dir auch eines aufmachen. Das hast du dir verdient. Aber echt:
ein Code der abzüglich der unnötigen Kommentare und trotz der vielen
Umbrüche komplett auf eine Seite passt. Genial!
So, anbei noch ein Atmel Studio7-Projekt. Ich hoffe mal, dass die
getroffenen Einstellungen alle mitgesichert werden.
PS. Ich sehe gerade mein Kompilat hat noch 166 Bytes Verbrauch, also
habe ich wohl einen Einstellungsfehler. Aber die Größe reicht ja auch.
A. K. schrieb:> Wahrscheinlich lässt sich im Studio enthaltene GCC auch direkt per> Kommandozeile aufrufen - wenn man weiss wie.
Dazu täte es einfach not, dass man, statt auf andere Betriebssysteme
zu schimpfen, in die man sich nicht „einarbeiten“ will, sich wenigstens
mal in das auserwählte eigene Betriebssystem einarbeitete, um ein
Konzept wie das des Suchpfades verstanden zu haben.
Dummerweise übernimmt das Gigabyte-Monster von Atmel es halt nicht
automatisch, den Suchpfad zum Compiler selbst im System einzutragen.
Wäre wohl zu viel Bürokratie.
Das Ändern der PATH-Variablen in Windows hat allerdings eines der
grauenvollstens GUIs, die es gibt. Man bekommt auf einen Pfadnamen
von in der Regel mehreren hundert Zeichen Länge nur ein kleines
Guckloch. Während sonst jeder Ar***h heutzutage im Vollbildmodus
starten will (wen interessiert schon, dass der Monitor 1900 Zeichen
breit ist und viel Platz für anderes böte, wenn man sich gerade die
Smartphone-Welt als Ziel ausgemacht hat?), kann man dieses beknackte
GUI auch nicht in der Größe ändern.
Jörg W. schrieb:> Das Ändern der PATH-Variablen in Windows hat allerdings eines der> grauenvollstens GUIs, die es gibt.
Und je nach Windows Version ist schon allein die Suche nach diesem
Dialog ziemlich spannend.
Moby A. schrieb:> Interessant wär mal der hier schon oft erwähnte Aspekt der> Entwicklungszeit: Etwa von Beitrag 1 dieses Threads an? Oder gar von> noch früher? (meinen Projektthread gibts ja schon ne ganze Weile)
Dir ist wirklich nichts zu peinlich, oder? Schau mal nach, seit wann es
die von dir bestätigte Programmspezifikation gibt. Bei deiner
schlangenartigen Argumentationsweise in diesem und anderen Threads, bin
ich mir sicher, dass niemand vorher ernsthaft angefangen hat.
Yalu wird vermutlich heute vormittag, nach einem erquicklichen Schlaf
und einem reichhaltigen Frühstück, die Zeit bis zum Mittag genutzt
haben, um das Programm zu schreiben. Nach dem Mittag und dem
dazugehörigen Schläfchen hat er es dann veröffentlicht.
Das war ja einfach.
Jay W. schrieb:> PS. Ich sehe gerade mein Kompilat hat noch 166 Bytes Verbrauch, also> habe ich wohl einen Einstellungsfehler.
Oder eine andere Version des Compilers. Robert kam beim Studio 6.2 mit
GCC 4.8.1 auch auf 166 Bytes.
A. K. schrieb:> Oder eine andere Version des Compilers. Robert kam beim Studio 6.2 mit> GCC 4.8.1 auch auf 166 Bytes.
Korrekt. Im Studio 7 werkelt ein GCC 4.9.2
Thread beobachten
Seitenaufteilung abschalten