Assembler: Für was/aktuell? Lernen wo, wie?

[dot]

Hostfrak schrieb:

Soetwas würde ich jetzt als pure Demagogie oder Populismus hinstellen. Eine seriöse Diskussion ist da nicht möglich...

Inwiefern das mit "Demagogie oder Populismus" zu tun hat ist mir zwar schleierhaft aber falls es nicht offensichtlich genug war: Das war eine halbironische Antwort auf dein "Beispiel" (wobei ein Körnchen Wahrheit drin steckt). Wenn du seriös diskutieren willst dann musst du auch mit seriösen Beispielen kommen.

dot schrieb:

Irgendein Hello World, noch dazu mit so merkwürdigem Code, seh ich jetzt nicht als wirklich repräsentativ für irgendwas. Abgesehen davon schaut mir das eher nach einem Debug Build als nach einem optimierten Release Build aus. Da kann ich ein genauso sinnvolles Gegenbeispiel bringen: [...]

...

[Bashar]

Die Antwort war von "Hostfrak", nicht von "Hostfreak".

[Amusement]

Hier merkt man wieder deutlich, wie ignorant und weltfremd die Assemblerfanboys sind. Liegt wohl daran, dass sie unbedingt ihr Mikrowissen verteidigen muessen, fuer das sich im Grunde keiner mehr interessiert.

Und das mit den Banken ist das laecherlichste was ich lange gelesen habe. Bei Bankensoftware zaehlt vor allem eins: Validierung und Sicherheit. Und da ist Assembler so ziemlich das mieseste was es gibt. Banken benuzten fast immer Cobol und in neueren Anwendungen Java.

[Hostfreak]

dot schrieb:

Inwiefern das mit "Demagogie oder Populismus" zu tun hat ist mir zwar schleierhaft aber falls es nicht offensichtlich genug war: Das war eine halbironische Antwort auf dein "Beispiel" (wobei ein Körnchen Wahrheit drin steckt). Wenn du seriös diskutieren willst dann musst du auch mit seriösen Beispielen kommen.

So.... jetzt ist Wochenende und ich bin in "Kampfstimmung" - nein - kämpfen müssen wir nicht.... Dieses Beispiel ist wirklich nur in 5 mn hingesch@#?+- Was es verdeutlichen soll, ist, dass in bestimmten Bereichen C++ absolut keine Berechtigung hat - Und das waren auch die Aussagen meiner vorherigen Posts. Ich denke aber, dass ich jetzt nicht am Zug bin 1000 Lines of C++ Code in Assembler umzusetzen, um zu beweisen, dass C++ im Verhältnis zu ASM von der Effizienz her keine Chance hat... Ich denke, das wird auch so jeder C++ Freak bestätigen. In der heutigen Zeit mit relativ schneller Hardware kann man ja auch recht grosszügig mit den Ressourcen umgehen... So gesehen - ok das mit dem C++.

Amusement schrieb:

Und das mit den Banken ist das laecherlichste was ich lange gelesen habe. Bei Bankensoftware zaehlt vor allem eins: Validierung und Sicherheit. Und da ist Assembler so ziemlich das mieseste was es gibt. Banken benuzten fast immer Cobol und in neueren Anwendungen Java.

Wie bester "Amusement" willst Du beispielsweise ein DB2 Exit bedienen - ausser mit Assembler? Das hat zwar nix mit der Anwendungsentwicklung zu tun - aber sehr wohl mit der Systemprogrammierung... - oder??

[Summertime]

So viel Krebs in einem Thread. *Summertime*

HansKlaus schrieb:

das mmn schönste an assembler ist einfach, daß du quasi nebenbei lernst, wie die cpu bzw. der computer intern funktioniert.

Das ist ein altes und dummes Gerücht, das mit jeder neuen Prozessorgeneration an Wahrheitsgehalt verliert.
Das was man in Assembler von der CPU "sieht" abstrahiert das reale Schaltwerk schon bis zur Unkenntlichkeit weg. Nur weil man mit Registern rumfrickelt heißt das nicht, man hätte irgendeine Ahnung davon wie eine CPU aufgebaut ist.

[supernicky]

asmQuestion schrieb:

