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.
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!"
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.
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).
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.
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. ;-)
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.
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)
(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?
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.
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. ;-)
(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?
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.
> 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.
