Diskussion:Real Mode

Real-Modus

Ein bisschen Google-Suche spuckt "Real-Modus" als selten verwendete dt. version aus. Ich habe mal Real-Modus als redirect auf Real Mode eingerichtet. --Dschwen 09:08, 10. Mär 2006 (CET)

Kleines Assemble Makro um in den "Unreal Mode" rein zu kommen

Ich habe ein Kleines Assemble Makro geschrieben, womit man in den "Unreal Mode" rein kommt, intresiert es jemanden?

Und in welcher Form kann ich es hier einfügen?

Soll ich es in einer Webseite einfügen und eine externe verlinkung dahinführen oder gibt es eine Bessere Lösung? --INFNIC >=< 21:39, 16. Mär 2006 (CET)

Kommt drauf an, wie groß es ist. Ich denke, unter 10..15 Zeilen kann es hier rein, wenn es länger ist (z.B. weil es ausführlich kommentiert ist, was sicher sinnvoll wäre), wäre es bei Wikisource besser aufgehoben.

Nochwas: Hast du mit diesem Programm auch getestet, dass das Abschalten des 64-KiB-Limits im "Unreal Mode" nur mit FS und GS funktioniert, oder woher hast du diese Aussage? Ich war bisher davon ausgegangen, dass dies mit allen Segmentregistern funktioniert, denn ich sehe keine Gründe, warum FS und GS da eine Sonderbehandlung erfahren haben sollten. --RokerHRO 00:01, 17. Mär 2006 (CET)

Vor dem 386 waren die Register 16 Bit Breit und 16 Bit wurden zur Adressierung benutz, das wird in manschen Programmen benutzt um von der Adresse FFFFh nach 0000h zu kommen in dem mann 1 dazu addiert.

Aus Kompatibilitätsgründen werden auch bei den 32 Bit Prozessoren nur die ersten 16 Bit zur Adressierung genommen.

Da es die FS und GS Register damals noch nicht gab, ist das bei diesen beiden Registern nicht der fall.

Man kann also mithilfe der FS und GS Register bis zu 4 GB Adressieren, was naturlich auch bedeutet das man nur Daten und nicht Programmcode bis 4GB adressieren kann, da der Instruction Pointer (IP) nur mit dem CS Register benutzt werden kann.

Man kann also mit FS:ESI oder GS:EDI oder mit jeder anderen möglichen Kombination mit den FS und GS Registern 4GB adressieren.

Das Makro ist länger als 15 Zeilen, ich werde es warscheinlich bei Wikisource einfügen und hier ein Link, nach dort, einfügen.

--INFNIC >< 09:35, 17. Mär 2006 (CET)

Also so ohne Weiteres kommt man auch mit FS und GS im Realmode nicht jenseits die 1-MiB-Grenze, da auch diese Segmentregister per Default auf 64 KiByte große Segmente begrenzt sind. Man muss über einen Trick im Protected Mode die Segmentlängen auf 4GiB hochsetzen, und dann wieder in den Realmode zurückschalten. Meines Wissens klappt dies aber mit allen anderen Segmentregistern genauso wie mit FS und GS. Dieses Feature ist eigentlich ein "Bug" im 386er. Laut Intel-Doku muss man die Segmentlängen vor dem Zurückschalten in den Realmodus auf 64KiB setzen, damit sich der Prozessor hinterher wieder so verhält, wie im "echten" Real Modus. Es ist nicht dokumentiert, was passiert, wenn man die Segmente vor dem Wechsel in den Real Modus nicht wieder auf 64KiB begrenzt. Beim 286er ging das ganze eh nicht, da dieser A) keine Segmentlängen größer 64KiB setzen konnte, und B) ein Wechsel in den Realmode eh nur über einen Prozessor-Reset möglich war, der alle Segmentlängen wieder auf Defaultwerte zurückgesetzt hat. Siehe: http://www.intel.com/design/intarch/datashts/23163011.pdf --RokerHRO 11:55, 17. Mär 2006 (CET)

Du hast schon recht mit dem Wechsel in den PM und zurück, genau das macht mein Assemble Makro. Ich Programmier in assembler und habe es selber ausprobiert, du kanst zwar auch bei den anderen Segmenregister die Segmentlängen auf 4GiB hochsetzen aber wenn du mit hilfe der anderen Segmenregister eine adresse bildest, dann findet zwischen der adresse FFFFh und 10000h eine übertag auf den 17 Bit statt und nur die ersten 16 Bit werden bei den anderen Segmenregister zur Adressbildung herangezogen, ich habe es ausprobiert, wen du willst schicke ich dir das Assemble Makro und du kanst es selber ausprobieren.

