Warum hat sich die ESA für SPARC für LEON entschieden?

Ende 1997 startete die Europäische Weltraumorganisation das LEON-Projekt, um leistungsfähigere Prozessoren für ESA-Missionen bereitzustellen. Eine offene Befehlssatzarchitektur war eine Grundvoraussetzung (sowohl um Verfügbarkeitsprobleme zu vermeiden als auch um Anpassungen zu ermöglichen), aber auch die Eignung für den Einsatz im Weltraum war eine wichtige Überlegung.

Die ESA entschied sich für die Verwendung von SPARC Version 8 (von 1991/1992 basierend auf dem Urheberrechtshinweis in The SPARC Architecture Manual: Version 8 , die Basis-ISA wurde 1987 veröffentlicht). SPARC hatte einige Vorteile:

• Es war vielleicht die einzige vollständig offene ISA mit signifikanter Unterstützung.
• Es war eine einigermaßen einfache ISA (RISC), eine freundliche Implementierung mit geringerem Aufwand.
• Es gab Workstations mit SPARC v8-kompatiblen Prozessoren, sodass Cross-Compiling vermieden werden konnte.
• Entwicklungstools für SPARC waren einigermaßen ausgereift, obwohl vermutlich mehr auf Server/Workstation-Workloads ausgerichtet.

Allerdings hatte SPARC auch einige Nachteile:

• Bis 1997 (mit der Einführung des Pentium II) wäre die Zukunft von SPARC in Workstations in Frage gestellt worden (wodurch das Cross-Compiling-Problem etwas umstritten wäre).
• SPARC wurde nicht allgemein als offenes ISA eingeführt, daher gab es keinen signifikanten Rohstoffeffekt. (Dies war wahrscheinlich keine große Überlegung für LEON, beeinflusst aber die Verfügbarkeit von Softwaretools. Die Offenheit von SPARC hat auch einen begrenzten Vorteil in Bezug auf Patente.)
• Als klassisches RISC hatte SPARC eine etwas schlechte Codedichte. (Die Codegröße ist ein wesentlicher Faktor für weltraumgestützte Computer.)
• SPARC wurde nicht allgemein für die Verwendung in eingebetteten Systemen übernommen. (Dies hätte die Verfügbarkeit von Entwicklungswerkzeugen beeinflusst, die für solche Systeme geeignet sind.)
• Die Registerfenster von SPARC hätten die minimale Kerngröße erhöht, die Komplexität des Hardwaredesigns leicht erhöht und eine komplexere Entwicklung für einen streng eingeschränkten Echtzeitbetrieb mit sich gebracht.
• SPARC enthielt weniger nützliche Funktionen wie markierte Arithmetik. (Dies war wahrscheinlich nicht von Bedeutung, da eine Teilmenge der Architektur verwendet werden konnte.)
• Das Anweisungsformat von SPARC war etwas weniger regelmäßig als bei anderen RISCs. (Dies ist ein ziemlich trivialer Einwand; der Größen-/Leistungsunterschied zwischen Befehlsdecodern für eine Alpha-ähnliche ISA und SPARC würde weniger als 1 % betragen.)

Angesichts der einigermaßen garantierten Verwendung der gewählten Architektur durch die ESA und der besonderen Anforderungen für weltraumgestützte Systeme scheint eine kundenspezifische ISA praktisch gewesen zu sein. Ein benutzerdefinierter, offener ISA hätte erhebliche Nachteile:

• Das Fehlen vorhandener Entwicklungstools hätte zusätzliche Kosten verursacht und die Compilerentwicklung mit der Hardwareentwicklung verknüpft (erhöhtes Zeitplanrisiko). (Nicht offene Tools für die SPARC-Entwicklung hätten ein gewisses Risiko für LEON dargestellt, aber dies hätte zu Recht als geringfügiges Problem angesehen werden können.)
• Das Fehlen von Same-ISA-Workstations hätte die anfängliche Entwicklung komplexer und kostspieliger gemacht.
• Selbst wenn man die Kosten für die Erstellung von Softwareentwicklungstools ausschließt, ist die Entwicklung einer neuen ISA mit erheblichen Kosten und Risiken verbunden. (Einen Konsens ohne Design-by-Committee-Effekte zu erzielen, ist eine Herausforderung, und die Gefahren des zweiten Systems könnten erheblich gewesen sein.)

Jede Erhöhung der (frühen) Kosten und Risiken kann die Wahrscheinlichkeit des Scheiterns des Projekts unverhältnismäßig erhöht haben. Andererseits hätte eine kundenspezifische ISA für den Zweck besser geeignet sein können und in der Luft- und Raumfahrt mehr externe Akzeptanz sowohl der ISA als auch der für die ESA entwickelten Chips (was die Qualität der Software erhöht hätte, erhöht das Testen von Implementierungen und reduzierte Hardwarekosten).

Wie kam es also dazu, dass die ESA SPARC einer benutzerdefinierten ISA vorzog (oder vielleicht eine begrenzte unbefristete Lizenz für eine andere RISC-ISA aushandelte)?