Das Thema RISC ist in: Geht es um vernetzte Arbeitsstationen, will der Anwender komfortable Benutzeroberflächen, legt er Wert auf menügestützte Window-Systeme und hochauflösende Grafik, dann benötigt er höchste Rechenleistung. Ein Fall für Reduced Instruction Set Computing also Gründe genug für die CW, zu einem Round-Table-Gespräch einzuladen. Vertreter der wichtigsten RISC-Unternehmen diskutierten mit CW-Redakteur Jan-Bernd Meyer über die Architektur mit reduziertem Befehlssatz, ihre Besonderheiten und die Chancen gegenüber CISC. Professor Arndt Bode von der TU München war neutralen Leiter des Gesprächs.
Professor Arndt Bode: Heute gibt es eine recht große Anzahl von Anbietern RISC-Architekturen und der Außenstehende fragt sich was sind eigentlich Unterschiede zwischen den einzelnen RISC-Systemen, was die Besonderheiten der speziellen Architekturen und welches sind ihre Ansätze, mit denen sie sich von der Konkurrenz unterscheiden?
Uwe Kranich (AMD): Unsere Strategie zielt eindeutig auf den Embedded-Control-Bereich und dabei konzentrieren wir uns auf den RISC-Prozessor 29000. Sinn und Grundlage der Entwicklung des Bausteins war, eine Architektur zu schaffen, die es ermöglicht, auch mit langsamen Speicherbausteinen problemlos zusammenzuarbeiten, ohne hohe Systemkosten zu erzeugen, was wir durch spezielle Cache-Strukturen wie unserem Branch-Target-Cache zu erreichen versucht haben.
Willi Haas (Mips): Die aktuellen Produkte der Firma Mips gehören nach Professor Bodes Definition wohl in die zweite Prozessor-Generation: der R3000 ist ein CMOS-, der R6000 ein ECL-Prozessor. Wir gehören mit unserer optimierenden Compiler-Familie zu den Vertretern der Stanford-Variante.
Rudolf Schmidberger (Motorola): Es ist nicht so wichtig, wie sich die RISC-Prozessoren unterscheiden. Wesentliche Unterschiede ergeben sich jedoch bei dem, was um den Prozessorkern herum geschieht. Workstations sind heute einerseits sehr leistungsfähig, andererseits verlangen sie, daß sehr große Speicherbereiche oder eine Cache-Unterstützung verwirklicht sein müssen. Im Embedded-Controller-Bereich sind die Anforderungen nicht so hoch, hier stehen Real-Time-Forderungen im Vordergrund. Wir sind Anhänger der Harvard-Architektur, die extern ausgeführt ist.
Martin Lippert (Sun): Der Sparc-Prozessor von Sun Microsystems wurde 1983 entwickelt. Sun war an einer Prozessorbasis für Produkte der nächsten 10 bis 15 Jahre interessiert. Das Wesentliche an der Sparc-Architektur ist die Tatsache, daß sie an Halbleiterhersteller zur Fertigung der Prozessoren lizenziert wurde, aber auch einer Fülle von Systemlieferanten angeboten wurde, die in eigenen Computer- und Workstationbereichen fertigen werden. Sparc stammt eindeutig von der Berkeley-Linie ab. Wir arbeiten im besonderen mit Register-Fenstern und nützen die Hardwareunterstützung auch durch Compiler im Betriebssystem aus.
Robert B. Richards (Cypress): Die Cypress-Implementationen des Sparc-Chips decken sowohl Workstation- als auch Server-Applikationen ab. Sie beinhalten Funktionen wie Integer, Fließkommaeinheiten und Cache-Controller und eine Memory-Management-Unit, wobei letzterer die Option auf dedizierte Cache-Chips bietet. Zu dieser ursprünglichen Implementation gibt es ein speziell für Multiprocessing-Applikationen entwickeltes Derivat und ein weiteres der Kern-Architektur, das Unterstützung für Embedded-Controller-Lösungen
bieten soll. Da dieser Chip weder einen Cache-Controller noch eine MMU benötigt, ist er eher für preisgünstige Rechnerleistung bei Embedded-Anwendungen geeignet. Er hat gegenüber anderen Sparc-Chips mit acht Registerfenstern deren zwölf. Man kann davon ausgehen, daß wir in sehr naher Zukunft eine superskalare Implementation präsentieren werden, Fließkomma-Cache- und MMU-Funktionen zusammengefaßt sein werden.
Sharad Gandhi (Intel): Ob es sich um einen embedded oder reprogrammable Prozessor handelt, entscheidet allein das zur Verfügung stehende Angebot an Tools, Debuggern, und sonstiger Software. Der 860-Prozessor ist das beste Beispiel, wie man embedded und reprogrammable definieren kann: Eigentlich eine klassische RISC-Architektur, die aber mit einem eingebauten Array- also Vektorprozessor versehen ist. Er hat eine Million Transistoren, die Hälfte davon wird allerdings benutzt für das On-chip-cache. Wegen der Harvard-Architektur ist es der CPU möglich, gleichzeitig auf den Code-Cache und den Daten-Cache zuzugreifen. Grundsätzlich tendiert Intel- wie auch der 860-Chip zeigt- mehr in Richtung superskalarer Architektur im Gegensatz zu Superpipelining-Bauweisen.
Bode: Die Gesamtkosten für ein Rechnersystem auf RISC-Basis resultiert ganz wesentlich aus dem Aufbau des Speichers und auch der Bus-Struktur. Welche Erfordernisse müssen leistungsfähige Speicher- und Busstrukturen erfüllen?
Gandhi: Einzelprozessor-Systeme brauchen in den meisten Situationen keinen zusätzlichen Second-Level-Cache. Bei Multiprozessor-Systemen ist dieser allerdings nicht nur für die Rechenleistung, sondern auch für die Busbandbreite wichtig. Wir glauben, daß ein integrierter Cache auf dem Chip für Systeme mit nur einer CPU in puncto Systemkosten ein großes Plus darstellt.
Schmidberger: Für den Embedded-control-Bereich unterstelle ich, daß ein Cash aufgrund der nicht vorhersehbaren Verhaltensweise nicht immer wünschenswert ist. Auch unser Prozessorbaustein besteht gemäß der Harvard-Architektur aus zwei völlig getrennten Bus-Systemen, wovon wir uns Vorteile bei der Zugriffsgeschwindigkeit versprechen. Wichtig sind auch die Organisation des Caches. Unser Prozessor mit 16 KB Cache läßt sich entsprechend vervielfältigen, so daß wir pro Busseite und damit insgesamt auf 256 KB Cache real kommen. Bei uns wird der Anwender insofern unterstützt, als er mehr Möglichkeiten erhält, seinen Aufwand in das eigentlich Design zu stecken und nicht in den prozessornahen Teil. Allerdings muß der Anwender sich überlegen, ob er Speichersysteme nicht gleich lassen und nur die reine Geschwindigkeit des Prozessorkerns mit den Caches ausnutzen möchte. Wichtig ist auch der Aspekt, ob es sich um ein physikalisches oder logisches Caches handelt. Daraus resultieren dann auch die Zugriffsgeschwindigkeiten und die Zeiten, die man bei der Speicherverwaltung verliert.
Wir haben auf den Chips das Cache und die Speicherverwaltungseinheit integriert, und eliminieren insoweit, trotz Implementierung eines physikalischen Caches, die Suchvorgänge auf der Speicherverwaltungseinheit. Ein Vorteil des physikalischen Caches ist auch, daß recht einfach ein sogenanntes Bus-Snooping durchgeführt werden kann und damit die Cache-Konsistenz von mehreren Prozessorknoten gewährleistet wird.
Die Trennung des Busses kann man natürlich im Speichersystem fortführen. Wenn ich mir den heutigen Workstation-Markt ansehe, da führt man nach den physikalischen Caches die Systembusse wieder zusammen, einfach um Kosten zu sparen. Man benutzt dynamische RAMs in der Regel also sowohl für Programm- wie Datenbereiche, die Cache-Implementierung letztlich garantiert, daß trotz der eingeschränkten Zugriffsmöglichkeit auf den gemeinsamen Speicher nach wie vor hohe Trefferraten und damit auch hohe Leistungswerte erreicht werden.
Haas: CMOS-Implementierungen gibt es derzeit durch unsere Halbleiter-Partner in Versionen zwischen 12 und 40 Megahertz. Der Cache-Controller bei der CMOS-Version ist integriert. Wir können Caches getrennt von Daten von 4 bis 256 KB verwenden. Sie sind immer Off-Chip, was für den Benutzer den Vorteil hat, daß er sich am Markt die günstigste Lösung aussuchen kann. Eine ganze Reihe unserer Hersteller hat bereits Zusatz- oder spezielle Derivate konstruiert, bei denen beispielsweise der gesamte externe Cache auf einem Speicher untergebracht werden kann. Multiprozessor-Optionen auf dem Chip unterstützen wir mittels zweier Signale. Die Cache-Protokolle für die Cache-Koherenz müssen extern realisiert werden.
Kranich: Der 29000 hat eine für uns klassische 3-Bus-Architektur, wobei Instruktion und Daten komplett getrennt sind. Damit ermöglichen wir auf beiden Bussen Zugriffe während eines Zykluß'. Das führt zu leicht berechenbaren Busbandbreiten. Wir brauchen keine On-Chip- oder Off-Chip-Cache. Ziel war es, mit langsamen DRAMS zusammenzuarbeiten - langsam übrigens relativ gemeint, DRAMs liefern nämlich hohe Erstzugriffszeiten aber auch hohe Bandbreiten um die Erstzugriffszeiten kompensieren zu können, die bei den DRAMS eben vorhanden sind. Das erreichen wir durch unseren Branch-Target-Cache, der nur Sprungziele speichert und dadurch keine große Transistoranzahl braucht, weil er nicht viele Speichereinträge benötigt.
Wichtig ist bei unserem kommpletten Konzept, daß es Hardware-abhängig ist. Dadurch müssen wir nicht mehr mit dem, Compiler dafür sorgen, daß es entsprechend auf das Memory-Modell abgestimmt ist. Vielmehr stellt die Hardware das fest. Außerdem brauchen wir keine Zero-Wait-State-Caches, um hohe Leistungen zu erreichen. Natürlich sinkt die Leistung mit den langsameren RAMs, aber es kommt nicht zu drastischen Einbrüchen, wenn man da und dort etwas länger braucht.
Gandhi: Beim 860er-Prozessor ist es möglich, den Cache so zu verwalten, daß man die Caches praktisch als Datenpuffer benutzen kann. Insbesondere bei iterativen Verfahren wie Vektoring ist es sehr nützlich, das ganze Programm in den Cache hineinzuladen.
Bode: Die größten Unterschiede bei den meisten Systemen sehe ich in der Registerorganisation. Welche Registerorganisation hat Ihr Rechner? Was ist die maximale Taktfrequenz bei den klassischen CMOS-Systemen und ist geplant, eine andere, schnellere, also eine ECL-oder Gallium-Arsenid-Variante zu entwickeln?
Kranich: Der 29000 von AMD hat 192 Register, davon sind 128 verwendbar als sogenannter Register, Kellercache also als Registerfenster mit variabler Größe Wir planen nicht, in Zukunft auf ECL zu gehen.
Haas: Wir haben in unserer Architektur 32 32-Bit-Register, die Mehrzweckeigenschaft besitzen. Zusätzlich gibt es noch 16 64-Bit-Register für Fließkomma-Operationen.
Schmidberger: Wir arbeiten zusammen mit Data General an einer ECL-Variante.
Lippert: Die SPARC-Architektur arbeitet generell in Registerfenstern, und in der Architektur sind Varianten definiert, die zwischen zwei oder bis zu 32 Registerfenster erlauben. Wieviele davon tatsächlich auf dem Chip vorhanden sind, hängt von der Implementierung ab. Den wesentlichen Vorteil sehen wir darin, daß sich durch diese Registerfenster das Laufzeitverhalten in einem realen Programm, bei dem in Unterprogramme gesprungen wird, stark verbessern läßt. An ECL- und Gallium-Arsenid-Varianten der Sparc-Architektur arbeiten unsere Lizenzfirmen.
Bode: Können Sie uns da genauere Megahertz-Raten nennen? Lippert: Etwa 200 MHz. Das Ganze soll als Multiprozessorsystem gekoppelt sein, bei dem man zwischen vier und acht Prozessoren kombinieren kann. Ob das für den traditionellen Computeranwender allerdings von praktischer Bedeutung ist, bezweifle ich, weil das doch sehr teuer werden wird.
Gandhi: Der 860er verfügt wie die meisten hier vorgestellten Prozessoren über 32 32-Bit-Register Integer, die Fließkomma-Einheit On-chip über 32 32-Bit-Register oder 16 64-Bit-Register. Momentan haben wir keine Pläne zur Entwicklung von ECL-oder Gallium-Arsenid-basierten Systemen.
Bode: Für den Benutzer ist es ganz wesentlich, weiche Entwicklungshilfsmittel zur Verfügung stehen. Ich gehe davon aus, daß alle Systeme Compiler für die gängigen Hochsprachen vorhanden sind?
Gandhi: Wir haben ein Entwicklungssystem, das eine PC mit einem 860-Board darstellt. Wir können heute praktisch alle Compiler wie C, Cobol etc. auf dem 860-Board Native-Mode fahren, ebenso Debugger. So können wir Code in ein anderes Embedded-System reinladen.
Richards: In puncto Debugging gibt es für unsere Implemtation einige Optionen: So lasen sich mit dem "Sun Tool" Real-time-Debugging-Applikationen verwirklichen. Außerdem gibt es Monitoring-Funktionen, die sich für Embedded-Applikationen nutzen lassen. Mit einer Debugging-Software von Flame Computers kann der Anwender Break-Points in Spec-Registern setzen, mit ihm lasse sich Traps generieren. Das alle geschieht interaktiv mit einem ebenfalls von Flame entwickelten Compiler. Compiler gibt es für alle gängigen Sprachen inklusive C oder für Al-Sprachen wie Lisp und Smalltalk.
Bode: Wie sieht es mit Prototyp-Hardware aus?
Richards: Da gibt es Boards, die VME-kompatibel sind oder auch in einer PC-Umgebung arbeiten. Auf jeder Sun-Maschine können sie Hostentwicklungen vornehmen. Es ist auch möglich, auf einem Non-native-Host wie etwa der Sun3 oder einem IBM PC AT mit Emulator zu entwicklen.
Schmidberger: Besondere Hardware haben wir nicht, beziehen uns auf Standardprodukte am Markt, die Verwendung finden können. Da gib es einerseits Entwicklungs-Maschinen. Das Angebot an Karten deckt den Bereich vom PC, über VME-, Multi-Bus- bis zu Q-Bus-Karten ab. Bekannte Häuser bieten Compiler. Diese Unternehmen sind übrigens in Anwendergruppe 88open versammelt, wo Software-Standards sowohl für Compiler auch für Applikationen ganz allgemeiner Art entwickelt wurden. Neben den typischen Compilern verfügen wir auch über Hochsprachen wie Ada, außerdem kann der Anwender auf AI-Sprachen wie Lisp und Prolog zurückgreifen.
Haas: Die Firma Mips hat ja Architektur in Zusammenhang mit den Compilern entwickelt. Diese Features sind somit bereits in der anfänglichen Phase berücksichtigt worden, Front-ends stehen derzeit C, Fortran, Pascal, PL1, Ada und Cobol zur Verfügung. In dem Tool-Paket "Systems Programmers Package" sind sämtliche Routinen und Simulatoren zusammengefaßt, die ursprünglich bei der ersten Konstruktion von Workstations bei uns im Hause verwendet worden sind. Mit einem Architektursimulator kann der Anwender etwa Speicherstrukturen vor Ort simulieren. Enthalten sind ein Debug-Monitor, ein Prompt-Monitor, sowie die gesamten Down-Load Utilities, die man letztendlich benötigt, wenn die entwickelte Software auf dem Ziel-System ausgetestet wird. Prototypen-Boards bieten unsere Halbleiterpartner sowie Drittfirmen an.
Kranich: Bei uns wählt der Anwender zwischen drei Emulatoren, unter Development-Boards, die für Stand-alone-PCs oder als VME-Bus-Boards ausgelegt sind, je nachdem, unter welcher Umgebung er arbeiten will. Die Tools laufen auf Hosts wie ATs, Sun und auch Native, also auf dem 29000-Prozessor selbst. Auch mit unserem Architektur-Simulator ist es dem Anwender gestattet, die resultierende Leistung aus einer Speicherkonfiguration und einer CPU-Konfiguration vorher bestimmen zu können. So läßt sich schon bei der Entwicklungsphase festlegen, welches Speichermodell man überhaupt braucht für eine bestimmte benötigte Leistung.
Bode: Es steht sicher fest, daß ein wesentlicher Unterschied zwischen RISC- und CISC-Architekturen der Grad der Optimierung bei der Übersetzung von höheren Programmiersprachen in Maschinencode ist. Für den Programmersteller bedeutet das aber, ihm wird zugemutet, sein Programm zunächst nicht optimiert übersetzen zu können. Er muß es zunächst debuggen, um es dann noch mal neu zu übersetzen und zu optimieren. Quellbezogen können die Programme aber dann nicht mehr getestet werden. Gibt es von einem der Hersteller Ansätze, dieses Problem zu lösen?
Haas: Wir haben einen speziellen Compiler-Switch, mit dem sich optimierte Programme debuggen lassen. Selbstverständlich wird es nicht in allen Fällen möglich sein, die wegoptimierten Features wieder zu rekonstruieren. Auf der anderen Seite können wir aber garantieren, daß sich die optimierten Programme verhalten wie die nicht optimierten.
Bode: Bleibt für mich aber trotzdem eine gewisse Skepsis. Für den Benutzer wichtig ist die Leistung, die ihre Systeme bieten. Wo kann der Benutzer über Ihre Produkte Informationen zuverlässiger Natur beziehen und welche Angaben hat er zu gewärtigen?
Kranich: Bei uns kann der Kunden seine Applikation mit unseren Tools und unserer Hardware laufen lassen. Er sieht dann selbst, wie leistungsfähig unser System sich für seine Anwendung darstellt.
Haas: Wir sind froh, daß die SPEC-Cooperative gegründet wurde, in der sich alle wichtigen Computerhersteller vereinigt haben. Als Gründungsmitglied veröffentlichen wir selbstverständlich Specmark-Ergebnisse. Auf Wunsch sind natürlich auch andere Ergebnisse verfügbar, wobei wir darauf hinweisen, daß die meistens wenig aussagekräftig sind.
Schmidberger: Motorola gibt Zahlen heraus, wobei wir versuchen, eine möglichst genaue Beschreibung zu machen, nach welchen Kriterien diese zustande gekommen sind und auf welchen Maschinen sie lauffähig sind. Aber der Anwender sollte real lauffähige Programme austesten und nur eingeschränkt unter anwendungsspezifischen Benchmarks.
Lippert: Sun stellt, wie jeder andere Hersteller auch, Zahlen zur Verfügung. Man muß sich allerdings darüber im klaren sein, daß diese sich nicht auf den RISC-Prozessors alleine beziehen, sondern daß dabei natürlich die Leistungsfähigkeit eines Gesamtsystems gekennzeichnet wird. Da alle heutigen Tests rein CPU-Integer- und Fließkommabezogen sind, empfehlen wir den Kunden, eine reale Anwendung auf einem in Frage kommenden System auszuprobieren.
Gandhi: Wir veröffentlichen regelmäßig Performance-Reports. Für den 860 haben wir Benchmarks von Spec, Dhrystone, Whetstone, Linpack. Wir liefern Beschreibungen zu den Systemen, Compilern und Optimier-Levels und über die Bedeutung verschiedener Benchmarks.
Bode: In fünf Jahren will man 10-15 Millionen Transistorfunktionen auf einen Chip bringen, im Jahr 2000 etwa 50 Millionen. Was wird dann aus der RISC-Philosophie? Was bleibt langfristig als wesentlicher Unterschied zwischen RISC- und CISC-Architekturen? Sind superskalare Eigenschaften nicht besser in RISC-Architekturen unterzubringen?
Gandhi: Der 486 ist ein Beispiel, daß man die gleiche Technologie anwendet, egal bei welcher Architektur. Ob RISC tot ist oder nicht - ich glaube, die Frage wird irrelevant. In zwei Jahren werden die Leute die Prozessoren nicht mehr klassifizieren nach RISC oder CISC, sondern andere Merkmale wie superskalar oder Superpipelining abfragen, oder ob eine Vektor-Einheit vorliegt oder eine Unterstützung von gewissen Multiprocessing-Cacheing-Lösungen.
Ich glaube, die Entwicklung geht in Richtung Multi- und Parallel-Processing. Intels Augenmerk richtet sich in allen drei Architekturen auf Superskalarität und die Unterstützung von Parallelismus von Prozessoren auf einer Platine und mehrerer Prozessoren innerhalb eines Chips.
Richards: Wir werden auf kommende Prozessoren, bei denen es sich um die 0.5-Mikron-Generation handelt, den Cache integrieren. Wir werden versuchen, funktionale Einheiten zusammen mit den zugehörigen Registern herauszulösen, um so Superpipelines und superskalare Architekturen zu ermöglichen. Der Bus wird intern weiter ausgelegt werden und die Performance soll sich durch neue Compiler steigern, die wiederum Pipeline-Strukturen besser unterstützen.
Lippert: Am wichtigsten wird die Softwareentwicklung sein. Die-Hardware-Entwicklung geht relativ schnell vonstatten, es gibt immer neue leistungsfähige Prozessoren. Die ganze Anwendungssoftware und die Compilerentwicklung vollzieht sich hingegen relativ langsam. Ich glaube, daß die Compiler-Entwicklung mehr Zeit braucht als die reine Prozessorentwicklung und daß das der Schlüssel sein wird zu der Frage, ob da ein Zusammenwachsen zwischen RISC und CISC stattfinden wird.
Haas: Das Acronym RISC ist ja etwas unglücklich gewählt und die reduzierten Befehlssätze sind eigentlich eher ein Seiteneffekt der eigentlichen Designphilosophie. Aufgrund des Fehlens der Load-store-Architektur und des Vorhandenseins von Befehlen unterschiedlicher Länge, wird sich das immer nachteilig auf die Leistung von CICS-Prozessoren auswirken. Auf der anderen Seite werden RISC-Prozessoren zusätzliche Befehle mit reinnehmen, wenn sich rausstellen sollte, daß sich damit eine Leistungssteigerung beziehungsweise andere gewünschte Eigenschaften erzielen lassen. Die grundsätzlichen Eigenschaften zwischen RISC und CISC werden bestehen bleiben, auch wenn wir glauben, daß die beiden aufeinander zugehen. Ein R3000-Prozessor benötigt heute ungefähr ein Zehntel der Chipfläche eines 486, wobei er in etwa die doppelte Leistung bringt.
Kranich: Für mich erscheint problematisch, mehrere Zyklen, die unterschiedlich lang sein können, oder unterschiedlich lange Befehlssequenzen so optimal zu schedulen, daß man hinterher wirklich eine Leistungssteigerung erzielt. Es genügt ja nicht, zwei oder mehrere Befehle gleichzeitig zu starten. Das ist bei komplexen Befehlssätzen nicht trivial. Superskalare Prinzipien müssen andererseits neben Leistungssteigerungen trotzdem die Binärkompatibilität garantieren. Es ist ja leider ein Trugschluß, zu glauben, man steckt einfach ein paar PCs zusammen und dann bringen die die x-fache Leistung. Gerade in bezug auf vernünftige Scheduler-Software für Multiprozessorsysteme ist da noch einiges zu tun, um wirklich nutzen zu können, was vom Integrationsgrad zur Verfügung gestellt wird.
Bode: Der wesentliche Unterschied zwischen den CISC- und den RISC-Architekturen war ja vom Standpunkt des Benutzers, daß jene eben aufwärtskompatible Modelle innerhalb einer Familie zur Verfügung gestellt haben. Heute läßt sich bei verschiedenen RISC-Herstellern ein gewisser Zug zu komplexeren RISC-Architekturen feststellen. Heißt das für den Anwender, irgendwann kommen doch neue Maschinenbefehlsschnittstellen? Wird er seinen Objektcode immer mit der neuen Technologie verwenden können oder nicht?
Lippert: In der Sparc-Architektur-Definition ist die Maschinenbefehlsschnittstelle definiert und festgeschrieben. Sun hat heute diese Technologie nicht mehr allein unter Kontrolle, da gibt es federführend die Gruppierung Sparc-International. Natürlich gehe ich davon aus, daß diese Maschinenbefehlsschnittstelle erhalten bleibt, so daß eine Aufwärtskompatibilität auf jeden Fall sichergestellt ist. Es kann natürlich der Zeitpunkt kommen, daß man sagt, jetzt braucht man verschiedene Funktionen. Das kann aber sicher ohne weiteres als Erweiterung implementiert werden, ohne keinen Bruch zur Aufwärtskompatibilität heraus zu beschwören.
Kranich: Ich kann mich nur Herrn Lippert anschließen: Man kann dem Anwender und den Softwarehäusern nicht jedes Jahrzehnt zumuten, ihre Software komplett neu zu portieren.
Ghandi: Ich glaube, wir stehen ganz am Anfang der Entwicklung. Was man bestimmt nicht oder nur sehr schlecht voraussehen kann, ist, wie die verschiedenen Entwickler einer bestimmten Architektur mit welcher Strategie, mit welcher Politik weiterfahren. Meiner Meinung nach ist es sehr schwer vorauszusehen, wie es in drei Jahren aussieht mit der zweiten oder dritten Generation gleicher Architekturen verschiedener Hersteller. Ob die gleiche Architektur bleibt, dazu kann wohl niemand eine klare Aussage machen.
Lippert: Also dazu möchte ich schon etwas sagen: Wenn ich Sie recht verstanden habe, sagen Sie ja, daß sich in den Architekturen durchaus noch mal etwas ändern kann. Daß man den Anwendern somit zumutet, noch-mal auf eine andere Maschinenbefehlsschnittstelle zu gehen. Das wäre aus meiner Sicht ein Fehler. Ich glaube, daß alle Systeme, die keine Kompatibilität sicherstellen, in zehn oder 15 Jahren am Markt keine Chance haben.
Gandhi: Meine Frage zielte nur darauf ab, ob die verschiedenen Hersteller von Sparc- oder Mips-Architekturen den gleichen Wert darauf legen, die Aufwärtskompatibilität mit anderen Hersteller abzusprechen. Also etwa, ob die nächste Generation von Cypress kompatibel zur kommenden und einer noch späteren von LSI sein wird und einen ähnlichen Objektcode unterstützt.
Lippert: Das ist ja grad die Zielsetzung von Sparc, die Basis zu
liefern für Systeme, die wirklich binär-code-kompatibel sind. Ich habe noch kein System von Silicon Graphics gesehen, das binär-kompatibel ist zu dem von Digital oder einem anderen Lizenznehmer, die auf der Mips-Architektur aufbauen. Das liegt an den Herstellern.
Haas: Das liegt am Betriebssystem, nicht an der Prozessor-Architektur.
Lippert: Klar, aber de facto interessant ist doch, was die Leute hinterher davon haben. Heute ist es so, daß sichergestellt werden muß, eine Multi-Vendor-Gemeinde zu schaffen, wie sie die PC-Welt kennt. Das ist die Basis für lange Softwarenutzung. Wenn sie das nicht garantieren können, macht das Ganze wenig Sinn.
Richards: Die Leute in der Branche haben eine Lektion gelernt: Der einzelne Silikon-Hersteller kann nicht mehr komplette Instruktions-Satz-Architekturen für sich alleine entwikkeln. Daß geht nur noch in einer Gruppe. Die muß sowohl über Expertise in der Technologie, als auch bei der Compiler-Entwicklung und der Systemintegration verfügen.
Nur mit diesem vereint angehäuften Wissen war es möglich beziehungsweise ließen sich Dinge entwickeln wie die Option, Hardware-Pipelines zu wechseln, um mehrere Instruktionen gleichzeitig zu starten, oder Anwender-definierte Instruktionen zu integrieren für die zukünftige Unterstützung von Co-Prozessoren wie etwa Grafik-Chips, die in den Instruktionensatz gemapped werden können. Auf CISC-Maschinen war das nie möglich.