C/C++ - Assembler

Wie lange willst du denn für die paar Befehle brauchen? Assembler lesen ist ja nun mit das Einfachste was es gibt. Den Algo dahinter oder den Sinn der Cacheoptimierung wirst du wahrscheinlich nie lernen.

Sone

Den Algo dahinter oder den Sinn der Cacheoptimierung wirst du wahrscheinlich nie lernen.

Pardon? Woher genau weißt du das? Ich habe noch etwa Vierzig bis Fünfzig Jahre vor mir, bevor ich senil werde.

Assembler lesen ist ja nun mit das Einfachste was es gibt.

Du wirst wohl Recht haben.

Verstehen ist aber nicht nützlich, etwas Wissen über die Performance der Operationen wäre schon nicht schlecht, das braucht dann aber etwas mehr als zwei Wochen.

Ich brauche es nur für C++, das ist alles.

Wenn ich mir hier ein paar deiner Postings anschauen, dann komme ich zu dem Schluss dass es bei dir nicht weit her ist mit dem Verständnis der Informatik. Du bist DER Facepalm-Kandidat hier und das mit Abstand.

Sone

Sag mal, wieso postest du das jetzt eigentlich? Haben wir beide was davon, ist dein Penis gewachsen, ...? Wenn du mich Scheiße findest, dann ist das schön für dich, kannst es dir mit Volkard und einer Tüte Popcorn gemütlich machen, aber halt dann gefälligst den Rand, wenn du mir keinen Tipp zum Assembler lernen geben kannst.

dann komme ich zu dem Schluss dass es bei dir nicht weit her ist mit dem Verständnis der Informatik.

Jemand, der so unverblümt seine Meinung kundtut, ist kein Stück besser als ich. Nur weil deine Grammatik in Ordnung ist, heißt das nicht, dass ich dich jetzt ernst nehmen darf.

Bleib ruhig, du kannst ja wahrscheinlich gar nichts dafür. So etwas wie dich gibt es in jedem Forum, ist doch nicht schlimm.

Sone

es sind halt viele neidisch auf sone weil er c++ sehr gut beherrscht und das andere auch wissen lässt. deswegen gibts ständig dämliche kommentare.

Kenner der Neider schrieb:

es sind halt viele neidisch auf sone weil er c++ sehr gut beherrscht und das andere auch wissen lässt. deswegen gibts ständig dämliche kommentare.

Diesen Eindruck macht er auf Anfänger und das ist gefährlich.

Seine Posts sind hauptsächlich Wiedergabe von irgendwo aufgeschnapptem Halbwissen und dementsprechend oft unangemessen, deshalb die dummen Kommentare.

Sone schrieb:

Ich stelle fest, dass immer wieder Performance oder generierter Code daran gemessen wird, wie der generierte Assembler für bestimmte C++-Programme aussieht...

Ist das sinnvoll?

Für Performance selten, da bringen die richtigen Algorithmen meisens 100 mal mehr.

Sone

Ja, aber wenn ich einen Compiler-Bug auf Assembler-Ebene verstehen will..?

dot

vollsinn schrieb:

Sone schrieb:

Ich stelle fest, dass immer wieder Performance oder generierter Code daran gemessen wird, wie der generierte Assembler für bestimmte C++-Programme aussieht...

Ist das sinnvoll?

Für Performance selten, da bringen die richtigen Algorithmen meisens 100 mal mehr.

Und der richtige Algorithmus auch noch richtig effizient implementiert, bringt dann die anderen 100x...

knivil

Ich stelle fest, dass immer wieder Performance oder generierter Code daran gemessen wird, wie der generierte Assembler für bestimmte C++-Programme aussieht...

Btw. Performance wird in Geschwindigkeit gemessen.

Sone

Nun gut, das habe ich offenbar falsch formuliert.

Man sieht sich den Assembler an, um den genauen Effekt des C++-Codes verstehen zu können. Also zum Beispiel was genau optimiert werden konnte.

http://savannah.nongnu.org/projects/pgubook/

Das Buch ist ganz brauchbar. Verwendet wird x86, leider kein x86-64. Trotzdem kein uralter Mist wie viele andere Bücher in dieser Sparte. Ist von 2004. Wenn man die Aufgaben mit x86-64-Assembler macht, lernt man aber auch gleich noch, wo man die dafür nötigen Informationen herbekommt.

