Apfelmaennchen in FASM-Assembler Update incl. FLUG!

Zitat

Und aus inc ax macht ASM.au3 0x6640.

Das 66h (2-Byte) ist ein sogenanntes Override-Präfix. Es wird im großen und ganzen verwendet um auf die Größe des nachfolgenden Operanden hinzuweisen. Das erste Byte modifiziert die Größe der Adresse und das zweite Byte ist für die Größe des verwendeten Registers.
Die Anzeige kommt ganz darauf an, in welchem Modus sich der Prozessor bzw der Debugger befindet (16/32 bit Real/Protectedmode) . So kann man 16/32 Bitcode "mischen"

Thx für den Link, bin zzt an einer SSE2/3-Version, die berechnet 4 Pixel auf einmal, das optimieren der cachelines muss aber noch rein....
Jedenfalls ist es ziemlich flott, allerdings nicht mehr mit dem "Inline"-Assembler zu machen. Aber als Assembler-DLL sollte auch der 64-Bitmode funktionieren.
Allerdings ist das alles nichts gegen eine Demo, welche per CUDA (als superschön lesbarer C-Code) auf einer Nvidia-Grafikkarte läuft. Durch heftigstes Parallelisieren (macht der Compiler selbsständig) und völlig fehlender Hauptspeicherzugriffe (alle Daten liegen auf der Graka) ist der Code dort 40-50x schneller als ein hochoptimierter Code auf einer CPU. Das ist der Hammer!

Aber den Inline-Assemblercode bekomm ich auch noch doppelt so schnell wie zzt^^, dann fehlen nur noch ca.10000% bis zu CUDA...

UPDATE 24/03/2010
Nun ist dank Ward aus dem engl. Forum ein völlig moderner Assembler in AutoIt und auch in das Apfelmännchenscript eingezogen!
Nun ist auch ein "Flug" bis hin zur prozessorabhängigen Genauigkeit von 2e-17 (80Bit) möglich, dabei kann das Fenster in der Größe verändert werden sowie eine andere Farbpalette.

Viel Spass!

Upps, sorry, mein Fehler! Da zzt. nur die 32-Bitversion unterstützt wird, bitte als 32Bit testen!
Das hängt mit der Verwendung der explizit erforderlichen 64Bit Register, der 64-Bit-Übergabeparameter usw zusammen.
aber mit Blick auf die "neuen" DLL- bzw Struct-typen

Zitat von Hilfe zu DllStructCreate()

INT_PTR, LONG_PTR, LRESULT, LPARAM 32 or 64bit signed integer (Je nach dem, ob die x86 oder die x64 Version von AutoIt benutzt wird)
UINT_PTR, ULONG_PTR, DWORD_PTR, WPARAM

kann man da ggf. etwas machen.

Btw, muß man den Pfad zu den 32-Bit-Dll´s (falls verwendet) in einem 32Bit-Script(auf 64Bit-System) angeben, oder nimmt Autoit bzw das BS "automatisch" den richtigen?

thx fürs testen, ggf könntet ihr auch mal ausprobieren, ob es hilft, die Zeile 480

$ret=MemoryFuncCall("int:cdecl", FAsmGetFuncPtr($AsmObj), "ptr", dllstructgetptr($asmstack)) ;Assembler aufrufen und Code starten

zu aktivieren und dafür die Zeile 489 auszukommentieren...

und wenn man schon dabei ist^^, die folgenden Zeilen 282-287 auch gleich auskommentieren, sie regeln den Funktionsaufruf der AutoItfunktion aus dem Assembler heraus....

FasmAdd($AsmObj, " fsave [ebp+40h] ");alle Coprozessorregister und den Copro-stack sichern
FasmAdd($AsmObj, " pushad ");alle Prozessorregister sichern
FasmAdd($AsmObj, " mov eax,dword[EBP+34h] ");Adresse der AutoItfunktion in eax laden, evtl Parameter vorher auf den stack pushen
FasmAdd($AsmOBj, " call eax ");AutoIt-Funktion aufrufen, erlaubt einen Interrupt, ansonsten wäre das Fenster während der gesamten Berechnung blockiert
FasmAdd($AsmObj, " popad ");Prozessorregister alle wiederherstellen
FasmAdd($AsmObj, " frstor [ebp+40h] ");coproregister und coprostack wiederherstellen 60

