Diskussion:Intel 80286

AMD 80286

Doof, daß in einem Artikel zum INTEL 80286 ein AMD 80286 abgebildet ist... (nicht signierter Beitrag von 195.145.215.1 (Diskussion) 11:30, 10. Mär 2006 (CET))

Das hat sich inzwischen ja erledigt... ‣Andreas•⚖ 14:21, 26. Aug. 2022 (CEST)

Stimmt das wirklich?

Auch musste in diesem Modus der Speicher nicht über die umständliche Segment-Adressierung angesprochen werden, bei der man nur 64 KiB auf einmal erreichen kann, sondern konnte praktisch den vollen Adressraum direkt ansprechen.

Meines Wissens konnte erst der 386 mehr als 64 KB am Stück ansprechen, denn der 286 hat ja nur die kurzen 16-Bit-Register. Wenn niemand protestiert und es besser weiß, möchte ich den zitierten Absatz dann lieber sobald wie möglich löschen. (nicht signierter Beitrag von Leider (Diskussion | Beiträge) 16:52, 31. Mai 2006 (CEST))

Doch, das stimmt. Der 80286 hatte schon den Protected Mode, den auch der 80386 hatte. Es gab ein paar Unterschiede, z.B. war es beim 80286 nicht moeglich den Protected Mode zu verlassen. Siehe den englischen Wikipedia Eintrag zu en:Protected mode: da ist erklaert dass die 32-Addressierung ueber einen Trick realisiert wurde obwohl die Register selbst 16-bittig waren. --DarkDust 18:00, 31. Mai 2006 (CEST)

Man konnte mit dem 286er durchaus den Protected Mode verlassen. Dazu musste man sich aber eines undokumentierten Befehls bedienen. Der Trick wird in folgendem Artikel beschrieben Real_Mode#Der_LOADALL-Trick. Bei Windows 3.x wurde dieser Trick verwendet um von Windows zu DOS zurückkehren zu können. Bei OS/2 war es genauso. --IT-Compiler (Diskussion) 16:40, 23. Aug. 2022 (CEST)

Nein, das stimmt so nicht ganz. Der 286er konnte zwar mehr als 64kb ansprechen, jedoch nicht an einem Stück. Ein normaler Befehl mit Addressierung konnte sich in einem Fenster von 64kb bewegen - um jedoch eine größere Adressdistanz zu überbücken, ist das Umsetzen der Segmentregister notwendig - und damit geht das direkt flöten. Dies war auch der Hauptgrund, warum der P-Mode des 80286 nicht wirklich brauchbar war - bzw. deutliche Vorteile gebracht hätte. Datenstrukturen waren damit auf 64kb begrenzt. Einige Compiler umgingen dies indem sie bei jedem Zugriff die Segmentregister setzten - das ging aber derart auf die Performance, so dass man darauf verzichtete. 80.129.213.225 10:17, 14. Sep. 2009 (CEST)

• 32-Adressierung? Dachte der 286er hat nur 24 Adressleitungen (24 Bit) also rechnerisch adressierbar sind 16 MB (wenn man das A20-Gate mal beiseite lässt). - Appaloosa 18:21, 31. Mai 2006 (CEST)

Das eine hat nicht unbedingt was mit dem anderen zu tun: der 8086 war ein reiner 16-bitter, der 8088 war auch 16-bittig hatte aber nur einen 8-bit breiten Datenbus. Beide hatten einen 20-bit breiten Addressbus (mir faellt da gerade auf dass die deutsche Wikipedia-Seite zum 8086 in diesem Punkt falsch ist). Das war auch der Grund fuer die Segment:Offset Adressierung als Trick um trotz 16-bit Registern den 20-bittigen Adressbus zu nutzen.

Speziell ist es aber im Protected Mode so dass die Adressierung virtuell ist: eine Adresse im Protected Mode muss nicht unbedingt auf eine echte Hardware-Speicheradresse matchen. Dadurch koennen heute moderne Betriebssysteme ihren Prozessen immer den selben Adressraum praesentieren, das Betriebssystem muss sich darum kuemmern dass an den entsprechenden virtuellen Adressen etwas ge-map-t wurde. Ist an der Adresse die angefordert wurde nichts ge-map-t dann gibt es eine Exception und das Betriebssystem (bzw. damals das entsprechende Programm) muss sich dann daran kuemmern dass dort was erscheint oder die Exception an das Programm weiterleiten (unter Linux ist das glaub ich der Segmentation Fault). So wird das mit den Swapdateien/partitionen erst moeglich. Ich hoffe ich habe das alles hier richtig erklaert :-) --DarkDust 16:31, 1. Jun 2006 (CEST)

