Assembler 16 / 32 / 64 Bit ?
-
Hallo zusammen,
ich habe gerade erst mit Assembler begonnen und habe einige Fragen.
Mir ist aufgefallen, das es zum einen Windows Assembler gibt unter denen man mit Calls Arbeitet und Dos Assembler unter denen man mit Interupts Arbeitet.Außerdem hatte ich Problem beim Linken meines Hallo Welt Programms, da ich mit dem masm32 Packet gearbeitet habe und der beispiel Code in 16 Bit Format geschrieben war.
Hier nun meine Frage worin liegt der Unterschied zwischen 16 Bit 32 Bit und 64 Bit Assembler bei 16 und 32 Bit gibt es ja andere Registerbezeichungen z.B. ax und eax wie ist das nun bei der 64 Bit Architektur gibt es da wieder ander Bezeichnungen, da braucht man dann auch wieder einen anderen Assembler oder nicht.
Das Beste wäre, wenn jemand so ein kleines Hallo welt Programm mal in allen 3 Arten
für mich Coden könnten.Hoffe mir kann jemand die Frage beantworten
mfg finalmove
-
Ein Hallo welt auf 3 arten kann ich dir nicht bieten, aber vielleicht hilft es trotzdem. 64-bit kannst du unter (dem normalen) windows gar nicht proggen. Wies mit 16 bit aussieht weiß ich nicht, glaube das geht. Zu den unterschieden:
Wie du schon richtig festgestellt hast, sind (u.a.) die Register unterschiedlich. Dabei gilt: die kleineren Register kann man (meist) trotzdem ansprechen. So hast du im long mode rax (64 bit), eax (32 bit), ax (16 bit) und noch das 8 bit register (al?). Dabei sind die register verschachtelt. Der unterschied zwischen call und int um systemfunktion aufzurufen liegt daran, dass du unter 32 bit die windows api benutzt.
-
ness schrieb:
Ein Hallo welt auf 3 arten kann ich dir nicht bieten,[...]
Tjo, ich leider auch nicht - was fuer Unterschiede sich jeweils im Code ergeben, haengt auch stark vom verwendeten OS ab. Theoretisch koennte der Code fuer alle 3 Versionen auch ziemlich gleich aussehen.
Das Problem mit deinem Beispielcode ist vermutlich auch weniger die Tatsache, dass es sich um 16Bit-Code handelt, sondern eher, dass es DOS-Code ist, den du versucht hast, in ein Windows-Programm zu linken.
Kein Wunder, dass Winodws dann beim Starten ein wenig verwirrt ist.Hast du dein Problem beim Linken inzwischen beheben koennen? Ansonsten mal ein wenig hier im Forum stoebern, entsprechende Fragen sind schon oefter's vorgekommen (vielleicht sollte ich mal ein Beispiel in die FAQ verschieben... :p)
Es gibt uebrigens keine "Windows" und "DOS"-Assembler, wie du es hier darstellst. Letztendlich erstellt der Assembler aus den Quellcodes nur eine Objektdatei. Ob daraus nun ein Windows-, DOS-Programm oder whatever wird, entscheidet sich beim Linken.
ness schrieb:
Der unterschied zwischen call und int um systemfunktion aufzurufen liegt daran, dass du unter 32 bit die windows api benutzt.
Hm... Ich schreibe bisweilen auch 32Bit-Programme in Assembler und benutze Interrupts, um Systemfunktionen aufzurufen. :p
Ob Interrupts oder Calls fuer Systemaufrufe verwendet werden, hat weder etwas mit 16, 32 oder 64Bit, noch mit dem verwendeten Assembler zu tun, sondern haengt allein vom Interface des Ziel-Systems ab.
-
OK vielen dank erst mal für die Infos,
@Nobuo T: das Problem mit dem Linken habe ich bereits behoben, es lag wie gesagt an dem verwendeten Linker, ich wollte ein 16 Bit Programm mit einem 32 Bit Linker Linken, und das ging natürlich nicht.
Gibt es eigentlich auch Unterschiede zwischen Assembler auf einem Linux OS und Windows OS ?
-
Klar. Mit reinem assembler kannst du unter einem vernünftigen os wenig anstellen, was nicht osabhängig ist.
-
So es ist wieder Freitag und ich kann mich mal wieder um den Post kümmer.
Also ich wollte jetzt mal ganz bei den Basics anfangen, ich müsste doch auch ohne Betriebssystem den Prozessor ansprechen ? Denn die befehle die ich ausführe kann doch der Prozessor, wie ist es dann aber möglich, dass ein Programm das ander Überwacht ?
Außerdem, wieder die alte Frage warum kann ich ein 16 Bit Programm nicht mit dem gleichen Linker linken wie ein 32 Bit Programm der Prozessor hat doch noch die 16 Bit Register und so weiter ?
Und warum kann ich unter Windows nur Calls verwenden und keine Interupts, blockiert das das Betriebssystem oder warum geht das nicht, denn der Prozessor hat doch intern auch noch die Interuppts ?
Fragen über Fragen aber ich steig da noch net so richtig durch !
Und hat jemand nen Assembler und Linker mit dem ich ein 64 Bit Programm Coden kann ?
Jetzt aber genug, ich bitte um Antworten
mfg finalmove
-
Hi
1. Neben den Prozessorbefehlen gibt es noch die Assembleranweisung, der Assembler ist plump ausgedrückt, die "Hochsprache" für den Opcode der CPU.
2. Du kannst mit Masm32 auch 16 bit Code linken, siehe hier: http://www.assembler.my100megs.com/masm.htm
3. Windows und auch Linux tun alles, damit Du als User nicht durchblickst, halten Dich von allem fern, insbesondere von den kürzesten Wegen im Rechner.
Will sagen, wegen der Sicherheit, sonst könnte sich ja jeder ein OS programmieren.
-
Ach,ja und 4.
Ich glaub der nasm kann das, bin mir jetzt aber nicht 100 pro sicher: http://nasm.sourceforge.net/
Du kannst Dir natürlich auch WinXP 64 (bei Linux weiß ich das jetzt nicht so...) drauftun, und mit Debug.exe Dein Hallowelt Programm tippen, nur wirst Du da keinen Unterschied erkennen, weil dafür stets die alten 16bit Register ausreichen.
-
finalmove schrieb:
Also ich wollte jetzt mal ganz bei den Basics anfangen, ich müsste doch auch ohne Betriebssystem den Prozessor ansprechen ? Denn die befehle die ich ausführe kann doch der Prozessor, wie ist es dann aber möglich, dass ein Programm das ander Überwacht ?
Bitte formuliere die Frage nochmal ausfuehrlicher - so kann ich sie nicht eindeutig beantworten (was genau ist mit "ein Programm das ander Überwacht" gemeint?).
finalmove schrieb:
Außerdem, wieder die alte Frage warum kann ich ein 16 Bit Programm nicht mit dem gleichen Linker linken wie ein 32 Bit Programm der Prozessor hat doch noch die 16 Bit Register und so weiter ?
Wie schon gesagt wurde: Geht meistens. Haengt ganz davon ab, welche Programmdateiformate (versch. .exe-Formate, .com, usw.) der Linker unterstuetzt.
finalmove schrieb:
Und warum kann ich unter Windows nur Calls verwenden und keine Interupts, blockiert das das Betriebssystem oder warum geht das nicht, denn der Prozessor hat doch intern auch noch die Interuppts ?
Du kannst auch unter Windows Interrupts verwenden, wenn du willst. Du kannst sogar versuchen per in/out direkt auf die Hardware zuzugreifen, oder wild ueberall im Speicher rumzuschreiben - da gibt's im Grunde genommen keine Probleme mit.
Das Betriebssystem (OS) muss jedoch bestimmte Regeln aufstellen, was die einzelnen Programme machen duerfen, was sie nicht duerfen und wie sich die Programme mit dem OS unterhalten koennen.
Ich denke, Punkt 1&2 sind klar - Sonst waere zB. Multitasking wie unter Windows gar nicht moeglich, da ja theoretisch jedes Programm einfach ein anderes Programm, oder gar das ganze OS abschiessen koennte, weil es Teile fremden Codes im Speicher loescht, oder ein Programm einem anderen dazwischenfunkt, wenn es gerade etwas mit einem bestimmten Hardware-Geraet machen will, usw.
Damit das OS seine Programme baendigen kann, ihnen Rechenzeit zuweisen, bzw. auf die Finger klopfen kann, wenn sie versuchen gegen die Regeln zu verstossen, bietet die i386-CPU im sog. Protected Mode verschiedene Funktionen. zB. die Exceptions.
Fuer naehere Einzelheiten kannst du dir mal das Protected Mode Tutorial in den
Asm-FAQ durchlesen.Punkt 3 sollte dann auch klar sein: Wenn die Programme aus og. Gruenden nicht selbst direkt auf die Hardware zugreifen duerfen, brauchen sie eine Moeglichkeit, um dem OS mitzuteilen, was sie gerne mit der Hardware machen wuerden. Das OS koordiniert dann die Hardwarezugriffe der einzelnen Programme, damit da nichts durcheinander kommt.
Bei Windows funktioniert diese Kommunikation zwischen OS und Programm nunmal anders als unter DOS, Linux oder beim BIOS groesstenteils nicht ueber Interrupts (ein paar Interruptfunktionen stellt Windows AFAIK aber auch noch bereit) sondern ueber calls. Alles nur eine Konventionssache - Windows hat zu Interruptaufrufen einfach nicht viel zu sagen.
Hoffe, ich konnte jetzt mal wenigstens etwas Licht ins Dunkel bringen.
-
mit fasm kann man 16/32/64 bit programme erstellen. Fasm ist mE sowieso der beste Assembler.
-
Zu der Überwachung: Der Prozessor weigert sich einfach, die Befehle auszuführen, die das Betriebssystem kompromittieren würden. Also alles, was irgendwie Taskselektoren, Deskriptortabellen, Page Tables und solches Zeug verwaltet, ist gesperrt. Das steht aber wohl in der Doku dabei.
-
Vielen dank erst mal an alle
@Nobuo T: Das war super erklärt und ich denke ich habe jetzt auch einiges besser verstanden, habe mit einem Freund neulich erst wieder über das Thema gesprochen, und er hat mir auch gesagt, das das OS einfach immer noch eine Schicht näher am Prozessor ist wie mein Code.
Lässt das OS z.B. nur dateien ausführen, die z.B. .exe am ende haben somit weiß windows ah ja da will jemand code ausführen.
Was mich wesentlich im bezug auf die Frage zu den Calls weiter gebracht hat ist, dass das OS einfach nicht will, dass ich alles auf dem Rechner machen darf bezüglich der Sicherheit sonst könnt ich ja ohne weiteres Admin rechte bekommen und so weiter.Eine weiter Frage ist, gibt es eine möglichkeit, assembler code direkt auszufürhen, das heist so ne Art mini OS zu booten so DOS eingabeaufforderungs mäßig, und dor dann direkt assembler befehle an den Prozessor zu schicken ohne Betriebssystem dazwischen, das dann kein Multithreading und Zeitscheiben verfahren möglich ist oder nur schwer weil man es selber Coden müsste is mir klar aber dann kann ich doch auf einem 16 / 32 / 64 Bit Rechner immer das gleiche Hallo Welt Programm ausführen oder ?
mfg Finalmove
-
hi,
Du musst halt deinen eigenen bootloader schreiben oder alternativ deinen assemblercode von grub oder anderen bootloadern laden.
finalmove schrieb:
...dann kann ich doch auf einem 16 / 32 / 64 Bit Rechner immer das gleiche Hallo Welt Programm ausführen oder?
Das kommt ganz auf die Rechner drauf an. Du kannst beispielsweise ein für den x86 gelinktes programm auch auf einem x86-64 (=AMD64) ausführen, aber mit Sicherheit _nicht_ auf einem Itanium 1/2 (=IA64). Prinzipiel wirst du ohne Betriebssystem eher große Probleme mit der Portabilität bekommen als mit, wegen unterschiedlicher Hardware (nicht nur Prozessor gemeint).
Hoffe es hilft.
-
Auch recht schoen: Schreibe ein .com-Programm fuer DOS.
Dieses Dateiformat hat keine Header - enthaelt also nur deinen Code und es gibt nur relativ wenig zu Beachten.
Wenn du die Treiber fuer den hohen Speicher (himem.sys; emm386.exe) zudem nicht laedtst, startet DOS dein Programm im RealMode. Damit kannst du dann praktisch alles mit dem Rechner und der Hardware machen, wozu du lustig bist.
Das ist dann fast als wuerde dein Code ohne OS gestartet (du kannst DOS einfach ueberschreiben), nur dass du falls gewuenscht doch noch ein paar Funktionen von DOS gestellt bekommst (Dateisystem, etc.).
-
Wenn du wirklich osdev betreiben willst würd ich dir auch empfehlen einen Emulator (bochs, qemu, VirtualPC) zu benutzen. Damit entfällt dann lästiges Neustarten und man kann auch durch den Code steppen, hat Fehlermeldungen...
-
Im Windows Server 2003 SDK (mitte 2005) ist für C/C++ neben dem cross-compiler ein "masm64" (für AMD) und ein "IAS" (für intel) samt linker etc. pp, allerdings ohne weitere (ausführliche) info enthalten.
Gruß
bjthr