History Of The SPARC CPU Architecture

[RetroBytes] nicely presents the curious history of the SPARC processor architecture. SPARC, short for Scalable Processor Architecture, defined some of the most commercially successful RISC processors during the 1980s and 1990s. SPARC was initially developed by Sun Microsystems, which most of us associate the SPARC but while most computer architectures are controlled by a single company, SPARC was championed by dozens of players.  The history of SPARC is not simply the history of Sun.

A Reduced Instruction Set Computer (RISC) design is based on an Instruction Set Architecture (ISA) that runs a limited number of simpler instructions than a Complex Instruction Set Computer (CISC) based on an ISA that comprises more, and more complex, instructions. With RISC leveraging simpler instructions, it generally requires a longer sequence of those simple instructions to complete the same task as fewer complex instructions in a CISC computer. The trade-off being the simple (more efficient) RISC instructions are usually run faster (at a higher clock rate) and in a highly pipelined fashion. Our overview of the modern ISA battles presents how the days of CISC are essentially over.

IBM may have been the first player exploring RISC processor concepts, however work by two different university groups was more visible and thus arguably more influential. The Stanford group commercialized into MIPS  and Berkeley RISC commercialized into SPARC.

SPARC Versions 7 and 8, the first two versions of SPARC, were 32 bit architectures. Evolution to SPARC Version 9 jumped up to 64 bits but preserved backward compatibility. While having 64 bit registers, legacy 32 bit instructions operated identically as they had in previous versions.  Only a handful of new 64 bit instructions were required and those automatically made use of the upper 32 bits. Other advancements in SPARC Version 9 exploited knowledge from existing code to identify performance improvements. These included cache prefetch, data misalignment handling, and conditional moves to reduce branching. Other major improvements in SPARC Version 9 boosted OS performance.  These included instruction privileges, register privileges, and multiple trap levels.

The SPARC Version 9 improvements were defined by SPARC International, members of which include Sun Microsystems, Fujitsu, Texas Instruments, Cray, Ross, and others.  Sun was a significant part of SPARC International, but they did not go it alone.

Since SPARC Version 9, progress has mostly focused on multiprocessing with Fujitsu still manufacturing SPARC-based mainframes. SPARC has also become open and royalty free and found a footing in embedded computing.  Some have even synthesized SPARC processors onto inexpensive FPGAs.

