Beiträge von Andy

Nur damit keine Mißverständnisse aufkommen. Ich wundere mich die ganze Zeit darüber, dass hier trotz der zahlreichen Postings noch niemand gemerkt hat, dass #cs/#ce in AlignComment beabsichtigt NICHT beachtet werden!

Wozu auch, welchen Sinn hat es, einen #cs/#ce-BLOCK der beabsichtigt Kommentare oder (wie im Fall von AssembleIt) Code enthält, an einer bestimmten Spalte auszurichten?!

AlignComment macht genau das, was es soll, nämlich die Kommentare nach dem Semikolon auszurichten. Und das fehlerfrei seit 7 Jahren.

Ich habe bisher immer noch keine Zeile AutoIt-Code erhalten, bei der das nicht funktioniert.

Also bevor man hier "Verbesserungen" postet sollte man erst mal ein (einziges) Problem finden...

Zitat von fakeraol

Ich blende z.B. ab und zu größere Source-Bereiche mal mit #cs #ce aus, und reaktiviere die dann u.U. auch mal per ; vor den #ce #ce.

Na und? Das macht dem Script doch nichts. Es geht doch darum, per Tastendruck Kommentare auszurichten.

Schlimmstenfalls stellst du fest, dass mit irgendeinem bisher nicht aufgetretenen Zeileninhalt AlignComment nicht (richtig) funktioniert.

Dann postest du hier diese Zeile und wenn irgendwer Lust hat, dann wird AlignComment geändert oder du richtest bei deinem Script die Kommentare selbst aus^^

"Security" besteht sowieso nicht.

Btw. benutze ich zum "ein/auskommentieren" von Codeabschnitten CTRL+Q, wie im Startpost beschrieben werden diese Zeilen nicht ausgerichtet.

fakeraol ähhh, POST #12

Dort hatte ich bereits geschrieben, dass nach 5 Jahren (mittlerweile sind es 7 Jahre) keine mir bekanntgewordenen Fehler mit demScript aufgetreten sind^^

Zitat von fakeraol

Falls man die Schriftfarbe abfragen kann, könnte man das verwenden.

Ja, das wäre ein Ansatz...dann müsste man die User-Einstellungen abfragen, in Scite die Schriftfarbe für die Kommentare feststellen, und daraufhin ausrichten. Wer Lust hat, kann das gerne tun, ich bleibe beim Hieb auf F4

chesstiger

Ich weiß nicht inwieweit deine "trivialen" Regeln dazu dienen sollen, die Kommentare auszurichten bzw. zu finden.

Aber mach dir darüber keinen Kopf!

Aktuell wäre ein "Tidy" für ASM-Code interessant

Den auf Tastendruck "schön" ausgerichtet und eingerückt würde AssembleIt bestimmt aufwerten

AlignComment funktioniert seit Jahren tadellos, einzig dass F4 mittlerweile in Scite für "Nachrichten" verwendet wird (wer braucht so etwas?!) stößt mir auf, ich habe aber keine Einstellung gefunden, um das zu ändern bzw. aus dem "Extras"-Menü zu entfernen. Egal, die SCITEUser.properties übersteuern glücklicherweise die "darunter" liegenden Einstellungen, von daher kein Problem.

Wessen Herz am "F4" für die Nachrichten hängt, für den ist im Startpost und im Script beschrieben wie der Shortkey geändert werden kann.

Zitat von Oscar

Willst Du Deine 9 Bytes haben, dann musst Du explizit "align 1" angeben:

Ja, MIR ist das klar :o)

Ich kann nur jedem raten, sich bei "gemischten Structs" und deren Übergabe an "fremde" DLLs tunlichst mit diesem Thema zu beschäftigen. Immerhin ist nicht jede DLL mit der "Standard" C++ #PRAGMA Pack() - Direktive kompiliert...und schon gar nicht weiß "jeder", nach welchem System dort in den Structs die Daten "gepackt" werden. Aber dafür haben ja die C(++)-ler die *.h-files. Auch die wollen durchforstet werden....

OT:

Und da fällt mir sofort wieder eine Anwendung ein^^

Man könnte wunderbar Bytes in den ungenutzten Plätzen dieser Structs verstecken und innerhalb der DLL oder eines Programms auswerten. Was man damit alles anstellen könnte...und das alles ohne Buffer-Overflow, denn der Buffer wird ja garnicht overflowed. Ein Buffer-Entry sozusagen

