ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
[Login] [Registrieren] [Passwort vergessen?] |
| |||
29.Nov.2001 Christoph Gutjahr |
Übersetzung des Statements zum OS4 der Frieden-Brüder Thomas und Hans-Jörg Frieden haben kürzlich in einer Newsgroup ausführlich auf diverse Fragen zu OS4 geantwortet. Im Folgenden die Übersetzung der wichtigsten Punkte (die einzelnen Beiträge wurden der Übersichtlichkeit halber neu gruppiert). 68k Emulator, Kompatibilität: Wie sieht es mit meiner 68060/50-604e/233 Combo aus... Welche Geschwindigkeit kann ich vom emulierten 060 im Vergleich zu meinem echten 50 Mhz. 060 erwarten? Schwer zu sagen. Der JIT ist noch in Arbeit, und die resultierende Geschwindigkeit hängt stark von dem Programm ab, welches du laufen lässt - es gibt Fälle, in denen die Geschwindigkeit eines echten 68060/50 erreicht wurde, manchmal aber auch nur die eines 68040/30. In jedem Fall gibt es noch sehr viele Möglichkeiten zur Optimierung. Wie bei jeder Art von Emulation, könnten Statistiken dabei helfen, die meist benutzten Befehle zu finden, und diesen spezielle Optimierungen zukommen zu lassen. Habt ihr irgendeinen Überblick (Prozentzahlen) darüber, welche Spiele mit dem 68k Emulator nicht mehr funktionieren werden? Nein, der Emulator entwickelt sich ja immer noch weiter. Außerdem werden wir etwas einbauen, über das ich jetzt noch nicht sprechen kann. Nur soviel: Wir werden die Möglichkeit haben, maximale Kompatibilität bei maximaler Performance sicherzustellen. Ich denke nicht, dass mehr als 1% des alten Code nicht funktionieren wird. Wenn das AmigaOS sich von der Abhängigkeit von den Custom Chips befreit, werden wir dann Kompatibilitätsprobleme bekommen, was Spiele angeht? Wir haben den Autor von WHDLoad kontaktiert, wir werden sehen, was dabei herauskommt. Ein anderes potentielles Problem ist, dass manche Programme unschöne Dinge mit Exec anstellen. Beispielsweise wühlen manche Programme in der Memory List von Exec herum. Natürlich ist das schlechter Programmierstil, aber einige Spiele machen das so, und das wird mit OS4 nicht mehr funktionieren, da das Memory System komplett durch das neue VM-System ersetzt wird. Wir werden einen kleinen (in der Größe veränderbaren) Memory Pool für "altes Zeug" beibehalten (z.B. kann Chip-RAM nicht virtuell sein, deswegen wird es wohl weiterhin in seiner alten Form vorhanden sein). Was ich jedoch am meisten fürchte sind Programme, die beispielsweise Stack Frames oder ähnliches voraussetzen. Das wird voraussichtlich fehlschlagen... Jemand, der für OS4 entwickeln möchte, sollte zunächst mal eine Datei lesen, die auf allen Developer-CDs zu finden ist, sie heißt FuturOS oder so ähnlich. Sie hat immer noch ihre Gültigkeit und informiert über eine ganze Reihe von Dingen, die für die Kompatibilität mit zukünftigen OS-Versionen entscheidend sind. Ehrlich, OS4 wird immer noch AmigaOS sein. Das heißt, es wird immer noch sehr klein und effizient sein. Die Tatsache, dass wir virtuellen Speicher haben werden, wird es nicht in Windows verwandeln. Ihr werdet weiterhin keine 70 MB zum Booten brauchen, wie bei Windows98... Der Speicherverbrauch wird im Vergleich zu OS 3.1 etwas ansteigen (hauptsächlich, da PPC-Code größer ist als 68k-Code), aber die Geschwindigkeit wird ebenfalls ansteigen... Denkt daran, wir haben einen PowerPC, eine sehr mächtige CPU, und diesmal können wir sie ohne den Bremsklotz 68k benutzen... Die meisten Programme werden laufen, allerdings werden solche, die beispielsweise direkt in das ROM springen - mit ExecBase herumwursteln - mit Intuition herumwursteln - usw. Probleme haben. Ich fürchte, es wird einige Programme geben, die nicht funktionieren werden, aber das ist unvermeidbar, ansonsten würden wir einen Haufen altes Zeug bis in alle Ewigkeit mit uns herumschleppen. Über die neue Exec Linrary: Basiert ExecSG auf der von AROS geleisteten Arbeit? Nein, ExecSG wird eine komplett neue Implementation sein. Die Exec von AROS ist ein Clone der alten Exec, aber ExecSG wird eine Menge neuer Features bekommen: Neues Library-Konzept, Hardware Abstraction Layer (Hardware Abstraktions Schicht) usw. Werden meine alten PowerUp ELF Programme auf diesem System funktionieren? Eure Lösung ist doch WarpUp-kompatibel, oder? [snip] Was PowerUp angeht, muss ich zugeben, dass ich nicht weiß, wie es arbeitet, aber ich bin sicher, dass es kein Probleme wäre, sie einzugliedern. Wir denken über eine Art Plugin-Schnittstelle für den Lader nach, der es erlauben würde, ein kleines Programm zu schreiben, dass einen bestimmten Dateityp lädt. Das würde beispielsweise bedeuten, dass Java JAR-Dateien, Shell-Skripte oder jegliches Binärformat transparent gehandhabt werden könnte. Wird AmigaOS4 intelligent genug sein, um trotz virtuellem Speicher keine Prozedur ähnlich "Herunterfahren" bei Windows zu benötigen? Nein, ein Herunterfahren wird nicht nötig sein. Die Auslagerungsdatei sollte auf einer speziellen Partition gespeichert werden, und diese wird neu initialisiert werden, wenn das System hochfährt, da das Speicherabbild dann sowieso unbrauchbar sein wird. Das bedeutet, du kannst den Rechner sogar dann ausschalten, wenn er gerade einen Schreibzugriff auf den virtuellen Speicher macht - Es kann kein Filesystem beschädigt werden, da ja überhaupt kein Filesystem beteiligt ist. Wo liegen die Vorteile von virtuellem Speicher gegenüber dem Spooling von der Festplatte? Spooling von der Festplatte ist beinahe immer die langsamere Lösung. Zum einen liegen Dateien auf der Festplatte meist nicht in einem Format vor, das das jeweilige Programm direkt nutzen kann. Beispielsweise könnten Sound-Dateien kodiert/komprimiert sein, und sie von Festplatte zu laden bedeutet, sie zu dekodieren/dekomprimieren. Virtueller Speicher schreibt einfach nur ein Abbild des Speichers auf die Festplatte und liest es wieder ein, wenn es benötigt wird - keine Notwendigkeit etwas zu konvertieren. Virtueller Speicher hat nicht so viel mit Magie zu tun, wie es zunächst erscheinen mag. Das neue Speicherverwaltungssystem wird nicht länger (wie es das alte System tut) jeden kleinen Speicherblock von der Memory List allozieren, es wird Page-basiert arbeiten. Das wird auch der Fragmentierung vorbeugen: Viele kleine Speicher-Allozierungen werden in Pages gesammelt (sehr ähnlich der derzeitigen Funktionsweise von Memory Pools). Wenn dem System die verfügbaren Pages ausgehen, werden die Pages aus dem Hauptspeicher ausgelagert, die länger nicht mehr benutzt wurden. Natürlich wird dem System der Speicher ausgehen, wenn auf der Swap-Partition kein Speicher mehr zur Verfügung steht, und die Allozierung wird fehlschlagen. Du kannst dir vorstellen, dass es nicht kompliziert ist, das Swapping abzuschalten: Wenn der physikalische Speicher ausgeht, und Swapping ausgeschaltet ist, wird eine Fehlermeldung ausgegeben, genauso als wäre die Swap-Partition voll. Das einzige Problem beim kompletten Abschalten des VM-Systems tritt auf, wenn ein großer Task bereits virtuellen Speicher belegt. Wird in diesem Fall das VM-System ausgeschaltet, muss der Task seinen virtuellen Speicher wieder in den physikalischen Speicher verlegen, und dafür könnte nicht genug Platz vorhanden sein (vergiss' nicht, dass du mit virtuellem Speicher Prozesse starten kannst, die ein Vielfaches des zur Verfügung stehenden physikalischen Speichers benötigen). Natürlich kannst du dann den entsprechenden Task einfach abschalten. Was auch gesagt werden sollte ist, dass die Allozierung von Speicher unter der absoluten Kontrolle der Applikation steht. Es wird ein zusätzliches Memory Flag geben, das Speicher-Allozierungen davon abhält, virtuell zu werden. Generelle Dinge Sind mit der neuen Multi-Plattform Strategie überhaupt noch Optimierungen möglich, oder wird es sich um C-Code handeln, der ein einziges Mal kompiliert wird? Es wird, soweit möglich, Optimierungen geben, aber der größte Teil wird reines C sein. Der HAL (Hardware Abstraktions-Schicht) wird der kritischste Teil einer Portierung sein. Übrigens, obwohl die Voraussetzungen vorhanden sind, ist derzeit keine Portierung nach (z.B.) x86 geplant (ich höre die Frage schon kommen :), da unsere Lizenz nur PPC abdeckt. Wie wird dieses neue System mit dem VP (AmigaDE) integriert? Wird es zwei Arten von Libraries geben? Zwei Arten von ausführbaren Dateien? VP-Routinen von außerhalb der AmigaDE Umgebung aufzurufen, ist unmöglich. Ich denke nicht, dass ein solcher Mechanismus existiert. Das DE wird bis zu einem bestimmten Grad integriert sein, aber es wird mehr oder weniger eine BlackBox bleiben, ein Rechner im Rechner sozusagen. Ich mag das Screens-Prinzip (besonders ziehbare Bildschirme, das ist aber kein Muss). Ich kann ohne eine dynamische Ramdisk nicht leben, ich mag Push/Pull Gadgets usw. - Intuition/Gadtools benötigt sicher eine kosmetische Komplettüberholung, aber die Funktionalität ist ziemlich genau die, die ich von einer GUI erwarte. Wie wird OS4.0 im Vergleich aussehen? Das Screens-Konzept ist immer noch Bestandteil von Intuition und wird es auch bleiben. Wir planen eine weitgehende Überarbeitung von Intuition, aber das wird bis nach dem ersten Release warten müssen. Modernere GUI-Klassen sind nötig, und eine komplette Überarbeitung zugunsten eines Skin-fähigen, skalierbaren Benutzerinterfaces. Kickstart ROMs WARUM BLOSS gibt es kein neues Kickstart ROM? Ich habe die Patches und Basteleien satt, die meinen Rechner resetten, bevor er überhaupt richtig gestartet ist und die SetPatch oder eine Mountlist benötigen, damit meine TD64-Geräte gemountet werden können. Ist in dieser Richtung irgendetwas zu erwarten? Ja, ein neues Kickstart wäre eine gute Sache. Wir denken darüber nach. Ich würde es persönlich vorziehen, wenn das Kickstart von Festplatte geladen werden würde (ich meine, wer arbeitet heute schon ohne Festplatte?) und das ROM nur einen minimalen Bootstrap und Treiber zum Booten des Systems enthalten würde (Festplatte, mimimale Grafik-Treiber für Textnachrichten, Ethernet für BOOTP-Bootvorgänge und ein CD-Filesystem für das Booten von CD-ROM) und der Rest von Festplatte geladen werden würde. Es mag andere Lösungsansätze geben, aber ein Update des physikalischen ROMs steht derzeit außer Frage. Ich würde eine solche Lösung sowieso nicht mehr anstreben, und es vorziehen, wenn das Mainboard eine Art FlashROM erhalten würde. Wir werden sehen, was möglich ist... Eyetechs AmigaOne hat ein FlashROM - würde das ganze Kickstart-ROM da hineinpassen, anstatt es einfach nur als ein minimales Boot-ROM zu benutzen, welches das eigentlich "ROM" von Festplatte lädt? Klar, wir werden das FlashROM des AmigaOne zum Booten benutzen. Zum Pegasos Motherboard: Noch eine Frage: Kannst du uns etwas über eine eventuelle Kooperation mit bplan sagen? Wir haben mit ihnen gesprochen. Falls ja, werdet ihr als einer der ersten ein BPlan Entwickler-Board bekommen? Wir werden an ihrem Entwicklerprogramm teilnehmen, aber wir werden nicht bevorzugt behandelt werden. Arbeiten die Treiber für verschiedene Hardware-Erweiterungen unabhängig vom Motherboard? Kann ich Grafikkarten, die von OS4 unterstützt werden, nicht aber von MorphOS (Radeon) betreiben? Diese Frage kann ich noch nicht beantworten. Die erste Version, die veröffentlicht wird, wird vermutlich noch einige Abhängigkeiten vom Amiga Chipsatz haben, die in verschiedenen Updates beseitigt werden. Es wird also sowieso noch ein wenig dauern bis irgendwelche nicht-Amiga Hardware unterstützt wird. Wird die komplette Hardware supportet, beispielsweise Firewire? Siehe vorherige Frage. Darüber wird entschieden, sobald wir das OS auf dem Board laufen haben. Firewire-Unterstützung wird wahrscheinlich irgendwann implementiert, hat aber im Moment keine Priorität. Benötige ich verschiedene Partitionen für MorphOS und AOS4? Die OS4-Libraries werden etwas anders aussehen als die derzeitigen Amiga-Libraries (sie benutzen ein anderes Dateiformat), deswegen könntest du Probleme bekommen, wenn MorphOS versucht eine solche New-Style Library zu öffnen. Theoretisch wäre es möglich... Entwickler-Unterlagen für OS4? Da die ganze Arbeit an OS4 umsonst ist, wenn niemand dafür entwickelt, wäre es möglich OS4.0 RKM-Dateien, die alle neuen OS4.0-Features erläutern, mit auf die CD zu packen? Wir werden so viele Informationen sobald wie möglich verfügbar machen. Das beinhaltet sowohl Entwickler-Unterlagen als auch eine Pre-Release Version von OS4 für Entwickler. Natürlich wollen wir so viele Anwendungen wie möglich für OS4 verfügbar haben, deswegen wird dies hohe Priorität haben. Entwickler-Unterlagen werden wahrscheinlich als Download verfügbar sein. Ich weiß nicht, ob wir eine CD erstellen werden, wahrscheinlich später, nach der Veröffentlichung der ersten Version. Zum TCP Stack, Filesystem: Welchen TCP-Stack benutzt ihr? Ich benutze im Moment MiamiDX, wie sieht der AOS 4.x Stack im Vergleich dazu aus? Der TCP-Stack ist der schnellste, der im Moment erhältlich ist, er schlägt jeden anderen Stack was die Transferraten angeht. Auf einer Ariadne II erreicht er über 900 KB/s. Wie sehr wird der TCP-Stack integriert sein? Ich hätte lieber eine echte bsdsocket.library auf Festplatte und ein separates Konfigurationsprogramm anstatt den TCP-Stack erst von Hand starten zu müssen. Ehrlich gesagt, weiß ich das nicht. Ich habe den TCP-Stack noch nicht gesehen. Ich nehme an, es wird eine Applikation sein, die in der WBStartup gestartet wird. Ich habe eine CyberstormPPC, alle meine Medien (2 HDs plus CD-ROM) außer meiner Floppy sind am SCSI-Controller meiner Cyberstorm angeschlossen. Ich nutze Trackdisk 64, die HDs sind mit dem Filesystem formatiert, das mit AOS 3.5/3.9 mitgeliefert wird. Werden diese Festplatten auch mit dem neuen Filesystem arbeiten? Wenn nicht, wie kann ich meine Daten "mitnehmen", ohne auf ein externes Backup-Medium (z.B. CD Brenner) angewiesen zu sein? Ich denke, das neue Filesystem ist komplett rückwärtskompatibel, aber ich kann mich hier irren. Olaf ist dafür zuständig. Falls es nicht funktioniert, könnten wir ein Konvertierungsprogramm anbieten, aber ich bin ziemlich sicher, dass es rückwärtskompatibel ist. Zum Zeitplan: Wie viel Arbeit wurde an OS4.0 geleistet und in welchen Bereichen, bevor das Projekt an Hyperion/Eyetech übergeben wurde? Größtenteils "sekundäre" Technologien, beispielsweise der TCP-Stack oder das Filesystem. Wir haben einige Dinge von H&P (wie WarpUp, von dem wir etwas Code leihen werden, und den H&P Emulator). Tatsächlich arbeiten wir im Moment "nur" an der neuen Exec. Ist Soundkarten-Unterstützung immer noch für OS4.2 vorgesehen, oder wird es das bereits in OS 4.0 geben? Es wird bereits teilweise Soundkarten-Unterstützung [Anmerkung des Übersetzers: Im englischen Text wird nur von "sound support" gesprochen...] in OS4 geben aber ich weiß nicht genau, wie weit das genau gehen wird. Wie gesagt, wir arbeiten an Exec, der Rest wird von anderen Leuten erledigt. Wie könnt ihr erwarten, das alles bis Februar fertig zu haben? ;) Obwohl Hyperion die meiste Arbeit am Kern des Updates leistet, wird sehr viel Arbeit von anderen erledigt. Als ich das letzte Mal gezählt habe, waren es insgesamt 18 Leute, die an OS4 gearbeitet haben. Die meisten Entwickler von OS 3.5 und 3.9 sind mit an Board, sowie einige weitere sehr kompetente Typen :-) Übersetzung: Christoph Gutjahr (ps) [Meldung: 29. Nov. 2001, 23:40] [Kommentare: 54 - 04. Dez. 2001, 01:00] [Per E-Mail versenden] [Druck-Version] [ASCII-Version] | ||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |