Beiträge von Andy

Zitat von AspirinJunkie

Wäre >>Ghidra<< von der NSA evtl. etwas was dir weiterhelfen könnte?

Hehe, das ist wie IDA Pro auf Speed . Komplett das look&feel abgekupfert und dazu noch getuned....

Der Decompiler ist auch sehr nützlich.

Zitat von AspirinJunkie

Die Optimierung erfolgt auf vielen verschiedenen Ebenen. Einmal natürlich auf algorithmischer Ebene.

Oh ja! UND auf Prozessorspezifischer Ebene. Ich hatte schon in den Compilerflags des GCC gestöbert und dort festgestellt, dass man explizit für bestimmte Prozessorgenerationen (bspw. Sandy Bridge, Haswell, Sky Lake, Bulldozer uswusf.) optimieren kann, und siehe da, in der libopenblas.dll sind reichlich Einsprungpunkte mit diesen Namen und, wie erwartet, für diese Prozessorgeneration optimierter Funktionscode.

Wenn ich das so grob überblicke, dann wurde sich echt Mühe gegeben . Im 64-Bit-Modus gibt es neben den 16 128 Bit breiten XMM-Registern noch etliche andere, bei AVX bis zu 32 512 Bit breite Prozessorregister https://de.wikipedia.org/wiki/Advanced_Vector_Extensions

Zitat von Wikipedia

Bei AVX-512 sind es aufgrund der Registerbreite von 512 Bit damit pro Befehl acht Additionen in doppelter Genauigkeit oder 16 Additionen in einfacher Genauigkeit.

Wohlgemerkt in EINEM Prozessortakt (in der Theorie^^). Davon wird definitiv gebrauch gemacht, wer also einen aktuellen Prozessor hat, der bekommt ggf. allein durch die Befehlserweiterung schon einen Geschwindigkeitsvorteil, wer (so wie ich^^) eine alte Gurke als Prozessor hat, der bekommt auch dafür den optimalen (?!) Code compiliert! TOP!

Es werden also Anwendungen mit der OpenBLAS gesucht, bei denen man dann hier im Forum bspw. Geschwindigkeitsvergleiche der Prozessoren anstellen könnte.

Fairerweise müsste man dann ggf. aber auch überlegen, eine CUDA- oder OpenCL-Bibliothek mit den in OpenBLAS verwendeten Funktionen einzusetzen. https://github.com/xianyi/clOpenBLAS oder https://github.com/CNugteren/CLBlast

Meiner Erfahrung nach würde eine 100€ Grafikkarte bzw. eine in den Prozessor integrierte GPU die schönen neuen 1000+€ teueren CPU´s um mehrere Faktoren abhängen...aber womit soll dann INTEL sein Geld verdienen

https://cnugteren.github.io/clblast/clblast.html , dort mal eine GTX750Ti (2015) mit einem Intel Skylake (2015) vergleichen....da ist die Graka Faktor 5-10(!) schneller

Zitat von AspirinJunkie

Die Abarbeitung erfolgt so, dass die Prozessorcaches möglichst optimal genutzt werden.
Hierzu gibt es ein sehr bekanntes Paper von Goto, wo beschrieben wird wie er damals vorgegangen ist

Ich empfehle die Optimization Manuals von Agner Fog https://www.agner.org/optimize/ , der nicht nur ein Computer-Nerd ist https://www.agner.org/cultsel/?e=0#0

Zitat von Schnuffel

Dazu braucht es aber den Blick auf das Problem und nicht auf die bereits eingeschränkte Lösungsfindung des Thread Erstellers.

Das nennt man das XY-Problem: https://de.wikipedia.org/wiki/XY-Problem

ja, jetzt funktioniert der Download....

Was aber auch nicht nachvollziehbar macht, warum es für 32 Bit keine libopenblas32.dll gibt und für 64 Bit eine libopenblas64.dll

Wenn schon für unterschiedliche Architekturen compiliert wird, dann sollte man auch die Dateinamen unterscheiden können....

Clevererweise, WENN man schon meint, EINEN Dateinamen verwenden zu müssen, dann compiliert man 32-Bit und 64-Bitfunktionen mit gleichem Namen (ja das geht!!) in EINE Datei und lässt die Architektur entscheiden....

Selbst in solch belächelten Programmiersprachen wie Interpreter-Scripting AutoIt gibt es eine If @AutoItX64 then....

Zitat von AspirinJunkie

verwendete die UDF bisher RtlCopyMemory, was aber offensichtlich für 32 Bit-Programme gar nicht zur Verfügung steht.

oder durch RtlMoveMemory ersetzen....

Habe aktuell nicht viel Zeit, aber ich möchte sehen, was die einzelnen Funktionen können (seitens Geschwindigkeit s. Assemblerfunktion zum Aufsummieren direkt in AutoIt )

Da meine (kostenlose) Version von IDA Pro nur 32-Bit disassemblen kann, hat ggf. jemand die Möglichkeit bzw. eine Software, die 64-Bit-libopenblas.dll zu disassemblieren mit ähnlichem Funktionsumfang wie IDA Pro?

Hi,

beim Download der libopenblas.dll von https://github.com/OpenMathLib/OpenBLAS/releases funktioniern nur die x64-*.dll-Dateien.

Dazu muss dann aber auch im AutoItscript #AutoIt3Wrapper_UseX64=y gesetzt werden.

Die x86*.dll lässt sich, zumindest aktuell bei mir, nicht downloaden...

Lt Beschreibung in den make-Files ist es möglich, die libopenblas.dll u.a. auch für "neuere" Prozessoren kompilieren zu lassen, also auch Unterstützung von bspw. AVX512. Die Dll soll dann automatisch die zum Prozessor passende Funktion auswählen....schaumamal^^

