When discussing a processor’s native language, we sometimes talk about the individual operation codes (opcodes) of each instruction. This discussion often involves learning the specific bit-by-bit organization of the instructions, or instruction formats.

The SPARC processor uses three basic instruction formats for the complete instruction set. As a software analyst examining system crash dumps, it is rare indeed that you will ever need to look at the raw instructions of a program in hexadecimal, because kadb and adb will be converting the values into assembly language for you. This process is referred to as “disassembling.” Should you want to explore this extremely detailed aspect of the instruction set, please refer to The SPARC Architecture Manual, Version 8.

The SPARC assembly language instructions, with which we will be working, and the SPARC opcodes are usually the same. We will point out the few cases where they differ.

When looking at SPARC assembly language via adb, we will see adb’s disassembled interpretation of the opcodes it finds. In very simple terms, the general syntax of assembly instructions we will see are as follows:

label:  instruction source destination 
        instruction label 

As we discuss each category of instruction, we will show the syntax of the instructions and some examples of assembly language code.

Throughout the rest of this chapter, while discussing the individual instructions in the SPARC instruction set and their syntax, we will use the following conventions. These are the same conventions you will find in The SPARC Architecture Manual, Version 8.

The load instruction is used to read a value stored in memory, placing the data into a register when it can then be manipulated. Here are six commonly used load instructions:

Now let’s look at a couple of examples. The instruction below reads the word of data stored at the memory address indicated by input register %i0 and loads it into output register %o1.

ld [%i0], %o1 

The next example reads an unsigned byte of data from memory, loading it into output register %o3. The memory address where the byte is read is the contents of input register %i4 plus hexadecimal 8. In a case like this, the value in %i4may often be the pointer to a structure. The offset of 8 points to the most significant byte of the third word in the structure, the 9th byte.

ldub [%i4 + 0x8], %o3 

The example below reads a double word (two words) from memory and loads the data into two registers starting with register %l4. So, if %i3contains address 0xfea603b0, this load instruction will read memory location 0xfea603b0 and 0xfea603b4, loading the data into registers %l4 and %l5, respectively.

ldd [%i3], %l4 

Each of the six load instructions shown above also has a variation that says to load the information from an alternate address space, such as the control registers for the Memory Management Unit. Each SPARC implementation may offer different alternate addressable registers that can be accessed via the load alternate address space instructions. During system crash dump analysis, odds are very good you will not run into these instructions, since they are not generated by the compiler, but we’ll show them just in case you do encounter them. Here they are.

The next six load instructions are specifically for the optional floating-point unit and the optional coprocessor. While in assembly language they appear to be instructions we’ve seen earlier, the actual opcodes differ.

If you feel comfortable with the various load instructions, the store instructions will be a piece of cake. After data in a register has been manipulated, we use the store instruction to write the data to a specified memory location.

There are four basic store operations and four alternate address space variations of them. They are as follows:

Let’s take a look at a couple of examples of store instructions. The one below stores the contents of input register %i3 into the memory location whose address is in local register %l6.

st %i3, [%l6] 

The next example stores the least significant byte in register %i0 into the 2nd byte of the word whose address is contained in register %l5.

stb %i0, [%l5 + 1] 

Of course, we also have additional store instructions that are used in conjunction with the optional floating-point processor and optional coprocessor. As with the load instructions, these instructions differ a bit between assembly language and the actual SPARC opcode.

Two instructions in the SPARC instruction set and two alternate address space variations of them can perform a read from memory and a write to memory atomically.

What do we mean by atomically? The instruction cannot be interrupted during its execution; the read and the write happen in the same breath. In a multiprocessor system, two or more processors executing the instructions addressing the same byte simultaneously are guaranteed to execute them in an undefined, but serial order.

Here are the instructions:

The ldstub instructions read an unsigned byte from memory into a register, then write all ones (hexadecimal 0xff) to that byte of memory. The swap instructions interchange the contents of a memory location with the contents of a register.