Außerdem was denkt ihr darüber asm von null auf zu lernen? Macht es Sinn? Und vorallem wo lernt man es gut? Gibt es verschiedene Arten?(Hatte mal kurz versucht nen asm code auszuprobieren ist jedoch nicht gegangen und mit einer anderen ide ist es gegangen)
Also was muss ich beachten? Wo anfangen? Was muss ich wissen. Und vorallem das fast wichtigste kennt ihr onlinequellen was am Anfang gut wäre, damit ich mal reinschnuppern kann bevor ich nen Buch kauf. Aber wie bereits gesagt auch Buchempfehlungen sind gern gesehen. Schreibt einfach ma alles Grundlegende was ihr wisst damit ich mir ein bisschen ein Bild machen kann :). Danke.

Hallo,

ich bin von VB.NET zu Assembler gekommen. Man muss Assembler von Null auf lernen, da du auch einiges über deinen PC wissen musst.

Vor 9 Monaten habe ich mir die Bücher von Rainer Backer und Rhode/Roming gekauft nur auf Neugier. Anschließend die ersten Zeilen geschrieben und siehe da, es geht.

Sinn macht es auf jeden Fall. Lernen ist niemals verkehrt.
Seit ich damit arbeit weiß ich was Zeiger sind, wie man sie nutzt und man kann kinderleicht mit der WindowsAPI programmieren.
Eine Fensteranwendung zu erstellen ist im Nu gemacht und die Programme sind winzig klein. An einigen Stellen kannst du sogar Windows umgehen und direkt mit deinem PC "sprechen".

Das wichtigste für mich war noch die Einfachheit.
Jede Zeile besteht aus einem einzigen Befehl (mit Operanden natürlich).

Sowas wie hier:

rc=bind(acceptSocket,(SOCKADDR*)&addr,sizeof(SOCKADDR_IN));

gibts da nicht...
Man muss zwar ein paar Zeilen mehr schreiben aber es lohnt sich allemal.
Zudem gibts dort genauso If, else, While, Loop und einiges mehr.
Da ich nur Hobbyprogrammierer bin, bleibe ich auf jeden Fall bei Assembler.

Worauf du achten musst ist, das du deinen Code nach jeder 5. Zeile mal auf Fehler testest. Sonst suchst du dir einen Wolf *g*

Man lernt wirklich viel und es ist nicht so schwer wie überall behauptet wird.
Es ist halt anders.

Nicky

[xpilz]

Hallo.
Ich lerne schon seit einer Woche Assembler lesen und schreiben. Habe dabei natürlich auch eigene Eindrücke von der Sprache gesammelt. Nachdem ich mir diesen Beitrag durchgelesen hatte, musste ich mir ernsthaft Gedanken darum machen ob es die eine Woche überhaupt wert war und dass ich stattdessen nur das Grundprinzip in einer Stunde verstehen sollte.

-Realist- schrieb:

... da man das Grundprinzip in einer Stunde verstanden hat...

Natürlich brauchte ich anfangs einiges an Motivation. Leider hatte ich auch ein für mich nur halbwegs nachvollziehbares Tutorial, aber der Reiz für mich persönlich Assembler zu lernen war die Sache, dass man die komplette Kontrolle hat und im Groben weiß, beziehungsweise bestimmen kann, was passiert.

Um meine Meinung mal etwas zu befestigen hier mal ein Beispiel: ~Ich hoffe es ist für euch nachvollziehbar~
Ein ganz normaler Funktionsaufruf sieht sich in vielen Sprachen ziemlich ähnlich. Ich beschränke mich aufgrund der Übersichtlichkeit nur auf C++ und Assembler.

int func(int ret=0) {
    return ret;
}

int main() {
    func(0);
    return 0;
}

So sieht im besten Fall ein Funktionsaufruf in C++ aus. Wenn man sich diesen Code anguckt. Wird einem klar das C++ einige seiner Pflichten als Hochsprache erfüllt hat. Man kann es schon mit minimalen Englisch Kentnissen und ein wenig Logik nachvollziehen. Dazu kann man den Code auf den ersten Blick auch recht leicht Warten. Was C++ aber für diese Vorteile aufgibt, ist die Klarheit einiger Instruktionen die zwischen einem Funktionsaufruf passieren. Und hier ist Assembler einzigartig (meines Wissens nach).
Hier ein größtenteils äquivalentes Beispiel, im Vergleich zu dem oberen.
(Gas Syntax)

.section .text
.globl _start
_start
  pushl $0
  call func

  movl $1, %eax
  movl $0, %ebx
  int $0x80

.type func, @function
func:
  movl 4(%esp), %eax
  ret

