Ihr habt ja immer schöne Stories und Vergleiche drauf... Leider trifft das die Situation hier mal wieder nicht. Da liegt es nämlich in der Natur künstlicher Probleme, daß sie sich leicht vermeiden ließen ;-)
:
Bearbeitet durch User
Gu. F. schrieb: > Dann hör jetzt endlch auf um den heisen Brei rum zu reden und zeig > endlich eine dieser Anwendungen und zwar eine von DIR (!) und eine mir > mehr als 20 Zeilen. Und? Wie sind gespannt...
Gu. F. schrieb: > Gu. F. schrieb: > Dann hör jetzt endlch auf um den heisen Brei rum zu reden und zeig > endlich eine dieser Anwendungen und zwar eine von DIR (!) und eine mir > mehr als 20 Zeilen. > > Und? > Wie sind gespannt... Gibts gerade nix zum nachplappern daß Du Dich schon selbst zitieren mußt? Weißt Du worauf ich gespannt bin? Wann Du mal zählen kannst ;-)
Moby A. schrieb: > Weil ab einer bestimmten Projektgröße der Überblick > verlorengeht. Trotzdem sind der Möglichkeiten des Asm-Programmierers > diesen zu behalten auch nicht gerade wenige. Das ist genau das, was du nicht kapierst. Dass man beim Programmieren den Überblick verliert, ist nicht etwa ein blöder Unfall, sondern völlig zwangsläufig: Ein Mensch kann bereits ein kleineres Projekt nicht mehr ohne weiteres überblicken. Den Überblick zu behalten ist die Hauptherausforderung in der Konzeption von Software und Programmiersprachen. Der Flaschenhals liegt beim Überblick (und damit Wartbarkeit, Korrektheit, Sicherheit, Erweiterbarkeit, ...) und nicht bei einzelnen Taktzyklen oder Speicherbytes. Du optimierst schlicht am falschen Ort für 99.9% der praktischen Projekte, kleinste Mikrocontrollerprojekte eingeschlossen. Und ich möchte dich ja mal sehen, einen Code für eine GPU oder einen modernen Mehrkern-Prozessor in Assembler effizienter hinzukriegen als der Compiler es kann. Vermutlich wirst du jetzt argumentieren, dass sei hier gar nicht Thema, aber im übernächsten Beitrag kommt dann trotzdem wieder die Aussage, deine Behauptungen würden prinzipiell für jedes Programm gelten. Nein, tun sich nicht, das ist schlicht und einfach falsch.
P. M. schrieb: > Dass man beim Programmieren > den Überblick verliert, ist nicht etwa ein blöder Unfall, sondern völlig > zwangsläufig Was nun aber nicht bedeutet, daß man dies mit einem gut gegliederten funktionellen System und guter Doku nicht beeinflussen könnte. > Der Flaschenhals liegt beim Überblick > (und damit > Wartbarkeit, Korrektheit, Sicherheit, Erweiterbarkeit, ...) Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10K. Das sagt ein durchschnittlicher Asm-Programmierer. > Du optimierst schlicht am > falschen Ort für 99.9% der praktischen Projekte, kleinste > Mikrocontrollerprojekte eingeschlossen. Nö. Ich optimiere Baugröße, Erweiterbarkeitsreserven und (weniger bedeutsam) die Hardwarekosten. Hinzu kommt die generell einfachere Softwareerstellung, angefangen mit den einfacheren Code- und Programmiermitteln, weniger Schreibaufwand und Verzicht auf suboptimale / fürs Ergebnis überflüssige C-Sprachkonstruktionen. > Und ich möchte dich ja mal sehen, einen Code für eine GPU oder einen > modernen Mehrkern-Prozessor in Assembler effizienter hinzukriegen Da kann ich Dich wieder beruhigen, davon war niemals die Rede (was nicht heißt daß es für Spezialzwecke nicht möglich wäre).
:
Bearbeitet durch User
Moby A. schrieb: > Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10k Die wir sicher gleich zu sehen kriegen. Am Ende stimmt das gar nicht ;-)
P. M. schrieb: > was du nicht kapierst ist, daß Du mit mir einen ASMler vor Dir hast der das nicht erst seit gestern macht und (wenn auch nur für eigene Zwecke) mehr als genug Projekte erfolgreich zu Ende gebracht hat. Was Du schließlich ignorierst sind auch die Massen an Asm-Code, die für AVR (z.B. hier in den Projekten) erstellt wurden. Warum wohl? Alles Umherirrende, die nur nicht Deine Logik kapieren? Es dürfte eher daran liegen, daß bei Dir, sagen wir es freundlich, die Assembler-Erfahrung noch ausbaufähig ist ;-)
:
Bearbeitet durch User
Moby A. schrieb: > ist, daß Du mit mir einen ASMler vor Dir hast der das nicht erst seit > gestern macht und (wenn auch nur für eigene Zwecke) mehr als genug > Projekte erfolgreich zu Ende gebracht hat. Als Biebelforscher mit dem ASM-Turm auf dem Markplatz...
Moby A. schrieb: > Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10K. Das > sagt ein durchschnittlicher Asm-Programmierer. Ok. Dann übersetze doch bitte mal die folgende C++-Funktion in Assembler, sagen wir für uint8_t und uint16_t und erkläre mit, wie die übersichtlicher und effizienter sein soll als in C:
1 | template <class T> |
2 | T max(T a, T b){ |
3 | return (a > b) ? a : b; |
4 | }
|
Uhu U. schrieb: > Als Biebelforscher mit dem ASM-Turm auf dem Markplatz... Ja ja ich weiß, für die Big Player hier mit der dicken C-Biiiiebel bleibt das schwer erträglich ;-) Da bleiben nur solche Argumente.
Moby A. schrieb: > Hinzu kommt die generell einfachere Softwareerstellung, angefangen mit > den einfacheren Code- und Programmiermitteln, weniger Schreibaufwand und > Verzicht auf suboptimale / fürs Ergebnis überflüssige > C-Sprachkonstruktionen. Das ist Satire.
P. M. schrieb: > C:template <class T> > T max(T a, T b){ > return (a > b) ? a : b; > } Was soll daran übersichtlich sein? Das ist kryptischer Kauderwelsch für Eingeweihte. Dessen Studium ist für 8-Bit MSR überflüssig ;-)
Moby A. schrieb: > Rufus Τ. F. schrieb: >> Das ist Satire. > > Das ist Tatsache. Dass es Satire ist? Ja, das ist eine Tatsache. Endlich siehst du das ein. mfg.
Also übersichtlicher als so geht's doch kaum:
1⌈2
2
2⌈1
2
⌈/1 2 3 4 5 3 8 1 3
8
:
Bearbeitet durch User
> Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10k
hmm - die µCs bei mir in der Bastelkiste fangen erst bei 128K an und
hören bei 1M auf (hab nur noch 32bit).
Die kleinen 128er nutze ich für kleinere Bastelsachen (bis runter zum
Lauflicht - ich habe damit aber auch schon einen Quadrokopter mit
kleinem Echtzeitbetriebssystem gebaut). Die kosten so wenig, dass es mir
egal ist, ob ich nur 3K davon benutze - spielt überhaupt keine Rolle.
die "großen" µC mit 1M Flash nutze ich wenn Grafikdisplays angesteuert
werden müssen. Einmal brauchte ich auch eine Soundausgabe und habe die
Sounddaten einfach im Flash abgelegt.
Einzig bei batteriebetriebenen Anwendungen wo es auf jedes µA ankommt,
könnte ich mir vorstellen einen kleinen 16bit msp430 zu nehmen, aber so
eine Anwendung hatte ich bislang noch nicht.
Für 8bit µCs (geschweige denn für ASM) sehe ich bei mir keinerlei
Verwendung mehr. Ich kann mir gut vorstellen, dass vor 20 oder 30 Jahren
die µCs mit viel Ressourcen noch sehr teuer waren. Da hat es sich
bestimmt gelohnt ASM zu nutzen. Das war aber lange vor meiner Zeit. In
meiner Azubizeit bin ich mal mit Embedded-Entwicklern in Kontakt
gekommen (das war so 1999 rum). Von denen hat niemand mehr ASM benutzt.
Die konnten es aber (das waren richtige Profis). Die Aussage war damals:
ASM nur im Notfall nutzen, wenn Handoptimierung notwendig ist. Komplette
Projekte in ASM hätten auf längere Sicht die Portierbarkeit zunichte
gemacht und für die Firma großen finanziellen Schaden bedeutet.
Wenn ich solche komplexen Darstellungsformen von Code sehe bin ich mit Asm immer heilfroh, einfachere Ausdrucksformen verwenden zu können. Z.B. ohne künstliche Kreationen wie Datentypen und dem noch unnützeren Konzept der Typumwandlungen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Da bleiben nur solche Argumente. Für deine Mini-Basteleien mag ASM ja ausreichen, aber für ernsthafte Projekte, die einen größeren Umfang haben und nicht nur Spielerei sind, geht das einfach nicht. Natürlich konnten auch die Menschen in der Altsteinzeit leben - fragt sich nur, warum wir nicht dabei geblieben sind, sondern auf Teufel-komm-raus Computer entwickeln mussten. Die Probleme, die unsere Vorfahren vor 2,5 Millionen Jahren hatten, waren nicht so komplex, dass sie hoch entwickelte Steinwerkzeuge dieser Qualität: http://www.chemieunterricht.de/dc2/pyrit/steinwerkzeug.htm gebraucht hätten - trotzdem hätten sie sie sofort genommen, wenn sie ihnen jemand angeboten hätte. Wenn man die Technikgeschichte von den ersten Anfängen an Revue passieren läßt, sieht man tausendfach Schritte der Qualität "vom Assembler zum C-Compiler" und einen bestimmten Schritt dieser Art zum allein seligmachenden zu erklären, ist genau so lächerlich, wie eine Kameltreiber- oder Schafhirtenreligion im 21. Jahrhundert. Du darfst gerne an sowas glauben, kannst aber nicht erwarten, dass dir zugejubelt wird.
Moby A. schrieb: > Das ist kryptischer Kauderwelsch für Eingeweihte. Wieso? Das ist ganz normales C. Wo bleibt überhaupt die C-Version von deinem "Projekt"? mfg.
Gebt's einfach auf. Der versteht überhaupt nicht was ihr ihm sagen wollt. Insofern ist er in seiner kleinen AVR assembler Welt happy. Lassen wir's dabei bleiben.
Gu. F. schrieb: > Gebt's einfach auf. Man muss das Unmögliche versuchen, um das Mögliche zu erreichen.
Thomas E. schrieb: > Wieso? Das ist ganz normales C. Das ist es nun nicht. Das ist C++; C kennt keine Templates. Moby A. schrieb: > bin ich mit Asm immer heilfroh, einfachere Ausdrucksformen verwenden zu > können. Z.B. ohne künstliche Kreationen wie Datentypen Natürlich. Genau. "Datentypen". Braucht man nicht. Was man nicht mit Werten im Zahlenraum zwischen 0 und 255 ausdrücken kann, ist es nicht wert, gesagt zu werden.
Rufus Τ. F. schrieb: > Natürlich. Genau. "Datentypen". Braucht man nicht. Was man nicht mit > Werten im Zahlenraum zwischen 0 und 255 ausdrücken kann, ist es nicht > wert, gesagt zu werden. Warum so viel? Unsereins kriegte es an der Uni mit einem Assembler zu tun, von dessen zu Grunde liegender Maschine man nicht wusste, ob dessen Byte 0..63 oder 0..99 codiert. Ein Wort hatte 5 solcher Bytes plus Vorzeichen. Alles, was es Wert ist geschrieben zu werden, kann auch in einem Zeichensatz mit 64 Codes ausgedrückt werden.
:
Bearbeitet durch User
Gu. F. schrieb: > Moby A. schrieb: >> Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10k > > Die wir sicher gleich zu sehen kriegen. Da man für das bloße Hin- und Herschieben von Daten¹ zwischen den einzelnen Schnittstellen des µC nie und nimmer 10k Programmcode braucht, würden wir bei der Veröffentlichung von Mobbys 10k-Programm enttäuscht feststellen, dass der größte Teil dieser 10k einfach nur fixe Daten sind, bspw. Textstrings, Fonts oder Grafiken für die Benutzerinteraktion über ein LCD. Damit kann man auch locker ein paar MB voll bekommen, ohne dass die Übersicht darunter leidet. Insofern würde Mobys 10k-Code keine neuen Erkenntnisse vermitteln, so dass er ihn auch gleich für sich behalten kann. ——————————— ¹) Alles andere wäre ja keine typische 8-Bit-Anwendung mehr.
Jonny O. schrieb: > hmm - die µCs bei mir in der Bastelkiste fangen erst bei 128K an und > hören bei 1M auf (hab nur noch 32bit) Wenn Deine Projekte diese Größen rechtfertigen dann sollen sie das. Ich vermute aber eher daß Du programmsprachbedingt eher zu den Leuten gehörst die in 5 Jahren auf 64 Bit mit 1-10M Speicher umsteigen müssen ;-) Für einen Quadrokopter mag die Dimensionierung ja stimmen- da würde ich es als Bastler aber vorziehen eines der zahlreichen Modelle zu kaufen. Den Sinn des Selbstbaus mag ich da schlecht erkennen. Grafik-LCD Ansteuerung ist auch eines der wahrscheinlichen Ausschlußkriterien für 8-Bit, da brauchts dann eben massig Speicher. > Komplette > Projekte in ASM hätten auf längere Sicht die Portierbarkeit zunichte > gemacht und für die Firma großen finanziellen Schaden bedeutet. Das kann ich für eine Firma und große Projekte nachvollziehen. Für 8-Bit MSR /IOT langt AVR/ASM auf ewig. Da ist noch zuviel Luft drin ;-)
Zeig. Ein. Beispiel. Nein, Deine berühmten 20 Zeilen genügen nicht. Zeig ein vollständiges Beispiel. Oh, und lass' das "IoT" weg. Das ist, so wie Du es gebrauchst, unwahr.
Uhu U. schrieb: > Natürlich konnten auch die Menschen in der Altsteinzeit leben Natürlich kann man 8-Bit MSR in Asm machen. Der Witz ist: Es ist einfacher und effizienter. Dafür sind auch keine Zujubler nötig, wenn man die einfache, funktionsfähige, nicht größer als nötige Lösung längst in der Hand hält ;-) Thomas E. schrieb: > Wo bleibt überhaupt die C-Version von deinem "Projekt"? Die Frage stelle ich mir auch. Wo das doch alles so modern und hochproduktiv sein soll... A. K. schrieb: > Man muss das Unmögliche versuchen, um das Mögliche zu erreichen Versuch lieber Dein Möglichstes, das scheinbar Unmögliche (ASM ist manchmal einfach besser) zu begreifen ;-) Rufus Τ. F. schrieb: > Was man nicht mit > Werten im Zahlenraum zwischen 0 und 255 ausdrücken kann, ... macht man in zwei oder drei oder vier! Yalu X. schrieb: > Da man für das bloße Hin- und Herschieben von Daten¹ zwischen den > einzelnen Schnittstellen des µC nie und nimmer 10k Programmcode braucht, > würden wir bei der Veröffentlichung von Mobbys 10k-Programm enttäuscht > feststellen, dass der größte Teil dieser 10k einfach nur fixe Daten > sind, bspw. Textstrings, Fonts oder Grafiken für die Benutzerinteraktion > über ein LCD. Damit kann man auch locker ein paar MB voll bekommen, ohne > dass die Übersicht darunter leidet. Da irrst Du Dich aber gewaltig. So ein Netzwerk vieler Sensoren und Aktoren kann mit Protokollverarbeitung und IfThen Logik ganz schön komplex werden, insbesondere wenn die Absichten von Menschen im SmartHome zu ergründen sind! Was die Texte angeht ist das für ein kleines 2x16 Display und eine auszuliefernde HTML-Seite dagegen nicht der Rede wert.
@Uhu Uhuhu (uhu) >> ist, daß Du mit mir einen ASMler vor Dir hast der das nicht erst seit >> gestern macht und (wenn auch nur für eigene Zwecke) mehr als genug >> Projekte erfolgreich zu Ende gebracht hat. >Als Biebelforscher mit dem ASM-Turm auf dem Markplatz... YMMD! Fällt diese ASM-Diskussion nicht mittlerweile unter das Poliktverbot? Ist das nicht sogar ein moderne Form des Cyber-Terrorismus? 8-0
Rufus Τ. F. schrieb: > Nein, Deine berühmten 20 Zeilen genügen nicht. Zeig ein vollständiges > Beispiel. Das Beitrag "Kleines Tiny13 Sensorboard" ist ein vollständiges Beispiel. Das genügt vollauf.
Moby A. schrieb: > Der Witz ist: Es ist einfacher und effizienter. So nach dem Motto: beide Flügel sind gleich lang, besonders der linke? Ja, es ist tatsächlich ein Witz, wenn man eine Sache mit nichts anderem vergleicht und dann zu dem Schluss kommt, sie sei einfacher und effizienter...
Falk B. schrieb: > Fällt diese ASM-Diskussion nicht mittlerweile unter das Poliktverbot? Damit kennst Du Dich ja jetzt aus, stimmts? Im Gegensatz zu Dir muß ich aber keinen Frust ablassen sondern amüsiere mich. Morgen kanns für mich weitergehen, schönen Abend noch ;-)
@ Moby AVR (moby-project) Benutzerseite >Beitrag "Kleines Tiny13 Sensorboard" >ist ein vollständiges Beispiel. Das genügt vollauf. Wie süß, wir stricken uns einen ADC selber ;-) Es beschreibt deinen Programmiererhorizont nur allzu gut. Viel Spaß noch beim Bastlen (als Brotwerwerb ist es für dich eher nicht geeignet)
@ Moby AVR (moby-project) Benutzerseite >> Fällt diese ASM-Diskussion nicht mittlerweile unter das Poliktverbot? >Damit kennst Du Dich ja jetzt aus, stimmts? Scheint so. >Im Gegensatz zu Dir muß ich aber keinen Frust ablassen sondern amüsiere >mich. Uns. ;-) >Morgen kanns für mich weitergehen, schönen Abend noch ;-) Und täglich grßt das Murmeltier . . . https://de.wikipedia.org/wiki/Und_t%C3%A4glich_gr%C3%BC%C3%9Ft_das_Murmeltier (Meine Herrn, was kennt Wikipedia eigentlich NICHT?)
Moby A. schrieb: > Beispiel. > > Das > Beitrag "Kleines Tiny13 Sensorboard" > > ist ein vollständiges Beispiel. Das genügt vollauf. Ohne Schaltplan... Und da laberst du von "Dokumentation"?
Was anderes in dem Zusammenhang: Moby, Du wolltest doch als Frontend für deine Hausautomatisierung von SerialComInstruments, was bei Dir ja funktioniert hat, nach LabView umschwenken. Beispielbild hattest Du hier gepostet: Beitrag "Re: Projekt: Virtuelle Instrumente an serielle Schnittstelle" Seit dem habe ich diesbezüglich von Dir dazu nichts mehr gehört. Ist Dir die Anbindung an LabView inzwischen mit ASM gelungen?
:
Bearbeitet durch User
Moby A. schrieb: > Da irrst Du Dich aber gewaltig. So ein Netzwerk vieler Sensoren und > Aktoren kann mit Protokollverarbeitung und IfThen Logik ganz schön > komplex werden, > insbesondere wenn die Absichten von Menschen im SmartHome zu ergründen > sind! Hmm, ist das alles? Und dafür brauchst du 10k? Da habe ich schon eine Hausautomatisierung gesehen, die tat mit deutlich weniger Code sehr viel mehr als nur einfache Protokolle und eine Latte von If-Abfragen abzuarbeiten. Da waren u.a. richtige Regelungstechnik und noch ein paar Dinge mehr enthalten, die aus deiner Sicht zwar keine typischen 8-Bit-Anwendungen sind, aber – oh Wunder – trotzdem auf einem 8-Bit-Controller liefen. Ok, das Ganze war nicht in Assembler, sondern in C programmiert, da hat es der Programmierer natürlich auch nicht ganz so schwer gehabt ;-)
> Ohne Schaltplan... Und da laberst du von "Dokumentation"? Projekte, die Schaltpläne besitzen, sind niemals typische 8-Bit MSR-Anwendungen. BTW, schon 1983 durfte ich zuschauen, wie zwei Ings eine 8-Bit-MSR-Anwendung in Hochsprache gebaut haben. Die mußten dafür sorgen, daß die 4 Farbenwerke einer x-hundert-Tonnen Druckmaschine übereinander passen. Auf die Idee, das in ASM zu machen wären die nie gekommen. Hatte doch der PLM80 Compiler diese wohldurchdachten ASM-Bausteine im Bauch, die er präzise anordnete um auch mal eine 16-Bit-Intergerzahl auszurechnen. > Gebt's einfach auf. > Der versteht überhaupt nicht was ihr ihm sagen wollt. Insofern ist er > in seiner kleinen AVR assembler Welt happy. > Lassen wir's dabei bleiben. Ich werde mich an Jörg W's Rat halten und einfach jedesmal, wenn er mal wieder Dinge, die er nicht versteht, niedermachen will die "Beitrag melden"-Taste drücken. Es nervt einfach, wenn eine Diskussion über die Abbildung von GPIO's in C++ nur noch der It-Neandertaler zu Wort kommt, weil er das für sein Fachgebiet hält.
Carl D. schrieb: > Ich werde mich an Jörg W's Rat halten und einfach jedesmal, wenn er mal > wieder Dinge, die er nicht versteht, niedermachen will die "Beitrag > melden"-Taste drücken. Es nervt einfach, wenn eine Diskussion über die > Abbildung von GPIO's in C++ nur noch der It-Neandertaler zu Wort kommt, > weil er das für sein Fachgebiet hält. Ich kann mir nicht vorstellen dass du das auf Dauer durchstehst. So eine Hartnäckigkeit kenne ich bisher nur von K.B.
> Ich kann mir nicht vorstellen dass du das auf Dauer durchstehst. > So eine Hartnäckigkeit kenne ich bisher nur von K.B. Man darf sich auch schwer erreichbare Ziele setzen ;-)
Moby A. schrieb: > Jonny O. schrieb: >> hmm - die µCs bei mir in der Bastelkiste fangen erst bei 128K an und >> hören bei 1M auf (hab nur noch 32bit) > > Wenn Deine Projekte diese Größen rechtfertigen dann sollen sie das. > Ich vermute aber eher daß Du programmsprachbedingt eher zu den Leuten > gehörst die in 5 Jahren auf 64 Bit mit 1-10M Speicher umsteigen müssen > ;-) > Für einen Quadrokopter mag die Dimensionierung ja stimmen- da würde ich > es als Bastler aber vorziehen eines der zahlreichen Modelle zu kaufen. > Den Sinn des Selbstbaus mag ich da schlecht erkennen. Grafik-LCD > Ansteuerung ist auch eines der wahrscheinlichen Ausschlußkriterien für > 8-Bit, da brauchts dann eben massig Speicher. > >> Komplette >> Projekte in ASM hätten auf längere Sicht die Portierbarkeit zunichte >> gemacht und für die Firma großen finanziellen Schaden bedeutet. > > Das kann ich für eine Firma und große Projekte nachvollziehen. Für 8-Bit > MSR /IOT langt AVR/ASM auf ewig. Da ist noch zuviel Luft drin ;-) Ich finde es auch absolut okay, wenn man im Hobby gerne und viel ASM benutzt. Ich finde es (hab ich glaube ich schonmal erwähnt) auch toll wenn man sich so gut mit der Architektur eines µCs auskennt und ao hardwarenah programmieren kann. Mach das ruhig weiter so Moby und lass dich da nicht verunsichern. Schlussendlich ist doch das Wichtigste, dass man Spaß am Hobby hat. Klar - du provozierst natürlich auch gerne - Hand aufs Herz ;-) Aber ich habe das Gefühl, dass sich die Leute auch gerne provozieren lassen. Naja nur meine 2 Cents ;)
Moby A. schrieb: > Natürlich kann man 8-Bit MSR in Asm machen. Für sehr einfache Anwendungen kann man das, für kompliziertere nicht. > Der Witz ist: Es ist einfacher und effizienter. Nein, ist es nicht. Assembler ist unlesbar, chaotisch und kryptisch, schon die Atmel-Variante hat über 130 Instruktionen. Die Hochsprachen sind dank Strukturierung und viel weniger Befehlen einfacher, übersichtlicher, klarer, leichter zu erlernen und einfacher zu benutzen. Hochsprachen sparen dadurch die wichtigste und kostbarste Ressource von allen ein: die Lebenszeit der Entwickler. Die ist so wichtig und kostbar, weil sie einerseits endlich ist und andererseits, anders als Hardware-Ressourcen, nicht für Geld zugekauft werden kann. Assembler zu benutzen, wo man auch ebensogut eine Hochsprache einsetzen könnte, ist nurmehr eine anachronistische und dumme Verschwendung der kostbarsten aller Ressourcen.
@Jonny O.: Niemand spricht Moby das Recht ab, seine Zeit mit was aus immer zuzubringen. Solange er anderen das auch zugesteht. Wie gut er das kann sieht man hier: Beitrag "C++ für Mikrocontroller" Es ging nicht um "ist C++ besser als ...", sondern um Fragen innerhalb der C++-Welt. Da braucht es keine "ASM ist besser"-Diskussion. Anderst hier: Die Überschrift lautet "ASM über alles", dann muß auch genau darüber diskutieret werden dürfen.
> Assembler zu > benutzen, wo man auch ebensogut eine Hochsprache einsetzen könnte, ist > nurmehr eine anachronistische und dumme Verschwendung der kostbarsten > aller Ressourcen. So wie ich Moby verstanden habe, macht er das aber als Hobby. Wenn es ihm Spaß macht mit ASM zu programmieren ist das doch okay. Es gibt doch viel verrücktere Hobbys. Manche Leute bauen sich aus TTL-Gattern ganze Computer zusammen. Im Prinzip total irre, aber wenns Spaß macht? Lebenszeit ist nur dann verschwendet, wenn wir sie ohne Freude verbringen. Ich dachte mir mal, weil doch bald Weihnachten ist, kann man mal so einen besinnlichen Spruch raus hauen. ;-D
Carl D. schrieb: > @Jonny O.: > Niemand spricht Moby das Recht ab, seine Zeit mit was aus immer > zuzubringen. Solange er anderen das auch zugesteht. Wie gut er das kann > sieht man hier: > > Beitrag "C++ für Mikrocontroller" > > Es ging nicht um "ist C++ besser als ...", sondern um Fragen innerhalb > der C++-Welt. Da braucht es keine "ASM ist besser"-Diskussion. > Anderst hier: Die Überschrift lautet "ASM über alles", dann muß auch > genau darüber diskutieret werden dürfen. Hi Carl, Wie gesagt: Moby provoziert - und das weiß er auch. Allerdings könnte man ihn auch ignorieren, wenn man nicht drauf anspringen will. Er hindert ja niemanden daran c zu benutzen.
Moby A. schrieb: > IfThen Logik ganz schön komplex werden, Seit wann kann der AVR-Assembler IfThen zur Laufzeit?
> Manche Leute bauen sich aus TTL-Gattern ganze Computer zusammen. Wenn die dann aber in jedem Thread über "Single-Chip-Microcontroller" erklären wollen, daß ihre TTL-Lösung besser ist und nur "immer besser sein kann", dann ist Schluß mit lustig. Du solltest dich mal mit dem Phänomen "Moby" beschäftigen, das ist nicht der "kleine Dicke, der von allen gehänselt wird", den er gerne mal gibt. > Er hindert ja niemanden daran c zu benutzen. Stimmt, nur unterhalten darf man sich darüber nicht, ohne sein Dazwischengeschreie ertragen zu müssen.
:
Bearbeitet durch User
Carl D. schrieb: > daß ihre TTL-Lösung besser ist und nur "immer besser sein kann", dann ist > Schluß mit lustig. Nee, erst dann wirds erst richtig lustig.
Uhu U. schrieb: > Nee, erst dann wirds erst richtig lustig. ... aber nur für Masochisten umd Mobys ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Was soll daran übersichtlich sein? > Das ist kryptischer Kauderwelsch für Eingeweihte. > Dessen Studium ist für 8-Bit MSR überflüssig ;-) Dann zeig doch mal, wie eifach es in Assembler gehen würde! Eine universell brauchbare Maximum-Funktion kann auch sehr gut bei 8-Bit-MSR auftreten. Ich warte auf eine Antwort oder sehe es als definitives Eingeständnis, dass du nicht nur auf dem Holzweg bist, sondern noch nicht mal rudimentär gültige Argumente vorbringen kannst.
Jonny O. schrieb: >> Assembler zu benutzen, wo man auch ebensogut eine Hochsprache einsetzen >> könnte, ist nurmehr eine anachronistische und dumme Verschwendung der >> kostbarsten aller Ressourcen. > > So wie ich Moby verstanden habe, macht er das aber als Hobby. Wenn es > ihm Spaß macht mit ASM zu programmieren ist das doch okay. Es gibt doch > viel verrücktere Hobbys. Natürlich. Der eine programmiert gerne in Assembler, ein anderer träufelt sich heißes Wachs auf die Geschlechtsteile. Damit habe ich überhaupt kein Problem, solange sie mich damit in Ruhe lassen. ;-)
Jonny O. schrieb: > Wie gesagt: Moby provoziert - und das weiß er auch. Allerdings könnte > man ihn auch ignorieren, wenn man nicht drauf anspringen will. Er > hindert ja niemanden daran c zu benutzen. Er zerstört Threads zu anderen Programmiersprachen mit seinem penetranten, provozierenden und beleidigenden Missionieren. Insofern hindert er streng genommen zwar niemanden C zu benutzen, aber er hindert andere daran, sich ungestört darüber auszutauschen.
Sheeva P. schrieb: > aber er hindert andere daran, sich ungestört darüber auszutauschen. Nochmal: in solchen Fällen, bitte „Beitrag melden“.
Sheeva P. schrieb: > Er zerstört Threads zu anderen Programmiersprachen So in der Art wie dieser (sein) Tread zerstört wird ? > penetranten, Ja > provozierenden Ja > und beleidigenden Er wird erheblich heftiger attackiert > Missionieren. Ja Es ist kein Geheimniss das man statt mit Moby auch mit einer Parkuhr über den ASM -> 'alle anderen Sprachen' Konflikt diskutieren könnte. Selbst Moby macht kein Geheimniss aus seiner Tiny + ASM Fixierung. Während Moby Gebetsmühlenartig die immer gleichen (nicht)Argumente bringt und auch überhaupt nicht vorhat sich davon abbringen zu lassen wird es auf der 'Gegenseite' immer verbissener. Ich bin überaupt nicht seiner Meinung, aber von seiner Fähigkeit selbst absolute Tiefschläge mit Herablassung statt Blutspuckend zu beantworten könnten sich hier manche eine Scheibe abschneiden. Was erwartet Ihr ? Es wird einfach nicht passieren das sich am Ende aller Diskussionen ein geläuterer Moby in seinen 'Kerninghan / Ritchie' vertief. Spult Euch gerne weiter auf, werdet beleidigend, zerreist alles was Mob hier ins Netz stellt aber es ist nicht Moby der sich damit lächerlich macht.
Moby A. schrieb: > Für jeden Zweck die richtigen Mittel. > Die AVR-Reihe bis hoch zum XMega stemmt einen Großteil typischer 8-Bit > MSR Apps, wobei die Verwendung von Asm den Einsatzhorizont noch einmal > ordentlich ausdehnt. Was ist daran nur so schwer zu verstehen? Ganz einfach: Du hast eine merkwürdige Auffassung von "typischen 8-Bit-Anwendungen". 99,9% der Entwickler sind da anderer Ansicht als Du. Wenn diese einen ATmega328 nehmen, dann nehmen sie ihn, um ihn auch auszunutzen. Denn sonst würden sie ja einen ATmega168. Während Du nur 0,1% eines ATmegas produktiv nutzen kannst, packen da andere Leute Anwendungen rein, von denen Du nur zu träumen wagst. Das sind typische 8-Bit-Anwendungen! Deine 23-Zeilen-Assembler-Programme sind einfach nur Verschwendung und lassen den Großteil der AVR-HW einfach brachliegen. Du bist also kein Sparfuchs, sondern eher ein Verschwender sondergleichen.
Frank M. schrieb: > Während Du nur 0,1% eines ATmegas produktiv nutzen kannst Ähm, war es nicht Moby der hier in der Kritik steht provozierende und unbewiesene Nichtargumente zu bringen ? Ich denke es steht ausser Frage das der ideale ASM Code eine MCU immer besser ausnutzt als der ideale C Code. Der Punkt über den hier m.E. überwiegend Einigkeit herrscht ist der, das ASM ab einer gewissen Größe von Menschen nicht mehr annähernd ideal zu schreiben ist und ein C Compiler da bessere und schnellere Arbeit abliefert. Ich kann mich noch gut an Zeiten erinnern in denen es oft keinen Weg an ASM vorbei gab weil Compiler und MCUs arg beschränkt waren. ASM hat bis heute seine Daseinsberechtigung. Sicher nicht in der Form wie Moby das propagiert, aber bis heute muß ich teilweise in den ASM Code schauen weil Compiler durchaus manchmal Fehler machen (sehr selten) die im Quellcode nicht zu erkennen sind. Gerade die 'optimierungen' mancher Compiler können einem echt die Karten legen. Z.B. beim Xmega den Takt umschalten geht in GCC je nach Optimierungsstufe mal und mal nicht. Grund ist das zwischen dem freischalten und beschreiben der Taktquellenregister nur x (?) Zyklen vergehen dürfen. Das scheint GCC nicht zu wissen und nicht zu berücksichtigen. Baue ich nicht vorhandenen Hardware in Code nach und brauche Taktgenaues Timing führt auch nichts an ASM vorbei. Ein Umstand der übrigens häufig durch brutal hohe Takte und fette Controller für kleine Aufgabe überdeckt wird. Die sind dann trotz verschwenderischer Programmierung immer noch schnell genug. Ein Punkt um den es Moby übrigens häufg geht und wo er nicht komplett unrecht hat. Man kann also sagen das man ASM Grundlagen beherrschen sollte auch wenn man C schreibt. Als ASM Coder braucht man aber nicht zwangsläufig C Kenntnisse. Mist, jetzt hör ich mich schon an wie Mobys Wassertträger ...
Michael K. schrieb: > Sheeva P. schrieb: >> Er zerstört Threads zu anderen Programmiersprachen > So in der Art wie dieser (sein) Tread zerstört wird ? Wenn ich das richtig sehe, haben anfangs mehrere Leute versucht, sachlich über sein Thema zu diskutieren. Daß der Thread trotzdem abgeglitten ist, liegt vor allem an Mobys vorangegangenen Provokationen, Beleidigungen und penetranten Missionierungen -- zumal das Thema des Threads nichts anderes als die Fortführung der Missionierung mit anderen Mitteln ist. >> und beleidigenden > Er wird erheblich heftiger attackiert Mag sein, aber zuerst gingen die Attacken vom ihm aus -- und schon unsere Mütter haben gewußt: wie man in den Wald hineinruft, so schallt es wieder heraus. Das ist schade, aber menschlich. ;-) Andererseits verstehe ich die Verbissenheit mancher Diskutanten nicht. Solange das Thema aber auf Assembler-Threads beschränkt bleibt, ist es doch ausgesprochen unterhaltsam. > Es ist kein Geheimniss das man statt mit Moby auch mit einer Parkuhr > über den ASM -> 'alle anderen Sprachen' Konflikt diskutieren könnte. > Selbst Moby macht kein Geheimniss aus seiner Tiny + ASM Fixierung. Hm... er bestreitet, daß es sich um eine Fixierung handelt, und behauptet stattdessen, der Rest der Welt sei aus Gründen der Angeberei und bewußten Ressourcenverschwendung auf Hochsprachen fixiert... > Spult Euch gerne weiter auf, werdet beleidigend, zerreist alles was Mob > hier ins Netz stellt aber es ist nicht Moby der sich damit lächerlich > macht. Das stimmt. Moby macht sich hingegen mit seiner totalen Unzugänglichkeit für rationale Argumene lächerlich, insofern besteht Gleichstand. ;-)
Michael K. schrieb: > Ich denke es steht ausser Frage das der ideale ASM Code eine MCU immer > besser ausnutzt als der ideale C Code. Das wird diesseits bestritten. Idealer Code ist immer derselbe, egal womit er ursprünglich entwickelt worden ist. Ein perfekter Compiler würde daher exakt denselben, eben perfekten Code erzeugen, wie der perfekte Assembler-Programmierer, nämlich den einen, perfekten Code. Wobei auch dabei ja noch immer die Frage bestehen bleibt, nach welchen Kriterien ein Code denn als ideal gälte. Schließlich folgt so ein Code mehreren, zum Teil konkurrierenden Zielen. Also was ist idealer Code? Bei minimierter Laufzeit? Minimiertem Flash- oder RAM-Verbrauch? Minimiertem Arbeitsaufwand des Entwicklers? Welche Rolle spielen Pfleg-, Wart- und Erweiterbarkeit, wie steht es um die Funktionalität? Gibt es da objektive, allgemein akzeptierte und einwandfrei meßbare Kriterien? Insofern ist die angebliche Ressourcenverschwendung durch Hochsprachen, die Moby hier so gerne behauptet, letztlich nur eine Kritik an den Optimierern real existierender Compiler. Wobei zu deren Ehrenrettung gesagt werden muß, daß die meisten Compiler nicht für winzigkleine Mikrocontrolleranwendungen, sondern für größere Umgebungen und Programme optimieren.
Sheeva P. schrieb: > er bestreitet, daß es sich um eine Fixierung handelt Ja, das behaupten immer alle von sich selbst. Verbohrt und verblendet sind immer nur die anderen. Ich habe mich selber schon recht eindeutig über Mobys innere Haltung geäussert. Tatsächlich gab es in Diskussionen Momente in denen er Argumenten zugänglich war und man klar erkennen konnte das er kein Idiot ist. Auf jede Form von Druck oder negativer Haltung schaltet der nur einfach ins 'Notlaufprogramm' und läßt alles abtropfen was ihm nicht genehm ist. Ich finde es einfach faszinierend das sobald Kommunikation in Schriftform stattfindet, die Diskutanten sich einen Dreck darum scheren wie der Mensch gestrickt ist der da auf der anderen Seite sitzt. Plötzlich zählt nur noch die eigene Wahrnehmung und die wird jedem um die Ohren gehauen ohne sich darum zu kümmern ob dieser Weg zu irgendeiner Verständigung führt. Ich finde Moby ist so eine art Institution hier. Man kann sich über ihn aufregen, muß es aber nicht. Die Reaktionen die er provoziert zeigen aber auch wie es mit der Offenheit gegenüber anderen Sichtweisen und der Fähigkeit sich in andere reinzuversetzen bei seinen Kontrahenten ausschaut. Mir würde etwas fehlen in diesem Forum wenn Moby plötzlich die Dinge so sehen würde wie alle anderen. Da gibt es ganz andere und ganz andere Sichtweisen die mit die Galle hochkochen lassen. Programmiersprachen lösen im allgemeinen nicht solche Emotionen in mir aus.
Sheeva P. schrieb: > Wobei zu deren Ehrenrettung > gesagt werden muß, daß die meisten Compiler nicht für winzigkleine > Mikrocontrolleranwendungen, sondern für größere Umgebungen und Programme > optimieren. Autsch. Soll heissen das C Compiler für MCU nicht geeignet sind weil die nur für größere Systeme optimieren können ? (binäre Sichtweise) Das wird Moby gerne hören ;-)
Michael K. schrieb: > Soll heissen das C Compiler für MCU nicht geeignet sind weil die nur für > größere Systeme optimieren können ? (binäre Sichtweise) > Das wird Moby gerne hören ;-) Auf einem sehr kleinen uC kann der Mensch vielleicht mit Kreativität noch etwas mehr herausholen als ein Compiler, der seine Stärken dann ausspielen kann, wenn der Mensch die ganzen Graphen an Abhängigkeiten nicht mehr überblicken kann. Ich denke, da sind wir mit Moby einigermassen einverstanden. Der Punkt der Diskussion ist eigentlich, dass Moby behauptet, seine Ansichten würden auch für grosse Programme gelten. Immer mit der selben Dikussionsmechanik: Moby: "Gilt prinzipiell auch für grosse Programme." Benutzer: "Ok, dann zeig doch mal für Fall X." Moby: "Das ist für mich aber nicht typisch 8-Bit." Benutzer: "Ah, dann sind wir uns ja einig, für sehr kleine Dinge mögen deine Ansichten ok sein." Moby: "Gilt prinzipiell auch für grosse Programme." Benutzer: "Ok, dann zeig doch mal..." usw.
Sheeva P. schrieb: > Das wird diesseits bestritten. Idealer Code ist immer derselbe, egal > womit er ursprünglich entwickelt worden ist. Auch bei idealem Code kann es verschiedene Möglichkeiten geben.
Michael K. schrieb: > das > ASM ab einer gewissen Größe von Menschen nicht mehr annähernd ideal zu > schreiben Für mich persönlich ist die Größe bereits da erreicht, wo ich in C mit einfachen Vergleichsoperatoren arbeiten kann. Eine Zeile wie
1 | if(val1 > val2){... |
wird vom XC8 immer richtig ins Maschinencode übersetzt und zwar egal ob die Werte 8bit, 16bit oder 24bit floats sind. Früher habe ich PICs oft in Assembler programmiert. Was habe ich geflucht und Zeit verloren, weil ich an solchen Stellen viele Fehler bei der Auswertung des Carry-Flag gemacht habe. Es entspricht einfach nicht meiner Denke. Wenn ich den ASM Code in Prosa so kommentieren muss, dass die Programmstruktur für mich später erkenntlich ist dann schreibe ich es lieber gleich in C. Das Ergebnis wird dadurch nicht größer, oft ist das Gegenteil der Fall. In C kann ich bei geschachtelten Vergleichen schneller erkennen, ob sich etwas zusammenfassen und verkürzen lässt. Oft fasst der Compiler C-Code skrupellos zu einem ASM Code zusammen, vor dem es mich grausen würde. Beispiel: Test mehrerer auf unterschiedlichen Ports liegenden Signale auf High:
1 | if ((InSensor1 == 1) |
2 | && (InSensor2 == 1) |
3 | && (InSensor3 == 1) |
4 | && (InSensor4 == 1)) |
5 | {
|
würde ich in ASM mit 4 mal BTFSS GOTO schreiben und entspr. kommentieren. Das sind dann 8 Maschinenbefehle. Der Compiler (XC8 free) macht daraus
1 | 03B0 1A85 BTFSC PORTA, 0x5 |
2 | 03B1 1E05 BTFSS PORTA, 0x4 |
3 | 03B2 2BB8 GOTO 0x3B8 |
4 | 03B3 1A87 BTFSC PORTC, 0x5 |
5 | 03B4 1E07 BTFSS PORTC, 0x4 |
6 | 03B5 2BB8 GOTO 0x3B8 |
und gewinnt mit 6 Befehlen 25% Land. Natürlich könnte ich solche Tricks selbst in ASM nutzen und sie mit Prosa umschreiben. Aber dann schreibe ich lieber gleich in C die Programmstruktur lesbar hin und ausserdem ist mein Prosa später vielleicht für mich verständlich, für einen Aussensteheden meistens mindestens erklärungsbedürftig. Die C Syntax ist dagegen für alle verbindlich, C ist nun mal die Weltsprache der µC.
:
Bearbeitet durch User
Witkatz :. schrieb: > Was habe ich geflucht und Zeit verloren, weil > ich an solchen Stellen viele Fehler bei der Auswertung des Carry-Flag > gemacht habe. Es entspricht einfach nicht meiner Denke. Das könnte durchaus erklären, warum Moby so versessen auf sein Assembler ist: Es ist insofern einfacher, dass dort alles per Fleissarbeit zusammengestiefelt wird, dafür ist fast kein abstraktes Denken erforderlich. Man kann sich Schritt für Schritt vorstellen, was der Prozessor macht, wie bei einem Kind, das mit der Finger-Methode rechnet...
Michael K. schrieb: > Tatsächlich gab es in Diskussionen Momente in denen er > Argumenten zugänglich war und man klar erkennen konnte das er kein Idiot > ist. Stimmt. Allerdings ist er in so einer Situation wohl nur nicht in Form. Witkatz :. schrieb: > Oft fasst der Compiler C-Code skrupellos zu einem ASM Code zusammen, vor > dem es mich grausen würde. [...] Natürlich könnte ich solche Tricks > selbst in ASM nutzen und sie mit Prosa umschreiben. 'Skrupellos' ist gut! Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert eventuell komplett neuen Assembler-Code. In 'C' muss man vielleicht nur einen Datentyp ändern. Den Code lässt man machen.
Witkatz :. schrieb: > Für mich persönlich Du sagts es. Persönliche Wahrnehmung. Ich habe eine ganz ähnliche wie Du, Moby hat eine ganz andere wie wir. Da wirklich jede exotische MCU einen Assembler hat aber nur fast jede einen C Compiler (unbewiesene Behauptung) steht das 'Weltsprachenargument' auf tönernen Füssen. Solche Behauptungen stehen auf der gleichen Stufe wie das wofür Moby ans kreuz genagelt wird. Mir wollte vor Jahren ein Softwareinformatiker erzählen C sei Mausetot, jetzt wo es die erste MCU mit Java Interpreter gäbe. Das Argument 'gilt im Prinzip auch für ...' stimmt doch auch. Wenn jemand in der Lage wäre das Projekt noch zu überblicken, man modular genug schreiben würde das auch mehrere daran arbeiten könnten und es weder Zeit noch Kostendruck gäbe, dann würde auch ein großen Projekt von ASM only profitieren können. Es wäre nur zu definieren worin dieser Profit bestünde. Ich stamme aus der Generation C64 und kenne durchaus den Reiz auf unterster Ebene mit der Hardware zu kommunizieren und trickreiche Laufzeitenhacks zu ersinnen die auf die Art mit C nicht möglich sind. Dein 6 Befehl Beispiel liesse sich in dreien lösen wenn alles auf einem Port läge. Port laden, ver-unden, test auf null + sprung. Ich schätze die Bequemlichkeiten von C, aber trotzdem schüttel ich manchmal den Kopf wie wenig sich heute noch darum gekümmert wird was da eigentlich im Hintergrund abläuft. Was haben wir nicht alles mit realen 4Mhz (8031), 64B Ram und einem 8K Eprom gelöst. Was an Power fehlte wurde durch Gehirnschmalz ersetzt. Tabellen im Eprom statt Echzeitberechnungen, Zyklenoptimierte Berechnungsroutinen als Warteschleife statt hirnfreier delay_ms(100) Konstruktionen. Klar, sowas ist heute nicht mehr nötig, aber deswegen kann das immer noch Spaß machen. Dieses ganze Behauptungsgefussel wer wie blöd ist und wer den universellen Plan hat was geht können wir uns wirklich sparen.
P. M. schrieb: > Auf einem sehr kleinen uC kann der Mensch vielleicht mit Kreativität > noch etwas mehr herausholen als ein Compiler, der seine Stärken dann > ausspielen kann, wenn der Mensch die ganzen Graphen an Abhängigkeiten > nicht mehr überblicken kann. Das ist genau das Problem: Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, weil das Flash nur zum kleinen Teil ausgenutzt wird. Und bei großen Programmen optimiert der Compiler besser als der Mensch. Vor > 20 Jahren hätte ich Moby sogar Recht gegeben. Ich kann mich noch an den gruseligen Code erinnern, der aus einen 8051-C-Compiler kam, wenn man externes RAM angesprochen hatte. Aber das war auch eine Kiste, die nie für C-Compiler gebaut wurde. Beim ATmega sieht man dagegen, daß er bereits hochsprachenkomptibel entwickelt wurde. Da sehe ich mit ASM keinerlei Vorteile mehr. Gruß, Stefan
Ralf G. schrieb: > Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert > eventuell komplett neuen Assembler-Code. DAS ist z.B. eines der schlagkräftgsten Argumente für Hochsprache.
Michael K. schrieb: > Da wirklich jede exotische MCU einen Assembler hat aber nur fast jede > einen C Compiler (unbewiesene Behauptung) steht das > 'Weltsprachenargument' auf tönernen Füssen. Hat Kurts CPU einen C-Compiler? Wohl kaum...
Michael K. schrieb: > dreien lösen wenn alles auf einem > Port läge. Port laden, ver-unden, test auf null + sprung Dazu müsste aber ein Befehl existieren, der n Bits eines Registers verknüpfen kann. Sonst werden aus dem einen ver-unden viele einzelne Operationen. mfg.
Uhu U. schrieb: > Hat Kurts CPU einen C-Compiler? Wohl kaum... Du velwechserst da was. Die CPU ist von Josef. Kurt bewegt sich auf anderen Abgründen.
Michael K. schrieb: > Z.B. beim Xmega den Takt umschalten geht in GCC je nach > Optimierungsstufe mal und mal nicht. Grund ist das zwischen dem > freischalten und beschreiben der Taktquellenregister nur x (?) Zyklen > vergehen dürfen. > Das scheint GCC nicht zu wissen und nicht zu berücksichtigen. Für den GCC sind das Zuweisungen an volatile SPeicheradressen, mehr nicht. Wollte man das AVR-Backend des Compilers tatsächlich mit solchen HW-Spitzfindigkeiten bemühen, dann würde man dies als Intrinsic-Funktion anbieten, also Quasi Spezial-ASM-Code injizieren, oder, außerhalb des Compilers, in der RT-(Include-)Lib per Macro Inline-Assembler einfügen würde. Das ist nämlich einer der wenigen Fälle, wo jeder hier zustimmen würde, daß ASM die einzige Wahl ist: Wenn es um Takt-genaue Ausführung geht. (jetzt wird gleich wieder ein Kasper kommen, der sich hier einen Halbsatz rauspickt und laut "Ätsch-Bätsch" schreit)
Michael K. schrieb: > Was haben wir nicht alles mit realen 4Mhz (8031), 64B Ram und einem 8K > Eprom gelöst. Was an Power fehlte wurde durch Gehirnschmalz ersetzt. Genau das wird uns immer von Moby erzählt, aber auf Nachfrage mit nichts belegt. In diesem Thread wurde Moby gefühlte hundert mal nach Beispielen, Projekten und was weis ich noch alles gefragt. Ergebnis --> NULL! Vor diesem Hintergrund kann so ein Gehabe wie: Moby A. schrieb: > Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10K. Das > sagt ein durchschnittlicher Asm-Programmierer. kann einen schon mal leicht ankot*** Wenn ich dieses Projekt zu sehen bekäme (egal wie effizient oder auch nicht) wäre ich sofort still und der Moby hätte einen guten Teil Glaubwürdigkeit erlangt.
Stefan K. schrieb: > Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, > weil das Flash nur zum kleinen Teil ausgenutzt wird. > Und bei großen Programmen optimiert der Compiler besser als der Mensch. Händische Optimierungen sind bei weitem nicht immer Codegrößenoptimierungen. Unter ASM kann ich spezielle Teile auf den Takt genau optimieren. Unter C müsste ich mir erstmal einen Timer + IRQ schnappen um auf ein festes Timing zu kommen. Blöd nur wenn alleine die IRQ Bearbeitung mehr Zyklen kostet als ich zur Verfügung habe. Ja, 100Mhz + 32bit lösen auch dieses Problem... Ich habe mal Code überarbeiten müssen bei dem der Autor in C Konstruktionen gewählt hat die auf unglaublichen Umwegen zum Ziel geführt haben. Hätte der Compiler sinngemäß verstanden was da mal rauskommen soll, hätte der optimieren können, aber in dem Fall ergab das einfach ein Codemonster was die 8K Begrenzung gerissen hat. Der Keil Compiler fing an extrem uncoole moves zu machen als er an die Codegrenze kam. Da war vieles nicht nachvollziehbar weil der völlig aus dem Tritt kam. Erst massives Abspecken und SDCC haben es dann gebracht. Die Hardware war unveränderlich, weil bereits in größeren Stückzahlen gebaut und auslieferbereit. Es gab ein prinzipbedingtes Timingproblem das unter ganz speziellen Umständen auftrat und das produkt quasi unbenutzbar machte. In so einem Fall ist es gut ein bißchen 'Moby' zu sein.
Michael K. schrieb: > In so einem Fall ist es gut ein bißchen 'Moby' zu sein. Natürlich ist es von Nutzen, das ASM-Handwerk zu beherrschen. Beherrschen heißt aber auch, die Grenzen zu kennen.
Gu. F. schrieb: > Wenn ich dieses Projekt zu sehen bekäme (egal wie effizient oder auch > nicht) wäre ich sofort still Das glaube ich zwar nicht, weil dann die Diskussion losginge 'das kann C aber noch viel besser', aber sei es drum. Ich sage auch nicht das man sich das heute noch antun muß. Warum soll ich mich mit einem 8085 oder 8031 abquälen wenn es für einen Bruchteil des Preises MCUs gibt die das alles ohne zucken nebenbei erledigen. Ich habe auch keine Beispielcodes, weil ich von >10Jahren mit dieser Art der Selbstkasteiung aufgehört habe. Ich betreibe kein Codemuseum, das ist alles schon lange dem Verfall anheim gefalen. Gu. F. schrieb: > Vor diesem Hintergrund kann so ein Gehabe wie: > Moby A. schrieb: >> Da kann ich Dich beruhigen: Alles im grünen Bereich bis hoch zu 10K. Das >> sagt ein durchschnittlicher Asm-Programmierer. > kann einen schon mal leicht ankot*** Er wurde massiv angegriffen und hat damit nur gesagt das er bis hoch zu 10K noch den Überblick über seinen Code behält. Was auch immer er da geschrieben hat ist mir auch egal, aber ich sehe nicht das mich sowas ankot**n müsste. Lass Ihn doch. Er macht tiny, nichts als tiny, ASM nichts als ASM. Natürlich fehlt da der Blick was auf anderen Platformen möglich ist und wo die Schwierigkeiten bei größeren Projekten liegen. Ich verstehe nur nicht das Moby mit Gewalt auf den rechten Pfad zurück geführt werden soll. Er bringt provokante Sprüche, er bekommt provokante Sprüche. Verbohrt und selbstreferenziert sind beide Seiten. Argumente wie: 'glaub ich ihm nicht bis ich nicht seinen Code gesehen habe' hören sich so ein wenig nach Bindl an (Wenn man es nicht wiegen kann ist es real nicht vorhanden) Mit der Coder Erfahrung die sich die meisten Diskutanten hier selbst zuschreiben sollte jedem klar sein das mit handoptimierten ASM auf den alten MCUs / Prozessoren Dinge erschaffen wurden für die man heute erheblich stärkere hardware projektieren würde. So, das kostet mir zuviel zeit, macht mal eine weile ohne mich weiter :-)
Michael K. schrieb: > C Compiler (unbewiesene Behauptung) steht das > 'Weltsprachenargument' auf tönernen Füssen. Ja sorry, es war flapsig ausgedrückt. Ich kann mich nur auf die bastelfreundlichen µC beziehen und selber benutze ich beim Basteln bis jetzt nur 8bit PICs. Un da schätze ich mir die Weltsprache C. Wenn ich ein Programmbeispiel im Netz suche, dann kann ich von C-Codeschnipseln profitieren, sogar wenn sie für AVR oder andere µC erstellt wurden. ASM Codeschnipsel bringen mir dagegen gar nichts, oder wenn dann nur die Kommentare etwas. Michael K. schrieb: > Ich schätze die Bequemlichkeiten von C, aber Ja, weil du die Wahl hast. Ein ASM Freak versperrt sich die Option. Man kann darüber duskutieren aber es bleibt seine Entscheidung.
@Michael K.: Da bin ich 100% Deiner Meinung. Ein DMX-Empfang auf einem mit 8Mhz laufenden 8031 ging definitiv nur in Assembler, und auch da war es sehr knifflig. Allerdings stellen heutige Microcontroller immer mehr Möglichkeiten zur Verfügung, die dieses bitgenaue Timing immer mehr in die Hardware verlagern können, z.B. durch DMA, Timer oder eine andere Hardware-Schnittstelle. Ein STM32Fxxx kann z.B. das Bitttiming zur Ansteuerung eines WS2812-Ledstrangs komplett per DMA übernehmen, die damit zur Nebenaufgabe mit wenigen % CPU-Auslastung mutiert. Ein Atmega ist dagegen mit dem UART-Empfang und der gleichzeitigen WS2812-Ansteuerung komplett ausgelastet. Früher hatten diese Spezial-Optimierungen Sinn, weil es einfach keine andere Möglichkeit gab. Aber heute ist ein Controller mit diesen Features direkt daneben im Regal für praktisch denselben Preis. > Ich habe mal Code überarbeiten müssen bei dem der Autor in C > Konstruktionen gewählt hat die auf unglaublichen Umwegen zum Ziel > geführt haben. Solche Konstrukte gibt es leider auch zur Genüge in Asm. Das Problem dabei ist, daß dort diese "Fehlkonstruktion" viel weniger ersichtlich ist und damit auch viel seltener korrigiert wird. Viele Grüße, Stefan
Witkatz :. schrieb: > 8bit PICs Der muss noch ... PICs ? 8 bit ? Alle Zutaten für zwei weitere Flame War Threads vorhanden. Beides geht ja garnicht wenn man dem Forum glauben schenken will. (ruhig Blut, benutze ich unter anderem auch)
P. M. schrieb: > Das könnte durchaus erklären, warum Moby so versessen auf sein Assembler > ist: Es ist insofern einfacher, dass dort alles per Fleissarbeit > zusammengestiefelt wird, dafür ist fast kein abstraktes Denken > erforderlich. Man kann sich Schritt für Schritt vorstellen, was der > Prozessor macht, wie bei einem Kind, das mit der Finger-Methode > rechnet... Hier mach Moby aber nicht wirklich eine gute Figur, z.B. beim Vergleich einer 32-Bit Zahl gegen eine Konstante: Sein Code ist nicht nur länglich sondern auch falsch, und das obwohl es nur ein unsigned Vergleich ist. Beitrag "Re: C versus Assembler->Performance" Wober Mobys eigentliche Lösung darin besteht, solche Arithmetik als "nicht typisch für 8-Bit Anwendungen" zu definieren. Übrigens wäre der Code auch bei einem 16-Bit Vergleich falsch gewesen...
Danke für die vielen interessanten Rückmeldungen. Ich werde mich bemühen, nach und nach möglichst vielen eine adäquate Antwort zu geben: Falk B. schrieb: > Wie süß, wir stricken uns einen ADC selber ;-) > Es beschreibt deinen Programmiererhorizont nur allzu gut. Das dürfte auch für Dich schnell recht bitter schmecken wenn Du die Aufgabe innerhalb Deines C-Programmiererhorizonts besser lösen solltest ;-) Uhu U. schrieb: > Ohne Schaltplan... Und da laberst du von "Dokumentation"? Das zeugt nun nicht gerade von "Experte", für dieses hinreichend beschriebene, bis zum Erbrechen diskutierte Projektchen noch eines Schaltplans zu bedürfen! Carl D. schrieb: > Projekte, die Schaltpläne besitzen, sind niemals typische 8-Bit > MSR-Anwendungen. Da könnte was dran sein! Carl D. Du überrascht mich ausnahmsweise. > Es nervt einfach, wenn eine Diskussion über die > Abbildung von GPIO's in C++ nur noch der It-Neandertaler zu Wort kommt, > weil er das für sein Fachgebiet hält. Der It-Neandertaler, der es schneller, kürzer und ohne großen abstrakten Theaterdonner löst, den meinst Du sicherlich ;-) Albert M. schrieb: > Seit dem habe ich diesbezüglich von Dir dazu nichts mehr gehört. Ist Dir > die Anbindung an LabView inzwischen mit ASM gelungen? Hallo Albert, danke der Nachfrage, das "Gelingen der Anbindung" von Labview ist natürlich nun just kein Problem der Programmiersprache. Habe das aber nicht vergessen und melde mich sobald das Frontend steht. Momentan stehen noch vielerlei Zuträger auf dem Programm- im Moment gerade ein Controller zur Steuerung u.a. meiner Projektor-Leinwand ;-) Yalu X. schrieb: > Hmm, ist das alles? Und dafür brauchst du 10k? Dein Zweifel wird wohl daran liegen daß Du hier was unterschätzt. Es sind wohl schon zuviele Netzteilnehmer geworden, die natürlich alle ferngesteuert, protokolliert und z.T. via Internet zugänglich gemacht werden wollen.
Michael K. schrieb: > Ich finde es einfach faszinierend das sobald Kommunikation in > Schriftform stattfindet, die Diskutanten sich einen Dreck darum scheren > wie der Mensch gestrickt ist der da auf der anderen Seite sitzt. > Plötzlich zählt nur noch die eigene Wahrnehmung und die wird jedem um > die Ohren gehauen ohne sich darum zu kümmern ob dieser Weg zu > irgendeiner Verständigung führt Ob es soweit ausufern muss, sei mal dahingestellt. Aber du sitzt demjenigen nicht gegenüber. Du siehst nicht sein Gesicht, seine Körpersprache, möglicherweise sein höhnisches Grinsen und hörst nicht seine Stimme. Daraus bilden wir uns aber unser Urteil über den Gesprächspartner. Viele Forumsdiskussionen, die sich elendig lange hinziehen, wären im richtigen Leben nach 5 Minuten zur Zufiedenheit aller Teilnehmer beendet. mfg.
Johann L. schrieb: > Hier mach Moby aber nicht wirklich eine gute Figur, z.B. beim Vergleich > einer 32-Bit Zahl gegen eine Konstante: Sein Code ist nicht nur länglich > sondern auch falsch, und das obwohl es nur ein unsigned Vergleich ist. Nun ja, mein Tag war zuvor recht lang- und trotzdem kam die korrigierte Lösung sehr schnell hinterher. Brauchst nicht unnötig auf ersterer Veröffentlichung rumzureiten :-) Jonny O. schrieb: > Mach das ruhig weiter so Moby und lass > dich da nicht verunsichern. Schlussendlich ist doch das Wichtigste, dass > man Spaß am Hobby hat. Klar - du provozierst natürlich auch gerne - Hand > aufs Herz ;-) Nein, um mich hier verunsichern zu lassen dafür hab ich schon zuviel mit SimplyAVR/ASM realisiert. Und was heißt schon "provozieren"... Wenn sich manch Experte hier mit einfachen Asm-Lösungen vor den Kopf gestoßen fühlt- warum sollte das mein Problem sein? Nein, es amüsiert mich! Sheeva P. schrieb: > Nein, ist es nicht. Assembler ist unlesbar, chaotisch und kryptisch, > schon die Atmel-Variante hat über 130 Instruktionen. Die nutzt man alle zusammen recht selten. Bis ich bei AVR mal wirklich den EOR gebraucht habe, das hat Jahre gebraucht ;-) Auch Dein restliches Hochlied auf die Hochsprache kann ich nicht nachvollziehen. Mit Deinem Versuch der Umsetzung des bischen Funktionalität meines Demo-Projekts bist Du jedenfalls gradios gescheitert, vom Erreichen der eigentlichen Ziele ganz zu schweigen. > Hochsprachen sparen dadurch die wichtigste und kostbarste Ressource von > allen ein: die Lebenszeit der Entwickler. Weißt Du womit meine "Lebenszeit als Entwickler" geschont wird? Damit daß ich mich nicht mit den Tausend Eigenheiten von Hochsprache und ihren komplexen Entwicklungsumgebungen herumschlagen muß. Damit daß ich auf Dauer bei der AVR-Reihe bleiben kann und nicht alle Jahre die Architektur wechseln muss samt erneuter Einarbeitungszeit in die immer komplexeren Einfälle mancher MC-Ingenieure... Vom Verfolgen der Programmiersprach-Weiterentwicklung bis hin zum aberwitzigen OOP für MC ganz abgesehen- was für eine Verschleuderung von (Lern)zeit, wenn man nur seine Projekte einfachstmöglich realisiert haben will... Während Du über Deinen Büchern hängst um nach Wegen zu suchen die allerneuesten Hochsprachenkonstrukte sinnvoll anzuwenden hab ich längst fertig ;-)
Michael K. schrieb: > Argumente wie: 'glaub ich ihm nicht bis ich nicht seinen Code gesehen > habe' hören sich so ein wenig nach Bindl an (Wenn man es nicht wiegen > kann ist es real nicht vorhanden) Sag mal, kannst oder willst du das Problem nicht verstehen. Er stempelt sämtliche Fachleute als Idioten ab, die mit Ihren dämlichen C Kompilern nur Code verschwenden und nicht wissen wie echte Kerle programmieren und dann kann er NICHTS vorweisen als seinen berühmten 20++ Zeiler? Also echt, das ist doch Satire.
Thomas E. schrieb: > Viele Forumsdiskussionen, die sich elendig lange hinziehen, wären im > richtigen Leben nach 5 Minuten zur Zufiedenheit aller Teilnehmer > beendet. Du mußt Dich ja nun nicht auch noch dran beteiligen, noch dazu mit manchem wohl weniger ernst gemeinten Beitrag... Jonny O. schrieb: > So wie ich Moby verstanden habe, macht er das aber als Hobby. Wenn es > ihm Spaß macht mit ASM zu programmieren ist das doch okay. Es gibt doch > viel verrücktere Hobbys. Manche Leute bauen sich aus TTL-Gattern ganze > Computer zusammen. Im Prinzip total irre, aber wenns Spaß macht? Asm auf AVR ist alles andere als irre. Nein, es kommen viele schöne kleine feine Lösungen dabei raus, ohne großen Aufwand, nur die Lösung im Blick. > Lebenszeit ist nur dann verschwendet, wenn wir sie ohne Freude > verbringen. Absolut. Insofern ist das begeisterte Studium hochabstrakter Lösungen für einfache Probleme keine verschwendete Zeit, das will ich mal einräumen.
@ Moby AVR (moby-project) Benutzerseite >Asm auf AVR ist alles andere als irre. Nein, es kommen viele schöne >kleine feine Lösungen dabei raus, ohne großen Aufwand, nur die Lösung im >Blick. Tunnelblick! 8-0
Uhu U. schrieb: > Gilt das nicht für alle deine Tage? Da hast Du recht- heutzutage ist man damit aber sicher kein Einzelfall ;-) Wenn dies allerdings permanent zu Programmierfehlern führen würde hätte ich den Spaß sicher längst verloren ;-) Uhu U. schrieb: > Seit wann kann der AVR-Assembler IfThen zur Laufzeit? Schon klar, Waldvogel. Was man gerne missverstehen will... Erinnere Dich bitte an die weisen Worte von Thomas Eckmann weiter oben zum sinnlosen Verlängern von Diskussionen. Carl D. schrieb: > Wenn die dann aber in jedem Thread über "Single-Chip-Microcontroller" > erklären wollen, daß ihre TTL-Lösung besser ist und nur "immer besser > sein kann", dann ist Schluß mit lustig. Schon klar, Carl D. Ich empfehle statt dem AVR eine TTL-Lösung. Manche Vergleiche sind wirklich himmelschreiend. P. M. schrieb: > Eine > universell brauchbare Maximum-Funktion kann auch sehr gut bei 8-Bit-MSR > auftreten. Falls damit maximale und minimale Stellen einer Wertereihe herauszufinden waren kommt das öfter vor und ist simpel herauszufinden- am besten gleich dynamisch verglichen beim Eintreffen der Werte. > Ich warte auf eine Antwort oder sehe es als definitives > Eingeständnis daß ich mich sicher nicht mit dieser Art, Funktionen zu formulieren auseinandersetzen werde.
Moby A. schrieb: > Du mußt Dich ja nun nicht auch noch dran beteiligen, noch dazu mit > manchem wohl weniger ernst gemeinten Beitrag... Erstens ist der Beitrag durchaus ernst gemeint, zweitens wirst du mir bestimmt nicht vorschreiben, woran ich mich in welcher Forum beteiligen darf. mfg.
Falk B. schrieb: > Tunnelblick! 8-0 Blick aufs Wesentliche! Blick auf die Bedürfnisse der App! Diese Art Tunnelblick ist sehr zu empfehlen- sich nicht unnötig ablenken zu lassen! Witkatz :. schrieb: > immerhin besteht ASM zu 66% aus SM ... sagen die Asm-Laien ;-) Michael K. schrieb: > Es ist kein Geheimniss das man statt mit Moby auch mit einer Parkuhr > über den ASM -> 'alle anderen Sprachen' Konflikt diskutieren könnte. > Selbst Moby macht kein Geheimniss aus seiner Tiny + ASM Fixierung. Fixierung auf genau jene Werkzeuge, die tatsächlich zur Problemlösung nötig sind, meinst Du sicherlich... > Während Moby Gebetsmühlenartig die immer gleichen (nicht)Argumente > bringt und auch überhaupt nicht vorhat sich davon abbringen zu lassen > wird es auf der 'Gegenseite' immer verbissener. Falsch. Ich bin von allem abzubringen wenn es denn Hand und Fuß hätte. Das ist zugegebenermaßen nach ein paar Jahren Asm-Erfahrung recht schwierig. Gleichzeitig kann ich permanent (auch hier) vergleichen, mit welchem Aufwand und mit welchem Ergebnis C(++) Lösungen produziert. Das führt dann regelmäßig dazu daß ich mich entspannt zurücklehnen kann ;-) > Es wird einfach nicht passieren das sich am Ende aller Diskussionen ein > geläuterer Moby in seinen 'Kerninghan / Ritchie' vertief. Damit könntest Du Recht haben. Um es aber ganz klar zu sagen: Ich möchte wirklich niemandem den Spaß an irgendeiner Sache nehmen. Nur sollte es jeder auch genauso handhaben und sein Tun permanent mit den Ergebnissen anderer Wege vergleichen!
:
Bearbeitet durch User
Moby A. schrieb: > Uhu U. schrieb: >> Seit wann kann der AVR-Assembler IfThen zur Laufzeit? > > Schon klar, Waldvogel. Was man gerne missverstehen will... Erinnere Dich > bitte an die weisen Worte von Thomas Eckmann weiter oben zum sinnlosen > Verlängern von Diskussionen. Ha, ha, da konntest du den geheimen Wunsch nach mehr Programmierkomfort nicht ganz unterdrücken und nun ringst du um eine Ausrede... Glaubwürdig geht anders ;-) > Schon klar, Waldvogel. Uhus sind alles, nur keine Waldvögel, Herr Moby Dünn.
Moby A. schrieb: > Nur sollte es > jeder auch genauso handhaben und sein Tun permanent mit den Ergebnissen > anderer Wege vergleichen! Und das tust du? Du hast doch noch nie in C programmiert. Du plapperst nur irgendwelche Dinge aus, die du meinst irgendwo gesehen zu haben, ohne sie verstanden zu haben. mfg.
Frank M. schrieb: > Ganz einfach: Du hast eine merkwürdige Auffassung von "typischen > 8-Bit-Anwendungen". > > 99,9% der Entwickler sind da anderer Ansicht als Du. Wenn diese einen > ATmega328 nehmen, dann nehmen sie ihn, um ihn auch auszunutzen. Denn > sonst würden sie ja einen ATmega168. Dem Asm-Programmierer langt dann ein Mega88. Höchstens. > Während Du nur 0,1% eines ATmegas produktiv nutzen kannst, packen da > andere Leute Anwendungen rein, von denen Du nur zu träumen wagst. Das > sind typische 8-Bit-Anwendungen! Natürlich. Ein Frank M. weiß das. Aber man kann es ja öfter mal behaupten. Verdammt, irgendwann muß doch mal was hängenbleiben!!! (denkt sich Frank M.) > Deine 23-Zeilen-Assembler-Programme sind einfach nur Verschwendung und > lassen den Großteil der AVR-HW einfach brachliegen. Du bist also kein > Sparfuchs, sondern eher ein Verschwender sondergleichen. Oh Gott- mit dieser Logik hätte ich nicht viel Spaß gehabt. Weißt Du eigentlich was "vorausschauend handeln" meint? Noch nie ein bestehendes Projekt erweitert? Deine Äußerungen sind reichlich praxisfern. Aber sonst hast Du wohl auch schon alles hier versucht... ;-(
Moby A. schrieb: > Nur sollte es > jeder auch genauso handhaben und sein Tun permanent mit den Ergebnissen > anderer Wege vergleichen! Schwierig, wenn du uns deine Ergebnisse seit 500 Threads vorenthälst.
Gu. F. schrieb: > Sag mal, kannst oder willst du das Problem nicht verstehen. Doch doch, ich versteh das Problem schon. Du fühlst Dich in Deinem Stolz verletzt und mußt das jetzt unbedingt richtigstellen. Unmöglich aufzuhören bis Moby sich endlich mit einem Strauß Blumen in der Hand bei Dir entschuldigt hat. Jaaaaa ... Ich will nicht sagen das es völlig ausgeschlossen ist das das je passiert, nur ... Hm, wie sag es am besten ? Heul doch, hört sich jetzt etwas hart an, oder ? Es gibt da draussen ein paar Milliarden Menschen die die Dinge anders sehen als ich. Jeder von denen hält sich in irgendwas für den King of Kotelett. Willst Du Dir die Pulsadern öffnen wenn Du nicht jeden einzelnen von Deiner Sicht der Dinge überzegen kannst ? Ist Dir wirklich noch nicht aufgefallen das Du 100 Jahre weitermachen könnstest ohne irgendetwas an seiner Überzeugung zu ändern ? Bist Du denn besser ?
Michael K. schrieb: > Doch doch, ich versteh das Problem schon. > Du fühlst Dich in Deinem Stolz verletzt und mußt das jetzt unbedingt > richtigstellen. > Unmöglich aufzuhören bis Moby sich endlich mit einem Strauß Blumen in > der Hand bei Dir entschuldigt hat. Du bist entweder krank oder Mobys zweit Account. tststs.
Uhu U. schrieb: >> Schon klar, Waldvogel. > > Uhus sind alles, nur keine Waldvögel, Herr Moby Dünn. Aber der Spruch ist trotzdem nicht schlecht. mfg.
Michael K. schrieb: > Frank M. schrieb: >> Während Du nur 0,1% eines ATmegas produktiv nutzen kannst > Ähm, war es nicht Moby der hier in der Kritik steht provozierende und > unbewiesene Nichtargumente zu bringen ? s.o. > Ich denke es steht ausser Frage das der ideale ASM Code eine MCU immer > besser ausnutzt als der ideale C Code. > Der Punkt über den hier m.E. überwiegend Einigkeit herrscht ist der, das > ASM ab einer gewissen Größe von Menschen nicht mehr annähernd ideal zu > schreiben ist und ein C Compiler da bessere und schnellere Arbeit > abliefert. Richtig. Ab einer gewissen Größe. Beim einen 10K, beim anderen 1K, beim dritten Null. > Gerade die 'optimierungen' mancher Compiler können einem echt die Karten > legen. > Z.B. beim Xmega den Takt umschalten geht in GCC je nach > Optimierungsstufe mal und mal nicht. Grund ist das zwischen dem > freischalten und beschreiben der Taktquellenregister nur x (?) Zyklen > vergehen dürfen. > Das scheint GCC nicht zu wissen und nicht zu berücksichtigen. Nettes Detail. Aber danke. Ich muß das gar nicht alles so genau wissen, manches kann auch in dunkler Ahnung verbleiben ;-) > Man kann also sagen das man ASM Grundlagen beherrschen sollte auch wenn > man C schreibt. Als ASM Coder braucht man aber nicht zwangsläufig C > Kenntnisse. So ist es. > Mist, jetzt hör ich mich schon an wie Mobys Wassertträger Nein. Endlich ist mal einer hier ehrlich. Auf dieser Basis lässt sich doch aufbauen...
Moby A. schrieb: > Weißt Du eigentlich was "vorausschauend handeln" meint? > Noch nie ein bestehendes Projekt erweitert? Natürlich, das mache ich stetig. Aber von Dir habe ich noch nie eine Erweiterung gesehen. Erweitere doch mal Dein berühmtes Sensorboard um 2 Sensoren. Wie Dir schon einige im dazugehörenden Thread vorgerechnet haben, musst Du Deinen Source dann komplett neuschreiben - weil die Programmlogik die feste Anzahl von Sensoren ausnutzt. Also: Was ist mit Deinen sogenannten "Erweiterungen"? Es gibt sie nicht.
Uhu U. schrieb: > Uhus sind alles, nur keine Waldvögel, Herr Moby Dünn. Uhus passen sich vielseitig an Lebensräume an- auch an Waldgebiete... Sheeva P. schrieb: > Das stimmt. Moby macht sich hingegen mit seiner totalen Unzugänglichkeit > für rationale Argumene lächerlich, insofern besteht Gleichstand. ;-) Weißt Du was das beste rationale Argument ist? Die fertige Lösung in der Hand und das Wissen, mit welchem simplen Aufwand sie zustande kam... Ich schau gerade nochmal in meinen Projekt-Thread voller seeehr greifbarer rationaler Argumente dieser Art: Beitrag "Kleines Tiny13 Sensorboard" Hey, immer noch keine greifbaren rationalen Gegenargumente ;-(
:
Bearbeitet durch User
Moby A. schrieb: > Fixierung auf genau jene Werkzeuge, die tatsächlich zur Problemlösung > nötig sind, meinst Du sicherlich.. Oh, natürlich habe ich genau das gemeint. Habe mich nur ungeschickt ausgedrückt. Moby A. schrieb: > Falsch. Ich bin von allem abzubringen wenn es denn Hand und Fuß hätte. Aber klar. Es liegt unzweifelhaft an uns das wir es einfach nicht schaffen uns verständlich auszudrücken. Wir können da nichts für, es ist der furchtbare C code der uns das Gehirn verkleister hat so das wir nur noch verschwurbeltes und unstrukturiertes Gebrabbel von uns geben können. Moby A. schrieb: > Ich möchte > wirklich niemandem den Spaß an irgendeiner Sache nehmen. Nur sollte es > jeder auch genauso handhaben und sein Tun permanent mit den Ergebnissen > anderer Wege vergleichen! Ja, das mit dem Vergleichen und dem Behaupten das der eigene Wege viel besser ist und die anderen ein wenig dumm, ist das natürlich so eine Sache. Da hat nicht jeder Deinen Weitblick zu sagen: 'Ich persönlich habe das so gelöst, aber es gibt da bestimmt viele Wege zum Ziel die auch nicht schlechter sind' Ich kann das auch garnicht verstehen sich jemand auf den Schlips getreten fühlt nur weil man ganz freundich darauf hinweist das die Entwicklung der letzten 40 Jahre im Compilerbau auf einem großen Irrtum beruht der einfach genügend Dumme gefunden hat die das unwidersprochen nachäffen. Ich finde das aber sehr nett von Dir das Du so überaus viel Geduld mit uns hast auch wenn es nicht immer leicht ist.
Moby A. schrieb: > Uhus passen sich vielseitig an Lebensräume an- auch an Waldgebiete... Was natürlich eine äußerst dünne Begründung für "Waldvogel" ist, Herr Moby Dünn...
Frank M. schrieb: > Aber von Dir habe ich noch nie eine Erweiterung gesehen. Erweitere > doch mal Dein berühmtes Sensorboard um 2 Sensoren. Wie Dir schon einige > im dazugehörenden Thread vorgerechnet haben, musst Du Deinen Source dann > komplett neuschreiben - weil die Programmlogik die feste Anzahl von > Sensoren ausnutzt. Vielleicht solltest Du dazu erst mal schauen welche Hardwaremöglichkeiten das Board bietet und welches der Sinn des gesamten Projekts ist. Und dann machst Du Dir noch einen Kopf darüber in welchem Rahmen welche Erweiterungen hier in Frage kommen. Im Gegensatz zu dem was Dir so vorschwebt erstelle ich auf den Punkt hin optimierte Lösungen- deshalb sind sie auch so effizient. Wenn ich mehr Sensoren gebraucht hätte überlegt man sich das vorher... Sheeva P. schrieb: > er Rest der Welt sei aus Gründen der Angeberei > und bewußten Ressourcenverschwendung auf Hochsprachen fixiert... Du unterstellst eben auch gerne was ;-) P. M. schrieb: > Der Punkt der Diskussion ist eigentlich, dass Moby behauptet, seine > Ansichten würden auch für grosse Programme gelten. Immer mit der selben > Dikussionsmechanik: > > Moby: "Gilt prinzipiell auch für grosse Programme." Na was heißt denn das, P.M.? Prinzipiell meint: 1. Es ist möglich. (Zum Verbesserungs-Potential von Asm hab ich mich ja schon geäußert) 2. Es hängt von gewissen Randbedingungen ab. Auch diese habe ich hier schon breitgetreten: Übung, Vorbereitung, System ...
Uhu U. schrieb: > Was natürlich eine äußerst dünne Begründung für "Waldvogel" ist, Herr > Moby Dünn... Ich wollte Dir nicht zu nahe treten. Immerhin, der Uhu ist sehr anpassungsfähig- also ein ehrenwerter Nickname ;-) Fehlt nur noch daß Du Deinem Namen alle Ehre machst...
Gu. F. schrieb: > Du bist entweder krank oder Mobys zweit Account. tststs. Klar, deswegen vertrete ich eine ganz andere Ansicht als er und habe auch schon einige Diskussionen mit ihm durch. Moment, vieleicht, wenn ich wirklich so krank bin, dann weiß ich ja garnicht das ich Moby bin. Hm, dumme Sache das. Moby ? Sag mal, bin ich Du, bist Du ich und warum hab ich plötzlich solche Kopfschmerzen. PFLEGER ! ICH WILL SOFORT MEINE MEDIZIN Nein, das ist einfach zu gut um jetzt damit aufzuhören. Was habe ich schon gelacht durch solche Threads. Wikipedia: Uhus haben einen massigen Körper und einen auffällig dicken Kopf mit Federohren. Die Augen sind orangegelb. Igitt, stimmt das ?
>> ATmega168. >Dem Asm-Programmierer langt dann ein Mega88. Höchstens. also 50% ohen Worte, echt..
Moby A. schrieb: > Vielleicht solltest Du dazu erst mal schauen welche > Hardwaremöglichkeiten das Board bietet und welches der Sinn des gesamten > Projekts ist. Und dann machst Du Dir noch einen Kopf darüber in welchem > Rahmen welche Erweiterungen hier in Frage kommen. Moment mal: Du warst es doch, der mit dem Verweis auf eine ominöse „Erweiterbarkeit“ dort bestimmte Implementierungsstrategien deiner Widersacher nicht akzeptieren wollte. Unterm Strich haben wir bislang jedenfalls noch nie etwas auch nur ansatzweise nennenswert Komplexeres als die paar Bytes dieses Sensorboards gesehen.
Moby A. schrieb: > Ich wollte Dir nicht zu nahe treten. > Immerhin, der Uhu ist sehr anpassungsfähig- > also ein ehrenwerter Nickname ;-) Wer sagt, daß er sich nach dem Vogel so nennt und nicht nach dem mehr oder weniger guten Kleber? > Fehlt nur noch daß Du Deinem Namen alle Ehre machst... Klebtomane?
Jörg W. schrieb: > Moby A. schrieb: >> Vielleicht solltest Du dazu erst mal schauen welche >> Hardwaremöglichkeiten das Board bietet und welches der Sinn des gesamten >> Projekts ist. Und dann machst Du Dir noch einen Kopf darüber in welchem >> Rahmen welche Erweiterungen hier in Frage kommen. > > Moment mal: Du warst es doch, der mit dem Verweis auf eine > ominöse „Erweiterbarkeit“ dort bestimmte Implementierungsstrategien > deiner Widersacher nicht akzeptieren wollte. Die ist nicht ominös sondern durchaus real. Das hat Software eigentlich so an sich ;-) Denkbare Beispiele hab ich genannt. Meistens weiß man auch nicht vorher, was die Zunkunft so alles an Ideen bringt. > Unterm Strich haben wir bislang jedenfalls noch nie etwas auch nur > ansatzweise nennenswert Komplexeres als die paar Bytes dieses > Sensorboards gesehen. Unterm Strich nehme ich zur Kenntnis, daß die behauptete Überlegenheit der Compiler für typische 8-Bit MSR Programme gegenüber Asm ein Märchen ist und vermutlich auch bleibt. Dazu bedurfte es nicht viel ;-)
Robert L. schrieb: >>> ATmega168. >>Dem Asm-Programmierer langt dann ein Mega88. Höchstens. > > also 50% > > ohen Worte, echt.. Gut so. Manches sollte man erstmal durchdenken bevor man es ausspricht ;-)
Moby A. schrieb: > Unterm Strich nehme ich zur Kenntnis, daß die behauptete Überlegenheit > der Compiler für typische 8-Bit MSR Programme gegenüber Asm ein Märchen > ist und vermutlich auch bleibt. Die hat wohl nie jemand behauptet, zumindest nicht was die „Dichte“ des Codes angeht (auf die es dir ja nahezu ausschließlich ankommt). Was die Entwicklungszeit angeht, da brauchst du dagegen mit keinem zu diskutieren.
>Die ist nicht ominös sondern durchaus real. Das hat Software eigentlich >so an sich ;-) Denkbare Beispiele hab ich genannt. Meistens weiß man >auch nicht vorher, was die Zunkunft so alles an Ideen bringt. Kurios wie du einerseits mit Erweiterbarkeit "Argumentierst". Andererseits jeglichen Nachteil von ASM dadurch "Rechtfertigst" dass durch gute Planung einmal erstellter Code nicht mehr geänderter werden muss.. z.b. > Im Gegensatz zu dem >was Dir so vorschwebt erstelle ich auf den Punkt hin optimierte >Lösungen- deshalb sind sie auch so effizient. >Wenn ich mehr Sensoren gebraucht hätte überlegt man sich das vorher...
Moby A. schrieb: > Robert L. schrieb: >>>> ATmega168. >>>Dem Asm-Programmierer langt dann ein Mega88. Höchstens. >> >> also 50% >> >> ohen Worte, echt.. > > Gut so. Manches sollte man erstmal durchdenken bevor man es ausspricht > ;-) ja, hättest du sollen
Moby A. schrieb: > Na was heißt denn das, P.M.? > Prinzipiell meint: > 1. Es ist möglich. (Zum Verbesserungs-Potential von Asm hab ich mich ja > schon geäußert) > 2. Es hängt von gewissen Randbedingungen ab. Auch diese habe ich hier > schon breitgetreten: Übung, Vorbereitung, System ... Es ist eben genau nicht möglich. Grössere Programme und grössere Prozessoren holen ihre Performance aus einem sehr komplexen Zusammenspiel diverser Komponenten, da hat der Mensch keine Chance, von Hand zu optimieren. Oder hast du das Gefühl, du könntest eine lange Kombination aus Register-Allokationen besser durchkombinieren als ein Computerprogramm namens Compiler?!?
Moby A. schrieb: > Unterm Strich nehme ich zur Kenntnis, daß die behauptete Überlegenheit > der Compiler für typische 8-Bit MSR Programme gegenüber Asm ein Märchen > ist und vermutlich auch bleibt. Dazu bedurfte es nicht viel ;-) So. Obwohl du im ganzen Thread der einzige mit der entsprechenden Meinung bist, nimmst du das also zur Kenntnis... Eine grössere Menge an Ignoranz ist eigentlich fast nicht mehr denkbar.
A. K. schrieb: > Sheeva P. schrieb: >> Das wird diesseits bestritten. Idealer Code ist immer derselbe, egal >> womit er ursprünglich entwickelt worden ist. > > Auch bei idealem Code kann es verschiedene Möglichkeiten geben. Vielen Dank, daß Du noch einmal auf den Kernpunkt meines darauf folgenden Absatzes ("Wobei auch dabei ja noch immer die Frage bestehen bleibt, nach welchen Kriterien ein Code denn als ideal gälte") hinweist. ;-)
Auf jeden Fall scheint sich die Erwähnung des Wortes "Assembler" auf diesen Thread gleichenfalls auszuwirken, wie auf Assembler-Listings. Viele Hundert Zeilen mit wenig Informationsgehalt.
Michael K. schrieb: > Ich stamme aus der Generation C64 und kenne durchaus den Reiz auf > unterster Ebene mit der Hardware zu kommunizieren und trickreiche > Laufzeitenhacks zu ersinnen die auf die Art mit C nicht möglich sind. Man kann Assembler-Code in C einbetten. Zum Glück ist das immer seltener notwendig, aber das ändert ja nichts daran, daß es geht. ;-) > Was haben wir nicht alles mit realen 4Mhz (8031), 64B Ram und einem 8K > Eprom gelöst. Was an Power fehlte wurde durch Gehirnschmalz ersetzt. Da sind wir wieder bei der kostbarsten Ressource von allen. > Dieses ganze Behauptungsgefussel wer wie blöd ist und wer den > universellen Plan hat was geht können wir uns wirklich sparen. Bis auf Moby haben das hier alle verstanden.
Stefan K. schrieb: > Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, > weil das Flash nur zum kleinen Teil ausgenutzt wird. > Und bei großen Programmen optimiert der Compiler besser als der Mensch. Das ist zweifellos die klügste Aussage, die ich dazu bisher gelesen habe.
Michael K. schrieb: > Unter ASM kann ich spezielle Teile auf den Takt genau optimieren. Nochmal: man kann Assembler in C einbetten, wenn man sowas braucht. > Ich habe mal Code überarbeiten müssen bei dem der Autor in C > Konstruktionen gewählt hat die auf unglaublichen Umwegen zum Ziel > geführt haben. Hätte der Compiler sinngemäß verstanden was da mal > rauskommen soll, hätte der optimieren können, aber in dem Fall ergab das > einfach ein Codemonster was die 8K Begrenzung gerissen hat. Und das soll jetzt ein Argument gegen C sein? Mach' mal die Gegenprobe: was wäre geschehen, wenn Dein Kollege ähnlichen Unsinn in Assembler geschrieben hätte? Dann hättest Du wohl die ganze Veranstaltung neu schreiben müssen. In jeder Programmiersprache kann man Unsinn machen. Das ist dann aber kein Argument gegen die Sprache, sondern nur eins gegen den Programmierer.
A.K.: > Also übersichtlicher als so geht's doch kaum: > 1⌈2 > 2 > 2⌈1 > 2 > ⌈/1 2 3 4 5 3 8 1 3 > 8 Vorsicht, wenn die ASM-Liga rausfindet, um was es sich da handelt, dann Gnade dir Gott. Hab auch etwas gebraucht, denn ich hab das nie selbst benutzt, nur die Sonderzeichen haben es verraten -> Iverson's Bessere Mathematik, noch Eine Programmier Sprache. Hat wie schon das C++-Template Max() den Vorteil, daß man sich nicht die "signed oder unsigned" Frage stellen muß, die "durchschnittlichen ASM-Programmieren" mit Sendungsbewußrsein gerne mal das Ergebnis verhagelt. Es gäbe auch noch: (max 1 2 3 4 5 3 8 1 3)
Carl D. schrieb: > Vorsicht, wenn die ASM-Liga rausfindet, um was es sich da handelt, dann > Gnade dir Gott. Wieso? Die Programmstruktur ist verdammt ähnlich. Goto wohin das Auge blickt, Struktur nicht zu finden. Oft noch nicht einmal mit Labels, sondern mit direkter numerischer Zieladresse. Und compiliert wird auch nicht. > die "durchschnittlichen ASM-Programmieren" mit Sendungsbewußrsein > gerne mal das Ergebnis verhagelt. Der Code war auch ohne Vorzeichen schon falsch.
:
Bearbeitet durch User
Sheeva P. schrieb: > Und das soll jetzt ein Argument gegen C sein? Nö, wo habe ich das gesagt ? Michael K. schrieb: > Erst massives Abspecken und SDCC haben es dann gebracht. Du weist was SDCC ist ?
Moby A. schrieb: > Johann L. schrieb: >> Hier mach Moby aber nicht wirklich eine gute Figur, z.B. beim Vergleich >> einer 32-Bit Zahl gegen eine Konstante: Sein Code ist nicht nur länglich >> sondern auch falsch, und das obwohl es nur ein unsigned Vergleich ist. > > Nun ja, mein Tag war zuvor recht lang- und trotzdem kam die korrigierte > Lösung sehr schnell hinterher. Brauchst nicht unnötig auf ersterer > Veröffentlichung rumzureiten :-) Wenn Assembler wirklich die Eigenschaften hätte, die Du ihm zuschreibst -- insbesondere Einfachheit, Klarheit und Übersichtlichkeit -- dann hättest Du Dich natürlich nicht korrigieren müssen, sondern gleich eine perfekte Lösung abgeliefert. Du schaffst es also offenbar nicht, Deinen eigenen Behauptungen gerecht zu werden. Daß Du Dich selbst nur als mittelmäßigen Assembler-Programmierer bezeichnest, ändert daran auch nichts. ;-) > Sheeva P. schrieb: > >> Nein, ist es nicht. Assembler ist unlesbar, chaotisch und kryptisch, >> schon die Atmel-Variante hat über 130 Instruktionen. > > Die nutzt man alle zusammen recht selten. Bis ich bei AVR mal wirklich > den EOR gebraucht habe, das hat Jahre gebraucht ;-) > Auch Dein restliches Hochlied auf die Hochsprache kann ich nicht > nachvollziehen. Natürlich kannst Du das nicht, weil Du keine Hochsprache beherrschst. Da ich hingegen sowohl Assembler als auch mehrere Hochsprachen beherrsche, kann mir Urteile bilden, die Dir mangels Horizont verwehrt bleiben. :-) > Mit Deinem Versuch der Umsetzung des bischen > Funktionalität meines Demo-Projekts bist Du jedenfalls gradios > gescheitert, vom Erreichen der eigentlichen Ziele ganz zu schweigen. Deine Reaktion auf meinen Code war plötzlich sofort neue Anforderungen zu erfinden. Meine Lebenszeit ist mir zu wertvoll, um sie mit unseriöser und unehrlicher Falschspielerei zu verschwenden. ;-) >> Hochsprachen sparen dadurch die wichtigste und kostbarste Ressource von >> allen ein: die Lebenszeit der Entwickler. > > Weißt Du womit meine "Lebenszeit als Entwickler" geschont wird? Ja, das weiß ich -- und zwar viel besser als Du es wissen kannst. Denn, wie gesagt, ich beherrsche sowohl Assembler als auch Hochsprachen. Und deswegen kann ich Dir mit absoluter Sicherheit sagen: die Hochsprachen haben gewonnen, weil man das Ziel damit viel einfacher, schneller, und preiswerter erreichen kann als mit kryptischem, chaotischem, unles- und unwartbarem Assembler-Spaghettigefumsel. Die Hochsprachen haben gewonnen, weil sie den Entwickler eben nicht dazu zwingen, seine Denk- und Sichtweise auf das Problem an die einer Maschine anzupassen, sondern es ermöglichen, das Problem strukturiert, mithin der natürlichen, menschlichen Gedankenstruktur folgend, einfach, schnell und mit dem geringsten Aufwand zu lösen. Genau deswegen haben übrigens auch die objektorientierten Sprachen über die prozeduralen Sprachen gesiegt: weil man dank Objektorientierung die Entitäten und Vorgänge aus der realen Welt noch einmal viel natürlicher abbilden und miteinander interagieren lassen kann -- wenn man das denn einmal gelernt hat, natürlich. ;-) > Damit daß ich mich nicht mit den Tausend Eigenheiten von Hochsprache und > ihren komplexen Entwicklungsumgebungen herumschlagen muß. Damit daß ich > auf Dauer bei der AVR-Reihe bleiben kann und nicht alle Jahre die > Architektur wechseln muss samt erneuter Einarbeitungszeit in die immer > komplexeren Einfälle mancher MC-Ingenieure... Vom Verfolgen der > Programmiersprach-Weiterentwicklung bis hin zum aberwitzigen OOP für MC > ganz abgesehen- was für eine Verschleuderung von (Lern)zeit, wenn man > nur seine Projekte einfachstmöglich realisiert haben will... Während Du > über Deinen Büchern hängst um nach Wegen zu suchen die allerneuesten > Hochsprachenkonstrukte sinnvoll anzuwenden hab ich längst fertig ;-) Entschuldige, aber da kann ich nur lachen. Strukturierte Programmierung und Objektorientierung zu erlernen, ist in Wahrheit nur ein einmaliger Aufwand, der durch die höhere Produktivität sofort amortisiert. Das ist nämlich in Wirklichkeit für die meisten Menschen gar nicht so schwierig wie Du es gerne behauptest; Menschen denken ohnehin schon in Strukturen und Objekten, und dann geht es nur noch darum, dies mit den Mitteln des jeweiligen Programmierparadigmas auszudrücken. Heute fangen schon Achtjährige mit strukturierter und objektorientierter Programmierung in der Grundschule an; in Großbritannien gehört das schon als Pflichtfach zum ganz normalen Lehrplan. Erzähl' mir also bitte nicht, daß das alles so oberkompliziert und schwierig sei. Oder möchtest Du uns ernsthaft weismachen, daß Dir etwas zu kompliziert ist, das schon Kinder in der Grundschule lernen können? Das würde allerdings vieles erklären. Vielleicht magst Du ja einmal darüber nachdenken, warum Grundschulkinder mit strukturierten und objektorientierten Sprachen an die Programmierung herangeführt werden, anstatt sie mit Assembler zu folter^Hfrustrieren... Obwohl, laß' das lieber: das Ergebnis wird Dir nicht gefallen. ;-)
Uhu U. schrieb: > Moby A. schrieb: >> Nun ja, mein Tag war zuvor recht lang- > > Gilt das nicht für alle deine Tage? Grundsätzlich sind alle Tage gleich lang. Aber verschieden breit! ;-)
Moby A. schrieb: > Um es aber ganz klar zu sagen: Ich möchte wirklich niemandem den Spaß an > irgendeiner Sache nehmen. Davon hat man bisher leider nichts gemerkt.
Moby A. schrieb: > Sheeva P. schrieb: >> er Rest der Welt sei aus Gründen der Angeberei >> und bewußten Ressourcenverschwendung auf Hochsprachen fixiert... > > Du unterstellst eben auch gerne was ;-) LOL! Siehe meine Zitatesammlung weiter oben.
Jörg W. schrieb: > Moby A. schrieb: >> Unterm Strich nehme ich zur Kenntnis, daß die behauptete Überlegenheit >> der Compiler für typische 8-Bit MSR Programme gegenüber Asm ein Märchen >> ist und vermutlich auch bleibt. > > Die hat wohl nie jemand behauptet, zumindest nicht was die „Dichte“ > des Codes angeht (auf die es dir ja nahezu ausschließlich ankommt). > > Was die Entwicklungszeit angeht, da brauchst du dagegen mit keinem zu > diskutieren. Deswegen vermeidet er es ja auch geradezu zwanghaft, auf mein Argument der kostbaren Lebenszeit einzugehen... aber natürlich ist es sehr durchsichtig, sich nur auf einen einzigen Punkt zu kaprizieren und alle anderen einfach geflissentlich zu ignorieren. ;-)
A. K. schrieb: (APL) > Wieso? Die Programmstruktur ist verdammt ähnlich. Goto wohin das Auge > blickt, Struktur nicht zu finden. Oft noch nicht einmal mit Labels, > sondern mit direkter numerischer Zieladresse. Und compiliert wird auch > nicht. ROTFL :)
Jörg W. schrieb: > Was die Entwicklungszeit angeht, da brauchst du dagegen mit keinem zu > diskutieren Doch, das mach ich auch gern. Dankbarerweise findet sich schon ein (nicht funktionsfähiger) C-Nachbau in meinem Projekt. Da war ich in Asm in jedem Falle schneller fertig ;-) Robert L. schrieb: > Kurios wie du einerseits mit Erweiterbarkeit "Argumentierst". > Andererseits jeglichen Nachteil von ASM dadurch "Rechtfertigst" dass > durch gute Planung einmal erstellter Code nicht mehr geänderter werden > muss.. Was ist da kurios? Wenn Code optimal auf die Hardware ausgerichtet ist heißt das noch lange nicht daß er sich funktionell nicht erweitern ließe. Warum siehst Du das so statisch? Schau mal ins Projekt! Das lässt sich z.B. prima mit einem Hauptprogramm erweitern welches die auszugebenden Werte nach irgendwelchen Vorgaben nachbearbeitet. Leute, wo bleibt bloß Eure Fantasie? P. M. schrieb: > Es ist eben genau nicht möglich. Grössere Programme und grössere > Prozessoren holen ihre Performance aus einem sehr komplexen > Zusammenspiel diverser Komponenten, da hat der Mensch keine Chance, von > Hand zu optimieren. Oder hast du das Gefühl, du könntest eine lange > Kombination aus Register-Allokationen besser durchkombinieren als ein > Computerprogramm namens Compiler?!? Ach was. Das Zauberwort lautet einfach: Mit System! Von grösseren Prozessoren war nie die Rede. Register-Allokationen sind kein Hindernis. Meine Vorgehensweise ist weiter oben beschrieben, fertige Funktionsbausteine daran angepasst. Der Compiler optimiert jenes Registerchaos, welches die Hochsprache samt all ihrer Konstruktionen selbst anrichtet, würde ich mal ganz flapsig sagen ;-)
P. M. schrieb: > So. Obwohl du im ganzen Thread der einzige mit der entsprechenden > Meinung bist Der Einzige unter ertappten Hochsprachlern ;-) Von Ignoranz könnt ich Dir auch manches berichten... Unmittelbare Folge ist daß man alles zehntausendmal wiederholen muß. Sheeva P. schrieb: > Stefan K. schrieb: > Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, > weil das Flash nur zum kleinen Teil ausgenutzt wird. > Und bei großen Programmen optimiert der Compiler besser als der Mensch. > > Das ist zweifellos die klügste Aussage, die ich dazu bisher gelesen > habe. Falsch. Sie nutzt eben doch was. Spätestens dann wenn man erweitern möchte. Oder statt einem Mega168 ein Mega88 ausreichen soll. Große, ganz große Programme mit großen Datenmengen und vielen Berechnungen würde ich auch in Hochsprache lösen.
Moby A. schrieb: >> Was die Entwicklungszeit angeht, da brauchst du dagegen mit keinem zu >> diskutieren > > Doch, das mach ich auch gern. Damit begibst du dich endgültig aufs Glatteis. Aber mach' ruhig, du definierst dir deine Welt ja ohnehin so zurecht, wie dir sie gerade passt. Dagegen kann man nicht mit rationalen Argumenten ankommen, denn im nächsten Moment hast du ja sowieso alles umdefiniert.
Jörg W. schrieb: > Damit begibst du dich endgültig aufs Glatteis. > > Aber mach' ruhig, du definierst dir deine Welt ja ohnehin so zurecht, > wie dir sie gerade passt. Dagegen kann man nicht mit rationalen > Argumenten ankommen, denn im nächsten Moment hast du ja sowieso alles > umdefiniert. Das hast Du Dir ja auch schön zurechtdefiniert. Das Wort "endgültig" hab ich auch schon öfter gehört. Bei kleinen Programmen und mit Übung, Vorbereitung, System ist der ASMler vielleicht sogar eher fertig. Ein sbi PortA,1 schreibt sich einfach schneller ;-) Bei größeren Sachen mit viel Optimietungspotential hatte ich mehr Zeitbedarf längst eingeräumt- freilich dann mit mehr Möglichkeiten fürs effizientere Ergebnis. Sheeva P. schrieb: > Wenn Assembler wirklich die Eigenschaften hätte, die Du ihm zuschreibst > -- insbesondere Einfachheit, Klarheit und Übersichtlichkeit -- dann > hättest Du Dich natürlich nicht korrigieren müssen, sondern gleich eine > perfekte Lösung abgeliefert. Na so ein Quatsch. Programmieren bleibt in jedem Fall eine anspruchsvolle Tätigkeit. Vielleicht sollte man etwas zu müde dann keinen Code mehr entwickeln und hier reinstellen... Korrigiert war sie ja trotzdem wenig später. Du hingegen hast es bis heute nicht geschafft, mit Deinem hochgelobten C eine funktionsfähige Version meines Projektcodes zu erstellen... > Da > ich hingegen sowohl Assembler als auch mehrere Hochsprachen beherrsche Das hast Du überzeugend demonstriert ;-) > Deine Reaktion auf meinen Code war plötzlich sofort neue Anforderungen > zu erfinden. Meine Lebenszeit ist mir zu wertvoll, um sie mit unseriöser > und unehrlicher Falschspielerei zu verschwenden. ;-) Alberne Ausreden. Den Ressourcenbedarf mit einer C-Lösung zu untertreffen war seit jeher erklärtes Ziel. Was zu den MC-Ressourcen zählt hatte ich als bekannt vorausgesetzt... > Die Hochsprachen haben gewonnen, weil sie den Entwickler eben nicht dazu > zwingen, seine Denk- und Sichtweise auf das Problem an die einer > Maschine anzupassen, Assembler hat gewonnen weil nur durch genaue Kenntnis der und Anpassung an die Maschine gelingt bestmöglicher effizienter Code. > Strukturierte Programmierung > und Objektorientierung ... bitte dort wo es Sinn macht. Und sie haben in jedem Fall ihren Preis der sich recht anschaulich in den nötigen Festplattengrößen heutiger PCs zeigt. Damit meine ich aber jetzt keine dicken Media-Sammlungen.
> als mit kryptischem, chaotischem, unles- und > unwartbarem Assembler-Spaghettigefumsel. Ich habe schon viel Code gesehen und geschrieben, aber …,Spaghettigefumsel bekommst du in jeder Sprache hin. Besonders Anfänger nach ihren ersten OOP-Kurs + Templates zum Frühstück, neigen gern am Problem vorbei zu designen. Ich will hier niemanden verteidigen, aber strukturierten/lesbaren/kommentierten Code kann man in jeder Sprache schreiben. Es ist aber auch eine typische Assembler vs. Hochsprachen Diskussionen, am Ende drehen alle durch :-) Bereue schon wieder etwas dazu geschrieben zu haben ...
Sheeva P. schrieb: > Deswegen vermeidet er es ja auch geradezu zwanghaft, auf mein Argument > der kostbaren Lebenszeit einzugehen... Lang und breit. Man sollte das nur nicht > einfach geflissentlich .. ignorieren ! P. M. schrieb: > Das könnte durchaus erklären, warum Moby so versessen auf sein Assembler > ist: Es ist insofern einfacher, dass dort alles per Fleissarbeit > zusammengestiefelt wird, dafür ist fast kein abstraktes Denken > erforderlich. Man kann sich Schritt für Schritt vorstellen, was der > Prozessor macht, wie bei einem Kind, das mit der Finger-Methode > rechnet... Da ist was dran. Das macht eben Asm einfach! Das hat es abstrakten Programmierformen voraus. Vom Schrecken der "Fleissarbeit" lässt sich freilich mit Übung, Vorbereitung, System so einiges nehmen. Nichtsdestotrotz sind in Asm genauso komplizierte "Maschinen" und Konstruktionen im Innern des MC zu entwickeln wie mit anderen Sprachen auch. Durch den unmittelbaren Kontakt zur und Kenntnis der Hardware mit optimalem Ergebnissen und allen Freiheiten.
Witkatz :. schrieb: > Für mich persönlich ist die Größe bereits da erreicht, wo ich in C mit > einfachen Vergleichsoperatoren arbeiten kann. Das mit dem Flags geht Dir mit der Zeit ins Blut über. Bei großen Berechnungen könnt ich allerdings schwach werden- nur brauch ich die selten. > Früher habe > ich PICs oft in Assembler programmiert. Was habe ich geflucht und Zeit > verloren, Hey da hab ich auch geflucht! Was war das für ein schlechter Controller samt zugehörigem Assembler! Fast wär ich auf Hochsprache umgestiegen. Zum Glück kamen aber dann die AVRs. > Die C Syntax ist dagegen für alle > verbindlich, C ist nun mal die Weltsprache der µC. Die AVR-Asm Syntax ist auch für alle verbindlich ;-)
Ralf G. schrieb: > Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert > eventuell komplett neuen Assembler-Code. Komplett neu? Welche "winzig kleine Änderung" sollte das bloß nötig machen ???
Moby A. schrieb: > Die AVR-Asm Syntax ist auch für alle verbindlich ;-) Nein. Atmels Assembler unterscheidet sich vom GNU Assembler.
Moby A. schrieb: > Ralf G. schrieb: >> Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert >> eventuell komplett neuen Assembler-Code. > > Komplett neu? Welche "winzig kleine Änderung" sollte das bloß nötig > machen ??? Das wurde doch schon mehrfach geschrieben, u.a. von Frank Frank M. schrieb: > Aber von Dir habe ich noch nie eine Erweiterung gesehen. Erweitere > doch mal Dein berühmtes Sensorboard um 2 Sensoren. Wie Dir schon einige > im dazugehörenden Thread vorgerechnet haben, musst Du Deinen Source dann > komplett neuschreiben - weil die Programmlogik die feste Anzahl von > Sensoren ausnutzt. Ignorieren gehört wohl zu deinen Spezialitäten.
Moby A. schrieb: > Sheeva P. schrieb: >> Stefan K. schrieb: >> Bei kleinen Programmen nutzt händische Optimierung mit Assembler nichts, >> weil das Flash nur zum kleinen Teil ausgenutzt wird. >> Und bei großen Programmen optimiert der Compiler besser als der Mensch. >> >> Das ist zweifellos die klügste Aussage, die ich dazu bisher gelesen >> habe. > > Falsch. Sie nutzt eben doch was. Spätestens dann wenn man erweitern > möchte. Oder statt einem Mega168 ein Mega88 ausreichen soll. LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und doppelter Programmspeicher) für nur € 1,35. > Große, ganz große Programme mit großen Datenmengen und vielen > Berechnungen würde ich auch in Hochsprache lösen. Als beruflicher Nutzer von Fuzzy Logic, in dessen Alltag es gerade um die Übertragung solcher Aussagen in berechenbare Regelwerke geht, stellt sich mir die Frage: was genau bedeuten hier die Termini "groß" und "ganz groß", bezogen auf Programme, sowie der Terminus "viele" bei den Berechnungen?
@Moby AVR deine Projekte sind gut Dokumentiert, leicht Verständlich, leicht Erweiterbar, 50% kleiner wie mit C möglich.. Sie verfolgen einen SEHR genau definiertem Zweck.. was war jetzt nochmal der Grund warum du den Code deines XMega Projektes (den mit dem Xport) nicht einfach postest?? "klauen" wird ihn keiner, weil die Aufgaben ja so speziell sind andererseits würdest du all das was du seit 500 Beiträgen versuchst zu vermitteln mit einem Schlag beweisen..
Sheeva P. schrieb: > LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, > den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und > doppelter Programmspeicher) für nur € 1,35. ATmega328 für 1,95 im Guloshop: Vierfacher Programmspeicher. Der ATmega88 wird da erst gar nicht angeboten... lohnt sich nicht.
Moby A. schrieb: > Du hingegen hast es bis heute nicht geschafft, mit Deinem hochgelobten C > eine funktionsfähige Version meines Projektcodes zu erstellen... >> Deine Reaktion auf meinen Code war plötzlich sofort neue Anforderungen >> zu erfinden. Meine Lebenszeit ist mir zu wertvoll, um sie mit unseriöser >> und unehrlicher Falschspielerei zu verschwenden. ;-)
Frank M. schrieb: > ATmega328 für 1,95 im Guloshop: Vermutlich ist der nicht für ein typ. "8-Bit MSR Programm" geeignet ;-)
Moby A. schrieb: > Du hingegen hast es bis heute nicht geschafft, > mit Deinem hochgelobten C eine funktionsfähige Version meines > Projektcodes zu erstellen... Du hast es bis heute ja auch nicht geschafft, Deinen unleserlichen Projektcode derart zu dokumenieren, dass man in C eine funktionsfähige Version Deines Codes programmieren kann! ;-) Und weisst Du, warum? Damit Du genau dieses Argument bringen kannst. Volle Absicht! Also: Her mit der Doku. Dann sehen wir weiter.
Marten W. schrieb: > Es ist aber auch eine typische Assembler vs. Hochsprachen Diskussionen, > am Ende drehen alle durch :-) Hihi ... > Bereue schon wieder etwas dazu geschrieben zu haben ... Ach was, mit dem ersten geschriebenen Wort ist klar das Dich alle hassen und es jede Menge Minus gibt. Das ist okay, das muß so sein. Am Rande einer Mittelalterlichen Hexenverbrennung zu versuchen eine sachliche und ausgeglichene Diskussion über Sinn und Zweck des ganzen zu führen ist ja auch eher die letzte dumme Idee die man je hatte. Da kann man nur lauthals lachend seinen Spaß bei haben während einem Blut und Erbrochenes um die Ohren fliegt. Pic gegen AVR 8bit gegen 32bit ASM gegen C Kurze Hosen gegen lange Hosen Fleischesser gegen Veganer Es wird schon einen Grund geben sich wie toll zu gebärden und mit Schaum vom Mund die immer gleichen Argumente in den Wind zu schreien. Ist doch deutlich zu erkennen das es einzig um dem Konflikt geht und nicht um die Gemeinsamkeiten. Selbst wenn mal einer zurücksteckt (Moby würde für große Programe und viel Datenverarbeitung auch C benutzen, hört, hört) wird das einfach ignoriert, denn > Er hat Jehova gesagt, steinigt ihn!
Marten W. schrieb: >> als mit kryptischem, chaotischem, unles- und >> unwartbarem Assembler-Spaghettigefumsel. > > Ich habe schon viel Code gesehen und geschrieben, aber > …,Spaghettigefumsel bekommst du in jeder Sprache hin. Besonders Anfänger > nach ihren ersten OOP-Kurs + Templates zum Frühstück, neigen gern am > Problem vorbei zu designen. Ich will hier niemanden verteidigen, aber > strukturierten/lesbaren/kommentierten Code kann man in jeder Sprache > schreiben. Selbstverständlich kann man in jeder Sprache schlechten Code schreiben. Aber Assembler ist Spaghetticode by Design; es gibt da schlicht und einfach keine Struktur und auch keine Sprachmittel, um das Programm zu strukturieren.
Michael K. schrieb: > Pic gegen AVR > 8bit gegen 32bit > ASM gegen C > Kurze Hosen gegen lange Hosen > Fleischesser gegen Veganer Mir ist es egal, ob ASM oder C. Hauptsache mit dem EMACS geschrieben!
Klaus W. schrieb: > Mir ist es egal, ob ASM oder C. Hauptsache mit dem EMACS geschrieben! ... und in Lisp ausgeführt. ;-)
Sheeva P. schrieb: > Selbstverständlich kann man in jeder Sprache schlechten Code schreiben. Real programmers can write FORTRAN programs in any language. :-)
Moby A. schrieb: > Ach was. Das Zauberwort lautet einfach: Mit System! > Von grösseren Prozessoren war nie die Rede. Siehst du, schon wieder das selbe Spiel. Zuerst behauptest du, es gelte für 8-Bitter. Da stimmt man dir so halb zu. Dann behauptest du, es gelte prinzipiell für jedes Programm. Da widerspricht man dir. Dann sagst du wieder, es gehe nicht um grössere Prozessoren. Also was jetzt, leg dich fest: Gilt deine Ansicht auch für grössere Prozessoren als für kleine 8-Bitter? Ja oder Nein? Moby A. schrieb: > P. M. schrieb: >> Es ist eben genau nicht möglich. Grössere Programme und grössere >> Prozessoren holen ihre Performance aus einem sehr komplexen >> Zusammenspiel diverser Komponenten, da hat der Mensch keine Chance, von >> Hand zu optimieren. Oder hast du das Gefühl, du könntest eine lange >> Kombination aus Register-Allokationen besser durchkombinieren als ein >> Computerprogramm namens Compiler?!? > > Ach was. Das Zauberwort lautet einfach: Mit System! > Von grösseren Prozessoren war nie die Rede. Register-Allokationen sind > kein Hindernis. Meine Vorgehensweise ist weiter oben beschrieben, > fertige Funktionsbausteine daran angepasst. Ok, du scheinst wirklich keine Ahnung zu haben, was in einem modernen Compiler passiert.
P. M. schrieb: > Ok, du scheinst wirklich keine Ahnung zu haben, was in einem modernen > Compiler passiert. Logisch, dass er das nicht hat, hat er ja nie benutzt. Deshalb glaubt er auch immer noch dran, dass er gegenüber einem Compiler tatsächlich 50 % kleineren Code verzapfen könnte.
Moby A. schrieb: > Komplett neu? Welche "winzig kleine Änderung" sollte das bloß nötig > machen ??? Z.B.: Einen auf 'unsigned' optimierten Vergleich einer 32-Bit-Zahl in 'signed' ändern. :-)
Ralf G. schrieb: > Einen auf 'unsigned' optimierten Vergleich einer 32-Bit-Zahl in 'signed' > ändern. :-) Wer seinen Code mit völlig überflüssigen, ressourcenfressenden 32-Bit-Variablen aufbläht, der hat die Effizienz einer hochoptimierten Assemblerprogrammierung in all seiner schlichten Schönheit und Eleganz einfach noch nicht verstanden ... Duck und weg, Stefan
"8bit ought to be enough for anybody [Moby Dick] "Ich bin ASM, Dein Gott. Du sollst keine anderen Programmierspachen neben mir haben." [Erstes Gebot Moby] "Wir sind ASM. Sie werden assimiliert werden. Deaktivieren Sie Ihre Schutzschilde und ergeben Sie sich. Wir werden ihre biologischen und technologischen Charakteristika den unsrigen hinzufügen. Ihre Kultur wird sich anpassen und uns dienen. Widerstand ist zwecklos!" [Raumschiff Entermoby]
Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: Jetzt musst du nur noch damit programmieren lernen Moby. Dann kommt deine Stunde.
@ Moby AVR (moby-project) Hallo! Ich bin ebenfalls begeisterter Assembler-Programmierer; auf vielen Prozessorarchitekturen. Ich programmiere auch in Hochsprache, vom verrückten FORTH über das kinderleichte C bis zu netzwerkfähigen Datenbankanwendungen für komplette Firmen. Für jede Aufgabe das geeignete Werkzeug. Wenn ich hier die engstirnigen Argumente Deiner "Gegner" lese, kann ich nur lächeln. Als ich letztens am Biertisch die Sorgen eines Bekannten hörte, der für die sicherheitsrelevante Software in seiner Firma die Validierung seines verwendeten C-Compilers machen muss, standen mir die Haare zu Berge. Er überlegt, alles in Assembler umzuschreiben, denn das würde der TÜV akzeptieren. Mein Tipp an Dich: lehne dich zurück und lächele! Du mußt Dir doch nicht die Haare wegen ein paar wenigen Leuten raufen. Es gibt genügend Leute, die Deine Meinung teilen, sonst gäbe es überhaupt keine Werkzeuge zur Assemblerprogrammierung.
Route 6. schrieb: > Mein Tipp an Dich: lehne dich zurück und lächele! Du mußt Dir doch nicht > die Haare wegen ein paar wenigen Leuten raufen. Es gibt genügend Leute, > die Deine Meinung teilen, sonst gäbe es überhaupt keine Werkzeuge zur > Assemblerprogrammierung. Vielleicht hättest du den Thread auch lesen sollen, bevor du hier etwas schreibst. Aber sonst scheinst du ja ein ganz toller Typ zu sein. mfg.
Route 6. schrieb: > Er überlegt, alles in Assembler umzuschreiben, denn das würde der TÜV > akzeptieren. Falls er es fertigbekommt, bevor sich die Spezifikation das nächste Mal ändert. ;-) Dass man bei Assembler tatsächlich „jedes Bit im Griff hat“, ich glaube, darüber sind wir uns alle einig. Allerdings mögen die meisten von uns (Moby explizit ausgenommen) den dafür zu zahlenden Preis in Form von Arbeits- oder Lebenszeit nicht zahlen.
Moby A. schrieb: > Hey da hab ich auch geflucht! Was war das für ein schlechter Controller > samt zugehörigem Assembler! Fast wär ich auf Hochsprache umgestiegen. > Zum Glück kamen aber dann die AVRs. >... > Die AVR-Asm Syntax ist auch für alle verbindlich ;-) Ich komme seit >15 Jahren mit PICs wunderbar zurecht. Auch mit Assembler komme ich gut zurecht. Neuerdings fand ich Spaß am XC8 und finde C auf 8bit PICs Klasse. Und jetzt? Jetzt muss ich mich sofort auf AVR Mikrocontroller stürzen, mit ausschließlich AVR-ASM. Ich hasse mein Leben ;-)
:
Bearbeitet durch User
Route 6. schrieb: > Für jede Aufgabe das geeignete Werkzeug. Wenn ich hier die engstirnigen > Argumente Deiner "Gegner" lese, kann ich nur lächeln. Wenn du den Thread gelesen hättest, dann würdest du sehen, dass genau der Standpunkt "geeignetes Werkzeug" hier schon die längste Zeit von den meisten vertreten wird. Und in den meisten Fällen ist das nicht Assembler. Route 6. schrieb: > Als ich letztens am Biertisch die Sorgen eines Bekannten hörte, der für > die sicherheitsrelevante Software in seiner Firma die Validierung seines > verwendeten C-Compilers machen muss, standen mir die Haare zu Berge. Frickler, die denken, ihre Probleme seien die Welt. Sorry, aber es gibt unzählige sicherheitsrelevante Anwendungen, die in C geschrieben sind. Wer das nicht hinkriegt, dann klemmts an einem anderen Ort.
P.M.: > Sorry, aber es gibt unzählige sicherheitsrelevante Anwendungen, die in > C geschrieben sind. Vor allem muß man nicht den kompletten Block zwischen Anforderung und Binärcode validieren, sondern kann auf einen validierten Codegenerator eines Compilers aufsetzen. Oder gibt es irgendwo zertifizierte ASM-Programmierer, die immer exakt gleich codieren?
Ist eig. dieses "C" Route 6. schrieb: > das kinderleichte C ein anderes als dieses "C"? Moby A. schrieb: > Das ist kryptischer Kauderwelsch für Eingeweihte. Vlt. ist ja alles nur ein... ähm... Missverständnis ;-)
Gu. F. schrieb: > Moby A. schrieb: >> Ralf G. schrieb: >>> Eine scheinbar winzig kleine Änderung in den Anforderungen erfordert >>> eventuell komplett neuen Assembler-Code. >> >> Komplett neu? Welche "winzig kleine Änderung" sollte das bloß nötig >> machen ??? > > Das wurde doch schon mehrfach geschrieben, u.a. von Frank > > Frank M. schrieb: >> Aber von Dir habe ich noch nie eine Erweiterung gesehen. Erweitere >> doch mal Dein berühmtes Sensorboard um 2 Sensoren. Wie Dir schon einige >> im dazugehörenden Thread vorgerechnet haben, musst Du Deinen Source dann >> komplett neuschreiben - weil die Programmlogik die feste Anzahl von >> Sensoren ausnutzt. > > Ignorieren gehört wohl zu deinen Spezialitäten. Der Einwand ist aber unberechtigt. Zu einem fertigen Design mal eben ein (paar) Sensoren hinzufügen zu wollen ist eben alles andere als eine Lapalie. Bietet der Controller 8 I/Os, man braucht aber nun partout 9 kann das schon ein komplettes Redesign der Hardware nötig machen. Genauso kann das je nach Funktionalität mit der Software sein. Nun kann man sich entscheiden: mach ich das von vornherein hard/softwareseitig flexibler und reserviere mehr Kapazitäten oder weiß ich von vorn herein was ich will und optimiere auf den Punkt, liefere die Lösung aus einem Guss. Flexibler benötigt dann eben auch mehr Ressourcen- gerade wenns in Hochsprache erfolgen soll. Ohne weiteres lässt sich auch in Assembler mehr Flexibilität verwirklichen, dann mit gleichem Preis. Ich bevorzuge, die benötigte Hardware zuallererst zu ermitteln, passende Software zu schreiben (bei AVR keine Wissenschaft) und damit die optimale Lösung aufs Parkett zu legen- andere Herangehensweisen könnte man glaub ich leicht in der Nähe gepflegten Pfusches ansiedeln. Wer freilich vorher nicht genau weiß was er/sie will muß dafür bezahlen.
Moby A. schrieb: > Flexibler benötigt dann eben auch mehr Ressourcen- gerade wenns in > Hochsprache erfolgen soll. Schreib' doch lieber nicht über Dinge, bei denen du dich nicht auskennst.
Sheeva P. schrieb: > LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, > den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und > doppelter Programmspeicher) für nur € 1,35. Na prima, leider ist diese Logik nicht die Regel... Dann gäbs keine Einwände- wenn der größere Flash dann nur nicht zu generell ineffizienterer Programmierweise verführen würde ;-) Sheeva P. schrieb: > was genau bedeuten hier die Termini "groß" und "ganz > groß", bezogen auf Programme, sowie der Terminus "viele" bei den > Berechnungen? Du denkst einfach zu statisch, willst das alles in Schubladen einsortiert haben. Natürlich gibts da keine Regeln. Das ist so variabel wie Übung, Vorbereitung, System der Programmierer die es umsetzen. Sheeva P. schrieb: > Moby A. schrieb: >> Um es aber ganz klar zu sagen: Ich möchte wirklich niemandem den Spaß an >> irgendeiner Sache nehmen. > > Davon hat man bisher leider nichts gemerkt. Daß Du mit Deiner C-Lösung nicht weitergekommen bist kannst Du nicht mir anlasten ;-)
Moby A. schrieb: > Daß Du mit Deiner C-Lösung nicht weitergekommen bist kannst Du nicht mir > anlasten ;-) Wohl aber, dass du damals auf Teufel komm raus NICHT dein Programm in kurzen, klaren Sätzen beschreiben wolltest. Irgendwer hat sogar den Versuch einer Anforderungsbeschreibung unternommen, die du aber bestätigt hast.
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >Moby A. schrieb: >> Flexibler benötigt dann eben auch mehr Ressourcen- gerade wenns in >> Hochsprache erfolgen soll. >Schreib' doch lieber nicht über Dinge, bei denen du dich nicht >auskennst. Sachkenntnis kann jede lebhafte Diskussion nur behindern! ;-)
Das witzigste: Wenn dieser Thread noch wesentlich länger wird, katapultiert TIOBE Assembler noch auf Platz 1, weil: die bei µC.net schreiben ja monatelang darüber! :-)
Jörg W. schrieb: > Schreib' doch lieber nicht über Dinge, bei denen du dich nicht > auskennst. Tja, leider leider ist es aber so ;-( Flexibilität kostet. In Form von portablem C bis zu 50% mehr Flash (Prognose von Peter D.- kann ich selbst aber nicht bestätigen) Was ich Dich noch fragen wollte, hast Du eigentlich wirklich schon mal was mit Xmega entwickelt? Robert L. schrieb: > was war jetzt nochmal der Grund warum du den Code deines XMega Projektes > (den mit dem Xport) nicht einfach postest?? Hatte ich das nicht schon beantwortet? Bitte such das nochmal raus. Wär auch reichlich unsinnig... Die meisten können schon das bischen Tiny-Code meines Projekts nicht nachvollziehen, obwohl sie hier große Reden schwingen ;-) Frank M. schrieb: > Du hast es bis heute ja auch nicht geschafft, Deinen unleserlichen > Projektcode derart zu dokumenieren, dass man in C eine funktionsfähige > Version Deines Codes programmieren kann! ;-) Das dürfte eher eine Aussage über Deine Kenntnisse sein... Wer aber auch mein kleines Programm mit leerem C-Code übersetzt der muß sich nicht mehr wundern wenn man dessen Beiträge nicht mehr ernst nimmt ;-) Sheeva P. schrieb: > Aber Assembler ist Spaghetticode by Design; es gibt da schlicht und > einfach keine Struktur und auch keine Sprachmittel, um das Programm zu > strukturieren. ... sprach der Experte ;-) Du redest auch viel wenn der Tag lang ist, oder? Zeig mal was Konkretes, das man auch ernst nehmen könnte ;-) Michael K. schrieb: > "8bit ought to be enough for anybody > [Moby Dick] > > "Ich bin ASM, Dein Gott. Du sollst keine anderen Programmierspachen > neben mir haben." > [Erstes Gebot Moby] > > "Wir sind ASM. Sie werden assimiliert werden. Deaktivieren Sie Ihre > Schutzschilde und ergeben Sie sich. Wir werden ihre biologischen und > technologischen Charakteristika den unsrigen hinzufügen. Ihre Kultur > wird sich anpassen und uns dienen. Widerstand ist zwecklos!" > [Raumschiff Entermoby] Das hebt mich und meine Absichten jetzt in Sphären, zu denen ich nie emporsteigen wollte... Nehmt Asm als das was es ist: Als optimale Programmierform kleiner 8-Bitter für übliches MSR.
:
Bearbeitet durch User
Moby A. schrieb: > Zu einem fertigen Design mal eben ein (paar) Sensoren hinzufügen zu > wollen ist eben alles andere als eine Lapalie. Bei mir wäre es das, solange der Bus, an dem die Sensoren hängen, und meine Software entsprechende Reserven haben. Ist der Bus ausgereizt => Worst case. Ist jedoch die Software ausgereizt, änndere ich an genau einer Stelle eine Zahl und die Software kann nun x Sensoren mehr verarbeiten, genügend RAM vorausgesetzt. Diese Änderung ist in unter einer Minute erledigt. Kannst du dir jetzt vorstellen, warum Flexibilität gewüscht ist? Moby A. schrieb: > Ich bevorzuge, die > benötigte Hardware zuallererst zu ermitteln, passende Software zu > schreiben (bei AVR keine Wissenschaft) und damit die optimale Lösung > aufs Parkett zu legen- andere Herangehensweisen könnte man glaub ich > leicht in der Nähe gepflegten Pfusches ansiedeln. passt irgendwie nicht zu Moby A. schrieb: > Meistens weiß man > auch nicht vorher, was die Zunkunft so alles an Ideen bringt.
>> LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, >> den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und >> doppelter Programmspeicher) für nur € 1,35. >Na prima, leider ist diese Logik nicht die Regel... Dann gäbs keine >Einwände- wenn der größere Flash dann nur nicht zu generell >ineffizienterer Programmierweise verführen würde ;-) doch, das ist die Regel.. nicht die Flash-Größe entscheidet den Preis, sondern die Stückzahl.. (vor allem wennst über den Tellerrand schaust, aka stm32 samt "board" für 3$ usw. , ) und JA man Programmiert ja absichtlich "Moby"-Ineffizient.. du bist nur der einzige der damit ein Problem hat ;-)
Frank M. schrieb: > Das witzigste: Wenn dieser Thread noch wesentlich länger wird, > katapultiert TIOBE Assembler noch auf Platz 1, weil: die bei µC.net > schreiben ja monatelang darüber! Das ist eine interessante Betrachtungsweise. Dann ist Moby womöglich gar kein Programmierer, sondern ein Bot. Und die Mehrzahl der "Leute", die ihm hier vehement widersprechen, sind ebenfalls Bots. Und das alles nur, um das Ranking zu verbessern. Jetzt ist die Sache klar. Also ist alles eine Verschwörung. Möglicherweise steckt ein Hasser einer weit verbreiteten Hochsprache dahinter. mfg.
Moby A. schrieb: > Jörg W. schrieb: >> Schreib' doch lieber nicht über Dinge, bei denen du dich nicht >> auskennst. > > Tja, leider leider ist es aber so ;-( Nein, keineswegs. > Flexibilität kostet. In Form von portablem C bis zu 50% mehr Flash > (Prognose von Peter D.- kann ich selbst aber nicht bestätigen) Die ist in dieser Form einfach Quatsch (auch wenn ich Peter sonst schätze), und nichts, auf dem du dich ausruhen solltest. Wenn das typische C-Programm 10 % mehr Code generiert als ein schönes, handgefeiltes Assemblerprogramm, dann dürfte das deutlich näher an der Realität sein, auch über 15 % würde ich hier nicht diskutieren. Aber nicht die Flexibilität selbst ist das, was da etwas kostet – das hatte ich dir mit der Umsetzung einer entsprechenden C++-Klasse für die IO-Zugriffe ja bereits demonstriert. Das hättest du in Assembler auch nicht besser hinbekommen, trotzdem ist die C++-Lösung deutlich flexibler, weil sie bspw. auch mit den IO-Ports direkt zurecht kommt, die nicht über SBI/CBI zugegriffen werden können, sondern nur über Speicher-Operationen. Dein einziges Argument dagegen war dann noch, dass die C++-Variante ja „kryptischer“ sei. Mag für dich eins sein, für viele andere ist es keins. > Was ich Dich noch fragen wollte, hast Du eigentlich wirklich schon mal > was mit Xmega entwickelt? Das musst du gerade fragen, der du der Meinung bist, dass die Peripherie der Xmegas kaum Unterschiede zu MegaAVR hätte … Aber wenn es dich beruhigt: ja, und zwar eins, was einen guten Teil der Hardware des entsprechenden Xmega ausgelastet hat, einfach deshalb, weil ein existierendes Board für einen völlig anderen Zweck mit einem kleinen Huckepack-Board umfunktioniert worden ist, sodass manche IO-Pins etwas unglücklich beschaltet worden sind. Da war dann bis zu DMA und Eventsystem alles mit im Boot. Das einzige, was ich da nicht einmal annähernd ausgelastet habe (trotz Gleitkomma und allem) war der Flash, gerade mal 10 KiB von 256 werden benutzt. Habe leider von Atmel kein Geld für die restlichen reichlich 240 KiB zurück bekommen. > Zeig mal was Konkretes, das man auch ernst nehmen könnte ;-) Das haben wir dich schon mehrmals gebeten, aber mehr als das Ding mit dem Tiny13 bekommen wir ja nicht zu sehen.
:
Bearbeitet durch Moderator
P. M. schrieb: > Siehst du, schon wieder das selbe Spiel. Zuerst behauptest du, es gelte > für 8-Bitter. Da stimmt man dir so halb zu. Dann behauptest du, es gelte > prinzipiell für jedes Programm. Da widerspricht man dir. Dann sagst du > wieder, es gehe nicht um grössere Prozessoren. > > Also was jetzt, leg dich fest: Gilt deine Ansicht auch für grössere > Prozessoren als für kleine 8-Bitter? Ja oder Nein? Welches "Spiel" konstruierst Du hier bloß? 1. Was prinzipiell meint hatte ich ausführlichst erklärt. 2. Grössere Controller oder gar Prozessoren hab ich nie als Ziele aufgeführt sondern das Gegenteil gesagt: Sie sind ob ihrer Komplexität nicht mehr für Asm geeignet. Das liegt aber nicht daran daß es mit Asm kein Verbesserungs- potential gäbe! Cyblord -. schrieb: > Jetzt musst du nur noch damit programmieren lernen Moby. Dann kommt > deine Stunde. Schau Dir mein Projektchen an, vielleicht lernst ja Du was draus ;-) Jörg W. schrieb: > Logisch, dass er das nicht hat, hat er ja nie benutzt. Deshalb > glaubt er auch immer noch dran, dass er gegenüber einem Compiler > tatsächlich 50 % kleineren Code verzapfen könnte. Unterstellungen machen wohl auch Moderatoren Spaß, nicht wahr? Demonstrier doch mal die gepriesene Leistungsfähigkeit an meinem Projekt- nur so kannst Du mich davon überzeugen (weil ichs prima vergleichen könnte). Route 6. schrieb: > Für jede Aufgabe das geeignete Werkzeug. Wenn ich hier die engstirnigen > Argumente Deiner "Gegner" lese, kann ich nur lächeln. > Mein Tipp an Dich: lehne dich zurück und lächele! Du mußt Dir doch nicht > die Haare wegen ein paar wenigen Leuten raufen. Es gibt genügend Leute, > die Deine Meinung teilen, sonst gäbe es überhaupt keine Werkzeuge zur > Assemblerprogrammierung. Das tu ich doch unentwegt... Wenn Fakten trotz zehntausendfacher Wiederholung mit alberner Ignoranz, Unkenntnis, Unterstellungen, Witzchen usw. usf. begegnet wird kann man doch nur lachen. Also mir machts Spaß!
> >Robert L. schrieb: >> was war jetzt nochmal der Grund warum du den Code deines XMega Projektes >> (den mit dem Xport) nicht einfach postest?? >Hatte ich das nicht schon beantwortet? Bitte such das nochmal raus. >Wär auch reichlich unsinnig... Die meisten können schon das bischen >Tiny-Code meines Projekts nicht nachvollziehen, obwohl sie hier große >Reden schwingen ;-) das wäre im Detail auch nicht notwendig, es genügt wenn 2 oder 3 den Code halbwegs verstehen/überschauen, und kundtun wie toll er ist.. es gibt hier genug Leute die wirklich gut ASM können, wenn die Code von einem (wie du selber schreibst) durchschnittlichem ASM Programmieren nicht lesen könne, beweist das doch eh nur dass deine Behauptungen nicht zutreffen..
Jörg W. schrieb: > Dass man bei Assembler tatsächlich „jedes Bit im Griff hat“, ich glaube, > darüber sind wir uns alle einig. Allerdings mögen die meisten von uns > (Moby explizit ausgenommen) den dafür zu zahlenden Preis in Form von > Arbeits- oder Lebenszeit nicht zahlen. ... weils an Übung, Vorbereitung und System mangelt. Falk B. schrieb: > Sachkenntnis kann jede lebhafte Diskussion nur behindern! ;-) Du hattest in Falk B. schrieb: > Naja, ich hab vor länhgerer Zeit mal mit STM32 rumgespielt, was mich > dabei am meisten abschreit sind die ELLLLLLENNLAAAANGEN Namen der > Register und die gefühlt TAUSENDEN Einstellungen, die man selbst für > einfachse IO-Konfifiguration machen muss!!! doch ganz vernünftige Ansichten. Insbesondere der aufgeführte Bläh-Code zur Initialisierung! Einfach köstlich. Sollte man Asm-Gegnern jeden Tag um die Ohren hauen ;-)
Moby A. schrieb: > Schau Dir mein Projektchen an, vielleicht lernst ja Du was draus In der Tat lernt man wirklich daraus. Aber nicht das, was du erwartest. Moby A. schrieb: > Demonstrier doch mal die gepriesene Leistungsfähigkeit an meinem > Projekt- nur so kannst Du mich davon überzeugen (weil ichs prima > vergleichen könnte). Du hast das C-Programm aber leider immer noch nicht geliefert. mfg.
:
Bearbeitet durch User
Witkatz :. schrieb: > Und jetzt? Jetzt muss ich mich sofort auf AVR Mikrocontroller stürzen, > mit ausschließlich AVR-ASM. Ich hasse mein Leben ;-) Nein. Mußt Du nicht. Kannst auch weiter 8-bittig Pic-ken... Mir kommts vor allem auf Eines an: Keep it simple. P. M. schrieb: > Wenn du den Thread gelesen hättest, dann würdest du sehen, dass genau > der Standpunkt "geeignetes Werkzeug" hier schon die längste Zeit von den > meisten vertreten wird. Und in den meisten Fällen ist das nicht > Assembler. Für 8-Bit MSR ist das Assembler. Je nach Übung, Vorbereitung, System. Natürlich hat auch C seine Berechtigung. Wogegen ich mich nur wende ist die These vom besseren C-Code gegenüber Asm. be s. schrieb: > Bei mir wäre es das, solange der Bus, an dem die Sensoren hängen Ja ja schön. An einem Bus. Meine Sensoren hängen an eigenständigen, vorverarbeitenden Knoten die die Ergebnisse an die Zentrale funken. Dort ist ein XMega zugange mit viiielen Reserven. Da spart man nicht. So ein SmartHome ist nie fertig. be s. schrieb: > passt irgendwie nicht zu Das passt schon. Konkrete Hardware mit konkreten Aufgaben. Wo Hardware-Erweiterungen denkbar sind macht mans flexibler. In meinem Kühlschrank und ein einem Badlüfter, da wo mein Projektchen eingesetzt wird, ist die vorgegebene Sensorausstattung absehbar ausreichend ;-)
Thomas E. schrieb: > Du hast das C-Programm aber leider immer noch nicht geliefert. Ich hab auch nicht behauptet, es wäre ressourcensparender! Behauptest Du das? Wenn ja: Dann vorzeigen ;-) Thomas E. schrieb: > Dann ist Moby womöglich gar kein Programmierer, sondern ein Bot. Ich merk schon, mangels weiterer Argumente bist jetzt auch Du am Ende ;-) Robert L. schrieb: > und JA man Programmiert ja absichtlich "Moby"-Ineffizient.. > du bist nur der einzige der damit ein Problem hat ;-) S.O. Beweisen bitte ;-) Jörg W. schrieb: >> Flexibilität kostet. In Form von portablem C bis zu 50% mehr Flash >> (Prognose von Peter D.- kann ich selbst aber nicht bestätigen) > > Die ist in dieser Form einfach Quatsch (auch wenn ich Peter sonst > schätze), und nichts, auf dem du dich ausruhen solltest. > Wenn das typische C-Programm 10 % mehr Code generiert als ein > schönes, handgefeiltes Assemblerprogramm, dann dürfte das deutlich > näher an der Realität sein, auch über 15 % würde ich hier nicht > diskutieren. Selbst die 10-15% gehen mir ja schon runter wie Öl ;-) > Aber nicht die Flexibilität selbst ist das, was da etwas kostet – das > hatte ich dir mit der Umsetzung einer entsprechenden C++-Klasse für > die IO-Zugriffe ja bereits demonstriert. Das hättest du in Assembler > auch nicht besser hinbekommen, trotzdem ist die C++-Lösung deutlich > flexibler, ... mit mehr Ressourcenverbrauch. Intransparent-abstraktem Code mit i.d.R. hohem Schreibaufwand. Aber gut, noch eine Verlängerung der C++ Diskussion hier- das schaff ich jetzt zeitlich nicht mehr ;-) > Das musst du gerade fragen, der du der Meinung bist, dass die > Peripherie der Xmegas kaum Unterschiede zu MegaAVR hätte … Genau. Das ist keine Meinung sondern Kenntnis. Nun könnte man freilich wieder übers Wörtchen "kaum" streiten aber Du wirst doch wenigstens zugeben, daß den Umstieg von AVR auf XMega und von AVR auf Cortex Welten trennen... > Aber wenn es dich beruhigt: ja, und zwar eins, was einen guten Teil > der Hardware des entsprechenden Xmega ausgelastet hat, einfach deshalb, > weil ein existierendes Board für einen völlig anderen Zweck mit einem > kleinen Huckepack-Board umfunktioniert worden ist, sodass manche > IO-Pins etwas unglücklich beschaltet worden sind. Da war dann bis zu > DMA und Eventsystem alles mit im Boot. Das einzige, was ich da nicht > einmal annähernd ausgelastet habe (trotz Gleitkomma und allem) war > der Flash, gerade mal 10 KiB von 256 werden benutzt. Habe leider von > Atmel kein Geld für die restlichen reichlich 240 KiB zurück bekommen. Vermutlich in Hochsprache und irgendwelchen Libraries. Kein Wunder, daß man da die Hardware nicht zu Gesicht bekommt ;-) > Das haben wir dich schon mehrmals gebeten, aber mehr als das Ding > mit dem Tiny13 bekommen wir ja nicht zu sehen. Der reicht auch als Demo der Überlegenheit von Assembler.
:
Bearbeitet durch User
Moby A. schrieb: > Ich hab auch nicht behauptet, es wäre ressourcensparender! > Behauptest Du das? Wenn ja: Dann vorzeigen Ich habe das auch nie behauptet. Moby A. schrieb: > Ich merk schon, mangels weiterer Argumente bist jetzt auch Du am Ende Ich habe noch gar nicht angefangen. Moby A. schrieb: > Selbst die 10-15% gehen mir ja schon runter wie Öl Ein sehr guter Assembler-Programmierer erreicht die vielleicht. Du nicht. Moby A. schrieb: > Der reicht auch als Demo der Überlegenheit von Assembler. Lach. mfg.
Moby A. schrieb: > Zeig mal was Konkretes, das man auch ernst nehmen könnte ;-) Pffffffffff ... ich hab mir grad die Tastatur versaut....
Moby A. schrieb: > Selbst die 10-15% gehen mir ja schon runter wie Öl ;-) Ach, was? Neulich warst du noch der Meinung, dass du mit einem halb so großen Device auskämst. > Nun könnte man freilich > wieder übers Wörtchen "kaum" streiten aber Du wirst doch wenigstens > zugeben, daß den Umstieg von AVR auf XMega und von AVR auf Cortex Welten > trennen... Nein, da stimme ich nicht zu. Sie sind anders, aber es sind da keine Welten dazwischen.
Moby A. schrieb: > Mir kommts vor allem auf Eines an: Keep it simple. Für deinen Horizont keine wirkliche Herausforderung ;-)
Moby A. schrieb: > Für 8-Bit MSR ist das Assembler. Je nach Übung, Vorbereitung, System. > Natürlich hat auch C seine Berechtigung. Wogegen ich mich nur wende ist > die These vom besseren C-Code gegenüber Asm. Das stimmt vielleicht dann, wenn "besser" heisst, dass das letzte Bit und der letzte Taktzyklus herausgequetscht wurden. Das ist in der heutigen Software-Entwicklung meistens aber nicht der Fall, da zählen andere Aspekte wie Entwicklungskosten, Wartbarkeit, Sicherheit, usw. Und zwar auch auf kleinen 8-Bittern.
Jörg W. schrieb: > Ach, was? Neulich warst du noch der Meinung, dass du mit einem > halb so großen Device auskämst. Tut er ja auch. Wenn er alles abgezogen hat, was er für unnötig oder viel zu kompliziert hält und was man davon sowieso nicht braucht, dann passt es auch in die Hälfte rein. So optimiert man Code.
:
Bearbeitet durch User
A. K. schrieb: > Wenn er alles abgezogen hat, was unnötig oder viel zu kompliziert ist > und was man sowieso nicht braucht, dann passt es auch in de Hälfte rein. Allerdings ist dieses Abziehen nur ihm gestattet. Allen anderen ist es verboten, weil ja die Erweiterbarkeit drunter leiden würde. ;-)
> Tut er ja auch. Wenn er alles abgezogen hat, was er für unnötig oder > viel zu kompliziert hält und was man davon sowieso nicht braucht, dann > passt es auch in die Hälfte rein. So optimiert man Code. nur daß ich damals mehrere Vorschläge hatte, die seinen Code noch mal kürzer machten, aber die waren natürlich dann "Schwachsinn", weil "not invented here". Alles was M. schreibt ist ein Fakt. Alles was andere schreiben hat mit dem 8-Bit-MSR-Thema nichts zu tun. Und es natürlich klar, daß sein Postulat "es get nicht besser" von anderen wiederlegt werden muß. Auf seiner Forums-Homepage nennt er sein Interesse an Naturwissenschaft. Ein solcher würde dieses C-Programm selber schreiben, um nachzuweisen, daß er Recht hat. So bleibt das eine These. (Und es könnte ja passieren, daß es bessere C-Programmierer gibt) Zudem vermute ich, es sind eher 8-Bit-M(S)-Anwendungen, denn Regelung kann man sich in M.'s kleiner Welt kaum vorstellen. Da muß man nämlich die Vorzeichen beachten.
:
Bearbeitet durch User
Wie ein kleines Kind vom Sandkasten nebenan doch die halbe Welt beschäftigen kann .... Wieso antwortet ihr überhaupt?
Markus M. schrieb: > Wie ein kleines Kind vom Sandkasten nebenan doch die halbe Welt > beschäftigen kann .... Wieso antwortet ihr überhaupt? Deshalb: Falk B. schrieb: > Schattenbox soll ja auch ganz nett sein. Chinesisches Schattenboxen dient "der Gesundheit, der Persönlichkeitsentwicklung und der Meditation" (Wikipedia).
Route 6. schrieb: > Ich bin ebenfalls begeisterter Assembler-Programmierer; auf vielen > Prozessorarchitekturen. Ich programmiere auch in Hochsprache, vom > verrückten FORTH über das kinderleichte C bis zu netzwerkfähigen > Datenbankanwendungen für komplette Firmen. Für komplette Firmen? Beeindruckend. Die meisten von uns entwickeln nur Anwendungen für halbe, viertel und achtel Firmen. Eine netzwerkfähige Datenbankanwendung in Assembler ist bestimmt sehr spannend, so etwas würde ich wirklich zu gerne mal sehen. ;-) > Für jede Aufgabe das geeignete Werkzeug. Lustigerweise sind hier alle darüber einig, außer Deinem Freund. ;-) > Wenn ich hier die engstirnigen Argumente Deiner "Gegner" lese, kann ich > nur lächeln. Frag' uns mal... > Als ich letztens am Biertisch die Sorgen eines Bekannten hörte, der für > die sicherheitsrelevante Software in seiner Firma die Validierung seines > verwendeten C-Compilers machen muss, standen mir die Haare zu Berge. > Er überlegt, alles in Assembler umzuschreiben, denn das würde der TÜV > akzeptieren. LOL! Was für einen seltsamen Compiler benutzt denn Dein Bekannter, daß er keinen Assembler-Code erzeugen kann? Damit könnte er auf das Neuschreiben verzichten, stattdessen für lange Zeit in Urlaub fahren, und trotzdem den TÜV-Prüfer und seinen Chef gleichzeitig glücklich machen. Das ist sicher nicht die übelste Ausgangslage für die nächste Gehaltsverhandlung.
Moby A. schrieb: > Sheeva P. schrieb: >> LOL! Den Mega88 gibt es beim großen F für € 1,99 in der 10-MHz-Version, >> den Mega168 in der 20-MHz-Version (also: doppelte Geschwindigkeit und >> doppelter Programmspeicher) für nur € 1,35. > > Na prima, leider ist diese Logik nicht die Regel... Dann gäbs keine > Einwände- wenn der größere Flash dann nur nicht zu generell > ineffizienterer Programmierweise verführen würde ;-) Dank größeren Flashs könnte man sich die sogar problemlos leisten. Damit hätte man obendrein viel kostbare Lebenszeit für noch bessere Funktionen, noch schönere Dinge und noch interessantere Projekte gewonnen. :-) > Sheeva P. schrieb: >> was genau bedeuten hier die Termini "groß" und "ganz >> groß", bezogen auf Programme, sowie der Terminus "viele" bei den >> Berechnungen? > > Du denkst einfach zu statisch, willst das alles in Schubladen > einsortiert haben. Natürlich gibts da keine Regeln. Das ist so variabel > wie Übung, Vorbereitung, System der Programmierer die es umsetzen. Tatsächlich denke ich da überhaupt gar nicht statisch, im Gegenteil. Die Fuzzy Logic ist bei sowas extrem dynamisch und flexibel. Also beantworte doch bitte meine Frage -- Du kannst das auch gerne in Assembler mit dem Fuzzy-Logic-Befehlssatz des M68HC12 ausdrücken, wie im "Motorola 68HC12 CPU12 Reference Manual" [1] dokumentiert. HF! [1] http://www.freescale.com/files/microcontrollers/doc/ref_manual/CPU12RM.pdf >> Moby A. schrieb: > Daß Du mit Deiner C-Lösung nicht weitergekommen bist kannst Du nicht mir > anlasten ;-) Das trifft leider nicht den Sachverhalt, wie Du ja weißt. Als ich meinen Code gepostet habe, hast Du geradezu panisch reagiert und plötzlich neue Anforderungen aus dem Hut gezaubert. Du hast behumst, und daraufhin habe ich die Sache abgebrochen und mich den schöneren Dingen in meinem Leben zugewandt. Warum sollte ich weiter denn mit einem Betrüger spielen? Ich hatte alles bewiesen, was zu beweisen war. (Und nein, mein Interesse an schlichtesten Sensorplatinchen, die nichteinmal mit Standardprotokollen kommunizieren, ist haargenau gleich Null.) :-) Insofern kannst Du mit Deiner Behauptung, ich sei "nicht weitergekommen", vielleicht Dich selbst blenden. Alle, die dabei waren, wissen es besser, und die anderen können es dank Deines Links ja selbst nachlesen. :-))
Thread beobachten
Seitenaufteilung abschalten