In general terms, both of these instructions, since they involve a lot of work, usually take longer to execute than others. However, when integrity of the data being manipulated is critical and timing is everything, these atomic instructions are invaluable. For example, it is the ldstub instruction that provides SPARC systems the ability to have safe, predictable locking mechanisms.

The memory access instructions generate the most traps. With the exception of the floating-point and coprocessor trap conditions, the traps shown below will cause a user program to terminate, dumping core. When these conditions are detected during execution of kernel code, it is considered catastrophic, and the system will immediately panic with a “bad trap.”.

When analyzing a system crash dump caused by a “bad trap,” you’ll usually find that a load or store instruction caused the crash.

Okay, let’s start off with the most commonly used arithmetic instructions:

We’ve already seen one example of these instructions. What do you think this next example instruction does?

sub %g4, %l3, %g4 

In programming terms, this might be expressed as:

%g4 = %g4 - %l3 

The contents of local register %l3 is subtracted from the contents of global register %g4and the result is stored back into %g4. Here’s another instruction.

addxcc %l0, 20, %l1 

This instruction adds the contents of %l0 and 20. It also adds in the PSRicc carry bit, which is either 0 or 1. The result is stored in %l1. Meanwhile, any integer condition codes occurring during the addition are recorded in the PSR icc fields. For example, if the result of the addition was negative, the icc negative bit would be set.

The next set of integer arithmetic instructions are not used often and are unlikely to appear during the course of system crash dump analysis.

Tagged arithmetic operations assume tagged-format data where the least significant two bits of the operands have special meaning. Languages such as LISP and Smalltalk use tagged arithmetic for dynamically typed data.

The tagged arithmetic instructions taddcctv and tsubcctv can cause tag overflow traps that would be handled by the operating system. These traps would not cause the system to panic and crash.

The logical instructions perform bitwise operations. The general syntax used is the same as the integer arithmetic instructions:

instruction sreg, reg_or_imm, dreg 

Here are the instructions.

Let’s try a few examples. Given that %g4contains 0x055, what would register %l2contain after each of the following instructions?

and %l0, 73, %l2     Answer: 51 
or %l0, 73, %l2      Answer: 77 
xor %l0, 73, %l2     Answer: 26 
xnor %l0, 73, %l2    Answer: ffff ffd6 

If you aren’t clear about how these answers were reached, you might want to talk to a programmer or refer to a good programming book.

None of the logical instructions generate traps.

The shift instructions use the same general syntax we’ve seen in the integer arithmetic and logical instructions.

instruction sreg, reg_or_imm, dreg 

The shift instructions shift the value in sreg left or right by a certain number of bit positions, as represented by reg_or_imm , and place the result in dreg . As the shift occurs, bits that drop off the end of the working register are lost. The PSRicc fields are not modified by the shift instructions.

There are no true “rotate” instructions in the SPARC instruction set. However, if a rotate is needed, the clever assembly language programmer can use the addcc instruction and the PSR icc overflow bit to his advantage.

Here are the three shift instructions:

The logical shifts replace the vacated bits with zeroes. The arithmetic shift replaces the vacated bits with the most significant bit of the value in sreg .

Here is an example of a shift instruction.

sll %l7, 2, %l7 

If the contents of %l7 started as 0x04, the result after shifting left two positions would be 0x10.

The shift instructions do not generate traps.

There are only a few miscellaneous instructions in the arithmetic / logical /shift set of SPARC instructions. Unlike the others, these instructions have differing syntaxes.

The sethi instruction is usually used in conjunction with a second command, such as a load. Let’s look at an example.

sethi %hi(0xf0155000), %o3 
ld [%o3 + 0x2a0], %l2 

The sethi instruction sets the high-order 22 bits of output register %03 to the high-order 22 bits of the value 0xf0155000. The load instruction then reads the value stored in memory location [%o3 + 0x2a0] (which calculates to 0xf01552a0) into local register %l2.

