4. PMODE: dpl > CPL - wo liegt der Fehler?

PMODE: dpl > CPL - wo liegt der Fehler?

  • T

    Original erstellt von Nobuo T:
    Hast Du das GBit im Codesegment-Descriptor immernoch gesetzt?
    So weit ich das sehe assemblierst Du nach dem PM-Label 16Bit-Code... Das wuerde sich dann ein bissel beissen.
    Also: Entweder G-Bit loeschen oder 32Bit-Code benutzen.

    Was ist an Granularity und 16-Bit code so beißig? Klar man kann nicht alles adressieren ohne address size prefix, aber machbar ists doch.

    0
  • N

    Ups...
    Wars net das GBit, von dem abhaengt, ob 32 oder 16Bit code erwartet wird? 🙄
    Bleibt ja dann nur noch das DBit, das war hier schliesslich auch gesetzt...

    0
  • T

    Original erstellt von Nobuo T:
    Ups...
    Wars net das GBit, von dem abhaengt, ob 32 oder 16Bit code erwartet wird? 🙄
    Bleibt ja dann nur noch das DBit, das war hier schliesslich auch gesetzt...

    Okay, das akzeptiere ich (auch B-Bit für Datensegmente genannt afair) 😃

    0
  • S

    Das G-Bit besagt ob die max Größe bei 0 1MB oder bei 1 4GB ist! Das D-Bit besagt ob das Segment < oder > als 64kb ist! Letzteres gehört zum DPL! Ich habe es mal auf 1 gestellt => DPL verändert => Bochs sagt mir DPL != CPL! Also ich denk nicht dass das der Fehler ist! Das G-Bit habe ich immernoch gesetzt! Wo benutze ich denn 16bit Code was ich nicht darf? 😕

    Kevin

    0
  • T

    Original erstellt von Surkevin:
    **Das G-Bit besagt ob die max Größe bei 0 1MB oder bei 1 4GB ist!
    **

    Fast. Genauer: Ob das Limit mit 4k multipliziert werden soll und so einen Bereich bis zu 4GB hat.

    **
    Das D-Bit besagt ob das Segment < oder > als 64kb ist!
    **

    Nein, wozu soll man dazu ein Bit bauen? das kann man wunderbar aus dem Limit sehen. Das D/B-Bit (im zweitobersten Byte das bit nr. 6 von unten) bestimmt, ob es sihc um ein 16 oder 32-Bite segment handelt. Das bestimmt die Instruktionsdekodierung bzw. Stackoperandengrößen etc. Solange dien Code 16-Bit ist, musst du das D/B-Bit ausmachen.

    **
    Letzteres gehört zum DPL!
    **

    Das D/B-Bit ist weit weg vom DPL. Sicher, dass du wom richtigen Bit redest? 🙂 Im übrigen wäre es echt merkwürdig ein Bit mit den von dir genannten Fähigkeiten in den DPL zu stopfen.

    **
    Ich habe es mal auf 1 gestellt => DPL verändert => Bochs sagt mir DPL != CPL!
    **

    Wenn du den DPL veränderst, kein Wunder. Das D/B-Bit hast du jedenfalls dann nicht verändert 😉

    **
    Also ich denk nicht dass das der Fehler ist! Das G-Bit habe ich immernoch gesetzt!
    **

    Damit sind deine Segmente Gleich 4k mal so groß. Also das Limit liegt biem Codesegment so nicht mehr bei 0x9fff, sondern bei 0x09ffffff und da sist _ein bisschen_ mehr. Mach das G-Bit besser nur an, wenn du auch wirklich soviel Platz willst.

    **
    Wo benutze ich denn 16bit Code was ich nicht darf? 😕
    **

    Du deklarierst dein Codesegment als 32-Bit, hast aber 16-Bit-Code drin. Damit werden die Befehle anders aufgelöst und die CPU führt Dinge aus, die sie nicht soll. Mach das D/B-Bit aus 🙂

    Zum neuen Code: wie du siehst, sind DS/ES noch nicht umgestezt worden, also ist der Fehler shcon vorm schrieben in den VRAM passiert. Liegt vielelicht an falschen D/B-Bits 😉

    [ Dieser Beitrag wurde am 26.04.2003 um 00:25 Uhr von TriPhoenix editiert. ]

    0
  • S

    Oh ich hab mich in der Zeile vertan bei den Descs!! *GGG*
    Endlich funktionierts! Lag aber am D/B-BIT!

    *freu*

    I love you all *g*

    Bis in paar mins wenn wieder was net geht *spass*

    Kevin

    0
  • S

    Gehen tut noch alles 😉 ABER!
    Ich hab nochmal ne Frage zum 16 bzw. 32 bit Code! Wo liegt denn da der Unterschied? Kann mir da mal wer ein Beispiel geben? Nur die Adressen sind doch verschieden aber Dinge wie die Operanden bleiben doch gleich oder nicht?

    Kevin

    0
  • T

    Original erstellt von Surkevin:
    **Gehen tut noch alles 😉 ABER!
    Ich hab nochmal ne Frage zum 16 bzw. 32 bit Code! Wo liegt denn da der Unterschied? Kann mir da mal wer ein Beispiel geben? Nur die Adressen sind doch verschieden aber Dinge wie die Operanden bleiben doch gleich oder nicht?
    **

    Nein. Zum ersten benutzen alle Befehle, die im 16-Bit-Modus mit 16-Bit Operanden arbeiten jetzt 32-Bit. mov ax, 1 mov bx, 2 codiert als B8 01 00 BB 02 00 wird im 32-Bit-Modus z.B. gleich als mov eax, 0x02BB0001 interpretiert, weil ein doppelt so lanegr Operand erwartet wird. Dass damit dre zweite Befehl gelich angeschnitten ist und es so danach totalen murks geben wird, siehst du ja.
    Des weiteren ist der 32-Bit-Modus viel mächtiger was die Adressierung angeht. Im 16-Bit Modus kann man nur sachen machen wie:
    mov ax, [bx+si]
    mov ax, [bx+di]
    mov ax, [bp+si]
    mov ax, [bp+di]
    mov ax, [si]
    mov ax, [di]
    mov ax, [adresse]
    mov ax, [bx]

    optional kann man auf alle varianten was draufzählen. Im 32-Bit-Modus kann man erstmal über jedes beliebige Register Adressieren, des weiteren kann man die scale-index-base-adressierung benutzen. Die sieht so aus:
    mov eax, [base + scale * index + address]
    base kann dabei ein beliebiges register sein, index alles außer esp, scale darf 1, 2, 4 oder 8 sein und address eine weitere konstante. Du siehst also, die Befehl können im 32-Bit-Modus eine komplett andere Bedeutung plötzlich haben. Auch hier ein beispiel:
    mov ax, [si]
    mov ax, [si]
    siueht als Bytekette so aus: 8B 04 8B 04 wird im 32-Bit-Modus als
    mov eax, [ebx+4*ecx]
    interpretiert (8B 04 8B), wobei das letzte 04-Byte noch frei rumsteht.

    [ Dieser Beitrag wurde am 26.04.2003 um 12:01 Uhr von TriPhoenix editiert. ]

    0
  • N

    Na, nu mach mal net den 16Bit mode schlecht 😉
    Diese von dir erwaehnte "scale-index-base-adressierung" kann man auch in einem Codesegment mit 16Bit code verwenden.
    AFAIK ist (fast) der einzige Unterschied zw. einem CSegment mit 16Bit und 32Bit code der, dass die Bedeutung der Address/Opcode size prefixes (66h und 67h) vertauscht wird.
    => In 16Bit Kodierung ist "mov edx,[ebx+2*eax]" (66h=>32Bit Instruktion+67h=>32Bit Addresse) :
    db 67h,66h,8Bh,14h,43h
    Und im 32Bit demnach ohne die beiden Prefixes nur:
    db 8Bh,14h,43h

    Obiger 16Bit-code wuerde nach 32Bit-Kodierung jedoch folgende OpCodes ergeben:
    mov dx,[si] (Prefixe 67h,66h =>16Bit code+16Bit Addresse => 8Bh,14h)
    inc ebx (verbleibt 43h)

    Der 2. Unterschied zw. 16Bit/32Bit-Code ist AFAIR, dass in 32Bit code rep/loop- und String-Instruktionen mit 32Bit registern arbeiten... (in 16Bit code demnach nur mit 16Bit-Registern)

    [ Dieser Beitrag wurde am 26.04.2003 um 19:13 Uhr von Nobuo T editiert. ]

    0
  • T

    Original erstellt von Nobuo T:
    **Diese von dir erwaehnte "scale-index-base-adressierung" kann man auch in einem Codesegment mit 16Bit code verwenden.
    **

    Klar, dann muss man aber die Befehle umcodieren 🙂 Man kann ja auch 16-Bit-Adressierung im 32-Bit-Modus benutzen 🙂

    **
    Der 2. Unterschied zw. 16Bit/32Bit-Code ist AFAIR, dass in 32Bit code rep/loop- und String-Instruktionen mit 32Bit registern arbeiten... (in 16Bit code demnach nur mit 16Bit-Registern)
    **

    Ich würde mal (unbewiesen 🙂 )behaupten, dass man das ändern kann, indem man da ein Prefix vorschmeißt.

    0
Anmelden zum Antworten