Alpha/Linux Wiki

Alpha is a 64-bit load/store RISC architecture. It has 32 integer and 32 floating-point registers, all 64 bits wide, and every instruction is 32 bits long. Memory is accessed only by loads and stores, which in the original architecture work on 32-bit longwords and 64-bit quadwords only. Later processors added extensions for byte and word access, multimedia, floating-point moves and square roots, and bit counting. This page summarizes the registers and their conventional use, the extensions and the processors that introduced them, and the instructions and assembler features most often met in Linux programming. The Alpha Architecture Reference Manual, Fourth Edition is the definitive reference; see References.

There are 32 integer registers. The $31 register holds the constant value 0. Writes to it are ignored.

By convention 12 registers are for temporary values, 7 ($9 to $15) are saved across function calls, and 6 are for passing arguments to functions. The return address ($26) and the stack pointer ($30) are also preserved.

There are 32 floating-point registers. The $f31 register holds the constant value 0.0. Writes to it are ignored.

By convention, 15 registers are for temporary values, 8 are saved across function calls, and 6 are for passing arguments to functions.

The program below calls printf from assembly. It is built and run with gcc hello.S -o hello and ./hello. The .frame, .mask, and .prologue directives describe the stack frame for debuggers and the unwinder, and ldgp sets up the global pointer, which must be reloaded after every call to another function. ¹⁾

	.data
PRINT:	.asciz	"Hello, World!\n"
 
	.text
	.align	4
	.set	noreorder
	.arch	ev56
	.globl	main
	.ent	main
main:
	.frame	$sp,16,$26,0		# 16-byte frame, return address in $26
	.mask	0x4000000,-16		# $26 is saved in the frame
	ldgp	$gp,0($27)		# load global pointer
	lda	$sp,-16($sp)		# allocate a stack frame
	stq	$26,0($sp)		# save return address to stack
	.prologue 1			# end of prologue; 1 means it uses $gp
 
	lda	$16,PRINT		# load format string
					# $16 is first argument to functions
	jsr	$26,printf		# call printf
	ldgp	$gp,0($26)		# reload global pointer
					# (necessary after function calls)
 
	mov	$31,$0			# return val = 0
	ldq	$26,0($sp)		# load return address from stack
	lda	$sp,16($sp)		# release the stack frame
	ret	$31,($26),1		# return, (1 signifies return from a procedure)
	.end	main
 
	.section .note.GNU-stack,"",@progbits

The extensions accumulate along the line EV56 (21164A, BWX), PCA56 (21164PC, adds MVI), EV6 (21264, adds FIX), and EV67 (21264A, adds CIX); each processor in that sequence implements the extensions of those before it, so the 21164A has BWX but not MVI. The amask instruction reports at run time which extensions a processor implements, using the bit given in the table; IMPLVER reports only the processor generation, for tuning decisions. ²⁾ GCC enables an extension with its -m option, or with a -mcpu value for a processor that has it. ^{3) 4)}

Linux requires BWX since Linux 6.10; see Kernel: Processor support.

The byte/word extension adds loads and stores of 8-bit bytes and 16-bit words, without which they are done by loading the containing quadword and extracting or inserting the byte; see Byte and Word Access.

The motion video instructions operate on bytes and words packed into a 64-bit register.

The floating-point extension adds moves between the integer and floating-point registers, which otherwise go through memory, and square root instructions.

The count extension adds bit counting instructions.

Alpha has no atomic read-modify-write instructions. Atomic operations are built from a load-locked and store-conditional pair: ldl_l or ldq_l loads a longword or quadword and sets a lock flag, and stl_c or stq_c stores only if no other processor has written to the locked location in the meantime, writing 1 to its source register on success and 0 on failure. The sequence is retried in a loop until the store succeeds. There are no byte or word forms, even with BWX. The architecture limits what may appear between the two instructions, and the ordering of memory accesses around them is set with mb and wmb barriers. ⁵⁾ See Memory Model for the rules and their consequences for Linux code.