Zitat von Oscar

Somit heißt das wohl, dass der angeforderte Speicher immer auf eine solche Adresse liegt.

Die Frage ist jetzt nur, ob man sich darauf verlassen kann, dass dieses Verhalten bei jedem Hard- und Softwareprodukt so ist.

Was wiederum die Frage aufwirft, wieso, wenn AutoIt die C(++) Funktion malloc aufruft (und somit über eine (die) Systemfunktion ( VirtualAlloc?!) Speicher reserviert) und diesen Pointer dann an DllStructCreate() übergibt, dann diese Speicheradresse nicht xxx-aligned ist?!

Das lässt nur einen Schluß zu, nämlich dass der von DllStructCreate() reservierte Speicher (mit dazugehörigem Pointer) nur Teil einer Speicheranforderung ist, ggf. steht ein Header mit den gesamten Infos zur Struct usw. "vorne dran". Es wurde sicher NICHT "vergessen", diesen Pointer aligned anzupassen. Wie schon bereits von mir beschrieben, war in früheren AutoIt-Versionen der Inhalt der Structs definitiv anders als zur Zeit. Wenn ich da ein DWORD; BYTE; UINT haben wollte, dann hab ich auch 9 Bytes bekommen. Aktuell ist die Struct 12 Bytes lang, und der UINT hat das Offset 8!

Inwieweit das Systemkonform ist, kann und will ich nicht beurteilen, klar ist jedenfalls, dass "gemischte" Structs immer wieder zu Stress bei DLL-Aufrufen führen. qed.

//EDIT

Im Endeffekt bleibt nur, auf DllStructCreate() zu verzichten und sich den Speicher per _MemVirtualAlloc zu reservieren.

Zitat von Bitnugger

Bei mir gab es keinen Registry-Schlüssel für Tidy... habe ihn aber nun angelegt - und wieder mal ist es eine '0', die Ärger macht.

ooops, habe das auch gerade bei einer Neuinstallation von AutoIt auf Win10 festgestellt...macht aber nix, denn diese Zeilen hier

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\AutoIt3Script\Shell\Tidy]

[HKEY_CLASSES_ROOT\AutoIt3Script\Shell\Tidy\Command]
@="\"C:\\Program Files (x86)\\AutoIt3\\SciTE\\Tidy\\Tidy.exe\" \"%1\""

in Scite kopieren, dann daraus eine Datei TIDY.REG erstellen, diese Datei doppelklicken und den Eintrag in die Registry abnicken.

AlignComment ruft dann auch Tidy auf.

Zitat von Oscar

Wenn ich den Speicher per "_MemVirtualAlloc" anfordere, dann bekomme ich immer Adressen, bei denen die letzten 4 Stellen Nullen sind. Ist das normal?

Scheint Systembedingt so zu sein. Man könnte ja eine Funktion schreiben, die das überprüft und ggf. aligned...auch auf XP und Win7/8/ME und was es sonst noch so gibt. Ich habe ehrlich gesagt keine Lust mehr, mich mit den AutoIt-DEV-gemachten Unzulänglickeiten rumzuschlagen, ich schreibe einen Fix und wenn nach einigen Jahren dann rauskommen sollte, dass ich den aktuell nicht mehr brauche, dann ist das dann eben so. Aber bis dahin kann ich entspannt die Rückmeldungen zu den aufgelaufenen Problemen der neuen Versionen beobachten und meine bisherigen Programme (hoffentlich) weiterbenutzen.

richtig...

Sollte so sein, ist aber ein Bug. Wird auch nicht mehr gefixt, habe ich schon vor Jahren gemeldet. Juckt mich nicht, habe ich mir eben eine eigene Funktion zum alignen geschrieben.

Dllstructcreate hat sowieso einige haarsträubende "Eigenheiten" in den letzten AutoIt-Versionen verpasst bekommen, die in den früheren Versionen definitiv nicht so waren....

Zitat von Zitat aus der Hilfe

The alignment of an array is the same as the alignment of one of the elements of the array.
The alignment of the beginning of a structure is the maximum alignment of any individual member.
Each member within the structure is be placed at its proper alignment as defined in the previous table, which require implicit internal padding, depending on the previous member.
Structure size is an integral multiple of its alignment, which requires padding after the last member.

