Bei den Herstellern von RISC-Architektureng die in großer Anzahl auf dem Markt vertreten sind, findet ein Ausscheidungswettbewerb statt. Bedauerlicherweise entscheidet dabei nicht die Qualität der technischen Merkmale, sondern die Anzahl der verfügbaren Anwendungsprogramme über den Fortbestand einzelner Architekturen ("Wo viel ist, kommt viel hin").
Als weiteres Kriterium wird allenfalls noch berücksichtigt, wie viele unabhängige Hersteller für den entsprechenden Baustein vorhanden sind, um Monopolsituationen bei Lieferungsengpässen auszuschliessen. Die Marketing-Bemühungen der Hersteller von RISC-Architekturen zielen also in die Richtung des Nachweises einer möglichst großen Anzahl von Anwendungen ("Applikationen"). Zu fast allen RISC-Architekturen existieren daher - initiiert von den Herstellern - Anwenderforen, in denen Anwender, Hersteller kommerzieller Systemsoftware, Hersteller ganzer Systeme etc. zusammengefaßt werden und die als Beleg eines möglichst weiten Anwendungsspektrums verwendet werden (88-Open, 29K Fusion, ACE).
Zahlenspiele bei den Anwendungsprogrammen
RISC-Hersteller bemühen sich zum Teil in grotesk anmutender Art, dem potentiellen Anwender des Produktes eine möglichst breite Basis an Anwendungsprogramme zu suggerieren. So wird beispielsweise in regelmäßigen Abständen die Anzahl der Applikationen veröffentlicht, wobei einfachste Treiber für spezielle Peripheriegeräte genauso gezählt werden wie ein großes kommerzielles Datenbanksystem.
Voraussetzung für das Greifen solcher Marketing-Maßnahmen ist die Tatsache, daß durch die Einführung neuer Architekturen, Betriebssysteme und weiterer Elemente der Systemsoftware eine zunehmende Unverträglichkeit zwischen existierender Software und neuen Systemen existiert. Während es bei klassischen Großrechnern üblich war, daß ein und derselbe Hersteller die Hardware des Systems, die zugehörige Systemsoftware und meist auch die Anwendungssoftware produzierte, so daß für eine Rechnersystem-Familie im allgemeinen zumindest die Aufwärtskompatibilität aller Modelle auf Objektcode-Ebene gegeben war, hat sich die Situation bei Systemen auf der Basis von Mikroprozessoren,
insbesondere von RISC-Architekturen, deutlich verändert.
Für die RISC-Mikroprozessor-Architektur eines Herstellers existieren im allgemeinen bereits x Hersteller, die auf der Basis des Prozessors eine Systemhardware herstellen. Für jedes dieser Systeme gibt es meist y unterschiedliche Softwarehäuser, die die Basissoftware wie Betriebssysteme und Compiler für höhere Programmiersprachen sowie Assembler, Binder und Lader realisieren. Auf der Basis der angebotenen Einheiten aus Systemhard- und -software existieren weitere z Hersteller von Anwendersoftware, die sich an den potentiellen Endkunden wenden.
Die vom Standpunkt des Endanwenders erwünschte Übertragbarkeit von Programmen kann also auf den verschiedensten Stufen scheitern.
- Inkompatibilität der Hardware: Bereits bei Verwendung gleicher Mikroprozessoren kann durch die Nutzung unterschiedlicher Systembusse und Speicherstrukturen die Übertragbarkeit leiden.
Sollen darüber hinaus in einem System mehrere Prozessoren als homogene Multiprozessorsysteme oder inhomogene Systeme beziehungsweise Netze genutzt werden, die untereinander Daten über Nachrichtenkoppelung oder gemeinsamen Speicher austauschen, entsteht die Inkompatibilität möglicherweise durch unterschiedliche Datendarstellung (Little-endian beziehungsweise Big-endian).
- Inkompatibilität in der Systemsoftware: Selbst bei der Benutzung gleicher Zielhardware kann durch die Nutzung unterschiedlicher Betriebssysteme (etwa Unix und MS-DOS) eine Unverträglichkeit entstehen. Ähnliches gilt für verschiedene Programmiersprachen. Jedoch selbst bei der Nutzung des gleichen Zielsystems und derselben Programmiersprache ist es möglich, daß wegen unterschiedlicher Verwendung der Ressourcen des Prozessors (bei RISC-Architekturen vor allem der Register) Programme nicht kompatibel sind.
- Inkompatibilität auf Ebene der Anwendungssoftware: Die Programmpakete verschiedener Hersteller für dasselbe Zielsystem und dieselbe Programmiersprache können wegen der unterschiedlichen Nutzung der Ressourcen der zugrundeliegenden Systemarchitektur nicht kompatibel sein.
Alle Aussagen bezüglich Inkompatibilität gelten natürlich verstärkt bei der Vermischung unterschiedlicher Zielhardware, Betriebssystem-Software, Programmiersprachen, Compiler und Anwendungssysteme.
Um eine möglichst große Zahl übertragbarer Anwendungen zu einer RISC-Architektur aufweisen zu können, bemühen sich die Prozessorhersteller um Maßnahmen zur Sicherung der Kompatibilität. Solche Maßnahmen sind:
- Konvertierungshilfsmittel in Hard- oder Software zur automatischen Umsetzung nichtkompatibler Elemente,
- Ausschluß von Inkompatibilitäten durch Festlegung von Standards bezüglich der Systemhardware und der Nutzung der Architektur-Ressourcen durch System- und Anwendungssoftware.
Eine wesentliche Quelle der Inkompatibilität auf Hardware-Ebene stellt ganz sicher die unterschiedliche Datendarstellung (Byte-Anordnung) dar. Mit zunehmender Verbreitung kooperierender vernetzter Systeme ist es daher notwendig, eine Anpassung der Datendarstellung zu erreichen.
Einige Hersteller bieten daher Prozessorvarianten an, die neben der verwendeten eigenen Darstellungsform eine Umordnung beim Einlesen der Daten aus dem Speicher ermöglichen. Wo eine solche Konvertierungshardware fehlt, muß sie speicherseitig nachgebildet werden.
Prinzipiell ist das Problem auch durch eine Konvertierungssoftware zu lösen, was zur Laufzeit jedoch keine realistische Variante darstellt. Der potentielle Anwender von RISC-Architekturen sollte sich die Möglichkeiten des gewählten Zielprozessors diesbezüglich genau ansehen.
Kooperierende Systeme sind heute außerordentlich häufig anzutreffen, etwa in Workstations, wo der Zentralprozessor mit einem Grafikprozessor und einem Prozessor zur Steuerung von Peripheriegeräten wie Laserdruckern zusammenarbeiten muß. Die bei den RISC-Architekturen reichlich vorhandenen Register eignen sich besonders gut für eine feste Zuordnung zu Betriebssystemen, Unterbrechungsbereichen und Benutzerprozessen. Für die Kompatibilität verschiedener Programmsysteme ist es daher unerläßlich, daß alle Elemente der System-und Benutzersoftware diese Registernutzung einheitlich behandeln.
Folgenloser Verstoß gegen die Konventionen
Dabei ist zu beachten, daß die von den Herstellern in Binärcode-Standards festgelegten Vereinbarungen nicht hardware- mäßig unterstützt werden und sich daher durch die Systemhardware auch nicht überprüfen lassen! Der Nutzer einer RISC-Architektur für eine Spezialanwendung kann also ohne Schaden für seine Anwendung gegen die Konventionen verstoßen, er büßt lediglich die Kompatibilität zu anderen Anwendungen ein.
Die von den Herstellern der RISC-Architekturen festgelegten Binärcode-Standards sind meist recht umfangreich und, da sie nicht Teil der Systemhardware sind, nicht oder nicht vollständig in den Datenbüchern zu den Prozessoren beschrieben. Der potentielle Anwender sollte sich also die entsprechenden Dokumente besorgen, wenn er Wert auf eine Kompatibilität zu einer größeren Klasse von Anwendungen legt. Nur bei Berücksichtigung aller Maßnahmen zur Beseitigung möglicher Inkompatibilitäten kann der Anwender auf die Übertragbarkeit seiner Software hoffen.
Aus Marketing-Gesichtspunkten wird bisweilen nur eine Maßnahme herausgegriffen und als Lösung für Kompatibilität und offene Systeme angepriesen. Die reale Welt ist leider meist komplexer!