Wie man unschwer erkennen kann, ist es schlecht lesbar. Vielleicht bräuchte dieser Code auch mehr Wartungsarbeit als der erste. Aber, wenn man etwas Ahnung von Assembler hat, und dazu noch eine Quelle, die ein Beispiel in dieser Art für eine Erklärung der Segmentierung verwendet, dann ist es an diesem Beispiel wesentlich besser zu verstehen als in einer anderen Sprache wie C++ (Im Bezug auf Funktionen).

Wollte man sich für längere Zeit mit der Assembler Sprache beschäftigen, sei es im Beruf, der Schule oder im Hobby, dann kann man sagen, je mehr man über Assembler liest, desto besser ist es. Egal welche Qualität die Lektüre bietet. Ich denke neben dem Lesen probiert man die Beispiele nebenbei auch aus. Läuft ein Versuch jetzt darauf hinaus das man es nicht versteht oder das Programm eine falsche Ausgabe macht, dann guckt man nach warum, probiert aus oder zieht das Internet zu Rate. Ich denke wie nachtfeuer schon gesagt hat, ist ein Selbstständiges Lernen für Assembler notwendig und wichtig. Gerade wenn man bei null Anfängt.

nachtfeuer schrieb:

... Das heißt, man ist (erstmal) gezwungen, sich diesen roten Aufbauplan selbst zu erstellen, ...

Auf Assembler bin ich nicht gekommen, weil ich unbedingt nebenbei wissen wollte wie eine CPU beziehungsweise der Computer intern funktioniert...

HansKlaus schrieb:

das mmn schönste an assembler ist einfach, daß du quasi nebenbei lernst, wie die cpu bzw. der computer intern funktioniert.

..., sondern wissen wollte was es im genaueren mit der Segmentierung (siehe: Segmentierung) auf sich hat. Ich persönlich finde, dass es sich allein dafür schon lohnt mit Assembler anzufangen. Das wie spielt dabei nach meiner Meinung erst einmal eine Nebenrolle.
Wichtiger ist: Motivation, Durchhaltevermögen und ein wenig Selbstständiges Lernen.

Ich hoffe alle zukünftigen Leser hilft mein Beitrag zu diesem Thema weiter.
Grüße, xpilz

[Ethon]

So.... jetzt ist Wochenende und ich bin in "Kampfstimmung" - nein - kämpfen müssen wir nicht.... Dieses Beispiel ist wirklich nur in 5 mn hingesch@#?+- Was es verdeutlichen soll, ist, dass in bestimmten Bereichen C++ absolut keine Berechtigung hat

Nö, du verstehst das falsch. Höchstens gewisse Bibliotheken und Techniken von C++ haben in gewissen Bereichen keine Berechtigung. I/O-Streams sind da ein Paradebeispiel, die sind saulahm, und du bringst es.
Aber weißt du was witzig ist: Bei I/O intensiven Applikationen zocken sogar die lahmen iostreams deine ASM-Lösung per Syscall ab da du kein Buffering verwendest.
Ergebnis: Deine ASM-Lösung ist sogar lahmer als Java oä. da das Konzept stinkt.

- Und das waren auch die Aussagen meiner vorherigen Posts. Ich denke aber, dass ich jetzt nicht am Zug bin 1000 Lines of C++ Code in Assembler umzusetzen, um zu beweisen, dass C++ im Verhältnis zu ASM von der Effizienz her keine Chance hat... Ich denke, das wird auch so jeder C++ Freak bestätigen.

Und nächster Denkfehler: Du gehst davon aus, dass ein Assembler-Programmierer genau den Prozessor versteht. Das tun aber nur die allerwenigsten, und die sind zu großen Teilen damit beschäftigt C/C++ Compiler zu schreiben.
Simples Beispiel: Machst du ein "mov eax, 0" und der Compiler (da er weiß dass es schneller ist) ein "xor eax, eax", dann ist der C++ Code bereits schneller.
Und das geht in ganz andere Größenordnungen, da es sich ein C++ Compiler leisten kann, absolut unverständlichen und hochperformanten ASM-Code zu erzeugen, den kein Mensch warten wollen würde.

Dann noch weitere Feinheiten, dass der Compiler Instruktionen perfekt anordnen kann usw

Kleine Teile mögen in ASM performanter möglich sein als es ein Compiler hinbekommt (Vor allem wenn man spezifische CPU-Features nutzt, die der Compiler per Default nicht unterstützt, zb AMD 3DNow! oä), in der Regel ist C++ aber schneller, je nach Technik eben.

