1982 erblickte er die Welt und ist somit dieses Jahr 40 Jahre alt geworden. Der Intel 80286 Prozessor. https://de.wikipedia.org/wiki/Intel_80286 https://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.
Nano schrieb: > Ich sprach von Serversoftware. Und hier ist ein Forum, da sprechen viele. > Wir haben ihn noch nicht gefeiert! Also für mich war die Grablegung feierlich genug. Ruhe sanft, ZweiAchtSechs, und werde nicht zum Z0mb1E ;-) https://www.gdata.de/ratgeber/was-ist-eigentlich-ein-zombie-pc
Fpgakuechle K. schrieb: > Nano schrieb: > >> Ich sprach von Serversoftware. > > Und hier ist ein Forum, da sprechen viele. > Lies: https://www.heise.de/forum/heise-online/Kommentare/40-Jahre-80286-Intels-286er-mit-dem-beruechtigten-A20-Gate/Irgendwie-merkwuerdig-der-Artikel/posting-40423614/show/ Nicht von mir, zeigt aber, wie das damals ausgesehen hat und bestätigt das, was ich versuche dir zu erklären.
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.
:
Bearbeitet durch User
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 …
Jörg W. schrieb: > Nein. Er nennt sich auch 16-bit-Prozessor. Erst der 68040 war offiziell > ein 32-bit-Prozessor. https://www.elektronikpraxis.vogel.de/40-jahre-motorola-68000-der-sprung-ins-32-bit-zeitalter-a-864419/ Motorola nannte ihn je nach externes Datenbusbreite 8, 16 und 32 bit: https://datasheetspdf.com/datasheet/68000.html
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
(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.
Beitrag #6983035 wurde von einem Moderator gelöscht.
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. ;-)
:
Bearbeitet durch User
(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.
:
Bearbeitet durch User
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.
Georg A. schrieb: > Anfang 90er: i860, so superskalar, dass kein Compiler ihn vernünftig > ausnutzen konnte. Wo war Moby, als man ihn brauchte?
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).
:
Bearbeitet durch User
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.
Fpgakuechle K. schrieb: > Den 68000 dagegen findet man […] … nicht zu vergessen die legendären ZyXEL-Modems, inklusive Übertaktung. ;-)
Beitrag #6983489 wurde vom Autor gelöscht.
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
:
Bearbeitet durch User
Bernhard K. schrieb: > Der 8086 flog aber auch im Weltall umher: auch der 80386, aber net der 286 - ist halt der Lückenbüßer der IT :-O
(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.
:
Bearbeitet durch User
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.
Jörg W. schrieb: > In einem ARM wirst du auch keine Segmentregister finden. ;-) Dafür aber bei IBMs POWER. Sogar 64-bittig. ;-)
(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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. :-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
(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.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
Jörg W. schrieb: > (wobei Oracle nach wie vor UltraSPARC-Server baut). Aber ohne Ultra, wie dem hier zu entnehmen ist: https://www.oracle.com/de/servers/sparc/
Matthias S. schrieb: > Übrigens hat IBM nur eine einzige Maschine mit 8086 gebaut, das PS/2 > Model 25. ... und Modell 30.
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. :))
(prx) A. K. schrieb: > ... und Modell 30. Ahh, richtig. das hatte ich übersehen. Also 'PS-Halbe Modell 30 = Model 15' :-P
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.