31 thoughts on “History Of The SPARC CPU Architecture

  1. Like the humor, the native english (british) accent.
    Is there a chance to make the mans voice reading text to the audience
    on my a.t.m. text only YT video channel?
    Sorry I’m humbling when it comes to speaking perfect English.

    1. It’s not merely a British accent, but a Northern British accent! e.g. instead of the word ‘great’ being pronounced as ‘gray-t’ it will be pronounced as ‘greit’ (a cross between an ‘ay’ sound and an ‘air’ sound) :-)

  2. I find the claim that sparc was a multi-player thing highly questionable. As far as I know Sun was the only player in the sparc game. Yes fujitsu made sparc chips — for Sun. Let’s see a list of all these other players.

    1. I had a Fujitsu desktop for about 2 year, ran SunOS just like the actual Sun machines in the office, the fan rattled a bit more and it needed extra drivers for the graphics card in it. But it did have a sparc chip made by Fujitsu in it and ran SunOS from Sun Microsystems. This was sometime in the late 90’s, but eventually when Solaris took over from SunOS, I do not remember seeing many of them after that OS upgrade.

    2. Wikipedia’s SPARC page has a list of implementations, and lists several device vendors. Fujitsu still make their own SPARC servers, and has built several supercomputers based on their own SPARC processors (the latest generation famously moved to ARM, but that’s another story).

      One notable SPARC implementation I’m surprised wasn’t mentioned is the LEON series, which is used by the European Space Agency (though IIRC they’re planning on transitioning to RISC-V).

    1. They’re over in the sense that you’re unlikely to see any new CISC architectures anytime soon. The closest and most recent I can think of is the RX from Renesas, which allows direct memory addressing at least for certain instructions.

      1. As far as I can tell, RX isn’t new either, but is directly descended from Mitsubishi’s R32C/M32C/M16C, which like Matsushita mn10300 has been around since at least the 1990s, possibly earlier. Everything else seems to predate that by another two decades.

        The more interesting debate is RISC vs VLIW, as the latter still pop up every few years in new projects (Elbrus, IA64, Transmeta, Denver, Tile, Hexagon, C6x, Prodigy, Kalray, …), though aside from DSPs tend to get replaced by RISC designs over time.

        Curiously, MCST is one of the last holdouts for both VLIW (Elbrus 16S) and SPARC (R2000), both released in the past few years.

    2. Sort of? the x86 ISA is certainly CISC but the implementation turns those instructions into a series opcodes that feed a RISC core.

      It’s somewhat of a nitpicky argument but it gets kinda cool when you drill down.

  3. The Super FX chip used in several Super Nintendo cartridges was a general purpose RISC. It didn’t have special hardware polygon features, the polygons were all done in software.

    1. I think I read on “The Doom Engine Black Book” by Fabien Sanglard, that Dylan Cuthbert (one of the Star-Fox and SuperFX chip developeres) stated:

      > The SNES was just the I/O part. All the elaboration was made on the SuperFX

      Ah! Great period, the ’90s.

  4. Pyramid technology had a commercial RISC cpu shipping in 1983 in refrigerator sized servers outperforming the DEC VAX machines. Speaking of RISC, I contend that the PDP-11 was the grandfather of all RISC machines with ~75 orthogonal instructions.

    1. PDP-11 definitely was not RISC. RISC philosophy is not about limited number of instructions and definitely not about orthogonality. It’s about instructions being simple and using only specific instructions for memory access (load/store architecture).

  5. i don’t see a whole lot of variation between all the different RISC platforms…ARM, MIPS, SPARC, RISC V, PPC. the differences between them from a compiler code generation perspective are mostly just quirks, like ARM’s ability to bit-shift most operands, or SPARC’s banked registers, or of course the myriad approaches to floating point and vector instructions. but iirc off the top of my head none of them put you dealing with multiple kinds of basic arithmetic (ADD) instructions for all the different addressing modes, which makes all of them a delight compared to, say, x86 or even m68k. and they all have plentiful full-size registers as well.

    so all things being equal, i’d prefer they all go obsolete and just one carry forward. the variation seems needless today.

    and that’s where the real differences between them lie, too…ARM is in everything, RISC V might be growing, and the rest are dying. between the two, i am rooting for RISC V because its lower barrier to entry might guarantee a life at the periphery, it might as well take over the center too.

    as for the others, i say, good riddance to good history. :)

  6. For the a very long while, my website ran on a SPARC based SUN box. And it ran faster and even cooler than the hardware that proceeded it. It now runs on whatever AWS chose for the hardware box that the site is roosting on, and probably slower by now.

  7. The LEON processor which is SPARC based was also available for the eCOS project. I do not know the status now.

    Oh and Sun2 boxes sometimes show up at the VCF East consignment area.

  8. When I first graduated college I worked on a Sparcstation 20 workstation. At that time if you did any heavy duty computing you worked on a workstation. Usually one made by Sun, but sometimes ones made by DEC or Data General.

    Each workstation company had their own flavor of Linux. Sun had Solaris. Data General had DGUX. DEC had ULTRIX.

    I worked in a company that made ASICs and the ASIC tools only ran in Unix. No one was writing tools for Linux and certainly not for windows.

    Little by little desktops running Linux were getting more powerful and companies like Synopsis started porting their tools to Linux.

    One day people realized you could buy a $1200 desktop that would perform as well as the $12,000 workstations. It seemed like overnight all the workstation companies disappeared. Linux went from a hobbyist’s toy to the dominant player. in 1998 it was all workstations. By 2002 you’d be hard pressed to find a workstation in the workplace.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.