Oktober 2015

You are browsing the site archives by month.

4 Mal Cortex-A15 für RISC OS

RISC OS Open Ltd. hat heute mit der Neuigkeit überrascht, dass eine bis dato (mir) unbekannte Firma namens Elesar Ltd. ein Board namens Titanium entwickelt hat. Basierend auf dem bekannten Dual-Cortex-A15-OMAP AM5728 von TI legt es etwas andere Schwerpunkte als die Konkurrenz. 2 GB RAM, sechs USB2.0-Host-Anschlüsse (plus zwei interne), 2x DVI-I, 2x Gigabit Ethernet, 8 MB interner Flash-Speicher, 2 serielle Ports und vier SATA-Ports lautet die interessante Mischung. Das Ganze in einem ATX-kompatiblen Package, mit I/O Shield zum Einbau in Standard-ATX-Gehäuse.

Der m.E. noch interessantere Teil der Nachricht: man macht sich nicht nur um Hardware Gedanken, sondern auch um Software. Piccolo Systems (zu Deutsch: Ben Avison) hat sich um eine anständige Treiberschicht für S-ATA gekümmert. Ein Meilenstein in der RISC OS-Geschichte, wenn wirklich das alte IDE-Gefummel in ADFS endlich abgelöst werden kann. Und wenn dadurch CDVDBurn tatsächlich mal mit “full speed” des Brenners arbeiten könnte.

Nun gibt es also vier “Bewerber” um den Preis “schnellste RISC OS-Hardware”, die allesamt auf dem TI OMAP5 basieren:

  • ISEE IGEPv5
  • TI OMAP5432 EVM
  • BeagleBoard-X15
  • Elesar Titanium

Hardware Overload. Gewisse Eigenschaften des Titanium-Boards lassen auf RISC OS-Herkunft schließen: das verhältnismäßig kleine interne Flash-ROM, die zusätzlichen 2K EEPROM, die geradezu “CMOS” schreien. 2 GB RAM als größte sinnvolle Speichermenge, mit der RISC OS umgehen kann. Und tatsächlich: hinter Elesar Ltd. steckt niemand anderes als Robert P. Sprowson, auch als “Sprow” bekannt.

Bin gespannt, was für Eindrücke von/nach der RISC OS London Show eintrudeln.

Zero Page Relocation – Gedanken zur Rückwärtskompatibilität

RISC OS steht (zumindest auf den modernen post-Risc PC-Plattformen) vor einem erneuten Schritt, der potenziell Schmerzen bei der Rückwärtskompatibilität verursachen wird. Hier kann man die Gründe, die RISC OS Open Ltd. dafür anführt, nachlesen. In der GAG-News 141 wurde ebenfalls ein Artikel dazu veröffentlicht.

Kurz zusammengefasst geht es um den Speicherbereich der ersten paar KB, der traditionell “Zero Page” genannt wird und z.B. “Kernel Scratch Space” beinhaltet und die Prozessorvektoren. Und natürlich die Adresse 0, beliebtes Ziel aller nicht initialisierter Pointer der systemunabhängigen Assemblersprachen (vulgo C und Konsorten).

Die Development-Builds seit dem 5.Juli haben die Zero Page nun in den hohen Speicherbereich verschoben und für Userspace-Code unzugänglich gemacht. Alle Software, die absichtlich oder unabsichtlich auf die Zero Page, wir sich mit einem Data Abort verabschieden. Bzw. das wäre der Fall, wenn nicht gleichzeitig eine Analyse- und Logging-Modul namens “ZeroPain” aktiv ist. Dieses beantwortet Lesezugriffe in einer kompatiblen Art und Weise und loggt gleichzeitig diese Zugriffe, um dem Softwareentwickler eine Analysemöglichkeit an die Hand zu geben. Wenn es nach dem veröffentlichten Fahrplan geht, wird ZeroPain ab 1.1.2016 nicht mehr zur Verfügung stehen.

Historisch betrachtet gab es bei RISC OS schon einige Zäsuren bezüglich der Rückwärtskompatibilität, und einige Utilities, die versuchten die Rückwärtskompatibilität wieder zu verbessern oder gar vollständig wiederherzustellen. Von RISC OS 2 nach RISC OS 3 gab es einige Verwerfungen, zum einen aufgrund der althergebrachten Home-Computer-Entwicklungsidee “direkt auf die Hardware”, die an einem großflächigen Wechsel der Peripherie-Chips zerschellte (6551 nach 8250, ST506 nach IDE, 1772 nach 82C710/11). Dann diverse Unterschiede zwischen den Betriebssystemversionen selbst – einige APIs erfuhren subtile Änderungen, und wer nicht genau nach Spec implementiert hatte, wurde kalt erwischt.

Dann kam der Risc PC. Wieder gravierende Änderungen in der Chipsatzlandschaft, dazu ein umgekrempeltes Videosystem um die neuen Grafikfähigkeiten abzubilden. Zig Spiele scheiterten aufgrund der Änderungen des VIDC20 gegenüber dem VIDC1. Game On!, eine Software des ARM Club, stellte einen VIDC1-Kompatibilitätslayer zur Verfügung.

Bis zu diesem Zeitpunkt konnte man mit Fug und Recht behaupten, dass Kompatibilitätsprobleme halt durch unfähige Programmierer zustande kamen – die Doku nicht richtig gelesen, die Hardware direkt angesprochen – selber schuld.