Und das auch noch unterschiedlich, ob 32- bzw. 64-Bit. Viel Spass!

$array=stringsplit($sText,chr(0),3)
_arraydisplay($array) ;oder
msgbox(0,0,$array[0])

...oder so...

Zitat von fakeraol

Hab den Regexp-Tester aus der Hilfe jetzt mal entsprechend Oskars Vorschlag umgebaut. Das Ergebnis ist ebenso unbefriedigend. Die Radio-Controls springen auf und ab und überlagern sich teilweise beim Resizen:

was sich bei mir (Win10) beheben lässt durch weglassen von GUI_DOCKSIZE, also

$returnGroup = GUICtrlCreateGroup("       Return Flag", 10, 280, 125, 120)
    GUICtrlSetResizing (-1,$GUI_DOCKSIZE + $GUI_DOCKLEFT)
Global $Radio_0 = GUICtrlCreateRadio("Match", 15, 300, 115, 18)
    GUICtrlSetResizing (-1, $GUI_DOCKLEFT)
Global $Radio_1 = GUICtrlCreateRadio("ArrayMatch", 15, 318, 115, 18)
    GUICtrlSetResizing (-1, $GUI_DOCKLEFT)
    GUICtrlSetState($Radio_1, $GUI_CHECKED)
Global $Radio_2 = GUICtrlCreateRadio("ArrayFullMatch", 15, 336, 115, 18)
    GUICtrlSetResizing (-1, $GUI_DOCKLEFT)
Global $Radio_3 = GUICtrlCreateRadio("ArrayGlobalMatch", 15, 354, 115, 18)
    GUICtrlSetResizing (-1, $GUI_DOCKLEFT)
Global $Radio_4 = GUICtrlCreateRadio("ArrayGlobalFullMatch", 15, 372, 115, 18)
    GUICtrlSetResizing (-1, $GUI_DOCKLEFT)

Hi zusammen,

nach einigen Stunden experimentieren habe ich den Grund gefunden, wieso der von mir heruntergeladene vorliegende OpenCL-Kernel ab einer bestimmten Menge zu sortierender Daten fehlerhaft (genauer gesagt, gar nicht mehr) sortiert.

Die GPU hat viele kleine Prozessoren (Work-Units), welche dafür ausgelegt sind, GLEICHZEITIG ein Problem zu lösen.

Der vorliegende OpenCL-Kernel für RadixSort ist gewissermaßen "nur" eine Umsetzung eines Standard C(++)-Codes für die CPU. Ergo viele ineinander verschachtelte For/To-Loops. Die Laufzeit auf einer einzelnen GPU-WorkUnit dauert irgendwann recht lange (bei mir ca. 3-4 Sekunden) , und der OpenCl-Treiber bricht daraufhin die Berechnung ab!

Dieses Abbrechen durch den Treiber hatte ich bisher noch nie feststellen können, idR. laufen die Kernel ja in einigen Mikrosekunden bzw. noch kürzer. IdR. dauert der Transfer von bspw. Bilddaten aus dem RAM zur GPU länger als die Berechnung bspw. eines Filters auf der GPU!

Läuft der Kernel auf einer CPU mit "wenigen", d.h. 4-8 Kernen, dann ist Algorithmusbedingt die Laufzeit sowieso SEHR lange, d.h. bis zu mehreren Minuten. Der Treiber bricht auf den von mir getesteten CPU´s den Lauf allerdings NICHT ab!

Es wird also ein Kernel gesucht, welcher die GPU bestimmungsgemäß auslastet....

Etliche im Netz verfügbare Kernel haben genau das oben beschriebene Problem.

Zitat von Oscar

Für einen String, der beispielsweise 33 Byte lang ist, muss ich also 48 Bytes reservieren und den dann auch noch auf eine 16-Byte-Adresse ausrichten?

Exakt. Dafür bearbeitest du aber 128Bit / 16 Bytes/ 8 Words / 4 Dwords oder 2 Qwords mit einem SSE-Befehl in einem einzigen Takt!

Am Anfang des Scriptes einen String aus 16 Nullbytes erstellen und dann an den String anhängen wäre auch eine Möglichkeit.

Zitat von Oscar

