In late 1997, the European Space Agency started the LEON project to provide higher performance processors for ESA missions. An open instruction set architecture was a first-level requirement (both to avoid availability issues and to allow customization), but suitability for use in space was also a major consideration.
The ESA chose to use SPARC Version 8 (from 1991/1992 based on the copyright notice in The SPARC Architecture Manual: Version 8, the base ISA was released in 1987). SPARC had some advantages:
- It was perhaps the only fully open ISA with significant backing.
- It was a reasonably simple ISA (RISC), friendly to lower-effort implementation.
- Workstations existed using SPARC v8 compatible processors, so cross compiling could be avoided.
- Development tools for SPARC were reasonably mature, though presumably more oriented toward server/workstation workloads.
However, SPARC also had some disadvantages:
- By 1997 (with the introduction of the Pentium II) the future of SPARC in workstations would have begun to be under question (making the cross compiling issue somewhat moot).
- SPARC was not being broadly adopted as an open ISA, so there was not a significant commodity effect. (This was probably not a major consideration for LEON, but influences the availability of software tools. The openness of SPARC also has limited advantage in terms of patents.)
- As a classic RISC SPARC had somewhat poor code density. (Code size is a significant factor for space-based computers.)
- SPARC was not being broadly adopted for use in embedded systems. (This would have influenced the availability of development tools suitable for such systems.)
- SPARC's register windows would have increased minimum core size, slightly increased hardware design complexity, and involved more complex development for tightly constrained real time operation.
- SPARC included less useful features like tagged arithmetic. (This was probably not significant since a subset of the architecture could be used.)
- SPARC's instruction format was somewhat less regular than other RISCs. (This is a rather trivial objection; the size/power difference between instruction decoders for an Alpha-like ISA and SPARC would be less than 1%.)
With somewhat guaranteed use by the ESA of whatever architecture was chosen and the special requirements for space-based systems, it seems that a custom ISA might have been practical. A custom, open ISA would have significant disadvantages:
- The lack of existing development tools would have added cost and linked compiler development to hardware development (increasing schedule risk). (Non-open tools for SPARC development would have represented some risk to LEON, but this could rightly have been considered a minor issue.)
- The lack of same-ISA workstations would have added complexity and cost to initial development.
- Even excluding the cost of producing software development tools, developing a new ISA has significant cost and risk. (Getting consensus without design-by-committee effects is challenging and second system dangers may have been significant.)
Any increase in (early) cost and risk may have disproportionately increased the probability of project failure. On the other hand, a custom ISA could have been more fit for the purpose and might have been able to generate more external adoption in aerospace both of the ISA and of chips developed for the ESA (which would have increased the quality of software, increased the testing of implementations, and reduced hardware costs).
So how did the ESA come to choose SPARC over a custom ISA (or perhaps negotiating a limited perpetual license for another RISC ISA)?