Alpha has no integer divide instruction. ⁶⁾ GCC compiles integer / and % with a variable divisor into calls to helper routines: __divq, __divqu, __remq and __remqu for 64-bit operands, and __divl, __divlu, __reml and __remlu for 32-bit ones. ⁷⁾ In user space the C library provides them; they are exported from libc.so.6.1. ⁸⁾ The kernel has its own copies.

The helpers are not ordinary functions. The dividend is passed in $24 (t10) and the divisor in $25 (t11), the result is returned in $27 (t12), the return address is in $23 (t9), and only $27 and $28 (at) may be changed; every other register is preserved. ⁹⁾ A JIT compiler or hand-written assembly that needs division has to call them with this convention or divide by other means. glibc's versions use the floating-point divider where the operands allow an exact result, and fall back to a shift-and-subtract loop otherwise. ¹⁰⁾

Division by zero is detected in software: the helper executes the gentrap PALcode call with the code GEN_INTDIV, and the kernel delivers SIGFPE with si_code FPE_INTDIV. ^{11) 12)}

call_pal calls a function of the PALcode, the firmware layer beneath the operating system. Linux uses the PALcode interface of Tru64 UNIX (OSF/1). The calls a user program meets are: ¹³⁾

GCC's __builtin_thread_pointer compiles to call_pal 0x9e (rduniq), and glibc uses it to find the thread's TLS block. ^{14) 15)} The system call convention, with the number in $0, arguments in $16 to $21, and an error flag returned in $19, is described under Linux ABI Differences: System calls.

GNU as accepts explicit relocation annotations on individual instructions, written after the operands with !. GCC emits them when it schedules the address calculations itself, and they appear in its assembly output and in hand-written assembly: ¹⁶⁾

• !literal marks an ldq that loads a symbol's address from the global offset table (GOT), and the !lituse_* operators mark the instructions that use the loaded address, so that the linker can optimize the sequence.
• !gpdisp marks the ldah and lda pair that computes the global pointer, as the ldgp macro does.
• !gprelhigh, !gprellow, and !gprel address data at a fixed offset from the global pointer.
• !tlsgd, !tlsldm, !gotdtprel, !dtprelhi, !gottprel, !tprelhi and related operators implement the thread-local storage models.

	ldah	$29,0($27)	!gpdisp!1
	lda	$29,0($29)	!gpdisp!1
	ldq	$1,b($29)	!literal!2
	ldl	$2,0($1)	!lituse_base!2

!literal and !gprel reach the GOT or data through a 16-bit displacement from the global pointer, which limits them to a 64 KiB window around the global pointer; see Toolchains for the "relocation truncated to fit" errors this causes in large programs.

Raymond Chen's blog series about the Alpha is a detailed, Windows-focused discussion of the instruction set.

• The Alpha AXP, part 1: Initial plunge
• The Alpha AXP, part 2: Integer calculations
• The Alpha AXP, part 3: Integer constants
• The Alpha AXP, part 4: Bit 15. Ugh. Bit 15.
• The Alpha AXP, part 5: Conditional operations and control flow
• The Alpha AXP, part 6: Memory access, basics
• The Alpha AXP, part 7: Memory access, loading unaligned data
• The Alpha AXP, part 8: Memory access, storing bytes and words and unaligned data
• The Alpha AXP, part 9: The memory model and atomic memory operations
• The Alpha AXP, part 10: Atomic updates to byte and word memory units
• The Alpha AXP, part 11: Processor faults
• The Alpha AXP, part 12: How you detect carry on a processor with no carry?
• The Alpha AXP, part 13: On treating a 64-bit processor as if it were a 32-bit processor
• The Alpha AXP, part 14: On the strange behavior of writes to the zero register
• The Alpha AXP, part 15: Variadic functions
• The Alpha AXP, part 16: What are the dire consequences of having 32-bit values in non-canonical form?
• The Alpha AXP, part 17: Reconstructing a call stack