Ja, der letzte Beitrag ist schon fast 3 Jahre her - ich weiß.
Aber da wäre noch etwas nicht ganz Unwichtiges anzumerken (#151).
Jesterfox schrieb:
Hauptproblem ist einerseits eine Eigenheit der alten ARM bei der Adressierung, Adressregister ist 32Bit, Adressleitungen gab es nur 24. Dadurch existierten da 8 ungenutzte Bits mit denen manche Programmierer Schindluder getrieben haben was auf modernen ARM-Prozessoren jetzt einem auf die Füße fällt.
Also "Schindluder" war es wohl nicht, denn die 8 Bits waren keineswegs ungenutzt, sondern beinhalteten die Flags und wurden somit permanent durch das System neu beschrieben!
Die ARM-Ingenieure wollten ihrem Prozessor kein eigenes Flag-Register spendieren, sondern verfrachteten es in das Register R15, welches ansonsten den Programmzähler (PC-Register) beherbergte. Das klingt nicht nur aus heutiger Sicht nach einem reichlich skurilen Einfall. Man muß daher etwas weiter ausholen, um die für diese Entscheidung grundlegende Logik erklären zu können.
Der ARM war ja von Anfang an als reinrassiger 32-Bit-Prozessor konzipiert. Andererseits waren Anfang der 90er Jahre die Computer gerade erst dabei die Megabyte-Marke beim RAM zu überschreiten. Arbeitsspeicher in Gigabyte bemessen erschien damals nicht bloß utopisch, sondern geradezu wie Science-Fiction. Acorn spendierte daher seiner aktuellen Rechnergeneration mit zunächst RISC OS 2, dann RISC OS 3 einen großzügig bemessenen Adressraum von insgesamt 64 MB. Davon war ein Viertel für physikalisches RAM reserviert.
(Mehr als 8 MB hat meines Wissens kein einziges Modell spendiert bekommen, die allermeisten wiesen nur 1 bis 2 MB auf. Meiner besaß die anfängliche Maximalgröße von 4 MB, die ich im Betrieb gern mit einer 2 MB-RAMdisk auffüllte; so riesig fühlte sich das damals an).
Zum Vergleich: die in den 80er Jahren vorherrschenden 8-Bit-Rechner hatten einen 16-Bit-Adressraum. Die Computer besaßen jedoch schon sehr bald deutlich mehr Speicher als die damit adressierbaren 64 KB. Um dieses Dilemma zu lösen, gab es die Technik des Bank- bzw. Blockswitching. Auf dieser Grundlage wurden stets immer nur
die 16K-Blöcke eingeblendet, die gerade benötigt wurden. Und nun hatte sich die Problematik plötzlich umgedreht; es gab nun viel mehr Adressen, als überhaupt durch realen Speicher belegt werden konnte.
Wer nachrechnet, wird jetzt einwerfen, dass man mit 24 Bit nur 16 MB adressieren kann und nicht 64 MB.
Stimmt.
Aber der ARM war ja grundsätzlich 32 Bit; also nicht nur Daten, sondern auch Adressen und sogar alle Opcodes (inklusive implizite Datenwerte!).
Alle Zugriffe erfolgten somit über
gerade Word-Adressen. Die Adressbits 0 und 1 waren somit immer null. Daher war der 24-Bit-Adressraum im Bereich von eigentlich 0-23 generell nach 2-25 verschoben. Es wurden also effektiv nicht 16 MB Bytes adressiert, sondern 16 MB Words und ergo halt 64 MB.
Somit gehörten Bit 0 und 1 sowie Bit 26-31 im PC-Register zum Flag-Register (PSR genannt). Das macht sich etwas seltsam, weil das PSR quasi in zwei Teilbereiche zerstückelt erscheint. Aber man darf sich den Registerinhalt nicht wie eine Linie, sondern mehr wie einen Ringpuffer vorstellen. So gesehen grenzen die oberen und unteren PSR-Bits direkt aneinander und bilden damit eine zusammenhängende Einheit. Jedenfalls bietet der Befehlssatz der ARM2/3-Prozessoren Kommando-Varianten mit denen man auf den Inhalt von Register R15 jeweils als Ganzes, nur den PC-Teil oder nur den PSR-Teil effizient zugreifen konnte.
Vielleicht fragt man sich, wie denn der ARM-Prozessor dann auf eine Byte-genaue Adresse zugreifen kann. Angenommen es soll das Byte an Adresse 3 gelesen werden. Dann holt der ARM das Word an Adresse 0, rotiert den Dateninhalt um 3 Bytes nach rechts und löscht die oberen 24 Bit im Zielregister. Und das ohne irgendwelchen zeitlichen Mehraufwand. Heißt also, die Bereitstellung eines Words geht genauso schnell wie die Bereitstellung eines einzelnen Bytes.
Ja, der ARM war schon ohne Übertreibung gesagt, ein Traum für Assembler-Programmierer! Obwohl das RISC-Konzept nicht unbedingt für Assembler-Komfort ausgelegt war, war es der ARM im Endeffekt dann doch. Zum Vergleich: in den 80ern hatte ich Maschinensprache am Z80-Prozessor kennen- und schätzen gelernt. Aber während man am Z80 immer auch etwas '
jonglieren' mußte (also auch befehlsoptimiert zu denken hatte), konnte man dank des intuitiven, geradlinigen Befehlssatzes des ARM den Code rein problemorientiert umsetzen. (Es gab daher auch weniger Flüchtigkeitsfehler.) Man darf nicht vergessen, in den ersten Jahrzehnten der Heimcomputer-Ära war Assemblerprogrammierung noch voll angesagt (nicht nur wegen Speed-Optimierung).
Mitte der 90er Jahre hatte das
'großzügige' 64-MB-Konzept aber bereits ausgedient. Die neuen ARM-Prozessoren unterstützten nun den vollen 32-Bit-Adressraum. Wie dieses Problem dann im technischen Detail im Hinblick auf Kompatibilität für die bestehende Software gelöst wurde, habe ich nicht weiter verfolgt. Mir war klar geworden, dass mein erster Acorn-Rechner auch mein letzter sein würde. Denn nachdem auch die '
Wunderwaffen' in Gestalt der neuen RISC-PC-Rechnergeneration sowie des (damals) superschnellen StrongARM-Prozessors den Untergang von Acorn nicht mehr aufhalten konnte, beschloß ich, meinen '
alten' Acorn-Compi bis zu seinem Ende weiter zu behalten und zu nutzen und dann auf PC umzusteigen.
Was ich damals nicht vorhergesehen hatte, war, dass die Community um RISC OS (,dem Betriebsystem für Acorn-Rechner mit ARM-Prozessoren), das Ende von Acorn um Jahrzehnte überdauern würde. Entscheidend war wohl letztendlich der Umstand, dass man sein Heil in der Entproprietärisierung gesucht und gefunden hat.
Was ich Anfang dieses Jahrtausends auch noch nicht wußte, war, dass ich noch nicht einmal die Hälfte meiner Zeit am (ehemaligen) Acorn-Compi abgesessen hatte. Zwar war das physikalisches Gerät damals bereits kurz vorm Exitus (Festplatte kaputt, Maus zerschlissen, Monitor mit gelegentlichen Bildflackern - und Ersatz war natürlich nicht zu bekommen), aber da gab es ja noch den '
VirtualA5000'-Emulator, den ich mir gleich nach Umstieg auf den PC für teures Geld gekauft hatte. Eine absolut lohnende Investition! Denn es war so, als hätte ich mir meinen Acorn-Rechner nochmals funkelnagelneu gekauft, aber mit mehr als 10-facher Geschwindigkeit und maximalen Arbeitsspeicher von nun 16 MB.
Mancher wird vielleicht sagen: kein Kunststück einen Rechner mit einer Taktfrequenz von 16 Mhz auf einem Host mit mehr als 2.000 Mhz so performt betreiben zu können!
Aber. Emulation ist was anderes als Virtualisierung. Letzteres geht davon aus, dass natives und virtuelles System auf einem eng verwandten Hardware-Konzept beruhen und somit für den Betrieb das Gastsystems direkt auf die Ressourcen des Hosts zugegriffen werden kann. Emulation aber meint die Umsetzung eines Rechners komplett in Software. Sowas jedoch frisst die Rechenleistung des Hosts tonnenweise. Der '
VirtualA5000'-Emulator verdankt seine beeindruckende Performance daher nicht zuletzt der '
Dynamic Recompilation'. Das heißt, die Übersetzung von ARM-Code findet unmerklich schon
vor Programmausführung statt (und nicht etwa währenddessen wie bei einem Simultan-Dolmetscher).
Es ist schon irgendwie blanke Ironie, wenn man sich klar macht, dass man die Programme, die man gerade in ARM-Assembler unter dem Emulator schreibt, in Wahrheit für die in den 90er Jahren als lahm verachteten PC-Prozessoren codiert!
Allerdings verfasste ich das meiste in meiner Emulatorzeit in BASIC. Denn noch stärker als der virtuelle ARM-Prozessor profitierte BASIC vom speed-optimierten Konzept des Emulators.
Somit lohnte es sich kaum noch, Programmcode in Assembler zu verfassen. Das beschränkte sich dann auf Betriebssystemerweiterungen und ähnlichem.
Darüber hinaus ist das BBC-BASIC in der Version V/VI beileibe kein primitiver Kram für '
Spaghetti-Code'. Es verfügte nämlich über alle Mittel zur struktuierten Programmierung (Funktionen und Prozeduren, globale und lokale Variablen, globale und lokale Fehlerabfangroutinen, lageunabhängigen Programcode - somit keine Zeilenummerierung bzw. Verweise). Und nicht zuletzt über einen
Inline-Assembler. Das geniale daran: man konnte alle BASIC-Befehle zusätzlich für die Struktuierung des Assemblercodes nutzen. Sowas muss man gesehen haben, was das in der Praxis für Vorteile bietet!
Aber das sind dann wieder ganz andere Themen.