Und dann wurde alles anders. Der StrongARM kam. Harvard- statt von-Neumann-Architektur beim 1st level cache und Writeback- statt Writethrough-Konfiguration, was selbstmodifizierenden Code aus der Bahn warf. 5-stufige statt 3-stufige Pipeline mit subtilen Änderungen beim Verhalten des PC. Und dazu der dramatische Geschwindigkeitsboost, der so manche Software aus dem Takt brachte. Dagegen war dann der Schritt RISC OS 3.7 nach RISC OS 4 ein Kindergeburtstag. Viele Softwarehersteller nutzten die Gelegenheit und machten mit Minimalupdates zur Herstellung der StrongARM-Kompatibilität zum letzten Mal Kasse. Mit StrongGuard des ARM Club stand eine Lösung für Spiele zur Verfügung, für Anwendungen gab es so etwas nie.

Aber die größte Zäsur kam erst danach. Von 26bit nach 32bit. Der IYONIX kam, dazu RISC OS 5, und das Ende des “legacy” 26bit-Adressmodus. Im Prinzip lief danach – außer den reinen BASIC-Erzeugnissen – keine Software mehr. Der geniale Aemulor linderte den Schmerz etwas, aber die Kompatibilität war begrenzt und die Anwesenheit von Aemulor im System hat diverse Nachteile für den regulären Betrieb.

Dann kam das BeagleBoard, und mit ihm die ARMv7-Architektur, wo ARM mal wieder das “nicht-ganz-rückwärtskompatibel”-Spiel spielte. Da das aber nur die relativ selten auftretenden “unaligned loads” betraf, hielt sich der Schaden in Grenzen – solange der Benutzer die “Alignment Exceptions” abschaltete. Was uns wieder zur “ZeroPain” führt, das ja letztlich denselben Ansatz fährt: Verstöße stillschweigend dulden.

Nun also “Zero Page Relocation”. Die Frage lautet wie immer: ist der Gewinn (durch höhere Systemstabilität, für mehr Freiheitsgrade für zukünftige Entwicklung) größer als der Verlust (Software läuft nicht mehr)? Die Antwort liegt vermutlich im Auge des Betrachters – setzt man unersetzliche Software ein, die dann nicht mehr läuft? Es gibt ja nun nicht besonders viele aktive RISC OS-Nutzer (geschweige denn -Entwickler), kann es sich die RISC OS-Welt leisten auch nur einen davon zu verlieren?

Ich muss gestehen: ich habe keine klare Meinung dazu. Endlose Rückwärtskompatibilität führt zu endlos steigenden Aufwänden, was sich ein System wie RISC OS, das nur wenige Entwickler hat, nicht leisten kann. Aber die Anwendersicht hat natürlich erhebliches Gewicht: was soll man mit einem System, das keine Nutzer mehr hat?

Aus meiner Sicht kann es nur einen Ausweg geben: wir brauchen in Zukunft eine wasserdichte Emulationslösung, die solche rückwärtskompatibilitätsbrechende Änderungen abfedert. Im Moment haben wir einen ganzen Zoo von Lösungen: ArcEm, ArchiEmu, ADFFS und Aemulor. Alle haben ihre Nischen und spezifischen Vorteile, sind aber allesamt für den Otto-Normalanwender viel zu kompliziert zu benutzen, bzw. dadurch ausgelöste Effekte sind nicht zu durchschauen. Es bräuchte eine modulare Lösung, zu der auch “normale” Entwickler beitragen können. Mir schwebt eine Art Hypervisor vor, in den man anwendungsspezifisch Kompatibilitäts-Handler einbauen kann, die z.B. bei SWI-Aufrufen wieder Kompatibilität herstellen können. Dazu muss pro Anwendung entschieden werden, ob sie codetechnisch nativ oder emuliert ausgeführt werden soll. Vollständige Emulation mit einer beliebigen RISC OS-Version muss möglich sein, die Fenster der Anwendung der Emulation müssen in das Host-Betriebssystem “seamless” eingebunden werden können. An der Prozessorkompatibilitätsfront könnte sowas wie LLVM durchaus helfen.

Was natürlich auch helfen würden: Open Source allüberall. Wird wohl nicht passieren, und braucht dann ja auch eine Menge Kümmerer, die die Software dann pflegen.

BeagleBoard-X15 startet im November

Es gibt mal wieder Neuigkeiten von dem Board, das RISC OS-technisch den High-End-Bereich etwas preiswerter abdecken könnte als das ISEE IGEPv5, das demnächst von CJE Micro’s als fertiges System verkauft werden soll.

Es gab ja schon einige Verzögerungen, ursprünglich wurde im Oktober 2014 ein Release im Februar 2015 angekündigt. Jetzt also November. Und leider ist auch der Preis gestiegen: von den ursprünglich angepeilten 199 US$ auf nun 248 US$ bei Digi-Key. Das ist nun leider nicht mehr weit entfernt von der Lite-Version des IGEPv5, aber mit 2 GB RAM und 2xGigabit Ethernet ist man etwas besser ausgerüstet. Dazu 4 GB Flash on board, 3 USB3.0-Hostanschlüsse und powered eSATA. Und einen anständigen HDMI-Anschluss – das microHDMI-Ding am IGEPv5 ist doch sehr fitzelig und strahlt nicht unbedingte Solidität aus.

Die offizielle Support-Seite bei eLinux.org spricht von 2000 Boards, die im ersten Batch gefertigt werden und die ab 15. November bei den Distributoren verfügbar sein sollen. Auch auf beagleboard.org kann man jetzt Infos zum X15 finden.

Hoffentlich ist die Anpassung des IGEPv5-Ports kein größeres Problem.

Vorherige Artikel zum BeagleBoard-X15: