Assembler (SPARC)

Assembler (SPARC) is the assembly language for the SPARC architecture — Scalable Processor ARChitecture — the RISC design Sun Microsystems introduced commercially in 1987 with the Sun-4 workstation. SPARC descends directly from the Berkeley RISC project, and it inherited that project’s most distinctive idea: register windows, a hardware mechanism that hands each function its own fresh set of registers, so that in the common case a procedure call needs no register saving or restoring at all. Reading SPARC assembly means understanding register windows, because almost every function in a SPARC binary begins with save and ends with restore, and the register names change meaning as you cross that boundary.

SPARC was also unusual in a non-technical way. In 1989, Sun handed the architecture specification to SPARC International, an independent trade organization, and licensed it broadly. That decision produced compatible processors from Fujitsu, Texas Instruments, Cypress, and others, an IEEE standard, an open-source core sponsored by the European Space Agency, and eventually the GPL-licensed release of a complete shipping processor design. Oracle wound down SPARC processor development after the M8 in 2017, but SPARC assembly remains in active use in space systems, in long-lived Solaris deployments, and in academic processor research.

History & Origins

From Berkeley RISC to SPARC (1980-1986)

SPARC’s lineage runs through the Berkeley RISC project led by David Patterson at UC Berkeley in the early 1980s. Berkeley’s RISC-I and RISC-II prototypes argued that a small, uniform instruction set could outperform complex ones, and they pushed one particular idea harder than any contemporary: a large physical register file exposed through a sliding window, so that a procedure call could give the callee its own registers by moving a pointer rather than by saving and restoring memory.

Sun Microsystems — then a workstation company buying Motorola 68000-family processors — took that design as the basis for its own architecture. The 32-bit SPARC Version 7 specification was published in 1986, and Fujitsu produced the MB86900, the first SPARC implementation. Sun did not build the chip itself; from the very beginning SPARC was a specification implemented by partners, a model that shaped everything that followed.

Commercial Launch and Openness (1987-1994)

The Sun-4/260 shipped in July 1987 as the first SPARC-based workstation. SPARC became the platform for SunOS and later Solaris, and Sun’s workstation business grew around it through the late 1980s and 1990s.

In 1989 Sun transferred stewardship of the architecture to SPARC International, a member-funded body that published the specifications and ran compliance testing. This was a deliberate strategy: an architecture that multiple vendors could build would attract more software than one locked to a single supplier. It worked well enough that SPARC chips came from Fujitsu, Texas Instruments, Cypress Semiconductor, Ross Technology, and others.

SPARC V8 arrived in 1990, most visibly adding hardware integer multiply and divide. It became the basis for IEEE Standard 1754-1994, one of very few microprocessor architectures ever standardized by the IEEE. SPARC V9, the 64-bit architecture, was released by SPARC International in 1993, developed by a committee whose members included Sun, Fujitsu, and Amdahl.

UltraSPARC, Niagara, and Open Silicon (1995-2010)

Sun’s UltraSPARC, introduced in 1995, was its first V9 implementation and introduced VIS, a SIMD extension aimed at graphics and image processing. The UltraSPARC line carried Sun’s servers through the dot-com era.

The most interesting late chapter began in 2005 with the UltraSPARC T1, codenamed Niagara. Instead of chasing single-thread performance, T1 put eight simple cores on a die, each running four hardware threads — 32 threads total — betting that server workloads are throughput-bound rather than latency-bound. In March 2006 Sun released the T1 design as OpenSPARC T1 under the GPL v2, publishing the Verilog RTL of a processor it was actively selling. OpenSPARC T2 followed in December 2007. Full RTL releases of a shipping, high-end commercial CPU were essentially unheard of at the time.

Meanwhile, Fujitsu pursued a parallel high-performance track with its SPARC64 processors, culminating in the SPARC64 VIIIfx used in the K computer, which reached No. 1 on the TOP500 in June 2011 at 8.162 petaflop/s on LINPACK.

Oracle and Wind-Down (2010-2017)

Oracle completed its acquisition of Sun in 2010 and continued SPARC development for several years, shipping the T-series and M-series with accelerators for cryptography and database operations built into the silicon. Oracle completed the SPARC M8 in 2017 and subsequently ended SPARC processor development. Solaris on SPARC remains under long-term support commitments, so deployed systems persist, but new SPARC silicon from Oracle is no longer forthcoming.

Design Philosophy

Register windows above all. SPARC’s defining choice is that the architectural register file is a window onto a much larger physical file. A procedure call rotates the window; the caller’s outputs become the callee’s inputs, with no memory traffic. This is inherited from Berkeley RISC and is the feature that most sharply distinguishes SPARC assembly from MIPS, ARM, or RISC-V.

A specification, not a chip. SPARC was written as an architecture that many vendors would implement, with implementation-dependent details deliberately left open — the number of register windows is a per-implementation parameter, not a fixed constant. Software that assumes a specific window count is not portable SPARC.

Load/store RISC discipline. Arithmetic operates on registers; only load and store touch memory. Addressing modes are limited to register plus register or register plus 13-bit signed immediate. Instructions are a fixed 32 bits and word-aligned.

Expose the pipeline. Like other RISC designs of its generation, SPARC has delay slots: the instruction after a branch or call executes before the transfer of control completes. SPARC adds a refinement — the annul bit — that lets a branch conditionally cancel its delay slot, which makes filling the slot useful far more often.

Room for the compiler and the assembler. SPARC assemblers provide a rich set of synthetic instructions, and the architecture leaves the assembler responsible for expanding large constants and addresses into instruction pairs.

Key Features

Register Windows

At any instant, 32 general-purpose registers are visible, in four groups of eight:

The save instruction advances the Current Window Pointer (CWP). The effect is that the caller’s %o registers become the callee’s %i registers — the same physical registers under different names — while the callee gets fresh %l and %o registers. restore moves the window back.

   caller's window:   [ globals ] [ ins ] [ locals ] [ outs ]
                                                        \
                                                         overlap
                                                        /
   callee's window:   [ globals ]        [ ins ] [ locals ] [ outs ]

Arguments therefore pass without any register shuffling, and returning a value means writing to %i0, which the caller reads as %o0.

The register file is finite, so the windows form a ring. When a save would overflow into the oldest live window, the processor traps — a window overflow — and the operating system’s trap handler spills a window to the stack. The mirror case, a window underflow trap, reloads one. This machinery is invisible to ordinary code and essential to systems programmers: SPARC kernels must implement spill and fill handlers, and the number of windows is implementation-defined (commonly 8, but the architecture permits a range).

%sp is %o6 and %fp is %i6, which follows naturally: the callee’s frame pointer is the caller’s stack pointer, established automatically by save.

Instruction Formats and Encoding

Every SPARC instruction is 32 bits and word-aligned. The top two bits select among a small number of formats covering sethi and branches, call, and the arithmetic/load-store forms. The call instruction carries a 30-bit word displacement, giving it a full 32-bit byte range — a nice consequence of fixed-size aligned instructions.

Because a 13-bit immediate is the largest that fits in an arithmetic instruction, loading a 32-bit constant takes two instructions, conventionally sethi plus an or:

1
2

        sethi   %hi(0x12345678), %l0    ! upper 22 bits
        or      %l0, %lo(0x12345678), %l0

Assemblers hide this behind the synthetic set instruction, which expands to one or two real instructions depending on the value — one reason set cannot legally be placed in a delay slot.

Delay Slots and the Annul Bit

The instruction following a control transfer executes anyway:

1
2
3

        cmp     %l0, %l1
        be      equal           ! branch if equal
        nop                     ! delay slot: always executes

SPARC’s addition to the standard delay-slot design is the annul bit, written as a ,a suffix. On a conditional branch, ,a means the delay-slot instruction is annulled (has no effect) when the branch is not taken. This makes it safe to move an instruction from the branch target into the delay slot, which is exactly what a loop wants:

1
2
3
4
5
6

loop:
        ld      [%l0], %l2
        add     %l0, 4, %l0
        subcc   %l1, 1, %l1
        bne,a   loop            ! annulled if not taken
        ld      [%l0], %l2      ! target's first instruction, hoisted here

Disassembly of optimized SPARC code is full of these, and misreading an annulled slot is a common source of confusion.

Synthetic Instructions

SPARC assemblers define a substantial set of synthetic (pseudo) instructions that map onto real ones:

The %g0 register does most of the work here. Reads return zero and writes are discarded, so it doubles as both a constant source and a discard destination — which is how a comparison becomes a subtract whose result nobody wants.

The + 8 in ret is not arbitrary: call saves the address of the call instruction, and the delay slot occupies the following word, so the return address is two instructions later.

Condition Codes

Unlike MIPS, SPARC does have condition codes. Arithmetic instructions ending in cc (addcc, subcc, andcc) set the integer condition-code register, and conditional branches test it. SPARC V9 added a second set of condition codes for 64-bit results (%xcc alongside %icc), plus conditional-move instructions that let short branches be eliminated entirely.

Tagged Arithmetic

SPARC includes taddcc and tsubcc, tagged add and subtract instructions that set the overflow condition when the low two bits of either operand are non-zero, along with trap-on-overflow variants (taddcctv, tsubcctv). These exist to accelerate dynamically-typed languages — Lisp and Smalltalk implementations that tag small integers in the low bits of a word — and are a small window into the language concerns of the mid-1980s. They were retained in V9, which deprecates the trapping variants, and are rarely used today.

