Open-source versus
Proprietary ISAs Moderator: Mark Hill
(University Wisconsin) Panelists: Dave Christie
(AMD), Dave Patterson (University of Califonia,
Berkeley) Mark
Hill’s position statement Mark Hill will moderate this debate
and--like a referee--takes no position. Dave
Christie’s position statement It’s Not The ISA, It’s
The Ecosystem! The mainstream commercial ISAs,
particularly x86 and ARM but also MIPS, SPARC and PowerPC, have served
industry -- well, the whole world really -- quite well over the years. These ISAs have provided an effective
standard, and standards provide stability, and stability supports strong
ecosystems which in turn have enabled the tremendous breadth of applications
that have changed life as we once knew it.
But one can’t attribute the astounding progress we’ve seen over the
past 2-3 decades to a particular ISA definition any more than one can accuse
perceived weaknesses in these definitions for a lack of even greater
progress. If any of these ISAs have
become juggernauts, it’s because of the ecosystems that have developed around
them, and the underlying economics of those ecosystems. (This is business
after all.) How they got to that point -- how they
reached the critical mass of support to pretty much take on lives of their
own (ask Intel about how well IA-64 killed off x86) -- was as much about
marketing, support capabilities, economics, and a dose of chance here and
there, as it was about any “architectural goodness” of the ISA definitions
themselves. As long as the ISAs
provided the basics needed to support software development needs at a given
point in time -- such as an instruction set that compilers could readily
target, protection mechanisms and virtual memory for multi-tasking OS support
-- along with commercially feasible implementations, that was really all that
mattered. Many ISAs met that criteria;
to the extent any of them survived, thrived, or shone brightly then faded (or
were prematurely extinguished), it’s been driven far more by economic factors
than specific details of the ISA. Moreover, the evolution of these ISAs, at
least in the past decade or two, has for the most part demonstrated
responsible stewardship, with extensions that have been carefully thought out
from a benefit and need perspective, often in consultation with others in the
industry. SIMD, 64-bit, machine
virtualization? none of these could be viewed as a
misstep. This evolution, which also
takes into account the ecosystems’ needs for backwards compatibility, keeps
these ISAs very much alive. These
aren’t your grandpa’s ISAs, which were seen as a lock-in for a company’s
customer base. These are the ISAs that
killed those off, but only because they came in the form of implementations,
and with an ecosystem model, that completely changed the economics of the
industry in ways the owning companies couldn’t handle. It’s these ecosystems, and the economics
achieved by the standards that these ecosystems provide, that provide a
formidable hurdle for any open ISA effort that would aspire to replace them,
or even achieve parity. What would
they bring to the party? How many do
we need -- one ring to rule them all?
Who will drive and participate in them and, from a business
perspective, why? Dave
Patterson’s position statement Given that the industry has been
revolutionized by open standards and open-source software -- like TCP/IP and
Linux -- why is one of the most important interfaces proprietary? While instruction set architectures
(ISAs) may be proprietary for historical or business reasons, there is no
good technical reason for the lack of free, open ISAs. It's not an error of omission. Companies
with successful ISAs like ARM, IBM, Intel, and MIPS have patents on quirks of
their ISAs, which prevent others from using them without licenses that
academia and many small companies can't afford. Even IBM's OpenPower is an oxymoron; you must pay IBM to use its
ISA. An ARM license doesn't even let you
design an ARM core; you just get to use its designs. (Only about 10 big
companies have licenses that allow them to design custom versions of ARM
cores.) While the business is sound, licenses stifle competition and
innovation by stopping many from designing and sharing their ISA-compatible
cores. Nor is it because the companies do most
of the software development. Despite the value of the software ecosystems
that grow around popular ISAs, outsiders build almost all of their software. Neither do companies exclusively have the
experience needed to design a competent ISA. While it's a lot of work, many
today can design ISAs. Nor are the most popular ISAs wonderful
ISAs. ARM and 80x86 aren't considered ISA exemplars.
Neither can only companies that design
ISAs verify them. Long ago, open organizations developed mechanisms to ensure
compatibility with hardware standards, such as floating point units (IEEE
754), networking chips and switches (Ethernet), and I/O buses (PCIe). If not for such organizations, open IT standards
would not be so popular. Finally, proprietary ISAs are not
guaranteed to last. If a company dies, it takes its ISAs with it. Digital
Equipment's demise also terminated the Alpha and VAX ISAs. |