Da ich mit der Rückmeldung des godbolt nicht wirklich weiter kam, habe ich mich etwas in C geübt und mit den Intrinsics gearbeitet. Letztendlich ist die godbolt-Websiteversion sowohl von der Speicherverwaltung als auch von der Codeausführung aka Laufzeit sehr eingeschränkt. Aber die Aktualität des Compilers und die einfache Programmierung, Code eingeben und läuft automatisch, ist schon klasse!

Der lokale GCC im Visual Studio Code ist aber auch flexibler und hat keine Einschränkungen an Speicher und Codelaufzeit.

Die "Additionsfunktion" mit AVX-Befehlen ist sehr schnell (je 4 Doubles aus dem Speicher werden in einem Prozessorbefehl zu 4 Doubles im Register dazuaddiert), beim Suchen nach Optimierungen (bin ja nicht der C-Freak!!!) habe ich meine Unterlagen dazu von Agner Fog durchforstet und bin u.a. auch hierüber gestolpert....ohne Worte...es gibt doch noch Typen die (erfolgreich) Prozessortakte zählen :o)

Siehe Antwort von Peter Cordes: https://stackoverflow.com/questions/3191…of-doubles-in-c und ggf. noch seine "improved version", wo die Compilerflags und deren Sinn und Unsinn explizit erläutert werden!

Dieser Code läuft übrigens in godbolt-Webversion

//EDIT

AspirinJunkie , mittlerweile bin ich so weit, dass man überlegen sollte, den "guten" ASM-Code durch einen Filter zu jagen und entweder lokal per AssembleIt oder mit einem online-Assembler assemblieren zu lassen.

Die so erhaltene Binary per DllCallAddress aufrufen, fettich. Ich habe es leider nicht geschafft einen Assembler zu finden, der den von godbolt erstellten ASM-Code (egal ob Intel- oder AT&T-Syntax) ohne Änderungen in eine Binary verarbeiten kann...

Ich teste gerade diverse Assembler g++ usw.

Ich kann in keinster Weise nachvollziehen, wo das Problem ist, den asm-code eins zu eins in die Opcodes zu überführen...jeder fu**ing 50 Jahre alte Assembler kann das.

Zitat von AspirinJunkie

Vielleicht versuche ich es mal mit der Dll-Variante und versuche die relevanten Binaries dort anschließend herauszulösen (oder ich versuche diese Memcall-Methode).

hehe, genau DAS hatte ich auch vor, Problem dabei ist, du musst die DLL disassemblen um den Einsprungpunkt in die einzelnen Funktionen zu finden....

Nein, der Ansatz mit einem Assembler, der gcc-asm-code assembliert, ist wesentlich einfacher

Zitat von AspirinJunkie

Die Alternative wäre ja wirklich kompilieren + linken.

Ja, ich bin mir sicher, wenn man etwas in den Eingeweiden von godbolt wühlt, dann gibt es dort genau solche Möglichkeiten.

Der "richtige" ASM-Code ist ja da! Ggf. gibt es die Möglichkeit, diesen direkt über den Linker in ein binary zu überführen.

Hier https://stackoverflow.com/questions/1647…tput-raw-binary habe ich etwas dazu gefunden

So when compiling with gcc if you pass -Wl,--oformat=binary you will generate a binary file instead of the elf format. Where --oformat=binary tells ld to generate a binary file.

Der Compiler und der Linker werfen dabei keinen Fehler, wenn ich das auf der Website nutze.

Bestimmt hat man die Möglichkeiten, eine .bin-Datei statt der .s-Datei (ASM-Code) zu erstellen und herunterzuladen.

Zitat von AspirinJunkie

Meine Vermutung ist, dass ich den gcc unter Linux anspreche und evtl. hier noch Unterschiede in der Behandlung von Gleitkommazahlen zwischen Linux und Windows existieren.
Darüber hinaus klappt das Beispiel hier auch nicht mit der 32-Bit-Variante - warum auch immer.

nein, glaube ich nicht.

"If you want to know how it works, read the code!"

Der C(++) Code ist ja "richtig". Wenn das Ergebnis nicht stimmt, dann muss zwangsläufig der ASM-Code "falsch" sein. Da scheint es daran zu liegen...

Wenn ich diese C-Zeilen in den Godbolt eingebe:

double test() {
    return 5.8;
}

erhalte ich im browser im godbolt mit dem gcc 14.2 den asm-code

test:
        movsd   xmm0, QWORD PTR .LC0[rip]
        ret
.LC0:
        .long   858993459
        .long   1075262259

(die beiden .long sind die 8 Bytes double für die Zahl 5.8)

was, umgeschrieben in FASM-Syntax und mit AssembleIt assembliert, einwandfrei funktioniert:

#include <assembleit2_64.au3>
#include <array.au3>
#AutoIt3Wrapper_UseX64=y


#cs blablub

		use64
 ztest:
        movsd   xmm0, QWORD  [.LC0]
        ret
.LC0:
        dd  858993459
        dd  1075262259

#ce blablub

;assembliert den Code und gibt das Ergebnis  aus
$ret = _AssembleIt2("double","blablub")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
exit

Ist auch logisch, wenn man sieht, was der ASM-Code da macht. 8 Bytes aus dem Speicher ab Offset .LC0 ins Register XMM0 schreiben und fettich.....

opcodes aka binary dazu:

 0xF20F100501000000C33333333333331740

Wenn der C-code über JIT.AU3 an godbolt gesendet wird, erhalte ich von dort

@@ Debug(81) : $sASMCode = test:
 movsd  xmm0,QWORD PTR [rip+0x0]        # 8 <test+0x8>
    R_X86_64_PC32 .LC0-0x4
 ret

>Error code: 0
@@ Debug(87) : $sBinary = f20f100500000000c3

die binary disassembliert wird zu

0:  f2 0f 10 05 00 00 00    movsd  xmm0,QWORD PTR [rip+0x0]        # 0x8
7:  00
8:  c3                      ret

Was man sofort sieht, WO IST DIE KONSTANTE?

