2. Interview mit Thomas Richter, Entwickler der mmu.library Thomas Richter werkelt derzeit an der mmu.library, die für Entwickler unentbehrlich werden könnte. Er hat den Sourcecode von Enforcer von Manfred Sinz erhalten, die Software als MuForce und den ersehnten und nie fertiggestellten GuardianAngel als MuGuardianAngel nachprogrammiert. Da sie von der MMU Gebrauch machen (mmu.library), übersteigen sie die alten Tools in ihrer Effizienz um Größenordnungen. Es könnte sogar von Speicherschutz gesprochen werden. Thomas Richter: Wenn ich hier schon mal dazwischenbrabbeln darf: (-: Ich würde nicht soweit gehen und von Speicherschutz sprechen. Unter Speicherschutz verstehe ich, dass Programm A nicht in den Daten von Programm B herumfuhrwerken kann, und umgekehrt. Leider ist das Amiga- Betriebssystem aber so aufgebaut, dass alle Programme auf einen gemeinsamen Speicherbereich zugreifen, man spricht auch von "shared memory". Das bedeutet insbesondere, dass ein Task problemlos Speicher allozieren kann, diesen an einen zweiten Task weiterreichen kann, und der Speicher dann von einem dritten Task freigegeben wird, ohne dass das OS von der Weitergabe der Resourcen erfahren muss. Die Effizienz des Amiga-OS begründet sich nicht zuletzt auf diesem Mechanismus - es müssen zur Kommunikation zwischen Prozessen, also Tasks, keine großen Datenmengen umgeschaufelt werden. Dies war bei der Einführung von AmigaOS auf einem einfachen 68000 mit 7MHz Takt von Bedeutung, an Speicherschutz hatte damals noch niemand denken wollen oder können - er lag in unnahbarer Ferne. Leider hat sich dieses Konzept heutzutage überlebt. AMIGA aktuell: Für den normalen User ist dies zwar keine Alternative, da das System durch dieses Tool stark abgebremst wird. Für Amiga-Softwareentwickler bedeutet dies jedoch ohne Frage eine Revolution. Unterstützt werden alle 68k-MMUs, von 68551 (020) bis 68060. Thomas Richter: Die Idee von MuGuardianAngel ist nicht neu, sie ist recht alt, und dieses Tool ist nicht die erste Implementierung der Idee, wie Sie ja schon oben bemerken. Die erste Version eines solchen Tools wurde seinerzeit von CBM intern verwendet, ich weiß aber nicht, wer das Programm geschrieben hat (Mike Sinz?). Leider hat es nie richtig funktioniert und die Entwicklung wurde eingestellt, so dass sonst niemand - und ich schließe mich hier ein - dieses Programm jemals zu Gesicht bekommen hat. Im Cyberguard findet sich mit der "Guard"-Option ein ähnliches Werkzeug, und auf dem Aminet gibt es ebenfalls ein GuardianAngelRemix. Allerdings sind dies alles "stand-alone" Tools, die sich nicht in eine Reihe von untereinander kompatiblen Tools eingliedern lassen und die zum Teil nicht einmal, wie der Cyberguard, kompatibel zur eigenen Firmware sind - ppc.library und Cyberguard GUARD laufen nicht zusammen. Ich denke, dass "Otto Normaluser" ein solches Tool normalerweise nicht verwenden wird, genausowenig wie er - oder sie - den Enforcer oder MuForce wird laufen lassen. Für Software-Entwickler ist es aber dennoch von einigem Interesse, so hoffe ich zumindest. AMIGA aktuell: Für User ist diese Library ebenfalls von großer Bedeutung. Viele Anwendungen/Tools werden durch diese Library erst sauber zu realisieren bzw. überhaupt erst ermöglicht werden. Warum haben Sie sich entschieden, an der mmu.library 'rumzuwerkeln'? Thomas Richter: Die neueren Amiga-Modelle haben mit der MMU - und was das ist sage ich vielleicht unten - ein Stück Hardware, das sehr effizient zur Speicherverwaltung verwendet werden kann. Diverse Programme verwenden die MMU demgemäß für ihre Zwecke, angefangen mit dem Enforcer zum Aufspüren von Fehlern in der Software, weiterhin der OxxyPatcher, Systeme, die "virtuellen Speicher" implementieren, diverse Emulatoren und einiges mehr. Leider gibt es im gesammten Amiga-Betriebssystem keine dokumentierte Schnittstelle für diese Hardware, so dass Tool A nicht mit Tool B kompatibel ist und man nur mit etwas Glück eine hoffentlich einigermaßen stabile Konfiguration hinbekommt. Die augenblickliche Situation ist etwa so absurd als würde man den Amiga ohne die Graphikbibliothek ausliefern und jedes Programm müsste seine Fenster selbst mit der Hardware malen. Es ist insofern nur zu leicht verständlich, dass das nicht wirklich klappen kann. Was hat mich nun persönlich dazu bewogen, dies zu ändern? Nunja, als Mathematiker habe ich vielleicht ein berufsbegründetes Interesse an kniffligen Problemen und deren Lösung, vielleicht kann man es so ausdrücken. Das Problem ist einerseits schwierig genug, um interessant zu sein, und andererseits dringend genug, um gelöst zu werden. Für einen Hobbyprogrammierer reicht dies als Motivation aus. Würden wirtschaftliche Interessen eine Rolle spielen, so dürfte man heute auf dem Amiga wohl gar nichts mehr schreiben, so bedauerlich das ist. AMIGA aktuell: Was erhoffen Sie sich dadurch? Thomas Richter: Ein konsistentes Interface zur MMU und damit eine Serie von Tools und Applikationen, die für den Benutzer problemlos zusammenarbeiten - und nicht zuletzt habe ich wieder etwas zum Herumkniffeln lerne eine ganze Menge neues über die Hardware. Letztendlich bekomme ich auch Tools, die mir selbst bei der eigenen Entwicklerarbeit helfen. AMIGA aktuell: Seit wann entwickeln Sie an dieser Library? Thomas Richter: Die Idee zur mmu.library trage ich schon seit mehr als einem Jahr in meinem Kopf herum. Auslöser diese Library nun wirklich zu schreiben, war eine Diskussion in der News-Group comp.sys.amiga.programmer, insbesondere mit Karl Uwe Lockhoff und vielen mehr. Das Design der Library war knifflig genug, so dass ich erst nach gründlichem Überlegen im Herbst/Winter letzten Jahres damit angefangen habe, sie zu implementieren, und, dank vieler hilfsbereiter Leute, zu testen - an dieser Stelle nochmal einen herzlichen Dank an die Gemeinde netter Tester, deren Rechner und Festplatten ich in Beschlag nehmen durfte. Es wäre wohl weitaus schwieriger geworden! AMIGA aktuell: Werden alle 68k-MMUs vollständig unterstützt? Gibt es vielleicht kleine Einschränkungen? Nicht alle unsere Leser sind mit dem Begriff 'MMU' vertraut. Könnten Sie bitte kurz die Funktionsweise erläutern? Thomas Richter: Es werden alle verfügbaren Mc68Ks unterstützt, angefangen von der 68851, die externe MMU des 68020, bis zum 68060 - die Unterstützung der MMUs ist so komplett, wie ich sie machen konnte, angefangen von der Möglichkeit, mehrere MMU-Tabellen zu erstellen und damit jedem Task im Prinzip seinen eigenen Addressraum zu geben - interessant für Emulatoren z.B. - über die Programmierung der Seitengröße der MMU innerhalb des technisch Möglichen bis zur Verwaltung der MMU-Ausnahmezustände wie etwa ausgelöst durch Zugriffe auf geschützte Speicherbereiche. Z.B. enthält der "Enforcer" - oder "MuForce", wie das Programm jetzt heißt, enthält demnach keinerlei CPU/MMU spezifischen Code mehr, es verwendet allein ein konsistenten Softwarelayer der Library. Da sich die einzelnen MMUs zum Teil etwas unterscheiden, gibt es natürlich ein paar Einschränkungen, das ist klar. Das Interface soll - muss - ja immer das gleiche bleiben, so dass ich zum Teil gewisse Features einer MMU auf einer anderen emulieren muss, sofern dies überhaupt möglich ist. Ohne jetzt wirklich ins Detail gehen zu wollen, sonst werde ich zu technisch, unterstützt die Library zum Beispiel keine der exotischeren Features der 68851-MMU, da diese auf keinem anderen Mitglied der MC68K-Familie auch nur annähernd vorhanden sind oder durch Trickserei eingebaut werden könnten. Für die oben genannten Applikationen sind diese Spezialitäten auch nur von geringem Interesse. Eine weitere große Einschränkung ist die Unterstützung eines PPC mit der ppc.library, d.h. durch PowerUp. Da man sich seitens P5 geweigert hat, mir die ppc-Library-Internals zu dokumentieren, wird es hierzu entgegen meiner ursprünglichen Planung keinerlei Support geben. WarpUp wird im Gegensatz dazu jedoch unterstützt, einfach weil es sehr viel sorgfältiger und mit Bedacht implementiert ist, so dass ich mich letztendlich gar nicht um eine Sonderbehandlung des PPC habe bemühen müssen - es funktioniert "auch so". Da jedoch von Frank Wille eine Emulation der ppc.library für WarpUp entwickelt wird, stellt dies hoffentlich auch keine wirkliche Einschränkung dar. Eventuell wird es auch Unterstützung für einen von der PPC CPU emulierte 68040 geben, sollte es überhaupt Bedarf für eine solche "Sonderbehandlung" geben. Ein drittes Problem sind Festplattenkontroller mit DMA, die entgegen den Richtlinien gewisse Os-Funktionen nicht aufrufen. Für den Normalbetrieb der Library und der Tools ist dies relativ bedeutungslos, aber z.B. Anwendungen, die etwa mit der MMU den Speicher defragmentieren, also eine effizientere Speicherverwaltung implementieren, werden dann mit diesen Boards nicht funktionieren - etwas dieser Art gibt es im Augenblick sowieso noch gar nicht. Dies betrifft einerseits wieder die Boards von P5, sowie GVP-Adapter. Letztere können durch Aufrüsten mit dem Guru-ROM allerdings "MMU-tauglich" gemacht werden, nichtzuletzt weil sich Ralph Babel netterweise so hilfsbereit zeigte und mir einige Internals dokumentierte. Bekannte PIO- Adapter wie das bekannte oktagon.device von Oliver Kastl haben hiermit überhaupt keine Probleme, das Problem entsteht konstruktionsbedingt gar nicht. Vielleicht nun zur letzten Frage, die ich zuerst hätte beantworten müssen: MMU bedeutet "memory management unit", etwa "Einheit zur Speicherverwaltung". Die MMU ist eine der eigentlichen Recheneinheit vorgeschaltete Logik - heutzutage meist in gleichen Chip untergebracht - die alle Speicherzugriffe abfängt, ggf. umlenkt, ggf. der CPU das Schreiben auf die Speicherbereiche verbietet, die Art, wie die CPU mit dem eingebauten Cache umgeht, kontrolliert und einiges mehr. Zugriffe der CPU auf den Speicher werden gewissermaßen durch die MMU "zensiert", so dass eine Speicheraddresse, wie sie einem Programm erscheint, nicht mit der physikalischen Speicheraddresse übereinstimmen muss, die auf dem Bus des Rechners zu sehen ist. Die MMU kann somit etwa RAM auf die Addressen des Kickstart-ROMS "spiegeln" und damit langsamere ROM-Zugriffe durch schnellere RAM-Zugriffe erstetzen. Das bekannte "CPU FastROM" in der Startup-Sequence macht genau dies. Beim "Enforcer" wird z.B. der Zugriff auf nicht existente Speicherbereiche gesperrt, so dass fehlerhafte Software damit einen Ausnahmezustand auslöst und damit seinerseits den Enforcer zum "Meckern" bringt. AMIGA aktuell: Welche Rolle kann diese Library/die MMU für das AmigaOS spielen, da die Implementierung von z B. Speicherschutz eh nicht möglich ist? Thomas Richter: AmigaOS wird meiner Einschätzung nach sowieso keine Rolle mehr spielen, insofern wird die Library vermutlich auf dem "Hobby"-Niveau verbleiben. Ich würde mich natürlich über Interesse seitens kommerzieller Softwarehersteller freuen, aber aufgrund der Marktposition des Amigas halte ich das für extrem unwahrscheinlich. Einerseits hilft die Library dem Entwickler durch Bereitstellen von entsprechenden Tools, andererseits hilft sie durch Bereitstellen von Funktionen, die bislang nur schwierig oder gar nicht, oder nur unter Kompatibilitätseinbußen zu erreichen waren. Typische Anwendungen der mmu.library - neben den oben genannten Entwicklertools - wären etwa Emulatoren oder Programme, die in einer "rauhen" Umgebung arbeiten müssen und demnach aktiv vor der Modifikation durch fehlerhafte Software - oder zum Teil sogar durch sich selbst - geschützt werden wollen. Debugger oder Mailbox-Systeme und Server kommen mir da in den Sinn. Dieser Schutz muss aber explizit von der mmu.library angefordert werden, erfolgt also nicht automatisch durch das Os, und erfordert ebenso eine geeignete Programmgestaltung. Ein gewisser Vorläufer zur Nachbearbeitung von Programmen liegt dem augenblicklichen Archiv in Form des "MuLink" Programmes bereits vor, allerdings erfolgt der Programmschutz nur soweit Kompatibilitätsprobleme dies zulassen und ist damit unvollständig. Letztendlich muss der Entwickler einer Software zur Library greifen und selbst tätig werden. AmigaOS lässt sich nachträglich ein *automatischer* Schutz nicht aufstülpen. AMIGA aktuell: Was exakt bedeutet die Library für den Entwickler und für den User (abgesehen von bugfreier Software)? Thomas Richter: Für den Entwickler schnelleres Finden von Fehlern, ganz klar. Für den User ein Bundle von "Power-Software", die garantiert zusammenarbeitet und sich nicht untereinander von den Resourcen abschneidet oder sich selbst auf die Füße trampelt. Erste Schritte dazu gibt es bereits mit den "MuTools", einer der Distribution beigelegten Toolsammlung mit "typischen" MMU-Anwendungen vom ROM-Remapper bis zum Enforcer-artigen Debugging Tool. Im Grunde genommen ist dies die Motivation der Library: Eine vernünftige Plattform schaffen, auf der aufbauend - entsprechend einer Graphikbibliothek - Applikationen miteinander die MMU ausnutzen und ausreizen können. Letztendlich bedeutet das auch, dass sich Programmideen realisieren lassen, die vorher in dem Maße nicht möglich waren, oder nur mit einer ungleich längeren Entwicklungsarbeit und Spezialversionen für jeden Prozessor und jede Konfiguration. Dieser Entwicklungsvorteil ist dann letztendlich auch ein Vorteil für den "Endverbraucher", so hoffe ich zumindest. AMIGA aktuell: Wann wird es eine erste öffentliche Release geben? Thomas Richter: Die Releases sind bereits öffentlich auf meiner Homepage (http://www.math.tu-berlin.de/~thor/thor/index.html; Anm. d. Red.) abzugreifen, und die stabilieren Versionen erscheinen regelmäßig auf dem Aminet, wobei ich mich allerdings etwas zurückhalte. Ich möchte das Aminet einfach nicht mit "beta"-Software überschwemmen, einfach weil "beta = beta than nothing" für "Otto Normaluser" Enttäuschungen bedeuten können. Es ist einfach noch nicht alles in dem Maße getestet, wie es getestet sein sollte. Vom Umfang der Library ist das augenblickliche Release - die 0.35 - schon komplett. Sollten sich nicht irgendwelche neuen Schwierigkeiten einstellen, so hoffe ich, dass eine Gamma-Version in einem Monat und die endgültige Version im August oder September verfügbar sein wird. AMIGA aktuell: Welche Entwicklung kann man in Verbindung mit der mmu.library noch erwarten? Vielleicht eine memory.library, neue 680x0-Libs? Thomas Richter: Ich werde vermutlich noch eine "Virtual Memory" Applikation schreiben, die wieder auf einer Bibliothek aufbauen wird, dies ist die geplante "memory.library", die Sie erwähnen. Diese Bibliothek wird natürlich wieder auf der "mmu.lib" aufbauen. Auf der "memory.library" aufbauend plane ich einen VMM-artigen Patch, der "virtual memory" auch für die üblichen Applikationen bereitstellt, allerdings mit den damit verbundenen "Risiken und Nebenwirkungen", die ein solcher Patch mit sich bringt. Ob es eine neue 68040.library geben wird, habe ich noch nicht entschieden. Im Prinzip wäre es nötig, da die augenblicklichen Versionen Dinge "doppelt" machen - eine rudimentäre MMU-Verwaltung nämlich - die die mmu.library besser und komfortabler erledigen kann. Gewisse Programmteile der 68040.library, wie z.B. die Emulation einiger FPU (Fließkomma) Befehle finden sich auf den Motorola-Seiten und liegen bereits auf meinem System. Ob ich mich einmal an die Implementierung wage, steht allerdings noch in den Sternen. Eine 68060.library werde ich leider nicht schreiben können, da mir einfach ein entsprechendes '060-basiertes System fehlt - es war knifflig genug, den MMU-Support für einen Prozessor zu schreiben, den ich nicht habe und auf dem ich demnach nicht testen kann, nicht zu reden von dem Aufwand, die FPU-Emulation "blind" zu stricken. Das ist mir dann doch ein paar Nummern zu groß. AMIGA aktuell: Wird bzw. könnte es einen PowerPC-Port geben? Thomas Richter: Ja und nein. Ich denke, ich werde versuchen, die mmu.library unter einer PPC-Emulation zum Laufen zu bekommen. Dazu sollte nicht allzuviel zu tun sein, da die von Sam Jordan entwickelte 68040-Emulation sehr vollständig ist - vermutlich beschränkt es sich auf das Anpassen einiger Details in der Verwaltung von MMU-Ausnahmezuständen, wenn ich überhaupt irgendetwas anpassen muss. Es wird aber vermutlich keine mmu.library auf der PPC-Seite geben, einfach weil WarpOS schon selbst Funktionen zur Programmierung der MMU bereitstellt und die Library damit einfach unnötig ist. Über den Umfang der MMU- Unterstützung seitens WarpOs kann ich allerdings recht wenig sagen, da ich mich noch nicht eingehend damit beschäftigt habe, wie die PPC MMU funktioniert. Sie unterscheidet sich von der MC68K MMU konzeptionell doch ein wenig, insofern lassen sich die Designgrundlagen der mmu.library nicht notwendig vollständig auf den PPC übertragen. AMIGA aktuell: Vielen Dank für das Interview. Ich wünsche Ihnen alles Gute! Thomas Richter: Vielen Dank auch für Ihr Interesse und weiterhin viel Spaß! Das Interview wurde geführt von Sofiane Ben Hassine. |