Zum Inhalt springen
L

Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

Assembler Tutorial #1 - Einleitung

The Morpheus Tutorials8:52 109.598 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

Transkriptautomatisch erstellt · 49 Zeilen
Herunterladen
  1. Einen wunderbaren schönen Mittag wünsche ich euch und herzlich willkommen zu einer neuen Tutorial-Reihe. Wir starten dieses Mal mit Assembler.
  2. Assembler ist eine wahrscheinlich sehr ungewöhnliche Wahl für einige, wenn es um Programmiersprachen geht. Denn ja, Assembler ist jetzt nicht gerade das, was wir bei irgendeinem Unternehmen oder sowas antreffen würden.
  3. Aber ihr werdet sehen, Assembler hat auch heutzutage noch seine Daseinsberechtigung. Es ist eine sehr alte Programmiersprache, weil sie auch gewisse Sachen macht,
  4. die man heutzutage einfach weg abstrahiert hat und alles einfacher wird heutzutage. Aber Assembler ist durchaus noch sinnvoll zu lernen, vor allem wenn man sich mit der CPU beschäftigen würde.
  5. Aber zunächst einmal geht es natürlich daraus zu finden, was ist eigentlich Assembler. Und da muss ich gleich sagen, Assembler ist so ziemlich das, was ihr als Maschinen-Sprache wahrscheinlich kennt.
  6. Es ist sehr, sehr maschinennah. Das heißt, ihr arbeitet fast direkt an der CPU dran. Eigentlich ziemlich direkt.
  7. Und das ist ganz toll, weil das hat viele Vorteile, aber leider natürlich auch Nachteile. Denn die CPU versteht eigentlich relativ wenig von dem, was ich jetzt euch erzählen würde.
  8. Gerade die CPU versteht im Endeffekt nur 1.0.1.0. Und Assembler ist nicht 1.0.1.0, aber es geht zumindest in diese Richtung.
  9. Also wir schreiben immer noch normalen Text, aber es ist schon sehr primitiv gehalten und wir haben nicht allzu viele Möglichkeiten. Wir müssen vielleicht über manche Sachen gerade ein bisschen mehr nachdenken, als wir das normalerweise tun würden.
  10. Also speziell wenn ich mir jetzt Pfeifen oder sowas angucke. Genau. Und hier haben wir mal ein kleines bisschen Code in Assembler tatsächlich,
  11. der vielleicht für einige jetzt ein bisschen schockierend ist, aber es ist an sich sogar einigermaßen lesbar. Man kann vielleicht sogar herausfinden, was hier passiert.
  12. Ich will jetzt hier gar nicht genau darauf eingehen. Das ist sowieso nur ein kleines Fragment von dem ganzen Code.
  13. Aber es ist auf jeden Fall mal ein Beispiel und ihr seht vorne haben wir dieses moff, deck, jz, call und so weiter. Das sind die Befehle, die der Prozessor oder die CPU, also das ist quasi dasselbe, die die dann auch wirklich verarbeiten kann.
  14. Ihr seht, diese Serie dreht sich auch sehr viel darüber, wie eigentlich der Prozessor in unserem Computer funktioniert. Und ja, das will ich hier auch noch ein bisschen mit reinbringen in diese Serie.
  15. Denn das ist auch wichtig, wenn man hier irgendwie Assembler verstehen möchte. Und andersrum natürlich auch, wenn man den Prozessor verstehen möchte, hilft es Assembler zu sehen.
  16. Und deswegen eben diese Tutorial-Reihe. So, jetzt haben wir einiges geklärt, was das zum Beispiel ist.
  17. Aber warum würde man sich sowas eigentlich antun wollen? Ich meine, die Nachteile liegen offen auf der Hand.
  18. Wir begehen quasi Selbstmord oder Massachismus, wenn wir Assembler schreiben. Es ist mega anstrengend.
  19. Also da kann man vielleicht fünf Zeilen Code schreiben, braucht dann eine Kaffeepause gefühlt. Es ist super einfach Bugs einzubauen und es ist absolut unleserlich.
  20. Also manche Leute verbringen wirklich nur Zeit damit, Assembler Code zu lesen und dann vielleicht darüber nachzudenken, was man machen könnte. Zudem ist der Code nicht portable.
  21. Das heißt, ihr schreibt wirklich was für diese CPU. Ihr schreibt nicht irgendwie was für alle Systeme, also irgendwie Windows, Linux, Mac oder sowas.
  22. Ne, das könnt ihr vergessen. Ihr schreibt, wenn, dann wirklich nur für einen bestimmten Prozessortypen was. Also zum Beispiel für 64-Bit-Prozessoren von Intel zum Beispiel.
  23. Weil diese 64-Bit-Prozessoren von Intel, die verstehen dann was, was in diese Richtung geht. Zum Beispiel eben.
  24. Und man kann sich natürlich sehr, sehr leichten Details verlieren, wenn man solchen krassen Code auf so engem Raum hat, weil man da echt lange mit einem Fragment auch nur beschäftigt ist.
  25. Das heißt, warum würde man eigentlich sowas überhaupt machen? Naja, ganz einfach. Der Code ist maschinenabhängig.
  26. Das ist eigentlich auch was Gutes, denn wir können damit Input und Output regeln. Wir können sehr, sehr spezielle Software ansprechen.
  27. Wir können zum Beispiel Treiber schreiben, wenn wir das wollen. Also mittlerweile in Linux muss man Treiber auch nicht mehr in Assembler schreiben.
  28. Wir können das Ganze in C schreiben, was aber auch noch ziemlich anstrengend ist. Und in anderen Systemen muss man tatsächlich noch auf Assembler zurückgreifen.
  29. Also speziell wenn ich mir zum Beispiel Game Boy, jeder von euch hatte vielleicht, oder manche von euch hatten vielleicht ein Game Boy, da wurden die Spiele immer noch in Assembler geschrieben, weil sie einfach keine andere Wahl hatten, als die Hardware direkt anzusprechen.
  30. Und das ist mega anstrengend, aber teilweise ist es immer noch so. Also je nachdem, welche Hardware ihr habt, werdet ihr Assembler in die Hand nehmen müssen.
  31. Speziell eben externe Hardware, Treiber oder sowas. Was wir natürlich auch damit machen können, und das ist was, was ich sehr gerne damit mache,
  32. und was ich auch hier auf dem Kanal weiter verfolgen werde, das heißt, da wird es auch bald eine Tutorial-Reihe dazu geben, ist Reverse Engineering bzw. Malware Analysis.
  33. Das bedeutet, ihr könnt den Code analysieren, den andere Leute geschrieben haben und vielleicht dann sogar schon kompiliert haben. Das heißt, ihr habt eigentlich nur eine ausführbare Datei, zum Beispiel eine.exe-Datei, weil mir jetzt, weil das vielleicht das einprägsame Beispiel ist,
  34. und könnt dann daraus wieder Assembler-Code sozusagen bauen und könnt diesen Assembler-Code dann lesen und vielleicht verstehen, was das Ding macht. Das heißt, dadurch könnt ihr dann auch rausfinden, ob das Ding jetzt zum Beispiel böse ist oder gutartig ist,
  35. und je nachdem, zum Beispiel eure kompletten Systemdateien verschlüsselt und ihr dann ein Lösegeld bezahlen müsst, solche Dinge zum Beispiel. Das heißt, da ist es natürlich auch immer noch wichtig, Assembler auch zu können und zumindest lesen zu können.
  36. Also ihr seht, man muss es nicht unbedingt immer schreiben, man kann es auch einfach mal teilweise nur lesen müssen. Man kann mit Assembler-Code unfassbar gut optimieren, da möchte ich gleich noch ein bisschen genauer darauf eingehen, was man da generell als Vorgehensweise machen sollte.
  37. Man kann Compiler-Regeln auch brechen, also zum Beispiel, wenn der Compiler immer sagt, ich rolle Schleifen aus, dann kann man zum Beispiel sagen, und in diesem speziellen Fall machst du das bitte nicht, schlechtes Beispiel, okay, gebe ich zu,
  38. aber man kann halt zum Beispiel einige Regeln vom Compiler einfach umgehen und man kann Code für speziell eine Hardware schreiben, der dann auch unfassbar optimiert sein kann, wenn man das möchte.
  39. Genau, und was ich schon erwähnt habe, wir werden ein höheres Verständnis für den Prozessor erlangen, das heißt, wir werden auch in der Lage sein zu verstehen, warum eigentlich unsere CPU so arbeitet, wie sie eigentlich arbeitet.
  40. Ja, das ist so das Ziel von der Tutorial-Reihe auch, also Reverse Engineering und das ganze Hardware-Zeugs und sowas werden wir nicht machen, wir werden hier wirklich nur Assembler behandeln und dann in aufbauenden Tutorial-Reihen werden wir dann eben vielleicht auf diese ganzen Themen eingehen können.
  41. Außer natürlich das Verständnis für die CPU, das möchte ich hier mit reinbringen. Wunderbar, so, das heißt, was haben wir als Fazit?
  42. Wir dürfen auf keinen Fall Projekte in Assembler schreiben, das ist unfassbar wichtig, weil es einfach nur der Tod ist und das keine Sau machen möchte. Okay, noch kurz ein paar Worte zur Performance.
  43. Ich habe ja gesagt, man kann seinen Code so wunderbar optimieren und so schnell machen, dass man mit den Ohren schlackert. Das Problem ist, dass man das nicht in Assembler alleine tun sollte, das heißt, Code-Optimierung fängt viel früher an.
  44. Code-Optimierung bedeutet, wir schreiben erstmal unseren Code in einer Hochsprache, zum Beispiel in C++. Dann machen wir mit dem Code einfach das, was wir immer machen würden, wir kompilieren ihn und sehen, wie schnell er ist und dann gucken wir, was wir an den Algorithmen machen können.
  45. Das heißt, wenn wir zum Beispiel einen Sortieralgorithmus haben und das ist einfach nur ein Insertion Sort, wer jetzt vielleicht ein bisschen Algorithmik kennt, der weiß, von was ich rede. Das ist einfach ein sehr, sehr primitiver Algorithmus, wenn wir den so drin lassen und dann direkt in Assembler reinspringen und da versuchen zu optimieren, kriegen wir vielleicht 5% Performance raus, wenn wir es gut machen.
  46. Aber wenn wir den Algorithmus optimieren, kriegen wir vielleicht einfach 5 Minuten, je nachdem, wie lange er halt läuft. Also von mir aus 50% schnelleren Code, wenn wir es richtig gut machen.
  47. Und ihr seht, die Algorithmen zu optimieren ist natürlich der allererste Schritt, denn das bringt am allermeisten. Dann können wir hergehen und können den Compiler optimieren lassen, das heißt, Compiler wie GCC oder sowas, die sind schon sehr, sehr gut darin, Code wirklich zu optimieren und zu verschnellern, indem sie verschiedene Tricks anwenden.
  48. Aber das ist, wie gesagt, auch nichts, was ihr machen müsst, sondern das lasst ihr den Compiler machen und anschließend, wenn diese Compiler Optimierung durch sind, dann können wir über Assembler reden. Das heißt, Assembler ist eigentlich der letzte Baustein in der Pipeline sozusagen und deswegen auch sozusagen das letzte, was wir bei Optimierung dann auch machen wollen.
  49. Gut, so das soll es als Einleitung schon mal gewesen sein und ja, ich hoffe, ihr freut euch auf die Serie. Wir hören uns beim nächsten Mal wieder. Bis dann. Ciao.

Zum Nachlesen