Wer weitere Aufgaben will, kann sich mal die Assignments von COS 217 (Princeton) angucken. Die Vorlesung benutzt oben genanntes Buch.

http://www.cs.princeton.edu/courses/archive/spring04/cos217/

gigg

Ein gutes Assembler-Online-Buch (behandelt auch protected mode unter Linux und Windows)

in deutscher Übersetzung:

http://www.drpaulcarter.com/pcasm/pcasm-book-german.zip

Ethon

Ich habe Assembler aus der anderen Richtung gelernt - Reverse Engineering.
Kann dir nur empfehlen dieses Buch irgendwo aufzutreiben: http://www.amazon.de/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817

Im Prinzip ist die Sicht eines Reverse Engineers die Richtige um das zu verstehen was dein Compiler ausspuckt.

habe ASM auch hauptsächlich durch 'Reversing' gelernt.

Ich hab plötzlich Programme wie int main(){printf("Hallo");return 0;} wieder interessant gefunden: man glaubt es kaum, wie viel im Hintergrund passiert, bis so ein Miniprogramm mal läuft.

Ich kann jetzt auch kein spezielles Buch nennen.
Besser ist es, du besorgst dir ein paar Tools (gdb bei Linux, bei Windows von mir aus OllyDbg), und gehst wirklich mal Zeile für Zeile so ein Programm auf ASM Ebene durch.
Schau dir vor allem auch den Stack an, und wie der verwendet wird.
Schau dir auch die verschiedenen Speicherbereiche an, wo liegt das .text Segment, welche Berechtigungen hat dieses Segment, usw...
Wie wird die C Bibliothek geladen.
Wo am Stack liegen die Command Line Argumente?
Wieso kann ich mit geschickten Buffer Overflows die Steuerung über das Programm übernehmen?

Gut, ein Buch das Spaß macht kann ich dir schon vorschlagen:
Hacking: The Art of Exploitation von Jon Erickson
Auch wenn es sich vielleicht so anhört - nein, es ist kein Script Kiddie Buch, sondern erklärt auf sehr spannende Weise Dinge, über die man sich sonst keine Gedanken macht, und zeigt vor allem, was man mit ASM Kenntnissen alles machen kann!

dot schrieb:

vollsinn schrieb:

Sone schrieb:

Ich stelle fest, dass immer wieder Performance oder generierter Code daran gemessen wird, wie der generierte Assembler für bestimmte C++-Programme aussieht...

Ist das sinnvoll?

Für Performance selten, da bringen die richtigen Algorithmen meisens 100 mal mehr.

Und der richtige Algorithmus auch noch richtig effizient implementiert, bringt dann die anderen 100x...

Auch nur, wenn du die ineffiziente Implementierung geschrieben hast.

dsadasda schrieb:

habe ASM auch hauptsächlich durch 'Reversing' gelernt.

Ich hab plötzlich Programme wie int main(){printf("Hallo");return 0;} wieder interessant gefunden: man glaubt es kaum, wie viel im Hintergrund passiert, bis so ein Miniprogramm mal läuft.

Vor allem glaubt man, dass man mit C LowLevel programmiert. Wenn du dann weißt was da alles noch im Hintergrund passiert, bis wirklich ein Buchstabe, der printf Anweisung, auf dem Bildschirm erscheint, weiß man erst, dass die meisten C Programme nur Sachen von einen Library-Funktion aufrufen, die wiederum mit dem Betriebssystem werkeln, die wieder das Bios bedienen. Die ganzen Sachen die man nicht in C sieht sind dann LowLevel.

Für mich gibt es nur eins was LowLevel ist und das ist Assembler. Der Rest ist schon extrem abstrahiert und man weiß nicht was wirklich passiert.

Ethon

blabla.

global _start
extern _puts

section .data
    hello:     db 'Hello, world!',0xA

section .text
  _start:
  push hello
  call _puts
  add esp, 4
  ret

Verrät einem jetzt auch nicht mehr als das C Programm.
Mit dem BIOS kannst du auch mit C arbeiten.
Macht echt keinen Unterschied.