Imho liegt es also nicht am godbolt und/oder dem compiler dort, sondern an deiner HTTP-Anfrage und dem entsprechenden response...

//EDIT

es hängt am flag "compile to binary object"

ist das gesetzt, compiliert der Compiler (opcodes aka binary sind falsch) und disassembliert den code, was zum o.g. "falschen" Ergebnis und ASM-Code führt...

Ist das flag nicht gesetzt, dann wird zwar der ASM-Code "richtig" erzeugt (woher ist jetzt die Frage?!) aber es fehlen die Opcodes im respose

Ich habe es nicht geschafft, die flags so einzustellen , dass der "richtige" ASM-Code zusammen mit den dazugehörigen Opcodes zurückkommt

//EDIT....Post unvollständig

Zitat von AspirinJunkie

Für mich sieht das schon ziemlich rund aus - was meint ihr dazu?

Nicht nur ziemlich rund...das ist schon fast perfekt.

Ich würde, wie in AssembleIt, den Sourcecode "lesbar" zwischen irgendwelche #cs- und #ce-Tags packen, dann hat man die Hochkommas und das '&@LF&_-gedöns nicht mehr, kann den Code einrücken und auch kommentieren.

Der ASM-Code ist ggf auch ganz nützlich um zu debuggen/Code zu optimieren. Ich habe mich mal etwas mit den Intrinsics befasst, AVX512 und die Prozessorbefehle "neuer" Prozessoren" sind schön mit C++ und der CPUID abzufragen, wie bspw. hier gezeigt https://en.algorithmica.org/hpc/simd/intrinsics/

Solltest du vorhaben, "große" Matritzen zu multiplizieren bzw. zu berechnen, sollten SSE/AVX-Befehle verwendet werden. Ist nicht schwer und Faktor 3-6 schneller, je nach Anforderung bzw. Aufgabenstellung und Befehlsauswahl sind auch noch einige Faktoren mehr drin. FMA benutze ich auch gerne wenn es passt...https://de.wikipedia.org/wiki/Fused_multiply-add und https://de.wikipedia.org/wiki/FMA_x86

Hmmmm..... $oHTTP.SetProxy(2, "localhost:3128") funktioniert nur bei deinem Proxyserver

Zitat von AspirinJunkie

Mein Problem liegt derzeit noch an einer anderen Stelle: Ich schaffe es nicht Pointer zu übergeben um ein Array abzuarbeiten.
Folgendes Beispiel läuft bislang nicht bei mir:

Ja, der Fehler liegt aber nicht bei dir, sondern bei godbolt bzw. den calling conventions des gcc.....das war mir schon bei den ersten Beispielen mit Funktionen mit Parametern aufgefallen.

Exkurs in Calling conventions: https://en.wikipedia.org/wiki/X86_calli…ing_conventions

Kurz zusammengefasst bestimmen die calling conventions, wie die Funktionsparameter an den ASM-Code übergeben werden.

Wenn man sich den Anfang des ASM-Code anschaut

 push   rbp
 mov    rbp,rsp
 mov    QWORD PTR [rbp-0x18],rdi
 mov    DWORD PTR [rbp-0x1c],esi

dann sieht man, dass die ersten beiden Parameter der Funktion die Register rdi (64 bit, die Adresse der Struct der zu addierenden doubles) und esi (32Bit, 5 Doubles sollen addiert werden) sind

esi ist der niedrige Teil des rsi - Registers

Die ersten beiden Parameter werden also in den Registern RDI und RSI übergeben....schaut man sich die calling conventions an, dann ist das

System V AMD64 ABI
The calling convention of the System V AMD64 ABI is followed on Solaris, Linux, FreeBSD, macOS,[26] and is the de facto standard among Unix and Unix-like operating systems. The OpenVMS Calling Standard on x86-64 is based on the System V ABI with some extensions needed for backwards compatibility.[27] The first six integer or pointer arguments are passed in registers RDI, RSI, RDX, RCX, R8, R9 (R10 is used as a static chain pointer in case of nested functions[28]: 21 ), while XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6 and XMM7 are used for the first floating point arguments.

Unix-gedöns....gcc....wtf....

Schau mal, ob du bei godbolt einen Compiler für Windows findest oder die calling conventions umstellen kannst...

Ich habe im von godbolt erstellten ASM-Code das register esi durch edx ersetzt und damit die Microsoft x64 calling convention erfüllt, der gcc kann das auch!!

Damit läuft dein Code:

#include <assembleit2_64.au3>
#include <array.au3>
#AutoIt3Wrapper_UseX64=y


#cs blablub

		use64
 push   rbp
 mov    rbp,rsp
 mov    QWORD  [rbp-0x18],rcx
 mov    DWORD  [rbp-0x1c],edx		;Microsoft x64 calling convention
 pxor   xmm0,xmm0
 movsd  QWORD  [rbp-0x8],xmm0
 mov    DWORD  [rbp-0xc],0x0
 jmp    bla
 blub:
 mov    eax,DWORD  [rbp-0xc]
 cdqe
 lea    rdx,[rax*8+0x0]
 mov    rax,QWORD  [rbp-0x18]
 add    rax,rdx
 movsd  xmm0,QWORD  [rax]
 movsd  xmm1,QWORD  [rbp-0x8]
 addsd  xmm0,xmm1
 movsd  QWORD  [rbp-0x8],xmm0
 add    DWORD  [rbp-0xc],0x1
 bla:
 mov    eax,DWORD  [rbp-0xc]
 cmp    eax,DWORD  [rbp-0x1c]
 jl     blub
 movsd  xmm0,QWORD  [rbp-0x8]
 pop    rbp
 ret

#ce blablub

; double data array
Global $tData = DllStructCreate("DOUBLE [5]")
For $i = 1 To 5
	DllStructSetData($tData, 1, Number($i & "." & $i), $i)
Next