Und wie sieht das mit der Übergabe bei AutoIt aus? Zum Beispiel bei der obigen Stringübergabe. Die Adresse scheint 16-Byte-aligned zu sein, aber ist auch die Größe korrekt?

Keine Ahnung, ob Strings 16-Byte aligned in AutoIt angelegt sind. Könnte man mal eruieren. Da AutoIt imho auf C++-Füßen steht, könnte das sein....Sagen wir mal so, wenn ICH einen Compiler geschrieben hätte, dann wären alle dessen Daten grundsätzlich aligned angelegt^^. Könnte ja sein, dass jemand ausnahmsweise mal "schnelle" Routinen schreiben wollte und sich keine (kaum) Gedanken über Prozessorcache usw. machen will/muss

Na klar! Also passt man die Größe des Speicherbereichs entsprechend an. Und natürlich auch die 16-Byte-aligned Startadresse. Dafür hatte ich die Funktion _dllstructcreate64() in AssembleIt vorgesehen.

Dort hinein die Daten, und alles geht glatt.

Bei Bitmaps ist es einfacher, der Startpointer ist durch die entsprechenden GDI-Funktionen immer 16-Byte-aligned.

Über die Länge der Bitmap kann man auch festzustellen, ob und wieviele Bytes ggf. "anzuhängen" sind, um eine glatt durch 16 teilbare Größe zu erhalten.

Für die Verwendung von 256-Bit (das sind die YMM-Register für den 64-Bit-Modus von SSE) oder gar 512-Bit AVX gilt entsprechendes!

Zitat von Oscar

Naja, ab welcher Stringlänge macht sich eine solche Optimierung denn bemerkbar?

Es geht um Clockticks pro Zeichen, je weniger, desto besser. Bei langen Strings werden deshalb bei guten String/Textbe-(bzw. ver-)arbeitungsprogrammen die Stringlängen genau EIN MAL berechnet und dann im Handle mit abgespeichert. Jede Funktion bekommt somit mit einem DWORD-Zugriff die Länge des Strings. Jeder Tastendruck, um einen Buchstaben bspw. ein Zeichen irgendwo einzutippern, erhöht dann auch automatisch den Stringlen-Counter.....

Zitat von Oscar

test byte[eax+ecx],0xff ; wenn "Zeichen and 0xff" <> 0

Auf das TEST wollte ich dich auch schon aufmerksam machen, gerade bspw. Test eax,eax (prüft eax auf 0 ) benötigt nur 2 Bytes in der Prozessorpipeline und einen Takt.

Hi,

Zitat von Oscar

Wie übergibt man Strings von AutoIt an Assembler?

Hier habe ich das schon mal behandelt. Zu beachten ist, dass AutoIt bei Verwendung von Pointern auf Variablen immer (!) eine Kopie anlegt, mit dessen Pointer dann gearbeitet wird. Dann reduziert sich das Script zu

#AutoIt3Wrapper_UseX64=n                          ; 32Bit-Modus
#include "assembleit2_64.au3"         ; <- Achtung! Pfad evtl. anpassen!
#Region ASM-Code
#cs StringCompare
    Use32                                         ; 32Bit Modus!
    mov esi,[esp+4]                               ; esi = String1 (Pointer)
    mov esi,[esi]    ;<--Pointer auf den Pointer!!!
    mov edi,[esp+8]                               ; edi = String2 (Pointer)
    mov edi,[edi]
    mov eax,esi                                   ; eax = esi (fuer StringLen)
    call StringLen                                ; die Laenge von String1 ermitteln (Return = ecx = Anzahl der Zeichen)
    mov ebx,ecx                                   ; und in ebx merken
    mov eax,edi                                   ; eax = edi (fuer StringLen)
    call StringLen                                ; die Laenge von String2 ermitteln (Return = ecx = Anzahl der Zeichen)
    cmp ecx,ebx                                   ; die beiden Laengen vergleichen
    jae @f                                        ; wenn String2 laenger oder gleich lang, dann ueberspringen
        mov ecx,ebx                               ; ansonsten Stringlaenge von String1 nach ecx
    @@:
;~     _ASMDBG_(); debug-gui anzeigen
    cld                                           ; Direction-Flag loeschen
    repe cmpsb                                    ; die Strings vergleichen (repe = wiederhole so viele Zeichen, wie in ecx vorgegeben)
    jb @below                                     ; wenn kleiner, dann springe zu @below
    ja @above                                     ; wenn groesser, dann springe zu @above
                                                  ; ansonsten
        mov eax,1                                 ; wenn String1 = String2, dann eax = 1
        ret                                       ; zurueck zu AutoIt
    @above:
        mov eax,2                                 ; wenn String1 > String2, dann eax = 2
        ret                                       ; zurueck zu AutoIt
    @below:
        mov eax,0                                 ; wenn String1 < String2, dann eax = 0
        ret                                       ; zurueck zu AutoIt
    StringLen:
        xor ecx,ecx                               ; ecx = Counter (auf 0 setzen)
        @CountLen:                                ; Schleife
            cmp byte[eax+ecx],0                   ; wenn das Nullbyte erreicht wurde
            je @CountEnd                          ; dann Schleife beenden
            inc ecx                               ; ansonsten ecx++
            jnz @CountLen                         ; wenn ungleich 0, dann @CountLen
            ret                                   ; wenn kein 0-Byte vorhanden, dann return (ecx = 0)
        @CountEnd:
        inc ecx                                   ; ecx++ (Nullbyte mitzaehlen)
        ret                                       ; return = ecx = Anzahl der Zeichen
#ce
#EndRegion ASM-Code
Global Const $aCompare[] = ['<', '=', '>']
Global $aString1='Das ist ein Text.1'
Global $aString2='Das ist ein Text.2'

$ret = _AssembleIt2("dword", "StringCompare", "str*", $aString1, "str*", $aString2)
ConsoleWrite(StringFormat('StringCompare: String1 %s String2\n', $aCompare[$ret]))
$ret = _AssembleIt2("dword", "StringCompare", "str*", $aString2, "str*", $aString1)
ConsoleWrite(StringFormat('StringCompare: String2 %s String1\n', $aCompare[$ret]))

Bei "kleinen" Daten wie int/float/dword oder Strings mit Größen von einigen Bytes usw ist das idR kein Problem, aber bei großen Strings übersteigt teilweise das Erstellen der Kopie in AutoIt die Laufzeit des ASM-Programms!

Nach Möglichkeit sollten daher bei großen Datenmengen die auch noch mehrmals bearbeitet werden sollen, wie auch im oberen Script gezeigt, die Daten in "eigene" Structs gepackt werden.

Btw. ist die Programmierung der "schnellsten" Stringlen-Funktion eine Aufgabe für ASM-Programmierer seit anbeginn aller Zeiten...und ein guter Einstieg in die Verwendung von SSE...16Bytes auf einen Schlag vergleichen FTW

Zitat von Musashi

Mir fällt, offen gesagt, kein plausibler Grund ein, warum sich die Qualität der Dokumentation im Rahmen der Revisionen derart verschlechtert hat - oder wurde sie absichtlich verschlechtert !?.

Tja, mit dem weiteren Hintergrundwissen, dass zu den ursprünglich in diesem Dokument verwendeten 128-Bit Befehlen die (zugegeben in der Funktion, aber NICHT in der Anwendung (!) ) erweiterten 256-Bit-SSE- und 512-Bit-AVX-Befehle "dazugeschustert" wurden, gehe ich persönlich davon aus, dass dort einfach jemand keinen Bock hatte, ein gutes und lesbares Dokument entsprechend zu erweitern sondern seinen eigenen Mist verzapft hat.

Ich jedenfalls weigere mich, mit solch einem unzumutbaren Müll zu arbeiten. Ich bin seit vielen Jahren AMD-Fanboy und kann mir daher auch rückblickend ein Urteil erlauben. TYPISCH AMD! Anfangs ein innovatives TOP-Produkt entwickeln und auf den Markt bringen, aber letztendlich mit aller Gewalt vermeiden, dass es zum durchschlagenden Erfolg wird! Das ist seit jeher so! Da fehlen Treiber oder funktionieren nicht (richtig) und man wartet monatelang auf Updates, Dokumentation ist grottenschlecht bzw. meist garnicht vorhanden, und "Support" ist völlig unbekannt...