Irgendwas stimmt da nicht

Irgendwie kommen mir die Zeilen im Absatz Memory-Extender und DOS-Extender ein wenig spanisch vor. War es nicht korrekt so, dass MS mit HIMEM.SYS nur die ersten 64KB über dem Hauptspeicher von 640KB addressiert hat und dieser Speicherbereich ausschließlich zum "Hochladen" von Systembestandteilen genutzt wurde (Beachte auch die Befehle in der Config.sys, wie loadhigh oder DOS=HIGH). Mit Extented Memory den Rest bis 1024KB und darüber hinaus der Speicher Expanted Memory genannt wurde, der erst mit Win 3.11 ansprechbar war?? Und damit erst wirklich der Protected Modus des 80286 "verstanden" wurde??? Ist es nicht so, dass dieser Modus erst wirklich möglich wurde, nachdem eine virtuelle Speicheradressierung, möglich war?? (Info zu meiner Person: mein erster Kontakt war ein Sinclair, danach Zenith-8086, 80286, 80386DX,AMD-386-40,80486DX33,P1-90...heute P4-2,6HT) (nicht signierter Beitrag von Jakker (Diskussion | Beiträge) 16:52, 07. Sep 2006 (CEST))

Der Hinweis auf die Monitorfarbe hatte ausschließlich informativen Karrakter!! (nicht signierter Beitrag von Jakker (Diskussion | Beiträge) 18:06, 07. Sep 2006 (CEST)) Im übrigen bin ich neu hier, habe keine Ahnung davon, wie hier diskutiert wird, wie man gegenseitig Kontakt aufnimmt etc.. Ich weiss nur, dass ich mein Wissen weiter geben möchte, solange ich lebe...... (nicht signierter Beitrag von Jakker (Diskussion | Beiträge) 18:18, 07. Sep 2006 (CEST))

Dies ist ein Artikel über den Prozessor 80286, der zufällig auch in IBM-Kompatiblen Rechnern verbaut wurde. Für diese Rechner existieren Artikel, folge den vorhandenen Links. Die Abteilung DOS-Extender ist tatsächlich in Teilen falsch, da muß mal was dran gemacht werden. In den Artikeln zu EMS und XMS ist es korrekter beschrieben, vielleicht liest Du dort und gleichst die Artikel gegeneinander ab. -- Smial 19:25, 7. Sep 2006 (CEST)

Die Aussage, dass der 80286 zufällig auch in IBM-Maschinen eingebaut wurde stimmt so nicht wirklich. Anfang der Achtziger waren IBM, Intel und Microsoft noch sehr aufeinnander angewiesen. Der Bau der Maschinen erfolgte sicher nicht komplett von IBM, waren aber zum Grossteil IBM bzw. Intel zertifizierte Maschinen, also in Linzenz gebaut (IBM-kompatibel). Im Übrigen war IBM bei der Entwicklung des 80286 massgeblich beteiligt; aus dieser Zusammenarbeit erfolgte nach und nach die Entwicklung bzw. Forcierung der RISC-Prozessoren, die über viele Jahre, wegen der hardwareseitigen Befehle, den CISC-Prozessoren überlegen waren. (nicht signierter Beitrag von Jakker (Diskussion | Beiträge) 20:26, 08. Sep 2006 (CEST))

Aua ;-) IBM-kompatible Rechner mussten weder von Intel noch von IBM zertifiziert werden. Das war ja auch genau der Grund, warum die Kompatiblen den Markt mehr oder weniger aufgrollt haben. IBM hat as AT-Design nie schützen lassen und konnte damit auch keine Lizenzen vergeben. Auch die Aussage, das RISC-Prozessoren den CISCs überlegen waren, stimmt so nicht ganz. RISC-Prozessoren haben einen höheren Befehlsdurchsatz - dafür aber weniger mächtige Befehle. Man brauchte für manche Operationen drei RISC-Instructions wo eine CISC-Instruction reichte. Wenn dann RISC dreimal schneller ist, ist nicht wirklich etwas gewonnen. RISC ist nicht per se überlegen, weil es RISC ist. 2003:CB:A3E8:8601:C1E7:3335:B7FD:BBBB 14:21, 5. Aug. 2018 (CEST)