Ich habe ein Buch in dem das genauer erklärt ist, sobald ich es gefunden habe schreibe ich eine genauere Erklärung.

--INFNIC >< 13:17, 17. Mär 2006 (CET)

Ich habe das Macro vorlaufig unter Benutzer:INFNIC/Makro um FS und GS auf 4 GB zu erhöhen eingefügt. Unter der Adresse [1] habe ich ein ähnliches Macro von jemand anderem gefunden.

Ich habe das Buch gefunden, es war im Keller. Eine Effektive Adresse größer als 655535 wird im Realmodus durch einen Interrupt 13 geahndet (auser bei FS und GS). Das ist der Grund warum es im Zusammenhang mit dem DS und ES Register im Realmodus und unter DOS nicht möglich ist.

--INFNIC >< 15:50, 17. Mär 2006 (CET)

Fortsetzung

Naja, laut obiger Intel-Doku sollten bei allen Segmentregistern Offsets größer 65535 im Realmode abgefangen werden. Dass man das umgehen kann, war von Intel nicht geplant (zumindest nicht dokumentiert). Dieses Limit ist aber nicht hartkodiert, sondern kommt einfach von den Segmentlimits, die in den "Schattenregistern" der Segmentregister auch im Realmode wirksam sind, nur halt im Realmode nicht geändert werden können. Im Protected Mode kann man sie aber für alle Segmente "aufbohren" und dies bleibt - fehlerhafterweise - auch nach dem Zurückschalten in den Realmode erhalten. Folgendes Beispiel bohrt jedenfalls das DS-Segment auf, so dass es auf 8MB Speicher zugreifen kann: [2] --RokerHRO 17:21, 17. Mär 2006 (CET)

Was ist in diesem zusammenhang ein Schattenregister? Gibt es dafür vielleicht einen Anglizismus, der besser bekannt ist als das deutsche Wort? Wenn ja, dann sollte man diesen verwenden. -MrBurns 16:02, 20. Jun. 2007 (CEST)

Im Englischen (und der Intel-Originaldoku) heißen sie "shadow register". Ich glaube nicht, dass die engl. Bezeichnung im deutschen Sprachraum bekannter ist.

Mit Schattenregistern meint man in der CPU gecachte Kopien der Werte für Segmentbasisadresse, Segmentlänge (Segmentlimit) und Segment-Attribute (lesbar, schreibbar, ausfürbar u.a.). Dir Originalwerte stehen in den Segmentdeskriptortabellen, also im Hauptspeicher. Damit die CPU nicht bei jedem Speicherzugriff diese Werte mühsam aus dem Hauptspeicher holen muss, werden sie für alle 6 Segmentregister (CS, DS, SS, ES, FS, GS) in der CPU in den so genannten Schattenregistern gecacht. Diese heißen Schattenregister, weil sie softwareseitig nicht direkt sichtbar sind, nur die 16-bit Segmentregister können gelesen/geschrieben werden. Beim Laden eines neuen 16-bit-Wertes in ein Segmentregister lädt die CPU selbstständig passenden Werte in die Schattenregister. Im Protected Mode holt sie sich die Werte eben aus den Deskriptortabellen, darum dauert das Laden eines Segmentregisters recht lange. Im Real Mode berechnet die CPU die Segmentbasisadresse aus der Segmentnummer, die übrigen Schattenregister bekommen Real-Mode-kompatible Defaultwerte.

Ich hoffe, nun ist der Vorgang klarer. Ich überlege nur noch, ob und wie man das in den Artikel einbauen könnte. --RokerHRO 20:38, 20. Jun. 2007 (CEST)

Auf dieser Seite [3] steht, dass Intel das Verhalten der Segmentregister insbesondere beim CodeSegment mehrmals geändert hat, letzten Endes die Prozessoren aber so gebaut hat, dass dort auch die Segmentlimits auf 4GiB gesetzt werden können. Das bringt natürlich nicht viel, da der IP weiterhin nur 16 Bit groß ist im Real Mode. Aber man kann ja mit CS:-Präfix auch Daten im Codesegment adressieren. --RokerHRO 17:27, 17. Mär 2006 (CET)

Es ist nicht empfehlenswert das Segmentlimit vom CS & SS bei Rückkehr in den RM auf einem anderen

Wert als 0x0000FFFF zu belassen. Bei den Datensegementen macht das nichts aus mit anderen Werten die oberhalb von 0x0000FFFF in RM zurückzukehren. Das ganze ist eine auf allen CPUs laufende undokumentierte Funktion (wobei es angeblich schon ein Dokument geben soll.....nur bekommt man das nur mit einer NDA)