Wie das marktwirtschaftlich "richtig" gemacht wird, zeigt Intel jedes Jahr aufs neue mit Milliardengewinnen. Das Produkt performancetechnisch nicht oder nur marginal weiterentwickeln aber massiv die Werbetrommel rühren. Doc´s sind schon bei Produktstart fast vollständig und benutzbar (bis auf SSE/AVX :o) ), man stellt für seinen Prozessor die besten Compiler und Bibliotheken zur Verfügung und eine effektive Kundenbetreuung ist selbstverständlich! Preis?! SPIELT ÜBERHAUPT KEINE ROLLE!!!

Übrigens sei dem Interessierten ans Herz gelegt, zu den SSE/AVX-Befehlen die entsprechenden Intel-Doc´s anzuschauen. Nicht bebildert, wall of text....man könnte meinen, Intel hätte den für diesen Mist verantwortlichen Mitarbeiter bei AMD eingeschleust, um deren "bessere" Dokumentation an den Marktführer "anzupassen"

Btt.:

Zitat von Musashi

Anschlussfrage (hoffentlich nerve ich Dich nicht ) :

Wie sieht es mit den Volumes 1,2,3 und 5 aus. Wären auch hier die älteren Revisionen vorzuziehen, und falls ja, hättest Du die Downloadlinks ?

Du nervst nicht.

Bzgl. der Revisionen sollte sich jeder ein eigenes Bild machen. Leider wird das dadurch erschwert, dass die älteren Versionen nicht mehr downzuloaden sind. Imho wurden noch vor einigen Jahren auf der Website die früheren Revisionen verlinkt. Ich jedenfalls finde diese Versionen nicht mehr.

Definitiv hat ein Compiler große Schwierigkeiten, SSE- bzw. AVX-Befehlsketten ein(bzw. um)zusetzen. Daher sind gerade in diesem Segment durch "handoptimierten" Code massive Performanceschübe möglich! Intrinsics sind genau dafür eingeführt worden!

Zitat von Musashi

Irgendwie komme ich, trotz Zeitmangel, doch etwas auf den Geschmack .

Hau rein

Zitat von Musashi

Wenn Du schreibst, dass die alten AMD-Docs um Klassen besser sind, meinst Du das im Vergleich zu den aktuellen Revisionen dieser Docs, oder zu neueren Dokumentationen im Allgemeinen ?

Ich meine die 128Bit-Media-Instructions, also die Referenz der SSE-Befehle Public.nr. #26568. In den neueren Versionen ist keine einzige (!) grafische Entsprechung. Kein Wunder, dass so gut wie niemand diese Befehlserweiterungen nutzt, übrigens auch per Intrinsics aus diversen Hochsprachen heraus, wenn niemand auch nur annähernd lt. der Beschreibung in der Lage ist nachzuvollziehen, was diese Befehle überhaupt bewirken!

Der Witz dabei ist, dass jeder sofort anhand der grafischen Entsprechung im Debugger SEHEN kann, wie die Inhalte der 128-Bit-Register aussehen sollten.

Siehe Eukalyptus´Shuffle-Script. Da sieht jeder sofort durch und "sieht" auch direkt den Befehl, den man benutzen muss um eine bestimmte Aktion auszulösen....

pasted-from-clipboard.png

Da lese ich nicht mal mehr den Text sondern suche in den Doc´s nur noch nach den entsprechenden "Bildern". Die kann man sich auch merken, wenn man diese Befehle nicht oft benutzt, so nach dem Motto "...habe ich doch schon mal irgendwo gesehen...."

Wie gesagt, alle diese SSE-Befehle sind (mindestens) per Intrinsics in C++ bzw. den gängigen Compilersprachen nutzbar!!! Verwendung dort...so gut wie NULL! Wieso?....Siehe die "neuen" entsprechenden Beschreibungen....Von AVX ganz zu schweigen....

Hi!

Ich hatte im vorigen Post die (alte) PDF-Datei von AMD mit den 128-Bit-Erweiterungen, also die SSE-Befehle, angehängt.

Ich finde diese PDF deshalb klasse, weil bei den Funktionen sämtliche Vorgänge der Register(inhalte) untereinander bebildert sind. Ich frage mich immer wieder, wie viele "Freaks" die aktuellen Doc´s von Intel und AMD in die Ecke feuern, weil definitiv KEIN MENSCH anhand der dortigen "Erklärungen" weiß, was in einem Register abläuft. Ein Bild sagt mehr als 1000 Worte!