[masm]

Ethon schrieb:

Aber weißt du was witzig ist: Bei I/O intensiven Applikationen zocken sogar die lahmen iostreams deine ASM-Lösung per Syscall ab da du kein Buffering verwendest.
Ergebnis: Deine ASM-Lösung ist sogar lahmer als Java oä. da das Konzept stinkt.

Man muss halt die richtigen Funktionen verwenden - genau wie es c++, java & co machen - das hat nicht mit der Art zu tun, wie man die Funktionen Aufruft.

Ethon schrieb:

Simples Beispiel: Machst du ein "mov eax, 0" und der Compiler (da er weiß dass es schneller ist) ein "xor eax, eax", dann ist der C++ Code bereits schneller.

Nö, XOR ist bestenfalls gleichschnell. XOR bringt nur etwas, wenn es darum geht Flag-Abhängigkeiten zu brechen.

Ethon schrieb:

in der Regel ist C++ aber schneller, je nach Technik eben.

Hängt vom Compiler und deren Einstellungen ab. Aber grundsätzlich kann ich dem zustimmen: Meiner Erfahrung nach sind Compiler hier und da Schlagbar, im Ganzen sind sie aber dem Assembler-Programmiere deutlich überlegen.

[nachtfeuer]

Ethon schrieb:

...

@Ethon: Es braucht nicht allzulange, um die Assembler Grundlagen zu verstehen, und sich bestimmte Programmiertechniken in Assembler anzueignen. Natürlich nicht in 10 Minuten oder 21 Tagen. Aber vielleicht nicht viel länger als 8 Wochen oder wenn man viel arbeitet, ein viertel oder halbes Jahr für weit fortgeschrittenere Techniken. Auf jeden Fall wird man schneller zum Asm-Profi als man in C++ guter Fortgeschrittener wird.
Umgekehrt helfen einem die Assemblergrundlagen, bessere, stabilere Programme zu schreiben oder Disassemblings viel besser zu verstehen. Und man kann auch aus Asm heraus C-Funktionen aufrufen, wie auch umgekehrt.

Setzt euch lieber hin, nehmt euch die Zeit, um Assembler zu lernen und zu vertiefen. Es ist keine verschwendete Zeit. Wenn dann ein tiefers, geübtes Verständnis über die Assemblerprogrammierung da ist, dann kann man nochmal kommen, und seine eigenen Urteile über Assembler hier im Asm-Forum lesen.
Nur Mut.

[Ethon]

Man muss halt die richtigen Funktionen verwenden - genau wie es c++, java & co machen - das hat nicht mit der Art zu tun, wie man die Funktionen Aufruft.

Naja, alle kochen nur mit Wasser.
In seinem Beispiel hat er write() direkt aufgerufen. Hätte man aus C++ auch können, aber er hat als Gegenbeispiel cout verwendet.
Um fair zu bleiben, hätte er in seinen Code Buffering, Locales etc einbauen müssen. Von daher fand ich den Vergleich schlicht unfair.

Nö, XOR ist bestenfalls gleichschnell. XOR bringt nur etwas, wenn es darum geht Flag-Abhängigkeiten zu brechen.

Du wirst NIEMALS ein "mov REGISTER, 0" sehen, das von einem x86 Compiler erzeugt wurde.
Selbst wenn mov gleichschnell wäre als ein xor(was es wirklich nicht ist), ist ein xor von der Instruktionsgröße her kleiner (1 Byte vs mehrere Bytes).
So Feinheiten, die als Mensch eher unintuitiv sind (obwohl sich das bei dem xor in Grenzen hält), aber für den Compiler ganz normal.

Meiner Erfahrung nach sind Compiler hier und da Schlagbar

Genau, und für das "hier und da" lohnt sich ja auch Assembler, hat schon einen Grund wieso memcpy und Konsorten in ASM geschrieben werden.
Nur nervt es mich tierisch, wenn Leute überall verbreiten wollen, dass Assembler ja soooo viel schneller sei als C etc.

[masm]

Ethon schrieb:

Du wirst NIEMALS ein "mov REGISTER, 0" sehen, das von einem x86 Compiler erzeugt wurde.
Selbst wenn mov gleichschnell wäre als ein xor(was es wirklich nicht ist), ist ein xor von der Instruktionsgröße her kleiner