Nicht empfehlenswert? Nunja, es ist - je nach Sichtweise - ein Bug oder ein undokumentiertes Feature der meisten 386er CPUs und ihrer Nachfolger. Dass dieser "Trick" auf den meisten CPUs funktioniert, ist eben keine Garantie, dass das auf allen CPUs und zukünftig so bleibt, das haben undokumentierte Features so an sich. Das steht aber auch im Artikel. --RokerHRO 11:39, 30. Mai 2007 (CEST)

LOADALL

"Mit Hilfe des Befehles LOADALL werden bei 80386-CPUs die gewünschten Werte in die Segmentdeskriptorcaches geladen, so dass selbst mit 16-Bit-Segmentregistern bis zu 4 GiB Hauptspeicher adressierbar sind. Hierfür muss der Prozessor jedoch in den Protected Mode geschaltet werden,..."

Was ist den das für ein Müll? Der LOADALL befehlt lauft meines wissens nach im Realmodus, der Befehl war doch daffür da, damit die Intelentwickler beim entwickeln der CPU für test auch im Realmodus den ganzen speicher adressieren konten, dewegen ist der Befehl auch nicht dokumentier und nur im 286 vorhanden. Nur in CPUs ohne den LOADALL muss man in den PM oder eine emulation des LOADALL Befehles nutzen um die Register für den RM auf 4G zu erweitern --INFNIC >< 09:03, 19. Mär. 2007 (CET)

Ich hab das mal korigiert und in richtiger Form niedergeschrieben, vobei ich die vermischung vom LOADALL Befehl mit dem Trich in den PM zu schalten um die Register auf 4GB zu erhöhen und anschliesen in den RM zurückschalten nicht gut finde...--INFNIC >< 09:21, 19. Mär. 2007 (CET)

"Alternativ wurden DOS-Extender genutzt, welche die Verwendung des Real-Mode-Betriebssystems MS-DOS durch Protected-Mode-Programme erlaubten, indem sie jeweils bei Bedarf zwischen den beiden Modi umschalteten." Was hat dieser Satz mit dem Unreal Mode zu tun? der gehört da eigentlich nicht rein... INFNIC >< 09:37, 19. Mär. 2007 (CET)

So ich hab jetz mal so wie es sich gehört LOADALL, PM Trick und DOS-Extender getrent. --INFNIC >< 10:02, 19. Mär. 2007 (CET)

LOADALL funktioniert auch im PM auf Privileg Level 0. Gilt auch für LOADALLD.

Details zu den beiden undokumentierten LOADALL-Befehlen

Sollen hier weitere Details dazu eingefügt werden, oder wäre dafür ein anderer oder sogar ein eigener Artikel besser angebracht? Was denkt ihr? Als brauchbare Quellen habe ich auf die Schnelle das hier und den englischen Wikipediaartikel gefunden. -RokerHRO 12:04, 30. Mai 2007 (CEST)

80286

Bei diesem Prozessor macht es keinen Sinn, da im RM die Segmentbasis immer Selektor*0x010 ist und ein Segment max 64k groß sein kann. Wieso wird diese CPU überhaupt beim "Unreal" erwähnt?!

Nein, auch im Real Mode werden die so genannten "Schattenregister" benutzt, um die linearen Adressen zu bekommen, das ist "hartverdrahtet". Bei einem Schreibzugriff auf die sichtbaren 16-bit-Segmentregister werden halt die Schattenregister im Real Mode automatisch mit Segmentbasis = Segmentnummer * 16, Segmentlimit = 65535 geladen, damit sich die CPU wie ein 8086 verhält. --RokerHRO 11:43, 30. Mai 2007 (CEST)

Überarbeitung notwendig

In diesem Artikel soll es um den Real Mode gehen und über den gibt es weit mehr zu sagen als das was hier steht. Anstatt dessen finde ich hier die Hälfte des Artikels damit gefüllt was der Unreal Mode ist und wie man diesen erreichen kann. Dies ist in diesem Artikel fehl am Platz. Bitte beim Thema bleiben - der Unreal Mode hat in diesem Artikel außer einer Erwähnung und einen entsprechenden Verweis auf einen Artikel über den Unreal Mode hier nichts verloren! Dies ist eine Wikipedia und keine Programmieranleitung! PF20080207 (nicht signierter Beitrag von 193.109.238.110 (Diskussion) )

Der Abschnitt über den "Unreal Mode" ist deswegen so umfangreich geworden, weil das, was vorher dort stand, schlicht falsch war und somit nach und nach erweitert wurde, bis es eben den jetzigen Umfang bekommen hat. Viel mehr gibts über diesen Unreal Mode nicht zu schreiben, daher bezweifle ich, ob es für einen eigenen Artikel reicht.