Zitat von Oscar

Leider ist die Lernkurve bei Assembler ja recht steil. Im Gegensatz zu AutoIt findet man recht wenig passende Dokus.

Du hast ja beeindruckend gezeigt, dass es trotzdem geht. Assembler ist ja kein Hexenwerk entgegen den heutzutage gängigen Programmiersprachen. Du hast eine Handvoll Register, den Speicherplatz und eine Handvoll EINFACHER(!!!) Befehle was gemacht werden soll.

Schlimmstenfalls muss man den Debugger bemühen. Und sich das Vorher-Nachher-Ergebnis anschauen....und "Bugs" GIBT ES NICHT!

Um etwas tiefer einzusteigen, empfehle ich die Beiträge, Manuals und Doc´s von Agner Fog. Sowohl für Compilerverwender als auch für die hardcore-ASM-Freaks ist das alles Stoff für unter das Kopfkissen

Zitat von Oscar

Die XMM-Register sind ja 128 Bit breit. Ich kann also 128 Bit (4 DWORDs) in einem Rutsch aus dem Speicher lesen.

Aber wie komme ich an die einzelnen DWORDs ran?

Bei SSE gibt es sicher 20 unterschiedliche MOV(XXX)-Befehle. Alle transferieren Speicherbereiche in Register bzw Register in Register. Das einzige, was beachtet werden muss ist das sog. alignment des Speicherzugriffs auf 16-Byte-Adressen. Aber auch für unaligned Speicherzugriffe gibt es (etwas langsamere) Befehle.

Um 4 DWORDS aus dem Speicher in ein Register zu schieben, bietet sich MOVDQU (das U für Unaligned) an. Bei Bitmaps liegen die Daten oder Pixel idR. hintereinander im Speicher. Da die Bitmap beim Erstellen durch GDI(plus) glücklicherweise schon 16-Byte aligned angelegt wird, bietet sich zum blockweisen auslesen von 4 dword/int/uint usw. der aligned Zugriff, also MOVDQA, an.

Aber das ist schon die hohe Kunst. Zum Erstellen von einfachen Tests und Programmen verwende einfach immer die Unaligned-Befehle, die Handvoll Speichertakte für den "länger dauernden" Zugriff sind meist die Mühe durch den Absturz(!) nicht wert. Beim aligned Zugriff auf eine unaligned Adresse folgt nämlich der Absturz, man bemerkt seine Fehler SOFORT deutlich

Übrigens macht es durchaus Sinn, die SSE-Befehle nur auf einen Teil der 128 Bit anzuwenden, viele Compiler machen das so, da die SSE-Befehle in einer eigenen Pipeline im Prozessor laufen und zu allem Überfluss auch noch extrem schnell abgearbeitet werden, idR. für die Standard-Befehle nur EIN Prozessortakt! Übrigens kann man die Registerinhalte, also die DWORDS, BYTES usw. innerhalb der Register beliebig anordnen, Eukalyptus hier aus dem Forum hat dazu ein wunderschönes AutoIt-Script erstellt.

Wenn du Fragen hast, egal zu was, bitte fragen! Ich weiß zwar nicht (mehr) viel, aber habe eine umfangreiche Sammlung von Dokumenten, Scripten und Tips und Tricks.

Und da du ja fit in C(++) bist, die Seite https://godbolt.org zeigt dir anschaulich, was diverse Compiler aus C++-Code machen, und wie mies dieser dann oft ist! Das "rumspielen" mit Compilerschaltern ändert dann oft das Compilerverhalten und zeigt meist auf den ersten Blick den "besseren" Code!

Oscar, TOP ASM-Code, handoptimiert und mit Multithreading den letzten Schliff gegeben.

Bin mal gespannt wo das endet....

Zitat von AspirinJunkie

Ein Radix-Sort sollte man auch noch selbst in OpenCL implementieren können.

hehe, da bin ich gerade dabei...und zwar den vorliegenden Kernel zu debuggen. Ich sehe da aber schon großes Potenzial in einer etwas anderen Umsetzung. Wenn man auf der GPU schon viele WorkUnits hat, dann muss man die auch ALLE gefälligst arbeiten lassen...und nicht nur zweien VIEL Arbeit aufhalsen!