Assembler bleibt weiterhin aktuell & wichtige Programmiersprache

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Gerade aus einem anderen Thread entnommen, warum Assemblerkenntnisse 
auch sinnvoll sind:

"Was bei dir in der Liste noch fehlt: grundlegende Assemblerkenntnisse
für die verwendete(n) Plattform(en). Damit sollst du nicht programmieren
(dauert viel zu lange), aber du musst das lesen und analysieren können,
was der Compiler ausspuckt. Spätestes im Disassembler-Listing des
Debuggers solltest du in der Lage sein nachzuvollziehen, was der
Compiler da zusammen gestöpselt hat."

Es ging dort um den Erwerb von Programmierkenntnissen für µC und den 
Absatz habe ich aus einer Antwort von Jörg kopiert.

[Ein T. (ein_typ)]

Horst G. schrieb:
> 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.

Äh... Also bei Python ist das nicht ganz so. Das fängt schon mit dem 
Interpreter an -- neben dem Standard-Interpreter CPython gibt es auch 
noch den performanten Pypy und obendrein die Interpreter Jython und 
IronPython in, und zur Interaktion mit, Java respektive .NET. Und dan 
ist es auch eine Frage von Bibliotheken und Laufzeitmodell, denn es gibt 
beispielsweise Compiler für Python wie nuitka, das den Python-Quelltext 
in C-Quellcode übersetzt, und im Bereich der Bibliotheken gibt es zum 
Beispiel viele wie numpy, das intern alles in C implementiert.

Vor einiger Zeit haben kluge Leute hier mal das Sieb des Erastothenes 
(oder das, was sie dafür hielten) in mehreren Skriptsprachen 
implementiert und gemessen. Ergebnis dieser durchaus spannenden Versuche 
war, das Pythons Standardinterpreter den Code am  langsamsten, der 
optimierte Pypy-Interpreter hingegen am schnellsten ausgeführt hat.  Das 
noch viel spannendere Ergebnis war dann aber, als jemand den irrtümlich 
für den korrekten Algorithmus gehaltenen durch eine korrekte 
Implementierung ersetzt hat, und damit um etliche Faktoren schnelleren 
Code produziert hat. Interessierte können den Thread hier [1] nachlesen. 
Mir persönlich hat der damalige Thread jedenfalls einmal mehr gezeigt, 
daß Algorithmen in der Regel wesentlich mehr Einfluß auf die Performance 
haben als die verwendeten Werkzeuge.

[1] Beitrag "Python oder besser bei C bleiben?"

Patrick L. schrieb:
> Ä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.

Mit der Aussage magst Du Recht haben, aber IMHO ziehst Du die flashcen 
Schlüsse daraus. Denn wenn sich viele Entwickler nicht mehr ausgiebig 
mit der Hardware auseinandersetzen müssen, dann deswegen, weil sie es 
nicht mehr müssen. Das resultiert in portablerer Software und darin, daß 
eine größere Anzahl von weniger spezialisierten Entwicklern zur 
Verfügung steht. Das kann man schade finden, wenn man die Beschäftigung 
mit Hardware, Architekturen und Befehlssätzen für einen hochheiligen 
Selbstzweck hält, aber für Unternehmen und auch für die Entwickler 
selbst ist diese größere Flexibilität eine ausgesprochen feine Sache.

Mir ist auch Dein Fetisch von der "Optimierten Programmierung" aus 
professioneller Sicht ein wenig unverständlich. Denn Softwareentwicklung 
kostet Geld, und am Ende ist die Abwägung zwischen kleineren 
Mikrocontrollern und produktiveren Werkzeugen immer dieselbe. Es nutzt 
Dir ökonomisch nichts, wenn Du bei einer Serie von 1.000 Geräten zwar 50 
Cent pro Gerät am Mikrocontroller sparst, aber einen Arbeitstag eines 
Entwicklers zusätzlich bezahlen mußt, der kostet nämlich etwa 560 Euro 
und Dich damit 56 Cent Mehrkosten pro Gerät... Und am Ende gilt: für 
nicht genutzte Ressourcen gibt es leider kein Geld zurück.

[Ein T. (ein_typ)]

Dieter D. schrieb:
> 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.

Für ein Projekt von ausgesprochen überschaubarer Komplexität, um nicht 
zu sagen: ein geradezu triviales Projetchen. Je umfangreicher sowas 
wird, desto stärker wird der Compiler und desto schlechter der Mensch.

[Patrick L. (Firma: S-C-I DATA GbR) (pali64)]

Ein T. schrieb:
> Mir ist auch Dein Fetisch von der "Optimierten Programmierung" aus
> professioneller Sicht ein wenig unverständlich. Denn Softwareentwicklung
> kostet Geld, und am Ende ist die Abwägung zwischen kleineren
> Mikrocontrollern und produktiveren Werkzeugen immer dieselbe. Es nutzt
> Dir ökonomisch nichts, wenn Du bei einer Serie von 1.000 Geräten zwar 50
> Cent pro Gerät am Mikrocontroller sparst, aber einen Arbeitstag eines
> Entwicklers zusätzlich bezahlen mußt, der kostet nämlich etwa 560 Euro
> und Dich damit 56 Cent Mehrkosten pro Gerät... Und am Ende gilt: für
> nicht genutzte Ressourcen gibt es leider kein Geld zurück

Da hängen sehr viele Faktoren mit zusammen, kann man wenn man will so 
sehen, ist aber in der Realität oft anders.
Angefangen damit dass wen das Mitbewerbergerät 56 Cent günstiger ist 
wirst du keins verkaufen.
Aber das ist nicht der Springende Punkt. Der liegt wen die Stückzahlen 
in die 100'000 de gehen. Oder auch nicht nur die 56 Cent am µP Gespart, 
da kommen noch zig Faktoren mit ins Spiel.

Global gesehen hast du recht, Nur sind es oft zig andere Faktoren die 
Entscheidend sind den kleineren µP zu nehmen.
In vielen Fällen, die wir umsetzen ist ein Faktor den Stromverbrauch.
So verrückt es klingt aber da wird um jedes 0,0x µA Gekämft.
In Chemieanwendungen bspw. wurde vom Kunden bezahlt, dies so weit runter 
zu brechen wie nur irgend möglich. Es ging da um Sensoren mit 
Netzwerkkommunikation, die aus dem Netzwerk gespiesen werden mussten.
Raus kam dann, von Anfangs einem STM32xx schlussendlich ein F2013 
Einsparung an Strom 2000% Einsparung PCB und Bauteile 200% 
Kostenersparnis lag bei rund 1%, wenn man es wieder mit allem 
Hochrechnet (Inkl Programmieroverhead) Man kann sich natürlich dann 
Fragen, "War es das Wert?",
Dem Kunden scheinbar schon, den es wäre sonst weder vom Platz, noch vom 
Strom, noch vom Design her realisierbar gewesen.
Der Kunde hätte es wohl auch machen lassen wenn es 500% mehr gekostet 
hätte, nur ob wir dann zum Zug gekommen wären, steht wo anders 
geschrieben.
Wie dem auch sei, es wurde so gefordert, den das Geld einsparen war 
nicht das primäre Kriterium.
So kann man einfach nicht Global sagen, das oder dies oder jenes sei 
besser.
Das muss immer von Fall zu Fall abgewogen werden.