Diskussion:Protected Mode

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Protected Mode“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit oder --~~~~.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Überarbeitung

Ich plane, ein paar Details über die Arbeitsweise der CPU im Protected Mode einzufügen. Dafür "parke" ich hier erstmal ein paar Bilder zwischen, ehe ich sie in den Artikel einfüge :-)

• 
• 

--RokerHRO 15:38, 24. Jan. 2007 (CET)

Wann willst du sie den einfügen? Der Beitrag ist vor über einem Jahr datiert und heute sind sie imer noch nicht drinne? --62.180.145.38 11:50, 4. Mai 2008 (CEST)

Tja, mit den Grafiken allein ist es nicht getan. Dazu braucht man ein bisschen Lust und Zeit und Ruhe, um die Grafiken zu erklären usw. Die habe ich im Moment halt nicht. --RokerHRO 14:00, 4. Mai 2008 (CEST)

Titel

Den Artikel bitte in Protected Mode umbenennen. Das ist der "richtige" Name. --217.185.137.69 15:25, 14. Apr. 2008 (CEST)

Frag doch mal Benutzer:Stern, der hatte den Artikel damals umbenannt. --RokerHRO 15:39, 14. Apr. 2008 (CEST)

Ach nein. Lassen wir "Schutzmodus", ich habe meine Meinung geändert. Es reicht ja, wenn er im Text erwähnt wird. --62.180.145.147 14:47, 5. Mai 2008 (CEST)

hmm, ich unterstuetze den antrag auf verwednugn von "protected mode"! -> der umbennende autor scheint mehr in der "Evolutionstheorie und Volkswirtschaftslehre" zu hause zu sein, und im technischen umfeld habe ich noch nie "schutz modus" vernommen. auch ein kurzer google test im deutschen internet zeigt keine keine deutliche häufung bei schutz modus, im gegenteil es gibt wohl eine siemens embedded technologie dieses namens. achja der zugehoerige "real mode" http://de.wikipedia.org/wiki/Real_Mode konnte sich ja auch bsi jetzt zwanghafter eindeutschung entziehen. also, fuer umbennung in den stehenden und eingeführten technischen begriff "protected mode" ! --- 141.52.232.84 21:29, 14. Mär. 2010 (CET)

erledigtErledigt, und das nach nur 2 Jahren! ;-) MfG, --R.Schuster 18:21, 5. Jun. 2010 (CEST)

