Hallo, ich versuche gerade nachzuvollziehen wie die Ausführung eines Programms am PC funktioniert. Bei dem Szenario, was passiert, wenn ich (innerhalb eines Betriebssystems) einen Maschinencode ausführe der direkt auf die Hardware zugreift bin ich auf ein Problem gestoßen für das ich keine Antwort finden kann. Eigentlich soll auf die Hardware ja über das Betriebssystem zugegriffen werden. Die meisten Compiler werden daher direkte Zugriffe auf die Hardware nicht zulassen. Mal angenommen ich hätte einen Compiler zur Verfügung, der es mir erlaubt einen Maschinenbefehl zu generieren, der z.B. direkt auf einen I/O Pin des Prozessors zugreift. Wo, bzw. wie wird dieser böse Maschinenbefehl abgefangen? Läuft irgendwo im Betriebssystem oder auf der CPU eine Art Interpreter, der zulässigen Code von nicht zulässigen unterscheidet? Werden Programme eigentlich tatsächlich in Maschinencode abgelegt oder gibt es da noch einmal eine Abstraktionsschicht?
TO schrieb: > Wo, bzw. wie wird dieser böse Maschinenbefehl abgefangen? Im Prozessor selbst. Der hat mindestens 2 Modi, System und Anwendung. Und dein böser Befehl wird vom Prozessor im Anwendungsmodus nicht ausgeführt.
TO schrieb: > Werden Programme eigentlich tatsächlich in Maschinencode abgelegt oder > gibt es da noch einmal eine Abstraktionsschicht? Traditionell Maschinencode. Meist werden Programme auch in Maschinencode ausgeliefert und installiert. In Android vor V5 gibt es eine Abstraktionsschicht für die Apps. Programme sind als Code einer Pseudomaschine (Dalvik VM) abgelegt und werden zur Laufzeit in Maschinencode übersetzt. Seit V5 werden sie bei der Installation in Maschinencode übersetzt.
:
Bearbeitet durch User
A. K. schrieb: > Im Prozessor selbst. Der hat mindestens 2 Modi, System und Anwendung. > Und dein böser Befehl wird vom Prozessor im Anwendungsmodus nicht > ausgeführt. Ich hab eher etwas software-gesteuertes vermutet. Deshalb habe ich auch keine Informationen finden können. Wenn ich das richtig verstanden habe, dann läuft das Betriebssystem im System-Modus und kümmert sich auch um die Verwaltung dieser Modi des Prozessors. Beim Ausführen einer Anwendung wird dann in den Anwendungsmodus umgeschaltet?
Ja, so eine CPU hat einen "privileged mode" und einen "user mode". Bestimmte Instruktionen sind nur im privileged mode erlaubt. Deine Anwendung läuft im user mode. Deshalb müssen Hardware-Treiber (zumindest in Linux) auch quasi Kernel-Plugins sein.
Da findest du alles was du wissen willst: http://www.amazon.de/Moderne-Betriebssysteme-Pearson-Studium-Tanenbaum/dp/3827373425/ref=sr_1_1?ie=UTF8&qid=1459712038&sr=8-1&keywords=moderne+betriebssysteme
>Betriebssystem zugegriffen werden. Die meisten Compiler werden daher >direkte Zugriffe auf die Hardware nicht zulassen. Dem Compiler ist das vollkommen wurscht, was Du da diesbezüglich programmierst. Die direkten Hardwarezugriffe werden erst zur Laufzeit des Programms duch die CPU abgefangen, die dann via OS solche Meldungen ungefähr wie "In der Anwendung ist ein Problem aufgetreten, und muß beendet werden" triggern (Exception C0000005 auf Windows, SigSegV bzw Signal 11 unter UniX/Linux). Kannst Dir ja mal folgendes zu Gemüte führen, denn dort werden die Privilegien bzw. Ringe geregelt: https://de.wikipedia.org/wiki/Ring_%28CPU%29
:
Bearbeitet durch User
Hallo Ich sehe nur die Möglichkeit, passende Treiber zu programmieren, dabei kommt ein Großteil des Programmes in den Treiber, oder man verwendet ein Betriebssystem ohne Protected Mode bzw. Protection, oder man programmiert ohne Betriebssystem. Bei Windows gibt es universelle Treiber für I/O Zugriffe, aber ob die was taugen, Geschwindigkeit usw.., weiß ich nicht. MfG
Naja. Hardwaere beinhaltet eigene Protokolle. Einige sind spezifiziert, wie zB das SATA, andere ein Wenig, dafuer plus Herstellererweiterungen. Wie zB die Grafikkarten. Ein Diskcontroller besteht also aus dem Interface zur Disk, genannt SATA, und einem Businterface, definiert durch den Diskcontroller Hersteller. Wie man nun diesen controller in das Betriebssystem einbindet macht also der Diskcontroller Treiber, geschrieben vom Diskcontroller Hersteller. Dieser Treiber kann also Sektoren lesen und Schreiben, so etwa. Dann benoetigt man noch einen Filesystem Treiber, vom Betriebssystem. zB fuer NTFS von windows. oder Ext2, Ext3, Ext4 bei Linux.
Matthias K. schrieb: > passende Treiber zu programmieren, dabei > kommt ein Großteil des Programmes in den Treiber Nein, das ist ein kapitaler Fehler. Der Treiber soll so einfach wie möglich programmiert werden und nur das Nötigste enthalten, um die Hardware zu bedienen. U.a. deshalb, weil ein Treiber privilegiert genug ist, das ganze System zum Stillstand zu bringen, er darf daher keine Warteschleifen enthalten oder länger laufende Operationen. Das heisst nicht, dass das immer eingehalten wird, es gibt auch unter Windows oder Linux Gelegenheiten, wo man einige Zeit eine Sanduhr sieht und das System nicht mehr reagiert, aber eigentlich darf das nicht passieren. Wenn du z.B. eine Relaiskarte ansteuern willst, dann gehört in den Treiber die Ausgabe eines Bytes an den I/O-Port, allerhöchstens kann man noch im Treiber Funktionen unterbringen, um ein einzelnes Relais zu schalten. Alles andere gehört ins (User) Anwendungsprogramm. Georg
TO schrieb: > Wo, bzw. wie wird dieser böse > Maschinenbefehl abgefangen? Es werden nicht die Befehle abgefangen, sondern es werden die Adressen durch die Memory Protection Unit (MPU) geprüft. Die User-Applikation kriegt einen bestimmten Memory-Bereich zugewiesen. Versucht sie Zugriffe außerhalb des Bereichs, gibt es eine Exception. Z.B. konnte man noch bis Windows-XP direkt auf die COM1 (Adresse 0x3F8) zugreifen. Die Exception hat dann eine original 16550 UART emuliert und das ging sogar, wenn die UART am USB hing.
Ich hab leider viel davon vergessen. Ich empfehl das iApx386 User manual von Intel. Es gibt Trap Gates, die bilden das Interface zwischen den verschiedenen Schichten. Zum einen gibt es privilegierten Code, der laeft im Ring 0, das sind zB Treiber. User Code laeuft im Ring 3, und das Betriebssystem laeuft im Ring 2. Wenn zB ein Sprung auf nichtexistierendes Memory ausgefuehrt werden soll, wird dieser Code von der Platte oder so nachgeladen. Wenn eine nicht existierende RAM Adresse gelesen/geschrieben werden soll, wird diese Memory Seite angelegt, resp geswappt. Interrupts gehen durch ein Interrupt Gate, dort werden die Interrupts virtualisiert. IO Zugriffe gehen durch ein anderes Gate, dort werden die Rechte geprueft. Memory Segmente haben jeweils Zugriffsrechte. Ein User Programm darf zB nie in ein Codesegment schreiben. User Code darf auch nicht ins RAM des Betriebssystems schreiben. Wenn das trotzdem der Fall sein sollte, wird das auch durch ein Gate erledigt. Shared Memory wird zB so verwaltet.
Peter D. schrieb: > Es werden nicht die Befehle abgefangen, Doch. Beides. Es werden vom Prozessor privilegierte Befehle abgefangen, beispielsweise enable/disable Interrupt, und es werden Speicherzugriffe kontrolliert.
Oh D. schrieb: > Ich empfehl das iApx386 User manual von Intel. Ich nicht. Die bizarre Komplexität des 386 in dieser Frage geht erheblich über das hinaus, was für das Verständnis der Grundlagen erforderlich ist und ist eher historisch interessant als für heutige Verhältnisse wesentlich. Diese Komplexität war übertrieben. Das ganze Gedödel mit Call-, Bill-, Trap-, Interrupt- und Task-Gates war nett gedacht, wurde aber kaum jemals so genutzt wie vorgesehen. In der 64-Bit x86 Architektur wurde das zusammen mit anderen Aspekten der Segmentierung stark eingeschrumpft und daran orientiert, was man tatsächlich benötigt. Nicht mehr an den feuchten Träumen aus sehr CISC-lastigen 80ern. Ein Beispiel dafür stellen die SYSCALL/SYSENTER-Befehle dar, die den ganzen Segment/Gate-Kram links liegen lassen. Ich denke, man sollte sich für die Grundlagen eher an der Architektur der Cortex A Prozessoren von ARM orientieren.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.