Lernkurve Assembler-Tut zu steil?

    Was kann/sollte am Tutorial verbessert/verändert werden, bei welchen Themen gibt es Probleme? 12

    1. Zu schwere Kost, habe Interesse, aber die Beispiele sind zu kompliziert (6) 50%
    2. Zu viel Erklärungen, mehr kleine Beispiele (4) 33%
    3. Bezug zu "realen" AutoIt-Projekten/Funktionen fehlt, die Beispiele sind zu abstrakt bzw.für die tägliche Arbeit nicht hilfreich (4) 33%
    4. Ich finde den Einstieg in Assembler nicht, brauche mehr Informationen/Links zu den Grundlagen/Referenzen (3) 25%
    5. Debugginghilfen fehlen, bei abgestürzten Assemblerscripten keine Rückmeldung über den Fehler (3) 25%
    6. Das Handling mit dem embedded Assembler ist viel zu kompliziert, eine "IDE" würde helfen (2) 17%
    7. Frustfaktor zu hoch bei Fehlschlägen, komme mit einfachsten Sachen nicht weiter (2) 17%
    8. Ich komme gut klar, habe Vorkenntnisse und kann diese nun in AutoIt nutzen (2) 17%

    Hi zusammen,
    nach einigen Rückmeldungen zum Tut habe ich festgestellt, daß es reichlich Bedarf an Verbesserungen/Veränderungen gibt.
    Mit dieser Umfrage möchte ich die bisher zwar interessierten, aber ggf. abgeschreckten User bitten, Vorschläge zur Verbesserung zu unterbreiten bzw. das bisherige Tut zu bewerten. Natürlich könnt ihr auch eure Vorschläge/Kritik hier im Thread posten!
    Es ist möglich, mehrere Antworten zu geben.

    Weiterhin möchte ich bitten, Vorschläge zu AutoIt-Funktionen zu unterbreiten, die einen deutlichen Geschwindigkeitsschub vertragen könnten. Gemeint sind Funktionen die sehr oft in Schleifen aufgerufen werden und die Scripte stark ausbremsen. Also die in Scite "hellblau" angezeigten Funktionen, bspw. zur Umrechnung von Werten wie _ColorConvertRGBtoHSL() oder ähnliches. Ich denke, "praxisnahe" Funktionen in Assembler führen zu einem früheren Erfolgserlebnis bzw. motivieren dazu, weiterzumachen!

    Wie mann sieht komme ich zwar einigermaßen klar aber habe doch schon beim einfachsten mist wie Consolenausgabe etc. schwierigkeiten.
    Und ich steige immernoch nicht hinter was zum beispiel BitOr macht oder was diese 3 Zeilen anstellen

    [autoit]

    FasmAdd($Fasm, "xor edx,edx") ;für Division mit Modulo
    FasmAdd($Fasm, "mov ebx,2");Division durch 2
    FasmAdd($Fasm, "div ebx");dividieren

    [/autoit]


    ebx = 2
    ebx = ebx : ebx ?????
    Aber wenn ich BitAnd richtig verstehe rechnet es nur zusammen also

    0 1 0 0 1 0 1 0
    0 1 1 1 0 1 0 1
    _____________
    0 1 0 0 0 0 0 0
    war das richtig ?

    XOR <> OR (in AutoIt BitOR() )
    Ein XOR mit sich selbst hat als Ergebnis immer Null!

    Irgendwer hat mal postuliert, daß ein XOR Register,Register schneller sein soll als ein MOV Register,0. Ist wohl eine Glaubensfrage... :D

    Bei DIV MUSS(! ) man beachten, dass das EDX-Register elementarer Bestandteil der Division ist! Das heisst, aus den 2 Registern EDX (obere 32 Bit) und EAX (untere 32 Bit) steht nach der Division in EAX der Teiler und in EDX der Rest! Ein MOD sozusagen! Zwangsläufig muss also vor der Division EDX einen Wert haben, damit überhaupt etws vernünftiges rauskommt. Stell dir EDX_EAX als 64 Bit-Zahl vor.
    Als AutoIt-Code also

    [autoit]

    $EDX=MOD($EDX_EAX,$EAX)
    $EAX=INT($EDX_EAX/$EAX)

    [/autoit]

    Wie man hoffentlich bei mir sieht kommenich auch weiter, aber langsam werden mir die Sachen zu kompliziert, zum Beispiel die 128bit auf einmal rechnen ist zu kompliziert (das davor habe ich kapiert, müsste vielleicht noch finit und Mathe von Tunnel angucken, aber ansonsten nur das sse Zeug).
    Wäre nett wenn das nochmal erklärt würde

    Message angekommen! Einfache Beispiele sind schon in der Pipeline^^

    AutoIt Funktionsvorschläge:

    [autoit]


    StringInStr() ; Wenn man das bei einer 800Kb großen Textdatei etwa 500.000 abfragt dauert es immens lange...
    StringReplace() ; Auch sehr Zeitintensiv.
    _ArraySort() ; ...
    Ubound() ; ...

    [/autoit]

    Wenn man diese Funktionen mit FASM realsieren könnte, das währe ein dickes Performance-Pluss :D

    thx für die Vorschläge, aber das muss ich Performancemässig testen, ich hatte gerade die Stringfunktionen als sehr schnell in Erinnerung!
    GGf kann man mit SSE/SSE2 etwas machen, wobei ich annehme, dass bei AutoIt gerade die "Standard"-Stringfunktionen von sehr schnellen C++-Libs profitieren...
    Weiterhin ist das Problem bei grossen Dateien, daß die Daten meist nicht in den/die Prozessor-Caches passen und viel schlimmer, Windows durch die "flexible" Speicherverwaltung auch mal ohne mit der Wimper zu zucken Hauptspeicher auf die Platte transferiert....das kann man in AutoIt übrigens sehr einfach mit dem Erstellen einer großen Struct provozieren.
    Btw, um StringInStr() um den Faktor 3 schneller rennen zu lassen, sollte man unbedingt den Casesense-Parameter auf 1 setzen (so man denn casesensitiv sucht^^)

    Für StringReplace() gilt gesagtes, bei kleinen Strings sehr schnell, bei SEHR grossen Strings frisst das Speicherhin- und hergeschaufel die Performance!

    Mit Arraysort() bin ich schon längere Zeit zu Gange, leider bietet AutoIt keine Möglichkeit, problemlos an die "internen" Speicherplätze der Arrayitems zu kommen. Bis zu einigen verketteten Listen bin ich gekommen, dann hatte ich keine Lust mehr...
    Eine Lösungsmöglichkeit wäre, die Arrays in Structs abzubilden, allerdings wäre dann der sehr schöne Datentyp VARIANT für die Katz, respektive die Möglichkeit, Arrays mit beliebigen Datentypen als Inhalt zu bearbeiten. Hat man allerdings Typen"reine" Arrays (z.B. Integer oder Float), dann wäre Assembler ggf eine Maßnahme. Ob da aber viel bei rumkommt, bezweifle ich. Array in Struct(Speicher) schreiben, Struct sortieren, zurück in Array schreiben dauert einfach zu lange bzw frisst die Performance auf. Für den, dem es egal ist, ob er seine "Items" per dllstructgetdata($array,1,index) oder per $array[index] liest/schreibt (beides übrigens gleich schnell! ), ist bei Typen"reinen" Arrays sicher was zu holen!
    Für Stringarrays gilt das gleiche, wer da eine "langsame" Anwendung hat, immer her damit^^ (unter der Vorraussetzung, auch schon Listen, Dictionarys usw ausprobiert zu haben)

    Zitat von Andy

    Irgendwer hat mal postuliert, daß ein XOR Register,Register schneller sein soll als ein MOV Register,0. Ist wohl eine Glaubensfrage... :D

    Naja OllyDbg schreibt auch XOR Register, Register statt MOV Register, 0.
    Ob es da bei Disassembler noch einen bestimmten Grund gibt ´weiß ich nicht, wahrscheinlich haben es die Entwickler einfach so gemacht :D

    Habe einige Testläufe gemacht und meine Befürchtungen wurden leider bestätigt.
    Das Problem ist nicht der (wirklich sauschnelle) Assemblercode, sondern AutoIt, daß bei einem Dll-Aufruf eine KOPIE der Variablen übergibt/zurückgibt. Da dafür gerade bei extrem großen Strings (habe den gesamten Speicher ausgenutzt) entweder ein Memory overflow, oder eine Auslagerung auf Platte erfolgt, und das Speichergeschaufel SEHR viel Zeit braucht (bei mir ca 1 Sekunde! ) steht das in keinem Verhältnis zur eigentlichen Laufzeit des Assemblercodes. Ich hatte Testweise den Speicher mit einem String gefüllt >>100MB und alle darin enthaltenen Zeichen ersetzt, der absolute worst case also. Die Laufzeit betrug ca 50 ms. Bis allerdings AutoIt den String in die Ausgabevariable kopiert hatte, waren ca. 1-2 Sekunden vergangen!
    Darauf gekommen bin ich, als ich die Stringadresse an das Assemblerscript übergeben hatte und dort nur ein einfaches RET aufrief. Da dauerte der Dll-call über eine Sekunde! Man kann das Vermeiden, indem man eine Struct anlegt und den superlangen String dort hineinkopiert. Allerdings dauert das natürlch genausolange, als wenn AutoIt den String selbst kopiert.....Das wäre also nur dann hilfreich, wenn man immer im selben langen String suchen/ersetzen würde. Weiterhin darf man den String keinesfalls per Rückgabeparameter "str" an AutoIt zurückgeben, da dann eine weitere "Kopie" erstellt wird!

    Wie gesagt, bringt dann evtl. etwas, wenn man die "passende" Anwendung hat. Siehe Beispiel "Pixelsearch" im Assembler-Tut, das macht auch nichts anderes als Bytes zu suchen....