Ich denke dass die GDT-Tabelle jetzt von den Bytes her richtig ist. Da man ja am Ende auf 8 Bytes kommt. Aber die Bit-Nummerierung ist etwas kaputt. Kann man da nicht besser die Grafik aus dem Magazin nehmen?

== Beispielcode falsch? ==

Ich finde die Grafik ziemlich ansprechend: http://wiki.osdev.org/GDT

Was mir noch aufgefallen ist: Ist der Beispielcode richtig? das RW-Bit ist dort mit der Bitmask 0x40 (also Bit 7) verzeichnet - in der Tabelle aber mit Bit 1.

Ich lasse da jetzt aber mal die Finger weg, weil ich nicht wirklich Ahnung davon habe. [[Benutzer:Garfield|Garfield]]
:Also ich schätze mal die Bitnummerierungen in der Tabelle sind falsch. Entweder du schaust in die Magazine, auf OSDev.org oder in ein anderes OS. Bei letzteren kann man zumindestens davon ausgehen, dass es stimmt, da es läuft.[[Benutzer:Jgraef|Jgraef]]

== Selektoren ==

Müsste man einen Selektor für Usersegment nicht mit 0x2b angeben, wenn es der 5. eintrag sein soll?
Null-Deskriptor (0) + Kernel Codesegment (1) + Kernel Datensegment (2) + User Codesegment (3) + User Datensegment (4) + task state segment(5)
hat also Index 5.<br>
und 0x23 = 00100 011 (00100 = 4 müsste aber 5 sein 00101) von daher:<br>
0000 0011 |<br>
0010 1000 =<br>
0010 1011 = 0x2b --[[Benutzer:Sebi2020|Sebi2020]] 20:27, 9. Jan. 2010 (CET)
:Soweit ich das nachvollziehen kann, ja, aber worauf beziehst du dich jetzt genau? --[[Benutzer:XanClic|XanClic]] 21:28, 9. Jan. 2010 (CET)
:: Auf den Abschnitt Selektoren im GDT Artikel: "Um also nach ds das Segment zu laden, das durch den fünften GDT-Eintrag beschrieben wird, und zwar als Userspace-Segment (Ring 3), könnte man folgenden Code verwenden:<br>
::<asm>mov $0x23 %ax   mov %ax, %ds</asm>
::: Müsste es nicht demzufolge dann 0x2b heißen? 0x23 Würde den 4 Eintrag in der GDT laden, und das wäre denn, wenn sie so eingerichtet ist wie vorgeschlagen, das User-Datensegment. --[[Benutzer:Sebi2020|Sebi2020]] 22:12, 9. Jan. 2010 (CET)
:::: Der fünfte Eintrag hat den Index 4, weil bei Null zu zählen angefangen wird. Passt also alles. --[[Benutzer:Taljeth|Taljeth]] 23:39, 9. Jan. 2010 (CET)

=== [[Global Descriptor Table#Struktur eines Eintrages|Struktur eines Eintrages]] ===
Diese Tabelle definiert nicht eindeutig, ob sich LIMIT[19:16] in den oberen 4 Bits (von der Tabelle suggeriert), oder in den unteren 4 Bits (korrekt) von Byte 6 befindet. Ich bin dafür horizontale Tabellen für Bitfelder (siehe z.B. [[CGA]], [[Control Register]], ...) zu verwenden. --[[Benutzer:Jidder|Jidder]] 20:43, 25. Sep. 2010 (CEST)

== I286 ==
Bei der I 268 dürfte doch eigentlich nur 24 Bit Base Addressen verwenden. Wie geht das den, wo doch hier alle Descriptoren 32 Bit Base Addressen enthalten. --[[Benutzer:Sannaj|Sannaj]] 09:21, 25. Nov. 2011 (CET)
: Beim 286 werden einfach die Bits 31..24 von der Basis (also Byte 7 im Descriptor) ignoriert, ebenso wie alle Limit-Bits oberhalb von Bit 15 und das Granularity-Flag. Es gibt auf dem 286 wimre sogar einen korrekten Überlauf in die unteren Bytes wenn so ein Segment die 16MB-Grenze überschreitet, bei 386 und aufwärts gibt es das nicht an der 16MB-Grenze sondern nur an der 4GB-Grenze. Das mit dem ignorieren klappt aber nur bei den Descriptoren für die normalen Datensegmente, einige der System-Descriptoren gibt es hingegen doppelt (mit unterschiedlichen Typen), einmal für 16Bit-PM und einmal für 32Bit-PM (bei 386 und aufwärts funktionieren natürlich beide). --[[Benutzer:Erik.vikinger|Erik.vikinger]] 10:04, 25. Nov. 2011 (CET)
: Wir müssen uns hier im Wiki auf das Wesentliche beschränken. Wenn wir hier alle möglichen urtümlichen Varianten behandeln, verwirren wir mehr, als dass das Wiki nützt. Ab einem gewissen Punkt muss man einfach sagen, dass es keinen Sinn macht hier auf diese Details einzugehen. Wenn dich das genauer interessiert, solltest du entweder in die aktuellen Intel Manuals schauen, oder dir das Manual vom 286er ergoogeln. --[[Benutzer:Jidder|Jidder]] 13:35, 25. Nov. 2011 (CET)
:: Das sollte jetzt keine Aufforderung sein, das in den Artikel einzubauen. Hat mich halt mal interessiert und ich hab im Internet nichts dazu gefunden. Also danke für die Auskunft. --[[Benutzer:Sannaj|Sannaj]] 18:28, 25. Nov. 2011 (CET)