;assembliert den Code und gibt das Ergebnis  aus
$ret = _AssembleIt2("double","blablub", "PTR", DllStructGetPtr($tData), "INT", 5)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

;Opcodes erzeugen
;~ $ret = _AssembleIt2("retbinary","blablub")
;~ ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

;und ab damit in den DllCallAddress()
Local $aStructMem = DllCall("kernel32.dll", "ptr", "VirtualAlloc", "ptr", 0, "ulong_ptr", DllStructGetSize(DllStructCreate("byte[86]")), "dword", 4096, "dword", 64)
Local $tCodeBuffer = DllStructCreate("byte[86]", Number($aStructMem[0]))  ;Address aligned 64 and Memory is  $MEM_COMMIT, $PAGE_EXECUTE_READWRITE
DllStructSetData($tCodeBuffer, 1,"0x554889E548894DE88955E4660FEFC0F20F1145F8C745F400000000EB2A8B45F44898488D14C500000000488B45E84801D0F20F1000F20F104DF8F20F58C1F20F1145F88345F4018B45F43B45E47CCEF20F1045F85DC3") ;write opcodes into memory
$ret=DllCallAddress("double:cdecl", DllStructGetPtr($tCodeBuffer), "PTR", DllStructGetPtr($tData), "INT", 5)
_arraydisplay($ret)

Wenn die Calling conventions vom aufrufenden Programm und der Funktion übereinstimmen, dann fluppt es :o)

//EDIT

habs gefunden:

__attribute__((ms_abi))

Im c++-code des gcc erstellt code der Microsoft x64 calling convention

Global $sSourceCode = _
'__attribute__((ms_abi))' & @LF & _
'double sumArray(double *arr, int size) {' & @LF & _
'    double sum = 0.0;' & @LF & _
'    for (int i = 0; i < size; i++) {' & @LF & _
'        sum += arr[i];' & @LF & _
'    }' & @LF & _
'    return sum;' & @LF & _
'}'

funzt!!!!

Btw. Vektorisierung...für Rust habe ich etwas gefunden: https://www.heise.de/hintergrund/Ta…15.html?seite=2

"Fast" gleicher Quellcode, aber 4x schneller....

Leider gibt es für Freebasic keine Vektorisierung, oder ich habe keine gefunden...

//EDIT

So wie ich das mittlerweile sehe, führt bei Vektorisierung kein Weg an hochoptimierten Libs oder Bibliotheken vorbei. AspirinJunkie , ggf. solltest du doch über den Vorschlag von UEZ nachdenken und eine dieser Libs integrieren und die Funktionen darin aufrufen....

//EDIT2

....ich schreibe dir aber gerne auch eine kleine und feine ASM-Funktion

Zitat von UEZ

Bei dir ist das anscheinend in Fleisch und Blut übergegangen.

Naja, du weisst ja wie das ist, man kann einem alten Hund keine neuen Tricks beibringen....braucht man aber auch nicht, seit dem allerersten Prozessor (na gut, x86-Prozessor also der 8086) ist der ASM-Code absolut unverändert. Einige Erweiterungen (x64,SSE,AVX uswusf.) sind dazugekommen und einige Handvoll neuer Prozessorbefehle, aber der "Ablauf" im ASM-Code ist wie vor 40 Jahren....da gibts nix "neues", also muss ich auch keine neuen Tricks lernen.

Zitat von UEZ

Das Aktualisieren wäre sicherlich auch einfacher, als mit dem ASM Code.

Bin ich voll und ganz dabei. Wenn die Compiler nur nicht so schrecklich "doof" wären....aber das liegt sicherlich an mir....ich habe Compilate disassembliert, da fliegt dir der Hut weg! Derart schnellen und GEILEN ASM-Code bekommen nicht mal die besten Assembler-Cracks geschrieben....und das nur mit einigen Zeilen (zugegeben auch GUTEM) Hochsprachencode und F5 drücken.....

In einigen anderen Beiträgen zu ähnlichen Themen habe ich schon geschrieben, wie ich mich mit den Jungs und Mädels im Forschungszentrum Jülich und deren HPC-Anwendungen und Optimierungen beschäftigt habe. DAS ist die obere Spitze vom Eisberg....da schreibt niemand irgendwelchen Larifaricode, ohne zu wissen bzw nachzuprüfen, was der Compiler daraus macht. Wenn in einen Rechencluster mehrere hundert Millionen Euro versenkt werden, dann nicht, um nur 5-10% von der Rechenleistung auszunutzen...schon 90% sind zu wenig!!!

Wie ich schon immer postuliert habe: langsamer Code ist und bleibt langsam, selbst mit einem schnellen Compiler compiliert! "Schneller" Code ist die Ausnutzung ALLER im Prozessor (egal ob CPU oder GPU) integrierten Komponenten und Rechenwerke. Da in Jülich auch mit OpenCL gearbeitet und entsprechend optimiert wurde, hat mir das auch bei schnellen Berechnungen auf meiner Grafikkarte geholfen. Die kostet nur die Hälfte von meinem Prozessor, ist aber in der Lage bestimmten Code x-mal schneller auszuführen....

S. Beispiel oben. Freebasic und Rust compilieren Code, der von einigen Bytes ASM-Code um mehrere Faktoren abgehängt wird! Da können aber die Compiler nix dafür, das hängt am Sourcecode! Nur weil ich weiß, dass man statt 4 Zahlen nacheinander zu addieren das auch in EINEM Prozessorbefehl machen kann, bin ich ja kein Crack....wenn ich mich "früher" statt mit Assembler mit C beschäftigt hätte, würde ich sicher auch SSE- und AVX-Code in C schreiben können. Oder in einer anderen Compilersprache...aber ich bin halt bei "Basic" hängengeblieben...und Assembler

Hi,

sorry für die späte Antwort.

Zitat von AspirinJunkie

Eventuell kannst du Licht ins Dunkel bringen in welchen Fällen das versagt und in welchen es klappt und was dazu immer notwendig ist.

