Für den Anfang Inline Assembler lernen?
-
Hallo, ich möchte mich mehr mit Assembler auseinandersetzen, nun frage ich mich, soll ich gleich zum richtigen Assembler wechseln oder kann ich z.B. den Inline Assembler in C++ bei Visual Studio verwenden? Ich möchte erstmal Grundlagen lernen, rechnen, strings ausgeben usw.
Im Inline Assembler kann man doch gleich das Ergebnis in der Konsole ausgeben, wie sieht es mit dem Programm das in reinem Assembler z.B. NASM erstellt wurde, diese muss doch noch gelinkt werden, in eine .EXE oder???
-
kernel64 schrieb:
Hallo, ich möchte mich mehr mit Assembler auseinandersetzen, nun frage ich mich, soll ich gleich zum richtigen Assembler wechseln oder kann ich z.B. den Inline Assembler in C++ bei Visual Studio verwenden? Ich möchte erstmal Grundlagen lernen, rechnen, strings ausgeben usw.
Kommt wohl vor allem darauf an, wie und was du lernen willst...
Ich habe damals auch zu allererst kurz mit Inline-Asm rumgespielt... allerdings in Pascal. Spricht also IMHO nichts dagegen, das auch im VS erstmal auszuprobieren, zum Lernen taugt das aber IMHO schnell nicht mehr so unbedingt...kernel64 schrieb:
Im Inline Assembler kann man doch gleich das Ergebnis in der Konsole ausgeben,
Aha? Offenbar hast du da ja schon einen Plan.
kernel64 schrieb:
wie sieht es mit dem Programm das in reinem Assembler z.B. NASM erstellt wurde, diese muss doch noch gelinkt werden, in eine .EXE oder???
Wie fuer alle Programme gilt: nicht unbedingt. Das hat aber nichts mit Assembler zu tun und verhaelt sich grundsaetzlich nicht anders als wie zB. mit C++-Programmen (die musst du idR. auch linken).
-
ich wollte nun auch mal mit asm anfangen. Habe dann auch erstmal mit inline asm in VS rumgespielt, aber naja... entweder bin ich zu blöde was in inline asm zu deklarieren oder es geht schlicht weg garnicht. genauso wie interupts. also ausgabe mit inline asm in VS wird wohl nix^^ (bitte korrigieren falls ich falsch liege.. wie gesagt, habe erst vor 1 Woche damit angefangen)
-
Du kannst AFAIK theoretisch mit den Schluesselwoertern db, dw, usw. und einem Label auch in Inline-Assembler Variablen anlegen (ich nehme an, das war gemeint), macht aber idR. keinen Sinn. Da nimmt man eher ausserhalb des Asm-Blocks deklarierte Variablen her.
Soft-Interrupts (Befehl int) sollten in einem Windows-Programm (das Einzige, was du allgemein mit dem VS erstellen kannst) generell nicht vorkommen.
Ausgaben machst du der Einfachheit halber ausserhalb des Asm-Blocks, sonst musst du WinAPI-Funktionen benutzen (siehe MSDN, WriteFile, usw.).
Was natuerlich nicht klappt, ist irgendein Anfaenger-Tutorial fuer DOS und TASM oder irgendeinen anderen richtigen Assembler herzunehmen und die Beispiele einfach in Inline-Assembler-Bloecke zu pasten.
Inline-Asm ist IMHO wirklich eher zum halbwegs planlosen Rumprobieren mit einzelnen Instruktionen gut.
-
Danke, werde dann doch zum normalen Assembler wechseln, welchen könnt ihr mir empfehlen, MASM, TASM, NASM ... werden die ersten beiden noch weiterentwickelt? Wäre persönlich dann für den NASM, ist sehr bekannt.
Welche Werkzeuge brauche ich neben dem Assembler?
- Assembler
- Linker
- ???Gibt es 64 Bit Assembler, wenn ja sollte man heut nicht damit anfangen im Zeitalter von 64 Bit??
-
Ich würde auch NASM lernen.
Und natürlich brauchst du noch einen Editor...
Mit IDEs siehts bei Assembler nicht so gut aus.
-
Melan schrieb:
Mit IDEs siehts bei Assembler nicht so gut aus.
hat meiner meinung nach auch nicht viel sinn, es sei denn man schafft es nicht "mov" ohne intellisens zu schreiben... und syntax highlighting is sowiso nur spielerei
-
Mein Reden.
Wuerde auch NASM empfehlen. Das Teil ist recht verbreitet, aktuell und hat einen TASM-Kompatibilitaetsmodus.
Dh. der NASM kann auch 64Bit. Wuerde ich aber zum Einstieg nicht empfehlen, da es hierzu AFAIK im Vergleich zu wenig Tutorials zum NASM allgemein keine bis extrem wenige Tutorials gibt - evtl. vorhandene bestimmt nicht fuer Einsteiger.
-
Hallo,
ich stehe ASM- (Inline) sehr positiv gegenüber. Es gibt viele Dinge die nur über ASM am Prozessor ausgereizt werden können. Notwendig dazu ist, dass man den Befehlssatz der CPU wirklich gut beherrscht und: Man muss wissen, dass alle neueren Prozessore den Kernel- und Usermodus beherrschen und zB M$ in Windows davon ausführlichst Gebrauch macht.
Es gibt eine Kehrseite der Medaille die da lautet: Zuviel ASM kann auch schädlich sein, weil eine ASM-Instruktion per Quellcode meistens nicht mehr im Kompilierungsprozess mit einfließt, bzw. so interpretiert wird, wie reiner C-Code, und dann so pur übernommen wird. Heutige Compiler sind aber das feinste was es in Bezug auf Codeeffizienz gibt und man muss da schon wie Waage zwischen der Hochsprache und dem ASM haben. Hochsprache und ASM müssen sich also ergänzen können - nicht bremsen!
Von reinen Assemblern heutzutage würde ich abraten.Hier habe ich eine Demo gemacht, wie man das in C++ umsetzen kann. Der code ermittelt die CPU-Speed.
#include <windows.h> #include <iostream> int main(int argc, char** argv){ FARPROC lnCnt; long lBoost, lhMod, lPrio = 0; _int64 lCnt1, lCnt2 = 0; HANDLE hProcess; //Funkpointer für GetTickcount für ASM ermitteln lnCnt = GetProcAddress(GetModuleHandleA("Kernel32.dll"),"GetTickCount"); if(lnCnt){ //derzeitige Process-Priorität merken hProcess = GetCurrentProcess(); lPrio = GetPriorityClass(hProcess); //Process auf Realtime heben ... dann aber Gas geben ;) lBoost = SetPriorityClass(hProcess, REALTIME_PRIORITY_CLASS); if(lBoost){ __asm{ //zuerst die Register sichern pushad //GetTickcount aufrufen und Startwert merken call DWORD PTR lnCnt mov ecx,eax WaitlP1: call DWORD PTR lnCnt cmp ecx,eax je WaitlP1 mov ecx, eax rdtsc //Quad's 64 Bit Variable mit Werten aus 32Bit Register füllen //geht so ;) mov DWORD PTR lCnt1[4], edx mov DWORD PTR lCnt1[0], eax add ecx,100 WaitlP2: call DWORD PTR lnCnt cmp ecx,eax ja WaitlP2 rdtsc mov DWORD PTR lCnt2[4], edx mov DWORD PTR lCnt2[0], eax //Register vom Stack wieder restaurieren popad } } //gemerkte Prozess-Priorität zurücksetzen SetPriorityClass(hProcess, lPrio); //Werte ausgeben ... std::cout << "CPU-Clock: " << (((lCnt2-lCnt1)/100000)-200) << " MHz" << std::endl; } else std::cout << "GetTickCount-not found ..." << std::endl; getchar(); return 0; }Viel spass beim probieren
-
CStern schrieb:
ich stehe ASM- (Inline) sehr positiv gegenüber. Es gibt viele Dinge die nur über ASM am Prozessor ausgereizt werden können. Notwendig dazu ist, dass man den Befehlssatz der CPU wirklich gut beherrscht...
Bis hierhin kann ich zwar noch ungefaehr zustimmen, aber was hat das mit dem Thema zu tun?
CStern schrieb:
[...] Man muss wissen, dass alle neueren Prozessore den Kernel- und Usermodus beherrschen und zB M$ in Windows davon ausführlichst Gebrauch macht.
Aeh, das ist wirklich keine Neuigkeit. Und jedes aktuelle Makro-Kern-OS macht letztendlich ungefaehr aehnlich viele Kern-Aufrufe, bzw. Spruenge zwischen Berechtigungsebenen. Hat nur leider wirklich gar nichts mehr mit dem Thema zu tun.
CStern schrieb:
Es gibt eine Kehrseite der Medaille die da lautet: Zuviel ASM kann auch schädlich sein, weil eine ASM-Instruktion per Quellcode meistens nicht mehr im Kompilierungsprozess mit einfließt, bzw. so interpretiert wird, wie reiner C-Code, und dann so pur übernommen wird.
Das ergibt ueberhaupt keinen Sinn.
CStern schrieb:
Heutige Compiler sind aber das feinste was es in Bezug auf Codeeffizienz gibt und man muss da schon wie Waage zwischen der Hochsprache und dem ASM haben. Hochsprache und ASM müssen sich also ergänzen können - nicht bremsen!
Von reinen Assemblern heutzutage würde ich abraten.Naja. Kommt sehr auf den Compiler, das Koennen des Programmierers und die Anforderungen des Projekts an.
Pauschal kann man vielleicht sagen, dass es nur sehr selten Sinn macht, ein Projekt in reinem Assembler umzusetzen, aber darum geht es in diesem Thema wie gesagt gar nicht!
Es geht darum, wie am Besten Assembler gelernt werden kann.
-
Hallo,
im Makro _ASM eingeschlossene Instruktionen werden nicht vom Compiler übersetzt. Macht es jetzt Sinn? Somit auch nicht optimiert etc.
Mir ging es weiter darum das, was ich geschrieben habe zu dokumentieren:
Was macht Sinn, was nicht. Instruktion ... hmmm.... Wenn man was zu sehen bekommt,
wie -ASM im code aussieht, es ausprobiert und selber dann daran arbeitet. Damit lernt man ASM (Inline-ASM). Zum Guten nutzen hoffentlich.Ferner bitte ich Dich darum, die Zitiererei zu unterlassen
und Dir einen freundlichen Ton gegenüber neuen Teilnehmern anzugewöhnen. Weil ich weiß, im Gegensatz zu vielen Menschen des real Live von was ich rede, und was ich geredet habe. Klar?
-
Nobuo T schrieb:
Es geht darum, wie am Besten Assembler gelernt werden kann.
der ist auch nicht zu verachten: http://betov.free.fr/
-
Hallo ich hab mir da mal das Tutorial runtergeladen AVG hat sich sofort gemeldet das da Viren drin sind .....
-
naja.. mal baQ to topic
Ich finde, bevor man sich in das totale Kaos stürzt, sollte man sich ein bisschen mit Inline ASM auseinander setzen. So brauch man u.a. erstmal garnix von Interrupts wissen etc. Habe mir jetzt auch schonmal ein größeren Einblick verschafft und bei uns in der Software den ein oder anderen Algorithmus ein wenig optimiert...
Fragen folgen :D:D:D
-
Ich habe mit Inline ASM beste Erfahrungen; zuerst habe ich die Grundlagen, was/wann/wie man in ein Register transportieren muss, die Befehle darauf anwenden, Sprünge etc. alles in Inline ASM gelernt. Wenn man das nicht tut muss man von Anfang an mit Ein/Ausgaben anfangen, sei es mit Win32 oder mit den DOS-Interrupts, und wenn man unter DOS mal eben was probieren möchte was eine Zahl entgegen nimmt und ein Resultat als String ausgibt dann gibt das schon viel Aufwand und viel zu lernen, was man sonst erst später muss (wenn man überhaupt DOS-Programme schreiben will - ich hab's schon getan).
Die Inline-ASM Instruktionen werden meines Wissens sicher nicht optimiert, das ist ja nicht der Sinn davon; die werden sicher so übernommen wie man sie programmiert (und die Optimierung stellt nicht gleich den Code um)? Unter C++, MFC etc sieht das natürlich anders aus, ob eine Methode inline hineinkopiert wird oder nicht, ob FPU verwendet wird, Übergabe/Speicherung von Variablen in Registern etc. in Assembler macht man das ja alles selbst oder eben nicht, da programmiert der Compiler wohl nicht etwas neues.