Ergänzung zu obigem. RISC hat sogar einen Nachteil, der insbesondere damals, als der 80286 auf dem Markt kam, sehr relevant war. Man braucht mehr Befehle und somit deutlich mehr RAM für den Code. RAM war 1982 aber sündhaft teuer und knapp. Deswegen waren da die CISC CPUs deutlich im Vorteil, weil man mit einem größeren Befehlssatz viel mehr Auswahl an Befehlen hat und somit mit wenigen Befehlen ausdrücken kann, was man eigentlichen machen möchte. Und wenn man dann nur einen einzigen Befehl anstatt 3 Befehle benötigt, dann sparte das ein paar Bytes des kostbaren Arbeitsspeichers ein. Bei mehreren Operationen summiert sich das dann zu vielen KiB. RISC wurde erst später interessant, als RAM günstiger und größer wurde und man auch mehr RAM adressieren konnte. Als Acorn der Hersteller der ersten ARM CPU den Archimedes 1987 herausbrachte, wurde der bereits mit 512 KiB RAM ausgeliefert. Das ist im Vergleich zu den 16 KiB oder 64 KiB von damals als die CISC CPUs entwickelt wurden, viel Arbeitsspeicher und erlaubt somit natürlich auch längere Programme mit mehreren Befehlen. --IT-Compiler (Diskussion) 17:18, 23. Aug. 2022 (CEST)

Datum der Einführung des 80286 falsch!

Ich glaube der Prozessor wurde erst 1992 eingeführt und nicht schon 1982. (nicht signierter Beitrag von 217.31.65.229 (Diskussion) 08:52, 01. Feb 2007 (CET))

Ich würde sagen da liegst du Falsch. 1995 kam der Pentium. und dazwischen muss noch der 386 und der 486 -- HAL 9000 08:56, 1. Feb. 2007 (CET)

1982 stimmt. Habe das Einführungsjahr des 286 bisher in mehreren Büchern gelesen.

Siehe auch Bild:

• 

  (c)Intel '82

-Appaloosa 14:52, 1. Feb. 2007 (CET) Ganz sicher! Ich hatte 1982 bereis einen 286-AT mit einer 40MB Festplatte!! (nicht signierter Beitrag von 81.217.84.162 (Diskussion) 21:50, 4. Dez. 2012 (CET))

Logischer Adressraum 1GB!

Das sollte man noch erwähnen. Im Buch von Hans-Peter Messmer "PC-Hardware" habe ich in der 5. Auflage auf der Seite 57 gelesen. "Im Protected Mode,.....sind Segment und Offset vollständig entkoppelt. Die Segmentregister besitzen eine völlig andere Bedeutung......Dadurch ist beim 80286 ein logischer Adressraum von maximal 1 GB......möglich."

Diesen Fakt sollte man dem Artikel noch hinzu fügen. Das Buch ist im Addison-Wesley Verlag erschienen und hat die ISBN 3-8273-1302-3 (nicht signierter Beitrag von 85.178.41.125 (Diskussion | Beiträge) 00:57, 6. Mai 2009 (CEST))

Gehäuseformen

Im Artikel sind 286er im PGA- und PLCC-Gehäuse abgebildet. Außerdem gab es den 286er noch in einer Art Keramikgehäuse, von dem ich nicht weiß, wie es heißt. Das Gehäuse war aus Keramik, ungefähr quadratisch und pyramidenstumpfförmig. Der Chip und der zugehörige passive Kühlkörper wurden mit einer Metallklammer in der Fassung gehalten, ähnlich CLCC aber mit angefaster Seitenfläche. Weiß einer, wie das Gehäuse heißt und kann ein Foto auftreiben?--Rotkaeppchen68 00:48, 1. Feb. 2010 (CET)

Die Gehäuseversion die du meinst wird wohl ein CLCC-Gehäuse gewesen sein. Vielleicht findest du hier dein Gehäuse. - Appaloosa 02:09, 1. Feb. 2010 (CET)

Schlecht geschrieben, Artikel erklärt nicht das "wie?", sondern nur das "das".

Im Artikel heißt es:

