1982 erblickte er die Welt und ist somit dieses Jahr 40 Jahre alt
geworden.
Der Intel 80286 Prozessor.
https://de.wikipedia.org/wiki/Intel_80286https://en.wikipedia.org/wiki/Intel_80286
Er war der erste 16 Bit Prozessor für den PC mit Protected Mode und
somit der Möglichkeit mehr als 1 MiB RAM anzusprechen. Bis zu 16 MiB
waren möglich.
Leider nutzte er noch segmentierten Hauptspeicher und kein Paging und
dem IBM AT verpasste IBM das A20 Gate und vergaß eine Abfragemöglichkeit
einzubauen ob es aktiv war.
Außerdem war seitens Intel nicht vorgesehen ihn vom Protected Mode zum
Real Mode zurückzuschalten, eine Lösung fanden Programmierer dann mit
dem Loadall Befehl dann dennoch.
https://de.wikipedia.org/wiki/Real_Mode#Der_LOADALL-Trick
Auf der Seite von DOS führte er zur Entwicklung zu Memory Extendern und
XMS Speicher mit dem man dann den Speicher oberhalb der 1 MiB unter DOS
standardisiert nutzen konnte.
Mit EMS war das natürlich möglich, funktionierte aber anders.
Und später kamen dann DOS Extender wie VCPI und DPMI dazu, mit denen
dann dafür geschriebene Anwendungen selbst im Protected Mode liefen.
Anfang Ende der 80 führte er zu günstigen bezahlbaren PCs mit mehr
Leistung als ein 8086 und für den ein oder anderen war es der erste PC,
ja vielleicht sogar Computer überhaupt.
Für mich z.B. war es der erste echte Computer auf dem ich beliebige
Software starten konnte.
Da ein Thread ohne Frage aber nicht viel Sinn macht kommen wir gleich
noch zur großen Geburtstagsfrage dieses Prozessors:
War der Intel 80286 rückblickend ein guter Wurf oder, wie es Bill Gates
nannte, ein "hirnloser Chip"?
Nano schrieb:> War der Intel 80286 rückblickend ein guter Wurf oder, wie es Bill Gates> nannte, ein "hirnloser Chip"?
Das Zitat würde ich eher auf den 8088 beziehen. Als der "Personal-
computer" von IBM auf den Markt kam, war die Fachwelt eher enttäuscht.
Damals waren die Chips der Konkurrenz deutlich besser.
Nano schrieb:> Der Intel 80286 Prozessor.> Er war der erste 16 Bit Prozessor für den PC mit Protected Mode und> somit der Möglichkeit mehr als 1 MiB RAM anzusprechen.
IMHO klingt das nach ungerechtfertigter Lobhudelei, weil bereits 1980
der Motorola 68000 vertrieben wurde, der auch in Computern und
Workstations eingesetzt wurde und auch auch über ein 1 MB RAM
addressieren konnte.
Der 80286 dominierte den Markt für (dumme) IBM-PC's, während der ältere
aber leistungsfähigere 68000 in Unix-workstations und GUI-fähigen
Desktoprechnern (Apple Lisa, Apple Macintosh, Commodore Amiga, Atari ST)
verbreitet war.
SCNR
Nano schrieb:> War der Intel 80286 rückblickend ein guter Wurf oder, wie es Bill Gates> nannte, ein "hirnloser Chip"?
Im Vergleich mit dem ungefähr zur selben Zeit reusgekommenen MC68010
möchte ich Herrn Gates ausnahmsweise zustimmen.
my2ct
(re)
Nano schrieb:> Leider nutzte er noch segmentierten Hauptspeicher und kein Paging
Einspruch. Segmente sind wesentlich besser als pages als Speicherschutz,
und Gates zum Aufruf höherer Systemebenen perfekt. Man erinnere sich,
dass eine DLL auf 286 einfach 1 mal den code geladen hat und für jede
Verwendung (Instanz) 1 Datensegment bekam. Auf paging-Architekturen wie
68000 und Pentium muss das codesegment umgeschrieben/beim Laden gepatcht
werden, und jede DLL instanz dupliziert den code und macht die
segmente/pages dirty. Damit unterschiedlich lange Segmente nicht ein
Problem mit Fragmentation des physischen Hauptspeichers haben, müssen
dahinter aber pages sein, das hat Intel dann bei 386 realisieren können.
Sehr genial an Segmenten ist, dann ein 16 bit Programm ein 32 bit
Programm bzw. DLL aufrufen kann, weil der Prozessor pro Segment wissen
kann, was drin ist. Das wurde bei Win32 aber wegen dem blöden Cutler der
nur seine DEC Alpha kannte nicht umgesetzt, so bekamen wir zu 16 bit
inkompatible 32 bit und nun 64 bit Umgebungen statt einer smoothen
Vergrösserung die man nur eingesetzt hätte wenn benötigt.
Nano schrieb:> Außerdem war seitens Intel nicht vorgesehen ihn vom Protected Mode zum> Real Mode zurückzuschalten
Wäre ja wenig protected gewesen wenn man das konnte. Aber irgendwas ist
immer. So haben sie auch das dirty bit für Segmente vergessen, und damit
virtuelle Speicherverwaltung ausgebremst.
Nano schrieb:> War der Intel 80286 rückblickend ein guter Wurf
Er war eine dermassen geglückte Erweiterung des 8086, dass man annehmen
musste, die 8086 Entwickler hatten den 286 schon im Kopf, nur darauf
wartend bis genügend Transistoren auf einen Chip passten, und selbst zum
386 einen Plan.
Hatten sie.
Der 286 ist eine monolithische Burroughs B5500, die gab es vor dem 8086,
man konnte also gucken was man mit wenig Transistoren hin bekam und mit
vielen dann draus machen konnte.
Fpgakuechle K. schrieb:> Nano schrieb:>>> Der Intel 80286 Prozessor.>>> Er war der erste 16 Bit Prozessor für den PC mit Protected Mode und>> somit der Möglichkeit mehr als 1 MiB RAM anzusprechen.>> IMHO klingt das nach ungerechtfertigter Lobhudelei, weil bereits 1980> der Motorola 68000 vertrieben wurde, der auch in Computern und> Workstations eingesetzt wurde und auch auch über ein 1 MB RAM> addressieren konnte.
Du solltest richtig lesen.
Der erste Prozessor mit Protected Mode für den PC.
Der Motorola 68k wurde nicht in PCs verbaut.
>> Der 80286 dominierte den Markt für (dumme) IBM-PC's, während der ältere> aber leistungsfähigere 68000 in Unix-workstations und GUI-fähigen> Desktoprechnern (Apple Lisa, Apple Macintosh, Commodore Amiga, Atari ST)> verbreitet war.
Lisa war viel zu teuer, da macht ein Vergleich überhaupt keinen Sinn.
Der 80268 wurde zusammen mit Xenix, einem Unix Betriebssystem, damals
aber bereits für Datenbankserver eingesetzt.
MaWin schrieb:> Nano schrieb:>> Leider nutzte er noch segmentierten Hauptspeicher und kein Paging>> Einspruch. Segmente sind wesentlich besser als pages als Speicherschutz,> und Gates zum Aufruf höherer Systemebenen perfekt. Man erinnere sich,> dass eine DLL auf 286 einfach 1 mal den code geladen hat und für jede> Verwendung (Instanz) 1 Datensegment bekam. Auf paging-Architekturen wie> 68000 und Pentium muss das codesegment umgeschrieben/beim Laden gepatcht> werden, und jede DLL instanz dupliziert den code und macht die> segmente/pages dirty. Damit unterschiedlich lange Segmente nicht ein> Problem mit Fragmentation des physischen Hauptspeichers haben, müssen> dahinter aber pages sein, das hat Intel dann bei 386 realisieren können.> Sehr genial an Segmenten ist, dann ein 16 bit Programm ein 32 bit> Programm bzw. DLL aufrufen kann, weil der Prozessor pro Segment wissen> kann, was drin ist.
Hm, okay. Der Speicherschutz mag besser sein.
Aber programmiertechnisch sind Pages und ein linearer Speicher meiner
Meinung nach klar im Vorteil.
> Nano schrieb:>> Außerdem war seitens Intel nicht vorgesehen ihn vom Protected Mode zum>> Real Mode zurückzuschalten>> Wäre ja wenig protected gewesen wenn man das konnte.
Der 386 hatte daher Ring 0 bis 3. In den Realmode zurückwechseln konnten
somit nur Programme, die im Ring 0 liefen. Also bei modernen
Betriebssystemen das OS.
Nano schrieb:> Der erste Prozessor mit Protected Mode für den PC.
'Protected Mode' - muss man nicht kennen.
> Der Motorola 68k wurde nicht in PCs verbaut.
Doch wurde er, allerdings eben nicht in IBM-PC resp Clones sondern in
Commodore, Apple, Atari PC's. PC heisst einfach nur "Persönlicher
Computer" also Single-User System in Abgrenzung zum zwischen
verschieenen Usern gesharden Mainframe. Es soll ja auch mal CPM-PC#s mit
Z80 gegeben haben.
> Der 80268 wurde zusammen mit Xenix, einem Unix Betriebssystem, damals> aber bereits für Datenbankserver eingesetzt.
Das Entscheidende für nen Server ist/war aber die Festplatte und nicht
die CPU. Deshalb wurde Unix auch eher für den AT entwickelt, der in der
Grundkonfiguration bereits eine HD mitbrachte (im Unterschied zum
Vor-VorgängerIBM-PC). Das lange Fehlen einer HD in der Grundausstattung
war dann auch m.E. der Grund für das Ausscheiden v. Atari ST und
Commodore Amiga aus dem PC Markt. Man musste mal recherchieren ob die
Commodore Unix-Maschine, der Amiga 3000UX, auch standardmäßig mit HD
geliefert wurde.
Fpgakuechle K. schrieb:> Nano schrieb:>>> Der erste Prozessor mit Protected Mode für den PC.> 'Protected Mode' - muss man nicht kennen.>>> Der Motorola 68k wurde nicht in PCs verbaut.> Doch wurde er, allerdings eben nicht in IBM-PC resp Clones sondern in> Commodore, Apple, Atari PC's. PC heisst einfach nur "Persönlicher> Computer" also Single-User System in Abgrenzung zum zwischen> verschieenen Usern gesharden Mainframe.
Das ist Haarspalterrei Jeder weiß, dass die Rechner von Commodore und
Atari Homecomputer waren und mit dem PC der IBM PC und kompatible
gemeint ist.
PC würde ich allerhöchstens noch für den Apple 2 in seiner Blütezeit
gelten lassen.
>> Der 80268 wurde zusammen mit Xenix, einem Unix Betriebssystem, damals>> aber bereits für Datenbankserver eingesetzt.> Das Entscheidende für nen Server ist/war aber die Festplatte und nicht> die CPU.
Das entscheidende war der Preis.
Und der 80286 + Xenix ermöglichte es erstmals, dass auch mittelgroße
Unternehmen sich brauchbare Server + die dafür passende Software leisten
konnten.
Und Commodore und Atari hatten da nichts vergleichbares im Angebot.
> Deshalb wurde Unix auch eher für den AT entwickelt, der in der> Grundkonfiguration bereits eine HD mitbrachte (im Unterschied zum> Vor-VorgängerIBM-PC).
Wenn der Zugriff auf die Daten schnell gehen sollte brauchte man auch
viel RAM und das war mit dem 80286 möglich, wenn man sich den RAM
leisten konnte.
Letzteres war für Firmen durchaus bezahlbar.
> Das lange Fehlen einer HD in der Grundausstattung> war dann auch m.E. der Grund für das Ausscheiden v. Atari ST und> Commodore Amiga aus dem PC Markt.
Festplatten konnte man nachrüsten. Dem Amiga und Atari ST fehlte aber
bereits die Serversoftware die es für den PC schon in vielfältigen
Angeboten damals gab.
Nano schrieb:> Das ist Haarspalterrei Jeder weiß, dass die Rechner von Commodore und> Atari Homecomputer waren
Jeder weiss, dass gerade Du ein nervtötender Haarspalter bist. Dann
kannst Du Dich auch selbst klar ausdrücken, statt vage Begriffe wie "PC"
zu verwenden.
Und dass diese "Homecomputer" - insbesondere Mega ST(E) und später der
TT030 - im Musik- und DTP-Bereich verbreitet waren, ist Dir offenbar
auch entgangen.
Sogar auf dem C64C stand übrigens "Personal Computer".
Hmmm schrieb:> Nano schrieb:>> Das ist Haarspalterrei Jeder weiß, dass die Rechner von Commodore und>> Atari Homecomputer waren>> Jeder weiss, dass gerade Du ein nervtötender Haarspalter bist. Dann> kannst Du Dich auch selbst klar ausdrücken, statt vage Begriffe wie "PC"> zu verwenden.
Aus dem Kontext ging klar hervor, was mit PC gemeint ist.
Das sieht man übrigens auch schon an dem Wort den, da ich "den PC"
sagte:
Nano schrieb:> Der erste Prozessor mit Protected Mode für den PC.> Der Motorola 68k wurde nicht in PCs verbaut.
Daraus ist klar erkennbar, dass nicht irgendwelche PCs gemeint sind,
sondern der Kontext bezieht sich klar auf den IBM kompatiblen PC.
Nano schrieb:> Das ist Haarspalterrei Jeder weiß, dass die Rechner von Commodore und> Atari Homecomputer waren und mit dem PC der IBM PC und kompatible> gemeint ist.
Das mit dem Haar im Spalt ist deine ganz persönliche Meinung, andere
Personen und auch die Fachliteratur benutzt eine andere Definition und
nach der gibt es sehr wohl PC's auch von Commodore, atari, Apple, ....
> Und der 80286 + Xenix ermöglichte es erstmals, dass auch mittelgroße> Unternehmen sich brauchbare Server + die dafür passende Software leisten> konnten.
Kommt auf Branche an, DTP und der ganze zeitschriftenbetrieb haben lange
Zeit auf Atari/Apple gesetzt (Calamus/QuarkXpress)
> Und Commodore und Atari hatten da nichts vergleichbares im Angebot.
Die hatten besseres, bspw NewTek Genlock für Videotitel und Blueboxing.
Etliche SF-Serien wurden damals auf Amiga gerendert, bspw. 'Babylon 5'
oder 'Space 2063'. Die Anwendung hängt eben nicht nur vom Prozessor ab,
sondern vom gesamten Systemdesign. Und das von IBM hat bei den
Mitbewerbern mehr Spott als Anerkennung erzeugt:
https://heise.cloudimg.io/bound/500x500/q60.png-lossy-60.webp-lossy-60.foil1/_www-heise-de_/select/mac-and-i/2017/1/1486649326965191/tn_image-1485421255279013.jpg> Wenn der Zugriff auf die Daten schnell gehen sollte brauchte man auch> viel RAM und das war mit dem 80286 möglich, wenn man sich den RAM> leisten konnte.
Kann der 68000 auch, sogar ohne die Segmenregisterverrenkungungen des
i286.
> Letzteres war für Firmen durchaus bezahlbar.
Wie 68000 SUN-workstations auch,... oderden Amiga Commodore Tower
> Dem Amiga und Atari ST fehlte aber> bereits die Serversoftware die es für den PC schon in vielfältigen> Angeboten damals gab.
Serverfunktion ist ja auch eher was für workstations und nicht für PC's.
Erst mit den i386 architektur und Linux wurde die IBM-PC Architektur
richtig servertauglich, vorher war das die Domäne der workstations (Sun,
hp -apollo, NeXT Cube, ...). Wobei man diese workstations auch gut als
individuellen Rechner nutzen konnte, bspw. für EDA. Dazu brauchte der
IBM-AT noch bis zur Jahrtausendwende. Und auch für den Commodore Amiga
gab es Unixserver. Und die ganzen Mailboxnetzte wie FidoNet oder mausnet
ware letzlich auch nichts anderes als Serverbasierte Datenbanken.
--
Also die Hauptanwendung für den 286-AT war nun mal Textprocessing
vielleicht noch lokale Datenbanken. Für alles andere ist die 68k
Architektur und DSP-Architekturen besser geeignet. Der 286 ist somit als
'Krone der monochromen Textverarbeitung' eher eine Episode als ein
Meilenstein der Conputergeschichte (das wäre dann erst der 386).
Aber jedem steht frei seine eigene 'Jugendsünde' zu vergöttern. Oder
gleich auf alles Digitale zu sch**sen und sich auf die Rolle eines
'Analog-Gottes' festzulegen ;-)
https://pbs.twimg.com/media/EO-koTUWkAA6TB8?format=jpg&name=large
Nano schrieb:> War der Intel 80286 rückblickend ein guter Wurf oder, wie es Bill Gates> nannte, ein "hirnloser Chip"?
Ich finde ehrlich gesagt, dass eher DOS ein hirnloses Betriebssystem
war, denn es hat die Vorteile des 286er überhaupt nicht richtig
ausgenutzt. Und das ging beim 386er und 486er konsequent so weiter. XMS
und EMS, um den Speicher über 1 MB wenigstens nicht komplett brach
liegen zu lassen, waren nur schlechte Krücken. Und als work-around gab
es dann noch die DOS-Extender.
>> Jeder weiss, dass gerade Du ein nervtötender Haarspalter bist. Dann>> kannst Du Dich auch selbst klar ausdrücken, statt vage Begriffe wie "PC">> zu verwenden.>> Aus dem Kontext ging klar hervor, was mit PC gemeint ist.
Nein, ging es nicht, weil du dir nicht die Zeit genommen hast die drei
Buchstaben IBM (oder H++A++L++ ;-) )davor zu setzen ...
Soviel Zeit muss sein !
Rolf M. schrieb:> Ich finde ehrlich gesagt, dass eher DOS ein hirnloses Betriebssystem> war, denn es hat die Vorteile des 286er überhaupt nicht richtig> ausgenutzt.
Ja war ja auch älter, aber Windows passte perfekt auf den 286.
Nano schrieb:> Aber programmiertechnisch sind Pages und ein linearer Speicher meiner> Meinung nach klar im Vorteil.
Klar nein.
Alleine der Krampf mit Stack (von oben) und Heap (von unten) um
denselben Speicher für 2 Zwecke zu nutzen. Wie elegant ist da ein
Stacksegment und Datensegment.
Kein Problem wenn der Stack wächst.
Erst recht bei Unterprogrammaufrufen und Ringwechseln. Viel Krampf bei
aktuellen vonNeumann Maschinen wurde damit entzerrt, mehrere
Datensegmente zum selben Codesegment bei DLL hatte ich schon erwähnt.
Auch Apple nutzte auf dem 68000 für MacOS das Prinzip der Segmente,
durch reservierte Register als Datensegmentpointer, ich glaube AmigaOS
auch, nur halt ohne Hardwareunterstützung.
Fpgakuechle K. schrieb:> Nano schrieb:>> Und der 80286 + Xenix ermöglichte es erstmals, dass auch mittelgroße>> Unternehmen sich brauchbare Server + die dafür passende Software leisten>> konnten.>> Kommt auf Branche an, DTP und der ganze zeitschriftenbetrieb haben lange> Zeit auf Atari/Apple gesetzt (Calamus/QuarkXpress)
Ich sprach von Serversoftware. Datenbanken, Fileserver usw. was man
früher halt bereits in Firmen brauchte.
Ich sprach nicht von Grafiksoftware auf Clientgeräten.
> Serverfunktion ist ja auch eher was für workstations und nicht für PC's.> Erst mit den i386 architektur und Linux wurde die IBM-PC Architektur> richtig servertauglich, vorher war das die Domäne der workstations (Sun,> hp -apollo, NeXT Cube, ...).
Und in dem Bereich ist eben bereits der 286 in bezahlbar eingesprungen,
sofern die Anforderungen nicht all zu hoch waren und sich mit dem 286er
+ Xenix umsetzen ließen.
Davon haben viele Firmen Gebrauch gemacht.
Und die Clients waren dann 8086er.
Und irgendwann hat man die 286er natürlich durch 386 und besser ersetzt.
Sun, DEC, Cray, IBM System/360 un sonstige Großrechner waren alle in
ganz anderen Preisregionen und für die kleineren mittelständische
Unternehmen nicht finanzierbar.
Rolf M. schrieb:> Nano schrieb:>> War der Intel 80286 rückblickend ein guter Wurf oder, wie es Bill Gates>> nannte, ein "hirnloser Chip"?>> Ich finde ehrlich gesagt, dass eher DOS ein hirnloses Betriebssystem> war, denn es hat die Vorteile des 286er überhaupt nicht richtig> ausgenutzt.
Für die Speichergrenze von 640 KB war IBM verantwortlich, nicht
Microsoft.
Den UMB hat IBM für Hardware reserviert und den Bereich rückblickend zu
groß gewählt.
Microsoft hat dann das eingekaufte QDOS entsprechend angepasst und
dieses entsprechend der Grenzen des ersten IBM PC und 8086 Prozessors zu
MS-DOS 1.0 weiterentwickelt.
Dafür war es entwickelt. Für den 286er IBM AT wurde es nicht entwickelt,
der war später lediglich abwärtskompatibel zu DOS.
Für den 286 hatte Microsoft Xenix im Programm und OS/2 in Entwicklung.
Und OS/2 wurde nur deswegen für den 286er entwickelt, weil IBM darauf
bestand. Die wollten ihre 286er Kunden nämlich nicht hängen lassen.
Microsoft hätte den 286er gerne aufgegeben und OS/2 gleich direkt für
den 386er entwickelt, der dann 1985 verfügbar war.
Mit der Windows 3.0 und später Windows 3.1 Oberfläche war Microsoft aber
so erfolgreich, dass sie bei OS/2 nicht mehr mitmachten und IBM eigene
Wege gehen musste.
Gleichzeitig setzte Microsoft über 200 Programmierer an um Windows NT
aus dem Boden zu stampfen und Microsoft setzte bei diesem gleich von
Anfang an auf Prozessorarchitekturunabhängigkeit und beim PC auf den
386er.
Insofern war DOS nie ein hirnloses Betriebssystem. Es war für den 8086
entwickelt und für den war es ideal.
Vor allem muss man hier auch beachten, dass Speicher noch sehr teuer
war, als der erste IBM PC rauskam. Da musste man sich also schon beim OS
stark einschränken.
> Und das ging beim 386er und 486er konsequent so weiter.
Du hattest die Möglichkeit Windows NT zu kaufen.
> XMS> und EMS, um den Speicher über 1 MB wenigstens nicht komplett brach> liegen zu lassen, waren nur schlechte Krücken. Und als work-around gab> es dann noch die DOS-Extender.
Wenn man DOS einsetzen wollte, ja, dann war das notwendig.
Fpgakuechle K. schrieb:>> Der erste Prozessor mit Protected Mode für den PC.>> 'Protected Mode' - muss man nicht kennen.
Es reicht ja, wenn man ihn benutzt. :-)
(Alle aktuellen x86-Betriebssysteme laufen im protected mode.)
MaWin schrieb:> Wie elegant ist da ein Stacksegment und Datensegment.
Der Haken war ja nur, dass jedes Segment trotzdem nur auf 64 KiB
limitiert war.
Das Problem hatte eben ein 68000 nicht, da konnte man problemlos auch
250 KB Daten am Stück bearbeiten.
Ansonsten hat man auf VM-Systemen natürlich so gesehen auch irgendwie
Segmente, denn Stack, Daten und ausführbares Programm werden in der MMU
separat abgebildet. Sie sind eben nur nicht bereits durch die Hardware
limitiert.
Nano schrieb:> Für die Speichergrenze von 640 KB war IBM verantwortlich, nicht> Microsoft.
Beim 8086, ja. Danach nicht mehr. MS-DOS hat im Bezug auf die Nutzung
der Prozessor-Features bis zu seinem Ende keine signifikante
Weiterentwicklung mehr erfahren.
> Den UMB hat IBM für Hardware reserviert und den Bereich rückblickend zu> groß gewählt.> Microsoft hat dann das eingekaufte QDOS entsprechend angepasst und> dieses entsprechend der Grenzen des ersten IBM PC und 8086 Prozessors zu> MS-DOS 1.0 weiterentwickelt.>> Dafür war es entwickelt. Für den 286er IBM AT wurde es nicht entwickelt,> der war später lediglich abwärtskompatibel zu DOS.
Allerdings gab es nicht nur MS-DOS 1.0, sondern noch einige weitere
Versionen, aber die haben die Prozessoren eben im Wesentlichen auch nur
als schnellere 8086er genutzt.
> Microsoft hätte den 286er gerne aufgegeben und OS/2 gleich direkt für> den 386er entwickelt, der dann 1985 verfügbar war.
Allerdings kam OS/2 dann von IBM, während MS-DOS auch beim 486er noch
nix konnte.
> Gleichzeitig setzte Microsoft über 200 Programmierer an um Windows NT> aus dem Boden zu stampfen und Microsoft setzte bei diesem gleich von> Anfang an auf Prozessorarchitekturunabhängigkeit und beim PC auf den> 386er.
NT spielte aber auf Heim-PCs keine Rolle. Das war für Workstations
gemacht.
> Insofern war DOS nie ein hirnloses Betriebssystem. Es war für den 8086> entwickelt und für den war es ideal.
Wer hat denn MS-DOS 5.0 noch auf einem 8086 betrieben? Das war auch für
neuere Prozessoren gemacht (und wurde dort auch sehr viel eingesetzt),
aber hat sie eben nicht sinnvoll genutzt.
> Vor allem muss man hier auch beachten, dass Speicher noch sehr teuer> war, als der erste IBM PC rauskam. Da musste man sich also schon beim OS> stark einschränken.>>> Und das ging beim 386er und 486er konsequent so weiter.>> Du hattest die Möglichkeit Windows NT zu kaufen.
Wie gesagt: Im Heimbereich war das nahezu bedeutungslos. Spiele hat da
keiner drauf gespielt, wenn sie überhaupt gelaufen sind. Und wie du
selbst sagtest: Speicher war teuer.
Ich hätte von DOS ja auch nicht volles präemptives Multitasking, Paging
und eine komplette graphische Benutzeroberfläche erwartet. Nur halt
etwas mehr als "benutzt den 486er als schnellen 8086". Zum Beispiel,
dass man dafür auch 32-Bit-Programme schreiben kann, ohne dass man
gleich am Betriebssystem vorbei alles komplett selber machen muss. Und
dass es ein paar mehr Treiber gibt als nur für Festplatte, Tastatur und
die Grafikkarte (die größtenteils eh nicht von DOS, sondern vom BIOS
kamen).
>> XMS>> und EMS, um den Speicher über 1 MB wenigstens nicht komplett brach>> liegen zu lassen, waren nur schlechte Krücken. Und als work-around gab>> es dann noch die DOS-Extender.>> Wenn man DOS einsetzen wollte, ja, dann war das notwendig.
Du meinst, wenn man Software einsetzen wollte, die für DOS geschrieben
war.
Jörg W. schrieb:> Ansonsten hat man auf VM-Systemen natürlich so gesehen auch irgendwie> Segmente, denn Stack, Daten und ausführbares Programm werden in der MMU> separat abgebildet. Sie sind eben nur nicht bereits durch die Hardware> limitiert.
Intel hat sie weiterhin "Segmente" genannt, aber es war eigentlich etwas
ganz anderes als die Speichersegmentierung im Real Mode. Auch der Zweck
ist ja ein ganz anderer.
Jörg W. schrieb:> Der Haken war ja nur, dass jedes Segment trotzdem nur auf 64 KiB> limitiert war.
Ist ja auch ein 16 bit Prozessor.
> Das Problem hatte eben ein 68000 nicht
War ja ein 32 bit Prozessor.
Ein 386 kann auch mehr als 64k pro Segment, Überraschung ?
Rolf M. schrieb:> Nano schrieb:>> Für die Speichergrenze von 640 KB war IBM verantwortlich, nicht>> Microsoft.>> Beim 8086, ja. Danach nicht mehr. MS-DOS hat im Bezug auf die Nutzung> der Prozessor-Features bis zu seinem Ende keine signifikante> Weiterentwicklung mehr erfahren.
Unsinn.
DOS Anwendungen nutzten DOS Funktionen zusammen mit BIOS aufrufen und
die lagen alle im UMB Bereich, der reserviert war und verlangten den
Real Mode.
Hier konnte Microsoft also gar nicht viel mehr machen, als das, was sie
gemacht haben, denn ein Bruch hätte dazu geführt, dass ältere DOS
Programme nicht mehr ausführbar gewesen wären.
Weiterentwicklungen gab es deswegen in Form von zuerst EMS, dann XMS
gefolgt von DPMI Dos Extendern wovon Windows 3.x im Standard Mode und
Extended Mode einer ist.
Die Windows >= 3.1 Programme liefen dann alle im Protected Mode.
Windows 3.0 war die letzte Version, die auch eine Ausführung von Windows
Programmen im Real Mode erlaubte. Windows Anwendungen die das nutzten,
gab es aber kaum welche. Die wurden alle für den Standard Mode und
Extended Mode entwickelt und liefen im Protected Mode.
Im Extended Mode, der erst ab dem 386er verfügbar war, war es möglich
DOS Anwendungen dank Virtual x86 Mode in einer MS DOS
Eingabeaufforderung auszuführen.
Beim 286er, also Standard Mode von Windows wurde Windows 3.1
unterbrochen und die DOS Anwendung dann so ausgeführt. Damit war aber
nur eine Ausführung von einer DOS Anwendung zur gleichen Zeit möglich.
Für mehr war der 386er nötig.
Und das war im Grunde das, was Microsoft machen konnte und auch gemacht
hat.
Im Laufe der Zeit gab es dann noch eine Win32 API für Windows 3.x so das
Userspaceprogramme entwickelt werden konnten, die auch unter Windows NT
liefen.
Und auf der DOS Schiene machte man mit Windows 95 dann weiter, da damit
eine bessere DOS Unterstützung möglich war, als mit Windows NT in dem
BIOS Zugriffe für den Userspace ja nicht mehr erlaubt waren.
Außerdem war der RAM Bedarf von Win9x geringer.
Das was du also Microsoft ankreidest fand alles im Rahmen der Windows
3.x und 9x Entwicklung statt und endete mit Windows ME.
Die Windows Programme liefen unter Windows XP und was danach kam dann
weiter.
>> Allerdings gab es nicht nur MS-DOS 1.0, sondern noch einige weitere> Versionen, aber die haben die Prozessoren eben im Wesentlichen auch nur> als schnellere 8086er genutzt.
Siehe oben.
Da konnte man nicht viel mehr machen als das was gemacht wurde.
Die DOS Programme diverser Hersteller ruften das BIOS direkt auf und auf
das hatte Microsoft keinen Einfluss und kann auch nicht umgangen werden.
Bei Windows NT und später ist das alles anders, da hier Userprogramme
die Hardware nicht mehr direkt ansteuern können, sondern alles über
Treiber und API Aufrufe abstrahiert ist.
Deswegen hat man hier als OS Entwickler dann auch viel mehr Einfluss und
Möglichkeiten die Kompatibilität zu wahren.
Nur bei DOS geht das halt nicht, weil die Anwendungen direkt die
Hardware aufrufen.
>> Microsoft hätte den 286er gerne aufgegeben und OS/2 gleich direkt für>> den 386er entwickelt, der dann 1985 verfügbar war.>> Allerdings kam OS/2 dann von IBM, während MS-DOS auch beim 486er noch> nix konnte.
Das ist falsch. Die ersten OS/2 Versionen wurden auch von Microsoft
verkauft.
Es gab somit OS/2 von IBM und Microsoft.
IBM verkaufte es an ihre IBM PC Kunden und lieferte es mit IBM PCs aus
und Microsoft bediente den Markt der IBM kompatiblen PCs.
Nur blieb der Markt vorerst bei DOS und dann kam Windows 3.x und wurde
ein voller Erfolg.
Entwickler meideten dann sogar für OS/2 direkt zu entwickeln, weil IBM
den Fehler machte und Windows 3.x mit OS/2 auslieferte.
Die Entwickler entwickelten daher nur für 16 Bit Windows und deckten
damit beide Märkte ab.
Das war der Genickbruch von IBM bezüglich OS/2.
Außerdem machte IBM bei OS/2 viele Fehler und verstand es nicht, das OS
richtig zu pushen.
IBM sorgte am Anfang bei OS/2 nicht einmal für Abwärtskompatibiliät zu
OS/2 1.0 und die Spieleindustrie wurde komplett ignoriert.
Dann lieferte es zu wenig Treiber mit und das Updaten von OS/2 war eine
Tortur.
Microsoft machte all das besser.
1. Sie gewährleisteten Abwärtskompatibilität
2. Sie setzten gleich von Anfang an bei Windows NT auf den richtigen,
also zukunftsfähigen Prozessor, nämlich den 386er.
3. Sie kümmerten sich um eine große breite Treiberunterstützung. Windows
lieferte schon von Anfang an sehr viele Treiber mit.
4. Das Updaten war viel einfacher.
5. Die Spieleindustrie wurde mit WinG und später DirectX nicht
vernachlässigt, sondern damit zum Wechsel von DOS auf Windows umworben.
6. Für Windows 3.x wurde sogar von Microsoft mit "QuickC für Windows
1.0" eine IDE + Compilersuite für damals extrem wenig Geld
herausgebracht um die Softwareentwicklung für Windows zu fördern. Damit
konnte man DOS Real Mode Programme und Windows 3.x Protected Mode
Programme entwickeln. IBM machte nichts dergleichen. Das Video über
Steve Balmer "Developers, Developers, Developers" kennst du vielleicht,
er hat es verstanden, dass man sich um seine Entwickler kümmern muss.
Microsoft mag moralisch betrachtet keine beliebte Firma sein, aber IBM
wäre noch viel schlimmer gewesen und Windows NT ist OS/2 technisch
überlegen, allein schon weil es gleich von Anfang an für den 386er
entwickelt wurde
und somit nicht die Beschränkungen hatte, die OS/2 hatte.
>> Gleichzeitig setzte Microsoft über 200 Programmierer an um Windows NT>> aus dem Boden zu stampfen und Microsoft setzte bei diesem gleich von>> Anfang an auf Prozessorarchitekturunabhängigkeit und beim PC auf den>> 386er.>> NT spielte aber auf Heim-PCs keine Rolle. Das war für Workstations> gemacht.
Wenn du das Geld hattest, konntest du es kaufen.
Der Heim Markt bediente natürlich Windows 3.x und Windows 9x weil das
die Mehrheit einsetze.
>> Insofern war DOS nie ein hirnloses Betriebssystem. Es war für den 8086>> entwickelt und für den war es ideal.>> Wer hat denn MS-DOS 5.0 noch auf einem 8086 betrieben? Das war auch für> neuere Prozessoren gemacht (und wurde dort auch sehr viel eingesetzt),> aber hat sie eben nicht sinnvoll genutzt.
Siehe oben. Verstehe erst einmal warum man DOS nicht einfach anders
machen kann.
>> Du hattest die Möglichkeit Windows NT zu kaufen.>> Wie gesagt: Im Heimbereich war das nahezu bedeutungslos. Spiele hat da> keiner drauf gespielt,
Ist ja jetzt nicht die Schuld von MS.
> Ich hätte von DOS ja auch nicht volles präemptives Multitasking, Paging> und eine komplette graphische Benutzeroberfläche erwartet. Nur halt> etwas mehr als "benutzt den 486er als schnellen 8086". Zum Beispiel,> dass man dafür auch 32-Bit-Programme schreiben kann, ohne dass man> gleich am Betriebssystem vorbei alles komplett selber machen muss.
Das kann man doch!
Dafür gab es die DOS Extender.
Jedes Spiel das beim Start "DOS/4GW" und ähnliches anzeigt macht genau
das.
Und Windows 3.x war selbst ein DPMI DOS Extender.
Und Win32 wurde nachgeschoben. Du hast das also alles bekommen.
Microsoft hat die DOS User mit Windows 9x sogar noch ziemlich lange
unterstützt.
Sie hätten nach Win32 und WinG die DOS Schiene auch viel früher fallen
lassen können und viel früher auf Windows NT only setzen können.
Dann hätten viele deiner DOS Anwendungen aber nicht mehr funktioniert,
weil das wegen den BIOS Aufrufen nicht geht.
Die DOSBox Emulation ist nicht grundlos entstanden.
> Und> dass es ein paar mehr Treiber gibt als nur für Festplatte, Tastatur und> die Grafikkarte (die größtenteils eh nicht von DOS, sondern vom BIOS> kamen).
Und was soll das bringen unter DOS?
Bei DOS haben die Anwendungen die Hardware selber direkt angesprochen.
Es gab abgesehen vom Dateisystem kaum eine Treiberabstraktion.
Und das nachträglich einzubauen hätte auch nicht viel Sinn gemacht, da
DOS es Programmen erlaubte im Real Mode zu laufen, womit sie alles
hätten machen können.
Die Entwicklung nach der du dich sehnst hat im Rahmen von Windows
stattgefunden. DOS war nicht weiterentwickelbar, man hätte mit der
Abwärtskompatibilität brechen müssen und dann wäre das kein DOS mehr
gewesen.
Und das hast du mit Windows NT ja im Grunde alles bekommen.
>>>> XMS>>> und EMS, um den Speicher über 1 MB wenigstens nicht komplett brach>>> liegen zu lassen, waren nur schlechte Krücken. Und als work-around gab>>> es dann noch die DOS-Extender.>>>> Wenn man DOS einsetzen wollte, ja, dann war das notwendig.>> Du meinst, wenn man Software einsetzen wollte, die für DOS geschrieben> war.
Ich meinte, wenn man Software unter DOS einsetzten wollte, die mehr als
640 KB nutzen hätte sollen.
MaWin schrieb:> Jörg W. schrieb:>> Der Haken war ja nur, dass jedes Segment trotzdem nur auf 64 KiB>> limitiert war.>> Ist ja auch ein 16 bit Prozessor.>>> Das Problem hatte eben ein 68000 nicht>> War ja ein 32 bit Prozessor.
Nein. Er nennt sich auch 16-bit-Prozessor. Erst der 68040 war offiziell
ein 32-bit-Prozessor.
Nach deiner Logik hätte ja ein Z80 als 8-Bit-Prozessor nur 256 Byte
adressieren können dürfen …
mal ehrlich, was gibts da zu feiern?
Der 68k war wesentlich mehr wert und interessanter und in Stückzahlen
früher und billiger.
Habe ich 1988 in C Prüfsoftware entwickelt mit 2,5 MB Ram ohne Stress
auf dem AtariST, war das immer auf dem PC eine Herausforderung für
EMM/QEMM und für den Programmierer der das in ASM eindampfen musste weil
der immer noch unter DOS lief.
Joachim B. schrieb:> Habe ich 1988 in C Prüfsoftware entwickelt mit 2,5 MB Ram ohne Stress> auf dem AtariST, war das immer auf dem PC eine Herausforderung für> EMM/QEMM und für den Programmierer der das in ASM eindampfen musste weil> der immer noch unter DOS lief.
Unter OS/2 hättest du auf dem 80286 die 2,5 MB RAM ohne Stress im
Protected Mode nutzen können.
Und VCPI und DPMI konforme DOS Extender für DOS gab es ab 1989. Mit
einem entsprechenden Compiler der protected Mode Programme compilierte
und DOS Extender unterstützte war das dann auch kein Problem mehr.
Der Watcom C Compiler lieferte bspw. ab Version 8.5 1991 gleich den
DOS/4GW DOS Extender mit und John Carmack nutzte den dann für Doom.
Die 80286 CPU und deren Protected Mode machte all das möglich.
Quälen hättest du dich lediglich mit einer 8086 oder 8088 CPU müssen und
dann hättest du für diese noch Extender Karten in den Rechner
reinstecken müssen, um überhaupt mehr als 640 KB RAM + ein paar
Zerquetschte nutzen zu können.
Und wer ASM direkt benutzt, hätte die CPU auch einfach selber in den
Protected Mode schalten können und dann auf das gesamte RAM, allerdings
noch segmentiert, zugreifen können.
Es lag also gar nicht an der CPU, sondern an DOS.
Nano schrieb:> Und wer ASM direkt benutzt, hätte die CPU auch einfach selber in den> Protected Mode schalten können und dann auf das gesamte RAM, allerdings> noch segmentiert, zugreifen können.
Hast Du jemals x86-Assembler-Code entwickelt?
Auf einer vernünftigen CPU hat man einfach ohne irgendwelche Klimmzüge
den gesamten zur Verfügung stehenden Speicher adressiert, im Fall des
68000 drei Jahre vor Erscheinen des 286ers. Und es wurde intern von
vornherein immer mit 32 Bit gearbeitet, unabhängig vom externen
Datenbus.
Du redest Dir gerade in Deinem Nostalgieanfall eine scheussliche
Architektur schön. Den Durchbruch der x86-Architektur gab es
letztendlich nur, weil man viel Rechenleistung für wenig Geld bekam,
nicht weil daran irgendwas besonders elegant oder innovativ gewesen
wäre.
Die Hersteller mit grösseren Preisschildern haben dementsprechend lange
auf andere Architekturen gesetzt, z.B. Sun (SPARC), SGI (MIPS) oder HP
(PA-RISC), nachdem sie zuerst 68k-CPUs verbaut hatten.
Nano schrieb:> Unter OS/2 hättest du auf dem 80286 die 2,5 MB RAM ohne Stress im> Protected Mode nutzen können.
mit Unterstützung von GPIB/IEEE488?
Ich musste mich ja dem beugen was kaufbar und günstig war und das war HP
IEEE488 ISA Card, QC für DOS. Die Chefs waren knauserig, alleine das
unser Student den 19" und 25MHz 486 für 25000,-DM bekam bedurfte
Erklärung!
Damals war PC & Monitor Geld=Prestige und nicht nach Effektivität
verteilt!
Hmmm schrieb:> Nano schrieb:>> Und wer ASM direkt benutzt, hätte die CPU auch einfach selber in den>> Protected Mode schalten können und dann auf das gesamte RAM, allerdings>> noch segmentiert, zugreifen können.>> Hast Du jemals x86-Assembler-Code entwickelt?
Selbstverständlich!
Und gerade mit Assembler stehen dir ja alle Optionen einer CPU zur
Verfügung.
> Auf einer vernünftigen CPU hat man einfach ohne irgendwelche Klimmzüge> den gesamten zur Verfügung stehenden Speicher adressiert, im Fall des> 68000 drei Jahre vor Erscheinen des 286ers.
Linearer Speicherzugriff im Protected Mode kam halt erst mit dem 386er.
Deswegen sagte ich ja ganz oben, dass die "immer noch" Segmentierung ein
Nachteil des 286er ist. Dennoch kann er Protected Mode und mit dem
richtigen OS, z.B. OS/2, kannst du davon dann auch direkt profitieren.
Unter DOS brauchst du halt DOS Extender.
> Du redest Dir gerade in Deinem Nostalgieanfall eine scheussliche> Architektur schön.
Ich mache diese Vergleiche 286er vs. 68K hier gar nicht, das machen nur
einige von euch.
> Den Durchbruch der x86-Architektur gab es> letztendlich nur, weil man viel Rechenleistung für wenig Geld bekam,> nicht weil daran irgendwas besonders elegant oder innovativ gewesen> wäre.
Der Durchbruch kam mit dem 386DX, denn das war eindeutig ein sehr guter
Wurf.
Er hatte nämlich alles, was eine moderne CPU damals brauchte.
Lediglich bei den Registern hätte es etwas mehr sein könnten, aber das
Problem wurde dann mit x86-64 gelöst.
Joachim B. schrieb:> Nano schrieb:>> Unter OS/2 hättest du auf dem 80286 die 2,5 MB RAM ohne Stress im>> Protected Mode nutzen können.>> mit Unterstützung von GPIB/IEEE488?
OS/2 war ein Protected Mode OS, entsprechend nutzten auch die Treiber
für Hardware den Protected Mode und BIOS Funktionen wurden, wie bei
jedem modernen OS, nach dem Booten des OS auch nicht mehr benutzt. Die
BIOS Funktionen verlangen nämlich den Real Mode, deswegen steuern
moderne Betriebssysteme die HW ohne Umwege lieber direkt an.
Solange für die Karte also OS/2 Treiber verfügbar waren, sollte das
funktionieren. Ja.
Nano schrieb:> Joachim B. schrieb:>> Nano schrieb:>>> Unter OS/2 hättest du auf dem 80286 die 2,5 MB RAM ohne Stress im>>> Protected Mode nutzen können.>>>> mit Unterstützung von GPIB/IEEE488?>> OS/2 war ein Protected Mode OS, entsprechend nutzten auch die Treiber> für Hardware den Protected Mode und BIOS Funktionen wurden, wie bei> jedem modernen OS, nach dem Booten des OS auch nicht mehr benutzt. Die> BIOS Funktionen verlangen nämlich den Real Mode, deswegen steuern> moderne Betriebssysteme die HW ohne Umwege lieber direkt an.>> Solange für die Karte also OS/2 Treiber verfügbar waren, sollte das> funktionieren. Ja.
Noch eine kleine Ergänzung.
Natürlich muss auch die Anwendung dann für OS/2 geschrieben sein.
Es nützt also nichts, eine DOS Anwendung in der DOS Umgebung von OS/2
auszuführen, in der Hoffnung, dass die dann die Treiber von OS/2 nutzt.
So funktioniert das natürlich nicht.
Für Windows NT und seine Nachfolger gilt übrigens das gleiche.
Nano schrieb:> War der Intel 80286 rückblickend ein guter Wurf oder, wie es Bill Gates> nannte, ein "hirnloser Chip"?
Ich will nichts von seinen Leistungen kleinreden, auf gar keinen Fall.
Aber wenn Bill Gates einen Chip hirnlos nennt, frage ich mich, ob er
auch alles gesehen und verstanden hat.
Der Mann hat Probleme mit seinen Erinnerungen und ist auf seinem Gebiet
sicher gut. Aber welches Gebiet ist das?
MaWin schrieb:> Motorola nannte ihn je nach externes Datenbusbreite 8, 16 und 32 bit
Ändert nichts daran, dass deine Logik, nur aufgrund einer bestimmten
CPU-Register-Breite auf den adressierbaren Adressraum zu schließen,
unpassend ist (wie am Beispiel der 8-Bit-CPUs einfach zu zeigen). Und
wenn man eben auf einem System, das schon bis zu 16 MiB Speicher
adressieren konnte, nur 64 KiB Daten (auf einfache Weise) hanhdaben
kann, dann ist das eine massive Einschränkung, die die Konkurrenz so
nicht hatte.
Nano schrieb:> Unter OS/2 hättest du auf dem 80286 die 2,5 MB RAM ohne Stress im> Protected Mode nutzen können.
Zum Problem der Segmentierung im protected mode gehörte die miserable
Performance bei streuender Adressierung von Datenmengen jenseits 64kB.
Ein Segmentregister zu laden war eine sehr teure Operation. Wenn man das
alle paar Zugriffe durchführen musste, wurde es übel.
Intel hatte zudem dafür weitsichtig dafür gesorgt, dass es auch
nachfolgenden Implementierungen nur sehr aufwändig möglich würde, das zu
beschleunigen.
Viel Code mit wenig Daten war daher weit effizienter als wenig Code mit
vielen Daten.
Nano schrieb:> Es nützt also nichts, eine DOS Anwendung in der DOS Umgebung von OS/2> auszuführen, in der Hoffnung, dass die dann die Treiber von OS/2 nutzt.> So funktioniert das natürlich nicht.
Doch. Genau so funktionierte das. Grundlegende Teile von OS/2 1.x waren
deshalb bimodal, liefen sowohl im protected als auch im real Mode. Eine
ziemlich bizarre Technik, wenn der Interrupt eines Treibers in beiden
Modi erfolgen kann. Es gab deshalb recht spezielle Wege im Umgang mit
Speicheradressierung auf dieser Ebene.
Nano schrieb:> Rolf M. schrieb:>> Nano schrieb:>>> Für die Speichergrenze von 640 KB war IBM verantwortlich, nicht>>> Microsoft.>>>> Beim 8086, ja. Danach nicht mehr. MS-DOS hat im Bezug auf die Nutzung>> der Prozessor-Features bis zu seinem Ende keine signifikante>> Weiterentwicklung mehr erfahren.>> Unsinn.
Was gab es denn da noch unter DOS, neben EMM386 und himem.sys? Das ist
schon wirklich das absolute Minimum. Zwischen MS-DOS 1.0 und 5.0 liegen
10 Jahre, in denen in dieser Hinsicht bis auf die genannten Dinge nichts
passiert ist.
> DOS Anwendungen nutzten DOS Funktionen zusammen mit BIOS aufrufen und> die lagen alle im UMB Bereich, der reserviert war und verlangten den> Real Mode.> Hier konnte Microsoft also gar nicht viel mehr machen, als das, was sie> gemacht haben, denn ein Bruch hätte dazu geführt, dass ältere DOS> Programme nicht mehr ausführbar gewesen wären.
Beim 286er vielleicht noch, aber spätestens beim 386er mit seinem
virtual 8086 mode wäre das problemlos gegangen. Genau dafür hat Intel
den ja eingeführt. Unter Windows hat man das ja dann auch gemacht. Warum
nicht unter DOS?
> Weiterentwicklungen gab es deswegen in Form von zuerst EMS, dann XMS> gefolgt von DPMI Dos Extendern wovon Windows 3.x im Standard Mode und> Extended Mode einer ist.
DOS-Extender sind nur nicht Teil von DOS, sondern auch wieder nur
Work-Arounds, um an DOS vorbei das zu machen, was es eigentlich selbst
hätte können sollen.
> Und das war im Grunde das, was Microsoft machen konnte und auch gemacht> hat.
Aber eben in Windows, was eigentlich nur ein graphischer Aufsatz für's
Betriebssystem sein sollte. Das eigentliche Betriebssystem war DOS, und
das konnte davon gar nichts.
> Und auf der DOS Schiene machte man mit Windows 95 dann weiter, da damit> eine bessere DOS Unterstützung möglich war, als mit Windows NT in dem> BIOS Zugriffe für den Userspace ja nicht mehr erlaubt waren.> Außerdem war der RAM Bedarf von Win9x geringer.
Da ist DOS dann aber immer mehr zum Bootloader für Windows verkommen.
Also auch keine Weiterentwicklung mehr.
> Die DOS Programme diverser Hersteller ruften das BIOS direkt auf und auf> das hatte Microsoft keinen Einfluss und kann auch nicht umgangen werden.
Natürlich konnte es das, sogar sehr einfach. Und zahlreiche
DOS-Hilfsprogramme (und Viren) haben das auch getan. Einfach den INT 10h
umbiegen, schon hat man alle BIOS-Aufrufe in der Hand.
> Nur bei DOS geht das halt nicht, weil die Anwendungen direkt die> Hardware aufrufen.
Direkte Hardware-Zugriffe sind natürlich was anderes. Ich hab aber auch
nirgends geschrieben, dass DOS die alle abfangen sollte.
> IBM verkaufte es an ihre IBM PC Kunden und lieferte es mit IBM PCs aus> und Microsoft bediente den Markt der IBM kompatiblen PCs.>> Nur blieb der Markt vorerst bei DOS und dann kam Windows 3.x und wurde> ein voller Erfolg.> Entwickler meideten dann sogar für OS/2 direkt zu entwickeln, weil IBM> den Fehler machte und Windows 3.x mit OS/2 auslieferte.> Die Entwickler entwickelten daher nur für 16 Bit Windows und deckten> damit beide Märkte ab.>> Das war der Genickbruch von IBM bezüglich OS/2.
Ich denke, ein Problem war gerade hier der Speicher. Ich hatte auf
meinem 486er damals OS/2, aber die zu der Zeit üblichen 4 MB reichten
nicht, um damit vernünftig zu arbeiten - schon gar nicht, wenn man das
enthaltene DOS/Windows auch noch mit laufen ließ.
>>> Gleichzeitig setzte Microsoft über 200 Programmierer an um Windows NT>>> aus dem Boden zu stampfen und Microsoft setzte bei diesem gleich von>>> Anfang an auf Prozessorarchitekturunabhängigkeit und beim PC auf den>>> 386er.>>>> NT spielte aber auf Heim-PCs keine Rolle. Das war für Workstations>> gemacht.>> Wenn du das Geld hattest, konntest du es kaufen.
Ja, aber da war das mit der DOS-Kompatibilität auch nicht gegeben.
>>> Du hattest die Möglichkeit Windows NT zu kaufen.>>>> Wie gesagt: Im Heimbereich war das nahezu bedeutungslos. Spiele hat da>> keiner drauf gespielt,>> Ist ja jetzt nicht die Schuld von MS.
Naja, NT wäre damals einfach nicht dafür geeignet gewesen. Das ist dann
eben wie oben bei OS/2. Was will ich mit einem Betriebssystem, das teuer
ist, zu vielen DOS-Anwendungen nicht kompatibel und das viel teuren
Speicher braucht? Ich kaufe ja auch keinen Traktor, um damit
Wochenendausflüge zu machen, auch wenn ein Traktor ein sehr praktisches
Gerät sein kann.
>> Ich hätte von DOS ja auch nicht volles präemptives Multitasking, Paging>> und eine komplette graphische Benutzeroberfläche erwartet. Nur halt>> etwas mehr als "benutzt den 486er als schnellen 8086". Zum Beispiel,>> dass man dafür auch 32-Bit-Programme schreiben kann, ohne dass man>> gleich am Betriebssystem vorbei alles komplett selber machen muss.>> Das kann man doch!> Dafür gab es die DOS Extender.
Die sind wie gesagt nicht Teil von DOS. Klar, irgendwann hat jemand
diese Unzulänglichkeiten von DOS erkannt und ist dann eingesprungen, um
diese zu umgehen.
> Jedes Spiel das beim Start "DOS/4GW" und ähnliches anzeigt macht genau> das.> Und Windows 3.x war selbst ein DPMI DOS Extender.>> Und Win32 wurde nachgeschoben. Du hast das also alles bekommen.> Microsoft hat die DOS User mit Windows 9x sogar noch ziemlich lange> unterstützt.
Der Punkt ist, dass das alles eben nicht Teil des Betriebssystems war,
sondern Teil der graphischen Benutzeroberfläche.
>> Und>> dass es ein paar mehr Treiber gibt als nur für Festplatte, Tastatur und>> die Grafikkarte (die größtenteils eh nicht von DOS, sondern vom BIOS>> kamen).>> Und was soll das bringen unter DOS?
Ich kann mich noch gut an Probleme mit nicht unterstützter Hardware
erinnern, weil damals jedes Programm jede Peripherie einzeln
unterstützen musste, damit es ging.
> Bei DOS haben die Anwendungen die Hardware selber direkt angesprochen.
Ja, weil sie es mussten, da in DOS ein Treibermodell dafür gefehlt hat.
Und das war immer recht problematisch. Es ist z.B. der Grund, weshalb
jedes Spiel seine eigene Treibersammlung für Soundkarten mitbringen
musste. Und weshalb sehr viele Soundkarten-Hersteller ihre Karten
SoundBlaster-kompatibel gemacht haben, damit sie auch mit Programmen
funktionieren, die nicht so üppig mit eigenen Treibern ausgestattet
sind. Hätte DOS dafür Treiber geboten, dann wäre das alles nicht nötig
gewesen. Erst unter Windows gab es dann sowas, aber eben nur für
Programme, die auch komplett für Windows geschrieben waren.
> Es gab abgesehen vom Dateisystem kaum eine Treiberabstraktion.
Das ist ja gerade das, was ich bemängle.
> Und das nachträglich einzubauen hätte auch nicht viel Sinn gemacht, da> DOS es Programmen erlaubte im Real Mode zu laufen, womit sie alles> hätten machen können.
Aber dann eben mit eigenem Treiber für jede einzelne
Hardware-Komponente. Und was heißt "nachträglich"? Das wäre einfach Teil
der Weiterentwicklung von DOS gewesen. Stattdessen hat man das halt dann
bei Windows "nachträglich" getan.
> Die Entwicklung nach der du dich sehnst hat im Rahmen von Windows> stattgefunden.
Genau, und die hätte im Rahmen von DOS stattfinden sollen. Denn es gibt
keinen erkennbaren Grund, weshalb für den Betrieb einer Soundkarte eine
graphische Benutzeroberfläche erforderlich sein sollte. Also weshalb
diese beiden Dinge so fest koppeln?
Nano schrieb:> Natürlich muss auch die Anwendung dann für OS/2 geschrieben sein.> Es nützt also nichts, eine DOS Anwendung in der DOS Umgebung von OS/2> auszuführen, in der Hoffnung, dass die dann die Treiber von OS/2 nutzt.> So funktioniert das natürlich nicht.
Doch, genau so funktionierte das unter OS/2, da es die Peripherie
virtualisieren konnte (Nannte sich "Virtual Device Driver"). Es hat also
z.B. für DOS-Anwendungen die Hardware-Register und ggf. zugehörige
BIOS-Funktionen emuliert, so dass diese meinten, direkt auf die Hardware
zuzugreifen, aber in Wirklichkeit ging es über den Treiber.
Rolf M. schrieb:> Doch, genau so funktionierte das unter OS/2, da es die Peripherie> virtualisieren konnte (Nannte sich "Virtual Device Driver").
Das ging aber erst in OS/2 2.0 mit dem Virtual86 Mode. In 1.x liefen nur
jene paar DOS-Programme, die sich an die offiziellen Schnittstellen
hielten, statt direkt auf die Hardware zu gehen.
(prx) A. K. schrieb:> Rolf M. schrieb:>> Doch, genau so funktionierte das unter OS/2, da es die Peripherie>> virtualisieren konnte (Nannte sich "Virtual Device Driver").>> Das ging aber erst in OS/2 2.0 mit dem Virtual86 Mode.
Ja. 2.0 war die erste OS/2-Version, mit der ich in Kontakt kam, daher
kenne ich die Details der früheren Versionen nicht. Ich weiß noch, dass
das als eine der großen Innovationen von OS/2 genannt wurde.
Man konnte den Commodore C16 einfach an irgendeinen Fernseher
anstöpseln, und BASIC lernen. Ein kleiner zusätzlicher Mathe-Kursus
hätte vermutlich auch gar nicht geschadet..
Die 68000, und da gab es früher hier im Forum richtig gute, bzw.
spannende Diskussionen zum Thema Weiterentwicklunng der Prozessoren,
liefen doch in eine Sackgasse. Kompatibilität? Naja..
Da gab es zwar später auch auf Windows, "läuft nur auf aktuellem
Windows" wie auch heute, aber die Kompatibilität ist bzw. war trotzdem
in vielen Fällen noch sehr gut.
Die Dokumentation war aber beim IBM PC vermutlich auch etwas besser, bei
den 68000 musste man sich vergebens im riesigen Bücherdschungel
zurechtfinden, und brauchte meistens eine Uni für ordentliche
Dokumentationen und deren "Links".
Midi usw. wurde zwar von Usb abgelöst - allerdings noch nicht in Rente
geschickt, dazu gibt es noch zuviel Gerätschaften in Musikschulen,
Muskistudios, oder privaten Kellern.
(prx) A. K. schrieb:> Viel Code mit wenig Daten war daher weit effizienter als wenig Code mit> vielen Daten.
Das doch sowieso schon immer, weil der Datenzugriff so langsam ist.
Deswegen gibt bzw. gab es ja auch die Entwicklungen hin zu immer
größeren Caches und religonhafte Einsätze von Allignment dort.
rbx schrieb:> Die 68000, und da gab es früher hier im Forum richtig gute, bzw.> spannende Diskussionen zum Thema Weiterentwicklunng der Prozessoren,> liefen doch in eine Sackgasse. Kompatibilität?
Wo fehlte da die Kompatibilität? Du konntest auch auf den neueren
680x0ern problemlos 68000-Code ausführen. 32-Bit-Code war es ja eh von
Anfang an.
rbx schrieb:> Da gab es zwar später auch auf Windows, "läuft nur auf aktuellem> Windows" wie auch heute
Was hat Windows mit m68k zu tun?
rbx schrieb:> Die Dokumentation war aber beim IBM PC vermutlich auch etwas besser
Warum vermutest Du das?
Hmmm schrieb:> Wo fehlte da die Kompatibilität? Du konntest auch auf den neueren> 680x0ern problemlos 68000-Code ausführen. 32-Bit-Code war es ja eh von> Anfang an.
Längerfristig lief es wirklich in die Sackgasse. Die
Befehlssatz-Architektur hatte ab 68020 eine so komplexe Dekodierung und
so komplexe Ausführungsabläufe, dass im Zeitalter von superskalaren
Prozessoren der Aufwand für eine effiziente Implementierung zu hoch
wurde. Die RISCs liefen ebenso den Rang ab, wie der ungefähr parallel
zum 68060 aufkommende Pentium Pro, der aufgrund des Marktes mit mehr
Geld gesegnet war.
Motorola erkannte korrekt auf eine falsche Entwicklungsrichtung. In
Coldfire lebte das ja dann weiter, aber drastisch in der Komplexität
reduziert und einen weniger anspruchsvollen Markt adressierend.
rbx schrieb:> Das doch sowieso schon immer, weil der Datenzugriff so langsam ist.> Deswegen gibt bzw. gab es ja auch die Entwicklungen hin zu immer> größeren Caches und religonhafte Einsätze von Allignment dort.
Das Problem liegt in dem, was bei der Ladeoperation eines
Segmentregisters geschieht. Es wird ja nicht nur das Register selbst
geladen, sondern der komplette damit verbundene Deskriptor, inklusive
Auswertung.
Intel nannte das zwar "Descriptor-Cache", aber es war eigentlich das
Gegenteil davon: Weil Intel sinnigerweise definiert hatte, dass jeder
Ladevorgang den Deskriptor erneut aus dem Speicher zieht, selbst wenn es
der gleiche ist, war es ausgesprochen aufwändig, einen echten
Deskriptor-Cache mit etlichen Einträgen zu implementieren, der also
nicht jedesmal den ganzen Zinnober nach sich zieht.
Das war einer der Gründe, weshalb für Win9x der Pentium Pro gegenüber
dem Pentium MMX im Nachteil war. Erst mit dem Pentium II kam dann ein
echter Descriptor-Cache in die P6-Linie, der das Update-Problem löste.
Vmtl indem Speicheroperationen auf den Descriptor-Tabellen
mitgeschnüffelt wurden.
Seit etlichen Jahren bremst Segmentierung wieder, auch in den alten
Modi, weil eine Basisadresse != 0 zusätzlich Zeit zur Berechnung
benötigt.
Nano schrieb:> War der Intel 80286 rückblickend ein guter Wurf
Er war nicht viel mehr als ein DOS-Beschleuniger, der den Real Mode
wesentlich schneller ausführte als der 8086. Der Rest war faktisch
Gimmik.
Ein guter Wurf war 386 dank des 32-Bit Modus und der damit
einhergehenden vernünftigen Adressierbarkeit grösserer Datenmengen. Und
der Pentium Pro (P6), der aufgrund der radikal anderen Mikroarchitektur
den Rückstand zu den damaligen RISCs einholte.
(prx) A. K. schrieb:> Und der Pentium Pro (P6), der aufgrund der radikal anderen> Mikroarchitektur den Rückstand zu den damaligen RISCs einholte.
Der Pentium Pro war auf Grund des großen integrierten Caches und der
geringen Ausbeute bei der Produktion teuer. Er hat sich deshalb nicht
gut verkauft.
Erst der Pentium II hat das dann durch sein Modul-Design entschärft und
war dann auch massentauglich.
Rolf M. schrieb:> Der Pentium Pro war auf Grund des großen integrierten Caches und der> geringen Ausbeute bei der Produktion teuer. Er hat sich deshalb nicht> gut verkauft.
Das auch. Aber auch wer den Preis zahlte, bekam bei Win9x nicht das, was
er sich erhofft haben mag. Bei WinNT und den Unixen hingegen war er
super.
MaWin schrieb:> Segmente sind wesentlich besser als pages als Speicherschutz,> und Gates zum Aufruf höherer Systemebenen perfekt.
Ganz zu schweigen vom nächsten logischen Schritt Intels, dem iAPX 432.
Ein grosser Wurf in die falsche Richtung. ;-)
(prx) A. K. schrieb:> MaWin schrieb:>> Segmente sind wesentlich besser als pages als Speicherschutz,>> und Gates zum Aufruf höherer Systemebenen perfekt.>> Ganz zu schweigen vom nächsten logischen Schritt Intels, dem iAPX 432.> Ein grosser Wurf in die falsche Richtung. ;-)
AFAIR wurde ja immerhin das Businterface von dem grossen Wurf in den
286er übernommen.
Aber es gab alle ~10 Jahre so "Knaller" von Intel.
Anfang 80er: iAPX432, so sicher, dass er zu langsam war.
Anfang 90er: i860, so superskalar, dass kein Compiler ihn vernünftig
ausnutzen konnte.
Anfang 2000er: Itanium, so VLIW, dass kein Compiler ihn vernünftig
ausnutzen konnte.
Anfang 2010: Larabee, wohl einfach so gefloppt.
Jörg W. schrieb:> Und> wenn man eben auf einem System, das schon bis zu 16 MiB Speicher> adressieren konnte, nur 64 KiB Daten (auf einfache Weise) hanhdaben> kann, dann ist das eine massive Einschränkung, die die Konkurrenz so> nicht hatte.
Der 80286 ist eine 16 Bit CPU. D.h. normalerweise wäre da bei 2^16-1
Schluss, das sind genau diese 65535 Bytes.
Dass er mehr adressieren kann, liegt ja am 24 Bit breiten Adressbus und
an der Segmentierung und den Offsets.
Zumal, was hätte es den gebracht?
DOS war ein 16 Bit OS und die Programme arbeiteten alle mit Segmenten
und Offsets und es stand wohl schon damals fest, dass es nicht mehr
lange bis zum 32 Bit Prozessor dauern würde.
Der 386 kam nämlich schon 1985, also gerademal 3 Jahre nach dem 80286.
Hätte man dem 80286 eine lineare Adressierung des 24 Bit breiten
Adressbus ermöglicht, dann hätte das sicherlich jede Menge Transistoren
und neuer Opcode Befehle gekostet und dann hätte man beim 386er das
alles zwecks Abwärtskompatibilität mitunterstützen müssen.
Dadurch, dass man das alles nicht so machte, konnte der 386er viel
schlanker ausfallen und rückwirkend war das dann auch besser so.
Ab ca. 1993 setzte dann ohnehin nahezu jedes neue größere DOS Spiel eine
386er CPU voraus, während die Arbeitswelt auf Windows umschwenkte und
die Real Mode Programmierung und Begrenzung auf 64 KB Segmente war somit
ohnehin Geschichte.
Und IBM setzte damals beim ersten PC auch deswegen auf den Intel 8086,
weil man damit recht einfach die vielen CP/M Programme vom Z80 auf den
PC portieren konnte. Für den gab es nämlich schon eine riesige
Softwarebasis in der Geschäftswelt und um da Kunden zu gewinnen und ein
Merkmal für einen Kaufanreiz zu haben, welches für den IBM PC spricht,
hat man deswegen das genau so gemacht.
Und aus dem gleichen Grund ist DOS CP/M sehr ähnlich.
Die 8 Bit Prozessoren auf denen damals CP/M lief waren auf 64 KiB
beschränkt, wollte man mehr RAM nutzen, so ging das nur mit
Bankswitching.
Beim 8086 entschied sich Intel anders, und verwendete stattdessen die
Geschichte mit den ziemlich frei wählbaren Segmentadressen und Offsets.
Das war wesentlich flexibler als das Bankswitching und der 80286 hat es
dann halt geerbt und mit dem 80386 war es dann nicht mehr nötig.
Nano schrieb:> Der 80286 ist eine 16 Bit CPU. D.h. normalerweise wäre da bei 2^16-1> Schluss, das sind genau diese 65535 Bytes.
Das ist der gleiche logische Trugschluss wie MaWin: nach diesem Schluss
hätten 8-Bit-CPUs nur jemals 256 Byte addressieren können dürfen. Haben
sie aber nicht, die konnten üblicherweise schon 65536 Bytes adressieren
(manche davon halt 256 Byte schneller als den Rest, OK). Es wäre also
nicht so sehr unlogisch, wenn eine CPU mit größerem möglichen Speicher
dann auch einen zumindest optional benutzbaren 24-bit-Adressierungsmodus
gehabt hätte.
> DOS war ein 16 Bit OS und die Programme arbeiteten alle mit Segmenten> und Offsets
Der 80286 ist ja aber nicht für das beschränkte MS-DOS konzipiert
worden, bei dem sowieso niemand jemals mehr als 640 KiB Speicher
brauchen würde. Die "Segmente" des 8086 waren eh schon, naja, nicht
gerade begeisternd, und wie A.K. schon ausgeführt hat, waren ein Wechsel
der Segmentregister im protected mode des 80286 einfach mal sehr teuer
geworden.
Jörg W. schrieb:> Das ist der gleiche logische Trugschluss wie MaWin
Datenbreite und Adressbreite haben keinen ursächlichen Zusammenhang.
Anfangs überstieg die Datenbreite die Adressbreite bei weitem, was sich
auch in der definierten Breite von Adress/Indexregistern niederschlug.
Etwa bei 60-Bit Datenregistern und 18-Bit Adressregistern (CDC6600) und
32-Bit Universalregistern mit ausdrücklich auf 24-Bit reduzierter
Nutzung bei Adressen (IBM 360, dieses Erbe steckt bis heute in deren
Mainframes drin).
Ein weiteress Indiz für die 'Hirnlosigkeit' des i286 ist seine
endemische Ausbreitung in einer einzigen, allerdings recht geräumigen,
Nische - den IBM PC.
Den 68000 dagegen findet man in mehreren Computer-/Workstationsystemen,
Messtechnik, Spielkonsolen, Arcade games und als embedded devices
(Postscript-drucker etc). Sogar eine strahlungsgehärtetet Variante fürs
Space shuttle gibt es.
Nano schrieb:> Und IBM setzte damals beim ersten PC auch deswegen auf den Intel 8086,> weil man damit recht einfach die vielen CP/M Programme vom Z80 auf den> PC portieren konnte.
Da hat mir ein in den späten 70ern/frühen 80ern bei Intel beschäftigter
Lehrstuhl-Mitarbeiter noch was anderes erzählt: Ein auch sehr
gewichtiger Grund, den 8088 zu nehmen, war das für damalige Verhältnisse
geradezu monströse DIL64-Gehäuse des 68000. Das DIL40 vom 8088 war
dagegen Standard und "bekannt". Motorola hat das Problem mit dem 68008
beseitigt, da war es aber schon zu spät, der kam erst 1982 raus.
Das mit CP/M war IMO eher weniger ein Grund, kurz nach PC-Einführung gab
es ja auch ein CP/M-68k, d.h. das war bei vermutlich eh schon in der
Pipeline, wie die PC-Entwicklung Mitte 80 gestartet hat.
Georg A. schrieb:> geradezu monströse DIL64-Gehäuse des 68000. Das DIL40 vom 8088 war> dagegen Standard und "bekannt". Motorola hat das Problem mit dem 68008
Tja der Preis der 8088-Xt IBM-Kompatiblen aus Fernost war halt weit
unter den 680x0 Maschinen - die hat man zwar bewundert anno 1985
aber nach einem Blick in den Geldbeutel war dann schnell die Auswahl
klar....
Der 8086 flog aber auch im Weltall umher: in seiner
Strahlungsharten Variante 80c86RRH -
Hier im Harris Katalog zu finden:
http://www.bitsavers.org/components/harris/
-> 1989_Harris_Products_Guide_89.pdf Seite 66
Verwendet im:
ROSAT:
https://www.bernd-leitenberger.de/astonomische-satelliten-xray1.shtml
(prx) A. K. schrieb:> Seit etlichen Jahren bremst Segmentierung wieder, auch in den alten> Modi, weil eine Basisadresse != 0 zusätzlich Zeit zur Berechnung> benötigt.
Es gibt doch seit etlichen Jahren keine Segmentaddressierug mehr.
Bring dich mal auf einen aktuellen Wissensstand...
(prx) A. K. schrieb:> Zum Problem der Segmentierung im protected mode gehörte die miserable> Performance bei streuender Adressierung von Datenmengen jenseits 64kB.> Ein Segmentregister zu laden war eine sehr teure Operation. Wenn man das> alle paar Zugriffe durchführen musste, wurde es übel.
Dann hat man wie so oft miesen Code ohne Verstand geschrieben.
Mit den Segmentregistern konnte man problemlos 4 x 64 KByte addressieren
(CS SS, DS, ES) und mit wenig Aufwand auch 4x 1 MByte mit 32 bit far
Zeigern.
Man musste also nur alle 64 kByte ein 16 Bit Segmentregister laden...
Muss wirklich furchtbar gewesen sein, auf einem Rechner mit
durchschnittlich
einem halben MByte Speicher musste man das 8x machen, um den ganzen
Speicher
zu addressieren.
Die Diskussion hier zeigt nur wie überheblich, fett und träge man im
Laufe
der Zeit wird, wenn man 8-16 GByte zum Verschwenden hat.
Im Nachhinein lässt sich immer leicht gescheit daherreden.
udok schrieb:> Es gibt doch seit etlichen Jahren keine Segmentaddressierug mehr.
Die alten Modi gibts immer noch, folglich auch deren Adressierung und
die dafür erforderliche Adressrechnung in Hardware. Während aber frühere
Implementierungen die Basisadresse des Segments obligatorisch
einfliessen liessen, findet diese Addition mittlerweile nur noch statt,
wenn nicht 0, kostet dann aber zusätzliche Zeit.
Im 64-Bit Modus ist zwar von der klassische Segmentierung nicht mehr
viel übrig. Die Basisadressen für Adressierung per FS/GS Präfix gibts
aber noch, und für die gilt das gleiche wie eben.
Die Adressierung passiert schon seit Ewigkeiten in einer eigenen ALU,
mit 0 Kosten.
Und seit ca. 20 Jahren gibt es den 64 Bit Modus, wo es keine Segmente
mehr gibt. Das ist doch alles längst gegessen.
udok schrieb:> Man musste also nur alle 64 kByte ein 16 Bit Segmentregister laden...
Lerne den Unterschied zwischen sequentieller und frei streuender
Adressierung.
Zwar konnte man sich in Grenzen der 64kB Limitierung anpassen, indem man
ein Programm speziell auf die Charakteristik des 286 neu schrieb, die
Algorithmen anpasste. Aber wenn man bereits auf 68000 in einem 32-Bit
Adress- und Datenmodell gearbeitet hatte, war die Migration zu 286 ein
grosser Schritt rückwärts.
Wenn man dann auch noch auf bestehendem Code aufbaute, der in alter
Unix-Tradition von sizeof(int) == sizeof(char *) ausging, war 16-Bit x86
jenseits der Small+Medium Models einfach bloss übel.
udok schrieb:> Die Adressierung passiert schon seit Ewigkeiten in einer eigenen ALU,> mit 0 Kosten.
Bring dich mal auf einen aktuellen Wissensstand...
"The load store pipelines are optimized for zero-segment-base
operations. A load or store that has a non-zero segment base suffers a
one-cycle penalty in the load-store pipeline." (AMD)
> Und seit ca. 20 Jahren gibt es den 64 Bit Modus, wo es keine Segmente> mehr gibt.
Aber deren Basisadressen gibts noch. Bei FS/GS.
Auf jeder Intel CPU der letzten 10 Jahre kannst du nicht nur
Adressen nebenbei berechnen, sondern auch bis zu typisch 6 Integer
Operationen
nebenläufig erledigen.. ähnlich bei Floating Point Operationen.
Die neueste Alder Lake CPU hat etwa 12 "Execution Ports", die
parallel arbeiten.
Ich kriege eine Kriese, wenn ich immer lese, wie mies angeblich
die x86 Architektur ist.
Ich frage mich da halt, warum dann die x86 CPU alle
anderen angeblich so überlegenen Architekturen verdrängt hat.
Und nicht nur im Billigsegment, sondern auch in Bereichen wo Kosten
keine wichtige Rolle spielen.
udok schrieb:> Ich frage mich da halt, warum dann die x86 CPU alle> anderen angeblich so überlegenen Architekturen verdrängt hat.
Geballte Marktmacht (Intel + Microsoft), und Gatter (die billig geworden
sind) an die Front geschmissen, damit man RISC ausbooten kann.
Erst, als der Strom nicht mehr aus der Steckdose kam (Mobiltelefon), hat
sich das gerächt. In einem ARM wirst du auch keine Segmentregister
finden. ;-)
udok schrieb:> Ich kriege eine Kriese, wenn ich immer lese, wie mies angeblich> die x86 Architektur ist.
Im Thread geht es ursprünglich darum, wie grossartig der 286 gewesen
sei. Nur gab es damals etliche Alternativen. Die Eleganz der Architektur
wars nicht, weshalb x86 siegte.
AMD hat Intel später gezeigt, wo der Bartel den Most holt, und wurde von
Microsoft dabei unterstützt. Die 64-Bit x86 Architektur ist weit besser.
(prx) A. K. schrieb:> und wurde von Microsoft dabei unterstützt
Naja. Microsoft hat sein 64-bit-Windows nur "beta" genannt, bis Intel
auch den Vorsprung aufgeholt hatte … so sehr dolle war die Unterstützung
dann wohl nicht. ;-) (Ich hatte just zu der Zeit hier ein wenig mit AMD
zu tun.)
Aber vermutlich war es Microsoft halt auch leid, bis zum
St.-Nimmerleins-Tag auf den Itanium zu warten.
(prx) A. K. schrieb:> Jörg W. schrieb:>> In einem ARM wirst du auch keine Segmentregister finden. ;-)>> Dafür aber bei IBMs POWER.
Was ja auch keine schlechte Architektur ist. Dürfte mittlerweile die
ziemlich einzig überlebende big-endian sein, oder?
Jörg W. schrieb:> Naja. Microsoft hat sein 64-bit-Windows nur "beta" genannt, bis Intel> auch den Vorsprung aufgeholt hatte … so sehr dolle war die Unterstützung> dann wohl nicht. ;-)
So wars gemeint: Soweit ich weiss hat Microsoft klargestellt, dass sie
nur eine 64-Bit x86 Version unterstützen. Weshalb Intel gezwungen war,
AMD64 zu übernehmen, statt eigene Brötchen zu backen. Ohnehin hatte
Intel eigentlich überhaupt keine Lust darauf, x86 jenseits der 32 Bit zu
hieven, wollte konkurrenzfrei IA64 verkaufen.
Jörg W. schrieb:> Was ja auch keine schlechte Architektur ist. Dürfte mittlerweile die> ziemlich einzig überlebende big-endian sein, oder?
IBMs Mainframe-Architektur gibts auch noch, wie auch immer die Kisten
jetzt gerade heissen.
RISC war doch schon immer ein theoretisches Konzept aus dem
Elfenbeinturm.
Das konnte sich in den 90'ern nicht durchsetzen, weil es viel zu
verschwenderisch mit dem RAM umging.
Heute kann es sich nicht durchsetzen, weil es viel zu verschwenderisch
mit
dem Cache und damit mit dem Akku umgeht (Cache bestimmt den
Stromverbrauch wesentlich mit).
Klar ist es für den lernfaulen Studenten im ersten Abschnitt ein
verlockend einfaches Konzept.. Er muss sich nur 32 Befehle merken.
Nur die Welt ist eben komplizierter, und die Nachteile sind gravierend,
abseits der Uni, die halt ein einfaches CPU-Modell für die Lehre
braucht.
Und mit geballter Marktmacht kannst du das Einknicken sämtlicher
anderer CPU's nicht argumentieren. Die waren schlichtweg nicht
konkurrenzfähig, und sind alle mit dem x64 technisch nicht mitgekommen.
Vielleicht mit Ausnahme der IBM Power Architektur.
Geradem im Supercomputerbereich wären die sonst noch da.
Da gibt es aber abseits von x86 nur mehr die Cray mit ihren
superskalaren
Prozessoren. Und inzwischen auch wieder Spezialentwicklungen aus Japan
und China.
Und ARM ist doch auch eine furchtbare Krücke mit inkompatiblen
Befehlssätzen, die inzwischen ähnlich kompliziert wie der von Intel ist.
ARM ist auch nur stromsparender, solange die CPUs in einem auf
stromsparend optimierten Halbleiterprozess gefertigt werden.
Wenn die in einem auf Leistung optimierten Prozess gefertigt werden,
schaut es anders aus.
(prx) A. K. schrieb:>> Was ja auch keine schlechte Architektur ist. Dürfte mittlerweile die>> ziemlich einzig überlebende big-endian sein, oder?>> IBMs Mainframe-Architektur gibts auch noch, wie auch immer die Kisten> jetzt gerade heissen.
Für den Programmierer ist es ein Segen.
Und auch ein wenig ironisch.
Jetzt, wo sie CPU unabhängig programmieren gelernt haben,
ist es nicht mehr notwendig.
Eine 128 Bit CPU wird ja in den nächsten Jahren nicht kommen..
Ich wünsche eine gute Nacht,
Udo
udok schrieb:> Und ARM ist doch auch eine furchtbare Krücke mit inkompatiblen> Befehlssätzen, die inzwischen ähnlich kompliziert wie der von Intel ist.
Jau, das Zeug wächst und gedeiht wie Unkraut. Allerdings hat ARM mit v8
einen klaren Schnitt gemacht und Altlasten über Bord geworfen. Und ganz
so schlecht wie vor dir dargestellt steht ARM in Form der
Apple-Implementierung nicht da.
Der Einfluss von Befehlssatz-Architekturen hat nachgelassen. Man kann
heute derart viel Transistoren da reinschmeissen, dass das weniger
relavant ist. War früher mal anders.
udok schrieb:> Eine 128 Bit CPU wird ja in den nächsten Jahren nicht kommen..
Bring dich mal auf einen aktuellen Wissensstand...
In meinem Laptop sind es 512 Bits. ;-)
OK, ob das Zukunft hat, oder Torvalds Fluch stärker war, ist noch offen.
Die 12er hats ja wieder abgeschaltet. Intels On-Off-Beziehung.
udok schrieb:> ARM ist auch nur stromsparender, solange die CPUs in einem auf> stromsparend optimierten Halbleiterprozess gefertigt werden
Das verwechselst du jetzt mit AVR. Der ist auch nicht "optimiert",
sondern einfach so grob, dass die Leckströme noch keine große Rolle
gespielt haben.
Die steigenden Energiekosten dürften aber auch x86/amd64 allmählich alt
aussehen lassen. Kann mir gut vorstellen, dass die in 10 Jahren selbst
in Servern langsam selten werden, denn die laufen 24x7, und Kosten
spielen da auch 'ne Rolle. Apple zeigt ja gerade, wie das auf einem PC
aussieht.
Jörg W. schrieb:> Kann mir gut vorstellen, dass die in 10 Jahren selbst> in Servern langsam selten werden
Dieser Trend zeichnet sich deutlich ab. Grossclouder wie Amazon
entwickeln ja schon ihre eigenen ARM-Prozessoren. Wobei nicht die
Performance-pro-Thread im Vordergrund steht, sondern die
Performance-pro-Watt.
Allerdings muss das nicht immer von Erfolg gekrönt sein. Die
Apple-Epigonen bei Samsung haben neben manch anderem auch dies
nachzumachen versucht, mit den eigenen Mongoose Cores. Um sie nach
lauter Misserfolgen wieder einzustellen, weil sie effektiv nicht einmal
Qualcomm schlagen konnten, von Apple ganz zu schweigen.
Rolf M. schrieb:> Beim 286er vielleicht noch, aber spätestens beim 386er mit seinem> virtual 8086 mode wäre das problemlos gegangen. Genau dafür hat Intel> den ja eingeführt. Unter Windows hat man das ja dann auch gemacht. Warum> nicht unter DOS?
Weil du das alles mit Windows 3.x bekommen hast.
Es war zu dem Zeitpunkt schon längst abzusehen, dass der Zug für reines
DOS abgefahren ist und Windows die Zukunft auf Microsoft Seite ist.
Und damit du auch DOS Programme im Protected Mode ausführen kannst, gab
es dafür den DPMI Standard.
>> Weiterentwicklungen gab es deswegen in Form von zuerst EMS, dann XMS>> gefolgt von DPMI Dos Extendern wovon Windows 3.x im Standard Mode und>> Extended Mode einer ist.>> DOS-Extender sind nur nicht Teil von DOS, sondern auch wieder nur> Work-Arounds, um an DOS vorbei das zu machen, was es eigentlich selbst> hätte können sollen.
Das kann es aber nicht. Da, wie ich dir bereits sagte, DOS eine
Kombination aus Real Mode DOS Funktionen und Real Mode BIOS Funktionen
ist.
DOS war somit eine Sackgasse und die Zukunft war ein echtes reines
protected mode Betriebssystem, dass du mit der Windows NT Linie auch
bekommen hast.
>> Und das war im Grunde das, was Microsoft machen konnte und auch gemacht>> hat.>> Aber eben in Windows, was eigentlich nur ein graphischer Aufsatz für's> Betriebssystem sein sollte. Das eigentliche Betriebssystem war DOS, und> das konnte davon gar nichts.
Windows NT war kein grafischer Aufsatz mehr.
Das war nur Win3.x, Win9x und Me.
>> Und auf der DOS Schiene machte man mit Windows 95 dann weiter, da damit>> eine bessere DOS Unterstützung möglich war, als mit Windows NT in dem>> BIOS Zugriffe für den Userspace ja nicht mehr erlaubt waren.>> Außerdem war der RAM Bedarf von Win9x geringer.>> Da ist DOS dann aber immer mehr zum Bootloader für Windows verkommen.> Also auch keine Weiterentwicklung mehr.
Die war ja auch nicht mehr nötig.
Da man neue Software gleich für Win9x und NT schrieb.
>> Die DOS Programme diverser Hersteller ruften das BIOS direkt auf und auf>> das hatte Microsoft keinen Einfluss und kann auch nicht umgangen werden.>> Natürlich konnte es das, sogar sehr einfach. Und zahlreiche> DOS-Hilfsprogramme (und Viren) haben das auch getan. Einfach den INT 10h> umbiegen, schon hat man alle BIOS-Aufrufe in der Hand.
Nein, so einfach geht es nicht. Schon gar nicht wenn man im Protected
Mode bleiben will.
Wenn es so einfach wäre, würden die FreeDOS Leute nämlich machen. Siehe:
"Support for UEFI?
FreeDOS 1.3 will not support UEFI-only systems. You will need to
enable "legacy" or "compatibility" mode in your UEFI to emulate a BIOS.
Since Intel plans to end "legacy BIOS" support in their new
platforms by 2020 (in favor of UEFI) users have asked if FreeDOS will be
updated to support UEFI. The short answer is No.
Like any DOS, FreeDOS makes use of BIOS for video and disk
functions. But even if these functions were moved into the FreeDOS
kernel, note that there are many, many existing DOS programs that
directly use BIOS to work. FreeDOS cannot "emulate" BIOS for these
programs."
http://wiki.freedos.org/wiki/index.php/Releases/1.3#Support_for_UEFI.3F
Das BIOS kannst du also auf echter Hardware nicht emulieren.
>> Nur bei DOS geht das halt nicht, weil die Anwendungen direkt die>> Hardware aufrufen.>> Direkte Hardware-Zugriffe sind natürlich was anderes. Ich hab aber auch> nirgends geschrieben, dass DOS die alle abfangen sollte.
Tja, dummerweise muss der PC Input und Output Anfrage und Befehle
durchführen können.
Und wenn die Anwendung ins VGA RAM schreiben will, dann kannst du das
auch nicht abfangen.
>> Ich denke, ein Problem war gerade hier der Speicher. Ich hatte auf> meinem 486er damals OS/2, aber die zu der Zeit üblichen 4 MB reichten> nicht, um damit vernünftig zu arbeiten - schon gar nicht, wenn man das> enthaltene DOS/Windows auch noch mit laufen ließ.
Das Speicherproblem kam noch dazu. War aber nicht die Grundursache.
Wer direkt für Windows entwickelte, deckte beide Märkte ab. Windows und
OS/2. Damit gab es keinen Grund mehr direkt für OS/2 zu entwickeln,
diese Kosten konnte man sich sparen und mangels Anwendungen verlor dann
IBM zunehmend gegen MS.
>>>>> Gleichzeitig setzte Microsoft über 200 Programmierer an um Windows NT>>>> aus dem Boden zu stampfen und Microsoft setzte bei diesem gleich von>>>> Anfang an auf Prozessorarchitekturunabhängigkeit und beim PC auf den>>>> 386er.>>>>>> NT spielte aber auf Heim-PCs keine Rolle. Das war für Workstations>>> gemacht.>>>> Wenn du das Geld hattest, konntest du es kaufen.>> Ja, aber da war das mit der DOS-Kompatibilität auch nicht gegeben.
Und? Wenn du ein vollwertiges Proteced Mode OS haben willst, was du oben
ja ständig aus DOS machen willst und an DOS bemängelst, dann geht das
halt nicht anders.
> Naja, NT wäre damals einfach nicht dafür geeignet gewesen.
Anfangs nicht. Aber Windows 2000 war dafür geeignet. Und möglicherweise
auch schon Windows NT 4.0. Denn DirectX 3.0 gab es für NT 4.0.
> Das ist dann> eben wie oben bei OS/2.
OS/2 bot bezüglich Spiele gar nichts. Nichtmal so etwas, wie es das bei
Windows 3.1 mit WinG gab.
https://de.wikipedia.org/wiki/WinG> Was will ich mit einem Betriebssystem, das teuer> ist, zu vielen DOS-Anwendungen nicht kompatibel und das viel teuren> Speicher braucht?
Windows NT war zum Arbeiten sehr gut geeignet, denn es war stabil und
bot präemptives Multitasking, Speicherschutz und Multiuserbetrieb.
Windows 9x bot nur präemptives Multitasking und eingeschränkten
Speicherschutz, nicht aber die anderen beiden Dinge. Und DOS bot nichts
davon.
>> Das kann man doch!>> Dafür gab es die DOS Extender.>> Die sind wie gesagt nicht Teil von DOS. Klar, irgendwann hat jemand> diese Unzulänglichkeiten von DOS erkannt und ist dann eingesprungen, um> diese zu umgehen.
Dieser Jemand war Microsoft, denn der DPMI Standard ist von MS.
>> Jedes Spiel das beim Start "DOS/4GW" und ähnliches anzeigt macht genau>> das.>> Und Windows 3.x war selbst ein DPMI DOS Extender.>>>> Und Win32 wurde nachgeschoben. Du hast das also alles bekommen.>> Microsoft hat die DOS User mit Windows 9x sogar noch ziemlich lange>> unterstützt.>> Der Punkt ist, dass das alles eben nicht Teil des Betriebssystems war,> sondern Teil der graphischen Benutzeroberfläche.
Damit scheinst du ein Problem zu haben, nicht ich.
Und wenn man dir sagt, dann nimm Windows NT, dann moserst du rum, weil
das kein DOS mehr ist. Aber genau so hätte ein DOS ausgesehen, wenn man
es entsprechend erweitert hätte.
Die DOS Anwendungen hätte man in eine Virtual 8086 Umgebung verfrachtet,
während der Kernel im Protected Mode blieb.
Wegen den BIOS Funktionen hätte man sich bezüglich dem V86 Mode was
ausdenken müssen und manches hätte schlichtweg gar nicht mehr
funktioniert.
Da hätte man dann eine Emulation wie die DOSBox benötigt.
Tja und all das, mit Ausnahme der DOSBox war eben Windows NT.
Also, wo ist jetzt dein Problem?
Du verlangst irgendwie aus viereckigen Türen runde Türen zu machen, ohne
aber die vier Ecken zu verlieren und das geht halt nicht.
Akzeptiere es einfach, DOS war am Ende seiner Fahnenstange.
>>> Und>>> dass es ein paar mehr Treiber gibt als nur für Festplatte, Tastatur und>>> die Grafikkarte (die größtenteils eh nicht von DOS, sondern vom BIOS>>> kamen).>>>> Und was soll das bringen unter DOS?>> Ich kann mich noch gut an Probleme mit nicht unterstützter Hardware> erinnern, weil damals jedes Programm jede Peripherie einzeln> unterstützen musste, damit es ging.
Ja, weil die Anwendungen direkt auf die HW zugreifen konnten und dies
auch taten. Da wäre jede Treiberschnittstelle im Weg gewesen, weil man
die dann erst einmal wegräumen hätte müssen, damit die alten Anwendungen
laufen.
>> Bei DOS haben die Anwendungen die Hardware selber direkt angesprochen.>> Ja, weil sie es mussten, da in DOS ein Treibermodell dafür gefehlt hat.> Und das war immer recht problematisch. Es ist z.B. der Grund, weshalb> jedes Spiel seine eigene Treibersammlung für Soundkarten mitbringen> musste. Und weshalb sehr viele Soundkarten-Hersteller ihre Karten> SoundBlaster-kompatibel gemacht haben, damit sie auch mit Programmen> funktionieren, die nicht so üppig mit eigenen Treibern ausgestattet> sind. Hätte DOS dafür Treiber geboten, dann wäre das alles nicht nötig> gewesen.
Es kann aber nur immer ein Treiber auf die HW zugreifen.
Hätte man das also später eingeführt, dann hätten alte Spiele, die die
HW noch direkt angesprochen haben, nicht mehr funktioniert, solange
diese Treiberschnittstelle im Weg war.
Außerdem war der Zug, als die Soundkarten rauskamen, für DOS ohnehin
schon abgefahren.
Das Ziel war mit Windows klar.
>> Und das nachträglich einzubauen hätte auch nicht viel Sinn gemacht, da>> DOS es Programmen erlaubte im Real Mode zu laufen, womit sie alles>> hätten machen können.>> Aber dann eben mit eigenem Treiber für jede einzelne> Hardware-Komponente.
Und es hätte geknallt.
Du wolltest bspw. Multitasking in DOS.
Z.B. um eine Audiodatei abzuspielen.
Das Programm, dass die abspielt, hätte dann vielleicht diese DOS
Treiberschnittstelle verwendet, nicht aber das alte Spiel, das du auch
noch starten hättest wollen.
Und schon hätte man einen Konflikt, da sowohl das Spiel, als auch das
Musikprogramm bzw. die Treiberschnittstelle die Soundkarte für sich in
Beschlag nehmen hätten wollen.
Das das nicht funktioniert ist auch der Grund, warum man da nichts mehr
weiter gemacht hat.
Die Zukunft war Windows, da konnte man das schön sauber implementieren.
Und an Windows 95 kannst du übrigens sehen, warum du Windows 95 in den
richtigen DOS Modus schalten musst, wenn du ein Spiel mit eigener
Soundunterstützung spielen willst.
> Und was heißt "nachträglich"? Das wäre einfach Teil> der Weiterentwicklung von DOS gewesen. Stattdessen hat man das halt dann> bei Windows "nachträglich" getan.
Bei Windows hat man es gleich von Anfang eingebaut.
>> Die Entwicklung nach der du dich sehnst hat im Rahmen von Windows>> stattgefunden.>> Genau, und die hätte im Rahmen von DOS stattfinden sollen.
Wozu? Was hätte es gebracht?
Die Kunden wollten Fenster und Buttons und keine Kommandozeile.
> Denn es gibt> keinen erkennbaren Grund, weshalb für den Betrieb einer Soundkarte eine> graphische Benutzeroberfläche erforderlich sein sollte. Also weshalb> diese beiden Dinge so fest koppeln?
Es ist zwar richtig, dass man für den Betrieb einer SOundkarte keine
grafische Oberfläche bräuchte, aber es gab alte DOS Spiele gab, die die
Soundkarte auch nutzen wollten und die hätten dann nicht mehr
funktioniert, wenn DOS mit einer eigenen Treiberschnittstelle für Sound
die Soundkarte in Beschlag genommen hätte.
Man muss doch eigentlich froh sein, dass Microsoft mit Windows NT, den
ganzen alten Ballast abgeworfen hat und du willst ihn wieder haben.
rbx schrieb:> Man konnte den Commodore C16 einfach an irgendeinen Fernseher> anstöpseln, und BASIC lernen. Ein kleiner zusätzlicher Mathe-Kursus> hätte vermutlich auch gar nicht geschadet..
Die ersten IBM PCs hatten wie der C64 auch, einen BASIC Interpreter
direkt im ROM integriert und bootete auch den BASIC Interpreter, wenn
kein DOS gebootet wurde.
Lediglich die kompatiblen hatten das aus Copyright Gründen nicht.
Für die gab es dann GW-Basic als zu MS-DOS mitgelieferte EXE Datei und
später wurde es dann durch QBasic ersetzt.
D.h. auf dem IBM war das genau so. Rechner einschalten und man konnte
direkt loslegen und in Basic programmieren.
Hier sieht man es, booten direkt ins BASIC ROM:
https://youtu.be/LwG-HuezJxY?t=818
(prx) A. K. schrieb:> Die RISCs liefen ebenso den Rang ab, wie der ungefähr parallel> zum 68060 aufkommende Pentium Pro, der aufgrund des Marktes mit mehr> Geld gesegnet war.
Der Pentium Pro war bereits ein RISC und verwendete µOps um die x86 CISC
Befehle nachzubilden.
(prx) A. K. schrieb:> Ein guter Wurf war 386 dank des 32-Bit Modus und der damit> einhergehenden vernünftigen Adressierbarkeit grösserer Datenmengen. Und> der Pentium Pro (P6), der aufgrund der radikal anderen Mikroarchitektur> den Rückstand zu den damaligen RISCs einholte.
Da bin ich ganz deiner Meinung.
Der nächste Sprung kam dann mit dem x86-64, der bot dann 64 Bit und
wesentlich mehr Register.
Georg A. schrieb:> Aber es gab alle ~10 Jahre so "Knaller" von Intel.>> Anfang 80er: iAPX432, so sicher, dass er zu langsam war.> Anfang 90er: i860, so superskalar, dass kein Compiler ihn vernünftig> ausnutzen konnte.> Anfang 2000er: Itanium, so VLIW, dass kein Compiler ihn vernünftig> ausnutzen konnte.> Anfang 2010: Larabee, wohl einfach so gefloppt.
In der Liste fehlt noch der Pentium 4 mit seiner extrem langen Pipeline.
Fpgakuechle K. schrieb:> Ein weiteress Indiz für die 'Hirnlosigkeit' des i286 ist seine> endemische Ausbreitung in einer einzigen, allerdings recht geräumigen,> Nische - den IBM PC.>> Den 68000 dagegen findet man in mehreren Computer-/Workstationsystemen,> Messtechnik, Spielkonsolen, Arcade games und als embedded devices> (Postscript-drucker etc). Sogar eine strahlungsgehärtetet Variante fürs> Space shuttle gibt es.
Im Space Shuttle steckt der 8086.
https://www.heise.de/newsticker/meldung/NASA-sucht-im-Internet-nach-uralten-Chips-59066.html
Und auf der ISS ist es der 80386 als Hauptcomputer.
udok schrieb:> Im Nachhinein lässt sich immer leicht gescheit daherreden.
Ich würde Dir zustimmen, wenn auf allen gängigen Architekturen solche
Klimmzüge notwendig gewesen wären. Aber das war eben nicht der Fall.
(prx) A. K. schrieb:> Aber wenn man bereits auf 68000 in einem 32-Bit> Adress- und Datenmodell gearbeitet hatte, war die Migration zu 286 ein> grosser Schritt rückwärts.
Ja, ich kann mich noch gut erinnern, wie mir auf MS-DOS portierter Code
um die Ohren geflogen ist, weil einige malloc()s die Grenze (64kB abzgl.
etwas Overhead) sprengten.
Nano schrieb:> Anfangs nicht. Aber Windows 2000 war dafür geeignet. Und möglicherweise> auch schon Windows NT 4.0. Denn DirectX 3.0 gab es für NT 4.0.
Korrekt, Half-Life/Counter-Strike lief bei mir unter NT 4.0.
Nano schrieb:> Die ersten IBM PCs hatten wie der C64 auch, einen BASIC Interpreter> direkt im ROM integriert und bootete auch den BASIC Interpreter, wenn> kein DOS gebootet wurde.
Sowas ist mir auch später nochmal begegnet, müsste ein 486er gewesen
sein, allerdings kein IBM. Ich war dementsprechend perplex, leider
fehlten damals noch die allgegenwärtigen Digitalkameras.
(prx) A. K. schrieb:> udok schrieb:>> Ich kriege eine Kriese, wenn ich immer lese, wie mies angeblich>> die x86 Architektur ist.>> Im Thread geht es ursprünglich darum, wie grossartig der 286 gewesen> sei.
Nein.
Ich habe lediglich nach eurer Meinung gefragt ob es ein guter Wurf im
Angesicht der damaligen Zeit war um die Geburtstagsparty auch mit etwas
Inhalt zu füllen.
Für meine Familie war es der erste PC, ein 386 hätte damals noch ca.
6000 DM gekostet und wäre viel zu teuer gewesen.
> AMD hat Intel später gezeigt, wo der Bartel den Most holt, und wurde von> Microsoft dabei unterstützt. Die 64-Bit x86 Architektur ist weit besser.
Als der Itanium, Ja. Anderseits kann man es Intel nicht verübeln, dass
sie es mit VLIW probiert haben. Jetzt ist man schlauer und weiß, dass
man an den Compilern scheitert.
Und für uns war es gut, dass es sich so herauskristallisiert hat, denn
mit dem Itanium hätte Intel ansonsten jetzt eine Monopolstellung, wenn
er wesentlich schneller und besser gewesen wäre und sich auch im
Consumermarkt später durchgesetzt hätte, wie es Anfangs von Intel
geplant war.
Aber wenn man schon die x86 Architektur mit dem Rest vergleicht, dann
könnte man auch mal die Frage stellen, warum der PowerPC ihn nicht
übertrumpft hat. Er war RISC und bei dem hat man alle alten Zöpfe
abgeschnitten und das gute bekannte behalten und eingearbeitet.
AMD + Intel waren bei diesem Rennen jedenfalls besser als IBM, Motorola
und Apple zusammen.
Der 68k hat ab dem 386er verloren.
udok schrieb:> RISC war doch schon immer ein theoretisches Konzept aus dem> Elfenbeinturm.>> Das konnte sich in den 90'ern nicht durchsetzen, weil es viel zu> verschwenderisch mit dem RAM umging.
Wurde der Acorn Archimedes eigentlich groß in Deutschland verkauft?
Ich kann mich jedenfalls nicht daran erinnern, dass der hier angeboten
wurde.
Es gab die typischen Homecomputer, also C64, Amiga, Atari die IBM
kompatiblen und Apple. Mehr gab's hier nicht.
Gut, etwas später kam noch kurzzeitig der DEC Alpha ins Rennen, spielte
aber letzten Endes in der Masse und Zuhause keine Rolle.
Nano schrieb:> Der 68k hat ab dem 386er verloren.
Wer hat eigentlich diese total durchgeknallten doppelt indirekten
Adressmodi ab dem 68020 eingebaut? Dagegen ist ja das A20-Gate noch zu
Ende gedacht...
Hmmm schrieb:> > Nano schrieb:>> Anfangs nicht. Aber Windows 2000 war dafür geeignet. Und möglicherweise>> auch schon Windows NT 4.0. Denn DirectX 3.0 gab es für NT 4.0.>> Korrekt, Half-Life/Counter-Strike lief bei mir unter NT 4.0.
Danke. Die ganzen 3dFX Spiele mit Glide Schnittselle müssten auch noch
gut unter Windows NT 4.0 laufen. Ebenso alles was OpenGL verwendet.
> Nano schrieb:>> Die ersten IBM PCs hatten wie der C64 auch, einen BASIC Interpreter>> direkt im ROM integriert und bootete auch den BASIC Interpreter, wenn>> kein DOS gebootet wurde.>> Sowas ist mir auch später nochmal begegnet, müsste ein 486er gewesen> sein, allerdings kein IBM. Ich war dementsprechend perplex, leider> fehlten damals noch die allgegenwärtigen Digitalkameras.
Das höre ich jetzt zum ersten mal, dass es auch 486er gegebenen haben
soll wo das ging.
Das war sicherlich eine Speziallösung.
Man konnte ja mit exe2bin kompilierten Code für ROM Bausteine bereit
machen und dann mit einem modifizierten ROM Bausteni diesen Code booten.
Siehe:
https://de.wikipedia.org/wiki/EXE2BIN
Nano schrieb:> Aber wenn man schon die x86 Architektur mit dem Rest vergleicht, dann> könnte man auch mal die Frage stellen, warum der PowerPC ihn nicht> übertrumpft hat. Er war RISC und bei dem hat man alle alten Zöpfe> abgeschnitten und das gute bekannte behalten und eingearbeitet.
In der x86-Welt hat man sich mit dem Abschneiden alter Zöpfe
traditionell schwergetan.
Apple hat einfach eine Emulation eingebaut, und wer mehr Performance
wollte, durfte den Softwarefirmen nochmal Umsatz bescheren. Dort wurden
auch rund 10 Jahre lang PPCs verbaut.
Ansonsten wurden PPCs an recht vielen Stellen verwendet, ohne dass man
viel davon mitbekommen hat: Sat-Receiver (dbox2), Spieleconsolen (z.B.
Wii), Luft- und Raumfahrt etc.
Nano schrieb:> Der 68k hat ab dem 386er verloren.
Technisch waren die neueren 68k-Prozessoren noch eine Weile gut dabei,
aber der Massenmarkt hatte sich mit dem Ableben von Atari und Commodore
erledigt, und Apple ist nach dem 68040 auf PPCs umgestiegen.
Nano schrieb:> Wurde der Acorn Archimedes eigentlich groß in Deutschland verkauft?
Ich glaube, mir ist mal bei Conrad einer begegnet, aber wirklich
verbreitet waren die nicht.
Nano schrieb:> Es gab die typischen Homecomputer, also C64, Amiga, Atari die IBM> kompatiblen und Apple. Mehr gab's hier nicht.
Da fehlen aber noch einige.
Sinclair ZX81 und ZX Spectrum (der QL mit 68008 hat sich hier nie
durchgesetzt), Atari 400/800, Apple II, TRS-80, Amstrad/Schneider
CPC464.
VC20, C16, Plus/4 und C128 zähle ich einfach mal zur C64-Kategorie.
Nano schrieb:> Das höre ich jetzt zum ersten mal, dass es auch 486er gegebenen haben> soll wo das ging.>> Das war sicherlich eine Speziallösung.
Das war ein relativ normales AT-Mainboard, aber an Hersteller und BIOS
kann ich mich nicht mehr erinnern.
Georg A. schrieb:> Nano schrieb:>> Der 68k hat ab dem 386er verloren.>> Wer hat eigentlich diese total durchgeknallten doppelt indirekten> Adressmodi ab dem 68020 eingebaut? Dagegen ist ja das A20-Gate noch zu> Ende gedacht...
Das lag in der Luft. Es gab damals zwei Entwicklungsrichtungen
gleichzeitig. Einerseits immer komplexer wie bei 68020: NEC V70,
NS32000, beide inspiriert von der noch erfolgreichen DEC VAX, Intel 432.
Andererseits die Idee der Vereinfachung durch RISC.
Dass hohe Komplexität mehr Problem als Lösung war, eine Sackgasse sein
konnte, das musste man erst einmal lernen. IBMs John Cocke hatte
Redeverbot, seine Erfahrungen blieben lange Zeit Firmengeheimnis. DEC
ging an der Komplexität fast zugrunde. Auch ich brauchte eine Weile um
das zu erkennen. Der erste Kontakt mit ARM in den 80ern war sehr
inspirierend.
Und manche lern(t)en es nie. :-)
udok schrieb:> Auf jeder Intel CPU der letzten 10 Jahre kannst du nicht nur> Adressen nebenbei berechnen, sondern auch bis zu typisch 6 Integer> Operationen>> Ich kriege eine Kriese, wenn ich immer lese, wie mies angeblich> die x86 Architektur ist.
Die intel-CPUs der letzten 10 Jahre haben keine x86 Architektur. Intel
hat seine Architektur schrittweise (MME,SSE) zur heutigrn geändert.
> Und nicht nur im Billigsegment, sondern auch in Bereichen wo Kosten> keine wichtige Rolle spielen.
Da wird erst reicht keine x86 eingesetzt. (Beschleinigerkarten, FPGA,
ASIC).
Linus hat m.e. den support für MMU-lose CPU's wie den 286 schon vor
Jahrzehnten aus dem Haupt-Repo rausgeschmissen. Den für 386 auch, 2012:
https://www.heise.de/newsticker/meldung/Linux-laeuft-in-Zukunft-nicht-mehr-auf-dem-i386-1767747.html
Nano schrieb:> Es gab die typischen Homecomputer, also C64, Amiga, Atari die IBM> kompatiblen und Apple.
Typische Homecomputer sind 8-bit; Amiga, ST auf 86000 sind damit PC.
Bitte lass diese Taschenspielertricks, Äpffel und Birnen in einen
Mörster zu werfen und Mus daraus zu stampfen. Damit runinierst du nur
den Rest deine Glaubwürdigkeit.
Auch IBM-kompatible werden daher nicht zu dem Home-computer gezählt,
vielleicht der Schneider-PC.
Fpgakuechle K. schrieb:> Linus hat m.e. den support für MMU-lose CPU's wie den 286 schon vor> Jahrzehnten aus dem Haupt-Repo rausgeschmissen
286 wurde m.W. nie von Linux unterstützt. Er hatte ja auf 386 angefangen
und 16-Bit 286 passt überhaupt nicht ins Schema.
Dafür gab es früher Unixe, wie Microport Unix und Microsoft Xenix.
Fpgakuechle K. schrieb:> Die intel-CPUs der letzten 10 Jahre haben keine x86 Architektur. Intel> hat seine Architektur schrittweise (MME,SSE) zur heutigrn geändert.
Ein gängiger Name ist x86-64. Der Schritt zu 64-Bit ist nicht von Intel,
sondern von AMD, und dieser Name wurde anfangs gelegentlich von AMD
selbst verwendet.
Was sie nicht haben ist eine 8086-Architektur. Bezeichnungen wie x86
steht für alles, was davon abstammt, wie erweitert auch immer es ist.
Nano schrieb:> Aber wenn man schon die x86 Architektur mit dem Rest vergleicht, dann> könnte man auch mal die Frage stellen, warum der PowerPC ihn nicht> übertrumpft hat. Er war RISC und bei dem hat man alle alten Zöpfe> abgeschnitten und das gute bekannte behalten und eingearbeitet.
Der Markt wählt nicht immer aktuell technisch Beste. Hier war es die
bereits bestehende grosse x86-Basis, die den Weg bestimmte. Dadurch
hatte Intel genug Geld, das sie in die Oberkante der Entwicklung stecken
konnten, sowohl bei der Implementierung der Architektur, als auch der
Fertigungstechnik.
In genau diese Falle ist Intel ja später selbst gestolpert. Als sie mit
IA64 von x86 weg wollten, ins proprietäre Monopol. Und AMD die Chance
sah, Intel mit den eigenen Waffen zu schlagen, indem sie x86-64 aka
AMD64 definierten, und so dem Markt die Chance gaben, bei x86 zu
bleiben. Die gegenüber Intels Pentium 4 mindestens konkurrenzfähige,
eher überlegene Hardware-Basis hatten sie mit Opteron/Athlon64 auch. Der
Rest ist Geschichte.
Apples Markt war finanziell nicht gross genug, um dauerhaft eine
vergleichbare Entwicklung durch Motorola zu tragen, und IBMs Prozessoren
liefen meist in eine für PC-artige Geräte unpassende Richtung.
(prx) A. K. schrieb:> Ganz zu schweigen vom nächsten logischen Schritt Intels, dem iAPX 432.> Ein grosser Wurf in die falsche Richtung. ;-)
Objektorientiert halt.
Da hat schon die Hardware die Verlangsamung gebracht, die man heute
mühsam per Software nachbildet, damit auch bei 3GHz ein Programm
garantiert nicht für den Benutzer flüssiger abläuft als unter 3MHz.
Wie sonst sollte man den Benutzer zu immer schnellerem Hardwareneukauf
zwingen, wenn zum Briefeschreiben schon der alte Rechner reichte.
(prx) A. K. schrieb:> 286 wurde m.W. nie von Linux unterstützt. Er hatte ja auf 386 angefangen> und 16-Bit 286 passt überhaupt nicht ins Schema.
Linux läuft nur auf CPUs mit paged MMU, der 286er kann nur Segmente.
udok schrieb:> Das konnte sich in den 90'ern nicht durchsetzen, weil es viel zu> verschwenderisch mit dem RAM umging.
Ich denke, es konnte sich nicht durchsetzen, weil kein DOS/Windows drauf
lief.
Bei den Highend-Workstations war es lange gut im Boot. Allerdings hat
war durch die schiere Masse dann mit Pentium/aufwärts halt aus der
PC-Ecke ein besseres Preis-Leistungs-Verhältnis zu haben als im
vergleichsweise geringstückzahligen Workstation- und Server-Bereich mit
deren speziellen RISC-CPUs. Spätestens, nachdem die Strukturen so klein
geworden sind, dass man N Kerne auf einen Chip bekam, war auch die noch
verbliebene Domäne vieler möglicher paralleler CPUs bei den reinen
Workstation-RISC-CPUs weg, und es hatte mehr Sinn, Solaris auf einem
x86/amd64 zu betreiben als auf 'ner vergleichsweise teuren UltraSPARC
(wobei Oracle nach wie vor UltraSPARC-Server baut).
Auf der anderen Seite hat ARM verstanden, dass die geringere Codedichte
von RISC ein Thema ist und dem mit Thumb den Kampf erfolgreich ansagen
können, wobei es hier nicht nur die Speichergröße selbst ist, sondern
auch der relativ bessere Speicherdurchsatz, wenn man (Cortex-M) aus
einem Flash arbeiten möchte, der letztlich den Flaschenhals in so einem
System bildet.
Russenhocke schrieb:> Linux läuft nur auf CPUs mit paged MMU, der 286er kann nur Segmente.
Nicht ganz:
https://github.com/jbruchon/elks
Wer also tatsächlich mal Linux-like auf einem 8086 oder '286 sowas haben
möchte - nur zu.
Und natürlich gibt es immer noch uCLinux, das ebenfalls ohne MMU
auskommt, m.W. aber nicht auf 8086 oder -286 portiert wurde/wird.
Übrigens hat IBM nur eine einzige Maschine mit 8086 gebaut, das PS/2
Model 25.
Fpgakuechle K. schrieb:> Typische Homecomputer sind 8-bit; Amiga, ST auf 86000 sind damit PC.
Dummerweise lautete der Werbeslogan für den Apple IIe Anfang der '80er
Jahre "Apple - The Personal Computer". IBM hatte da noch nix auf dem
Markt, was sie PC hätten nennen können.
Die deutsche Übersetzung war damals übrigens noch "Der persönliche
Computer". Nicht "der Personal-Computer", im Sinne von PC für's Gesocks,
Workstations für die Elite.
MaWin schrieb:> Wie sonst sollte man den Benutzer zu immer schnellerem Hardwareneukauf> zwingen, wenn zum Briefeschreiben schon der alte Rechner reichte.
oder zum Telefonieren das alte Motorola Handy:
https://en.wikipedia.org/wiki/Motorola_Razr
Ein Freund meinte mal, dass die Playstation 3 extrem langsame (nervige)
Desktop-Performance hat.
Von der Spielewelt her könnte man durchaus sagen, "vom Ballerspiel zum
HPC" aber dann gibt es ja auch noch Bitcoin und Co..also Geld.
Viele gute Atari-Programmierer hatten oft schon vorher auf einem Apple
programmiert. Zu diesem Punkt fällt mir noch ein: sind wohl Asteroids
oder Tetris etwas aus der Mode gekommen, was? ;)
Ein wichtiges Übergangsmoment war ja wirklich die Abholung in Richtung
16/32 Bit und höhere Taktfrequenzen und noch mehr bzw. größere
Arbeitsspeicher oder Festplatten.
In den Musikzeitschriften tauchte irgendwann der 486 als wichtiges
Kaufargument auf.
Das Highlight für mich (auch viel später noch) waren aber das Internet
und Mame-Roms. Viele gute Hinweise diesbezüglich gab es auch in c't
Heften.
Soul E. schrieb:> Die deutsche Übersetzung war damals übrigens noch "Der persönliche> Computer". Nicht "der Personal-Computer", im Sinne von PC für's Gesocks,> Workstations für die Elite.
Hmm, PC verstehe ich immer noch als persönlichen Computer. Für alles
geeignet, aber eben auch für zuhause.
Ist doch aus dem Englischen übernommen worden. Das Wort "personal" gibt
es im Deutschen eher zufällig mit der Bedeutung "Gesocks" wie es Soul E.
so markig beschreibt. :))
Matthias S. schrieb:> Und natürlich gibt es immer noch uCLinux, das ebenfalls ohne MMU> auskommt,
(OT) Das IMO eine Super-Erfindung ist. Hab damit lange auf dem
Microblaze gearbeitet. Ja, man muss etwas aufpassen, dass man nicht wild
im Speicher rumschmiert, aber das kennt man ja schon vom Atari ST.
Defensives Programmieren eben ;) Aber sonst ist fast alles so wie auf
echtem Linux, das macht die Entwicklung auch für so arme CPUs sehr
einfach.