Und für die Hardcoretester, funktionieren denn die Beispielfunktionen in der fasmdemo.au3?

die fasmdemo.au3 funktioniert aber?

hmmmm, seltsam, der eigentliche Code wurde nicht geändert, der war in 5 min auf den Fasm angepasst, erweitert wurde nur AutoIt-Code
Jedenfalls läuft der Assembler einwandfrei durch, sowohl Oscars als auch Funkeys Bytecode sind genau wie meiner...schade schade, da werde ich wohl jemanden nerven müssen, der mit mir zusammen den Fehler sucht^^
Freiwillige Vor^^

nein, habe sowohl eine amd 4850 @2,8 ghz als auch einen Intel PIII mit 1,2 ghz
Bei Bekannten mit Intel-Laptops funktioniert es jedenfalls....

Ok, vielen Dank fürs Testen,

Zitat

Flug funktioniert bei mir nicht, da wird der Rechner zu schwach sein (AMD XP 2400+).

der Flug sollte aber immer funktionieren, anfangs hagbe ich sogar per sleep() die Framerate auf 25 begrenzt, damit es nicht zu schnell geht.
Später wirde es, je nach Bildausschnitt, ruckelig, da in den "tiefen" (schwarzen) Bereichen pro Pixel bis zu 20.000 Iterationen (innere Schleifendurchläufe) berechnet werden. Beim Flug ist das aus Geschwindigkeitsgründen begrenzt. Beim "normalen" zoomen per Mausklick finden in großen Tiefen mehr als 100k Iterationen/Pixel statt. Dabei wird jedes Mal die Sequenz

while (($x * $x + $y * $y) < $tiefe and $iteration < $maxiteration)
$xtemp = $x * $x - $y * $y + $x0
$y = 2 * $x * $y + $y0
$x = $xtemp
$iteration += 1
wend

durchgerechnet...

Btw. ich war sehr überrascht, daß der 8088-Code mit den "alten" Koprozessorbefehlen (damals schon intern 80Bit) ohne weiteres mit den parallel arbeitenden modernen SSE/SSE2/SSE3-Umsetzungen mithalten kann. Habe dazu eine DLL (auch in Assembler) geschrieben, die Laufzeit ist seltsamerweise fast Identisch. Allerdings wird zwangsläufig beim parallelen Rechnen per SSE nur mit 64 oder schlimmer noch 32 Bit Genauigkeit gerechnet, somit ist dann beim Zoomen wesentlich früher das Ende erreicht. Allerdings muss ich zugeben, daß ich noch nicht auf Zugriffe im Cache (Loop unrolling) optimiert habe, da sollten noch etwas rauszuholen sein. Wenn man bedenkt, daß ein Zugriff in den Hauptspeicher 100 Takte benötigt (die komplette oben gezeigte Schleife benötigt weniger!) und ein Zugriff im L1-Cache nur 1-2 Takte erkennt man das Potential. Moderne C-Compiler optimieren das übrigens automatisch, es gibt nicht viel Leute, die per Assembler schnelleren Code produzieren können....

Zitat

Dann klicke ich in die Gui und ein Teil des Apfelmännchen erscheint (zu groß). Nach insgesamt 5 Klicks wird die Gui dann dunkel.

OK, auch für diesen Hinweis vielen Dank!

Zitat

Ohne _Asmcode_changecolor() läuft es.

Aha! Werde das mal unter die Lupe nehmen. Ich vermute, daß in der Memory.au3 irgendwo der Wurm steckt. Wahrscheinlich gehen die Betriebssysteme >XP wesentlich restriktiver mit ausführbarem Code in nicht extra dafür freigegebenen Speicherbereichen um.
Trancexx aus dem engl. Forum hat dafür eine tolle Methode entwickelt, die auch auf allen BS läuft. Dabei wird der Bytecode (auch von "normalen EXE´s oder DLL´s) vom BS genau wie bei einem normalen Programmstart in den Speicher geschrieben und dort ausgeführt, wen es interessiert, Stichwort "subrogation".

Hier eine Version komplett ohne Assembler-Build also auch ohne die ggf störenden Befehle in der Memory.au3, um den Assembler komplett als Fehlerquelle auszuschalten.
Funktioniert ggf nicht unter 64Bit.
//EDIT noch mehr rausgeschmissen ^^....
autoit.de/wcf/attachment/8396/