• Der Protected Mode dagegen erlaubt es, über den 24 Bit breiten Adressbus bis zu 16 MiB zu adressieren. Die Beschränkung auf maximal 64 KiB große Segmente blieb jedoch auch in diesem Betriebsmodus bestehen – alle Adressregister waren nach wie vor nur 16 Bit breit. Allerdings konnte ein Segment auf eine nahezu beliebige Adresse im 24-Bit-Adressraum gelegt werden. Nur so erschloss sich für Programmcode der gesamte Adressraum. Durch die Speicherverwaltungsmöglichkeit des Protected Modes steht ein virtueller Speicher von knapp 1 GiB (16383 Segmente zu max. 64 KiB) zu Verfügung.

Damit wird dem Leser zwar klar, dass der Prozessor einen 24 Bit breiten Adressraum hat und somit 16 MiB adressieren kann und ein Segment immer noch nur 64 KiB groß ist, aber da ein Adressregister immer noch nur 16 Bit breit ist, erklärt das nicht das wie die 16 MiB nun genau adressiert werden.
Beim 8086 wird eine Adresse als Segment und Offset angegeben. Für die Wahl des Segments gibt es 4 Segmentregister (CS, DS, ES und SS), die jeweils 16 Bit breit sind, damit kann man sich das also so vorstellen, als würde bei einem linearen Speicherblock von 1024 KiB Größe ein 64 KiB Fenster in 2^16 Stufen, also 16 Byte großen Sprüngen entlang des 1024 MiB großen Speichers verschoben werden und mit dem Offset kann man ein bestimmtes Byte innerhalb dieses 64 KiB Fenster dann direkt ansprechen. Da sich die 2^16 möglichen 64 KiB Fenster überlappen, muss man natürlich nicht die ganze Zeit so ein Fenster verschieben, es genügt die Verwendung von normierten Segmentadressen, aber so detailliert wollte ich das jetzt auch nicht erklären, schließlich geht es hier um den 286er, wer es genau wissen will, kann das im Real Mode Artikel nachlesen.
Zurück zum 286er, wie der das nun macht, ist aus der oben zitieren Ausführung nicht klar. Es gibt kein 24 Bit breites Adressregister (00'00'00h bis FF'FF'FFh), das ist immer noch nur 16 Bit breit (00'00h bis FF'FFh) (Anmerkung: 2 Hexzeichen stehen für genau 8 Bit). Der entscheidende Satz:

• Allerdings konnte ein Segment auf eine nahezu beliebige Adresse im 24-Bit-Adressraum gelegt werden.

erklärt jedenfalls nicht das wie. Wie genau wurde ein Segment bzw. 64 KiB Fenster also auf eine nahezu beliebige Adresse im 24 Bit Adressraum gelegt? Mit dem klassischen Segment:Offset Schema des 8086 allein jedenfalls nicht, das reicht dafür nicht aus. Und der 286er ist immer noch ein reiner 16 Bit Prozessor, alle seine Register sind nur 16 Bit breit. Diese Frage, wie so ein Segment beim 286 auf eine nahezu beliebige Adresse des 24 Bit Adressraums gelegt wird, beantwortet der Artikel nicht, eine Beantwortung wäre hier aber zwingend erforderlich. --IT-Compiler (Diskussion) 16:24, 23. Aug. 2022 (CEST)

Siehe z.B. Segmentierung (Speicherverwaltung) und Protected Mode#16-Bit Protected Mode. ‣Andreas•⚖ 14:19, 26. Aug. 2022 (CEST)

Schon klar, dass es noch andere Artikel gibt. Trotzdem sollte man das in dem Artikel, wenn man das schon erwähnt, entweder erklären oder auf die anderen Artikel verweisen, in dem es dann erklärt wird. Den Segmentierungs Artikel habe ich übrigens schon gelesen, aber der reißt das bezüglich dem 286er nur kurz an. Den Protected Mode Artikel werde ich diesbezüglich nochmal lesen. --IT-Compiler (Diskussion) 15:29, 26. Aug. 2022 (CEST)

Ich sehe das grundsätzlich auch so, allerdings würde ich das nicht im Artikel zum Intel 80286 ausführlich erklären, sondern in den entsprechenden anderen (zu verlinkenden) Artikeln, denn auch andere Prozessoren (alle x86-CPUs nach dem 80286) unterstützen dieselbe Adressierungsmethode. ‣Andreas•⚖ 17:08, 26. Aug. 2022 (CEST)