Mal eine Frage an diejenigen, die (früher) in Assembler mit Bank Switching (z.B. beim C128) und der Segment:Offset Adressierung der x86 Prozessoren im Real Mode gearbeitet haben. Welche Variante fandet ihr denn zum Programmieren besser? Sofern ich das richtig verstanden habe, wurden beim Bank Switching komplette RAM Bereiche ausgetauscht. Ist es richtig dass man Bänke nur als Ganzes, aber nicht überlappend, also z.B. von Bank A die obere Hälfte und von Bank B die untere, einblenden konnte? Beim x86 konnte man dagegen das eingeblendete Segment, wenn gewünscht, in 16 Byte Schritten praktisch im ganzen 1 MiB Speicherbereich entlang verschieben, so dass man z.B. zwei aufeinanderfolgende 64 KiB Bereiche auch einfach überlappend ansprechen konnte, in dem man das Segmentfenster z.B. ab der oberen Hälfte des ersten 64 KiB Bereich beginnen lies, so dass es praktisch in die untere Hälfte des darauf folgenden 64 KiB Bereich hineinragte, womit man sich die Far Pointer Sprünge sparen konnte. Hier könnte ich mir vorstellen, dass das programmiertechnisch ein paar Vorteile brachte, weil man so nur das Segmentfenster entsprechend verschieben musste und sich, wie schon gesagt, die Far Pointer zu einem gewissen Grad ersparen konnte, während beim Bank Switching immer auch ein Austausch der aktiven Bank notwendig war, was extra Zeit kostete. Kann man das so sagen? Vielleicht können diejenigen, die mit beiden Methoden früher in Assembler programmiert haben dazu mal etwas sagen und aus dem Nähkästchen plaudern. Und welche Rechner machten, abgesehen vom C128, noch so vom Bank Switching Gebrauch?
Nano schrieb: > Welche Variante fandet ihr denn zum Programmieren besser? Bank switching. > Ist es richtig dass man Bänke nur > als Ganzes, aber nicht überlappend, also z.B. von Bank A die obere > Hälfte und von Bank B die untere, einblenden konnte? Kommt rein auf die Hardware an. Prinzipiell ist natürlich auch solcher Schwachsinn möglich. Macht bloß niemand, der noch alle Latten am Zaun hat... > Und welche Rechner machten, abgesehen vom C128, noch so vom Bank > Switching Gebrauch? Nahezu alle Homecomputer und Spieleconsolen der 8-Bit-Ära haben Bank-Switching verwendet. Wenn auch nicht immer unbedingt in der Form, dass man aus der Software heraus aktiv und gezielt switchen konnte...
Nano schrieb: > Welche Variante fandet ihr denn zum Programmieren besser? Segment:Offset ist genial, wenn die Segmente sinnvoll verteilt sind, also codesegment, datasegment, stacksegment und daten im heap. Denn es erlaubt ein Verschieben der Segmente (heap kollidiert nicht mit stack) und das splitting von coderesourcen und ausführender Instanz, also eine DLL due nur ein mal in den Speicher geladen wird, aber von mehreren Prozessen (stacksegment) mit jeweils eigenem Datensegment (threadstatic) benutzt werden. Zudem erlauben Segmente bytegenaue Abgrenzung auf was zugegriffen wird und was nicht, und machen den üblichen Vorteil der caches, wenn code und daten im Speicher bevorzugt in einem kleinen Beteich und nicht quer verstreut addressiert wrrden, auch im cide sichtbar: segment neu laden dauert länger. Und die call-Gates um von einem Codesegment zum anderen im höheren Ring zu kommen wobei vom stack nur das benötigte umkopiert wird, machen Betriebssystemaufrufe sicher. Die Segmentierung, erfunden mit der Bourroughs 5500, ist perfekt. Leider hat man beim 286 das dirty-bit vergessen. Banking ist Krampf, ob Speicher oder PIC I/O Ports, und hat keine Ähnlichkeit mit Segmenten, ist eher eine primitive MMU aging Speicherverwaltung. Ich erinnere mich noch an eine CPU, die 32k Speicher für das Betriebssystem hatte, und gebankte 32k pro Benutzer. Das ging halbwegs, es konnte dadurch halt ein Benutzer nicht dem anderen reinpfuschen, und auch nicht ins Betriebssystem Daten speichern. Es war halt 1 page. Mit allen Nachteilen, wie physikalische Grösse die nichts mit der softwarebenötigten Grösse zu tun hat.
c-hater schrieb: > Nano schrieb: > >> Welche Variante fandet ihr denn zum Programmieren besser? > > Bank switching. Eine Begründung wäre noch klasse. Habe das "und warum" in der Frage leider vergessen. >> Ist es richtig dass man Bänke nur >> als Ganzes, aber nicht überlappend, also z.B. von Bank A die obere >> Hälfte und von Bank B die untere, einblenden konnte? > > Kommt rein auf die Hardware an. Prinzipiell ist natürlich auch solcher > Schwachsinn möglich. Macht bloß niemand, der noch alle Latten am Zaun > hat... Es hätte aber Vorteile, weil man so bspw. eine Hälfte einer Bank mit wichtigen Funktionen dauerhaft einblenden könnte und nur die obere Hälfte von anderen Bänken switchen müsste. Damit könnte man dann innerhalb einer aktiven Bank die Funktionen der anderen Bank nutzen ohne ständig die Bänke hin und her schalten zu müssen, was man ja ansonsten tun müsste, wenn man auf diese wichtigen Funktionen der anderen Bank zugreifen müsste. Der Vorteil wäre somit ein Performancevorteil. Der Nachteil ungenutzer Speicherplatz. Wobei man für sehr seltene Funktionen auch den unteren Teil einer Bank natürlich noch switchen könnte um den mal nur kurz zu nutzen, ist halt eine Frage des Aufwands. > >> Und welche Rechner machten, abgesehen vom C128, noch so vom Bank >> Switching Gebrauch? > > Nahezu alle Homecomputer und Spieleconsolen der 8-Bit-Ära haben > Bank-Switching verwendet. Wenn auch nicht immer unbedingt in der Form, > dass man aus der Software heraus aktiv und gezielt switchen konnte... Aber Bank Switching macht doch erst ab mehr als 64 KiB RAM Sinn, oder meinst du damit das Switchen auf ROMs.
MaWin schrieb: > Nano schrieb: >> Welche Variante fandet ihr denn zum Programmieren besser? > > Segment:Offset ist genial, wenn die Segmente sinnvoll verteilt sind, > also codesegment, datasegment, stacksegment und daten im heap. > .... Danke für deine Antwort.
Nano schrieb: > Aber Bank Switching macht doch erst ab mehr als 64 KiB RAM Sinn, oder > meinst du damit das Switchen auf ROMs. Hardwarezugriffe habe ich noch vergessen. Wobei man die vielleicht auch in den Adressbereich einblenden könnte. Keine Ahnung wie das bei der ein oder anderen Bank Switching CPU gemacht wurde. Hatte nie einen Home Computer.
C64 (6502), da konnte man das ROM ›hochheben‹ um an das darunter liegende RAM zu gelangen. Wie beliebt die Segmentierung wirklich war konnte man an den frenetischen Jubelrufen erkennen als Motorola zB. den 68000 heraus brachte und den Segmentierungsquark überflüssig machte. Der bessere Befehlssatz war dann noch der Zuckerguss oben drauf.
Beides Krücken, um den für die CPU ursprünglich vorgesehen Adressraum zu erweitern. Platform-Banking wie z.B. beim C64, wo es nur darum ging, ROMS oder (Video)RAM ein-/auszublenden, ist verhältnismäßig harmlos. CPU-Banking (wie bei den PICs) ist ein Alptraum. Die Segment:Offset-Methode bei den x86ern brachte zumindest ein paar weitere Vorteile (s. MaWin), allerdings ergaben sich auch zig (inkompatible) Memorymodelle (tiny/small/medium/compact/large/huge), die zu einem ziemlichen Durcheinander führten (jedes Lib in 6 Varianten!?!). Mit den 32-Bit-CPUs hat sich das ziemlich schnell erledigt - weine dem keine Träne nach.
foobar schrieb: > Beides Krücken Das kann man aus Programmierersicht ruhig noch deutlicher formulieren: Beides Ingenieurs-Pfusch!
Hast du dich im jahrhundert geirrt?
Meiner Meinung nach macht das bank switching nur Sinn, wenn dem Prozessor mehr Speicher zur Verfügung steht, als er addressieren kann. Der C64 z.B. hatte ja 64k RAM, was das Maximum war, das die CPU adressieren konnte. Um jetzt noch ROM für bspw. Basic unterzubringen, musste man einen Teil des RAM ausblenden, um an dieser Stelle auf das ROM zugreifen zu können. Die Speichersegmentierung beim x86 funktioniert ja so, daß sie dem direkt über die 16 Bit Register erreichbaren Adressraum weitere 4 Bit hinzufügt. Damit erweitert sich der adressierbare Speicher auf 2^20 Adressen, was 1Mbyte ist. Den Sinn für diese Aufteilung habe ich auch nie verstanden, man hätte besser gleich die kompletten 16 Bit der Segmentregister nutzbar machen sollen, damit hätte selbst dieser Kern schon 4GByte addressieren können. Spätere x86 können im protected mode ein "flaches" (flat) Speichermodell, damit wird bei den 32bit Prozessoren die volle Registerbreite für den Speicherzugriff nutzbar, bedeutet man kann ohne (programmierseitige) Segmentierung 4GByte allein mit den Basisregistern addressieren, bei 64bit sind's 16 Exabyte oder so, derzeit nutzt das keine CPU komplett aus (übliche CPUs nutzen "nur" 48bit), reicht also noch 'ne Weile. Programme wie himem.sys usw. funktionierten so, daß man sich dort quasi Speicher über 1MByte in Blöcken "bestellen" konnte und Daten in diese Blöcke hinein oder wieder heraus kopieren lassen konnte. Dazu wechselten diese kurz in den protected mode, kopierten die Daten und wechselten wieder zurück. DOS-Extender haben's andersrum gemacht. Das Programm ist praktisch im protected mode gelaufen und für DOS-Zugriffe wurde kurz in den real mode gewechselt. Wie man sieht, irgendwie war das Modell Speichersegmentierung wohl generell etwas scheiße, auch wenns in Bezug auf den Stack evtl. ein paar Vorteile bringt, und die Softwarebranche hat recht schnell festgestellt "brauchen wir nicht!"
:
Bearbeitet durch User
Lust L. schrieb: > foobar schrieb: >> Beides Krücken > > Das kann man aus Programmierersicht ruhig noch deutlicher formulieren: > Beides Ingenieurs-Pfusch! Das ist doch Unsinn! Jetzt denkt doch mal nach. Früher, als diese 8 und 16 Bit CPUs auf den Markt kamen war ein Silizium Waver sau teuer und hatte wenig Platz, immerhin waren das diese 100 mm bis höchstens 200 mm Waver. Die Fertigungsgröße war mit > 1000 nm riesig, so dass nur wenige Chips auf den Waver passte. Wollte man die Ausbeute erhöhen um auf einen bezahlbaren Preis für die Chip zu kommen, dann gab es dafür nur einen Weg, man musste die Transistoranzahl pro CPU reduzieren. Und wie macht man das? Ganz einfach, man fertigt nur 8 Bit und 16 Bit CPUs, anstatt 32 Bit CPU. Eine 16 Bit CPU hat nur halb so breite Register wie eine 32 Bit CPU. Um nur ein einziges Bit zu speichern, braucht man mehrere Transistoren. Bei 16 Bit weniger spart man somit 16 * n Transistoren ein. Insofern war das kein Pfusch, sondern schlichtweg erforderlich. 32 Bit CPUs konnte sich anfangs nämlich keiner Leisten. Das kam erst später mit dem 68k, der intern 32 Bit breite Register hatte, damit 32 Bit breite Adressen reinpassen.
Ben B. schrieb: > Den Sinn für diese Aufteilung habe ich auch > nie verstanden, man hätte besser gleich die kompletten 16 Bit der > Segmentregister nutzbar machen sollen, damit hätte selbst dieser Kern > schon 4GByte addressieren können. Meine Vermutung: Es sparte wahrscheinlich intern Datenleitungen und somit auch Transistoren. Man konnte so aus wenigen Transistoren also mehr machen und trotzdem 1 MiB adressieren. > Wie man sieht, irgendwie war das Modell Speichersegmentierung wohl > generell etwas scheiße, auch wenns in Bezug auf den Stack evtl. ein paar > Vorteile bringt, und die Softwarebranche hat recht schnell festgestellt > "brauchen wir nicht!" Das stimmt nicht. Der 80386 von Intel kam 1985 raus und es hat 8 Jahre gedauert bis ein größerer Teil der Softwarewelt mit Windows NT 3.1 nachzog. Und das war nur für Businessgeräte, weil die NT Lizenz teuer und der nutzen für den Endanwender gering war. Beim Konsumenten ging es mit 32 Bit also eigentlich erst ab Windows 95 wirklich los. Zwar gab es zuvor noch DOS Extender, wie du selbst richtig sagst, aber die wurden erst in einer Spätphase von DOS ab ca. 1993 von Software verwendet und bis Windows 95 waren es dann nur noch 2 Jahre. Win32s für Windows 3.x gab es zwar auch noch, aber das erschien auch erst 1992, also 7 Jahre nachdem die ersten 32 Bit fähigen x86 CPUs verfügbar waren. Sicherlich hängt es auch damit zusammen, dass mehr als 1 MiB RAM bis ca. 1992 noch teuer war, so dass der Real Mode noch genügte. Aber selbst wenn man nicht mehr als 1 MiB nutzt, hätte das Flat Memory Modell, wie es die 32 Bit CPU bot, Vorteile gebracht.
Ach und dann noch etwas. Ein 32 Bit OS wie Windows NT braucht allein schon 4 MiB für die Page Table. Siehe dazu: https://www.cs.cornell.edu/courses/cs4410/2015su/lectures/lec14-pagetables.html Insofern ist auch das ein Grund, warum es zumindest auf OS Seite so lange gedauert hat, bis ein 32 Bit OS verfügbar ist. Und es erklärt auch, warum die Mindest RAM Anforderungen von Windows NT für die damalige Zeit gleich so hoch waren.
Nano schrieb: > Insofern war das kein Pfusch, sondern schlichtweg erforderlich. Das ist doch Quatsch. Wieso sollten einfache lineare Adressräume und 8/16 Bit CPUs einander ausschließen? Tatsächlich ist es wie bei Software: Da wird bei inflationärem Wachstum diverser Modi ständig an- und umgebaut anstatt gleich von grundauf ein stimmiges Konzept zu entwickeln. Stimmig heißt: Aus Programmierer-Sicht maximal einfach. Leider ist das nicht die Haupt-Priorität der Hardware-Entwickler. Mit der Folge sehr sehr vieler unnützer Software-Entwickler Stunden inklusive Debugging von Fehlern aus einem inflationär wachsenden Fehler-Potential.
:
Bearbeitet durch User
Lust L. schrieb: > Nano schrieb: >> Insofern war das kein Pfusch, sondern schlichtweg erforderlich. > > Das ist doch Quatsch. > Wieso sollten einfache lineare Adressräume und 8/16 Bit CPUs einander > ausschließen? Mit einem nur 16 Bit breiten Register kannst du 2^16-1 Byte ansprechen. Das sind 64 KiB, das war es. Der Rest geht dann nur über Segmente oder Bank Switching oder es wird höllisch ineffizient.
Nano schrieb: > Mit einem nur 16 Bit breiten Register kannst du 2^16-1 Byte ansprechen. > Das sind 64 KiB, das war es. Natürlich. Und wenn eine CPU mehr ansprechen können soll brauchts einfach entsprechend mehr Bits und Adresspins und keine wie auch immer gearteten Kunststückchen. Der Banking-Zirkus fand sich etwa auch in den ersten PICs. Damit hat es sich zum Glück in der Folge schnell aufgehört. Wohingegen ein Banking ganzer CPU-Registersätze zum schnellen Kontextwechsel in Interrupts/ im Multitasking eine gute Idee ist (wäre).
:
Bearbeitet durch User
Ben B. schrieb: > Den Sinn für diese Aufteilung habe ich auch nie verstanden, Ben B. schrieb: > Wie man sieht, irgendwie war das Modell Speichersegmentierung wohl > generell etwas scheiße, Na ja, wenn man Dinge nicht versteht, kann man auf merkwürdige Schlussfolgerungen kommen. Denk mal anders: was, wenn die Intel-Chipdesigner schon beim 8086 das Design des späteren 286 vor Augen hatten weil sie die B5500 kannten ? Es waren nur zu wenig Transistoren um die Segmentierung damals schon abzubilden. Aber man brauchte das Registermodell, und einen einfachen Weg es trotzdem funktional abzubilden. Da ist das reinaddieren der Segmentregister eine geniale Idee. Und was ist, wenn WindowsNT nur aus falschen Gründen die Segmentierung aufgab, und all ihre Vorzüge die z.B. Apple beim 68k mit R14 (register für data segment basis) softwaretechnisch simulieren musste aber keinen Hardwareschutz hatte, über Bord warf,; weil der Chefdesigner hinter NT zu dumm war. David Cutler kannte nur die VAX und favorisierte als DEC Mensch den ähnlichen DEC Alpha Prozessor auf dem seiner Meinung nach NT unbedingt laufen musste (was schnell wieder in der Versenkung verschwand) und hat NT gebaut in dem er hunderte Funktionen von VMS einfach rüberkopiert hat, unpassend wie sie waren, wie man noch heute an der Unzahl der unter Windows nicht ausgewerteten ehemaligen VMS Parameter erkennt. So ist Windows zu doof gewesen, 16 und 32 bit nahtlos zusammen arbeiten zu lassen, sondern hat 2 völlig getrennte Welten aufgesetzt, wie heute bei 64 bit gleich nochmal (man erinnere sich an ODBC, ODBC32 und ODBC32(64 bit) wo der Schwachsinn^3 mit thunking layers überdeutlich wurde). Nicht alles in der IT ist klug überlegt.
MaWin schrieb: > Da ist das reinaddieren der Segmentregister eine geniale Idee. Derlei "geniale" Ideen finden sich viele. Der Freak ist geradezu berauscht davon. Im Detail mögen es wirklich clevere Ideen sein. Mit etwas Abstand betrachtet sind es aber gerade sie, die (mit etwas Abstand betrachtet) gerade jene Schritte sind die dann in der Folge zu unnötig viel Komplexität führen. Dabei mögen oft kurzfristig zu erzielende Kostenvorteile eine Rolle spielen. Und doch dürfte aufwendigerer, dafür einfacher zu programmierender Hardware langfristig mehr Markterfolg beschieden sein.
Lust L. schrieb: > MaWin schrieb: >> Da ist das reinaddieren der Segmentregister eine geniale Idee. > > Derlei "geniale" Ideen finden sich viele. Der Freak ist geradezu > berauscht davon. Im Detail mögen es wirklich clevere Ideen sein. Mit > etwas Abstand betrachtet sind es aber gerade sie, die (mit etwas Abstand > betrachtet) gerade jene Schritte sind die dann in der Folge zu unnötig > viel Komplexität führen. Dabei mögen oft kurzfristig zu erzielende > Kostenvorteile eine Rolle spielen. Und doch dürfte aufwendigerer, dafür > einfacher zu programmierender Hardware langfristig mehr Markterfolg > beschieden sein. Und was hättest du als alternativ den mit einer begrenzten Transistoranzahl gemacht? Alle anderen CPU Designs, die zu dem Zeitpunkt, als der 8086 erschien, mehr Transistoren verballerten waren so sündhaft teuer, dass sie keine Zukunft hatten. Ist das dann besser? Zumal, Chipfläche war teuer, aber fähige Programmierer konnten auch mit Segmentierung weit kommen. Der 8086 wurde Marktführer und später, ab dem 386er war das x86 Design nicht mehr aufzuhalten. Das Geld dafür brachte der 8086.
Nano schrieb: > Und was hättest du als alternativ den mit einer begrenzten > Transistoranzahl gemacht? Die Dinge haben sich aus dem Chip-Urschleim nunmal so entwickelt und Nachher-Schläue ist viel einfacher als in eine ungewisse (wirtschaftlich/ technologische) Zukunft hin zu entwickeln. Insofern ist "Pfusch" wohl nicht ganz zu vermeiden. Trotzdem sollte man (wenn auch im Nachhinein) Pfusch als solchen bezeichnen dürfen. Sauber und bequem zu programmierende Hardware hat eben zu oft nicht die Priorität die sie wirklich haben sollte.
Nano schrieb: > Aber Bank Switching macht doch erst ab mehr als 64 KiB RAM Sinn, oder > meinst du damit das Switchen auf ROMs. ROM und/oder MMIO. Und ob das Bank-Switching Sinn ergibt, hängt nicht direkt von der Menge des RAM ab, sondern vielmehr vom erreichbaren Adressraum im Verhältnis zum benötigten Adressraum. Nicht immer sind 64k Adressraum erreichbar, selbst dann nicht, wenn die CPU selber 64k adressieren könnte. Es gab da oft aus Kostengründen Sparschaltungen (die dann später mittels Bank-Switching mühsam aufgebohrt werden mussten). Und übrigens gab (und gibt) es umgekehrt auch 8-Bitter, die mehr als 64k adressieren können. Die beiden Größen "8-Bit-CPU" und "64k-Adressraum" stehen in keinerlei kausalem Zusammenhang.
Lust L. schrieb: > Nano schrieb: >> Und was hättest du als alternativ den mit einer begrenzten >> Transistoranzahl gemacht? > > Die Dinge haben sich aus dem Chip-Urschleim nunmal so entwickelt und > Nachher-Schläue ist viel einfacher als in eine ungewisse > (wirtschaftlich/ technologische) Zukunft hin zu entwickeln. Insofern ist > "Pfusch" wohl nicht ganz zu vermeiden. Trotzdem sollte man (wenn auch im > Nachhinein) Pfusch als solchen bezeichnen dürfen. Sauber und bequem zu > programmierende Hardware hat eben zu oft nicht die Priorität die sie > wirklich haben sollte. Also hat du oben nur Unsinn geschwurbelt. Wusste ich es doch.
c-hater schrieb: > Die beiden Größen "8-Bit-CPU" und "64k-Adressraum" > stehen in keinerlei kausalem Zusammenhang. Das Problem ist das Laden der Adressregister, wenn sie breiter als 16 Bit sind. Das ist umständlich und dauert lang.
Nano schrieb: > Es hätte aber Vorteile, weil man so bspw. eine Hälfte einer Bank mit > wichtigen Funktionen dauerhaft einblenden könnte und nur die obere > Hälfte von anderen Bänken switchen müsste. CP/M 3 Wie bank switching ohne common memory sinnvoll funktionieren soll, möge hier bitte noch erläutert werden c-hater schrieb: > Kommt rein auf die Hardware an. Prinzipiell ist natürlich auch solcher > Schwachsinn möglich. Macht bloß niemand, der noch alle Latten am Zaun > hat... Ja, Gary Kildall war vermutlich ein Vollidiot. Ist es das, was Du uns mitteilen möchtest?
hex-fan schrieb: > Das Problem ist das Laden der Adressregister, wenn sie > breiter als 16 Bit sind. Das ist umständlich und dauert lang. Das kommt doch nur auf den Befehlssatz an. Auch das Laden (oder In-/De-krementieren) eines Register-Paars muss ja bei einer 8Bit-CPU irgendwie besonders unterstützt werden, wenn es einigermaßen effizient sein soll. Und ganz genauso geht das halt prinzipiell auch für Register-Triples oder -Quads. Genau deswegen: es gibt keinen direkten Zshg. zwischen "8-Bit-CPU" und "64k-Adressraum". Der "natürliche" Adressraum einer 8-Bit-CPU wären 256 Byte. Das ist, was mit einem Register abbildbar ist.
c-hater schrieb: > Der "natürliche" Adressraum einer 8-Bit-CPU wären 256 Byte. Das ist, was > mit einem Register abbildbar ist. Und schon sind wir bei der Zero-Page (Zwei- statt Drei-Byte Befehlen) und der Page 1 für den Stack samt 8bit Stackpointer.
Nano schrieb: > Ein 32 Bit OS wie Windows NT braucht allein schon 4 MiB für die Page > Table. Nein. Diese Zahl gilt für die dort beschriebene single level page table. 386 verwendet jedoch das dort ebenfalls beschriebene hierarchische Verfahren.
Percy N. schrieb: > Ja, Gary Kildall war vermutlich ein Vollidiot. Ist es das, was Du uns > mitteilen möchtest? Keine Ahnung, hab' den Namen nie gehört. Musste erstmal ein wenig recherchieren, wer das war. Aber mein Recherche-Ergebnis sagt: ja, das war wohl tatsächlich irgendwie ein Idiot. In vieler Hinsicht. Was mir allerdings bei meiner Recherche nicht klar geworden ist: Was genau hatte er speziell mit dem Thema "Bank-Switching" zu schaffen? Erfunden hat er es zumindest sicherlich nicht...
MaWin schrieb: > So ist Windows zu doof gewesen, 16 und 32 bit nahtlos zusammen arbeiten > zu lassen, sondern hat 2 völlig getrennte Welten aufgesetzt OS/2 integrierte ab 2.0 sowohl 16- als auch 32-Bit Komponenten und Anwendungen in einer Welt. Den Ansatz von NT, ein reines 32-Bit System zu schaffen, halte ich für wesentlich besser. Zum Problem kommt es nämlich, wenn 16-Bit Komponenten auf Speicher zugreifen sollen, der zu einer 32-Bit Anwendung gehört. Dann wird's schrecklich.
c-hater schrieb: > Der "natürliche" Adressraum einer 8-Bit-CPU wären 256 Byte. Das ist, was > mit einem Register abbildbar ist. Wobei sich das auf Adressregister und Adressverarbeitung bezieht. Die Breite der Datenverarbeitung ist irrelevant. Die Breite des Datenbusses ist es ebenso.
c-hater schrieb: > Was mir allerdings bei meiner Recherche nicht klar geworden ist: Was > genau hatte er speziell mit dem Thema "Bank-Switching" zu schaffen? > Erfunden hat er es zumindest sicherlich nicht... Du scheinst recht umfassende Bildungslücken mit Dir herumzutragen. Warum wohl hatte ich CP/M 3 erwähnt? c-hater schrieb: > ja, das war wohl tatsächlich irgendwie ein Idiot. In vieler Hinsicht. Damit scheinst Du offenbar besonders vertraut zu sein, Schwätzer!
Percy N. schrieb: > Du scheinst recht umfassende Bildungslücken mit Dir herumzutragen. Warum > wohl hatte ich CP/M 3 erwähnt? Nunja, kann sein das DIR CP/M 3 irgendwie wichtig ist. Für mich war das aber niemals wichtig (und wird es wohl auch niemals werden). Übrigens geht es vermutlich 99,9% der Weltbevölkerung genauso wie mir. Sprich: du hast da wohl ein kleines Problem mit einem deutlichen Tunnelblick...
Lust L. schrieb: > Nano schrieb: >> Und was hättest du als alternativ den mit einer begrenzten >> Transistoranzahl gemacht? > > Die Dinge haben sich aus dem Chip-Urschleim nunmal so entwickelt und > Nachher-Schläue ist viel einfacher als in eine ungewisse > (wirtschaftlich/ technologische) Zukunft hin zu entwickeln. Insofern ist > "Pfusch" wohl nicht ganz zu vermeiden. Trotzdem sollte man (wenn auch im > Nachhinein) Pfusch als solchen bezeichnen dürfen. Sauber und bequem zu > programmierende Hardware hat eben zu oft nicht die Priorität die sie > wirklich haben sollte. Ziemlich unwissendes gequassle! Schau dir mal ne Preisliste von z.B. 1978 an: 4 KB RAM Speichererweiterungen für die damaligen Computer so etwa um die 3000 DM (etwas durchblättern ...) http://www.cc-computerarchiv.de/CC_SELLER_BC_PDF/CC_SELLER_BC_1978.pdf Ergibt für 64KByte RAM so etwa 20000 bit 24000 DM (je nach Hersteller), zu dieser Zeit definitiv zu teuer für "daheim". Standard "daheim" waren so 1 bis 2 k RAM, also noch weit weit entfernt vom 16-Bit Addresraum limit; also nix Pfusch - damals konnte sich halt noch keiner die Speicherzukunft so richtig vorstellen!
c-hater schrieb: > Sprich: du hast da wohl ein kleines Problem mit einem deutlichen > Tunnelblick... Nein, warum sollte ich unter Deinem Tunnelblick leiden? Deine alberne Anmaßung kann mich auch nicht tangieren, damit machst Du Dich bur lächerlich. Business as usual.
> Das Problem ist das Laden der Adressregister, wenn sie > breiter als 16 Bit sind. Das ist umständlich und dauert lang. Das ist dann aus meiner Sicht wieder eine Schwäche des Befehlssatzes. Man kann mit dem x86 z.B. auch rein in 8bit rechnen wenn man das lustig findet (MOV AL,8bit). Genauso könnte man auch die Segmentregister auslegen wenn man so eine CPU designed. Oder allgemein gesagt, ich verstehe wirklich nicht, wieso man die Segmentregister nicht einfach "on top" auf die 16bit Basisregister gesetzt hat, sondern sie da irgendwo mitten rein addiert (mit der Wertigkeit 16). Die Segmentregister sind auch beim x86 schon umständlich zu bedienen. Sowas wie MOV DS,0 oder ADD DS,irgendwas kann die CPU nicht. Das muss man - egal obs sinnvoll ist oder nicht, das ergibt sich aus der Anwendung - auf Umwegen machen, z.B. über den Stack oder über bestimmte Basisregister. Da gibts vieles, was der x86 kann und vieles, was er nicht kann. Was die Software angeht... das ist ein allgemeines Problem. Keines was jetzt direkt mit den Adressmodi einer CPU zusammenhängt. Aber wenn ich ein großes kommerzielles Produkt wie beispielsweise Windows schreiben möchte, was nutzt mir das, wenn es nur auf den neuesten Maschinen läuft? Das kauft niemand, das bringt Unsicherheit ("Geht das auf meinem Computer? Ich will keinen neuen kaufen.") und gerade im Office-Segment laufen viele ältere Maschinen. Die waren gerade in den Anfängen von Windows alle mal teuer und als elektronische Schreibmaschine sind sie viele Jahre schnell genug. Also wieso sollte ich da auf 32bit programmieren, wenn ich damit alle alten 16bit Maschinen ausklammere und die 32bit eigentlich gar nicht brauche um etwas Text wegzuspeichern und auszudrucken. Heute ist das anders, jede Mühle kann 64Bit-Befehle, es ist egal ob ich 64bit verwende oder nur 32bit wenns reicht. Jetzt fangen ja eher die Probleme in die andere Richtung an, daß aktuelle Betriebssysteme keine alten 16-Bit-Programme mehr zulassen. Viele alte Spiele laufen nur noch im DOS-Emulator. In der Wissenschaft sieht's auch wieder anders aus. Wenn ich da sehr mit sehr großen Zahlen oder extrem hoher Genauigkeit hantieren muss, dann sind 32 Bit schnell zu wenig, genauso 64 Bit. Da kann man quasi niemals genug von haben wenn man Performance will. Jede Zahl, die sei es wegen Genauigkeit oder wegen ihrer enormen Größe nicht mehr in ein Register passt, muss ich mir im Hauptspeicher zusammenbasteln und darunter leidet natürlich die Performance. Das ist immer so, kann man als einschränkenden Faktor heutiger CPU-Architektur sehen. Als Win95 damals erschien, war das für manche Hardware auch eine ziemliche Herausforderung. Es gab dann von vielen Spielen eine Win95- und eine DOS-Version, wobei die DOS-Version häufig eine bessere Performance hatte (meistens wohl weil Windows nicht den ganzen Speicher belegte) und man daher regelmäßig Win95 beendete und das Spiel unter DOS laufen ließ. Das hat sich erst geändert, als Windows die DirectX-Komponente mitbrachte, bzw. Direct3D. Es gab zwar oft immer noch eine DOS-Version, denn nicht jeder hatte eine Grafikhardware, die sich für DirectX eignete, aber die Windows-Version sah ab dem Moment halt schöner aus oder gewann an Performance und das Potential neuerer Grafikkarten war auch nur noch unter Windows nutzbar, was das Ende der DOS-Versionen bedeutete. Das könnte man jetzt noch einen Schritt weiter ausführen, denn DirectX 10 lief dann auch nicht mehr unter Win98 oder XP, man brauchte Win7 oder das ungeliebte Windows Vista. Für WinXP oder früher war bei DirectX 9.0c Schluss.
Entspannungswandler schrieb: > Standard "daheim" waren so 1 bis 2 k RAM, also noch weit weit entfernt > vom 16-Bit Addresraum limit; also nix Pfusch Schau noch mal genau was ich konkret mit Pfusch bezeichnet habe.
Lust L. schrieb: > Entspannungswandler schrieb: >> Standard "daheim" waren so 1 bis 2 k RAM, also noch weit weit entfernt >> vom 16-Bit Addresraum limit; also nix Pfusch > > Schau noch mal genau was ich konkret mit Pfusch bezeichnet habe. Ich bleib dabei: du redest unqualifizierten Quark aus deiner limitierten heutigen Sicht heraus. Es gab damals halt die etablierten CPUs mit 16-Bit Adressraum. Die CPUs mit mehr Addressraum waren damals schlicht und einfach zu Teuer für Privat. Als dann die Speicherpreiss günstiger und günstiger wurden ergibt sich Banking logisch als kostengünstige Alternative. Pfusch war das ganz und gar nicht sondern notwendig.
Entspannungswandler schrieb: > Pfusch war das ganz und gar nicht sondern notwendig. Daß es Beweggründe gegeben haben mag auf diesen Banking-Pfusch zu setzen hatte ich gar nicht bestritten. Dennoch bleibt Pfusch Pfusch- weil letztlich unnötig, unsauber, umständlich. Mit dem sich verbilligenden Speicher wurden durchaus auch CPUs günstiger. Hier hätte man gleich auf eine saubere, lineare Speicher-Lösung setzen sollen statt fortlaufend zu verschlimmbessern und die überflüssigen Segmentierungs/Banking- Krücken bis in heutige CPU Zeiten mitzuschleppen.
Entspannungswandler schrieb: > Schau dir mal ne Preisliste von z.B. 1978 an: > 4 KB RAM Speichererweiterungen für die damaligen Computer > so etwa um die 3000 DM (etwas durchblättern ...) Das war so sehr grob ein/zwei Jahre nachdem ich mir meinen ersten scamp zusammen gelötet hatte und dann nicht lang danach auf MOS6502 wechselte.(Ich mochte schon damals die Segmentierung des scamp nicht, obwohl die erst bei 4k gegriffen hätte) Ich erinnere mich ja nicht mehr an vieles aus der Zeit, aber ich bin mir verdammt sicher das ich damals keine 750DM für 8Stück 2102 (1k*1bit) gezahlt hatte. Auch ein kompletter KIM-1 lag in zumindest erschwinglichen Bereichen.
Norbert schrieb: > Ich mochte schon damals die Segmentierung des scamp nicht, > obwohl die erst bei 4k gegriffen hätte Wurde das wirklich als Segmentierung bezeichnet? Auf mich wirkt das eher als Switching zwischen 16 Bank zu 4 KB. Da der SC/MP seitens des Herstellers m.E. eher die Controller-Schiene adressierte, werden die oft mit 4 KB ausgekommen sein. Dass Elektor den etwas aufblies, weil verglichen mit 8080 und 6800 bezahlbar, steht auf einem anderen Blatt. Der 6502 drückte den Preis massiv und war die deutlich bessere Lösung.
:
Bearbeitet durch User
Ben B. schrieb: >> Das Problem ist das Laden der Adressregister, wenn sie >> breiter als 16 Bit sind. Das ist umständlich und dauert lang. > Das ist dann aus meiner Sicht wieder eine Schwäche des Befehlssatzes. > > Man kann mit dem x86 z.B. auch rein in 8bit rechnen wenn man das lustig > findet (MOV AL,8bit). Genauso könnte man auch die Segmentregister > auslegen wenn man so eine CPU designed. Oder allgemein gesagt, ich > verstehe wirklich nicht, wieso man die Segmentregister nicht einfach "on > top" auf die 16bit Basisregister gesetzt hat, sondern sie da irgendwo > mitten rein addiert (mit der Wertigkeit 16). Wie schon erwähnt benötigt man dadurch sehr wahrscheinlich weniger Transistoren oder Datenleitungen. Segment und Offset muss die CPU schließlich intern miteinander verrechnen um eine 20 Bit Adresse zu erhalten.
(prx) A. K. schrieb: > Zum Problem kommt es nämlich, wenn 16-Bit Komponenten auf Speicher > zugreifen sollen, der zu einer 32-Bit Anwendung gehört. Dann wird's > schrecklich. Wenn man schlecht designt. Gut designt man ein 32 bit Betriebssystem, dass 16 bit Programme laufen lässt. Die Daten werden vom Programm angelegt, sind also zugreifbar. Externe Daten, z.B. vom Ethernet geliefert, werden in Puffer des Aufrufers kopiert. Und schon ist alles ganz einfach.
(prx) A. K. schrieb: > Wurde das wirklich als Segmentierung bezeichnet? Auf mich wirkt das eher > als Switching Es hatte mit Segmenten so rein gar nichts zu tun. Es wurde auch als page bezeichnet.
(prx) A. K. schrieb: > Wurde das wirklich als Segmentierung bezeichnet? Auf mich wirkt das eher > als Switching zwischen 16 Bank zu 4 KB. Ja, das stimmt wohl. Unglückliche Wortwahl. Die Unterlagen von NS hatte ich damals alle mit weggegeben, kann nicht mehr nachschauen wie das seinerzeit genannt wurde. Die A4 Unterlagen von MOS (die Blauen) habe ich noch heute!
Lust L. schrieb: > Entspannungswandler schrieb: >> Pfusch war das ganz und gar nicht sondern notwendig. > > Daß es Beweggründe gegeben haben mag auf diesen Banking-Pfusch zu setzen > hatte ich gar nicht bestritten. Dennoch bleibt Pfusch Pfusch- weil > letztlich unnötig, unsauber, umständlich. Mit dem sich verbilligenden > Speicher wurden durchaus auch CPUs günstiger. Für die Heimcomputerverwertung waren vor dem 68k von Motorola 32 Bit CPUs anfangs noch zu teuer und mit Bankswitching konnte man 16 Bit CPUs verwenden und denen so trotzdem mehr als 64Kib RAM spendieren. > Hier hätte man gleich auf > eine saubere, lineare Speicher-Lösung setzen sollen statt fortlaufend zu > verschlimmbessern Das gab es dann mit dem Atari ST und Amiga 1000 sowie Macintosh, die alle die 68K CPU von Motorola verwendete. > und die überflüssigen Segmentierungs/Banking- Krücken > bis in heutige CPU Zeiten mitzuschleppen. Die x86 CPUs mussten abwärtskompatibel zur Software sein. Beim IBM PC und kompatiblen war zu dem Zeitpunkt DOS das Maß der Dinge und das Softwareangebot gigantisch, sogar gigantischer als anfangs das Softwareangebot für CP/M. Ein 386er, der kein DOS ausführen kann, hätte keiner gekauft. Und 32 Bit x86 Betriebssysteme gab es zu dem Zeitpunkt auch noch keine. Xenix war 16 Bit. Man hätte mit dem Entfernen des Virtual 8086 Mode bis ca. 1995, eher sogar 3 Jahre später warten müssen, aber das war dann viel zu spät, weil der Real Mode DOS Softwarebestand da dann noch größer war.
Ben B. schrieb: > Oder allgemein gesagt, ich > verstehe wirklich nicht, wieso man die Segmentregister nicht einfach "on > top" auf die 16bit Basisregister gesetzt hat Weil man das nicht allzu beliebte Bankswitching nicht wollte? Allerdings hatte Intel den 8086 nicht für hundert Lebensjahre konzipiert, sondern für einige wenige. Das Ziel war iAPX 432, der 8086 bloss ein Zwischenschritt. Nie davon gehört? Muss man auch nicht, ausser man stellt solche Fragen. ;-)
:
Bearbeitet durch User
Lust L. schrieb: > Hier hätte man gleich auf > eine saubere, lineare Speicher-Lösung setzen sollen statt fortlaufend zu > verschlimmbessern und die überflüssigen Segmentierungs/Banking- Krücken > bis in heutige CPU Zeiten mitzuschleppen. Jaja. Wenn man immer darauf warten würde, dass die optimale, bis in alle Ewigkeit ausreichende Lösung existiert und sie obendrein auch nicht wesentlich teuerer ist als der aktuelle "Pfusch", dann würden wir heute noch in Höhlen leben. Wenn überhaupt... Merke: die ganze Menschheitsgeschichte lang hat immer nur der schnelle und billige Pfusch die Fortschritte gebracht. Denn der setzte immer die Maßstäbe, an der dann Besseres wachsen konnte. Bis das aber gewachsen war, konnte man immerhin schon den "Pfusch" benutzen...
Lust L. schrieb: > Daß es Beweggründe gegeben haben mag auf diesen Banking-Pfusch zu setzen > hatte ich gar nicht bestritten. Dennoch bleibt Pfusch Pfusch- weil > letztlich unnötig, unsauber, umständlich. Unnötig war der "Pfusch" höchstens für Wohlhabende. Ich hatte damals einen Apple II mit Language-Card, bei dem mittels "pfuschigem" Bank-Switching 64K RAM, 12K ROM und 4K I/O-Space im 64K-Adressraum des 6502 untergebracht waren. Eigentlich war das völlig unnötig, denn es gab ja schließlich auf dem MC68000 basierende Workstations von Apollo und Sun, die ohne diesen "Pfusch" auskamen. Leider haben diese Rechner locker das Zehnfache eines Apple gekostet, weswegen ich den "Pfusch" als absolut notwendig empfand. Wenn es dir anders erging/ergeht, bist du entweder steinreich oder blutjung :)
Yalu X. schrieb: > Unnötig war der "Pfusch" höchstens für Wohlhabende. Wer sich bei Mercrdes keinen professionellen Reisebus leisten kann, der muss sich halt mit einer zusamnengepfuschten S-Klasse begnügen und mit der deutlich niedrigeren Transportleistung abfinden ;-)))
Yalu X. schrieb: > Bank-Switching 64K RAM, 12K ROM und 4K I/O-Space im > 64K-Adressraum des 6502 untergebracht waren. Dazu habe ich mal eine Frage. Wie muss man sich das dann vorstellen, also wie genau war das gelöst? Variante 1: Bezüglich der Einblendung in den 16 Bit Adressraum wurde zwischen 64 KiB RAM, 12K ROM und 4K I/O-Space umgeschaltet. Also so, dass, wenn das 12K ROM aktiv war kein RAM verfügbar war. Kann das sein? Irgendwie nicht, oder wie hat man sonst Daten ausgetauscht, etwa nur über Register? Variante 2: Bezüglich der Einblendung in den 16 Bit Adressraum wurde zwischen 64 KiB RAM, 12K ROM und 4K I/O-Space umgeschaltet und zwar so, dass das RAM zumindest als 64 KiB - 12K ROM Größe verfügbar war. Also so per Bank Switching wahlweise wie man es gerade braucht: A) 64 Kib RAM komplett B) 52 Kib RAM + 12K ROM C) 60 Kib RAM + 4K I/O D) 48 KiB RAM + 12K ROM + 4K I/O Variante 3: 12 K ROM und 4 K I/O-Space waren fest und dauerhaft in den Adressraum eingeblendet, weswegen man nur 48 KiB RAM nutzen konnte. Oder doch eine andere Variante?
Die 48K RAM auf dem Mainboard (0000-BFFF) und die 4K I/O-Space (C000-CFFF) sind immer da. Gebankswitcht werden nur die oberen 12K, wo sich normalerweise das ROM befindet. Die 16K-RAM-Erweiterung kann man sich in drei Blöcke zu 4K, 4K und 8K unterteilt vorstellen. In den obersten 8K des Adressraums (E000-FFFF) kann man zwischen dem entsprechenden ROM-Bereich und dem 8K-Block des RAM umschalten. In dem darunterliegenden 4K-Bereich (D000-DFFF) kann man zwischen dem entsprechenden ROM-Bereich und einem der beiden 4k-Blöcke des RAM umschalten. Dann gibt es noch einen Modus, bei dem Lesezugriffe im Bereich von D000-FFFF) zum ROM und Schreibzugriffe zum RAM geleitet werden.
Noch etwas: Dann waren praktisch nur 4 KiB RAM, deren Adressraum vom 4K I/O-Space ständig belegt war, nicht benutzbar.
Ja, es sind maximal 60K RAM gleichzeitig sichtbar. Den I/O-Space braucht man u.a. für die Bildschirmausgabe, und auch die Hardwareregister für die Steuerung das Bank-Switching liegen in diesem Bereich. Würde man ihn ausblenden, könnte man ihn deswegen höchstens durch einen Reset wieder aktivieren.
c-hater schrieb: > Wenn man immer darauf warten würde, dass die optimale, bis in alle > Ewigkeit ausreichende Lösung existiert Ein linearer Adressraum ohne Banking-Zirkus war ist und bleibt kein unerreichbarer Traum.
> Ein linearer Adressraum ohne Banking-Zirkus > war ist und bleibt kein unerreichbarer Traum. Spätestens wenn Du mehr Speicher brauchst als Deine CPU intern addressieren kann, hast Du keine andere Wahl. Irgendwo müssen ja die zusätzlichen Addressbits herkommen.
Ben B. schrieb: > Spätestens wenn Du mehr Speicher brauchst als Deine CPU intern > addressieren kann, hast Du keine andere Wahl. In 8-16-bit Zeiten verwendete man, wenn der Code nicht in den Programmsspeicher oder -Adressraum passte, oft Overlays. Da wurde ohne jede Hardware-Unterstützung ein Teil des Programmcodes in mehrere Sektionen aufgeteilt, die den gleichen Adressraum nutzten und sich gegenseitig ersetzend bei Bedarf nachgeladen wurden. https://de.wikipedia.org/wiki/Overlay_(Programmierung)
:
Bearbeitet durch User
(prx) A. K. schrieb: > In 8-16-bit Zeiten verwendete man, wenn der Code nicht in den > Programmsspeicher oder -Adressraum passte, oft Overlays. Da wurde ohne > jede Hardware-Unterstützung ein Teil des Programmcodes in mehrere > Sektionen aufgeteilt, die den gleichen Adressraum nutzten und sich > gegenseitig ersetzend bei Bedarf nachgeladen wurden. Zu ergänzen: Bankswitching ermöglicht es, die Overlays gleichzeitig im Soeicher zu halten; etwas ausgefeilter per MMU.
Ben B. schrieb: > Spätestens wenn Du mehr Speicher brauchst als Deine CPU intern > addressieren kann nehm ich eine andere CPU! Im übrigen sollten 64 Bit (heutzutage) für jeden Zweck ausreichen. Ich weiß nicht warum Pfusch- Lösungen hier immer noch so geheiligt werden. Ist es der Hirn-Schmalz den mancher Teilnehmer da zur Genüge reingesteckt haben mag?
:
Bearbeitet durch User
Lust L. schrieb: > Im übrigen sollten 64 Bit (heutzutage) für jeden Zweck ausreichen. Lies doch wenigstens mal den Eröffnungsbeitrag (der erste Satz genügt schon): Nano schrieb: > Mal eine Frage an diejenigen, die (früher) in Assembler mit Bank > Switching (z.B. beim C128) und der Segment:Offset Adressierung der x86 > Prozessoren im Real Mode gearbeitet haben. heutzutage ≠ früher
Lust L. schrieb: > Ben B. schrieb: >> Spätestens wenn Du mehr Speicher brauchst als Deine CPU intern >> addressieren kann > > nehm ich eine andere CPU! Die es damals nicht gab oder sündhaft teuer waren. > Im übrigen sollten 64 Bit (heutzutage) für jeden Zweck ausreichen. Heutzutage ist nicht gestern. Und heutzutage spielen Kosten bei Massenproduktion und Energie sparen immer noch eine Rolle, weswegen einer 8 oder 16 Bit CPU einer fetten 64 Bit CPU der Vorzug gegeben wird. Jedes vermeidbare Bit benötigt nämlich eine Vielzahl von Transistoren die alle Strom brauchen. Und beim Preis entscheidet immer noch die Fläche.
Lust L. schrieb: > Ich weiß nicht warum Pfusch- Lösungen hier immer noch so geheiligt > werden. Ist es der Hirn-Schmalz den mancher Teilnehmer da zur Genüge > reingesteckt haben mag? Ich weiß nicht, warum manche hier auf so hohem Ross aufzutrumpfen versuchen. Irgend einen Grund wird das haben, aber den möchte man wahrscheinlich gar nicht wissen.
Yalu X. schrieb: > Lust L. schrieb: >> Im übrigen sollten 64 Bit (heutzutage) für jeden Zweck ausreichen. > > Lies doch wenigstens mal den Eröffnungsbeitrag (der erste Satz genügt > schon): Du verlangst zuviel. Das zeigt sich schon beim ersten Wort, einem Imperativ. Unterstellend bzw. voraussetzend das eine solche Tätigkeit einfach zu bewerkstelligen wäre.
Lust L. schrieb: > Ein linearer Adressraum ohne Banking-Zirkus war ist und bleibt kein > unerreichbarer Traum. Ist halt die technisch primitivste Lösung, aber die Klimmzüge um in ihm per Hardware abgesichert Programme mit Speicherschutz, Betriebssystemaufrufen, Mapping von Code von der Platte in den Speicher, virtualisierung etc. zu erreichen sind halt blöd. Und das alles nur, weil die Logik der Hardware nicht mit der Logik der Verwendung zusammenpasst. So muss man seitenweise verwalten (4k page, 4MB Programm = 1000 Deskriptoren) und code beim Laden patchen und hat trotzdem nicht so schöne Einrichtungen wie gates und getrennten heap und stack.
MaWin schrieb: > So muss man seitenweise verwalten (4k page, 4MB Programm = 1000 > Deskriptoren) und code beim Laden patchen und hat trotzdem nicht so > schöne Einrichtungen wie gates und getrennten heap und stack. Segmentierung ist ein sehr schönes Konzept, wenn man es auf Objektebene betreibt und die Adressarithmetik den Segment-Teil nicht anfasst. Buffer overflows sind dann Geschichte. Der Aufwand steigt jedoch, die Performance kann darunter leiden und man benötigt eine recht andere ISA als das, womit wir es zu tun haben. Reduziert auf einige wenige Segmente wie Code, Stack, Heap, Data, Const gewinnt man dadurch vergleichsweise wenig. Mit Gates verhält es sich ähnlich. Auch die sind eher nett gemeint als wirklich nützlich, wenn man es eilig hat. Was man schon daran erkennt, dass mit AMD64 eine völlig anderer und weitaus schnellerer Weg zum Wechsel in den Kernel eingeschlagen wurde. Solche Konzepte laufen in die beliebten Kategorien RISC/CISC und Schönheit/Effizienz. Hohe Komplexität im Microcode eines Prozessors, für solche Operationen wie Gates, ist summarum weniger effizient, verglichen mit Prozessoren, die nur die Grundfunktionen implementieren, und komplexe Funktionen der Software überlassen. Es hat einige Anläufe gebraucht, bis jeder Hersteller das gelernt hatte.
:
Bearbeitet durch User
Yalu X. schrieb: > Lies doch wenigstens mal den Eröffnungsbeitrag (der erste Satz genügt > schon) Ich gebe eine Antwort auf die darauf folgende Frage. Keine der Varianten ist besser! (prx) A. K. schrieb: > Segmentierung ist ein sehr schönes Konzept Bei soviel Liebe zum überflüssigen Detail fehlen mir dann alle weiteren Worte. MaWin schrieb: > Lust L. schrieb: > >> Ein linearer Adressraum ohne Banking-Zirkus war ist und bleibt kein >> unerreichbarer Traum. > > Ist halt die technisch primitivste Lösung, aber die Klimmzüge um in ihm > per Hardware abgesichert Programme mit Speicherschutz, > Betriebssystemaufrufen, Mapping von Code von der Platte in den Speicher, > virtualisierung etc. zu erreichen sind halt blöd. Mal einer der in der Sache Argumente bringt. Zu "technisch primitiv" fällt mir nur ein: "Keep it simple". Zum Rest kann mir keiner erklären daß sich bestimmte festzulegende Speicherbereiche konstruktiv nicht mit entsprechenden Attributen belegen ließen. Das geht mit dem Ziel eines durchgehend linearen Speichers nicht konträr. So, nun möchte ich die Liebe der Freaks zu komplexen Lösungen nicht weiter stören.
Lust L. schrieb: > (prx) A. K. schrieb: >> Segmentierung ist ein sehr schönes Konzept > > Bei soviel Liebe zum überflüssigen Detail fehlen mir dann alle weiteren > Worte. Nur scheinst du überhaupt nicht gemerkt zu haben, dass du mit "keep it simple" im Grunde das gleiche geschrieben hast wie ich. ;-)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Lust L. schrieb: > >> (prx) A. K. schrieb: >>> Segmentierung ist ein sehr schönes Konzept >> >> Bei soviel Liebe zum überflüssigen Detail fehlen mir dann alle weiteren >> Worte. > > Nur scheinst du überhaupt nicht gemerkt zu haben, dass du mit "keep it > simple" im Grunde das gleiche geschrieben hast wie ich. ;-) Das mag damit zusammenhängen, dass Präferenz für linear adressierbaren Speicher mitinter einwm linearen Verstand entspringen könnte.
Percy N. schrieb: > Das mag damit zusammenhängen, dass Präferenz für linear adressierbaren > Speicher mitinter einwm linearen Verstand entspringen könnte. Wenn's in der Sache eng wird wird's halt persönlich ;-)
Lust L. schrieb: > Percy N. schrieb: > >> Das mag damit zusammenhängen, dass Präferenz für linear adressierbaren >> Speicher mitinter einwm linearen Verstand entspringen könnte. > > Wenn's in der Sache eng wird wird's halt persönlich ;-) So zum Beispiel? Blind F. schrieb: > Dein Horizont scheint nicht über den Rand eines Bierglases hinaus zu > reichen in dem Du auf dem Boden sitzt, Blind F. schrieb: > Sie es wie es sei, das Du Dich hier her-umtreibst wundert mich > angesichts Deines elektronischen Analphabetismus schon eine geraume > Zeit.
> nehm ich eine andere CPU! Foul. Du spielst Fußball auch nicht mit 20 Toren. > Im übrigen sollten 64 Bit (heutzutage) für jeden Zweck ausreichen. Da kann ich mich an einen tollen Spruch erinnen, in etwa sowas wie "niemand braucht mehr als 640kb RAM in seinem PC". Wer sich damit ein kleines bißchen geirrt hat, kannst Du selbst googlen. Zur Adressierung mögen 64bit im Moment locker für alles ausreichen. Könnte in 10 Jahren auch anders aussehen. Aber sobald ich in Richtung Zahlentheorie möchte, bestes Beispiel Primzahlsuche und Primfaktorzerlegung oder sowie ich eine sehr hohe Genauigkeit bei Berechnungen brauche, verliere ich sehr schnell sehr viel Geschwindigkeit wenn die Zahlen nicht mehr in die Prozessorregister passen und ich gezwungen bin, im Hauptspeicher zu rechnen. Ich hätte z.B. auch nicht gedacht, daß ich einige meiner super-alten PHP-Projekte mal auf MySQLI portieren muss. Oder alles, was der Einfachhalt halber Unix-Zeitstempel benutzt, wird 2038 ein Problem bekommen wenn die verwendeten 32bit Integer nicht mehr reichen. Da wären 64bit auch besser gewesen, hat 1970 aber niemand dran gedacht.
Ben B. schrieb: > Zur Adressierung mögen 64bit im Moment locker für alles ausreichen. > Könnte in 10 Jahren auch anders aussehen Ach so. Dann brauchts den Banking-Pfusch also weiterhin willst Du wohl damit sagen? Hier gehts doch nicht drum ob irgendeine Hardware zukünftig noch reicht. Hier gehts drum was bereits möglich ist und was es dazu braucht. Daß Banking längst überflüssig ist sollte man schon zuzugeben bereit sein. Und daß es jederzeit nur eine Krücke war auch. > Da wären 64bit auch besser gewesen, hat 1970 aber niemand dran gedacht. Wenn man aber 1970 oder wann auch immer die Notwendigkeit zu mehr Speicher sah hätte man das ebensogut mit einem größeren Adressbereich der CPU lösen können statt kunstvoll umständliche Banking Methoden zu bemühen. Was ist daran bloß so schwer zu verstehen?
:
Bearbeitet durch User
Lust L. schrieb: > Und daß es jederzeit nur eine Krücke war auch. Eher eine Problemlösung. Also eher etwas für Ingenieure als für Installateure. Lust L. schrieb: > Wenn man aber 1970 oder wann auch immer die Notwendigkeit zu mehr > Speicher sah hätte man das ebensogut mit einem größeren Adressbereich > der CPU lösen können statt kunstvoll !!! > umständliche Banking Methoden zu > bemühen. Dafür hätte man eine andere CPU gebraucht. > Was ist daran bloß so schwer zu verstehen? Ja, das fragt man sich.
:
Bearbeitet durch User
> Und daß es jederzeit nur eine Krücke war auch.
Genau das ist Blödsinn. Ich weiß nicht wieso Du so einen Hass auf bank
switching schiebst. Wenn ein Prozessor nunmal nur 16 Adressleitungen
hat, dann hat er nur 16 Adressleitungen. Wenn der nun aus irgend einem
Grund mehr Speicher bekommen soll (wie beispielsweise der C64), was
machst Du ohne bank switching? Erfindest Du extra dafür einen neuen
Prozessor? Oder bohrst Du beim alten das Gehäuse auf und klebst 'ne
zusätzliche Leitung an den Die?
Übrigens, man kann das Problem auch atomar aufdröseln. Alle
Adressleitungen außer A0 sind praktisch nichts anderes als bank
switching für A0. Prinzipiell ist auch A0 selbst schon bank switching,
ein Speicherbaustein legt Dir dadurch wahlweise Datenwort 0 oder
Datenwort 1 an den Datenbus, aber niemals beide gleichzeitig oder was
immer Du Dir wünschst.
Deinen Hass auf die Speichersegmentierung bzw. "alles was nicht model
flat ist", könnte ich noch am ehesten verstehen.
Also - ich verstehe Dein Problem nicht.
Lust L. schrieb: > Daß Banking längst überflüssig ist sollte man schon zuzugeben bereit > sein. Unsinn, wie immer. Gründe (Embedded Systeme, Massenprodukte usw.) habe ich dir ja oben schon genannt. Dazu kommen tut nun aber noch etwas: "In addition many embedded systems are real-time systems and overlays provide more determinate response-time than paging. For example, the Space Shuttle Primary Avionics System Software (PASS) uses programmed overlays.[" https://en.wikipedia.org/wiki/Overlay_(programming)#Applications Fazit: Sieh es ein, du hast keine Ahnung worüber hier gesprochen wird.
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.