Danke! Danke, endlich laesst der Schmerz nach! 95.115.68.199 (13:10, 4. Jul 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Falsches im Text

Was ist ein Betriebssystem

"Die meisten modernen Betriebssysteme für x86-Rechner, wie zum Beispiel Windows (ab Windows 2.03 optional, ab Windows 3.1 zwingend), Linux oder Mac OS X, arbeiten in diesem Betriebsmodus."

Windows vor Win95 war kein Betriebsystem. Es war ohne MS-DOS nicht lauffähig. Siehe auch http://www.thefreecountry.com/programming/dosextenders.shtml für damalige Programmierung im 32-Bit PM.

Win3.x benutzte, so wie Win95, DOS nur zum Booten und teilweise danach noch für Dateisystemzugriffe. Alles andere, Speicherverwaltung, Taskverwaltung, Grafik, Sound, Netzwerk (teilweise) hat es selber gemacht. (Teilweise gab es auch schon für Win3.x sogenannte "32-Bit-Festplattentreiber", die dann nur von Windows genutzt wurden, unter reinem DOS (also nicht in der DOS-Box) waren diese Platten (meist SCSI-Platten) nicht ansprechbar.)

Kurzum: Die meisten Funktionen, die ein aktuelles Betriebssystem ausmachen, hat Win3.x bereits selber, also ohne DOS-Funktionen zu benötigen, gemacht. Somit kann man es durchaus als Betriebssystem, oder von mir aus Betriebssystemerweiterung gelten lassen. Für die Art des Speicherzugriffs (also Protected Mode) und der Speicherverwaltung war es (nach dem Hochfahren) allemal unabhängig von DOS. (Im Gegensatz zu den ersten Windows-Versionen 1.x und 2.x.) Und darum geht es hier in diesem Artikel. --RokerHRO 20:54, 27. Sep. 2008 (CEST)

Einleitung in den PM

Also in der Einleitung ist diese Passage falsch: "bezeichnet einen speziellen Betriebsmodus der IA-32-Architektur (auch als x86-Architektur bekannt) von Intel, der seit dem 80286er Prozessor vorhanden ist"

Weil:

1. "spezieller Betriebsmodus" -> der PM ist aber eigentlich der native Betriebsmodus dieser Prozessoren (der Real Mode soll in nach Intel nur noch aktivieren)

2. da steht es ist ein Modus der IA-32 Architektur, IA-32 sind aber erst die Prozessoren ab dem 386 (den da wurde erst der 32bit-Modus eingeführt)

3. IA-32 ist nicht x86! x86 sind alle Prozessoren ab dem 8086.

--62.180.145.38 11:24, 4. Mai 2008 (CEST)

Zu 1. Intel hat auch mal einen 80376 herausgebracht, der nur noch den PM kannte, ansonten aber ein 386er war. Er war ein Flop. Intel hatte in den Jahren nach der Verstellung des 80386 öfter versucht, den Real-Mode für tot zu erklären, aber wenn der Real Mode angeblich nur noch dazu da sein soll, in den PM zu schalten, dann stellt man sich schon die Frage, warum es ihn eigentlich noch bzw. wieder gibt und warum er nach wie vor vollkommen kompatibel ist?! Ganz einfach: Weil man es sich nicht erlauben kann, den Real Mode nicht mehr zu unterstützen. Ich finde, dass lediglich das "spezieller" in "spezieller Betriebsmodus" unangebracht ist. Eine Wertung hinsichtlich der Bedeutung der Betriebsmodi sollte der Artikel nicht vornehmen. --Ruscsi 13:15, 4. Mai 2008 (CEST)

Zu 2. und 3. gebe ich Dir voll recht. Da herrscht bei WP wirklich ein furchtbares Durcheinander und die korrekte Begriffsabgrenzung über alle dieses Thema betreffenden Artikel einzuführen wäre eine unglaublich große Aufgabe. Ich würde es sehr begrüßen, wenn sich jemand dieses Themas mal annehmen könnte. Ebenso unangebracht finde ich die häufig erwähnte Behauptung, der 8086/88 kenne (nur) den Real Mode. Der Real Mode wurde aber erst mit dem 80286 eingeführt. --Ruscsi 13:15, 4. Mai 2008 (CEST)

Das mit dem 376 hatte ich damals auch gehört, danke, dass du daran erinnert hast. Bisher fehlt dieser Prozessor in der Wikipedia anscheinend völlig. --RokerHRO 18:12, 4. Mai 2008 (CEST)

Du hängst dich an dem Wort "speziell" auf. Sollte man schreiben: "einer der Betriebsmodi der Prozessoren ab dem 286er"? Denn es ist ja nicht so, dass der eine Modus nativ läuft und die anderen "emuliert" werden oder sowas. Bezügl. der Aufdröselung in den 16-bit-Protected-Mode, der beim 286er eingeführt wurde und dem 32-Bit-PM, den es ab dem 386er gibt, gebe ich dir recht, da sollte man besser differenzieren. Ich seh schon, die Überarbeitung, die ich seit langem vorhabe, wird immer dringlicher. ;-( --RokerHRO 18:12, 4. Mai 2008 (CEST)

Großes Durcheinander? Allerdings. Selbst Intel hat den 8086 mit in die IA-32-Tüte gesteckt: In der IA-32 Dokumentation, die ich mir letztens von ihrer WWW-Seite runtergeladen hab steht, dass IA-32-Prozessoren alle von 8086 bis 486, Pentium X und Xeon sind. Wenn ich den Link wiederfinde kann ich ihn ja mal hier reinstellen. Also, viel Spaß. --62.180.145.147 14:40, 5. Mai 2008 (CEST)

Hier. Ging schneller als ich gedacht hab. Volume 3 A oder B, keine Ahnung. Die Brocken sind insgesamt 8MB groß. --62.180.145.147 14:43, 5. Mai 2008 (CEST)

In dem Manual, das ich gefunden habe ([1]) steht am Ende von Kapitel 1.1: “IA-32 architecture is the instruction set architecture and programming environment for Intel's 32-bit microprocessors.” Und Anfang von Kapitel 2 System Architecture Overview: “IA-32 architecture (beginning with the Intel386 processor family) provides [...]” --RokerHRO 21:06, 26. Feb. 2010 (CET)

Der 80376 wird/wurde als Embedded CPU hergestellt und ist/war somit nicht als CPU für den uns bekannten Heimcomputer vorgesehen. Weiterhin kann der 376 physikalisch nur 16 MB ansprechen (24 Bit Address Bus). Weiterhin gibt es keine Unterstützung von 16 Bit Segmenten (286er Code läuft nicht!), da das 'Default Operation Size' Bit im Segmentdeskriptor 1 sein muß (Quelle: Handbuch 80376/80386 DX)

Den RM gibt es noch aus Kompatibilitätsgründen - ein PC soll (theoretisch) noch mit MS DOS 1.0 laufen können. Der RM entspricht aber nicht 100% im Verhalten des 8086 - Überläufe bei der Addition der Segmentaddresse mit der Speicheraddresse zur linearen Addresse werden nicht behandelt. Somit kann man mit 286+ in diesem Modus 1MB+65519 Byte ansprechen. Mit dem 486 wurden extra Pins vorgesehen, über die exterm die Maskierung von Address Bit A20 gesteuert werden kann. (nicht signierter Beitrag von 79.199.58.131 (Diskussion | Beiträge) 15:17, 26. Feb. 2010 (CET))

Naja, bei 286er und 386er PCs wurde diese Schaltung über ein externes Gate, das berühmt-berüchtigte A20-Gate erledigt, ab dem 486er wanderte dieses Gate dann in die CPU. AFAIK war das Verhalten des 8086 bei diesem Überlauf gar nicht spezifiziert worden, somit müssen Nachfolger-CPUs nicht das gleiche Verhalten nachbilden, um als "kompatibel" verkauft werden zu können. Und natürlich verhält sich ein heutiger Prozessor auch in anderen Punkten vom Verhalten des 8086, da die 32-Bit-Befehle, FPU, MMX u.a. auch alles im Real-Mode zur Verfügung steht. --RokerHRO 21:06, 26. Feb. 2010 (CET)

Nur durch zusätzliche Opcodes verhält sich eine CPU nicht gleich anders. FPU gab es schon für den 8086 (8089). MMX läuft unter dem Tarnschleier der FPU (um bei Taskwechsel das Sichern der MMX-Daten sicherzustellen). SSE geht ohne Freischaltung nicht im RM. Vorgesehen die linearen Speicherbereiche 0x00000-0x0ffef über die Segmente 0xf001-0xffff ist nicht vorgesehen nach den Unterlagen die mir bekannt sind. Nur weil bei 286+ 0x0f als POP CS nicht funktioniert, sind diese nicht automatisch inkompatibel zum 8086. --79.199.56.73 17:17, 2. Mär. 2010 (CET)

Einigen wir uns darauf: Ein 286er und seine Nachfolger verhalten sich im Real Modus 100% so wie das dokumentierte Verhalten des 8086 ist. Der Opcode 0F_hex war meines Wissens beim 8086 "reserviert" (auch wenn er vom Schema der Opcodes her einem POP CS entsprach, und einige 8086er (Nachbauten?) bei diesem Opcode ein POP CS ausgeführt haben mögen. Ebenso die anderen Opcodes 60..67, die erst bei späteren Prozessoren eine definierte Bedeutung bekamen. --RokerHRO 23:03, 2. Mär. 2010 (CET)

POP CS geht auf Intel 8086/8088 ;) Hab es selbst vor 10~15 Jahren mal ausprobiert, wo ich mal kurz Zugriff auf einen passenden PC hatte. Man muß nur die Befehlswarteschlange berücksichtigen, da diese nicht gelöscht wird und sich somit noch Folgebefehle enthalten kann. 60-6F müssten 70-7F entsprechen, ist aber zu lange her als daß ich es jetzt noch 100% bestätigen kann. --79.199.74.98 22:53, 9. Mär. 2010 (CET)

Verschiebung nach Protected Mode

Hallo. Ich habe den Artikel auf Protected Mode verschoben, da Schutzmodus nicht nur ungeläufig ist, sondern bereits an WP:TF grenzt. MfG, --R.Schuster 18:16, 5. Jun. 2010 (CEST)

64 Bit

Es handelt sich, wenn man die Beschreibung ( http://www.intel.com/products/processor/manuals/ ) der Funktionen der CPUs durchliest, um einen komplett eigenen Modus und gehört aus dem Artikel in einen entsprechend eigenen hinein (im englischen Wiki ist das auch getrennt behandelt). Protected Mode ist nur das was im 80286 neu eingebaut und im 80386 erweitert wurde und mehr nicht. --79.199.61.109 20:24, 8. Jun. 2010 (CEST)

Das ist Ansichtssache. Es werden im 64-Bit "Long Mode" nunmal sehr viele Register und Datenstrukturen weiter verwendet, die eben beim 286er/386er mit dem PM eingeführt worden sind: GDT(R), LDT(R), IDT(R), Segmentselektoren und -deskriptoren, die Privilegienlevel usw.

Auch das Paging ist auch nur im PM möglich, im 64-Bit-Modus ist es zwingend vorgeschrieben. Auf Systemlevel ist da echt vieles nur auf 64 Bit aufgebort worden. Grundlegend Neues hab ich jedenfalls nicht gefunden.

Aus Sicht der Anwendungsprogramme fallen eben die breiteren Register und ihre doppelte Anzahl auf. Im Gegensatz zu den 32-Bit-Erweiterungen, die auch für 16-Bit- und RealMode-Programme nutzbar waren, sind dagegen die 64-Bit-Erweiterungen nur im 64-Bit-Modus verfügbar. Grundlegend anders ist das Programmieren da aber auch nicht, sofern man auch vorher schon ein "flat memory model" gewohnt war (was heute auch auf 32-bit-Betriebssystemen ja Standard ist)

So gesehen ist der 64-Bit-Modus nicht so grundlegend anders als der 32-Bit-PM und vieles kann daher an der gleichen Stelle beschrieben werden. Wie wir das hier nun machen und in welchen/m Artikel(n), ohne Redundanzen zu erzeugen, darüber kann man natürlich diskutieren. :-)

--RokerHRO 20:59, 8. Jun. 2010 (CEST)

Die Datenstrukturen werden nur deswegen verwendet, weil dies der einfachste Weg war die Architektur entsprechend auf 64 bit zu erweiteren. Es findet keine Segmentierung mehr statt (als Segemntbasis wird für CS,SS,DS & ES 0 gesetzt -> keine Segmentierung mehr des Speichers.) Es werden keinen Limit Checks durchgeführt. ARPL (Adjust Requested Privilege Level) funktioniert nicht. Intel selbst spricht in seinen Dokumenten auch von unterschiedlichen Modi: Real, Mode, Protected Mode, Virtual 8086 Mode, System Managment Mode und IA-32e Mode (innerhalb dessen 64 Bit Mode & Compatibility Mode) (siehe Vol 3A Seite 2-11 {fortlaufende PDF Seite 59}) Endweder alle Modi in einen Beitrag (und dann neuer Titel "Betriebsmodi der x86 CPUs / IA-32 Architektur) oder trennen --79.199.77.248 18:56, 11. Jun. 2010 (CEST)

Wie Intel das nennt, ist mir relativ schnuppe. Ich hatte meine Informationen über den 64-Bit-Modus von AMD, die haben's schließlich erfunden. ;-)

Es werden im 64-Bit-Modus zwar viele Felder aus den Segmentdeskriptoren ignoriert, aber die Datenstruktur und mit ihr die gesamte Desctriptor Tables (GDT und IDT) werden weiterhin verwendet. Sie sind sogar auf 64 Bit aufgebohrt worden. Und für die Segmentregister FS und GS wird weiterhin die Segmentbasisadresse ausgewertet.

Es werden aber nicht nur die Datenstrukturen der Segmentierungs-Einheit weiter verwendet, auch das gesamte Paging wurde ja im 386er PM eingeführt das wird im 64-Bit-Modus im Prinzip genauso weitergeführt, mit eben Anpassungen auf 64 Bit und 4-Level-Paging. Grundlegend Neues gibts da aber AFAIK ebenso nicht.

Ich habe aber nichts dagegen, wenn der ganze 64-Bit-Kram in einem separaten Artikel ausgelagert wird, wo man dann auf den („klassischen“) Protected Mode verweisen kann und dann nur noch die Unterschiede behandelt werden müssen. Wer macht's? --RokerHRO 19:26, 11. Jun. 2010 (CEST)

Unterschied zwischen dem 16 bit mode und dem 32 bit mode und der adressierbaren Speichermenge

Immer wieder kann man im Internet es lesen das man angeblich den 32 Bit Mode benötigen würde, um 4 GiB an Speicher adressieren zu können. Das stimmt aber überhaupt gar nicht. Schon auf einem 80386+ ist es möglich im 16 Bit Protected Mode den gesamten 4 GiB Adressraum zu adressieren. (Nur auf einem 80286er ist man auf 16 MiB beschränkt, aber nicht mehr auf einem Intel 80386+!!!)

Dafür erweitert man die Segmentgrösse im Segmenteintrag einer GDT/LDT von defaultmäßig 64 KiB auf 4 GiB. Nun kann man beispielsweise zusammen mit einem 32 Bit-Adress-Register den gesamten 4 GiB-Adressraum adressieren und den freien (und physikalisch vorhandenen) Speicher davon verwenden, insofern der Speicher noch nicht vom Bios und anderen Geräten bereits belegt und reserviert wurde. Vergleichsweise so wie auch im 32 bit mode.

Der einzige Unterschied zwischen dem 16 bit mode und dem 32 bit mode ist die Bedeutung und Verwendung der Operandsize(66h)- und Adresssize(67h)- Prefixe. (Mit der adressierbaren Speichermenge hat das aber rein gar nichts zu tun.) Diese Operandsize- und Adresssize- Prefixe können im Protected mode, sowie auch im Real Adressmode und auch im Virtual-8086 mode im Codesegment verwendet werden, um den defaultmäßige Grösse des Operanden und/oder der Adresse für die Dauer eines Befehls zu überschreiben bzw. umzukehren. Die defaultmäßige Grösse des Operanden und/oder der Adresse (16 bit- oder 32 bit mode) kann mit dem D-Flag im code-segment descriptor einer GDT/LDT verändert werden.

Mit den Assembler-Direktiven USE16 und USE32 zeigen wir den Assembler welchen Mode wir verwenden wollen und wie unsere Befehle interpretiert werden sollen. Der Assembler erzeugt dann entweder Opcodes mit, oder ohne solche Prefixe.

[USE16]

Im 16 bit mode muss der Assembler diese Prefixe verwenden, wenn man 32 bit Operanden und/oder 32 bit Adressen verwenden möchte. Anderfalls werden im 16 bit mode nur 16 bit Operanden und/oder 16 bit Adressen verwendet.

[USE32]

Im 32 bit mode ändert sich die Bedeutung dieser Operandsize- und Adresssize-Prefixe grundlegend. Wenn man im 32 bit mode 32 bit Operanden und/oder 32 bit Adressen verwenden möchte, dann muss der Assembler diese Prefixe weglassen und nur wenn man 16 bit Operanden und/oder 16 bit Adressen verwenden möchte, dann muss der Assembler diese Prefixe verwenden.

--92.231.180.48 10:36, 28. Jan. 2013 (CET)Dirk Wolfgang Glomp

Du hast recht. Ich habe dein Statement zum Anlass genommen, die von mir schon seit langem geplante Überarbeitung des Artikels zu beginnen. Ich hoffe, der Artikel ist nun ein bisschen verständlicher geworden. --RokerHRO (Diskussion) 13:39, 28. Jan. 2013 (CET)