Hello World (Linux/SPARC, 32-bit)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

        .section ".rodata"
msg:    .asciz  "Hello, World!\n"
        .set    msglen, 14

        .section ".text"
        .global _start
_start:
        mov     4, %g1          ! write
        mov     1, %o0          ! fd = stdout
        set     msg, %o1        ! buffer
        mov     msglen, %o2     ! length
        ta      0x10            ! trap into the kernel

        mov     1, %g1          ! exit
        clr     %o0
        ta      0x10

System calls are made with a trap instruction rather than a dedicated opcode: the call number goes in %g1, arguments in %o0 onward, and ta raises a software trap. On Solaris the mechanism is the same shape but uses a different trap number and its own call numbering, so the two are not interchangeable.

Function Calls

The canonical SPARC function is a save/restore pair, with the return folded into the delay slot:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

sum3:                           ! int sum3(int a, int b, int c)
        save    %sp, -96, %sp   ! new register window + stack frame
        add     %i0, %i1, %l0   ! args arrive in %i0..%i2
        add     %l0, %i2, %l0
        ret                     ! jmpl %i7 + 8, %g0
        restore %l0, 0, %o0     ! delay slot: result lands in caller's %o0

caller:
        save    %sp, -96, %sp
        mov     1, %o0
        mov     2, %o1
        call    sum3
        mov     3, %o2          ! delay slot: third argument
        ! result now in %o0
        ret
        restore

Two idioms are worth naming. First, restore sits in ret’s delay slot and does double duty: it pops the window and performs add %l0, 0, %o0, writing the result into what the caller sees as %o0. Second, the third argument is set up in the call’s delay slot — textually after the call, but executed before control reaches the callee. Both are ubiquitous in real SPARC code and both surprise people reading it for the first time.

Leaf functions that make no calls of their own often skip save entirely and return with retl, using %o registers directly.

Evolution

The V8-to-V9 transition is the one that matters most for assembly programmers. V9 widened the integer registers to 64 bits while keeping the register-window model intact, so V8 code reads almost unchanged — but the stack bias, calling conventions, and condition-code handling differ, and a 64-bit SPARC frame is not a 32-bit frame with wider slots.

Current Relevance

SPARC is no longer a growing architecture, but SPARC assembly is not a dead skill:

Space systems. The LEON family — open-source, fault-tolerant SPARC V8 cores initiated by the European Space Agency and developed with Gaisler — is a standard processor for European space missions. Radiation-tolerant SPARC parts fly on spacecraft with decade-plus operational lifetimes, and their flight software is built with SPARC toolchains.

Solaris in the enterprise. Large SPARC/Solaris installations, particularly around Oracle databases, are still in production and still supported. Debugging, performance work, and kernel-level maintenance on those systems involves reading SPARC disassembly.

Processor research and teaching. OpenSPARC T1 and T2 remain among the few complete, industrially-verified processor designs available under a free license, and they continue to serve as reference material for computer architecture work and FPGA-based research.

Emulation and preservation. QEMU emulates both 32-bit and 64-bit SPARC systems, which keeps Solaris and SunOS software runnable without original hardware and makes SPARC assembly accessible to anyone curious about it.

Toolchain support is solid and maintained: GCC and GNU binutils target SPARC, and cross-toolchains are packaged by major Linux distributions. Debian maintains an unofficial sparc64 port.

Why It Matters

SPARC matters for three things.

The first is register windows, the most fully-realized commercial implementation of an idea that was, in the 1980s, a genuine open question in architecture: should the hardware manage the calling convention? SPARC said yes, emphatically. The answer turned out to be contested — MIPS, ARM, and later RISC-V all declined to follow, on the grounds that windows complicate context switching, make register file design harder, and mostly solve a problem that compilers can solve in software. But it was a real experiment run at commercial scale, and the trade-offs it exposed informed everything designed afterward. Intel’s Itanium later revisited the same territory with its register stack engine, arriving at a different set of compromises.

The second is the open-architecture model. Handing the specification to SPARC International in 1989, licensing it widely, standardizing it through the IEEE, and eventually releasing complete processor RTL under the GPL was a sustained, decades-long bet that an architecture spreads further when no one owns it outright. That bet did not save SPARC commercially — but it is recognizably the model that RISC-V now pursues far more successfully, and SPARC’s openness is why LEON exists, why OpenSPARC could be studied, and why the architecture outlived its principal vendor’s interest in it.

The third is simply that SPARC assembly is worth reading. It is a coherent design with a strong point of view, and its idioms — save/restore, the annulled delay slot, restore doing the return value in the delay slot of ret, %g0 as universal zero and universal sink — are memorable in a way that more uniform instruction sets are not. Learning it teaches you what an architecture looks like when it commits hard to one big idea.