Assembler 16 / 32 / 64 Bit ?
-
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