Die Größe ist heut zu tage nur noch in wenigen Fällen von Bedeutung. Und ganz neben bei, XOR ist grundsätzlich nicht schneller - nur in bestimmten Situation kann es Vorteile bringen es zu verwenden.
Wenn du es nicht glaubst, kannst du es ja mal auf aktuellen Systemen testen.

[dot]

masm schrieb:

Die Größe ist heut zu tage nur noch in wenigen Fällen von Bedeutung.

Ist das so? Ich würde mal behaupten, die Größe ist vor allem heutzutage immer mehr von Bedeutung. Denn die CPUs werden immer schneller, die Speicher aber nicht. Google mal nach Instruction Cache...

[abc.w]

Ich habe mal auf einer CPU Takte für xor gemessen: http://www.c-plusplus.net/forum/237896-full
Es gibt einen Geschwindigkeitsvorteil, wenn man drei mal hintereinander das eine und gleiche Register mit xor nullt, ob es Sinn macht oder nicht - sei dahingestellt. Irgendwas tut sich in der CPU...

Irgendwo im Optimization Manual von Intel steht, dass ihre CPUs eine Art spezielle Unterstützung für xor haben. Vielleicht ein Beispiel, welchen Einfluss ein "Glaube" entwickeln kann. Der Glaube an das gute alte xor bewegt die Chiphersteller, ihre Chips zu modifizieren, damit sie in den Benchmark-Tests ja nicht langsamer abschneiden. Die Benchmark-Tests enthalten ja im guten Glauben lauter xor reg, reg... Die Modifikationen auf dem Chip brauchen mehr Chipfläche, mehr Chipfläche bedeutet mehr Geld - aber dieses Geld werden wir, die Gläubigen an xor, beim Kauf des nächsten PCs ausgeben müssen

[dot]

Das hat nichts mit irgendeinem Glauben zu tun. xor und sub auf das selbe Register haben eine andere Semantik als ein mov 0.

Intel Optimization Manual schrieb:

[...] Furthermore, they do not consume an issue port or an execution unit. So using zero idioms are preferable than moving 0’s into the register. [...]

Assembly/Compiler Coding Rule 36. (M impact, ML generality) Use dependency-breaking-idiom instructions to set a register to 0, or to break a false dependence chain resulting from re-use of registers.

[masm]

dot schrieb:

masm schrieb:

Die Größe ist heut zu tage nur noch in wenigen Fällen von Bedeutung.

Ist das so? Ich würde mal behaupten, die Größe ist vor allem heutzutage immer mehr von Bedeutung. Denn die CPUs werden immer schneller, die Speicher aber nicht. Google mal nach Instruction Cache...

Der (code-) cache ist stetig mit den CPU Generationen gewachsen und, gemäß sein Natur, auch sein Geschwindigkeit. Auser in sehr kleine Schleifen (<= 32Byte), machte meiner Erfahrung nach die Befehlsgröße keinen Unterschied mehr. Typisches Beispiel: add eax,1 und inc eax ... wenn man nicht grade für den Pentium 4 programmiert, ist reine Geschmackssache – einen Geschwindigkeitsunterscheide habe ich in (sinnvollen) Algorithmen noch nie festgestellt (genau wie bei XOR vs. MOV).

[dot]

Intel sieht das anders. Nicht nur bei xor vs. mov, sondern auch bei inc vs add:

Intel Optimization Manual schrieb:

Assembly/Compiler Coding Rule 33. (M impact, H generality) INC and DEC instructions should be replaced with ADD or SUB instructions, because ADD and SUB overwrite all flags, whereas INC and DEC do not, therefore creating false dependencies on earlier instructions that set the flags.

Ich würde mal sagen, gerade in kleinen Schleifen machts keinen Unterschied, weil der ganze Code sowieso im Cache bleibt. Interessant wird das, wenn man mal das Programm als ganzes betrachtet. Die Caches sind nicht wirklich soviel größer, eine SandyBridge CPU hat sogar einen kleineren L2-Cache als mancher Pentium 4. Und selbst wenn, der Speicher ist trotzdem nicht wirklich schneller geworden. Außerdem ist der unterste Cache normalerweise shared und muss alle Cores füttern (mittlerweile gibts da ja mehr als einen von). Und das Problem ist auch nicht der Cache, sondern alles was nicht im Cache ist

[nachtfeuer]

Naja, logisch verknüpfte Operationen wie xor und co gehören natürlich zum Allerletzten, was man bei der Asm-Programmierung lernt, falls überhaupt...Und es hat vermutlich auch noch nie Leute gegeben, die Assembler direkt über den C-Compiler gelernt haben...

