Ich hatte früher mal eine Schaltung mit einem 80186 gemacht - lang ist's her :-) Ist dieser fast-Mikrocontroller eigentlich noch von Bedeutung, wird er in aktuellen Entwicklungen industriell noch eingesetzt?
Bedeutung hat der keine mehr, es gibt ihn auch nicht mehr zu kaufen. Der einzige, der aus dieser Zeit überlebt hat, ist der 8051, dessen Kern aufgepeppt nach wie vor in verschiedenen MC's werkelt. Grüsse
Der Mikrocontroller in den XPorts von Lantronix basiert auf dem 80186. http://www.lantronix.com/device-networking/embedded-device-servers/dstni-lx_dstni-ex.html
Bei der Architektur hab ich nie den Durchblick durch die Speichermodelle gekriegt - SMALL, LARGE, HUGE ?!?
Der Intel 80186 steuert im Airbus A320 einige Ruder an. Der andere Kanal basiert auf dem Motorola 68k. Es sind also noch ein paar von den Teilen unterwegs, und sie scheinen auch zu funktionieren :)
SMALL 64k (ein Segment) für Daten, 64k für Code LARGE Daten theoretisch unbegrenzt, ein Datum aber maximal 64k (ein Segment), Code theoretisch unbegrenzt. HUGE Daten und Programm unbegrenzt. http://www.ousob.com/ng/masm/ng564f9.php
Wird immer noch gern in Sicherheitskritischen Designs benutzt. Da die Eigenschaften (und vor allem Fehler) von Prozessor und Compilern sehr gut Dokumentiert und erprobt. Das erleichtert die Zertifizierung. Wenn ich nicht irre müssten auch noch Tausende in den Signalanlagen der Bahn ihren Dienst tun. Es sei denn die sind inzwischen alle "Verbessert".
Die Nixdorf PWS (Professional Workstation) hatte einen 80186. Das war 1989, als ich damit jobmäßig zu tun hatte. Das war irgendwie ein PC, aber irgendwie auch nicht. Wenn man ein paar Interrupts umbog, konnten darauf sogar einige DOS-Programme laufen.
Oliver Döring schrieb: > Es sind also noch ein paar von den Teilen unterwegs, und sie scheinen > auch zu funktionieren :) Wobei ich diese Teile nicht wirklich als "aktuelle Entwicklungen" bezeichnen würde (O-Ton TO). Auch die Voyager-Sonden funktionieren wohl noch, zumindest teilweise. ;-)
Der Siemens PC-D hatte auch so ein Teil drin, aber mit zusätzlicher externer MMU. Das ekelige am 80186 war halt das komische Segmentsystem.
A. K. schrieb: > Auch die Voyager-Sonden funktionieren wohl > noch, zumindest teilweise. ;-) Ist ja auch nicht leicht, die HW zu updaten...
Christian Berger schrieb: > Das ekelige am 80186 war halt das komische Segmentsystem. Genau, das fand ich ja auch. Wobei man zugeben muss, dass es halt irgend sowas geben muss, wenn man mit einem 16-Bit-Rechner mehr als 64k adressieren will.
Mir hatten damals (wie heute immer noch) 64kb gereicht, deswegen hatte ich es noch relaiv einfach.
Im Cyberhome AD-M212 und AD-M512 DVD Player war übrigens auch einer drin.
Daniel schrieb: > Genau, das fand ich ja auch. Wobei man zugeben muss, dass es halt irgend > sowas geben muss, wenn man mit einem 16-Bit-Rechner mehr als 64k > adressieren will. Aber die Segmente müssen ja nicht an jeder 16-Byte-Grenze neu anfangen dürfen. Man hätte stattdessen konsequent die A16-Leitung als Page-Grenze definieren können. Das kostet aber Ressourcen (welches Programm braucht schon genau 64kB) und war deshalb verpönt. Christian Berger schrieb: > Das ekelige am 80186 war halt das komische Segmentsystem. Und dann das A20 Gate bei dessen Verwendung im PC... ;-)
> Das ekelige am 80186 war halt das komische Segmentsystem.
Du meinst die elegante Art der Speicherverwaltung
von der Burroughs 5500,
mit dem Daten und Code bliebig verschiebbar (relozierbar) sind,
wie es heute jedes Betriebssystem fordert,
was flat memory Dumpfbacken-CPUs wie Motorola 68000 durch
aufwändige und laufzeitintensive Programmierung "Macintosh
R11 R12 R13) erreichen mussten, und trotzdem keine DLL zwischen
verschiedenen Prozessen sharen können weil Datenbasisadresse
verschieden in den Code gepatcht werden müsste, also alles
doppelt geladen werden muß ?
Nicht zu vergessen die elegante Art des bytegenauen gegenseitigen
Speicherschutzes (den andere CPUs nur 4k Block-weise können),
bei dem nur beim Segmentwechsel eine Rechteüberprüfung notwendig
ist (die aber erst die 80286 konnte), statt bei jedem Zugriff ?
Segmentadressierung ist elegant und eine gute Lösung zur
Unterstützung des Beriebssystems, blöderweise hat Intel 1 bit
in den Segmentdeskriptoren vergessen von der Burroughs zu übernehmen,
das dirty bit, das die virtuelle Speicherverwaltung erschwerte
(aber nicht unmöglich machte: Erst alle Segmente r/o anlegen,
beim ersten Schreibzugriff auf ein erlaubtes Segment das woanders
als dirty markieren und auf r/w erlaubt schalten, bloss Microsoft
kam nicht auf die Idee, die Intels Entwickler als selbstverständlich
annahmen...)
Es gibt nichts eleganteres als segmentierte Adressräume,
und daß bei einer 20 oder 24 bit Adressraum Maschine die Register
16 bit breits waren ist auch kein Problem sondern passte gut
Windows 3.11 war unglaublich effizient implementiert durch Nutzung
der Segmente, nur leider hat Microsoft den Speicherschutz (Ring 0-3
und Gates zum Übergang zwischen Ringen) nicht sauber durchgezogen.
IN einigen Spektrumanalysatoren von R&S sizzt der 186 auch drin (FSA, ESMI,..) . Hatte mal einen verhältnismäßig modernen DSR Testempfänger von R&S da war der auch noch drin - die müssen das Ding gemocht haben (Bj. ca- 1996 - 1999) vg Maik
MaWin schrieb: > was flat memory Dumpfbacken-CPUs wie Motorola 68000 durch > aufwändige und laufzeitintensive Programmierung "Macintosh > R11 R12 R13) erreichen mussten Ich glaube, da hast Du was nicht verstanden. 68k (und vorher auch 6809) kannten voll relokatiblen Code, wo überhaupt keine aufwendige oder laufzeitintensive Programmierung nötig war.
> Ich glaube, da hast Du was nicht verstanden.
Ich bin sicher, da hast Du was nicht verstanden.
Kein 68k Programm kann mit relativen calls/Sprüngen arbeiten, wenn es
mit anderen Programmen verknüpft werden muß.
Aber du darfst dich gerne in die Programmierung beispielsweise des 68k
Macintosh einarbeiten, wie ich das getan habe.
MaWin schrieb: >> Das ekelige am 80186 war halt das komische Segmentsystem. > > Du meinst die elegante Art der Speicherverwaltung > von der Burroughs 5500, > mit dem Daten und Code bliebig verschiebbar (relozierbar) sind, > wie es heute jedes Betriebssystem fordert, > was flat memory Dumpfbacken-CPUs wie Motorola 68000 durch > aufwändige und laufzeitintensive Programmierung "Macintosh > R11 R12 R13) erreichen mussten, und trotzdem keine DLL zwischen > verschiedenen Prozessen sharen können weil Datenbasisadresse > verschieden in den Code gepatcht werden müsste, also alles > doppelt geladen werden muß ? Hat nur nichts mit dem MC68k zu tun, sondern unfähigen Programmierern bei Apple und Palm (letztere haben mit div. zusätzlichen Beschränkungen wohl das schlechteste 68k OS aller Zeiten geliefert). Gegenbeispiel wäre u.a. das AmigaOS
MaWin schrieb: > Du meinst die elegante Art der Speicherverwaltung > von der Burroughs 5500, Ich kenne die zwar nicht, aber vermute, dass die eher vergleichbar mit der Segmentierung der 286 war. Der 186er fehlte der System-Modus und privilegierte Befehle zur Segmentverwaltung, so dass jeder Depp damit machen konnte was er wollte. Und das natürlich auch in jeder erdenklich üblen Weise tat. > Es gibt nichts eleganteres als segmentierte Adressräume, Die aber schon damals veraltet waren, weil Paging zwar leicht Platz verschwendet - damals waren 512 Byte Pages recht verbreitet - aber keine Probleme mit wachsenden Adressräumen (Daten, Stack) und mit Fragmentierung hat.
MaWin schrieb: > Kein 68k Programm kann mit relativen calls/Sprüngen arbeiten, wenn es > mit anderen Programmen verknüpft werden muß. 86er auch nicht immer ;-). Ok, sie müssen es nicht, weil die Segmentbasis zumindest im protected Mode nicht Teil des Programms ist und die dort enthaltene Segmentnummer feststeht. Allerdings waren segmentierte Calls im protected Mode langsamer als die Ersatzsequenzen bei 68000.
A. K. schrieb: > MaWin schrieb: >> Kein 68k Programm kann mit relativen calls/Sprüngen arbeiten, wenn es >> mit anderen Programmen verknüpft werden muß. > > 86er auch nicht immer ;-). Ok, sie müssen es nicht, weil die > Segmentbasis zumindest im protected Mode nicht Teil des Programms ist > und die dort enthaltene Segmentnummer feststeht. Allerdings waren > segmentierte Calls im protected Mode langsamer als die Ersatzsequenzen > bei 68000. Was die Apfelfreunde damals immer anprangerten, warum die max. 64k großen Datenstrukturen (wenn man mal vom Huge-Modell absieht). Der 68k war da viel besser. Der benutzte singned Offsets, 16bit groß, ergo 32k. Aber das haben die "Designer" nie wirklich verstanden. 68k, nicht 68020++, die waren dann auch mit 386++ zu vergleichen. Wie das ausgegangen ist, kann man bei den i7-Mac's sehen (-;
> Allerdings waren segmentierte Calls im protected Mode langsamer > als die Ersatzsequenzen bei 68000. Was nicht viel ausmacht weil die ja selten sind. > Palm (letztere haben mit div. zusätzlichen Beschränkungen > wohl das schlechteste 68k OS aller Zeiten geliefert). Zustimm. Ich hab mich auch gewundert, als wir mal ein Programm für den Palm schreiben mussten, welche absolut mieses Betrübssystem das war, wie man so dumm wie Palm sein konnte. > Gegenbeispiel wäre u.a. das AmigaOS Na ja, die umgehen alle Probleme in dem sie sie nicht können: "1.AmigaOS shared libraries share one data segment (the library base) among multiple openers. " So muss man atürlich nicht für unterschiedliche Owner relocaten. "2.On AmigaOS, the shared object files aren't really shared yet, meaning that the code (and the data, but for the data this is intentional) is loaded into memory every time the shared object is used." Dasselbe Problem wie flat memory nun unter Windows, eben für dumme Prozessoren ohne Segmente.
Gebhard Raich schrieb: > es gibt ihn auch nicht mehr zu kaufen. Von Intel nicht, aber es gibt eine Alternative für den 80C186: http://edageek.com/2007/02/26/innovasic-intel-80c186-188-microcontroller/ http://www.innovasic.com/Products/ia186eb-ia188eb
MaWin schrieb: > Zustimm. Ich hab mich auch gewundert, als wir mal ein Programm für den > Palm schreiben mussten, welche absolut mieses Betrübssystem das war, wie > man so dumm wie Palm sein konnte. > >> Gegenbeispiel wäre u.a. das AmigaOS > > Na ja, die umgehen alle Probleme in dem sie sie nicht können: > > "1.AmigaOS shared libraries share one data segment (the library base) > among multiple openers. " > > So muss man atürlich nicht für unterschiedliche Owner relocaten. > > "2.On AmigaOS, the shared object files aren't really shared yet, meaning > that the code (and the data, but for the data this is intentional) is > loaded into memory every time the shared object is used." Das bezieht sich nur nicht auf AmigaOS < 4 d.h. nicht auf die ursprünglichen 68k-Versionen. Wenn jedes Programm erstmal eine Kopie von exec, dos, graphics etc. ins RAM geschaufelt hätte, hätte es kein Multitasking auf dem Amiga gegeben. "The SAS runtime library tools offer two ways to handle library bases. There is the conventional method where there is only one copy of a library's LVO tables" und "There is also a second method where each library client receives its own copy of the library's LVO tables, Library structure, and global data. In this case, OpenLibrary() returns a different library base pointer for every program that opens the same library. The socket.library from Commodore's AS225 TCP/IP networking software is an example of a library that returns a unique library base for each client." http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node008C.html http://daniel.haxx.se/stuff/LIBRARY.TXT
Stefan Frings schrieb: > Ist dieser fast-Mikrocontroller eigentlich noch von Bedeutung, wird er > in aktuellen Entwicklungen industriell noch eingesetzt? Nein fuer neue Anwendungen. Er ist nur noch von Bedeutung wenn man ein 20 Jahre altes Geraet hat und jetzt eine Aenderung daran machen muss. Ein 186er koennte noch nicht mal einem modernen 8051 das Wasser reichen;-) Robert
X86 schrieb: > Der 68k war da viel besser. Der benutzte singned Offsets, 16bit groß, > ergo 32k. Weshalb heutige ARM Prozessoren ja bekanntlich wie die IBM Mainframes nur 4KB Speicher adressieren können. Intels IA64-Architektur hat diesem Schema zufolge einen 1-Byte Adressraum. Das ist natürlich Käse. Die Anzahl Bits im Offset einer Register-relativen oder absoluten Adressierung hat überhaupt nichts mit dem Adressraum zu tun. Das Kriterium dafür ist nicht die Codierung speicherbezogener Befehle, sondern die Breite der Adressrechnung. Und die erfolgte bei bei 68000 in 32 Bits Breite, weshalb Daten jenseits von 32K und 64K nichts im Weg stand. Nicht die 68000 war aufgrund ihrer Beschränkung der Offsets die falsche Konstruktion, sondern die 68020 war es mit ihrer bizarren Komplexität der erweiterten Speicheradressierung und der Codierung davon. Von vielem davon wurde bereits bei 68040/60 vom Hersteller wieder abgeraten und es flog bei Coldfire ganz raus. Einzig die limitierten Branch-Offsets waren ein echtes Manko, evtl. noch die diversen Beschränkungen PC-relativer Datenadressierung.
MaWin schrieb: >> Allerdings waren segmentierte Calls im protected Mode langsamer >> als die Ersatzsequenzen bei 68000. > > Was nicht viel ausmacht weil die ja selten sind. Heute ja, weil man sie für Codeadressierung nicht mehr verwendet. Damals sah das anders aus. Wenn mehr als 64KB Code zusammen kam, dann waren Funktionen zumindest bei Verwendung von (C-) Compilern überwiegend so definiert, dass sie segmentiert aufgerufen werden mussten, selbst wenn sie tatsächlich im gleichen Segment lagen. Denn Stack-Frame und Return-Befehl definierten die Art des Aufrufs einer Funktion, nicht die Platzierung. Folglich waren Funktionsaufrufe im "large" Modell überwiegend segmentiert, also mitnichten selten. Nur bei Beschränkung auf 64KB Code waren sie selten.
A. K. schrieb: > Das ist natürlich Käse. Die Anzahl Bits im Offset einer > Register-relativen oder absoluten Adressierung hat überhaupt nichts mit > dem Adressraum zu tun. Das Kriterium dafür ist nicht die Codierung > speicherbezogener Befehle, sondern die Breite der Adressrechnung. Korrektur: Gemeint ist hier die maximale Grösse einzelner Daten- und Codeobjekte, nicht der gesamte jeweilige Adressraum. Der Adressraum kann grösser sein als die ohne üble Umwege adressierbaren Daten- und Codeobjekte. Mit der Codierung der Befehle hat aber beides nichts zu tun.
> Das ist natürlich Käse. Die Anzahl Bits im Offset einer > Register-relativen oder absoluten Adressierung hat überhaupt nichts mit > dem Adressraum zu tun. Ein Zugriff auf table[i] geht nur über Offset, und wenn der Offset eben nur 15 bit hat, ist bei Tabellen über 32767 Elementen Schluss, man müsste sonst (bei jedem, nicht nur einem nahemn, denn man weiss ja nicht wie gross i sein wird) Zugriff umfänglichen Code schreiben, wie er unter Intel als huge bekannt ist. Und das war genau das, was Motorolavertreter lächerlich fanden und selbst viel schlimmer hatten. Daß auch ein Segment:Offset Intel viele 64k Tabellen haben konnte weil der Adresstaum scho damals in die Gigabytes ging, und auf jede einzelne schnell zugreifen konnte, war ja nicht der Kritikpunkt. Sodern eben der Offset.
MaWin schrieb: > Ein Zugriff auf table[i] geht nur über Offset, und wenn der Offset eben > nur 15 bit hat, ist bei Tabellen über 32767 Elementen Schluss, Keineswegs. Die bereits von Anfang bei der 68000 existierende indizierte Adressierung d8(Ax,Xn.W/L) rechnet wahlweise mit 16-Bit Index (.W) und mit 32-Bit Index (.L). d8(Ax,Xn.L) rechnet also 32 Bits Ax + 32 Bits Xn + sign-extended d8. Xn = D0-7/A0-7. Eingeschränkt ist einzig die Adressierung d16(Ax), also mit Konstante relativ zum Register, aber damit sind fast alle real auftretenden Fälle erfasst. Da hier der Offset konstant ist hat der Compiler meist auch kein Problem, grössere Offsets zu erkennen und anders zu rechnen. So wird beispielsweise mov #offset32, A1 ... 0(Ax,A1.L) daraus, wenn der Offset nicht in d16 passt. Solche Limits haben ürigens alle aktuell gängigen General-Purpose-Architekturen. Auch AMD64 verwendet sinnvollerweise keine 64-Bit Offsets in der Codierung. Ärgerlich war (und blieb) nur, dass Datenzugriffe PC-relativ eingeschränkt waren, einerseits auf d16, andererseit auf Lesezugriffe. Damit wurde es schwierig, voll verschiebliche Codemodule zu bauen, die ihre eigenen Daten PC-relativ adressieren. Ein Problem, das auch in der PC-Architektur bestand und erst mit AMD64 behoben wurde.
> Damit wurde es schwierig, voll verschiebliche Codemodule zu bauen, ...
Fix: ... wurde es aufwendiger, voll verschiebliche Codemodule zu bauen
Sehr interessante Diskussion! Bisher dachte ich immer, daß Segmentierung aus einer Not heraus geboren wurde und eher störend als hilfreich wäre. Allerdings kenne ich Segmentierung auch nur vom C166 und dort wird es auch als "Manko" angegeben: http://www.mikrocontroller.net/articles/C166
Pako schrieb: > Bisher dachte ich immer, daß Segmentierung aus einer Not heraus geboren > wurde und eher störend als hilfreich wäre. Was es ja auch. Die sehr primitive Segmentierung von 86ern ohne protected mode war erheblich einfacher zu implementieren als Paging. Weshalb Intel diese chipintern bringen konnte, Zilog die in "echten" Betriebssystemen auch nutzbare Segmentierung der Z8000 aber externalisieren musste. Dass mit komplexen Betriebssystemen und virtuellem Speicher ausgestattete 32-Bit Systeme eher auf Paging als auf Segmentierung setzten war indes auch damals mühelos erkennbar. Man musste sich nur die damals führenden 32-Bit Architekturen ansehen, wie VAX und IBM-370. Mit 386 hatte Intel die Segmentierung aus der 16-Bit Ära herüber gerettet und als eine Art Objektorientierung verkaufen wollen. Sie blieben mit dieser Vorstellung aber ziemlich einsam, weil die Anwender dies weitgehend ignorierten und auf einen linearen 32-Bit Adressraum setzten und die Segmentierung darin nur für Kleinigkeiten wie thread-lokale Daten verwendeten. Auch stolze Konzepte wie das integrierte Task-Switching landeten effektiv in Ablage P, weil langsamer als zu Fuss.
> Segmentierung auch nur vom C166 Auch dort keine echte nützliche, sondern eine unverstanden implementierte, die wirklich nur ein Klotz am Bein ist. Immer dran denken: Der 286 war in den Köpfen, als der 8086 gebaut wurde, man wusste wohin man wollte, wenn erst genügend Transistoren auf einen Chip passen, Gordon Moore war schliesslich von Intel, er war Intel. > Dass mit komplexen Betriebssystemen und virtuellem Speicher > ausgestattete 32-Bit Systeme eher auf Paging als auf Segmentierung > setzten war indes auch damals mühelos erkennbar Nicht wirklich, die Betriebssystem folgten der vorhandenen Hardware. Die B5500 wurde halt später erfunden, nur haben wenige Menschen verstanden warum das segmentierte Konzept so viel besser war. Das ist heute ja auch nicht anders. Die wenigsten Schwätzer haben schon mal ein oder mehrere Betriebssysteme implementiert.
MaWin schrieb: > Die wenigsten Schwätzer haben schon mal ein oder mehrere Betriebssysteme > implementiert. Falls du mich meinst: ich habe, auf 68000. Compiler-Codegenerierung ebenfalls, auch da war 68000 mit dabei. Brilliant wirkende Konzepte sind nicht automatisch auch brilliant in der Praxis. In Intels iAPX432 sollten diese Ideen zukunftsträchtig umgesetzt werden. Das war eine der grössten konzeptionellen Pleiten in der Geschichte der Rechnerarchitekturen.
> Falls du mich meinst Nein. > Brilliant wirkende Konzepte sind nicht automatisch auch brilliant in der > Praxis. In Intels iAPX432 sollten diese Ideen zukunftsträchtig umgesetzt > werden. Das war eine der grössten konzeptionellen Pleiten in der < Geschichte der Rechnerarchitekturen. Na ja, objektorientiert halt. Heute in Software schwer in Mode, und keiner schreit daß die Architektur eine Pleite wäre, obwohl genau dasselbe wie damals passiert. Heute schreit man nur, daß die Prozessoren endlich mehr Leistung haben müssten, damit die unsäglich umständlichen Programme wenigstens halbwegs bedienbar schnell ablaufen. iAPX432 fand ich auch sehr interesasnt, hatte ich aber nie in den Fingern. Transputer fand ich auch sehr interessant, bis ich dann T800 mal programmieren musste. Daher ist praktische Erfahrung immer gut.
MaWin schrieb: > Heute in Software schwer in Mode, und keiner schreit daß die Architektur > eine Pleite wäre, obwohl genau dasselbe wie damals passiert. Der gewaltige Unterschied besteht darin, wo und wann der Aufwand entsteht. Ein Prozessor kann nur sehr begrenzt optimieren. Wenn ein sehr komplexer CALL Befehl u.A. alle Möglichkeiten von Unterprogrammaufrufen enthält, inklusive lokaler Funktionen mit ihren Datascopes wie in Pascal (siehe auch x86 CALL+ENTER/LEAVE in Vollform), dann bleibt dem Prozessor nichts übrig, als die jedes Mal alle in Betracht zu ziehen, auch wenn in 95% der Fälle ein primitiver JSR ausreicht. Dieser Overhead kostet dann bei jedem Aufruf Zeit, weshalb der CALL Befehl der DEC VAX ebenso selten Verwendung fand wie ENTER bei x86. Die Leute merkten, dass es schneller ist, wenn man auf dem einfachen Befehl aufbaut und zusätzliche Befehle nur bei Bedarf hinzufügt. Der Compiler hat da ganz andere Möglichkeiten als der Prozessor. Der kann bereits zur Übersetzungszeit die Komplexität wesentlich reduzieren. Beispielsweise wenn er virtuelle Methoden statisch aufrufen und ggf. inlinen kann, weil er aus dem Kontext die Klasse bereits kennt, oder weil er basierend auf Profiling einen 90%-Fall vor der Schleife einmalig testet. Der Compiler weiss auch, ob ein Funktionsaufruf lokale Funktionen berücksichtigen muss und kann dann bedarfsgemäss entsprechend Code erzeugen, während der Prozessor das jedesmal zur Laufzeit prüfen muss. > Transputer fand ich auch sehr interessant, bis ich dann T800 mal > programmieren musste. Daher ist praktische Erfahrung immer gut. Yep, hab einen C-Compiler dafür gebaut. Der war eine nette Idee für genau die paar Jahre, die es dauerte, bis andere Architekturen einen Befehl pro Takt ausführen konnten und war hoffnungslos aus dem Rennen, als es dann auch noch mehrere pro Takt zu werden drohten. Stack-Architekturen waren immer eine gute Idee, wenn es einfach sein sollte, und oft eine schlechte, wenn es (dauerhaft) schnell werden sollte. Siehe auch 8087-FPU, und heute inbesondere Java-VM vs. Dalvik-VM (Android). Bei der DVM lassen sich Optimierungen in die Generierung von DVM-Code verlagern, die in der JVM nur zur Laufzeit realisierbar sind.
MaWin schrieb: > Nicht wirklich, die Betriebssystem folgten der vorhandenen Hardware. Es gibt beide Richtungen. Am Anfang kann eine Idee stehen, die nicht selten eine Kooperation von Hardware und Software benötigt. Jene CPU-Designer, die in der 60ern die Möglichkeiten für virtuellen Speicher in Hardware gossen, die haben das nur getan, weil das entsprechende Betriebssystem-Konzept bereits in den Köpfen steckte. Andernfalls wäre der Aufwand nicht getrieben worden. Bei der Virtualisierung von und auf PC-Prozesoren lief es über lange Zeit regelrecht verkehrt herum. Intel hatte mit 386 zwar die Fähigkeit geschaffen, real mode DOS VMs zu implementieren, was schon bald Systeme wie VM/386 für virtuelle DOS-Maschinen in DOS ermöglichte, später die DOS-Box von NT. Aber Intel hatte andererseits eine Virtualisierung des protected mode eigentlich unmöglich gemacht, weil wenige essentielle, damals längst bekannte und eigentlich unproblematische Kleinigkeiten vergessen wurden. Die Leistung von VMware war es, das eigentlich Unmögliche möglich zu machen, indem man Intels Fehler durch diverse Tricks einschliesslich partieller Befehls-Emulation umging. Dennoch dauerte es ein Jahrzehnt, bis die Weiterentwicklung der x86-Hardware allmählich der Entwicklung der Virtualisierung folgte und unterstützende Mechanismen einbaute. Hier kam eindeutig erst das Betriebssystem und dann lange später die passende Hardware.
X86 schrieb: > 68k, nicht 68020++, die waren dann auch mit 386++ zu vergleichen. Wie > das ausgegangen ist, kann man bei den i7-Mac's sehen (-; Der Weg, den Macs über 68000 und PowerPC zu x86 nahmen, hat wenig mit der Qualität der Architektur zu tun. Sondern mit Masse und Entwicklungskosten. Der Enwicklungsaufwand für aktuelle High-End Prozessoren ist nur mit entweder grosser Stückzahl refinanzierbar (Intel/AMD), oder mit einem sogar für Apple-Kunden prohibitiv hohen Einzelstückpreis und technischem Aufwand (IBM Power). Was 68xxx vs x86 angeht, so ist x86 allen Unkenrufen zum Trotz besser als ihr Ruf, wenn man es auf den Vergleich dieser beiden Architekturen beschränkt. Motorola hatte sich nämlich mit der 68020 mit beachtlicher Konsequenz in die falsche Richtung bewegt und das dann spätesten anno 68060 gemerkt, als ein Teil jener schönen neuen Features der 68020 einer schnellen Ausführung der Befehle bös im Weg stand. Schon die 68000 hat freilich aufgrund des 2-Adresse Move-Befehls Fallen in petto, die sich bei 68010 in Form aufwendiger Mikrocode-Interrupts statt der anderswo üblichen Retries von Befehlen bemerkbar machte. Die x86 Architektur bot aller Hässlichkeit zum Trotz deutlich weniger Stolperfallen bei der Entwicklung schneller superskalarer Implementierungen als die 68xxx Architektur. Intel hatte es also bei der Beschleunigung der Hardware leichter als Motorola, weshalb Motorola den Ausweg über 88000 und später PowerPC suchte, aber an der schieren Masse der PC-Verkäufe scheiterte.
MaWin schrieb: > Dasselbe Problem wie flat memory nun unter Windows, eben für dumme > Prozessoren ohne Segmente. Ein vermutlich nicht allgemein bekanntes Beispiel dafür, weshalb Segmente zur Klasse der in der Realität problematischen Konzepte gehören: Die Adressrechnung enthält gegenüber einem linearen Adressraum eine letztlich unproduktive Addition zusätzlich. Die verlängert effektiv die Zugriffszeit auf den Speicher. Diese Adressrechnung erfolgt zwingend vor dem Cache-Zugriff, jedenfalls wenn die Basisadresse feiner auflöst als das 4KB Paging. Im Gegensatz dazu lässt sich ein 4KB Paging im Cache-Zugriff verstecken, so dass es die Zugriffszeit nicht verlängert, weil der Zugriff auf den TLB parallel zum Cache-Zugriff erfolgen kann. Mindestens dann wenn cachesize divided by associativity >= 4KB gilt, was bei Intel immer zutrifft. Das ist der Hauptgrund, weshalb mit Intels L1-Caches immer auch deren Assoziativität wuchs - AMD ging andere Wege, um das dort resultierende Aliasing-Problem zu lösen.
> Die Adressrechnung enthält gegenüber einem linearen Adressraum > eine letztlich unproduktive Addition zusätzlich. Ja, bei naiver Betrachuntg tritt dieses Problem auf, wenn man immer schneller wird, so daß schon diese Addition von Segmentbasis+Offset zeitkritisch wird. Natürlich könnte man, wenn man schon Register virtualisiert, auch einen vorausgerechneten Adresswert durch den Prozessor schleppen. Bei jedem Verändern der zugrundeliegenden Bezugswerte müsste der zwar neu berechnet werden, aber das liegt einen Befehl vor dem Zugriff über ihn, damit wäre er kein zetliches bottleneck mehr. Klar macht das die CPU nicht einfacher. > Bei der Virtualisierung von und auf PC-Prozesoren lief es über lange > Zeit regelrecht verkehrt herum. Intel hatte mit 386 zwar die Fähigkeit > geschaffen, real mode DOS VMs zu implementieren, was schon bald Systeme > wie VM/386 für virtuelle DOS-Maschinen in DOS ermöglichte, später die > DOS-Box von NT. Ich würde nicht sagen, daß es verkehrt herum lief, sondern Virtualisierung war zuerst da, die Boxen kamen dann. Daß das virtualisieren von sich selbst den Intel Leuten nicht notwendig erschien, war halt so und ein Bremser für VMware.
MaWin schrieb: > Ich würde nicht sagen, daß es verkehrt herum lief, sondern > Virtualisierung war zuerst da, die Boxen kamen dann. Wenn man Virtualisierungssysteme als Betriebsysteme betrachtet, und das tue ich, dann steht hier also das Betriebssystem lange vor der Hardware und ist damit exakt die umgekehrte Reihenfolge, als jene, die du oben als "die Betriebssystem folgten der vorhandenen Hardware" beschrieben hast. > Daß das > virtualisieren von sich selbst den Intel Leuten nicht notwendig > erschien, war halt so und ein Bremser für VMware. Ein Bremser für die Virtualisierung, die sonst früher da gewesen wäre, aber nun wirklich kein Bremser für VMware, wirtschaftlich betrachtet. Ohne Intels Fehler hätte das jeder gekonnt, so aber wurde VMware damit gross, dass sie es trotzdem effizient konnten. Um den Verschwörungstheoeretiker hervorzukehren frage ich mich mittlerweile freilich, ob die fehlende Virtualisierungsunterstützung seitens Intel nicht vielmehr Absicht war. Was man tun musste wussten sie ja, nichts Anderes nämlich als das, was sie selbst für VM86 implementierten. Virtualisierung benötigt zwar grössere teurere Rechner als normales Blech, aber insgesamt weniger Prozessoren. Erfahrungen mit Strategien von IBM lassen solche Überlegungen als nicht völlig absurd erscheinen. IBM hatte sich einen gewissen Ruf erworben, interne Entwicklungen zu unterdrücken, die das gute laufende Geschäft mit der klassischen Hardware gefährden könnten.
MaWin schrieb: > Natürlich könnte man, wenn man schon Register virtualisiert, > auch einen vorausgerechneten Adresswert durch den Prozessor > schleppen. Bei eher statischen Registerinhalten ja, aber bei pointer chasing bringt das nichts. Vorausgesetzt, die Segmentnummer ist Teil des Pointers, was der realistische Fall ist. Intels Assoziation der Register mit getrennten Segmentnummern reduziert den Nutzen von Segmentierung erheblich. Segmentierung im Objektsinn bringt doch nur was, wenn es sehr viele davon geben kann und die Segmentnummer folglich Teil der Objektadresse ist. Wenige Segmente bringen IMHO keinen Vorteil gegenüber einem linearen Adressraum, wenn dessen begrenzte Grösse selbst kein Problem ist. Trennung der Befehle in jene, die Segmente manipulieren, und jene die sie nutzen, vergrössert die Anzahl Befehle, die für die gleiche Tätigkeit nötig sind.
Was ist denn aus diesen Nec20, Nec25 Zeug geworden, wurde das weiterentwickelt oder einfach nur abgekündigt ?
Fortsetzung: Letztlich verlagert Segmentierung Aufwand in die Laufzeit, ohne zur Laufzeiteffizienz irgendwie produktiv beizutragen. Da erscheint es klüger, den Sicherheitsaspekt davon abzutrennen und als optionalen Code dort zu generieren, wo er sinnvoll ist. Code zur Kontrolle von Werten und Adressen kann der Compiler auch selbst erzeugen, kann es aber oft auch weglassen, wenn er weiss, dass nichts anbrennen kann. Vor der Schleife ist der Check billiger als drinnen.
pic tech schrieb: > Was ist denn aus diesen Nec20, Nec25 Zeug geworden, wurde das > weiterentwickelt oder einfach nur abgekündigt ? Da dieser Teil von NECs mittlerweile beim grossen vereinheitlichten japanischen Elektronikkonzern Renesas gelandet ist, siehe dort.
> Fortsetzung: Letztlich verlagert Segmentierung Aufwand in die Laufzeit, > ohne zur Laufzeiteffizienz irgendwie produktiv beizutragen. Falsch. Wenn du das, was Segmentierung leistet (gemeinsame DLL mit prozesspezifischen Daten, hierarchiche Rechte wer wen aufrufen bzw. benutzen darf), ohne Segmentierung machen willst, hast du den Aufwand in der Software, und an manchen Stellen gar keine Chance es zu emulieren.
Welchen Vorteil bringt hier die Segmentierung, gegenüber einer ISA, die PC-relative Datenadressierung beherrscht und somit Code+Daten einer DLL zu einem positionsunabhängigen Bündel schnallen kann? Eine erste Idee dazu wäre die Möglichkeit, globale Segment-IDs vergeben zu können. Wenn man freilich die Segment-ID als Teil des Adressraums betrachtet, dann muss man fairerweise eine Adressierung mit 16-Bit ID und 16-Bit Offset mit einem unsegmentierten 32-Bit Adressraum betrachten. Bei dem man genau das gleiche machen kann, aber keine Begrenzung auf 64K Objekte hat. Interessanter finde ich das, was die Power-Architektur als Segmente bezeichnet. Weil das einen globalen prozessübergreifenden und damit TLB-freundlichen Adressraum erzeugt, ohne fixe Offset-Grenzen einzuführen.
Interessante Diskussion. Ich persönlich habe bereits beim 286 aufgegeben, zu versuchen zu verstehen, was intern abläuft.
> Welchen Vorteil bringt hier die Segmentierung, gegenüber einer ISA, die > PC-relative Datenadressierung beherrscht und somit Code+Daten einer DLL > zu einem positionsunabhängigen Bündel schnallen kann? Daß die Daten prozesslokal sind. Also eine DLL, x mal Daten je nach Aufrufer. Emuliert z.B. in einem Register die Datenbasisadresse mitzuführen fehlen dir die Zugriffsrechte. Auch noch die Zugriffsrechte emulieren heisst Daten in verschieden geschütze Seiten zu platzieren. Wenn du das mehrere Stufen durchziehst, bekommst du eine quadratisch steigende Anzahl von Seitenbelegungstabellen, also unkratikabel. > Interessanter finde ich das, was die Power-Architektur als Segmente > bezeichnet Das ist auch durchaus eine nützliche Lösung. Hab ich aber noch kein Betriesyystem für geschrieben...
H.joachim Seifert schrieb: > Ich persönlich habe bereits beim 286 aufgegeben, zu versuchen zu > verstehen, was intern abläuft. Bei mir wars umgekehrt. Mich hatten ab ca. K5 und P5 ebendiese Abläufe sehr interessiert. Einen übersichtlichen Einblick in den Aufbau der meisten aktuellen x86-Prozessoren bietet http://www.agner.org/optimize/microarchitecture.pdf
Tja, interessant wäre es schon gewesen. Aber Kapazitäten sind immer begrenzt. Ich fand die beginnende Mikrocontroller-Schiene für mich lukrativer und für mich persönlich zukunftsträchtiger.
MaWin schrieb: > Daß die Daten prozesslokal sind. Jo, aber das geht mit Paging eher besser als mit Segmentierung. Weil man das gleich noch mit copy-on-write (COW) verbinden kann. Womit dann nur jene Data Pages prozesslokal sind, die sich tatsächlich zwischen den Prozessen unterscheiden. Sobald einer in eine Page reinschreibt, kriegt er davon eine Kopie. Bis dahin hat er die selbe Page wie die anderen Prozesse. Je nach Art der Daten und der Prozesshistorie kann das recht viel sparen. > Wenn du das mehrere Stufen durchziehst, bekommst du eine quadratisch > steigende Anzahl von Seitenbelegungstabellen, also unkratikabel. Bei der quadratischen Entwicklung kann ich dir nicht folgen. Ich sehe die eher sublinear, mit COW und ggf. Pagetable Sharing.
MaWin schrieb: > Emuliert z.B. in einem Register die Datenbasisadresse mitzuführen fehlen > dir die Zugriffsrechte. Weshalb sollten die Daten in jeden Prozess relativ zum Code an einer anderen Adresse liegen? Selbst wenn die DLL x-mal im gleichen Adressraum liegt wird das nicht zum Problem, weil der Code das ebenfalls tun kann. Und wenn man das dann noch geschickt an 2MB-Grenzen orientiert (also Adressbereich für n*2MB Code und die Daten dahinter), dann dupliziert sich mit dem Code rein garnix, weils dafür überall die selbe Pagetable sein kann.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.