"Es" funktioniert in allen Fällen in denen der Compiler in der Lage ist, ohne einzubindende Module (ASM-)Code zu erzeugen. Ich bin mir sogar sicher dass funktionsfähiger Code entstehen würde, wenn du bspw. die SQRT()-Funktion aus der Bibliothek herauslösen würdest und in den Quellcode einbindest. Für den Quellcode

'#include <math.h>' & @LF & _
'double squareroot(double num) {' & @LF & _
'    return sqrt(num);' & @LF & _
'}'

wird folgender ASM-Code erzeugt

push   rbp
 mov    rbp,rsp
 sub    rsp,0x10
 movsd  QWORD PTR [rbp-0x8],xmm0
 mov    rax,QWORD PTR [rbp-0x8]
 movq   xmm0,rax
 call   1b <squareroot+0x1b>
    R_X86_64_PLT32 sqrt-0x4
 leave
 ret

der "call 1b" ruft die Unterfunktion an der Adresse 1b im Code auf, das ist allerdings genau die nächste Zeile mit dem "leave", was den Rücksprung aus der Funktion aufruft. Wie du bereits vermutet hast, wird der Call in die Unterfunktion ausgeführt, aber infolge fehlendem Code nicht ausgeführt.

Was bereits bemerkenswert ist, ist die Tatsache, dass du "fast" lauffähigen Assemblercode aka Opcodes erzeugen kannst.

Ich habe mal etwas mit dem gcc auf godbolt experimentiert. **ToDo**Ggf. sollte man per AutoItscript einen "echten" gcc oder anderen Compiler lokal steuern und die Opcodes disassemblieren....

Der vom godbolt erzeugte ASM-Code stellt ausschliesslich das 1:1-pendant des C(++)-Codes dar! Da wird keinerlei "Struktur" mitassembliert! Will heißen:

Eine C-Funktion main() (oder andererer Funktionsname), welcher KEINE andere Funktion aufruft, wird, wie von dir demonstriert, anstandslos ausgeführt.

Wird allerdings in main() eine andere Funktion (bspw. add())aufgerufen, muss diese vor main() deklariert werden. Der C-Compiler "weiß", dass die add()-Funktion eine Funktion ist und springt im Compilat zu main(), arbeitet den dortigen Code bis zur Funktion add() ab, springt in add(), von dort zurück in main() und beendet das Programm....

Im von godbolt erzeugten ASM-Code wird "einfach" eine Funktion add() erzeugt und eine Funktion main()

Sourcecode:

int add(int num) {
    return num + num;
}


int main() {
int b = 5;    
int a = add(b);
return a;
}

Daraus macht godbolt:

add(int):
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     eax, DWORD PTR [rbp-4]
        add     eax, eax
        pop     rbp
        ret
main:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     DWORD PTR [rbp-4], 5
        mov     eax, DWORD PTR [rbp-4]
        mov     edi, eax
        call    add(int)
        mov     DWORD PTR [rbp-8], eax
        mov     eax, DWORD PTR [rbp-8]
        leave
        ret

dieser Code hat aber ein Problem. Wenn assembliert, startet der code bei add() und wird beim nächsten ret beendet. main() wird NIE aufgerufen.

Würde main() VOR den anderen Funktionen stehen, so wie hier (und die (int)´s im code entfernt werden), so dass folgender Code entsteht

main:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     DWORD PTR [rbp-4], 5
        mov     eax, DWORD PTR [rbp-4]
        mov     edi, eax
        call    add
        mov     DWORD PTR [rbp-8], eax
        mov     eax, DWORD PTR [rbp-8]
        leave
        ret


add:
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     eax, DWORD PTR [rbp-4]
        add     eax, eax
        pop     rbp
        ret