Muss das jetzt eigentlich sein, dass ihr euch an so einem Quark festbeißen müsst?
mov ax,0 wird auch gerne für Anfänger geschrieben, die noch gar keine logischen-Verknüpf-Asm-Befehle kennen oder vielleicht um die Lesbarkeit des Codes hier und da zu erleichtern. Früher, in DOS-286 Zeiten, waren xor Befehle schneller, aber mit dem Pentium und stärkerer Risc-Bauform spielen ganz andere Punkte eine Rolle.

Ethon liegt mehrfach daneben, u.a., wie oben schon erwähnt und mit der Annahme, dass heutzutage mit Asm in 286er Realmode Zeit und auf Anfängerniveau programmiert wird und dagegen mit C++ in 2011 mit Performanceoptimierern und Profilern. Viele Asm-Einführungen arbeiten mit Dos auf 286er Niveau und Realmode, einfach, weil es fundamentale Grundlagen sind, die man schnell lernt und die sich relativ einfach auf neuere Entwicklungen übertragen lassen. Das ist so ähnlich, wie wenn beim C++ Anfang nur Konsoleprogramme geschrieben werden. Daraus eine Philosophie über Assembler vs C++ zu entwickeln ist dann so ähnlich tiefschürfend, als würde man schreiben, mit Blitzbasic lassen sich tolle Spiele entwickeln, mit C++ nur Konsolezeugs.

Es ist auch ein Irrtum, zu glauben, dass Assemblerprofis nur in Assembler programmieren und nicht wüßten, was so ein C-Compiler rausspuckt oder umgekehrt, dass gute C-Profis kein Assembler könnten oder bräuchten.

[Ethon_notloggedin]

Naja, logisch verknüpfte Operationen wie xor und co gehören natürlich zum Allerletzten, was man bei der Asm-Programmierung lernt, falls überhaupt...Und es hat vermutlich auch noch nie Leute gegeben, die Assembler direkt über den C-Compiler gelernt haben...

Hey, xor war doch nur ein Beispiel.
Es geht mir einfach um Dinge, die als Mensch nicht direkt intuitiv wirken, gibt ja viel wüstere Dinge, die ein Compiler anstellt.

dass heutzutage mit Asm in 286er Realmode Zeit und auf Anfängerniveau programmiert wird und dagegen mit C++ in 2011 mit Performanceoptimierern und Profilern.

Gibt es denn optimierende Assembler? Wüsste nicht davon, mal einen gesehen zu haben.
Und nein, so schlecht hab ich Assembler nicht dargestellt, und wenn doch, wars nicht beabsichtigt.

Zum Rest: Ich kann durchaus Assembler, Reverse Engineering ist ein Hobby von mir. Trotzdem sehe ich mich durchaus in der Lage C++ Code zu schreiben, der ASM-Code in Sachen Performance nicht nachsteht.

Der einzige Standpunkt, der hier von mir vertreten wird, ist dass ASM kein Muss für möglichst performanten Code ist, mehr nicht.

[nachtfeuer]

Ethon_notloggedin schrieb:

Gibt es denn optimierende Assembler? Wüsste nicht davon, mal einen gesehen zu haben.

Das überrascht leider nicht, denn man sieht den optimierenden Teil in aller Regel im Spiegel.

Ethon_notloggedin schrieb:

Zum Rest: Ich kann durchaus Assembler, Reverse Engineering ist ein Hobby von mir. Trotzdem sehe ich mich durchaus in der Lage C++ Code zu schreiben, der ASM-Code in Sachen Performance nicht nachsteht.

Sag ich doch. Und es ist auch logisch. Du benutzt einen C++ Compiler, der etliche Effizienzevolutionen hinter sich hat, und setzt deine eigenen gegen Null tendierenden Assemblerprogrammierkenntnisse dagegen. (Also wenn dich schon xors im Compilerout überraschen...;) )

Das einzige Heilmittel dagegen ist, mehr zu lernen und mehr zu üben. Ob nun C++, Java oder Assembler, das ist schnuppe. Aber je mehr du weißt(und abguckst) und je mehr du geübt hast, desto effektiveren Code kannst du programmieren.

Es ist aber nicht wirklich schlimm, wenn man mal von Vorurteil zu Vorurteil hier im Asm-Forum hoppelt, das ist das normalste von der Welt