SPARC
| File:Sun Microsystems logo.svg Sun Microsystems logo | |
| Company type | Public |
|---|---|
| Industry | Computer hardware |
| Founded | 24 February 1982 in Santa Clara, California, United States |
| Founder | Vinod Khosla, Andy Bechtolsheim, Scott McNealy, Bill Joy |
| Fate | Acquired by Oracle Corporation in 2010 |
| Successor | Oracle Corporation |
| Headquarters | Santa Clara, California , United States |
| Products | SPARC architecture, workstations, servers, software |
Number of employees | 38,000 |
| Parent | Oracle Corporation |
SPARC (an acronym for Scalable Processor ARChitecture) is a reduced instruction set computer (RISC) instruction set architecture initially created by Sun Microsystems. Drawing inspiration from the pioneering Berkeley RISC project of the early 1980s, SPARC was developed beginning in 1986 and officially launched in 1987. It emerged as one of the foremost commercially successful RISC architectures, influencing numerous similar designs throughout the 1980s and 1990s. Following Oracle's acquisition of Sun Microsystems, active SPARC development concluded in 2017, although Fujitsu continues to advance processor designs based on this architecture.
Description
By the mid-1980s, RISC architectures demonstrated a better price/performance ratio compared to conventional CISC processors. During this period, workstation manufacturer Sun Microsystems swiftly shifted from the Motorola 68000 series to processors based on RISC principles.
The original 32-bit SPARC V7 served as the foundation for Sun's Sun-4 workstation and server product lines, succeeding the earlier Motorola-based Sun-3 systems. Enhancements introduced with SPARC V8 were incorporated into the SuperSPARC CPUs released in 1992. The introduction of SPARC V9 in 1993 brought 64-bit capabilities, which were first commercially realized in Sun's UltraSPARC processors debuting in 1995. Later SPARC CPUs found application in symmetric multiprocessing (SMP) and non-uniform memory access (CC-NUMA) server platforms from companies including Sun, Solbourne, and Fujitsu.
In 1989, control over SPARC’s design transitioned to the SPARC International consortium, which oversees licensing, trademark rights—including ownership of the "SPARC" name—and compliance testing. This organization broadened SPARC’s reach by offering royalty-free licenses to multiple manufacturers such as Atmel, Bipolar Integrated Technology, Cypress Semiconductor, Fujitsu, Matsushita (Panasonic), and Texas Instruments.
As of 2024, prominent commercial SPARC processors comprise Fujitsu's SPARC64 XII, released in September 2017 for its SPARC M12 server line, alongside Oracle’s SPARC M8 processor for high-performance servers introduced during the same period.
On September 1, 2017, after a series of layoffs beginning in late 2016 at Oracle Labs, Oracle officially halted further development of SPARC processors following completion of the M8 model. Key engineering teams based in Austin, Texas; Santa Clara, California; and Burlington, Massachusetts were subsequently disbanded.
Fujitsu intends to phase out SPARC production after issuing two upgraded iterations of its legacy M12 server between 2020–22 and again during 2026–27. The planned end-of-sale date for UNIX servers is set for 2029, with mainframe support concluding by 2034 as part of a customer modernization initiative aimed at migrating away from traditional UNIX/SPARC environments.
Features
The design of SPARC was strongly shaped by earlier RISC projects such as Berkeley RISC I and II and the IBM 801. These early RISC architectures emphasized simplicity by targeting nearly one instruction per clock cycle, akin to the approach taken by the MIPS architecture, and omitted complex instructions including multiply or divide operations. Additionally, SPARC incorporates the branch delay slot, a hallmark feature derived from these foundational RISC concepts.
Typically, SPARC CPUs house up to 160 general-purpose registers. According to the "Oracle SPARC Architecture 2015" specification, implementations may vary between 72 and 640 general-purpose registers with 64-bit width. At any given moment, only 32 registers are accessible—comprising eight global registers (with g0 permanently set to zero) plus 24 registers drawn from a stack of register windows. Each register window consists of eight local registers and overlaps eight registers with adjacent windows used for passing arguments and returning values, thereby enhancing function call and return efficiency.
The "scalable" nature of SPARC allows it to be implemented across a spectrum ranging from embedded processors up to large-scale servers while maintaining a consistent core instruction set. The number of register windows can be configured between three and thirty-two depending on design trade-offs between efficient call stack handling and hardware complexity. Comparable register file mechanisms appear in other architectures such as the Intel i960, IA-64, and AMD 29000.
Over time, SPARC has undergone revisions: hardware support for multiply and divide instructions was introduced in version 8; version 9 added support for 64-bit addressing and data operations starting in 1994.
In version 8 of SPARC, the floating-point register file includes sixteen double-precision registers that can also be accessed as thirty-two single-precision registers by splitting each double-precision register. These can be paired to form eight quad-precision registers. Version 9 expanded this with sixteen additional double-precision registers (also available as eight quad-precision), though these cannot be used as single-precision registers. As of 2024, no existing SPARC CPU provides native hardware support for quad-precision floating-point operations.
Tagged add and subtract instructions verify that the lowest two bits of operands are zero and signal overflow if not. This feature supports runtime environments for languages like ML and Lisp, which utilize tagged integer representations.
SPARC V8 strictly adheres to big-endian byte ordering. In contrast, the 64-bit SPARC V9 maintains big-endian instruction encoding but allows data access using either big-endian or little-endian formats selectable at runtime or per memory page through MMU configuration. This capability facilitates compatibility with inherently little-endian peripherals such as PCI devices.
History
The SPARC architecture has undergone three significant revisions. The original 32-bit design, known as SPARC version 7 (V7), debuted in 1986. This was succeeded by SPARC version 8 (V8) in 1990, which introduced integer multiplication and division instructions and enhanced floating-point arithmetic capabilities from 80-bit to 128-bit quad-precision. V8 served as the foundation for the IEEE Standard 1754-1994 for 32-bit microprocessors.
In 1993, SPARC International released the 64-bit SPARC version 9 (V9) architecture, developed through collaboration among companies such as Amdahl, Fujitsu, ICL, LSI Logic, Matsushita, Philips, Ross Technology, Sun Microsystems, and Texas Instruments. Subsequent specifications have preserved full compliance with SPARC V9 Level 1.
Fujitsu and Sun jointly published the Joint Programming Specification 1 (JPS1) in 2002, outlining shared processor features implemented in their respective CPUs—the UltraSPARC III and SPARC64 V. This was followed by JPS2 in late 2003 to accommodate multicore processors, which was adopted by UltraSPARC IV and SPARC64 VI models.
Sun's 2006 release of the UltraSPARC Architecture 2005 extended the SPARC V9 standard by integrating enhancements from UltraSPARC III-IV+ and Chip Multi-Threading (CMT) features introduced with the UltraSPARC T1. These improvements included VIS 1 and VIS 2 instruction sets, multiple global register levels, a 64-bit memory management unit (MMU), new privileged instructions, and mechanisms for hyperprivileged register access.
The subsequent update, UltraSPARC Architecture 2007, was aligned with the UltraSPARC T2 processor implementation. In December of that year, Sun Microsystems made the UltraSPARC T2 processor's RTL design publicly available through the OpenSPARC initiative under the GNU GPL v2 license. The OpenSPARC T2 design incorporates eight cores with sixteen pipelines and supports up to sixty-four hardware threads.
Oracle introduced the Oracle SPARC Architecture 2011 reference in August 2012, which included updates such as VIS 3 instruction set extensions and a hyperprivileged mode. Later, in October 2015, Oracle unveiled the SPARC M7 processor based on the Oracle SPARC Architecture 2015, featuring VIS 4 extensions alongside hardware-accelerated encryption and silicon secured memory (SSM).
Since its initial implementation with V7 in 1987 through various UltraSPARC generations, SPARC architecture has maintained uninterrupted application binary compatibility. Notably, Sun's SuperSPARC and UltraSPARC-I processors served as standard reference platforms for SPEC CPU95 and CPU2000 benchmarks; similarly, the UltraSPARC-II at 296 MHz acted as a reference system for SPEC CPU2006.
Architecture
SPARC follows a load–store architecture paradigm—also called a register–register architecture—where all instructions operate on registers except those explicitly accessing memory, consistent with RISC design principles.
A typical SPARC CPU includes an integer unit (IU) responsible for load/store operations and arithmetic computations. It may also be equipped with a floating-point unit (FPU) dedicated to floating-point processing. In SPARC V8 implementations, an optional co-processor (CP) can be present for specialized functions; however, the architecture itself does not prescribe specific co-processor operations beyond load and store capabilities.
Registers
The architecture employs an overlapping register window mechanism featuring thirty-two visible general-purpose registers at any moment. Hardware maintains a Current Window Pointer (CWP) that selects which window is currently active. The total number of register windows is configurable—up to thirty-two windows are possible in SPARC V7 and V8 due to the five-bit CWP field within the Processor State Register (PSR).
In versions V7 and V8, procedure calls use the SAVE instruction to decrement CWP, thereby opening a new stack frame; conversely, RESTORE increments CWP to return from procedures. Trap events and RETT instructions also affect CWP. Starting with SPARC V9, this behavior is reversed: RESTORE decrements while SAVE increments CWP, but these changes do not apply to nonprivileged instructions.
| Register group | Mnemonic | Register address | Availability |
|---|---|---|---|
| global | G0...G7 | R[0]...R[7] | fixed; G0 is always zero |
| out | O0...O7 | R[8]...R[15] | passed as "in" registers to called subroutine |
| local | L0...L7 | R[16]...R[23] | local to current procedure |
| in | I0...I7 | R[24]...R[31] | received from caller as "out" registers |
Besides these windowed registers, there is a dedicated Y register used for multiply-step operations as well as integer multiplication and division instructions.
In SPARC V8 processors equipped with an FPU, there are thirty-two floating-point registers of thirty-two bits each designed for single-precision IEEE 754 floating-point values. Double-precision numbers occupy pairs of adjacent registers (even–odd pairs), while quadruple-precision values use groups of four consecutive registers.
For SPARC V9 CPUs featuring an FPU:
- Thirty-two registers of thirty-two bits each support single-precision IEEE 754 floating-point numbers;
- Thirty-two sixty-four-bit registers handle double-precision values;
- Sixteen one-hundred-twenty-eight-bit registers accommodate quad-precision data.
These sixty-four thirty-two-bit floating-point registers are organized such that pairs combine into sixty-four-bit registers and quartets form one-hundred-twenty-eight-bit registers. All floating-point registers are globally accessible and do not utilize windowing.
Instruction formats
Every SPARC instruction is encoded within a 32-bit word, aligned on word boundaries. The initial two bits determine one of four distinct instruction formats. Arithmetic and logical operations involve two source operands and one destination operand. The destination register, labeled RD, receives the result and is positioned near the start of the instruction. The source registers, RS1 and RS2, provide input values; RS2 can alternatively be replaced by an immediate constant.
| Type | Bit | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| SETHI format | 00 | RD | 100 | Immediate constant (22 bits) | ||||||||||||||||||||||||||||
| I Branch format | 00 | A | icc | 010 | Displacement constant (22 bits) | |||||||||||||||||||||||||||
| F Branch format | 00 | A | fcc | 110 | Displacement constant (22 bits) | |||||||||||||||||||||||||||
| C Branch format | 00 | A | ccc | 111 | Displacement constant (22 bits) | |||||||||||||||||||||||||||
| CALL disp | 01 | PC-relative displacement | ||||||||||||||||||||||||||||||
| Arithmetic register | 10 | RD | opcode | RS1 | 0 | 0 | RS2 | |||||||||||||||||||||||||
| Arithmetic immediate | 10 | RD | opcode | RS1 | 1 | Immediate constant (13 bits) | ||||||||||||||||||||||||||
| FPU operation | 10 | FD | 110100/110101 | FS1 | opf | FS2 | ||||||||||||||||||||||||||
| CP operation | 10 | RD | 110110/110111 | RS1 | opc | RS2 | ||||||||||||||||||||||||||
| JMPL register | 10 | RD | 111000 | RS1 | 0 | 0 | RS2 | |||||||||||||||||||||||||
| JMPL immediate | 10 | RD | 111000 | RS1 | 1 | Immediate constant (13 bits) | ||||||||||||||||||||||||||
| LD/ST register | 11 | RD | opcode | RS1 | 0 | 0 | RS2 | |||||||||||||||||||||||||
| LD/ST immediate | 11 | RD | opcode | RS1 | 1 | Immediate constant (13 bits) | ||||||||||||||||||||||||||
Loads and stores
Load and store instructions utilize two operands to compute a memory address and a third to indicate the register involved in data transfer. The effective address results from adding the two address operands, where the second operand can be either a register or an immediate value. Load operations fetch data from memory into the specified register, whereas store operations write data from a register back into memory. Assembly syntax represents address operands within square brackets combined by a plus sign; for example, ld [%L1+%L2],%L3 loads the data located at the address formed by %L1 plus %L2 into register %L3.
SPARC supports multiple data sizes for load/store instructions: bytes (8 bits), half-words (16 bits), full words (32 bits), and double-precision values (64 bits). When loading, registers are either zero-filled for unsigned data or sign-extended according to the highest bit for signed data. Store instructions write only the relevant lower portion of the register's content to memory. Double-precision load/store commands operate across register pairs. Common instructions include LD, ST, LDUB, LDSB, LDUH, LDSH, LDD, STB, STH, and STD.
In the SPARC V9 architecture with its expanded 64-bit registers, load and store instructions have been adapted accordingly. The LD instruction becomes LDUW when zero-extending loads of the lower 32 bits are performed; similarly, ST is renamed STW for storing the lower half of a register. Additional instructions such as LDSW allow sign-extending loads of words, while LDX and STX handle complete 64-bit transfers.
Floating-point load and store instructions include LDF for single precision, LDDF for double precision, and LDQF for quad precision loads; their corresponding store operations are STF, STDF, and STQF.
The MEMBAR instruction ensures memory operation ordering by guaranteeing that all previous store effects are globally visible before any subsequent load instructions execute. This mechanism provides explicit synchronization control over memory references across multiple processors.
ALU operations
Arithmetic and logical commands follow a three-operand structure: two source operands and one destination register. The middle operand may be either a register or a 13-bit signed immediate value; the other operands must be registers. Any operand can refer to G0, and results written to G0 are discarded—this feature is useful for condition testing. Illustrative examples include:
add %L1,%L2,%L3 !sum values in %L1 and %L2, store result in %L3 add %L1,1,%L1 !increment the contents of %L1 add %G0,%G0,%L4 !reset %L4 to zero
Essential instructions encompass , , , , , along with their negated counterparts , , and . Most arithmetic instructions come in pairs: one variant updates the NZVC condition flags in the status register, while the other does not, granting compilers flexibility for optimizing delay slots. Appending to an instruction activates condition code updates:
subcc %L1,10,%G0 !compare %L1 with 10, update flags but discard result
The X suffix on add/sub indicates carry flag propagation:
addx %L1,100,%L1 !add 100 to %L1 and track carry bit
While SPARC V7 does not support hardware multiply/divide instructions, it includes which performs one multiplication step per cycle, consistent with RISC design principles. SPARC V8 introduced complete multiply and divide instructions: , , , and , each available with optional condition code updates. These instructions utilize the Y register to hold the upper 32 bits of the product or dividend; registers and provide access to Y. SPARC V9 further expanded functionality with 64-bit multiply/divide instructions (, , ) that operate without involving the Y register.
Branching
Conditional branching relies on testing condition codes stored in the status register, necessitating an ALU instruction that sets these flags followed by a branch instruction that evaluates them. In SPARC, standard ALU operations targeting %G0 are employed for such tests:
subcc %L1,10,%G0 !set zero flag if %L1 equals 10 be WASEQUAL !branch if zero flag is set
Branch instructions define conditions via icc or fcc fields and employ a 22-bit PC-relative displacement, supporting a ±8MB range. The ANNUL (A) bit determines delay slot behavior: when set, the delay slot executes only if the branch is taken.
Available branch types include unconditional (), never (), equal (), not equal (), less than (), less or equal (), as well as unsigned variants like , along with tests on sign, carry, and overflow flags.
Condition codes from the FPU and coprocessors are managed separately; prefixing branch instructions with F or C targets these specific sets of flags.
The instruction enables subroutine jumps using a 30-bit PC-relative word offset that spans the full 4GB address space; it saves the return address in register R15 (also known as output register O7). The three-operand instruction calculates jump targets by adding two operands—where the second operand can be either a constant or register—and stores the return address in a designated register.
Large constants
Because instruction opcodes consume bits within the fixed 32-bit instruction word, loading an entire 32-bit constant requires multiple instructions. This is especially important since registers hold 32-bit addresses. The specialized instruction loads a 22-bit immediate into the upper bits of a register while clearing its lower 10 bits. This is commonly followed by an instruction that sets the lower 10 bits. Assemblers provide convenient macros like and to simplify this sequence:
sethi %hi(0x89ABCDEF),%L1 !load upper 22 bits into L1 or %L1,%lo(0x89ABCDEF),%L1 !set lower 10 bits using OR
These macros are resolved during assembly time, avoiding runtime penalty and making clear that %L1 holds a single combined value. To further streamline this process, assemblers offer a pseudo-instruction , which merges both steps:
set 0x89ABCDEF,%L1
If the immediate fits within a signed 13-bit range, then only one instruction is emitted instead.
Synthetic instructions
To streamline frequent programming operations and enhance coding productivity, the SPARC assembler utilizes synthetic instructions. Notable instances include:
| mnemonic | actual output | function |
|---|---|---|
| <syntaxhighlight lang="text" class="" style="" inline="1">nop</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">sethi 0,%g0</syntaxhighlight> | performs no operation |
| <syntaxhighlight lang="text" class="" style="" inline="1">clr %reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">or %g0,%g0,%reg</syntaxhighlight> | resets a register to zero |
| <syntaxhighlight lang="text" class="" style="" inline="1">clr [address]</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">st %g0,[address]</syntaxhighlight> | clears memory at specified location |
| <syntaxhighlight lang="text" class="" style="" inline="1">clrh [address]</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">sth %g0,[address]</syntaxhighlight> | zeros out half-word at memory address |
| <syntaxhighlight lang="text" class="" style="" inline="1">clrb [address]</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">stb %g0,[address]</syntaxhighlight> | clears a byte in memory at address |
| <syntaxhighlight lang="text" class="" style="" inline="1">cmp %reg1,%reg2</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">subcc %reg1,%reg2,%g0</syntaxhighlight> | compares two registers and updates condition flags |
| <syntaxhighlight lang="text" class="" style="" inline="1">cmp %reg,const</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">subcc %reg,const,%g0</syntaxhighlight> | compares a register with a constant value |
| <syntaxhighlight lang="text" class="" style="" inline="1">mov %reg1,%reg2</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">or %g0,%reg1,%reg2</syntaxhighlight> | duplicates register content |
| <syntaxhighlight lang="text" class="" style="" inline="1">mov const,%reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">or %g0,const,%reg</syntaxhighlight> | loads a constant into a register |
| <syntaxhighlight lang="text" class="" style="" inline="1">inc %reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">add %reg,1,%reg</syntaxhighlight> | increments the value in a register by one |
| <syntaxhighlight lang="text" class="" style="" inline="1">inccc %reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">addcc %reg,1,%reg</syntaxhighlight> | increments with condition code updates |
| <syntaxhighlight lang="text" class="" style="" inline="1">dec %reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">sub %reg,1,%reg</syntaxhighlight> | decrements register value by one |
| <syntaxhighlight lang="text" class="" style="" inline="1">deccc %reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">subcc %reg,1,%reg</syntaxhighlight> | decrements with condition code updates |
| <syntaxhighlight lang="text" class="" style="" inline="1">not %reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">xnor %reg,%g0,%reg</syntaxhighlight> | performs bitwise NOT on register contents |
| <syntaxhighlight lang="text" class="" style="" inline="1">neg %reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">sub %g0,%reg,%reg</syntaxhighlight> | computes two's complement (negation) of register value |
| <syntaxhighlight lang="text" class="" style="" inline="1">tst %reg</syntaxhighlight> | <syntaxhighlight lang="text" class="" style="" inline="1">orcc %reg,%g0,%g0</syntaxhighlight> | tests whether register is positive, zero, or negative |
SPARC architecture licensees
Prior to SPARC's introduction, Intel was the exclusive manufacturer of the 80386 processor, resulting in high costs and industry concerns regarding reliance on a single CPU source. When Sun Microsystems launched SPARC in 1987, it committed to making the architecture accessible through multiple vendors. Fujitsu became the initial licensee, followed by Cypress Semiconductor; by 1989, these companies had released SPARC CPUs alongside Texas Instruments's floating-point units. Prominent licensees of the SPARC architecture include:
- Afara Websystems
- Bipolar Integrated Technology (BIT)
- Cypress Semiconductor
- European Space Research and Technology Center (ESTEC)
- Fujitsu (including Fujitsu Microelectronics)
- Gaisler Research
- HAL Computer Systems
- Hyundai
- LSI Logic
- Matra Harris Semiconductors (MHS)
- Matsushita Electrical Industrial Co.
- Meiko Scientific
- Metaflow Technologies
- Philips Electronics
- Prisma
- Ross Technology
- Solbourne Computer
- Systems & Processes Engineering Corporation (SPEC)
- TEMIC
- Texas Instruments
- Weitek
Implementations
... [Table continues listing significant models with details on clock rates, architecture revisions, launch years, threading capabilities, fabrication processes, transistor quantities, power usage, and cache sizes]| Name (codename) | Manufacturer | Clock Speed (MHz) | Architecture Version | Release Year | Total Threads[note 1] | Fabrication Process (nm) | Transistor Count (millions) | Die Dimensions (mm2) | IO Pin Count | Power Consumption (W) | Operating Voltage (V) | L1 Data Cache (KB) | L1 Instruction Cache (KB) | L2 Cache (KB) | L3 Cache (KB) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SPARC MB86900 | Fujitsu | "14.28–33" | V7 | 1986 | 1×1=1 | 1300 | 0.11 | — | 256 | — | — | 0–128 (unified) | none | none | |
| SPARC | "Various"[note 2] | "14.28–40" | V7 | 1989–1992 | 1×1=1 | 800–1300 | ~0.1–1.8 | — | 160–256 | — | — | 0–128 (unified) | none | none | |
| MN10501 (KAP) | "Solbourne Computer, Matsushita" | "33–36" | "V8" | "1990–1991" | "1×1=1" | —" | "1.0"[1] | —" | —" | —" | —" | "8" | "8" | "0–256" | none" |
| microSPARC I (Tsunami) | "TI TMS390S10" | "40–50" | V8 | 1992 | 1×1=1 | 800 | 0.8 | 225? | 288 | 2.5 | 5 | 2 | 4 | none | none |
| SuperSPARC I (Viking) | "TI TMX390Z50 / Sun STP1020" | "33–60" | V8 | 1992 | 1×1=1 | 800 | 3.1 | — | 293 | 14.3 | 5 | 16 | 20 | 0–2048 | none |
| SPARClite | "Fujitsu MB8683x" | "66–108" | V8E | 1992 | 1×1=1 | 144, 176 | 2.5/3.3–5.0 V, 2.5–3.3 V | 1, 2, 8, 16 | 1, 2, 8, 16 | none | none | ||||
| hyperSPARC (Colorado series) | "Ross RT620A-D variants" | "40–200" | V8 | 1993–1996 | 1×1=1 | varied from 5? to 16 KB L2 cache and up to 256 KB L3 cache | |||||||||
| microSPARC II (Swift) | "Fujitsu MB86904 / Sun STP1012" | "60–125" | V8 | 1994 | 1×1=1 | 233 | 321 | 5 | 3.3 | 8 | 16 | style="background: #EEE; color:black; vertical-align: middle; text-align: center; " class="table-cast"|none | style="background: #EEE; color:black; vertical-align: middle; text-align: center; " class="table-cast"|none| | ||
| UltraSPARC T7 / M7 series | "Oracle" | "4133 MHz" | OSA2015 | 2015 | 8×32=256 | 20 nm | >10 billion transistors | Template:Dunno | Template:Dunno | Template:Dunno | Template:Dunno | 16×32 KB Dcache | 16×32 KB Icache | 256×24 KB L2 cache | 65536 KB L3 cache |
| SPARC64 XII | "Fujitsu" | "4250 MHz" | OSA201? / HPC-ACE | 2017 | 8×12=96 | 20 nm | 5500 million transistors | 795 mm² | 1860 IO pins | Template:Dunno | Template:Dunno | 64×12 KB Dcache | 64×12 KB Icache | 512×12 KB L2 cache | 32768 KB L3 cache |
| SPARC M8 | "Oracle" | "5000 MHz" | OSA2017 | 2017 | 8×32=256 | 20 nm | transistor count unknown | die size/power/voltage/cache details not disclosed | |||||||
| LEON4 | (Cobham Gaisler) GR740 | V8E |2017 |1×4=4 |32 nm | data not available | data not available | data not available | data not available | 1.2/2.5/3.3 V |4x4 KB Dcache |4x4 KB Icache |2048 KB L2 cache | style="background: #EEE; color:black; vertical-align: middle; text-align: center; " class="table-cast"|none | |||||||||||||
Notes:
Operating system compatibility
SPARC platforms have predominantly run operating systems developed by Sun, including SunOS, Solaris, JavaOS, as well as OpenSolaris and its derivatives such as illumos and OpenIndiana. Additionally, these systems have supported other OS options like NeXTSTEP, RTEMS, FreeBSD, OpenBSD, NetBSD, and various distributions of Linux.
In 1993, Intergraph revealed plans to port Windows NT to the SPARC architecture, though this initiative was eventually discontinued. Later, in October 2015, Oracle launched a "Linux for SPARC reference platform" to extend Linux support on SPARC hardware.
Open source SPARC projects
There are multiple open source implementations of the SPARC architecture available:
- LEON: a 32-bit SPARC V8 core engineered for radiation resilience, primarily targeting aerospace applications. Its source code is written in VHDL and distributed under the GPL.
- OpenSPARC T1: introduced in 2006, this 64-bit processor design features 32 threads and adheres to the UltraSPARC Architecture 2005 and SPARC Version 9 standards. The Verilog source code is largely licensed under the GPL.
- S1: a 64-bit CPU core compatible with the Wishbone bus, derived from OpenSPARC T1 and supporting 4-way simultaneous multithreading (SMT), also released under the GPL.
- OpenSPARC T2: launched in 2008, this 64-bit design supports 64 threads and complies with UltraSPARC Architecture 2007 and SPARC Version 9; its Verilog source is predominantly GPL-licensed.
A comprehensive open source SPARC simulator named RAMP Gold exists as well. It implements a 32-bit, 64-thread SPARC V8 processor tailored for FPGA simulation and is developed in SystemVerilog under BSD licenses.
Supercomputing applications
Fujitsu produces specialized processors known as SPARC64 fx that incorporate HPC-ACE instruction set extensions designed for high-performance computing environments.
The Fujitsu K computer achieved the top position on the TOP500 supercomputer list in both June and November of 2011. It featured 88,128 SPARC64 VIIIfx CPUs with an aggregate of 705,024 cores—nearly twice the core count of any competing system at that time. This system outperformed the next five highest-ranked supercomputers combined and led in energy efficiency metrics. On the June 2011 edition of the Green500 list, it secured sixth place with an efficiency rating of 824.56 MFLOPS/W. By November 2012, although it had dropped to third place on TOP500, it was noted for having the highest power consumption among leading systems and ranked eighty-fifth on Green500. Subsequent HPC processors such as the IXfx and XIfx models power newer Fujitsu PRIMEHPC FX10 and FX100 supercomputers.
China’s supercomputer Tianhe-2, which claimed first place on the November 2014 TOP500 list, incorporates nodes equipped with domestically developed Galaxy FT-1500 processors based on OpenSPARC technology; however, these processors were not factored into its LINPACK benchmark performance.
See also
- ERC32 — a processor based on the SPARC V7 specification
- Ross Technology, Inc. — a developer of SPARC microprocessors during the 1980s and 1990s
- Sparcle — a modified SPARC architecture that supports multiprocessing, utilized in MIT’s Alewife project
- LEON — a space-qualified SPARC V8 microprocessor
- R1000 — a Russian quad-core microprocessor conforming to the SPARC V9 standard
- Galaxy FT-1500 — a Chinese OpenSPARC-based processor featuring sixteen cores
External links
- SPARC International, Inc.
- Oracle SPARC Processor Documentation (archived October 13, 2019)
- Technical Documents for SPARC
- OpenSPARC Architecture Specification
- Reference Materials for Hypervisor/Sun4v
- Fujitsu Extensions for SPARC64 V, VI, VII, VIIIfx, IXfx (archived April 3, 2019)
- X / X+ Specification Documents
- Documentation for Sun UltraSPARC Processors (archived January 14, 2010)
- Sun FOSS Open Hardware Documentation (archived December 9, 2011)
- OpenSPARC Project (archived February 27, 2011)
- Oracle SPARC and Solaris Public Roadmap (archived May 25, 2018)
- Fujitsu SPARC Development Roadmap
- Collection of SPARC Processor Images and Descriptions
- The Rough Guide to MBus Modules (covering SuperSPARC and hyperSPARC)
- Comprehensive Listing of Operating Systems Compatible with SPARC64 Processors
Cite error: <ref> tags exist for a group named "note", but no corresponding <references group="note"/> tag was found