dann wird dieser code anstandslos assembliert (u.a. von AssembleIt, aber auch bei https://defuse.ca/online-x86-assembler.htm#disassembly)

0x554889E54883EC10C745FC050000008B45FC89C7E8080000008945F88B45F8C9C3554889E5897DFC8B45FC01C05DC3

und ist lauffähig (ACHTUNG! AssembleIt benutzt den FASM-Assembler, und der reagiert allergisch darauf, wenn man "call add" aufruft. add ist eine Assembler- Anweisung, benennt man die Funktion bzw. Adresse im Code in "addieren" um, funzt alles problemlos^^). Der Disassembler https://defuse.ca/online-x86-assembler.htm#disassembly assembliert zu

0:  55                      push   rbp
1:  48 89 e5                mov    rbp,rsp
4:  48 83 ec 10             sub    rsp,0x10
8:  c7 45 fc 05 00 00 00    mov    DWORD PTR [rbp-0x4],0x5
f:  8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
12: 89 c7                   mov    edi,eax
14: e8 08 00 00 00          call   21 <add>
19: 89 45 f8                mov    DWORD PTR [rbp-0x8],eax
1c: 8b 45 f8                mov    eax,DWORD PTR [rbp-0x8]
1f: c9                      leave
20: c3                      ret
0000000000000021 <add>:
21: 55                      push   rbp
22: 48 89 e5                mov    rbp,rsp
25: 89 7d fc                mov    DWORD PTR [rbp-0x4],edi
28: 8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
2b: 01 c0                   add    eax,eax
2d: 5d                      pop    rbp
2e: c3                      ret

der call-befehl ruft die Funktion add an der Adresse 21 auf (FASM macht das genau so....JEDER Assembler generiert die gleichen OpCode:

0x554889E54883EC10C745FC050000008B45FC89C7E8080000008945F88B45F8C9C3554889E5897DFC8B45FC01C05DC3

welcher auch das "richtige" Ergebnis liefert: (AutoIt-Code hier von AssembleIt erzeugt)

Local $aStructMem = DllCall("kernel32.dll", "ptr", "VirtualAlloc", "ptr", 0, "ulong_ptr", DllStructGetSize(DllStructCreate("byte[47]")), "dword", 4096, "dword", 64)
Local $tCodeBuffer = DllStructCreate("byte[47]", Number($aStructMem[0]))  ;Address aligned 64 and Memory is  $MEM_COMMIT, $PAGE_EXECUTE_READWRITE
DllStructSetData($tCodeBuffer, 1,"0x554889E54883EC10C745FC050000008B45FC89C7E8080000008945F88B45F8C9C3554889E5897DFC8B45FC01C05DC3") ;write opcodes into memory
$ret=DllCallAddress("int:cdecl", DllStructGetPtr($tCodeBuffer))

ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret[0] & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

Zur Vollständigkeit halber der AssembleIt-Code:

#include <assembleit2_64.au3>
#AutoIt3Wrapper_UseX64=y


#cs blablub

		use64
main:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     DWORD  [rbp-4], 5
        mov     eax, DWORD  [rbp-4]
        mov     edi, eax
        call    addieren
        mov     DWORD  [rbp-8], eax
        mov     eax, DWORD  [rbp-8]
        leave
        ret

addieren:
        push    rbp
        mov     rbp, rsp
        mov     DWORD  [rbp-4], edi
        mov     eax, DWORD  [rbp-4]
        add     eax, eax
        pop     rbp
        ret

#ce blablub


;assembliert den Code und gibt das Ergebnis 5+5=10 aus
$ret = _AssembleIt2("int","blablub")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console	

consolewrite(@crlf & @crlf & @crlf & "AssembleIt erzeugt AutoIt-Code aka DllCallAddress()" & @crlf)
;erzeugt lauffähigen AutoIt-Code
;erstellt Opcodes und ruft diese per DllCallAddress() auf
$ret = _AssembleIt2("int","blablub","retbinary",@scriptlinenumber)

Zusammengefasst:

Du bist mit deinem Programm bei ca. 90% Funktionalität angelangt. Ganz ohne Nachbearbeitung des vom Godbolt-gcc (oder von anderen Compilern) erzeugten Codes geht es zzt. noch nicht. Btw. habe ich sowohl die von UEZ als auch die von Kanashius erzeugte ASM-Codes mit AssembleIt lauffähig bekommen, allerdings mit "Nachbearbeitung".

Bei der Erstellung einer DLL werden Bibliotheken bzw. die darin enthaltenen und im Code benötigten Funktionen dazugelinkt.

Aber wo ist das Problem, aus bspw. C(++) - Bibliotheken die einzelnen Funktionen zu assemblieren und später an dein Programm "anzuhängen".

Man hätte den Vorteil, dass man nur noch ca. 5% des ASM-Codes schreiben bzw. rudimentär ändern müsste, um ein extrem schnelles Programm in AutoIt zu erhalten.....schreib mal einige Zeilen C(++)-code oder mit einem anderen Compiler und wir sehen weiter.

Oder schon fortgeschritten: Gib mit den disassemblierten, also ASM- Code einer von dir benötigten Matrix-Funktion (bspw. von einem x-beliebigen Compiler generiert), und ich sehe zu, dass ich dazu die passenden Opcodes erstelle....

Dieses Projekt würde den "AutoItcompiler" fast überflüssig machen....

Zitat von AspirinJunkie

Ok vielleicht hilft dir ja folgendes Skript ein bisschen:

Ui, DAS ist ja cool...

Zitat von AspirinJunkie

Hm bei mir klappt es noch nicht ganz:

Ja, Verständnisfehler oder von mir nicht richtig/exakt beschrieben:

$bRet = _AssembleIt2("int", "square", "int", $a) aufgerufen mit dem Rückgabedatentyp, "Funktionsnamen" und den Parametern (Parameter wie beim DllCall, jeweils Datentyp und Variable) assembliert den ASM-Code, schreibt ihn in den Speicher, ruft ihn auf und gibt das Ergebnis der Funktion zurück. Der ASM-Code kann mit Debugger (aktuell nur für 32-Bitcode) nachvollzogen werden , Registerinhalte, Stack usw. Der aufgerufene (und assemblierte) ASM-Code läuft nativ auf dem Prozessor, der "Overhead" der _AssembleIt2-Funktion ist nur einige Millisekunden.

_AssembleIt2("retbinary","Funktionsname") gibt den assemblierten Binärcode zurück, den man dann allerdings noch in eine Struct schreiben und aufrufen muss....Diese Funktion ist aktuell unnötig!

Ich habe eine Erweiterung geschrieben, welche einige Zeilen AutoItcode erstellt, mit der dann der ASM-Code direkt per DllCallAddress() aufgerufen werden kann. Dazu werden die Parameter "retbinary",@ScriptlineNumber hinten an die Parameter von AssembleIt angehängt. Damit baut dann AssembleIt den kompletten Aufruf der ASM-binary aus dem Speicher, bsp:

$bRet = _AssembleIt2("int", "square", "int", $a,"retbinary",@ScriptLineNumber)

erzeugt (steht in der Scite Console und im Clipboard):

Local $aStructMem = DllCall("kernel32.dll", "ptr", "VirtualAlloc", "ptr", 0, "ulong_ptr", DllStructGetSize(DllStructCreate("byte[15]")), "dword", 4096, "dword", 64)
Local $tCodeBuffer = DllStructCreate("byte[15]", Number($aStructMem[0])) ;Address aligned 64 and Memory is $MEM_COMMIT, $PAGE_EXECUTE_READWRITE
DllStructSetData($tCodeBuffer, 1,"0x554889E5894DFC8B45FC0FAFC05DC3") ;write opcodes into memory
$ret=DllCallAddress("int:cdecl", DllStructGetPtr($tCodeBuffer), "int", $a)

und ersetzt dann

$bRet = _AssembleIt2("int", "square", "int", $a)

womit #include <assembleit2_64.au3> überflüssig wird

Hier dein Beispiel (habe deine Fragen kommentiert/beantwortet)

#include <assembleit2_64.au3>
#AutoIt3Wrapper_UseX64=y


#cs square

		use64
		push    rbp
        mov     rbp, rsp
        mov     DWORD [rbp-4], ecx
        mov     eax, DWORD [rbp-4]
        imul    eax, eax
        pop     rbp
        ret

#ce square

; ist das die Größe des 1. Parameters in Bytes?
$a=4
;nein, das ist der Parameter, der Integer der quadriert werden soll

; ASM-Code ausführen
$bRet = _AssembleIt2("int", "square", "int", $a)  ; was macht das a?!
;das $a ist der Parameter, der Integer, der quadriert werden soll
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $bRet = ' & $bRet & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

;erstellt das binary der Funktion "square"....nur noch in Ausnahmefällen nötig, da....
$binary = _AssembleIt2("retbinary","square")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $binary = ' & $binary & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

;....mit
$bRet = _AssembleIt2("int", "square", "int", $a,"retbinary",@ScriptLineNumber)
;erzeugt wird: (s. Console und Clipboard), damit #include <assembleit2_64.au3> überflüssig wird

Local $aStructMem = DllCall("kernel32.dll", "ptr", "VirtualAlloc", "ptr", 0, "ulong_ptr", DllStructGetSize(DllStructCreate("byte[15]")), "dword", 4096, "dword", 64)
Local $tCodeBuffer = DllStructCreate("byte[15]", Number($aStructMem[0]))  ;Address aligned 64 and Memory is  $MEM_COMMIT, $PAGE_EXECUTE_READWRITE
DllStructSetData($tCodeBuffer, 1,"0x554889E5894DFC8B45FC0FAFC05DC3") ;write opcodes into memory
$ret=DllCallAddress("int:cdecl", DllStructGetPtr($tCodeBuffer), "int", $a)

_arraydisplay($ret); da DllCallAddress() ein Array zurückgibt

;15 quadrieren
$ret=DllCallAddress("int:cdecl", DllStructGetPtr($tCodeBuffer), "int", 15)
_arraydisplay($ret)

Noch etwas zum Verständnis:

Im 64-Bit-Modus ist eine 64 Bytes aligned Speicheradresse zwingend notwendig, um die in den Speicher geschriebenen Opcodes auszuführen.

DllStructcreate() richtet nur 4 Byte aligned aus, für den 32-Bit-Modus reicht das, bei 64-Bit-Modus nicht....daher der Umweg über VirtualAlloc. In AssembleIt gibt es eine Funktion _DllStructCreate64(), die exakt dafür vorgesehen ist. Im 32-Bit-Modus schadet das 64-Bit align auch nicht....gerade im Gegenteil, Zugriff auf aligned Daten führt idR zu schnellerem Code.

Zitat von AspirinJunkie

Ok also ganz ohne Anpassungen kann ich den Output von denen also offensichtlich nicht verwenden?

Jeder Compilerbauer kocht sein eigenes Süppchen. Würdest du bspw. den GCC-C-Compiler den Code erstellen/assemblieren lassen und per DllCallAddress im GCC aufrufen, dan würde das auch genau so funktionieren.

Das macht dann ein Assembler / Disassembler, bspw. so , auch online

image.png

Bin heute Abend wieder Online, dann versuchen wir das mal ohne Modifikationen am Code....bis denne

https://en.wikipedia.org/wiki/Kahan_summation_algorithm ist sehr interessant. Unten im Artikel ist von den optimierten sum()-Funktionen einiger Sprachen die Rede.

Dann wäre es es echt eine Überlegung wert, den von diesen Compilern erstellten Code in eine AssembleIt-Funktion zu kopieren und den Binärcode erstellen zu lassen.

Das wäre echt einfach....

Zitat von AspirinJunkie

Ich habe zwar keine Ahnung von Assembler aber ein Träumchen wäre es, wenn ich dort den Code in C eingeben könnte und dann entweder direkt ein Binary oder ein ASM-Code erhalte, welchen ich in AssembleIt2 verwenden könnte,.

Yepp, das funktioniert auch (fast) genau so

image.png

den Assemblercode (hier 64Bit) kannst du so ins AssembleIt einfügen, ich mach mal ein Beispiel.

AssembleIt2_64 v 313.zip

#include <assembleit2_64.au3>
#AutoIt3Wrapper_UseX64=y


#cs square

		use64
		push    rbp
        mov     rbp, rsp
        mov     DWORD [rbp-4], ecx
        mov     eax, DWORD [rbp-4]
        imul    eax, eax

        pop     rbp
        ret

#ce square


$a=8

$ret = _AssembleIt2("int","square",  "int",$a);,"retbinary",@scriptlinenumber)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console		

in Zeile 12 wurde das Register edi durch ecx ersetzt, s. 64-Bit Aufrufkonventionen, ggf. kann man das auch per fastcall o.ä. anpassen

die DWORD PTR wurden durch DWORD ersetzt bzw. das PTR entfernt, das ist dem im AssembleIt verwendeten FASM Assembler geschuldet. Aber das erkennt AssembleIt und weist dich hin...

Ansonsten könnte man die so erstellten bzw auch von UEZ und Kanashius erstellten Codes so einfügen und per AssembleIt testen und bearbeiten

Zitat von AspirinJunkie

Der interessante Schritt dazwischen "ASM-Code in ein aus AutoIt heraus aufrufbares Binary zu überführen" sind wir aber bislang noch nicht angegangen.

Doch, schau mal in mein Script in Post #10.

Binärcode mit Aufruf per DllCallAddress()

Zitat von AspirinJunkie

Komplett unterschiedlich: Von 2 bis 1 Million in Einerschritten alles möglich.

Ok, dann wird es interessant. Ggf. macht es dann auch Sinn, den (für parallele Berechnungen) lahmarschigen Prozessor (CPU) mit Hilfe der Grafikkarte bzw. in die CPU integrierter GPU auf die Sprünge zu helfen.

Matrixberechnungen werden nicht ohne Grund bei Supercomputeranwendungen auf GPU´s ausgelagert. Die sind dafür prädestiniert, Vektorisierungen sind dort einfach zu erstellen...Cuda ist auf Nvidia beschränkt, daher habe ich solches schon in AutoIt per OpenCL umgesetzt.

Btw. Vektorisierung, UEZ und Kanashius das sollte man auch dem Compiler hinwerfen, dann macht der auch parallel ausführbaren Code...

Zitat von AspirinJunkie

Hatte AssembleIt da nicht Techniken dafür?

Na klar^^, habe imho sogar im letzten Jahr ein Howto verfasst...

AssembleIt kann nun nach dem Testen/Debuggen selbstständig den AutoItcode mit Binärcode und Aufruf über DllCallAddress() erstellen, s.S. 7 unten

How To _AssembleIt2() deutsch.pdf

Ich zitiere mich mal selbst:

Zitat von Andy

Könnte mal jemand BITTE einen GCC oder Intel/M$-Compiler anwerfen? Und damit mal versuchen, ob mit deren Compileroptionen diese simple SSE-Addition "richtig" ausgeführt wird?

Habe eben auf https://godbolt.org mal folgende Funktion mit den verschiedensten Compilern durchgetestet.

void sumArray(float* x,int* n) {
    int i;
    float sum;
    for (i = 0; i < n; i++) {
        sum += x[i];
    }
}

Bin ja nicht der C-Spezialist, sollte so aber passen....

K E I N E R der von den zwölfundneunzig von mir ausgewählten Compilern hat etwas anderes gemacht, als nacheinander einzelne Floats zu addieren. Von SSE/SIMD oder anderen seit Jahrzehnten möglichen Techniken zur parallelen Berechnung keine Spur....

Ich spiele mal mit den Compileroptionen rum....schaumamal

//EDIT

So wie ich das sehe, empfehlen die Compiler-Hersteller die Verwendung von Intrinsics...

https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html

Damit werden die ASM-Instruktionen in die Hochsprache gehievt...warum auch nicht, da macht der Compiler wenigstens (ohne zu "optimieren") was er soll!

HADDPS https://www.intel.com/content/www/us…4&ssetechs=SSE3

image.png

Habe mir mal den Code von Rust angeschaut....da schiessen mir ehrlich gesagt die Tränen in die Augen...

Der Prozessorbefehl, den alle Compilate (bisher) (und auch ich^^) benutzen um die Floats zusammenzuzählen lautet ADDPS

image.png

Wie man im Schaubild sieht, addiert der Befehl 4 Floats aus einem Register oder Speicher zu den 4 Floats im Register....DAS ist der Sinn und Zweck von SSE (Streaming SIMD Extensions), die parallele Ausführung von Instruktionen, hier die Addition. SIMD heißt Single Instruction Multiple Data, man kann MEHRERE Daten gleichzeitig bearbeiten.

Ich in meinem ASM-Programm mache das auch so, ich lese 128 Bit (16 Byte) an Daten ein und addiere diese zu den 128 Bit Daten (aka 4 Floats = 16 Bytes) im Register....logischerweise muss man dann, um die nächsten 4 Floats (16 Bytes) zu addieren, im Speicher auch 16 Bytes weiter springen....Rust springt 4 Bytes weiter....addiert also immer nur EINE Float!!! Natürlich werden die folgenden 3 Floats auch zu den entsprechenden Teilen im Register dazuaddiert, das ist aber völlig irrelevant, da der Compiler diese Addition nie berücksichtigt!

Die Rust-Schleife läuft also 4x länger als eigentlich vorgesehen, und bei 3 von 4 ADDPS haut auch noch der unaligned Speicherzugriff voll rein...Soviel zu "Compiler-Optionen".....

UEZ´s Compiler benutzt für die Addition der Floats den uralten (seit 1999 überflüssigen) Coprozessor mit
fadd qword ptr [ebx]

und addiert, wie Rust, jede der Floats im Speicher nacheinander.....

Könnte mal jemand BITTE einen GCC oder Intel/M$-Compiler anwerfen? Und damit mal versuchen, ob mit deren Compileroptionen diese simple SSE-Addition "richtig" ausgeführt wird?

Und um jetzt die aufkommende Frage der interessierten Leser zu beantworten: "Ja, Andy, du hast jetzt im letzten Schleifendurchlauf alle Floats addiert, die bestehen im XMM-Register aber doch aus 4 einzelnen Floats die auch noch zusammengezählt werden müssen!"

Ja, stimmt! Im XMM-Register stehen 4 Floats "hintereinander", um innerhalb eines XMM-Registers die einzelnen Teile zusammenzuaddieren, gibt es den image.png

der addiert innerhalb des Registers.

Angenommen im Register xmm0 stehen die Floats 1.0 2.0 6.0 7.0

dann wird in der Instruktion HADDPS xmm0,xmm0 folgendes berechnet

6.0 + 7.0 =13.0 geht ins 4. Registerteil

1.0 + 2.0 = 3.0 geht ins 3. Registerteil

6.0 +7.0 =13.0 geht ins 2. Registerteil

1.0 + 2.0 = 3.0 geht ins 1. Registerteil

Im Register xmm0 stehen also die Floats 13.0 3.0 13.0 3.0

beim nochmaligen HADDPS xmm0,xmm0 wird berechnet

13.0 + 3.0 =16.0 geht ins 4. Registerteil

13.0 + 3.0 = 16.0 geht ins 3. Registerteil

13.0 +3.0 =16.0 geht ins 2. Registerteil

13.0 + 3.0 = 16.0 geht ins 1. Registerteil

Danach stehen in allen Registerteilen (Floats) die Summe der 4 einzelnen Floats aka die Gesamtsumme aller Floats

Tadaaaaaa!