Assembler bleibt weiterhin aktuell & wichtige Programmiersprache

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.

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.

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 ;-)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.

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

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.

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. ;-)

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.

Cyblord -. schrieb:
> Der, dessen Name nicht genannt werden darf.

Moby?
Duck und weg.

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.

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.

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).

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?

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. :)

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.

Urs H. schrieb:
> Ein Fehler.

Ein Fehler ist es nur, wenn die konventionelle Alternative zum Problem 
wird.

(prx) A. K. schrieb:
> die konventionelle Alternative

die da wäre?

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.

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.

(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? ;-)

Und je weniger Aufwand du in modellspezifische Anpassungen steckst, 
desto billiger wirds. :-)

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.

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

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.

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. :-))

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.

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"...

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.

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.

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.

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.

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.

Patrick L. schrieb:
> Genau so kann ein Kompiler nicht denken

Ich denke das bestreitet hier niemand.

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.

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.

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.

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.

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.)

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...

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.

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.

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.

(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.