Auf dem Index von Januar 2022 von Tiobe: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/assembly-language/ Erreicht Assembler nun Rang 8 mit 1.85% und einem Zuwachs von +0.21%. Zum Warum: a) Ursachen für den Anstieg wäre unter anderem der Bedarf für die neuen Prozessoren aus chinesischen Eigenentwicklungen zu nennen. Die Assemblermodule, die die Compiler von höheren Programmiersprachen benötigen, müssen µC-spezifisch programmiert werden. b) Auch auf kleine µC können damit sehr schnelle Funktionen realisiert werden. Wegen deren Stromsparsamkeit rückt das auch wieder mehr in den Fokus. c) Die Anbindung des Quantencomputers als Quantencoprozessor verlangt eine sehr schnelle Anbindung, die Programmierarbeiten auf der Maschinencode-Ebene erfordert. In der Vergangenheit gab es zum Beispiel eine höhere Nutzung von Assembler für die Weiterentwicklung der Compiler für die Parallelisierung (Nutzen mehrere Kerne) und für die Virtualisierungsbeschleunigung (CPU und GPU). Wichtig dabei ist aber, dass hier in der Regel nicht Assembler-Code direkt geschrieben wird, sondern es hierzu Werkzeuge als Programmierumgebung gibt, die natürlich in höheren Programmiersprachen geschrieben sind und dort das Prozessormodell zur Simulation hinterlegt ist. Es gibt hier im Forum einen Postenden, der als ASM-Enthusiast zu weit aus überschwänglicher Freude über das Ziel herausschießt. Sein Thread wird deshalb immer wieder gelöscht.
:
Dieter schrieb: > Zum Warum: d) Jeder Hackstotzen, der mal eine Zeile Inline-Assembler irgendwo herkopiert hat, behauptet, er hätte "auch" in Assembler programmiert. Frei nach dem Motto "traue keiner Statistik, die du nicht selbst gefälscht hast" sollte man sich die Datenbasis ansehen: zur Ermittlung der Zahlen dient im Grunde, wie oft das Wort "Assembler" in Google eingegeben wurde:
1 | Popular search engines such as Google, Bing, Yahoo!, Wikipedia, |
2 | Amazon, YouTube and Baidu are used to calculate the ratings. |
Und das Fazit lautet:
1 | It is important to note that the TIOBE index is not about the |
2 | best programming language or the language in which most lines of code |
3 | have been written. |
> Sein Thread wird deshalb immer wieder gelöscht.
Er hat schlicht Hausverbot. Er weiß, warum.
:
Bearbeitet durch Moderator
Wow, den steilsten Aufstieg hat Fortran geschafft, um 11 Plätze nach oben! Dinosaurier sind einfach nicht totzukriegen.
ich habe beides gemacht, Assembler und C. Zu Beginn fühlte ich mich wohl in Assembler und empfand das auch nicht als unkomfortabel. Wenn aber auf einem 8-Bitter mit 12 oder 16 Bit gerechnet werden soll, ist C eine große Erleichterung. Und zu pflegen ist der Code auch definitiv besser.
in meinen über 30 Jahren habe ich genau 4 Zeilen Assembler nach dem Studium benötigt. Im Studium selbst natürlich ausgiebig damit rumgemacht aber danach nie wieder. Wird aus meiner sicht nur noch benötigt, wenn kein Compiler zur Verfügung steht oder der ums Verrecken den Zugriff auf spezielle Register / Funktionen nicht zuläßt (weils nicht geht oder der Programmierer es nicht umsetzen kann)
Interessant warum dieser Post nicht gelöscht wird
Ich für mein teil sage: Assembler hat genau so seine Daseinsberechtigung wie "C" und oder Basic in all ihren Varianten. Assembler ist halt nun mal Maschinennahe (eigentlich wurde dem Maschinencode einfach verständliche Namen gegeben). Macro-Assembler sind dann schon wieder eine Stufe höher. Aber es ist ja schon in der Regel so das bevor irgend eine Hochsprache für einen neuen µC kommt, kommt halt Maschinencode dann Assembler und erst später irgend eine Hochsprache die im Ursprung aber auch im Assembler geschrieben wurde. Später folgen dan noch Hochsprachen die in Hochsprachen geschrieben wurden bis hin zu Betriebssysteme, so ala RTOS & Co. Als ergo je mehr neue Prozessoren kommen des do mehr Assembler wird verwendet. Mal von den ob. schon geposteten Copy&Paste Relikten. Auch wenn ich selber rund 70% der Software die ich programmiere in Assembler mache, (mit unter weil wir auch schon eigene µC Designet haben). Würde ich niemals sagen das Hochsprachen Quatsch oder unnötig sind. Drum eben alles hat seine Daseinsberechtigung dass sinn macht, sonst würde es nicht immer noch verwendet und auch weiterentwickelt. Content B. schrieb: > Interessant warum dieser Post nicht gelöscht wird Wenn du diesen meinst der da gestartet wurde, weil diese Diskussion hier nicht Provokativ ist und Sinn macht ;-)
:
Bearbeitet durch User
Content B. schrieb: > Interessant warum dieser Post nicht gelöscht wird Das Löschen hat nichts mit dem Thema zu tun, sondern mit der Person, die hier Hausverbot hat.
Beitrag #6936966 wurde von einem Moderator gelöscht.
Beitrag #6936974 wurde von einem Moderator gelöscht.
Lothar M. schrieb: > Frei nach dem Motto "traue keiner Statistik, die du nicht selbst > gefälscht hast" sollte man sich die Datenbasis ansehen: ... Das Interessante steckt in den Gewichtungsfunktionen, die sich dahinter verbergen. Zum Beispiel die Suchen der privaten Hausanschlüsse haben ein anderes Gewicht als die Suchen am Hochschulrechner (IP-Nummerkreise der Hochschulen), Fachartikel gesucht und aufgerufen werden. Heinz schrieb: > Im Studium selbst natürlich ausgiebig damit rumgemacht > aber danach nie wieder. Bei Dir ist das so wie bei der Mehrheit nach dem Studium. Es reicht zu wissen, was Assembler ist und leistet. Wenn Sonderfunktionen benötigt werden, weiß man ungefähr wo die Firmen zu finden wären, die solche Anforderungen umsetzten könnten.
Beitrag #6936981 wurde von einem Moderator gelöscht.
Dieter schrieb: > Das Interessante steckt in den Gewichtungsfunktionen, die sich dahinter > verbergen. Ja, das ist auch eine Möglichkeit, das Ergebnis einer Statistik irgendwie zu beeinflussen.
Ich liebe Assembler, gerade auf Mikrocontroller habe ich gerne die direkte Kontrolle über Hardware und Interrupts, das hindert mich aber nicht auch andere Programmiersprachen zu verwenden, es kommt immer auf die Anwendung an. Ich kann die Emotionen nicht ganz verstehen die hier manchmal hervorkommen wenn das Thema Assembler auftaucht.
Beitrag #6936988 wurde von einem Moderator gelöscht.
Lothar M. schrieb: > Dieter schrieb: >> Das Interessante steckt in den Gewichtungsfunktionen, die sich dahinter >> verbergen. > Ja, das ist auch eine Möglichkeit, das Ergebnis einer Statistik > irgendwie zu beeinflussen. Mir hat man mal erklärt dass Statistiker Ergebnisse so beeinflussen können wie es der Auftraggeber wünscht, ohne dabei Falschangaben zu machen. Content B. schrieb im Beitrag #6936988: > Darf ich erfahren warum meine Frage gelöscht wurde? Eventuell mag er deine herkunft nicht?
Beitrag #6936990 wurde vom Autor gelöscht.
Beitrag #6936994 wurde von einem Moderator gelöscht.
Michael schrieb: > Mir hat man mal erklärt dass Statistiker Ergebnisse so beeinflussen > können wie es der Auftraggeber wünscht, ohne dabei Falschangaben zu > machen. Das sind keine Statistiker, das sind BWLer und Marketingleute. Statistiken kann man auch nicht wirklich beeinflussen, aber man kann die Datenbasis falsch interpretieren, aber eben das macht dann nicht der Statistiker.
Beitrag #6937002 wurde von einem Moderator gelöscht.
Content B. schrieb im Beitrag #6937002: > Lothar M. schrieb im Beitrag #6936990: >> Content B. schrieb im Beitrag #6936988: >>> Darf ich erfahren warum meine Frage gelöscht wurde? >> Lies deine Emails und hör auf, hier herumzutrollen! > Ich habe aber keine Löschmail bekommen! Persönliches Pech, bei mir kommen solche Löschmails an. Aber seis drum: der Grund ist, dass wir die Löschung von Posts gesperrter User nicht diskutieren.
:
Bearbeitet durch Moderator
Peter S. schrieb: > Statistiken kann man auch nicht wirklich beeinflussen Aus berufenem Munde: https://de.statista.com/statistik/lexikon/definition/8/luegen_mit_statistiken/
Dieter schrieb: > c) Die Anbindung des Quantencomputers als Quantencoprozessor verlangt > eine sehr schnelle Anbindung, die Programmierarbeiten auf der > Maschinencode-Ebene erfordert. kannst du erklären, was du damit meinst?
Lothar M. schrieb: > Aber seis drum: der Grund ist, dass wir die Löschung von Posts > gesperrter User nicht diskutieren. Danke! Jetzt verstehe ich! Werde mich auch nun daran halten!
He He, bei der Aufzählung fehlt Cobol. Zu Assembler: Den Tiny 10 programmiere ich ausschließlich in Assembler. Das ist aber auch die einzige Anwendung, die ich dafür habe. Dieter schrieb: > Wichtig dabei ist aber, dass hier in der Regel nicht Assembler-Code > direkt geschrieben wird, sondern es hierzu Werkzeuge als > Programmierumgebung gibt, die natürlich in höheren Programmiersprachen > geschrieben sind und dort das Prozessormodell zur Simulation hinterlegt > ist. Ähm, und das ist jetzt programmieren in Assembler oder wie oder was?
Andreas B. schrieb: > Ähm, und das ist jetzt programmieren in Assembler oder wie oder was? Berechtigte Frage, sehr viele Compiler machen ja ein Assemblercode daraus (Ja auch IAR) und dass ist dann nicht in Assembler Programmiert sonder zu Assembler Compiliert ;-) So sehe ich das jedenfalls.
Also die machen aus dem Programmcode Maschinencode und können es wenn gewünscht als Textfile mit Assembler Mnemonics ausgeben, das ist nicht programmieren in Assembler.
Peter S. schrieb: > Also die machen aus dem Programmcode Maschinencode Definitionssache. GCC macht Assembler-Quelltext draus, der von einem völlig anderen Programmpaket mit anderen Autoren in Binärcode umgesetzt wird.
Dieter schrieb: > c) Die Anbindung des Quantencomputers als Quantencoprozessor verlangt > eine sehr schnelle Anbindung, die Programmierarbeiten auf der > Maschinencode-Ebene erfordert. Wie sieht denn eine typische Anbindung eines Quantencomputers an einen Mikrocontroller bzgl. der Hardwareschnittstelle und des Kommunikationsprotokolls aus? Hast du da einschlägige Erfahrungen? Wo werden heute Quantencomputer schon produktiv eingesetzt, und das zudem in so großer Anzahl, dass sich die zu deren Anbindung erforderliche Assemblerprogrammierung in der Tiobe-Statistik niederschlagen würde?
Peter S. schrieb: > das ist nicht > programmieren in Assembler. Das sowieso nicht aber tatsächlich macht IAR aus beispielsweise dem C Code zuerst ein Assemblercode dann folgt der Linker usw. Auch wenn man sich den Code nicht Speichern oder ausdrucken lässt, geht IAR von "C" den weg über den Assembler.
Patrick L. schrieb: > aber tatsächlich macht IAR aus beispielsweise dem C Code zuerst ein > Assemblercode Die meisten Compiler machen das, denn sonst ist es unheimlich schwer, Compilerfehler zu finden.
Andreas B. schrieb: > Den Tiny 10 Mal ganz abgesehen davon, ob einen die Performancefrage zu ASM zwingt...... Je kleiner das "Ding" desto eher ASM Bei den großen gibts Alternativen. Unter der Annahme, dass sich die Anzahl der professionellen Programmierer in den letzten 10 Jahren kaum verändert und die Anzahl der Arduino User sich stark erhöht hat, sehe ich diesen Anwachs nicht in der C++ Linie. An der Sprachliste sieht man deutlich, dass da nicht, oder nicht nur, der µC Bereich abgedekt wird. Somit die ganze Statistik auch recht wertlos ist, wenn man den µC Bereich im Blick hat. Und, wo sind wie hier? Mikrocontroller.net! C und C++ sind wohl die Sprachen, welche am ehesten an die ASM Performace ran kommen, sich aber durch ihre viel höhere Portabilität auszeichenen. Dass sich viele Leute für ASM interessieren, ok, mag sein, z.B. beim Debuggen oder Ausbildung. Aber dass sich das in der Anzahl der Projekte oder Produktentwicklungen genau so abbilder, das kann ich nicht glauben.
Minus M. schrieb: > Dass sich viele Leute für ASM interessieren, ok, mag sein, z.B. beim > Debuggen oder Ausbildung. Aber dass sich das in der Anzahl der Projekte > oder Produktentwicklungen genau so abbilder, das kann ich nicht glauben. Da binn ich ganz bei dir. Wie schon erwähnt käme ich auch nicht auf die Idee für ein Kleinen MSP mit 512 Byte Flash oder OTP ein C Code zu schreiben. Genauso wenig käme ich aber auf die Idee, für ein x Core ARM ein Assemblercode zu schreiben. Ja ich habe auch schon für V20/V50/ oder 486 oder Pentium II usw. Assemblecode geschrieben, einfach weil es so das beste war. Und zu 6502 und 65816 Zeiten sogar komplette Betriebssysteme in Assembler geschrieben. Ganz zu schweigen in den frühen Jahren noch SC/MP oder 4004 oft sogar echt Handassembliert. Oder ja der Liebe ZX81 da schwirren mir Heute noch die Mnemonics im Kopf rum während ich das hier schreibe, so ED$ B0$ = LDIR oder C9$ = ret usw. Aber ich würde nicht im Traum auf die Idee kommen, ein Assemblercode für ein Multicor ARM µC zu schreiben. Selbst der MSP432 ist in Assembler schon Grenz-wertig. Da greife selbst ich, als oft verpönter Assemblerfreak gern zu Hochsprachen. Den es ist einfach bei einer gewisser Komplexität zu Aufwendig und Zeitraubend.
Beitrag #6939095 wurde von einem Moderator gelöscht.
Lothar M. schrieb: > Patrick L. schrieb: >> aber tatsächlich macht IAR aus beispielsweise dem C Code zuerst ein >> Assemblercode > Die meisten Compiler machen das, denn sonst ist es unheimlich schwer, > Compilerfehler zu finden. Was ist der Unterschied? Assemblercode sollte unzweideutig dem Maschinencode entsprechen. Und umgekehrt. Es ist nur eine andere Darstellungsform. Oder sehe ich das falsch?
Cyblord -. schrieb: > Es ist nur eine andere > Darstellungsform. Das schon, aber es ist halt einfacher, einen Sprung zu einem Label zu überprüfen als eine relative Adresse auszurechnen.
Beitrag #6939125 wurde von einem Moderator gelöscht.
Beitrag #6939159 wurde von einem Moderator gelöscht.
Beitrag #6939163 wurde von einem Moderator gelöscht.
Beitrag #6939164 wurde von einem Moderator gelöscht.
Beitrag #6939165 wurde von einem Moderator gelöscht.
Beitrag #6939169 wurde von einem Moderator gelöscht.
Beitrag #6939170 wurde von einem Moderator gelöscht.
Beitrag #6939172 wurde von einem Moderator gelöscht.
Zurück zum Tema: Cyblord -. schrieb: > Was ist der Unterschied? Assemblercode sollte unzweideutig dem > Maschinencode entsprechen. Nicht Unbedingt, Oft sind Assembler Befehle auch Mehrere MC Befehle. Es gibt sogenannte Pseudo Befehle, oder auch Emulierte befehle. Fakt ist das in mehreren Compiler (IAR nochmals als Beispiel genannt), tatsächlich zuerst ein Assemblercode Generiert wird und der dann Assembliert wird und definitiv nicht direkt ein MC Code generiert bzw. kompiliert wird. und da ist IAR lange nicht der einzige.
Beitrag #6939174 wurde von einem Moderator gelöscht.
Beitrag #6939175 wurde von einem Moderator gelöscht.
Beitrag #6939176 wurde von einem Moderator gelöscht.
Beitrag #6939177 wurde von einem Moderator gelöscht.
Beitrag #6939178 wurde von einem Moderator gelöscht.
Beitrag #6939183 wurde von einem Moderator gelöscht.
Cyblord -. schrieb: > Was ist der Unterschied Ein signifikanter Unterschied ist, dass beim Maschinencode keinerlei Registernamen, Sprungmarken oder Arrays zu erkennen sind. Oder was steht da: AC12AD13AE10AF1112002F8E0E8F0F2244 A50B250DF509E50A350CF5081200132259 0C002300787FE4F6D8FD7581130200031D EFF88DF0A4FFEDC5F0CEA42EFEEC88F016 4003F00A42EFE22CB00000001FFEB543F6 Ist das ein Programm oder ein Icon für ein Display? Wenn es ein Programm ist: was macht es? > Es ist nur eine andere Darstellungsform. Oder sehe ich das falsch? Schon, aber dem Maschinencode fehlt jede Abstraktion, die den Assemblercode so lesbar macht. Oder anders: wenn es "nur" eine andere Darstellung wäre, dann könnte man aus den obigen Hexzahlen einfach Buchstaben für Buchstaben den ursprünglichen Assemblercode wieder herstellen. Das geht aber eben nicht, weil die originalen Namen verloren gegangen sind. Patrick L. schrieb: > Oft sind Assembler Befehle auch Mehrere MC Befehle. Das wären dann ein Makros. So ein Code wird von Compilern eher selten erzeugt. > Es gibt sogenannte Pseudo Befehle, oder auch Emulierte befehle. Es gibt Befehle, wie z.B. "clr R0", der im Maschinencode tatsächlich als "xor R0, R0" umgesetzt wird.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Patrick L. schrieb: > >> Oft sind Assembler Befehle auch Mehrere MC Befehle. > > Das wären dann ein Makros. So ein Code wird von Compilern eher selten > erzeugt. Beispiel dafür: https://www.keil.com/support/man/docs/armasm/armasm_dom1359731146992.htm
(prx) A. K. schrieb: > Beispiel dafür: Die Überschrift dort ist "Writing Assembly Language". Das hört sich nach handgeschriebenem Code an. Die Frage ist aber, ob der Compiler tatsächlich einen MOV32 Befehl erzeugt, der dann vom Assembler reloziert wird, oder ob der nicht gleich die MOV-MOVT Sequenz aus dem C-Code macht.
Es gibt einen weiteren Grenzfall in ARM Thumb, der ganz sicher von Compilern genutzt wird. Dieser Befehlssatz hat nur 16 Bit breite Befehle. Mit einer Ausnahme, dem in 32 Bits codierten BL Befehl. Aber wenn man dessen Codierung betrachtet, könnte man glatt denken, das wären eigentlich zwei 16-Bit Befehle, um einfachen Implementierungen den Ablauf zu erleichtern.
:
Bearbeitet durch User
Hi Schöne,aber überflüssige Diskussion. Assembler hat wie Basic,Pascal,C, und was es sonst noch an Sprachen gibt, seine Daseinsberechtigung. Ob man Assembler unbedingt lernen muss, nö. Genauso wenig wie man C, Basic oder sonstwas lernen muss. Diejenigen,die das Mal gelernt haben und noch nutzen, werden wohl wissen, warum. Ich nehme Assembler, weil auf Controllerebene kleine Programme ganz gut umgesetzt werden können, vorausgesetzt keine umfangreiche Mathematik. Aber selbst das wäre nicht unlösbar, wenn man denn endlich die Basis 2 so selbstverständlich wie die Basis 10 verstehen würde. Ach ja, noch was falls ihr mich zu C belehren wollt, ich kann kein C. Und zum Lernen hab ich keine Lust. Mir reichen die Hochsprachen, die ich auf PC Ebene brauche. Also, Last dem Radfahrer sein Radl und dem Formel 1 Fan seinen Boliden. Die Welt funktioniert, weil sie vielfältig ist, bunt und nicht schwarzweiß. Hi Gruß oldmax
Peter S. schrieb: > Das sind keine Statistiker, das sind BWLer und Marketingleute. > Statistiken kann man auch nicht wirklich beeinflussen, aber man kann die > Datenbasis falsch interpretieren, aber eben das macht dann nicht der > Statistiker. Sehr beliebt ist auch das Verfahren, mehrere Erhebungen durchzuführen und nach Auswertung jeweils das genehmste Ergebnis bekannt zu geben. Bei der Volksbefragung zur Hamburgischen Olympiabewerbung wurden alle paar Tage neue Umfrageergebnisse veröffentlicht, die zunächst breite Zustimmung vermuten ließen, dann aber immer weiter einbrachen. Bekanntlich fiel die Vorlage schlussendlich durch. Auffällig war gewesen, dass keine zwei Prognosen von dem selben Institut stammten und es sich jeweils keineswegs um eines der bekannten Institute handelte. Wie viele Umfragen jeweils parallel durchgeführt worden waren, blieb Gegenstand der Spekulation, da hierzu soweit ersichtlich nichts veröffentlicht wurde.
Ich finde gut, dass man Assembler Fragmente leicht in C einbetten kann. So habe ich das sichere Gefühl, im Notfall an den Einschränkungen des Compilers vorbei arbeiten zu können, wenn es denn mal sein muss. Gebraucht habe ich es in 30 Jahren nicht einmal, dennoch fühle ich mich mit diesem Ass im Ärmel wohler. Ich habe ganz am Anfang unterschiedliche Computer und Mikrocontroller ein bisschen in Assembler programmiert (z.B. ein Modell einer Getränke-Abfüll-Anlage mit C64 und eine Düsseldorfer Rheinturm-Uhr auf 8051). Bis heute bin ich der Meinung, dass das sinnvoll war, weil ich dabei einiges über die Funktionsweise von Mikrocomputern gelernt habe. Ich glaube, dieses Wissen nützt mir sogar heute noch, wenn ich in Java Payment Systeme programmiere. Denn ich habe bei jeder Code-Zeile ein Gefühl dafür, wie aufwändig deren Ausführung ist. Ich bemerke bei anderen Kollegen, dass sie oft keinen blassen Schimmer zu den "Kosten" ihrer Codes haben. Unsere Server haben zwar reichlich Leistung und Speicher, aber wenn sie 1000 User gleichzeitig bedienen, dann spielt Effizienz an einigen Stellen doch eine wichtige Rolle. Das kann man nicht mit einer Desktop Anwendung vergleichen, die nur einen einzigen User zeitnah bedienen muss. In die Breite skalieren ist nicht ohne weitere Aufwände möglich, zudem wollen wir doch alle Energie sparen, oder? Ich denke, auch die Smartphone Entwickler würden von Assembler Kenntnissen profitieren, selbst wenn sie die Smartphones nie in Assembler programmieren. Smartphones haben zwar inzwischen auch Leistung und Speicher ohne Ende, aber der Strom aus den Akkus bleibt knapp. Keiner will eine App nutzen, die den Akku innerhalb einer Stunde leer saugt.
Michael schrieb: > Lothar M. schrieb: >> Dieter schrieb: >>> Das Interessante steckt in den Gewichtungsfunktionen, die sich dahinter >>> verbergen. >> Ja, das ist auch eine Möglichkeit, das Ergebnis einer Statistik >> irgendwie zu beeinflussen. > Mir hat man mal erklärt dass Statistiker Ergebnisse so beeinflussen > können wie es der Auftraggeber wünscht, ohne dabei Falschangaben zu > machen. Ich war mal vor Jahren in einer Bürgerinitiative und da kamen die Fachleute mit vielen Statistiken und Vorträgen um die Leute zu überzeugen. Ich habe damals ein recht einfaches Programm geschrieben das deren Daten verwendet und die Gewichtungen variiert hat. Damit konnte man das gewünschte Ergebnis eingeben und bekam es genauso schön präsentiert zurück. Solche Fachleute schönen auch gerne die Diagramme durch 0-Punkt Verschiebung und solche Scherze. Wenn du zwei Werte (120,110) als Balken nebeneinander malst sieht der Unterschied zwischen den beiden doch gleich viel imposanter aus wenn du das Diagramm bei 100 beginnen lässt und nicht bei 0. Zum Thema: Ich benutze Assembler wenn ich Start Code schreiben muss, sonst nicht.
:
Bearbeitet durch User
Assembler programmieren ist wie Kreuzworträtsel lösen - kann Spaß machen, aber bringt dich nicht wirklich weiter... Stefan ⛄ F. schrieb: > Ich denke, auch die Smartphone Entwickler würden von Assembler > Kenntnissen profitieren, Smartphone-Apps werden in ganz anderen Dimensionen gemessen. Viel wichtiger als die Optimierung einzelner Codezeilen ist es, die allgemeinen Abläufe zu verschlanken, also z.B. nicht jede Menge Timer laufen lassen, nicht ständig HTTP-Abfragen zu senden, Daten zwischenzuhalten, bei der Grafik Hardwarebeschleunigung aktivieren, und insbesondere dafür sorgen dass die CPU nicht ständig aufgeweckt wird. Letztlich also seltener überhaupt etwas ausführen - wenn man es dann ausführt, ist es relativ egal wie effizient es ist. Assembler-Kenntnisse sind hier kaum nützlich, dazu sollte man eher etwas über Datenstrukturen, Abläufe und natürlich das verwendete Framework/API wissen; insbesondere bei Android ist der Application Lifecycle und die asynchrone Denkweise recht unintuitiv. Wenn man sich eine App vorstellt, die nicht dynamisch online Daten lädt und auch nicht gerade riesige Datenmengen verarbeitet, dann wird die prinzipbedingt schon ziemlich gut laufen, Optimierungen bringen dann kaum spürbaren Vorteil. Erst wenn dynamische Daten hinzukommen (was natürlich bei sehr vielen Apps der Fall ist) gibt es oft viel Optimierungspotenzial. Ein Gegenbeispiel sind Multimedia-Inhalte - Videodekodierung wird vom handoptimierten nativen Libraries im Framework gemacht und ist natürlich auch Hardware-Beschleunigt. Auf Anwendungsebene gibt es da aber auch nicht viel zu tun. Interessant ist, dass es Social Media-Apps gibt, die so miserabel umgesetzt sind, dass sie doppelt so viel Energie verbrauchen wie YouTube schauen, obwohl so ein Videostream eine Menge Rechenleistung braucht - einfach nur weil die betreffende App ständig alle Inhalte per HTTP nachlädt und sich in ihren asynchronen Abläufen verheddert.
Lothar M. schrieb: > Ja, das ist auch eine Möglichkeit, das Ergebnis einer Statistik > irgendwie zu beeinflussen. Winston Churchill sagte: "Ich glaube nur der Statistik, die ich selbst gefälscht habe" :-)
Andreas B. schrieb: > Cyblord -. schrieb: >> Es ist nur eine andere >> Darstellungsform. > > Das schon, aber es ist halt einfacher, einen Sprung zu einem Label zu > überprüfen als eine relative Adresse auszurechnen. Genau das. In Assembler gibt es Labels, im Maschinencode nicht. Der Assembler kompiliert im Grunde Adressen. nur die Mnemonics sind mehr oder weniger 1 zu 1. Werte kann ein Assembler normalerweise auch übersetzen, also er akzeptiert Dezimal-, Binär-, Hexadezimalschreibweisen und Zeichen(ketten). Dazu kommen noch Befehle zur Speicherstrukturierung.
Niklas G. schrieb: > Assembler programmieren ist wie Kreuzworträtsel lösen - kann Spaß > machen, aber bringt dich nicht wirklich weiter... Kann ich so nicht stehen lassen Sorry! Unser Betrieb hat Unsummen für "C" Programmierer ausgegeben um Effiziente Lösungen herbeizuschaffen mit dem Erfolg, dass heute noch immer alles im Kleinsektor mit Hohen Stückzahlen in Assembler geschrieben wird. Assembler kann und darf mann nicht ein Nieschendasein zusprechen, den es gibt immer Situationen wo der Assembler "C" überlegen ist. Wie gesagt, würde mir nie in den Sinn kommen Umfangreiche APP's mit Datenbank und Grafikfunktionen in Assembler zu Schreiben (lassen) da haben Hochsprachen ihr klaren Vorteil. Genausowenig würde ich aber niemals dort wo es wegen großen Stückzahlen drauf ankommt etwas in "C" schreiben (lassen) weil da die Performance und die möglichst platzsparende Variante (Nein nicht einfach den nächst "größeren" nehmen) in "C" den Aufwand Qudratiert, weil dan extrem viiel Aufwand in die Optimierung der Hochsprache investiert werden muss, mit dem Erfolg dass es dan doch nicht im kleineren µC Platz hat. Oder auch oft im Nachhinein plötzlich Timing Probleme, oder Stackoverflow hervorruft usw. Ich kenne beispielsweise kein "C" Kompiler der auf die Idee kommt nicht verwendete Pheripherie in µC's als Speicher zu verwenden (Nur als Beispiel und nicht zur Diskussion) was aber in Assembler gang und gebe ist. Oder aber gewisse Programmteile Platzbedinngt im FLASH oder ROM oder FRAM Komprimiert hält und zur Verwendung dann ins RAM entpackt. Hochsprachen sind Maschienen und können nicht selbstständig Denken wenn sie Kompilieren und den Assembler Code daraus erzeugen. Ein Mensch mit Hirn aber schon!
:
Bearbeitet durch User
Dieter schrieb: > Erreicht Assembler nun Rang 8 mit 1.85% und einem Zuwachs von +0.21%. Schön für dich.
Lothar M. schrieb: > zur Ermittlung > der Zahlen dient im Grunde, wie oft das Wort "Assembler" in Google > eingegeben wurde: Daraus könnte man auch rückschliessen, das Assembler so undurchschaubar ist, das man ständig googlen muss :-) Mit Popularität hat das m.M.n. nicht so viel zu tun, eher damit, das jemand ständig googlet, weil er es nicht kapiert. Für mich jedenfalls sind die Zeiten vorbei. Gut, wenn es sich um ein Tiny Projekt in einem Tiny MC handelt, würde ich notfalls nochmal drauf zurückfallen, aber kein Assembler war so schön wie beim MCS51. Da habe ich auch komplexere Dinge programmiert wie Satellitenempfänger oder Einzelbild Maschine aus einem V2000 Rekorder. Aber muss man heute ja nicht mehr. Mein letztes Assembler Projekt war die Anpassung von Basic-52 auf die PS2 SPS von Kloeckner Moeller.
:
Bearbeitet durch User
Patrick L. schrieb: > Ich kenne beispielsweise kein "C" Kompiler der auf die Idee kommt nicht > verwendete Pheripherie in µC's als Speicher zu verwenden (Nur als > Beispiel und nicht zur Diskussion) was aber in Assembler gang und gebe > ist. Das macht der Assembler aber auch nicht automatisch. Dem C-Compiler kann man das genau so beibringen, indem man z.B. im Linker-Script einen Speicherbereich in die Peripherie-Blöcke hinein mappt. Patrick L. schrieb: > Oder aber gewisse Programmteile Platzbedinngt im FLASH oder ROM oder > FRAM Komprimiert hält und zur Verwendung dann ins RAM entpackt. Genau das macht aber der IAR-ARM C Compiler mit den Initialisierungsdaten... Und was für eine Rolle spielt hier die Programmiersprache? Code als Daten behandeln kann man so ziemlich in allen nativen Sprachen (sogar in Java übrigens - der Java-Code in .jar Dateien ist ja sogar immer komprimiert), egal ob der Code jetzt handgeschrieben oder vom Compiler generiert ist. Ist natürlich nicht portabel.
:
Bearbeitet durch User
Beitrag #6939504 wurde von einem Moderator gelöscht.
Gerhard G. schrieb im Beitrag #6939504: > beweisen die aktuellen Zahlen hin zu diesem Jahr den stabilen Platz von > Assembler in der Top10 der Programmiersprachen- Ist Assembler nicht eher ein Indiz für uC? Jede Stellenanzeige, jeder Artikel hat irgendwie auch Assembler dabei. Aber eher so wie Patina, für's authentische.
Niklas G. schrieb: > Genau das macht aber der IAR-ARM C Compiler mit den > Initialisierungsdaten... Und was für eine Rolle spielt hier die > Programmiersprache? Code als Daten behandeln kann man so ziemlich in > allen nativen Sprachen (sogar in Java übrigens - der Java-Code in .jar > Dateien ist ja sogar immer komprimiert), egal ob der Code jetzt > handgeschrieben oder vom Compiler generiert ist. Ist natürlich nicht > portabel. Jep da hast du ein +1 Verdient habe ich aber auch Explizit schon erwähnt das die ARM da ganz speziell sind und ich da niemals auf die Idee kommen würde Assembler dafür zu schreiben. Hatte da sogar konkret auf den MSP432 Verwiesen. Nochmnals ich bin zwar ein Assembler Freak aber kein Fanatiker. Ja habe ich auch schon Erwähnt, Es gibt zig Situationen wo Hochsprachen dem Assembler Haushoch überlegen sind, einfach weil sie extrem viel Library und Tools haben und nicht zuletzt das "Denken" abnehmen und somit Zeit Verkürzen. Ich unterhalte auch 2 Onlinegame (frage welche werden aus Forrenregelgründen nicht beantwortet) und da wird Phyton, Java. uvA. verwendet und um Himmelswillen kein Assembler, der wäre da so fehl am Platz wie ein Java in einem 512Byt OTP eines µC. Es geht nur darum dass es Falsch ist zu sagen, Zitat: Niklas G. schrieb: > Assembler programmieren ist wie Kreuzworträtsel lösen - kann Spaß > machen, aber bringt dich nicht wirklich weiter... Assembler hat definitiv seine Daseinsberechtigung und macht wenn man in diese Richtung Programmiert auch sinn. Nicht zuletzt dass sehr viele angebliche Assembller Verächter dennoch sich mit dem Assembler Code auseinander-schlagen der von Ihrem über alles erhabene C Kompiler generiert wird. Warum wohl (wurde auch schion Diskutiert) machen sehr viele wenn nicht die Meisten "C" Kompiler ein Assemblercode der danach assembliert wird daraus und nicht Direkt ein Maschienencode? Erstauntlich ist dabei, dass es früher (So Beaggle Brother's und 6502 Zeiten) noch so war, dass der Kompiler direkt den Maschinencode erzeugte, heute aber tatsächlich wieder vermehrt den Weg über Assembler geht. Da kann man noch 100'000 Posts lang drüber Streiten und den Thread zu Tode diskutieren, es ändert nichts an den Tatsachen das es so ist. Assembler und alle Hochsprachen hat jedes seinen Platz und somit seine Daseinsberechtigung. Der eine Schwört auf das und der Andere auf das Andere. Schade dabei ist, nur das schon fast Epileptisch Anfall mäßig, dann das andere versucht wird, zu Tode zu Treten, was dann wieder unsinnige Diskussion und Streitpost's auslöst, die niemandem wirklich was bringen, außer vielleicht dessen persönlichen Befriedigung. Und wenn dann keine Argumente mehr Vorliegen, geht es dann mit den Herren Deutschlehrer und Rechtschreibeprofessoren weiter, einfach um auch noch, ein Paar Tastenschlägen zum besten zu geben. Und dann Kurz bevor der Mod ein Schlösschen an den Thread hängt, geht es noch mit übelsten Beschimpfungen und Beleidigungen los. Aber in der Regel ist dann der Thread eh schon lange zu Tode diskutiert und aus meiner Überwachung raus geflogen, weshalb hier schon einige bemerkt haben dass dann von mir keine Antworten mehr kommen. Da helfe ich dann lieber wieder in einem Anderen Thread jemanden mit Rat und Tat, damit meine eh schon knappe Zeit, sinnvoll eingesetzt wird. Einige hier im Forum sind froh um Hilfe, andere sind halt hier nur um die Zeit, tot zu schlagen. Kurz zum Tema: ob jetzt Assembler Platz 8 hat und "C" den Platz 4 ist doch so was von Egal. Jeder soll das Verwenden was er als Optimum empfindet, den dann ist es auch Optimal führ Ihn. Genau wie es sinnlos ist einem Kind den Haferschleimbrei hinzustellen und Dessert vom Feinsten zu verkaufen. Genau so wird der verbissene Programmschreiber, sich höchstens darüber aufregen und niemals Effizient auf eine andere Sprache wechseln. Widerwille und Anschiss (oft auch L.m.a.A. genannt) ist der schlimmste Feind des Programmierers. 73 55
:
Bearbeitet durch User
Dieter schrieb: > Erreicht Assembler nun Rang 8 mit 1.85% und einem Zuwachs von +0.21%. Wow... Und das für alle Assembler zusammen! (Denn der Profi weiß, dass es "den" Assembler gar nicht gibt - im Gegensatz zu C oder Python) Na, wenn DAS mal nicht eine Erfolgsgeschichte ist, dann weiß ich auch nicht... > Zum Warum: Ich nehme an, Belege für Dein Geschwurbel reichst Du noch nach - oder dürfen wir Deinen Beitrag in der Ablage B (für "Blödsinn") verbuchen?
Patrick L. schrieb: > habe ich aber auch Explizit schon erwähnt > das die ARM da ganz speziell sind und ich da niemals auf die Idee > kommen würde Assembler dafür zu schreiben. ARM-Assembler ist gar nicht so schlimm: ARM-ASM-Tutorial Weil es eben 32bit ist, werden Adressberechnungen & Co schön einfach (für Arrays & Structs).
Niklas G. schrieb: > ARM-Assembler ist gar nicht so schlimm Der vom Sharc DSP ist auch ganz nett:
1 | log_score:
|
2 | i_reg=logs_data; /*Point to data array*/ |
3 | R11=R11+1; /*Increment exponent*/ |
4 | R7=-R11, F10=mem(i_reg,1); /*Negate exponent*/ |
5 | F12=SCALB F12 BY R7; /*F12= .5<=f<1*/ |
6 | COMP(F12,F10), F10=mem(i_reg,1); /*Compare f > C0*/ |
7 | IF GT JUMP adjust_z (DB); |
8 | F7=F12-F10; /*znum = f-.5*/ |
9 | F8=F7*F10; /*znum * .5*/ |
10 | JUMP compute_r (DB); |
11 | F12=F8+F10; /*zden = znum * .5 + .5*/ |
12 | R11=R11-1; /*N = N - 1*/ |
13 | adjust_z: |
14 | F7=F7-F10; /*znum = f - .5 - .5*/ |
15 | F8=F12*F10; /*f * .5*/ |
16 | F12=F8+F10; /*zden = f * .5 + .5*/ |
(aus dem auf https://dsp-sys.de/allgemeine-informationen verlinkten Applications Handbook) Horst G. schrieb: > Und das für alle Assembler zusammen! Ja, aber eben auch für alle Suchanfragen nach "C" und "Python" und sonstwas zusammen. An dieser Stelle liegt nicht der eigentliche Schwachpunkt der Statistik.
:
Bearbeitet durch Moderator
Dieter schrieb: > Auf dem Index von Januar 2022 von Tiobe: > > https://www.tiobe.com/tiobe-index/ > https://www.tiobe.com/tiobe-index/assembly-language/ > > Erreicht Assembler nun Rang 8 mit 1.85% und einem Zuwachs von +0.21%. Er dümpelt seit Beginn unter der 3% Marke herum und der Wahnsinns Zuwachs ist der zwischen den beiden gelben Punkten. Gib mal "Assembler" als Suchbegriff in die Suchmaschine deiner Wahl ein oder suche danach in Github oder so. Dann zähl mal nur die Seiten die echten Assembler Projekt Code referenzieren dann wirst du eine völlig andere Statistik bekommen. Gilt sicher auch für alle anderen Sprachen. Assembler hat seine Berechtigung und man braucht ihn, aber die üblichen Argumente, die hier immer angeführt werden, langweilen mich.
Lothar M. schrieb: > Der vom Sharc DSP ist auch ganz nett: Ich habe das mal lernen müssen: https://en.m.wikibooks.org/wiki/360_Assembly/360_Instructions Allerdings nie gebraucht. ;-)
Beitrag #6939664 wurde von einem Moderator gelöscht.
Yalu X. schrieb: > Content B. schrieb: >> Interessant warum dieser Post nicht gelöscht wird > > Das Löschen hat nichts mit dem Thema zu tun, sondern mit der Person, die > hier Hausverbot hat. Der, dessen Name nicht genannt werden darf.
Beitrag #6939690 wurde von einem Moderator gelöscht.
Andreas B. schrieb: > Ich habe das mal lernen müssen: > https://en.m.wikibooks.org/wiki/360_Assembly/360_Instructions > Allerdings nie gebraucht. ;-) Ja, da gibt/gab es schon einige Blüten..... Eine etwas seltsame Pflanze waren die Kessel von DataGeneral. Mit meist AOS/VS als Betriebssystem. Aber auch durchaus noch weiteren OS, wie MV/UX. Mit als erste Aktion wurde von einem Hilfspozessor (anfangs V20, später 80286) ein Domain spezifischer Microcode von der Platte, oder Band, geladen und damit der Hauptprozessor lauffähig gemacht. Für diesen Hauptprozessor gab es dann konsequenter Weise verschiedene Assembler, je nach OS und Microcode. War schon ein Kreuz mit den Dingern .... Mein Hauptarbeitsgebiet zu der Zeit war die Treibererstellung bei einem Hersteller von Spezialhardware für eben die DG MV Reihe und auch PC ROM-Bioserweiterungen. Fast ausschließlich Assembler. Ehr nervig, als schön.
Minus M. schrieb: > Mit als erste Aktion wurde von einem Hilfspozessor (anfangs V20, später > 80286) ein Domain spezifischer Microcode von der Platte, oder Band, > geladen und damit der Hauptprozessor lauffähig gemacht. Das war und ist bei grösseren Rechnern weit verbreitet. Auch bei den ersten VAXen startete zunächst eine eingebaute PDP-11 und präparierte sie. Von aktuellen Intel-Prozessoren wird berichtet, dass ein interner Quark mit der berüchtigten Management Engine benötigt wird, um den Hauptprozessor hochzufahren. Abgeschaltet werden kann sie demgemäss allenfalls danach.
:
Bearbeitet durch User
Niklas G. schrieb: > werden Adressberechnungen & Co schön einfach > (für Arrays & Structs). O.T.: ich weiß noch vor 25 Jahren etwa, wie ich meinem Studienkollege erzählte, dass mein µC tolle Adressierungen haben. Direct, indirect, indexed X. Und er so ... ja, hat seiner auch (ich glaube 6502 oder so) ... Bis mir nach einiger Zeit klar wurde, dass er bei meiner Aufzählung Kommas rausgehört hatte.
Beitrag #6939891 wurde von einem Moderator gelöscht.
Beitrag #6939936 wurde von einem Moderator gelöscht.
eine abstruse Statistik. Horst G. schrieb: > Wow... Und das für alle Assembler zusammen! (Denn der Profi weiß, > dass es "den" Assembler gar nicht gibt - im Gegensatz zu C oder Python) > Na, wenn DAS mal nicht eine Erfolgsgeschichte ist, dann weiß ich auch > nicht... Ich bin zwar kein Profi, habe aber aber sicher in über 15 unterschiedlichen Assemblersprachen erfolgreich programmiert; muß ich aber nicht mehr dank ...Algol,Fortran, Basic, Forth, Pascal, c, c++...etc.
:
Bearbeitet durch User
Beitrag #6940006 wurde von einem Moderator gelöscht.
Beitrag #6940013 wurde von einem Moderator gelöscht.
Beitrag #6940053 wurde von einem Moderator gelöscht.
Beitrag #6940087 wurde von einem Moderator gelöscht.
Patrick L. schrieb: > Ich kenne beispielsweise kein "C" Kompiler der auf die Idee kommt nicht > verwendete Pheripherie in µC's als Speicher zu verwenden (Nur als > Beispiel und nicht zur Diskussion) was aber in Assembler gang und gebe > ist. Ja - das ist auch extrem wichtig. Ich habe nichts gegen Assembler - manchmal ist es hilfreich (weil schneller) aber eher selten - nur in extrem zeitkritischen Fällen. Wenn mir ein MC zu langsam ist nehme ich halt einen anderen (als Laie - ein Profi mag aus Kostengründen anders entscheiden).
:
Bearbeitet durch User
Patrick L. schrieb: > Ich kenne beispielsweise kein "C" Kompiler der auf die Idee kommt nicht > verwendete Pheripherie in µC's als Speicher zu verwenden (Nur als > Beispiel und nicht zur Diskussion) was aber in Assembler gang und gebe > ist. Das ist in C genauso einfach oder schwierig wie in Assembler. Und nein, ein Assembler macht das auch nicht selber.
Finn Z. schrieb im Beitrag #6940087: > Es ist ja auch kein Wunder: Gerade bei den kleineren Controllern und im > wachsenden 8Bit Markt ist ASM oft die beste Sprache der Wahl. Wovon träumst Du nachts?
Beitrag #6940137 wurde von einem Moderator gelöscht.
Beitrag #6940154 wurde von einem Moderator gelöscht.
Beitrag #6940157 wurde von einem Moderator gelöscht.
Beitrag #6940170 wurde von einem Moderator gelöscht.
Beitrag #6940220 wurde von einem Moderator gelöscht.
Beitrag #6940232 wurde von einem Moderator gelöscht.
Beitrag #6940429 wurde von einem Moderator gelöscht.
Beitrag #6940456 wurde von einem Moderator gelöscht.
Beitrag #6940510 wurde von einem Moderator gelöscht.
Beitrag #6940525 wurde von einem Moderator gelöscht.
Beitrag #6940527 wurde von einem Moderator gelöscht.
Beitrag #6940551 wurde von einem Moderator gelöscht.
Hans-Georg L. schrieb: > Solche Fachleute schönen auch gerne die Diagramme > durch 0-Punkt Verschiebung und solche Scherze. Wenn du zwei Werte > (120,110) als Balken nebeneinander malst sieht der Unterschied zwischen > den beiden doch gleich viel imposanter aus wenn du das Diagramm bei 100 > beginnen lässt und nicht bei 0. Ein ähnlicher sehr einfacher Trick ist, bei prozentualen Angaben die Basis geschickt zu wählen. Also "a liegt 50% über b" vs. "b ist um 33% geringer als a". Sagt beides das gleiche aus, aber wirkt auf den Leser anders. Hugo H. schrieb: > Winston Churchill sagte: "Ich glaube nur der Statistik, die ich selbst > gefälscht habe" :-) Tatsächlich soll Churchill das nie gesagt haben. Das erkennt man auch schon daran, dass es keine einheitliche englische Version dieses Spruchs gibt und dass dieser eigentlich nur im Deutschen überhaupt verbreitet ist. Vielmehr soll Goebbels das Churchill in den Mund gelegt haben. Patrick L. schrieb: > Oder aber gewisse Programmteile Platzbedinngt im FLASH oder ROM oder > FRAM Komprimiert hält und zur Verwendung dann ins RAM entpackt. Kannst du mir denn einen Assembler nennen, der das für dich macht? Von Hand könnte man das schließlich auch in C machen. Niklas G. schrieb: > ARM-Assembler ist gar nicht so schlimm: ARM-ASM-Tutorial > > Weil es eben 32bit ist, werden Adressberechnungen & Co schön einfach > (für Arrays & Structs). Allerdings gibt es keine 32-Bit-Immediates, weil dafür in den Instruktionen kein Platz ist.
Rolf M. schrieb: > Allerdings gibt es keine 32-Bit-Immediates, weil dafür in den > Instruktionen kein Platz ist. Stimmt, aber der Assembler unterstützt die Pseudo-Instruktion "ldr rX, =0x12345678" welche den Wert als separate Konstante ablegt und dann von da lädt. Alternativ gibt es noch die mov32-Instruktion, welche in eine Kombination aus mov und movt übersetzt wird. Das erscheint zwar etwas umständlich, ist aber für die Effizienz ein guter Kompromiss und dank Pseudo-Instruktion ist es eben auch einfach zu nutzen.
Rolf M. schrieb: >> Weil es eben 32bit ist, werden Adressberechnungen & Co schön einfach >> (für Arrays & Structs). > > Allerdings gibt es keine 32-Bit-Immediates, weil dafür in den > Instruktionen kein Platz ist. Das gilt generell für RISC mit festem Befehlsformat. Umgang mit Konstanten und Adressen kann umständlicher sein als bei CISC. Wobei auch x86-64 weitgehend auf volle Breite von 64 Bit verzichtet, weil zu verschwenderisch und zu selten nötig.
Yalu X. schrieb: > Wie sieht denn eine typische Anbindung eines Quantencomputers an einen > Mikrocontroller bzgl. der Hardwareschnittstelle und des > Kommunikationsprotokolls aus? Hast du da einschlägige Erfahrungen? Man wartet noch auf Antworten :)
Urs H. schrieb: > Man wartet noch auf Antworten :) Oder weiss noch nicht, welche der vielen Antworten die richtige ist. :)
Beitrag #6940601 wurde von einem Moderator gelöscht.
Patrick L. schrieb: > Ich kenne beispielsweise kein "C" Kompiler der auf die Idee kommt nicht > verwendete Pheripherie in µC's als Speicher zu verwenden (Nur als > Beispiel und nicht zur Diskussion) was aber in Assembler gang und gebe > ist. Nur speziell bei Dir, aber nicht generell. Sowohl in C als auch in Assembler muß sich der Programmierer selber die Mühe machen. Und der entscheidet sich in der Regel für die Bequemlichkeit, d.h. dagegen. In den AVRs wurden dafür extra die GPIOR2..0 implementiert. Ich habe sie unter Assembler nie benutzt. Ich habe das GPIOR0 mal in C-Programmen benutzt, um zu unterscheiden, ob eine echter Reset erfolgte oder nur ein wildgewordener Pointer über den Resetvektor in das Init und dann ins Main lief. Ein echter Reset schreibt dort 0x00 rein, während der SRAM unverändert bleibt.
Peter D. schrieb: > In den AVRs wurden dafür extra die GPIOR2..0 implementiert. Ich habe sie > unter Assembler nie benutzt. Ein Fehler. Optimal für schnell abfragbare, global-binäre Status-Infos.
:
Bearbeitet durch User
Urs H. schrieb: > Ein Fehler. Ein Fehler ist es nur, wenn die konventionelle Alternative zum Problem wird.
Urs H. schrieb: > Peter D. schrieb: >> In den AVRs wurden dafür extra die GPIOR2..0 implementiert. Ich habe sie >> unter Assembler nie benutzt. > > Ein Fehler. Nö. Der winzige Mehrverbrauch an Flash und Zeit ist für den Benutzer komplett unsichtbar. Die Funktion bleibt auch die selbe. Daher kein Fehler.
Beitrag #6940619 wurde von einem Moderator gelöscht.
Urs H. schrieb: > (prx) A. K. schrieb: >> die konventionelle Alternative > > die da wäre? Gewöhnliche Variablen in gewöhnlichem RAM. GPIORx hat Vorteile, weil kürzer und atomar, aber das muss nicht immer ein Problem sein, und hat den Nachteil, dass es nicht portabel ist.
:
Bearbeitet durch User
(prx) A. K. schrieb: > GPIORx hat Vorteile Eben. Deshalb nutzt man sowas. Schlechtere Alternativen (mit SRAM-Verbrauch, mehr Flash, mehr Cycles) gibt es immer :)
Nery L. schrieb im Beitrag #6940619: > Es ist ja auch kein Wunder: Gerade bei den kleineren Controllern und im > wachsenden 8Bit Markt ist ASM oft die beste Sprache der Wahl. Naja, den uralten ATtiny12 mit Hardwarestack und ohne SRAM wird wohl keiner mehr für neue Projekte einsetzen. Der Nachfolger ATtiny25 läßt sich wunderbar und super bequem in C programmieren.
Urs H. schrieb: > Eben. Deshalb nutzt man sowas. In der IT nennt man sowas "vendor lock-in" oder "walled garden" ;-). Wobei das sogar in Assembler innerhalb einer Architektur nicht portabel ist, weils die GPIORx nicht bei jedem AVR gibt. Der Rest ist dann Sache des persönlichen Umgangs mit diesem Effekt. Der vielleicht davon geprägt sein kann, sich im Laufe der Zeit mit beliebig vielen Plattformen beschäftigt zu haben. > mit SRAM-Verbrauch, mehr Flash, mehr Cycles Hast du schon mal bei Atmel/Microchip oder dem Händler nachgefragt, wieviel Geld es retour gibt, wenn du Ressourcen ungenutzt lässt? ;-)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Hast du schon mal bei Atmel/Microchip oder dem Händler nachgefragt, > wieviel Geld es retour gibt, wenn du Ressourcen ungenutzt lässt? Je weniger RAM ich belege, umso geringer ist die Wahrscheinlichkeit eines Ausfalls durch Stack/Heap Überlauf. Das ist einfacher zu sagen als: Je weniger ich schlampe, umso zuverlässiger läuft mein Produkt.
Und je weniger Aufwand du in modellspezifische Anpassungen steckst, desto billiger wirds. :-)
Beitrag #6940641 wurde von einem Moderator gelöscht.
Peter D. schrieb: > Der winzige Mehrverbrauch an Flash und Zeit ist für den Benutzer > komplett unsichtbar. Die Funktion bleibt auch die selbe. Für gewöhnlich bleiben die Details des Programmablaufs dem Nutzer immer verborgen :) (prx) A. K. schrieb: > nicht portabel ist, weils die > GPIORx nicht bei jedem AVR gibt Portabel spielt bei Assembler nicht so die große Rolle. Da ist Peter D. im Vorteil. Halbwegs aktuelle AVRs haben meines Wissens aber alle GPIOR's. Dann kann man sie auch benutzen und muß sie nicht aus bloßer Angst vor Inkompatibilitäten vermeiden. Beim Nutzen spezieller Controller-Features ist der Asm-Programmierer ja oft im Vorteil- schon weil er sich meist genauer für interessiert.
Beitrag #6940650 wurde von einem Moderator gelöscht.
Tja wenn man nicht alles liest. Ich habe nie gesagt dass der Assembler irgend Wass selber macht, sondern ich habe geschrieben das wenn jemand mit Hirn in Assembler Programmiert. Und dass der "C" Kompiler einem das Denke abnimmt, wobei der Kompiler nicht denken kann... Schlussfolgerung könnt ihr selber draus ziehen. Aber das ist halt so mit dem Zitieren, Mann/Frau schneidet sich das aus, was man gerne Lesen möchte und kommentiert es dann entsprechen. Der nächste schneidet sich das dann dort aus und kommentiert es wieder...usw. Macht sich kaum einer die mühe alles zu lesen. Dann entstehen solche Sachen draus: Peter D. schrieb: > Nur speziell bei Dir, aber nicht generell. Und sieht jemand den Zusammenhang? Nein? Ohh schade, habe ich das Zitat wohl versehentlich ein bisschen Falsch interpretiert. So werde ich dann plötzlich als "C" Gegner dargestellt und von den Nachfolger dann entsprechend angelabert. Liest mal richtig und Kommentiert dann auch richtig. Es gibt hier kein Kompiler der euch das abnimmt. Text schreiben ist wie Assembler. Mann muss selber Denken und selber lesen. Der Kompiler ist grob gesehen nichts anderes, als eine Sammlung von vorgefertigten Assemblerfunktionen, die durch den Befehl in der Zeile dann zusammengesetzt wird, je nach Optimierungsoptionen sucht der Kompiler dann noch Doppelte Befehle und fasst die dann wieder zusammen. Optimiert Befehle weg, die als Resultat so nichts zu tun scheinen, und gibt dann dies dem Assembler weiter. Dieser Assembliert dann das was aus dem Kompiler kam, und übergibt es dann dem Linker...usw. Einem Kompiliertem Programm einer Hochsprache sieht man dann dies auch wider an. es tauchen richtige Muster auf. Nochmals für die die nicht lust haben alles zu lesen: Jede Sprache ob Assembler ob "C" oder gar Pascal usw. hat ihre Daseinsberechtigung. Es ist Nicht die Sprache, sondern dass was der Programmierer daraus macht. Denken tut keine Sprache, denken tut der Programmierer. Etwas anderes habe ich nie behauptet. 73 55
:
Bearbeitet durch User
Beitrag #6940660 wurde von einem Moderator gelöscht.
Beitrag #6940664 wurde von einem Moderator gelöscht.
Patrick L. schrieb: > Der Kompiler ist grob gesehen nichts anderes, als eine Sammlung von > vorgefertigten Assemblerfunktionen, die durch den Befehl in der Zeile > dann zusammengesetzt wird, je nach Optimierungsoptionen sucht der > Kompiler dann noch Doppelte Befehle und fasst die dann wieder zusammen. Sorry, aber das ist Quark. Schon seit aberzig Jahren. Je nach Definitioon von "denken" passt der Begriff oder nicht, aber da geschieht weitaus mehr als deine Beschreibung besagt.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Sorry, aber das ist Quark. Schon seit aberzig Jahren. Der Quark wird auch nicht dadurch besser, dass er hier jeden Monat neu erzählt wird. Sogar die Grimms Märchen haben ausgedient. Man kann es übrigens ganz leicht wiederlegen, indem man sich das Assembler Listing von folgendem Code anschaut:
1 | int zahl=12; |
2 | int zehner=zahl/10; |
3 | int einer=zahl%10; |
Die unteren beiden Zeilen werden eindeutig nicht nach dem Baukasten-System zusammen kopiert. Auch nicht wenn man sie tauscht oder was andere dazwischen packt. Die Division wird nur einmal berechnet.
Stefan ⛄ F. schrieb im Beitrag #6940660:
> Sorry, das sollte in einem anderen Thread landen.
Passt doch prima hierher. Die überschüssigen ATtiny13 kannst du Moby für
teuer Geld verkaufen, denn das ist seine Lieblingsplattform. :-))
Beitrag #6940693 wurde von einem Moderator gelöscht.
Beitrag #6940698 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb: > (prx) A. K. schrieb: >> Sorry, aber das ist Quark. Schon seit aberzig Jahren. > > Der Quark wird auch nicht dadurch besser, dass er hier jeden Monat neu > erzählt wird. Sogar die Grimms Märchen haben ausgedient. > > Man kann es übrigens ganz leicht wiederlegen, indem man sich das > Assembler Listing von folgendem Code anschaut: > int zahl=12; > int zehner=zahl/10; > int einer=zahl%10; > > Die unteren beiden Zeilen werden eindeutig nicht nach dem > Baukasten-System zusammen kopiert. Auch nicht wenn man sie tauscht oder > was andere dazwischen packt. Die Division wird nur einmal berechnet. Nein es ist definitiv so und kein Quark (Habe es gerade eben mit dem IAR ausprobiert) Schallte Alle Optimierungen ab und Ohhh was da raus kommt ist ja echt ein schönes wiederholtes Muster..... Es gibt zwar die Firma Cyberdyne, aber sie haben (noch) keinen Terminator gebaut. Ein Computer "Denkt" genau so wenig wie irgend ein Programmierwerkzeug. Denken muss der der das Werkzeug anwendet.
Patrick L. schrieb: > Schallte Alle Optimierungen ab und Ohhh was da raus kommt ist ja echt > ein schönes wiederholtes Muster..... ja klar das gilt aber nicht mehr wenn Optimierungen im Spiel sind. Ich gebe dir aber Recht, jeder Compiler erzeugt Footprints. Mit etwas Erfahrung kann man aus dem Disassembly schon ein paar Dinge ableiten. Dazu ist aber auch ein Background notwendig wie wie ein gegebener C Compiler bestimmte Dinge umsetzt.
Stefan ⛄ F. schrieb: > Das ist albern. Wiso? Es Zeigt dann genau dass die Reihenfolge so ist und eben nicht Quark. Der Kompiler greift auf eine Datenbank von Befehlen zu die irgend ein Programmierer(meist Team) vorgefertigt hat. Holt sich daraus den Assemblerblock mit Hilfe, sagen wir des besseren Verständnisswillen, mit einer Konjugationsphase den Block raus,(Egentlich so wie die Bekannte ELIZA Software) Setzt sie dann zusammen und Optimiert das ganze dann. Der anwender bekommt davon eigentlich nichts mit, und denkt Ohh der Kompiler Denkt ja. Aber nein er Denkt nicht er arbeitet nur ab. Und da kann man nur Mio von Posts drüber Diskutieren es ändert nichts an der Tatsache dass es so ist, Zumindest so lange wir noch keinen Cybedyne Terminator haben. Wie schon gesagt ist das nur Grob gesehen, da kommen noch viele Algorytmen ins Spiel, aber im Endeffekt ist es ein gut Optimiertes Baukasten-System, so wie ein Macroassembler übrigens auch. Und keine Intelligenz.
:
Bearbeitet durch User
Beitrag #6940743 wurde von einem Moderator gelöscht.
Patrick L. schrieb: > Aber nein er Denkt nicht er arbeitet nur ab. Mit diesem Ansatz gibt es natürlich generell keine KI/AI. Allerdings: verglichen mit dem, was der durchschnittlich "denkende" Mensch hinbekommen würde, ist so ein Compilat oft wesentlich "durchdachter", weil eben ein überdurchschnittlich schlauer Mensch (ggfs. samt Team) sich Gedanken zum Thema gemacht, sich tief ins Handbuch eingearbeitet und die Compilersoftware darauf hin optimiert hat, dass sie erkennt, was der Code eigentlich machen soll. Noch ein Wort zum Thema "Datenbasis und fehlerhafte Interpretation": Kennt eigentlich wer den Mythos mit der Aufmerksamkeitsspanne von 8 Sekunden? Diesen Mythos, der von allen möglichen Quellen immer wieder wiedergekäut wird? Wenn man sich das Thema näher anschaut, dann basiert auch diese Aussage auch auf untauglichem Datenmaterial und einer gewagten Annahme: https://www.webcampus.de/blog/104/die-8-sekunden-aufmerksamkeitsspanne-gibt-es-sie-wirklich https://medium.com/audvice/hast-du-eine-k%C3%BCrzere-aufmerksamkeitsspanne-als-ein-goldfisch-d3ab95aba020 Insofern ist diese Untersuchung und die Interpreation der Zahlen eher eine "Aufmerksamkeits-Panne"...
:
Bearbeitet durch Moderator
Patrick L. schrieb: > Der Kompiler greift auf eine Datenbank von Befehlen zu die irgend ein > Programmierer(meist Team) vorgefertigt hat. Danke. Ich bin bereits aktiv mit Codegeneratoren von Compilern befasst gewesen. Was du beschreibst kann ein kleiner Teil davon sein, muss aber nicht.
:
Bearbeitet durch User
Lothar M. schrieb: > ist so ein Compilat oft wesentlich "durchdachter", > weil eben ein überdurchschnittlich schlauer Mensch sich Gedanken zum > Thema gemacht Nicht nur ein Mensch, sondern ziemlich viele
Stefan ⛄ F. schrieb: > Nicht nur ein Mensch, sondern ziemlich viele Zumindest bei solchen wie GCC. Im Markt von Mikrocontrollern können auch Compiler existieren, die eine deutlich dünnere Personaldecke haben.
:
Bearbeitet durch User
Patrick L. schrieb: > Wiso? Weil ein Compiler ohne Optimierungen praktisch mit angezogener Handbremse fährt, das Ergebnis ist nicht sinnvoll mit irgendwas vergleichbar. Patrick L. schrieb: > Der Kompiler greift auf eine Datenbank von Befehlen zu die irgend ein > Programmierer(meist Team) vorgefertigt hat. Das ist aber eine schwammige Aussage. Die Compiler machen eine Flussanalyse um zu schauen welche Daten wo verwendet werden, auch über mehrere Funktionen hinweg (wenn inline), bevor überhaupt irgendwas durch "Bausteine" ersetzt wird. Ein schönes Beispiel ist ein großes switch-case-Konstrukt, bei dem die einzelnen Werte nicht aufeinander folgen. Der GCC baut daraus eine binäre Suche, sodass die Laufzeit logarithmisch in der Fall-Anzahl ist. Natürlich ist dieser Suchbaum auch "nur" mit einem vorgegebenen Algorithmus erzeugt, aber es ist trotzdem ziemlich clever und auch sehr effizient. Wenn man die Werte im Code ändert, passt der Compiler den Suchbaum beim nächsten Übersetzungslauf blitzschnell an. Bei handgeschriebenem Assembler-Code wäre das eine Menge Aufwand. So eine Umsetzung würde ich schon nicht mehr als ein Baukastensystem bezeichnen. Dazu optimieren die Compiler noch speziell auf die Eigenschaften der Pipeline des Prozessors hin, d.h. Befehle werden so verschoben dass aufeinanderfolgende Instruktionen auf unterschiedliche Prozessor-Funktionen zugreifen und enge Abhängigkeiten vermieden werden. Das ist ein Optimierungsprozess und hat nicht mehr viel mit simplem Ersetzen oder "Baukasten" zu tun. Patrick L. schrieb: > aber im Endeffekt ist es ein gut Optimiertes > Baukasten-System, so wie ein Macroassembler übrigens auch. Ein Macro-Assembler, der nur Textersetzungen macht, ist nicht mit einem modernen(!) Compiler zu vergleichen. Die Algorithmen, die im Compiler stecken, sind zwar (noch?!) keine künstliche Intelligenz und können nicht als "denken" bezeichnet werden; aber an so vielen Stellen im modernen Leben verlassen wir uns voll und ganz auf Optimierung mithilfe von solchen Algorithmen auf einer Ebene, welche manuell überhaupt nicht zu erreichen ist, wie z.B. Optimierung von Fahr/Flug-Plänen, Zeitplänen, Logistik-Wegen, Werkstücken mittels FEM oder CFD; warum nicht auch bei der Erstellung von Prozessor-Instruktionen?
Die aktive "Personaldecke", also Entwicklung, der Zortech/Symantec/DigitalMars C++ und D Compiler für PCs besteht m.W. aus einer Person, Walter Bright, der seit zig Jahren in dem Thema steckt.
:
Bearbeitet durch User
Beitrag #6940784 wurde von einem Moderator gelöscht.
Niklas G. schrieb: > Der GCC baut daraus eine > binäre Suche, sodass die Laufzeit logarithmisch in der Fall-Anzahl ist. Das ist eine Variante davon. Davor steht eine Analyse, welche der Varianten der Implementierung welchen Aufwand erzeugt, und welche folglich in Abhängigkeit von der Optimierungseinstellung vorzuziehen ist.
:
Bearbeitet durch User
Lothar M. schrieb: > Verglichen mit dem, was der duchschnittlich "denkende" Mensch > hinbekommen würde, ist so ein Compilat oft wesentlich "durchdachter", > weil eben ein überdurchschnittlich schlauer Mensch sich Gedanken zum > Thema gemacht, sich tief ins Handbuch eingearbeitet und die > Compilersoftware darauf hin optimiert hat, dass sie erkennt, was der > Code eigentlich machen soll. Genau das meine ich. Mit keinem Wort sage ich dass ein Kompiler schlecht ist da hat sich oft ein ganzes Team Jahre damit befasst ein Algorytmus zu entwickeln, der das so Optimiert, Sowohl das Auslesen der fertigen Routinen, so wie das Nachoptimieren der selben. Ein Kompiler kann dir sehr viel Vereinfachen oder auch oft besser Kompilieren wie wenn du es selber machst und schreibst. Nur halt eben kann er(der Kompiler) nicht Denken, auch wenn es oft so aussieht. Eine Gut programmierte ELIZA wird auch nicht von jedem Menschen gleich als eine solche erkannt. Ihre Rechtschreibung und Grammatik ist zu 100% Stimmig (im Gegensatz zu meiner). Aber wenn man sich lange genug damit befasst, wird mann feststellen dass es keine Intelligenz ist. So könnte ELIZA hier auch nicht am "Gespräch" teilnehmen und Mehr oder Weniger Intelligente Antworten oder Fragen posten. Genau so kann ein Kompiler nicht denken und es gibt Situationen ind denen der Denkende Mensch dem Kompiler trotz allem wenn er direkt in Assembler schreibt ihm überlegen sein kann. Genau so wie ich als Beispiel, dass mit der Nicht verwendeten Pheripheri als Speicher genant habe. Der Kompiler kann das genau so wenig wie der Assembler es kann. Aber der Programmierer der in Assembler Programmiert muss sich zwangsäufig mehr mit der Hardware befassen die er Programmiert und kann deshalb auch solche Klimmzüge realisieren. Ein Programmierer der sich nur mit dem Code und dem was soll wann wie passieren Befasst wird dies nicht machen, weil er nicht sicher sein kann was für eine Hardware dahinter steckt, auf welcher sein Portierbarer Code nachher läuft. Deshalb ist da der Assemblerprogrammierer im Vorteil er ist gezwungen sich mit der Hardware zu befassen und kann diesbezüglich gerade für ein Massenprodukt dies Preis-optimierter Programmieren als ein anderer, der sich nicht mit der Hardware befasst. Zweifelsohne wird dann oft in einer Hochsprache zu Programmieren und alle Parameter richtig einzustellen Aufwendiger wie wenn der Assemblerfreak das für ein µC mit 512 Byte Flash/OTP und 32 Byte Ramm direkt schreibt. Der C Programmierer sagt einfach Es braucht 2K Flasch und 64 Byte RAM sonst geht es nicht. Selber oft erlebt, genau diese aussagen, und Schlussendlich sich über die Kosten der Externen IT Geärgert und dann selber in Assembler, doch in 512Byte gepackt und mit 32 Byte ausgekommen. Fazit die Herstellung hat sich für 1/3 des preises realisieren lassen weil man den gerade mal 0,15€ µC verwenden konnte anstelle des 1,60€ Teuren mit mehr RAM und mehr OTP. Dennoch würde ich nie auf die Idee kommen ein Handyapp oder eine Funktionsengine der Onlinegam in Assembler zu Programmieren, da nehme ich Java oder Phyton usw.
Beitrag #6940808 wurde von einem Moderator gelöscht.
Patrick L. schrieb: > Genau so kann ein Kompiler nicht denken Ich denke das bestreitet hier niemand.
Beitrag #6940818 wurde von einem Moderator gelöscht.
Patrick L. schrieb: > Deshalb ist da der Assemblerprogrammierer im Vorteil er ist gezwungen > sich mit der Hardware zu befassen Nur weil man nicht dazu gezwungen ist, kann man es trotzdem machen. Auch ein C++-Programmierer kann wissen wie die Maschine funktioniert und solche Späße machen wie Peripherie-Register als Speicher missbrauchen. Überhaupt ist die Einteilung in Assembler-Programmierer und C-Programmierer wenig sinnvoll, denn viele Leute können beides. Selbst wenn solches Wissen nur Assembler-Programmierern zugänglich wäre, könnten sie es auch auf ihre C- oder C++-Programme übertragen. Tatsächlich ist viel C++-Software ziemlich performance-kritisch (z.B. wissenschaftliche Berechnungen oder Grafik-Engines), weshalb C++-Programmierer oft sehr genau über Assembler-Code und Performance-Optimierung Bescheid wissen. Das bezieht sich allerdings oft auf PC-Hardware statt auf Mikrocontroller-Hardware. Da geht es dann eher darum Vektor-Instruktionen (AVX) effizient zu nutzen oder Datenstrukturen und Algorithmen so zu optimieren, dass der CPU-Cache optimal ausgenutzt wird. Patrick L. schrieb: > Zweifelsohne wird dann oft in einer Hochsprache zu Programmieren und > alle Parameter richtig einzustellen Das ist eine unbegründete Behauptung. Compiler-Optionen einstellen ist keine Mammutaufgabe. Patrick L. schrieb: > Selber oft erlebt, genau diese aussagen, und Schlussendlich sich über > die Kosten der Externen IT Geärgert Das ist sowieso keine "IT" sondern Software-Entwicklung. Nur weil eine Firma das nicht kann, heißt das noch lange nicht dass das alle nicht können. Patrick L. schrieb: > Der C Programmierer sagt einfach Es braucht 2K Flasch und 64 Byte RAM > sonst geht es nicht. Das Hauptproblem ist eher dass solche Mini-Controller oft keinen Software-Stack haben, keine Offset-Adressierung beherrschen o.ä. Kleinen C- oder C++-Code zu schreiben ist an sich kein großes Problem. Patrick L. schrieb: > Fazit die Herstellung hat sich für 1/3 des preises realisieren lassen Welche in Deutschland ansässigen Firmen arbeiten überhaupt (noch) in dieser Größenordnung? Ich hatte den Eindruck dass solche preissensitiven Massenprodukte sowieso alle in China entwickelt werden; die meisten hiesigen Produkte nutzen einfach den größtmöglichen Controller oder gleich ein Embedded Linux-System, weil es Spezial-Produkte mit geringer Stückzahl sind.
Beitrag #6940836 wurde von einem Moderator gelöscht.
Niklas G. schrieb: > Welche in Deutschland ansässigen Firmen arbeiten überhaupt (noch) in > dieser Größenordnung? Ich hatte den Eindruck dass solche preissensitiven > Massenprodukte sowieso alle in China entwickelt werden; die meisten > hiesigen Produkte nutzen einfach den größtmöglichen Controller oder > gleich ein Embedded Linux-System, weil es Spezial-Produkte mit geringer > Stückzahl sind. Wier! Wir Verzichten so wohl auf Fertigung von PCB in Cina und wir Verzichten auch auf Bestückung in China. Dafür gibt es genug Firmen die da in DE gerade mal ein Briefkasten und ein Büro haben. Und schon das Personal sitzt irgend wo im Aussland und wird per Anrufumleitung im DE Büro mit dem Auftragsgeber verbunden. Unsere Politik ist möglichst alles hier in DE oder CH,FR zu machen um da Arbeitsplätze zu sichern. Gerade das macht nun in den **** Zeiten unser Vorteil aus. Wir haben bis Dato für keine unserer Produkte Liefer-Engpässe. Die im Moment, fast am Hungertuch nagenden Unternehmen, hier in DE bekommen Aufträge und nicht die in CN. Das Produkt ist zwar etwas Teurer aber eben halt lieferbar. Was nützt mir ein Superkontroller der 1/10 kostet wenn er erst im Jahr 2023 geliefert werden kann? dann nehme ich lieber den, der den Preis halt kostet, aber ich kann dem Kunden das Produkt nicht erst liefern wenn er es dann nicht mehr braucht. Genau so versuchen wir Preisoptimiert zu Produzieren anstelle in CN durch deren Politik zu sparen.
:
Bearbeitet durch User
Der Hauptunterschied zwischen Assembler- und C-Programmierern ist, daß ein C-Programmierer den Code möglichst portabel halten will, d.h. Hardwareabhängigkeiten auf ein Mindestmaß zu reduzieren versucht. Z.B. Portpins muß man zugreifen, aber Peripherie als RAM zu mißbrauchen, hat in der Regel keinerlei Nutzen. Der C-Programmierer lagert oft sogar die Hardwarezugriffe in einen low level Driver aus, um eine Portierung auf andere CPUs, Cores zu erleichtern. Peripherie als RAM zu mißbrauchen, kann sogar gemeine Fehlerquellen beinhalten, z.B. sind in manchen IO-Registern nicht alle Bits implementiert oder sie können scheinbar zufällig ihren Wert ändern (Input Capture).
Niklas G. schrieb: > Tatsächlich ist viel C++-Software ziemlich performance-kritisch (z.B. > wissenschaftliche Berechnungen oder Grafik-Engines), weshalb > C++-Programmierer oft sehr genau über Assembler-Code und > Performance-Optimierung Bescheid wissen. Und als Nebenprodukt fallen bei so einer Person dann Tools wie compiler-explorer/godbolt.org ab.
Peter D. schrieb: > Peripherie als RAM zu mißbrauchen, kann sogar gemeine Fehlerquellen > beinhalten, z.B. sind in manchen IO-Registern nicht alle Bits > implementiert oder sie können scheinbar zufällig ihren Wert ändern > (Input Capture). Oder sie beeinflussen undokumentiert andere Teile des µC.
Peter D. schrieb: > Peripherie als RAM zu mißbrauchen > können scheinbar zufällig ihren Wert ändern Warum sollte man das tun? Die Zeiten des RAM-Mangels sind vorbei. Denn das bezieht sich sicher nicht auf die angesprochenen GPIOR Register, die sind ausdrücklich zu Status-Speicherung vorgesehen. Wie es überhaupt manches Schätzchen in Controllern zu entdecken gilt. Peter D. schrieb: > Code möglichst portabel halten gelingt in einer Highlevel Sprache sicher besser, das steht doch außer Frage. Ob es diese Portabilität immer braucht steht auf einem ganz anderen Blatt. Patrick L. schrieb: > Wier! > > Wir Verzichten so wohl auf Fertigung von PCB in Cina und wir Verzichten > auch auf Bestückung in China. > Dafür gibt es genug Firmen die da in DE gerade mal ein Briefkasten und > ein Büro haben. Und schon das Personal sitzt irgend wo im Aussland und > wird per Anrufumleitung im DE Büro mit dem Auftragsgeber verbunden. > > Unsere Politik ist möglichst alles hier in DE... Die Zeiten werden sich wieder ändern. Es hängt doch alles an der C*** Pandemie. Niklas G. schrieb: > Tatsächlich ist viel C++-Software ziemlich performance-kritisch (z.B. > wissenschaftliche Berechnungen oder Grafik-Engines), weshalb > C++-Programmierer oft sehr genau über Assembler-Code und > Performance-Optimierung Bescheid wissen. Das bezieht sich allerdings oft > auf PC-Hardware statt auf Mikrocontroller-Hardware. Gerade diese Unterscheidung ist denke ich wichtig. Assembler ist auf PC-Hardware nun wirklich die Ausnahme.
:
Bearbeitet durch User
Peter D. schrieb: > Peripherie als RAM zu mißbrauchen, kann sogar gemeine Fehlerquellen > beinhalten, z.B. sind in manchen IO-Registern nicht alle Bits > implementiert oder sie können scheinbar zufällig ihren Wert ändern > (Input Capture). Ist richtig wenn das Gehirn grad Ferien macht..... :-D Aber grad bei gewissen µC ist zum beispiel 8k RAM für USB oder für den Coprozessor oder 16 Word(2x8Bit) ram fürs LCD on Chip Komt dazu das dan diese auch noch sehr schnell über Kurzbefehle im Untersten RAM Segment platziert sind und so noch schneller angesprochen werden können (Kurzform oder Zerropage Adressing) und so wiederum noch mehr FLASH sparen kann. Eine solche Optimierung ist nur dann möglich wenn man sich intensiv mit der Hardware befasst, und wen da nur schon 10'000 Stk von produziert werden (bispiel BMI Hybrid die wir herstellen, mit integriertem µC) dann kann da schon mal ein paar € gespart werden, was dann dem Kunden weitergegeben werden kann um das Produkt gegenüber einem CN Produkt wieder Atraktiv zu machen. Genau da Haben (Mehrere Softwarefirmen versagt, weil sie es unbedingt in einer Hochsprache realisieren wollten). Schlussendlich habe ich andere Arbeit liegengelassen und es selber in Assembler umgesetzt. Das hat nichts direkt mit der Hochsprache zu tun, aber ganz gewiss mit der Ganzen sagen wir Politik. Heutige Programmierer die in Hochsprachen Programmieren haben den Röhrenblick und was der Kompiler nicht schafft geht halt nicht. Man verlernt das selber Denken, man überlässt es den anderen die das Endprodukt nicht kennen und den Kompiler so universell wie möglich gestalten müssen. und genau da ist der Assemblerfreak klar im Vorteil. Er muss denken Genua so wie man heute das Handy schon als Vernsteuerung für Menschen bezeichnen kann. Fragst du jemanden wass, hat sein Großhirn Sendepause, und das Kleinhirn zückt reflektionsartig das Smartphone und er fragt Tante Gurgel danach. Ohne aber zu Überlegen dass dort nicht die gewünschte Antwort zu finden ist. Die Frage war nämlich, Was hat dein Nacbarhaus für eine Hausnummer. Probiert es ruhig mal mit so banalen Fragen aus, wie viele zücken ihr Smartphone, auch schon wenn man sie nach ihrer Adresse fragt? Der Kompiler kann sicher vieles besser und schneller aber er kann nicht Denken. der den Ihn verbissen Anwendet, (Assembler braucht man nicht) verlernt das "Um die Ecke denken". Das ist Fakt.
:
Bearbeitet durch User
Patrick L. schrieb: > [...] > > Das ist Fakt. Nichts von dem, was du geschrieben hast, ist ein Fakt. Das ist alles deine Meinung.
Urs H. schrieb: > Ob es diese Portabilität immer braucht steht auf einem ganz > anderen Blatt. Ich hab viele Funktionen, die auf 8051, AVR, Cortex-M3 laufen. Sie nur einmal entwickeln und testen zu müssen, hat schon ne Menge Zeit und Nerven gespart.
Peter D. schrieb: > Urs H. schrieb: >> Ob es diese Portabilität immer braucht steht auf einem ganz >> anderen Blatt. > > Ich hab viele Funktionen, die auf 8051, AVR, Cortex-M3 laufen. > Sie nur einmal entwickeln und testen zu müssen, hat schon ne Menge Zeit > und Nerven gespart. Besonders vorteilhaft ist das zur Zeit, wo offenbar viele Redesign betreiben müssen, gerne auch mal auf einer ganz neuen µC-Familie. Ich bin dafür, dass man sich in seiner Ausbildung mal mit Assembler beschäftigt hat um zu verstehen, wie es auf der untersten Ebene zugeht. Außerdem kann man so später besser Fehler in Compilersprachenprogrammen finden. Ansonsten ist es faszinierend, was der Compiler so alles findet. Da werden bspw. gerne mal Code-Fragmente aus vollkommen unterschiedlichen Funktionen zweifach verwendet - etwas, auf das man händisch kaum stoßen würde. Nein, das möchte ich mir auf Assemblerebene nicht mehr antun. C steht beim Speicherplatzverbrauch einem Assemblerprogramm kaum nach - wie das Moby-Beispiel vor ein paar Jahren zeigte, konnte das der Compiler sogar besser ;-) Und intensiv mit der Hardware beschäftigen muss man sich so oder so. Ich wüsste nicht, was ich als Assembler-Programmierer in der Doku anderes oder mehr lesen sollte als jetzt unter C. Die gewichtigsten Argumenten für Hochsprachen bleiben für mich die zumindest deutlich leichtere Portierbarkeit und die deutlich geringere Fehleranfälligkeit (Typprüfungen, Stackoperationen usw.)
Beitrag #6941025 wurde von einem Moderator gelöscht.
Chris D. schrieb: > Ich wüsste nicht, was ich als Assembler-Programmierer > in der Doku anderes oder mehr lesen sollte als jetzt unter C. Mir fällt was ein: Das ganze Dokument mit dem Befehlssatz muss man als C Entwickler nicht lesen.
Patrick L. schrieb: > Der Kompiler kann sicher vieles besser und schneller aber er kann nicht > Denken. Das ist zum einen bei vielen Menschen auch eher fraglich und zum anderen muss der auch nicht denken können. Eine Programmiersprache ist streng regelbasiert und der Compiler soll einfach Regeln einhalten, Abläufe abbilden und soweit möglich Optimierungen durchführen und das Housekeeping im Hintergrund machen, damit ich mich auf die eigentlich Arbeit konzentrieren kann. Ich habe früher 8085 programmiert, danach 8051. Ein makro Assembler war da schon Raketenwissenschaft. Klar musste ich alles Handoptimieren, der hatte ja nix und konnte ja nix. Klar habe ich mir darauf einen gewedelt wenn ich durch DEN Trick zwei Maschinenzyklen gespartt habe und eine wichtige Loop dadurch 30% schneller wurde. Heute ist das einfach witzlos bis auf wenige Spezialfälle. Entwickler kosten immer mehr und MCUs immer weniger. Die MCUs strotzen nur so vor Kraft und HW Funktionen und Übersichtlichkeit ist weit wichtiger geworden als einem 1K ASM Schnippsel trotz arschlangsamer MCU und dämlicher HW irgendwei das Fliegen beizubringen. Außerdem gab es diese ASM Diskussion schon 100 mal hier und auch damals hat Moby die angeheizt und damals hat ein Mod über einen kleinen Codecontest bewiesen das der C Compiler effizienteren Code geschrieben hatte als die selbsternannten ASM Gurus. Ist Jahre her. Das sind alles völlig fruchtlose Diskussionen. Das 'Volk' hat schon lange mit den Füssen abgestimmt.
Chris D. schrieb: > C steht beim Speicherplatzverbrauch einem Assemblerprogramm kaum nach Man darf da nicht den Assembler-Obercrack mit dem dem C-Anfänger vergleichen. Oder gar meinen, dass jemand, der Assembler programmiert, quasi per Definition und automatisch den kompakteren und schnelleren Code erzeugt. Das schafft der erfahrene Assemblerprogrammierer nämlich erst dann , wenn er sich sehr gut in die Plattform eingearbeitet hat. Allerdings schafft das der ebenso erfahrene C-Programmierer mit seiner Programmiersprache auch, weil er sich nämlich ebenfalls in die Plattform eingearbeitet hat. Patrick L. schrieb: > Eine solche Optimierung ist nur dann möglich wenn man sich intensiv mit > der Hardware befasst Das gilt in jedem Fall und immer. Und man muss dann aber schon den hochspezialisierten und erfahrenen Programmierer aus der einen Fraktion mit dem hochspezialisierten und erfahrenen Programmierer aus der anderen Fraktion vergleichen, wenn es darum geht, herauszufinden, wo man das Optimum herauszuholen könnte. > Genau da Haben (Mehrere Softwarefirmen versagt, weil sie es unbedingt in > einer Hochsprache realisieren wollten). Sie haben meines Erachtens deshalb versagt, weil sie es nicht konnten. Also einfach, weil sie nicht den Spezialisten hatten, der die Aufgabe lösen konnte. Denn dass es nicht an der Hardware lag, das hast du ja dann mit dem Assembler bewiesen...
:
Bearbeitet durch Moderator
Max M. schrieb: > Die MCUs strotzen nur so vor Kraft und HW Funktionen und > Übersichtlichkeit ist weit wichtiger geworden als einem 1K ASM > Schnippsel trotz arschlangsamer MCU und dämlicher HW irgendwei das > Fliegen beizubringen. Richtig, den ersten Punkt wollte ich noch angesprochen haben. Viele Geschwindigkeitsoptimierungen (ein gerne angebrachtes Argument pro Assembler) fallen heute schlicht weg, weil die entsprechenden Funktionen bereits in Hardware gegossen wurden. Beispiele sind das schnelle Verschieben/Ausgeben von Daten mittels DMA, Quadraturencoder hat auch jeder an Bord, LCD-Ansteuerung usw. Die Hardware kann das dann viel besser als jeder Assembler- oder auch Compilersprachencode.
:
Bearbeitet durch Moderator
Vor zehn Jahren arbeitete ich an einen AES DSPic B.L. Da war ASM nur zum Schreiben und Lesen des FLASH wegen spezieller Zugangsbeschränkungen und Prozeduren notwendig, was aber als Inline nach Datenblatt Vorgaben auch gut funktionierte. Sonst wurde ASM nie gebraucht. Hier war also funktionelle Notwendigkeit die Motivation für etwas ASM.
Gerhard O. schrieb: > etwas ASM. Mache ich auch, z.B. wenn ich eine Clock Source umstelle und nur ein paar Zyklen Zeit habe von beschreiben des Sicherheitsregisters mit dem Schlüssel und dem Setzen des Clock Registers. ASM ist manchmal nötig oder einfach schnell und praktisch. Aber eben nur in mässiger Dosierung, sonst versteht das kein Mensch mehr. Der mega Trick von heute ist manchmal der Sargnagel von Morgen.
Beitrag #6941117 wurde von einem Moderator gelöscht.
Beitrag #6941132 wurde von einem Moderator gelöscht.
Beitrag #6941188 wurde von einem Moderator gelöscht.
Beitrag #6941235 wurde von einem Moderator gelöscht.
Beitrag #6941239 wurde von einem Moderator gelöscht.
Ber X. schrieb im Beitrag #6941235: > Es ist ja auch kein Wunder: Gerade bei den kleineren Controllern und im > wachsenden 8Bit Markt ist ASM oft die beste Sprache der Wahl. Kompakt, > schnell, direkt, transparent, wenig Bürokratie. Der Kontrast wird hier > zu den sprachtechnisch immer weiter aufgeblähten, sich inflationär > vermehrenden Hochsprachen eher noch größer als kleiner. Die Praxis spricht möglicherweise eine andere Sprache. Vor über 22 Jahren mußte bei mir in der Firma eine alte notwendige HW modernisiert werden die noch auf einem NEC uC lief und in ASM geschrieben war. Der Entwickler der NEC FW war schon lange nicht mehr in der FA angestellt; die alten MSDOS bzw. CP/M Werkzeuge existierten nicht mehr und auch die Quellen nützten nicht viel. Moderne NEC Entwicklungswerkzeuge für den betroffenen uC existierten nicht. Ein damals neu eingestellter junger Computer Ingenieur entschied dann prompt das Ganze mit einem 16er PIC mit 368B SRAM in C zu machen weil PIC ASM auch nicht so tolle war. Er schrieb die FW dann anhand der Vorgaben auf C um mit einen damals neu auf dem Markt erschienenen CCS Compiler und wir sahen nie mehr zurück und alle zukünftigen 8-Bit uC Projekte wurden in C geschrieben. Es gab nie wirkliche Probleme. Erweiterungen und Anpassungen über die Jahre waren schnell und problemlos durchzuführen.
Um Nochmals auf das Thema zurückzukommen: [Assembler bleibt weiterhin aktuell & wichtige Programmiersprache] Ist schlicht richtig. [das Assembler etwas besser] kann ist schlicht falsch. Wie schon geschrieben aber scheinbar überlesen: Weder der Assembler kann noch die Hochsprache kann. Das sind alles Werkzeuge. Und ein Werkzeug ist immer nur so gut wie der, der es anwendet. Also all die Diskussionen sind Irrelevant. Das einzige was meine Erfahrung zeigt, dass es gut ist wenn man Assembler Versteht. denn wenn man nicht Versteht was der Kompiler da macht, ist man auch nicht im Stand die Hardware dahinter zu verstehen und den Code dahingehend zu Optimieren. Ja ist auch richtig das die Prozessoren x fach leistungsfähiger sind wie damals. Es ist auch dahingehend Richtig das heute das Ganze Konzept mit BuntiKlicki so komplex wurde dass es Teilweise mit Assembler kaum mehr machbar ist. Ändert aber dennoch nichts daran das Der Programmierer sich kaum mehr mit der Hardware selber befasst und so in sehr vielen Fällen daher nicht mehr Optimiert Programmiert. Habt ihr schon mal diverse DLL und Funktionen von Windof angeschaut? Vieles ließe sich bei Optimierter Programmieren (Egal ob in Hochsprache oder Assembler), aber es zeigt die zunehmende sage mal "Faulheit" obwohl das falsche Wort dafür, der Hochsprachenprogrammierer die das ganze Programmiert haben. Sehr viele solche DLL wimmeln gerade von x fach in sich geschachtelten Rutinen oder sich Zigfach wiederholenden Codeblöcke, die x fach mehr Zeit und Platz brauchen, wie wenn sich der Programmierer etwas mehr mit der Hardware und dem eigentlichen Code auseinandergesetzt hätte. Böse gesagt muss der heutige µP x mal so viel leisten um das selbe Resultat zu erreichen wie wenn man sein Grips dabei eingeschaltet hätte, als man die Software zusammengeflickt hatte. Nochmals ich bin weder ein Hochsprachen Gegner noch ein Assemblerfanatiker. Jedes Werkzeug am richtigen Ort richtig eingesetzt, da liegt der Hase im Pfeffer. Und meiner Meinung nach, ging das einfach verloren, weil (Ja mann nimmt einfach den nächst grösseren und schnelleren µC dann passt das). Es nimmt sich kaum mehr einer die Zeit sich ausgiebig mit der Hardware zu befassen und die Software darauf zu Schreiben. Nein mann kann sagen, mann schreibt die Software und sucht dann passende Hardware. Unter anderem kommt das auch davon, dass man einfach verbissen und verbohrt denkt der Kompiler macht dass schon. Dabei aber vergisst das der Kompiler eben nicht selber denkt und mann ihm sagen muss, was er wie Optimieren soll. Sprich man muss die Parameter richtig setzen. Der Assembler Optimiert eigentlich so gut wie gar nichts (es gibt da auch Ausnahmen) und mann muss von Anfang an Denken. Es gibt auch Assemblerprogrammierer oder Eher Baukastenbauer die einfach fertige Segmente im Internet zusammensuchen, und dann sagen (Habe ich in Assembler Programmiert). Da ist dann auch wieder klar dass da nicht von Optimierten Programmieren die rede sein kann. Darum was soll die Diskussion das ist besser oder das ist besser? Besser ist der Quellcode von dem, der sich mit der Hardware befasst hat und sich überlegt hat, was wann wie wo und warum passiert.
Lothar M. schrieb: > Ja, aber eben auch für alle Suchanfragen nach "C" und "Python" und > sonstwas zusammen. An dieser Stelle liegt nicht der eigentliche > Schwachpunkt der Statistik Doch. Denn C und Python sind per se immer noch C und Python, egal um welche Version es sich handelt; das ist schon vergleichbar bzw. kann auf dieser Ebene in einen Topf geworfen werden. x86-Assembler mit allen 8-Bit-, 32-Bit-Assemblern usw. in einen Topf zu werfen kann man zu Statistikzwecken zwar machen, wenn man sich der limitierten Aussagekraft dessen bewusst ist – wie der TO daraus aber irgendwelche Schlüsse auf kleine uCs oder Quantencomputer zu ziehen, ist allerdings natürlich kompletter Schwachsinn. Ähnlich wie die Linux-auf-dem-Desktop-Diskussion, basierend auf Marktanteilen ermittelt aus Browser-Footprints, auf deren Basis irgendein Scherzkeks uns die Allmacht der KDE (oder noch blöder, einer Distribution) "nachweisen" will. Belege für seine steilen Thesen liefert der TO ja indes aus gutem Grunde nicht mit.
Beitrag #6941387 wurde von einem Moderator gelöscht.
(prx) A. K. schrieb: > Rolf M. schrieb: >>> Weil es eben 32bit ist, werden Adressberechnungen & Co schön einfach >>> (für Arrays & Structs). >> >> Allerdings gibt es keine 32-Bit-Immediates, weil dafür in den >> Instruktionen kein Platz ist. > > Das gilt generell für RISC mit festem Befehlsformat. Eigentlich nur für RISC, dessen Befehle nicht breiter sind als die Bitbreite der ALU. Bei AVR z.B. geht es, weil die Register 8 Bit breit sind, die Befehle aber 16 Bit.
Rolf M. schrieb: > Bei AVR z.B. geht es, weil die Register 8 Bit breit sind, die Befehle > aber 16 Bit. Nicht bei Adressen. Es geht, weil die Befehle eine variable Länge haben.
Chris D. schrieb: > Nein, das möchte ich mir auf Assemblerebene nicht mehr antun. C steht > beim Speicherplatzverbrauch einem Assemblerprogramm kaum nach - wie das > Moby-Beispiel vor ein paar Jahren zeigte, konnte das der Compiler sogar > besser ;-) Das ist auch nicht so verwunderlich, wenn ich daran zurückdenke denke wieviele Veröffentlichungen von Doktorarbeiten es zum Beispiel zur Optimierung von Compilern im letzten Jahrtausend gab, die bestimmte Strukturen bereits im Sourcecode erkennen um einen effektiven compelierten Code auszuspucken. Im Vergleich zu diesem Aufwand, der im Compiler steckt, schnitt die genannte Person des erwähnten Beispiels erstaunlich gut ab. Umgekehrt hat es immer einen Zeit gedauert, wenn Mikroprozessoren um neue Maschinenbefehle erweitert wurden, bis die Compiler diese unterstützten. Es gab sogar in einer Zeitschrift vor vielen Jahren eine Liste undokumentierte Befehle von Prozessoren. Übrigens gibt es das heute noch, wie folgender Artikel zeigt: https://www.trojaner-board.de/201467-intel-prozessoren-zwei-undokumentierte-befehle-microcode-enttarnt.html Auf solchem Spezialgebiet der IT-Sicherheit sind Kenntnisse über den Microcode von Prozessoren und Programmierung in Assembler erforderlich.
Beitrag #6941888 wurde von einem Moderator gelöscht.
Beitrag #6941956 wurde von einem Moderator gelöscht.
Beitrag #6942170 wurde von einem Moderator gelöscht.
Beitrag #6942207 wurde von einem Moderator gelöscht.
Beitrag #6942227 wurde von einem Moderator gelöscht.
Beitrag #6942341 wurde von einem Moderator gelöscht.
Beitrag #6942364 wurde von einem Moderator gelöscht.
Beitrag #6942447 wurde von einem Moderator gelöscht.
Beitrag #6942692 wurde von einem Moderator gelöscht.
Beitrag #6942706 wurde von einem Moderator gelöscht.
Beitrag #6942768 wurde von einem Moderator gelöscht.
Beitrag #6952489 wurde von einem Moderator gelöscht.
Beitrag #6953258 wurde von einem Moderator gelöscht.
Beitrag #6954799 wurde von einem Moderator gelöscht.
Beitrag #6955456 wurde von einem Moderator gelöscht.
Beitrag #6957429 wurde von einem Moderator gelöscht.
Beitrag #6957456 wurde von einem Moderator gelöscht.
Beitrag #6957457 wurde von einem Moderator gelöscht.
Beitrag #6957459 wurde von einem Moderator gelöscht.
Beitrag #6958147 wurde von einem Moderator gelöscht.
Beitrag #6958151 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.