Aber was konkret vermisst du denn über den "echten" Real Mode im Artikel? Kannst du relevante Fakten nennen, die du im Artikel vermisst, dann kann ich sie gerne einbauen. --RokerHRO 12:10, 7. Feb. 2008 (CET)

Der Unreal Mode mode ist im Grunde genommen kein eigener Modus, er ist eigentlich nichts anderes als der Real Modus mit bestimmten einstellungen in den Schattenregistern, von da her ist der Unreal Mode hier gut aufgehoben. INFNIC >< 15:22, 21. Apr. 2008 (CEST)--

Von da her werde ich den Baustein "Dieser Artikel beschäftigt sich fast zur Hälfte mit dem "Unreal Mode"..." entfernen. INFNIC >< 15:23, 21. Apr. 2008 (CEST)--

ÜA?

"Durch einen speziellen Maschinenbefehl kann man den Prozessor in den Protected Mode versetzen." -> Das hört sich lustig an. Als bräuchte man Magie um umzuschalten. In Wirklichkeit ist das eigentliche schalten den PM ein simples setzen des ersten Bits des CR0-Registers:

or cr0, 00000000000000000000000000000001b                     ; erstes Bit des CR0-Registers setzen
                                                              ; (die vielen Nullen hätte man sich auch sparen können)

Da der or-Befehl aber mit cr0 nicht arbeitet (glaub ich) muss man erst einen Umweg über ein Allzweckregister (oder den Stack?) machen. Aber das ist kein "spezieller Maschinenbefehl": Den gibt es nicht.

Magie braucht man nicht, aber eben einen speziellen MOV-Befehl, um das CR0-Register zu beschreiben. Dieser besitzt einen anderen ("speziellen") Opcode als die üblichen General-Purpose-Register- und RAM-MOV-Befehle. --RokerHRO 13:59, 4. Mai 2008 (CEST)

Ja... Schon klar. Vielleicht kann man Maschinenbefehl ja durch MOV-Befehl ersetzen. --62.180.145.147 14:25, 5. Mai 2008 (CEST)

Also störst du dich eher an dem Wort "Maschinenbefehl" als an "speziell"? --RokerHRO 15:22, 5. Mai 2008 (CEST)

Ja. MOV-Befehl ist, denke ich, genauer. Denn der Leser könnte dann ja auch denken es wäre vielleicht eine Art "SPM"-Befehl (Switch to Protected Mode) (also richtig als eigenen Mnemonic u. Opcode). --62.180.144.34 17:43, 7. Mai 2008 (CEST)

Dann ändere es halt. :-) --RokerHRO 23:48, 7. Mai 2008 (CEST)

MS-DOS 8-Bootdisketten mit NT

Der Satz Es gibt allerdings noch den Ausweg, eine MS-DOS 8 Bootdiskette in Windows NT (sic!) zu erstellen, sie mit den nötigen Treibern zu bestücken und von ihr aus das gewünschte Programm auszuführen. kann nicht stimmen. Da kann man noch 10x sic! hintereinanderhängen. Mit Windows NT 4 kann man sicher keine MS-DOS-8-Bootdiskette erstellen lassen (oder überhaupt DOS-Bootdisketten); denn NT 4 erschien 1996, also vor MS-DOS 8. Mit XP aufwärts (bei 2000 bin ich unsicher) lassen sich Bootdisketten erstellen. Die haben ja den NT-Kernel, aber unter "Windows NT" versteht man, wenn man sich nicht explizit auf den Kernel beruft, NT 4 oder ältere. Auf der anderen Seite ist der Vorschlag nicht ganz alltagstauglich. Wie will man auf eine HD zugreifen, falls die nicht zufälligerweise in FAT formatiert ist (die meisten Software, die den Extender benötigen, passen nicht auf eine Diskette)? --Filzstift ✑ 11:33, 17. Jan. 2011 (CET)

Unechter Realmodus (Unreal Mode) vs. LOADALL und CPU Reset

Auch wenn der unechte Realmodus von LOADALL oder dem CPU Reset Gebrauch macht, so gehört LOADALL und CPU Reset in einen eigenen separaten Abschnitt, der aufzeigt, wie man beim 286 vom Protected Mode zurück in den Real Mode kommt. Denn der LOADALL Trick wird bspw. auch von Windows 3.1 verwendet und das läuft definitiv nicht im Unreal Mode, sondern nutzt den Protected Mode des 286. Genaugenommen gehört diese Erklärung zum Zurückschalten des 286 in den Real Mode in den Protected Mode Artikel und da steht momentan dazu noch gar nichts. --93.229.166.99 18:39, 3. Jul. 2024 (CEST)