Why was this method used to read the value at memory location f01552a0? If you remember, due to the 32-bit width restriction of SPARC instructions, it is not possible to say “put 0xf01552a0 into %03.” If we add up the number of opcode bits used to identify the put instruction, the 32 bits of the value 0xf01552a0 and the bits needed to point to %03, we would have an instruction that is well over 32 bits in width.

The sethi instruction only contains the high-order 22 bits of the value 0xf01552a0 (thus, f0155000). The load instruction can include an offset of 13 bits in the [address] field, more than is needed to construct a valid memory address.

The nop instruction is actually a variation of the sethi instruction, as shown below.

sethi 0, %g0 

Register %g0 is rather like the /dev/null of registers. Reading %g0always results in zero. Writing to %g0 has no effect.

The nop instruction is actually executed, but it makes no modifications to the registers or memory. nopsare used when timing delays are required. There are actually many different instructions which could serve equally well as a nop. The compiler uses sethi. adb should recognize other varieties and display them as nop.

The mulscc instruction is a very busy little instruction that conditionally shifts a value, conditionally performs addition and updates the icc fields. You will see the mulsccinstruction used on systems that do not have the integer multiply and divide instructions implemented in the hardware.

save and restore instructions are used to manipulate the register windows.

In the set of miscellaneous arithmetic / logical / shift instructions, only the save and restore instructions can generate traps. The saveinstruction can cause a “window overflow” trap and the restore can cause a “window underflow” trap. Neither of these traps will cause the system to crash. Instead, the kernel kicks in and does some special window handling. We discuss windows in more detail in Chapter 17, “Stacks.”

The next table shows the conditional test and branch instructions for the integer unit. The third column shows which conditions the PSR icc bits must satisfy in order for the branch to be taken. As a reminder, the icc bits are:

Here are the branch on integer condition codes instructions:

Here is a snippet of assembly code that demonstrates how a branch instruction might be used.

main+0x34:      ld      [%l4 - 0x8], %l0 
main+0x38:      subcc   %l0, 0x6, %g0 
main+0x3c:      bne     main + 0x5c 
main+0x40:      nop 
main+0x44:      ld      [%fp - 0x8], %l0 

A value is read in from memory and placed into local register %l0.

Using the “subtract & modify icc” instruction, we subtract 6 from the value in %l0. No result is stored because the dreg or destination register is the /dev/null of registers, %g0; however, the icc bits are modified as appropriate.

Using the “branch on not equal” instruction, we test the setting of the Z bit. If it is set to 1, the values were equal; the value in memory was a 6. If the Z bit is clear, the values were not equal and we jump to location main+0x5c.

While doing the branch, the delay instruction, nop, gets executed.

If the branch is not taken, we still execute the nop instruction and then continue to the following load instruction at location main+0x44.

The branch on integer condition codes instructions do not generate traps.

The fcc field of the floating-point status register, %fsr, is updated by the floating-point compare instructions. The branch on floating-point condition codes instructions test the fcc field and branches accordingly. As a reminder, here are the fcc codes.

If a floating-point unit exists, the following branch instructions can be executed:

These commands can generate fp disabled and fp exception traps, neither of which should cause panics. When one of these traps does occur, the operating system, not the hardware, is responsible for performing the floating-point operation.

When this book was being written, there were no SPARC processor implementations that had yet incorporated a coprocessor. Even so, The SPARC Architecture Manual, Version 8 does define recommended instructions specific to the coprocessor.

The branch on coprocessor condition codes instructions assume there are two bits in the coprocessor status register that are used to represent conditions. The possible values for these two bits are: 0, 1, 2, and 3.

Here are the branch on coprocessor condition codes instructions.

Like the floating-point unit branch instructions, these instructions can cause coprocessor disabled and coprocessor exception traps. Both of these traps should not cause system panics and should instead cause the operating system to intervene and perform the required task.

The delayed transfer control instructions that we’ve seen all have an optional annul flag or bit which can be specified in the instruction by appending ,a to the instruction opcode. When set, the annul bit says to execute the delay instruction only if we take the branch. If we don’t take the branch, a set annul bit annuls or nullifies the execution of the delay instruction; the delay instruction is not executed.

