Hacker News Reader

Comment by unethical_ban | Hacker News Reader

As a totally ignorant person to CPU architecture, I do wonder what was wrong with OpenSPARC.

I remember hearing about it back in college in the 2000s and thinking "wow, open source hardware! This is revolutionary!". I'm sure there is a good reason it didn't work/scale, but does anyone here know?

View on HN

Andrew Waterman (Chief Engineer, Co-Founder of RISC-V and SiFive) describes the motivation for a new instruction set for RISC V in "Design of the RISC-V Instruction Set Architecture" (https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...).

The document contains a short discussion of the pros and cons of most architectures which were still somewhat popular at the time RISC V was designed (the Power/PPC is omitted) - MIPS, SPARC, Alpha, ARMv7/v8, OpenRISC and x86.

Major points that count against SPARC in Waterman's view are:

- SPARC register windows have significant power and area cost and complicate superscalar implementations

- Branches use condition codes which result in more complexity for OOO implementations with register renaming

- Load/store pair instructions also complicate implementations with register renaming (ARMv8 has introduced those, too)

- Moves between the floating-point and integer register files must use the memory system as an intermediary

- The only atomic memory operation is fetch-and-store, which is insufficient to implement many wait-free data structures

The openly available SPARC implementations are either embedded-style cores (e.g. Gaisler's LEON3) or relatively specialized cores for highly parallel workloads such as web serving (T1 and T2). Regular Sun 4m/4u cores were not available in source form, but the SPARC license would have allowed alternative implementations. The license used to be available for a one-time fee of $99, but it seems SPARC can be used free and without royalties now, the $99 are an optional registration fee at SPARC International (https://sparc.org/faq/#q3).

To add to this, Andrew et. al. at Berkeley built SPARC cores, so they were well aware of what it took to implement hardware to run SPARC software. I believe some of the really annoying challenges were at the system/privileged architecture level, including issues where off-the-shelf privileged software was either not obeying the specification or instead relied on undefined/underdefined corner cases. I believe RISCV's atomic read/modify/write CSR behavior was informed from some of these experiences.

Sparc has register windows[0] and branch delay slots[1]. The former was made obsolete by graph-coloring register allocation[2] and the latter by smarter branch predictors. It's certainly possible to design aggressive Sparc implementations, but newer designs such as RISC-V have a lot less legacy baggage.

[0] https://yarchive.net/comp/register_windows.html

[1] https://en.wikipedia.org/wiki/Delay_slot

[2] https://en.wikipedia.org/wiki/Register_allocation#Graph-colo...

To add to everything that's been said, opensparc only covers 32bit, and is thus of limited usefulness.

Same with OpenRISC, at the time the RISC-V project was started.

ARM too. The RISC-V design was fairly well advanced by the May 2011 spec, and IMAFD (and E) were in essentially their current form in the May 2014 spec.

Aarch64 was announced between those two in October 2011, with the first 64 bit Apple iPhone 5s shipping in September 2013 and with ARM's own cores such as Samsung Galaxy S6 in April 2015.

The first commercial RISC-V chip (SiFive FE310) shipped in December 2016.

Reply on news.ycombinator.com