Here is the same snippet of assembly code we used earlier to demonstrate how a branch instruction might be used. This time, the bneinstruction has been changed to bne,a.

main+0x34:      ld      [%l4 - 0x8], %l0 
main+0x38:      subcc   %l0, 0x6, %g0 
main+0x3c:      bne, a  main + 0x5c 
main+0x40:      nop 
main+0x44:      ld      [%fp - 0x8], %l0 

This time, if the value in %l0 is not equal to 6, we will jump to main+0x5c while executing the nop instruction. Conversely, if the value in %l0is equal to 6, we will skip the delay instruction all together and move on to the load instruction. Usually the delay instruction consists of something that does real work, instead of a nop. Unoptimized compiler output will often contain nop instructions.

For the “branch always” and “branch never” instructions, the delay instruction is executed if the annul bit is not set, and it is not executed when the annul bit is set.

Two instructions perform unconditional branches. They are:

The call instruction transfers control to an address relative to the current PC, whereas the jump and link, jmpl, instruction performs a register-indirect control transfer.

The call instruction places the current value of the Program Counter into register %o7, whereas the jmpl instruction allows the programmer to specify in which register to store the PC.

The call instruction does not generate any traps.

The jmpl instruction generates a “memory address not aligned” trap when address is not word aligned.

We talk about traps in detail in another chapter. For now, let’s just say that normally a trap is any condition in the hardware that shouldn’t have occurred. Generalizing, we could say when an instruction is executing, if something goes wrong, the instruction gets stuck or trapped and can’t finish its job. When this happens, the hardware suddenly switches to “Plan B,” records the current Program Counter and jumps to a special trap handler. The operating system gets involved and may decide to panic, kill the offending program, or simply provide assistance to the hardware via software routines.

The SPARC processor offers the programmer a way to force a trap condition. Using the PSR icc field, a routine can test the condition codes and based on the results, force a trap. When the trap is “taken,” the hardware still switches to “Plan B,” records the PC, and jumps into the trap handler, specifically to the section set aside for software trap number specified as sw_trap_num . This is the way a user program actually issues a system call— by trapping into the kernel with a specific code.

Here are the trap on integer condition codes instructions. You’ll see that they are quite similar to the branch on icc instructions.

The trap on integer condition codes instructions never execute the delay instruction.

These instructions all generate a trap instruction trap.

After a trap condition is handled by the operating system and everyone is happy again, instruction execution returns to the previously scheduled program that had caused the condition. The instruction, rettor return from a trap, does this control transfer.

Under various conditions, rett can cause any of the following traps.

rett is a privileged instruction.

The other three SPARC instructions in the state register category are:

The unimp instruction is an unimplemented instruction that, when executed, will generate an illegal instruction trap.

The stbar instruction forces all pending stores and atomic load-stores to complete prior to moving on to subsequent stores and atomic load-stores. The stbarinstruction does not generate any traps.

The flush instruction forces all pending memory access instructions involving the specified address to complete before subsequent accesses are attempted.

The stbar and flush instructions are made available for memory management implementations that use memory caches, thus not guaranteeing instant modification of memory.

Here are the arithmetic instructions.

When working with floating-point values, it is often necessary to convert the values to integer values, or from integer back to floating-point. There are also times when a conversions from one floating-point precision to another are needed. The following instructions perform all of the floating-point value conversions:

Earlier, we saw that the floating-point unit has a set of condition code bits and that there are a set of branch on floating-point conditions codes instructions. What we have not yet seen is how the fcc bits get modified.

As a reminder, the comparison instructions set the fcc bits, as shown below.

Here are the floating-point value comparison instructions.

There are three miscellaneous floating-point instructions, as follows:

The floating-point instructions can generate fp exception and fp disabled traps, all of which must result in the operating system processing the requested instruction via software, such as floating-point library routines.