Escolar Documentos
Profissional Documentos
Cultura Documentos
Tensilica, Inc.
3255-6 Scott Blvd.
Santa Clara, CA 95054
(408) 986-8000
fax (408) 986-8919
www.tensilica.com
© 2010 Tensilica, Inc.
Printed in the United States of America
All Rights Reserved
This publication is provided “AS IS.” Tensilica, Inc. (hereafter “Tensilica”) does not make any warranty of any kind, either ex-
pressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
Information in this document is provided solely to enable system and software developers to use Tensilica processors. Unless
specifically set forth herein, there are no express or implied patent, copyright or any other intellectual property rights or licens-
es granted hereunder to design or fabricate Tensilica integrated circuits or integrated circuits based on the information in this
document. Tensilica does not warrant that the contents of this publication, whether individually or as one or more groups,
meets your requirements or that the publication is error-free. This publication could include technical inaccuracies or typo-
graphical errors. Changes may be made to the information herein, and these changes may be incorporated in new editions of
this publication.
Tensilica and Xtensa are registered trademarks of Tensilica, Inc. The following terms are trademarks of Tensilica, Inc.: FLIX,
OSKit, Sea of Processors, TurboXim, Vectra, Xenergy, Xplorer, and XPRES. All other trademarks and registered trademarks
are the property of their respective companies.
Tensilica, Inc.
3255-6 Scott Blvd.
Santa Clara, CA 95054
(408) 986-8000
fax (408) 986-8919
www.tensilica.com
Contents
1. Introduction ................................................................................................................... 1
1.1 What Problem is Tensilica Solving? ............................................................................. 1
1.1.1 Adding Architectural Enhancements .................................................................. 1
1.1.2 Creating Custom Processor Configurations ........................................................ 4
1.1.3 Mapping the Architecture into Hardware ............................................................. 4
1.1.4 Development and Verification Tools ................................................................... 5
1.2 The Xtensa Instruction Set Architecture ....................................................................... 5
1.2.1 Configurability ................................................................................................. 7
1.2.2 Extensibility ..................................................................................................... 8
1.2.2.1 State Extensions ..................................................................................... 9
1.2.2.2 Register File Extensions .......................................................................... 9
1.2.2.3 Instruction Extensions .............................................................................. 9
1.2.2.4 Coprocessor Extensions .......................................................................... 9
1.2.3 Time-to-Market ................................................................................................ 9
1.2.4 Code Density ................................................................................................ 10
1.2.5 Low Implementation Cost ............................................................................... 10
1.2.6 Low-Power .................................................................................................... 11
1.2.7 Performance ................................................................................................. 11
1.2.8 Pipelines ....................................................................................................... 12
1.3 The Xtensa Processor Generator.............................................................................. 13
1.3.1 Processor Configuration ................................................................................. 13
1.3.2 System-Specific Instructions—The TIE Language ............................................. 13
2. Notation ....................................................................................................................... 17
2.1 Bit and Byte Order .................................................................................................. 17
2.2 Expressions ........................................................................................................... 19
2.3 Unsigned Semantics ............................................................................................... 20
2.4 Case ..................................................................................................................... 20
2.5 Statements ............................................................................................................. 21
2.6 Instruction Fields..................................................................................................... 21
3. Core Architecture ......................................................................................................... 23
3.1 Overview of the Core Architecture ............................................................................ 23
3.2 Processor-Configuration Parameters......................................................................... 23
3.3 Registers ............................................................................................................... 24
3.3.1 General (AR) Registers ................................................................................... 24
3.3.2 Shifts and the Shift Amount Register (SAR) ....................................................... 25
3.3.3 Reading and Writing the Special Registers ....................................................... 26
3.4 Data Formats and Alignment .................................................................................... 26
3.5 Memory ................................................................................................................. 27
3.5.1 Memory Addressing ....................................................................................... 27
3.5.2 Addressing Modes ......................................................................................... 28
3.5.3 Program Counter ........................................................................................... 29
3.5.4 Instruction Fetch ............................................................................................ 29
3.5.4.1 Little-Endian Fetch Semantics ................................................................ 29
List of Figures
List of Tables
Table 7–241. S3 (from Table 7–240) Format RRRN (no fields vary) ..................................... 586
Table 8–242. Windowed Register Usage........................................................................... 587
Table 8–243. CALL0 Register Usage ................................................................................ 589
Table 8–244. Data Types and Alignment ........................................................................... 589
Table 8–245. Breakpoint Instruction Operand Conventions ................................................. 596
Table 8–246. Instruction Idioms........................................................................................ 599
Table 8–247. Xtensa Pipeline .......................................................................................... 608
Table 9-248. Instructions Added ...................................................................................... 611
Table 9-249. Cache Attribute Register .............................................................................. 617
Table 9-250. Cache Attribute Special Register .................................................................. 617
Table 9–251. T1050 Additional SYNC Requirements .......................................................... 621
Preface
This manual is written for Tensilica customers who are experienced in working with mi-
croprocessors or in writing assembly code or compilers. It is NOT a specification for one
particular implementation of the Architecture, but rather a reference for the ongoing
Instruction Set Architecture. For a detailed specification for specific products, refer to a
specific Tensilica processor data book.
Notation
italic_name indicates a program or file name, document title, or term being defined.
$ represents your shell prompt, in user-session examples.
literal_input indicates literal command-line input.
variable indicates a user parameter.
literal_keyword (in text paragraphs) indicates a literal command keyword.
literal_output indicates literal program output.
... output ... indicates unspecified program output.
[optional-variable] indicates an optional parameter.
[variable] indicates a parameter within literal square-braces.
{variable} indicates a parameter within literal curly-braces.
(variable) indicates a parameter within literal parentheses.
| means OR.
(var1 | var2) indicates a required choice between one of multiple parameters.
[var1 | var2] indicates an optional choice between one of multiple parameters.
var1 [, varn]* indicates a list of 1 or more parameters (0 or more repetitions).
4'b0010 is a 4-bit value specified in binary.
12'o7016 is a 12-bit value specified in octal.
10'd4839 is a 10-bit value specified in decimal.
32'hff2a or 32'HFF2A is a 32-bit value specified in hexadecimal.
Terms
0x at the beginning of a value indicates a hexadecimal value.
b means bit.
B means byte.
flush is deprecated due to potential ambiguity (it may mean write-back or discard).
Mb means megabit.
MB means megabyte.
PC means program counter.
word means 4 bytes.
The following changes have been made to this document for the Tensilica RC-2010.1
release:
Deleted several extraneous blank pages in between each chapter in previous re-
lease.
Corrected erroneous cross-references to Table 4–55 through Table 4–58 in
Section 4.4.1.1 on page 83
Clarified information about lookup rings in Section 4.6.2.2 and Section 4.6.2.3.
The following changes have been made to this document for the Tensilica RC-2009.0
release:
A new register, ATOMCL, has been added to Section 4.3.13 “Conditional Store Op-
tion” on page 91. The ATOMCTL register controls the interaction of the S32C1I in-
struction with the memory system.
The description of attributes for the Section 4.6.3 “Region Protection Option” on
page 187 and the Section 4.6.5.10 “MMU Option Memory Attributes” on page 213
have been improved. There are no actual changes to the attributes.
The Section 4.6.5 “MMU Option” on page 196 has gained a new option. Way5 and
Way6 can now be either variable or fixed. The variable version provides more flexi-
bility in the address map and has a setting where the MMU puts out a physical ad-
dress equal to the virtual address and is, in that sense, turned off.
Many of the SYNC instruction requirements listed in Section 5.3 “Special Registers”
on page 259 have not actually been needed after T1050. Those requirements have
now been removed from Section 5.3 but retained in Appendix A.
The RER and WER instructions have been added to Chapter 6.
1. Introduction
This chapter provides an overview of Tensilica, the Xtensa Instruction Set Architecture
(ISA), and the Xtensa Processor Generator.
It is also not appropriate to simply design traditional processors with more features to
cover all applications, because any given application only requires a particular set of
features — a processor with features not required by the application is overly costly and
consumes unnecessary power. It is also not possible to know all of the potential applica-
tion targets when a processor is initially designed.
If processor configuration could be automated and made reliable, then system designers
would have the option and ability to create truly efficient application solutions.
This is just what Tensilica is about: Tensilica provides a set of techniques and tools for
designing an application solution that contains one or more processors, each one con-
figured and enhanced at design-time to fine-tune its suitability for a specific application.
Fine-tuning an architecture can consist of any combination of:
Extensibility: Adding architectural enhancements.
Configurability: Creating custom processor configurations.
Retargetability: Mapping the architecture into hardware to meet different speed, ar-
ea, and power targets in different processes.
stead a programmable processor is introduced into the system for protocol processing.
This processor’s programmability also allows bug fixes and upgrades to later protocols
to be done by loading the instruction memories with new software. However, the proces-
sor was probably not designed for this particular application (the application may not
have even existed when the processor was designed), and the application may perform
operations that require many instructions — operations that could be accomplished with
a trivial amount of additional processor logic.
Both the value and the length must be computed, so that length bits can be shifted off to
find the start of the next token. (A similar encoding is used in the MPEG compression
standard.) There are many ways to code this for a conventional RISC instruction set, but
all of them require many instructions, because there are many tests to be done, and
each test requires a single cycle (as opposed to a single gate delay for logic). For exam-
ple, in the MIPS instruction set, the above decode procedure might look like this:
This is so expensive that a 256-entry lookup table is typically used instead. However, a
256-entry lookup table takes significant space and can take many cycles to access. For
longer Huffman encodings, the table size would become prohibitive, leading to more
complex and slower code.
The logic to decode this requires roughly 30 gates (just the combinatorial logic function,
not counting instruction decode and so forth) — less than 0.1% of a processor gate-
count — and can be computed by a special-purpose processor instruction in a single cy-
cle. This is a factor of 4 to 20 speed-up over using general-purpose instructions only. A
processor extended to have this logic in the form of an instruction would simply do:
Tensilica’s solution is to provide a mechanism with which to easily and efficiently extend
processor architecture with application-specific instructions.
While the ability to extend processor architecture, which we call extensibility, lets system
designers incorporate new functionality into a processor, configurability lets processor
designers specify whether (or how much) pre-designed functionality is required for a
particular product.
Extensibility and configurability provide great flexibility. However, the resulting design
must still be mapped into physical hardware. Synthesis, placement, and routing tools
allow high-level representations of a design to be automatically mapped into more
detailed designs. While these mapping operations do not change the functionality of the
design, they are important building blocks that facilitate extensibility and configurability.
Many processors are manually designed all the way to the layout. For such a processor
design, extensibility and configurability would require changes to the layout. By contrast,
the Tensilica system builds on existing synthesis, placement, and routing tools so that
configuration need only change the input to synthesis, and conventional mapping tech-
niques are used to create physical hardware.
Some synthesis tools choose different mapping based on the designer’s goal specifica-
tions, allowing the mapping to optimize for speed, power, area, or target components.
This is as close to providing configurability that existing mapping tools come: the design-
er can specify different synthesis parameters for a fixed input. By contrast, the Tensilica
approach lets the designer alter the input to synthesis, and change its functionality.
In addition, when the processor changes, the software tool chain — compilers, assem-
blers, linkers, debuggers, simulators, and profilers — must change as well. In the past,
the cost of software changes associated with processor reconfigurations has been a
major impediment. Tensilica automates these changes also.
Finally, it should be possible to get feedback on the performance, cost, power, and other
effects of processor reconfiguration without taking the design through the entire map-
ping process. This feedback can be used to direct further reconfiguration of the proces-
sor until the system design goals are achieved. Tensilica’s technology dramatically
improves the feedback loop.
This manual describes the Xtensa ISA — both the core architecture and the architectur-
al options. Figure 1–1 illustrates the general organization of the processor hardware in
which the Xtensa ISA is implemented. This manual does not describe the memory map,
protection model, or peripherals that can be implemented in particular configurations of
the Xtensa ISA.
Exception Support
Table 1–2 compares the architectural features provided by the Xtensa ISA to those of
typical RISC architectures. Each of the Xtensa features are described in this manual.
1.2.1 Configurability
The Xtensa ISA goes further than incorporating post-RISC features: it is modular,
consisting of a core architecture and architectural options. Table 1–3 lists the initial set
of modular components.
1.2.2 Extensibility
In addition to the Xtensa components shown in Table 1–3, designers can extend the
Xtensa architecture by adding States, Register Files, and instructions that operate both
on the AR Register File and on the additional states the designer has added. These in-
structions can be single cycle or multiple cycles, and share or re-use logic.
The designer can add State Registers. These State Registers can be the source or
destination of various instructions and are saved and restored by the operating system.
The designer can add Register Files of widely varying size. These Register Files can be
the source or destination of various instructions and are saved and restored by the
operating system. The registers within them are allocated by the compiler, which can
spill and re-fill them if necessary.
The designer can define new instructions that contain simple functions consisting of
combinatorial logic that takes one or two source operands from registers and produces a
result to be written to a register:
Instructions can also be much more complex with register file values and State appear-
ing as both inputs and outputs. These Instructions are described using the Tensilica
Instruction Extension (TIE) language (see Section 1.3.2).
Another mechanism to extend the Xtensa ISA is to use the Coprocessor Option. A co-
processor is defined as a combination of registers, other state, and logic that operates
on that state, including loads, stores and setting of Booleans for branch true/false oper-
ations. A particular coprocessor can be enabled or disabled to control with one bit
whether or not instructions accessing that combination of registers and other state may
or may not execute.
1.2.3 Time-to-Market
The Xtensa core ISA is implemented as 24-bit instructions. This instruction width pro-
vides a direct 25% reduction in code size compared with 32-bit ISAs. The instructions
provide access to the entire processor hardware and support special functions, such as
single-instruction compare-and-branch, which reduce the number of instructions re-
quired to implement various applications. These special functions result in further code-
size reductions.
The Xtensa ISA also includes a Code Density Option that further reduces code size.
This option adds 16-bit instructions that are distinguished by opcode, and that can be
freely intermixed with 24-bit instructions to achieve higher code density than competing
ISAs without giving up the performance of a 32-bit ISA. The 16-bit instructions add no
new functionality but provide compact encoding of the most frequently used 24-bit in-
structions. In typical code, roughly half of all instructions can be encoded in 16 bits.
The core ISA omits the branch delay slots required by some RISC ISAs. This increases
code density by eliminating NOPs the compiler uses to fill the slot after a branch when it
cannot find a real instruction to put there (only 50% of the branch delay slots are filled on
some RISC architectures).
The Xtensa ISA provides a Windowed Registers Option. Xtensa windowed registers re-
duce code size by:
Eliminating register saves and restores at procedure entry and exit
Reducing argument shuffling
Allowing more local variables to live permanently in registers
The Xtensa architecture fully supports the common data types and operations found in a
broad range of applications. The base architecture omits special-purpose data types
and operations. Optional instructions, the TIE language (see Section 1.3.2), and option-
al coprocessors allow the designer to add exactly the functionality needed, thus reduc-
ing the cost and performance due to unused general-purpose functions.
The Xtensa ISA’s improvements in code size help reduce system cost (for example, by
reducing the amount of ROM, Flash, or RAM required). Making features like the number
of debug registers configurable allows the system designer, instead of the processor
designer, to decide the cost/benefit trade-off.
1.2.6 Low-Power
The Xtensa ISA has several energy-efficient attributes that enhance battery-operated
systems. The core ISA is built on 32-bit operations; some embedded processors of sim-
ilar performance have 64-bit base operations, which consumes additional power, often
unnecessarily. (TIE does allow 64-bit or greater computations to be added to the proces-
sor for those algorithms that require it, but these can be used selectively to achieve a
balance between performance and power consumption.)
The core ISA uses a register file with only two read ports and one write port, a configura-
tion that requires fewer transistors and less power than architectures with more ports.
The Xtensa Windowed Registers Option saves power by reducing the number of dy-
namic data-memory references and increasing the opportunities for variables to reside
in registers, where accesses require less power than memory accesses.
The WAITI (Wait for Interrupt) instruction, which is a part of the Interrupt Option, saves
power by setting the current interrupt level, powering down the processor’s logic, and
waiting for an interrupt.
1.2.7 Performance
The Xtensa ISA achieves its extensibility, code density, and low-power advantages with-
out sacrificing performance. For example, the Thumb and MIPS16 extensions of the
ARM and MIPS ISAs, respectively, provide improved code density by using only eight
registers and by reducing operand flexibility. By contrast, the Xtensa 24-bit instructions
can access 16 virtual registers with 3 register operands, and 16-bit instructions can
access all 16 registers with 1 to 3 register operands. The mapping of the 16 virtual
registers to the physical register file can eliminate register saves and restores at proce-
dure entry and exit, also increasing performance.
These features are described in Section 3.8 of this manual. Other features of the archi-
tecture minimize critical paths, allow better compiler scheduling, and require fewer exe-
cuted instructions to implement a given program.
1.2.8 Pipelines
The Xtensa ISA can be implemented using a variety of pipelines. A 5-stage load-store
oriented pipeline, such as is used in many RISC processors, is supported by Xtensa im-
plementations and illustrated in Figure 1–2. Many other variations are possible. A 7-
stage load-store oriented pipeline is supported by some Xtensa implementations. In-
structions can also have computation in later pipe stages so that the computation can
use memory data loaded by the same instruction.
General
Decode Registers Coprocessor R: Instruction Decode/
(AR Registers) Registers Register Fetch Cycle
Address E: Execute/Effective
ALU
Generation Address Cycle
Coprocessor
ALU
Xtensa Local
Memory Data Data Data
Interface RAM Cache ROM
M: Memory Access/
(XLMI)
Branch Complete Cycle
Exception
Resolution W: Write Back Cycle
and Write
Back
The instruction set was also designed with a 2-read, 1-write general register file (called
Address Registers) in mind. While this approach results in lower implementation cost, it
prevents the inclusion of auto-incrementing loads and indexed stores to or from the
Address Registers. For the sake of symmetry, the ISA therefore does not include auto-
incrementing stores and indexed loads. However, all of these addressing modes are
possible for designer defined loads and stores. Designers can implement register files
with more read and write ports. For example, the Xtensa Floating-Point Coprocessor
Option contains a floating point register file with three read ports.
The Generator user interface captures designer input in several ways, including:
Configuration of the processor micro-architecture
Configuration of Tensilica-provided instruction and coprocessor options
Specification of designer-defined instruction and coprocessor extensions, using the
Tensilica Instruction Extension (TIE) language
Together, these specifications make up the configuration database shown near the top
of Figure 1–3. This file is used to generate all the software tools and hardware descrip-
tions for the final application-specific processor.
The Generator interface drives the creation and optimization of all forms of the proces-
sor needed for integration into the system design flow. Based on the designer’s specifi-
cations, it creates synthesizable Verilog or VHDL code, synthesis scripts, an HDL test
bench, and physical placement files. Simultaneously, an optimized C and C++ compiler,
assembler, linker, symbolic debugger, Instruction Set Simulator, libraries and verification
tests are built for the designer’s software development.
The Generator interface lets the designer specify implementation targets for speed, area
and process technology, as well as the optimization priorities used in synthesis and lay-
out.
The Tensilica Instruction Extension (TIE) language lets the designer add instructions to
the processor implementation, including full software support for generated instructions.
The specification of instruction extensions can include the following aspects as well as
many others:
Instruction Operation — Defines the operation of an additional instruction
In addition to designer-defined register and register file operands, instructions can use
AR registers as source values. They may generate multiple results, including AR register
file results. These instructions should be designed to have circuit delays appropriate to
the number cycles specified in the schedule specifications to avoid limiting the proces-
sor clock frequency. The instruction semantics are expressed in a subset of Verilog,
including all commonly used operators (multiply, add, subtract, minus, not, or, compari-
sons, reduction operators, shifts, concatenation, and conditionals).
The use of TIE for the creation of new instructions and coprocessors is described in the
Tensilica Instruction Extension (TIE) Language User’s Guide. The TIE language is de-
scribed in the Tensilica Instruction Extension (TIE) Language Reference Manual.
Configure Processor
(including Custom TIE
Instructions)
Configuration-Specific
Database
Configuration-
Configuration Specific Configuration-Specific
-Independent Software HDL Description and
XtTools Development
Tools
CAD Scripts
Install Software:
Synthesize Logic
Set up Environment
Hardware User
Tasks Software Hardware
Automatically
Generated
Software User
Tasks
2. Notation
This manual uses the following notation for instruction descriptions. Additional notation
specific to opcode encodings is provided in "Opcode Encodings" on page 574.
In specifying little- or big-endian ordering during actual processor configuration, you are
specifying both the bit and the byte order; the two orderings have the same most-signifi-
cant and least-significant ends.
Figure 2–5 on page 18 illustrates big- and little-endian byte order, as implemented by
Xtensa load (page 33) and store (page 36) instructions. Xtensa processors transfer data
to and from the system using interfaces that are configurable in width (32, 64, or 128 bits
in current implementations). These interfaces arrange their n bits according to their sig-
nificance representing an n-bit unsigned integer value (that is, 0 to 2n-1). Load and store
instructions that reference quantities less than n bits access different bits of this integer
in little-endian and big-endian byte orderings (for example, by changing the selection al-
gorithm for loads). Xtensa processors do not rearrange bits of a word to implement endi-
anness (for example, swapping bytes for big-endian operation).
Little-Endian bit numbering for BBC/BBS instructions:
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
←most-significant least-significant→
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
←most-significant least-significant→
Figure 2–4. Big and Little Bit Numbering for BBC/BBS Instructions
word 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
word 1 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
word 2 … 32
2.2 Expressions
Table 2–4 defines notational forms used in expressions that describe the operation of in-
structions. In the table, v is an n-bit quantity, u is an m-bit quantity, and t is a 1-bit
quantity.
(0 || u) < (0 || v)
2.4 Case
Processor-state variables (for example, registers) are shown in UPPER CASE.
2.5 Statements
Table 2–5 defines notational forms used in statements used to describe the operation of
instructions.
3. Core Architecture
The Xtensa Core Architecture provides a baseline set of instructions available in every
Xtensa implementation. Having such a baseline eases the implementation of core soft-
ware such as operating system ports and a compiler. This chapter describes that Core
Architecture.
The Xtensa core ISA is implemented as a set of 24-bit instructions that perform 32-bit
operations. The instruction width was chosen primarily with code-size economy in mind.
The instructions themselves were selected for their utility in a wide range of embedded
applications. The core ISA has many powerful features, such as compound operation
instructions, that enhance its fit to embedded applications, but it avoids features that
would benefit some applications at the expense of cost or power on others (for example,
features that require extra register-file ports). Such features can be implemented in the
Xtensa architecture using options and coprocessors specifically targeted at a particular
application area.
The Xtensa ISA is organized as a core set of instructions with various optional packages
that extend the functionality for specific application areas. This allows the designer to
include only the required functionality in the processor core, maximizing the efficiency of
the solution. The core ISA provides the functionality required for general control applica-
tions, and excels at decision-making and bit and byte manipulation. The core also pro-
vides a target for third-party software, and for this reason deletions from the core are not
supported. Conversely, numeric computing applications such as digital signal process-
ing are best done with optional ISA packages appropriate for specific application areas,
such as the MAC16 Option for integer filters, or the Floating-Point Coprocessor Option
for high-end audio processing.
3.3 Registers
Table 3–8 lists the core-architecture registers. Each register is described in the sections
that follow. Additional registers are added with many of the options described in
Chapter 4. The complete set of registers that are predefined in the architecture, includ-
ing all registers used by the architectural options, is listed in Table 5–127 on page 205.
Each instruction contains up to three 4-bit general-register specifiers, each of which can
select one of 16 32-bit registers. These general registers are named address registers
(AR) to distinguish them from coprocessor registers, which in many systems might serve
as “data” registers. However, the AR registers are not restricted to holding addresses;
they can also hold data.
If the Windowed Register Option is configured, the address register file is extended and
a mapping from virtual to physical registers is used.
The contents of the address register file are undefined after reset.
The ISA provides conventional immediate shifts (logical left, logical right, and arithmetic
right), but it does not provide single-instruction shifts in which the shift amount is a regis-
ter operand. Taking the shift amount from a general register can create a critical timing
path. Also, simple shifts do not extend efficiently to larger widths. Funnel shifts (where
two data values are catenated on input to the shifter) solve this problem, but require too
many operands. The ISA solves both problems by providing a funnel shift in which the
shift amount is taken from the SAR register. Variable shifts are synthesized by the com-
piler using an instruction to compute SAR from the shift amount in a general register,
followed by a funnel shift.
Funnel shifts are also useful for working with the 40-bit accumulator values created by
the MAC16 Option.
To facilitate unsigned bit-field extraction, the EXTUI instructions take a 4-bit mask field
that specifies the number of bits to mask the result of the shift. The 4-bit field specifies
masks of one to 16 ones. The SRLI instruction provides shifting without a mask.
The legal range of values for SAR is zero to 32, not zero to 31, so SAR is defined as six
bits. The use of SRC, SRA, SLL, or SRL when SAR > 32 is undefined.
The funnel shifter can also be used efficiently for byte alignment of unaligned memory
data. To load four bytes from an arbitrary byte boundary (in a processor that does not
have the Unaligned Exception Option), use the following code:
l32i a4,a3,0
l32i a5,a3,4
ssa8l a3
src a4,a5,a4
An unaligned block copy can be done (in a processor that does not have the Unaligned
Exception Option) with the following code for little-endian and small changes for big-en-
dian:
l32i a6,a3,0
ssa8l a3
loopnez a4,endloop
loop:
l32i a7,a3,4
src a8,a7,a6
s32i a8,a2,0
l32i a6,a3,8
src a8,a6,a7
s32i a8,a2,4
addi a2,a2,8
addi a3,a3,8
endloop:
The overhead, compared to an aligned copy, is only one SRC per L32I.
The SAR register is part of the Non-Privileged Special Register set in the Xtensa ISA (the
other registers in this set are associated with the architectural options). The contents of
the special register in the Core Architecture can be read to an AR register with the read
special register (RSR.SAR) instruction or written from an AR register with the write spe-
cial register (WSR.SAR) instruction as shown in Table 3–9. The exchange special regis-
ter (XSR.SAR) instruction accomplishes the combined action of the read and write in-
structions.
Table 3–10 summarizes the width and alignment of each data type. The processor uses
byte addressing for all data types stored in memory (that is, all except the MAC16 accu-
mulator). Byte order can be specified as either big-endian or little-endian. In big-endian
byte order, byte 0 is the most-significant (left-most) byte. In little-endian byte order, byte
0 is the least-significant (right-most) byte. When specifying a byte order, both the byte
order and the bit order are specified: the two orderings always have the same most-
significant and least-significant ends.
3.5 Memory
The Xtensa ISA is based on 32-bit virtual and physical memory addresses, which
provides a 232 or 4 GB address space for instructions and data.
Figure 3–6 shows an example of the processor’s interpretation of addresses when con-
figured with caches. The widths of all fields are configurable, and in some cases the
width may be zero (in particular, there are always zero ignored bits today). The cache in-
dex and cache tag will overlap if the page size is smaller than the size of a single way of
the cache and if physical tags are used.
31 0
Physical Address
Without the Region Protection Option or the MMU Option, virtual and physical address-
es are identical; if physical addresses are configured to be smaller than virtual address-
es, virtual addresses are mapped to physical addresses only by truncation (high-order
bits are ignored). With the Region Protection Option or the MMU Option, virtual page
numbers are translated to physical page numbers.
Without the Region Protection Option or the MMU Option, the formal definition of virtual
to physical translation is as follows (note that the ring parameter is ignored):
The core ISA supports both little-endian (PC compatible) and big-endian (Internet com-
patible) address models as a configuration parameter. In this manual:
msbFirst = 1 is big-endian.
msbFirst = 0 is little-endian.
The core instruction set implements the register + immediate addressing mode. The
core ISA does not implement auto-incrementing stores or indexed loads. However, such
addressing modes are possible for coprocessors. For example, the Floating-Point
Coprocessor Option implements indexed as well as immediate addressing modes.
The 32-bit program counter (PC) holds a byte address and can address 4 GB of virtual
memory for instructions. However, when the Windowed Register Option is configured,
the register-window call instructions only store the low 30 bits of the return address.
Register-window return instructions leave the two most-significant bits of the PC un-
changed. Therefore, subroutines called using register window instructions must be
placed in the same 1 GB address region as the call.
This section describes the execution loop of the processor using the notation of
Chapter 2. The individual instruction actions are represented by the Inst() statement,
and are detailed in subsequent sections. Two versions of this code are supported; one
for little-endian (msbFirst = 0) and one for big-endian (msbFirst = 1). This definition
is in terms of a hypothetical aligned 64-bit fetch, and should not be confused with the
fetch algorithms used by specific Xtensa ISA implementations. Aligned 32-bit fetch and
unaligned fetch are other possible implementations, which would produce logically
equivalent results, but with different timings. Also, actual implementations would be ex-
pected to access memory only once for each fetch unit, not once per instruction as in the
definition in Section 3.5.4.1 and Section 3.5.4.2.
The processor may speculatively fetch instructions following the address in the program
counter. To facilitate this and to allow flexibility in the implementation, software must not
position instructions within the last 64 bytes before a boundary where protection or
cache attributes change. This exclusion does not apply if one of the two protections or
attributes is invalid. Instructions may be placed within 64 bytes before a transition from
valid to invalid or from invalid to valid — but not before any other transition. In addition, if
the Windowed Register Option is implemented, software must not position instructions
within the last 16 bytes of a 230 (1 GB) boundary, to allow flexibility in the implementation
of the register-window call and return instructions. The operation of the processor in
these exclusion regions is not defined.
Little-endian instruction fetch is defined as follows for a 64-bit fetch width (other fetch
sizes are similar):
goto abortInstruction
endif
(mem0, error) ← ReadInstMemory(pAddr0, attributes, 8'b11111111)
-- get start of instruction
if error then
EXCVADDR ← vAddr0
Exception (InstructionFetchErrorCause)
goto abortInstruction
endif
b ← 0||PC2..0
if b2 = 0 or b1 = 0 or (b0 = 0 and mem0(b||3'b011) = 1) then
-- instruction contained within a single fetch (64 bits in this example)
inst ← (undefined64||mem0)((b+2)||3'b111)..(b||3'b000)
else
-- instruction crosses a fetch boundary (64 bits in this example)
vAddr1 ← vaddr0 + 32'd8
(pAddr1, attributes, cause) ← ftranslate(vAddr1, CRING)
if invalid(attributes) then
EXCVADDR ← vAddr1
Exception (cause)
goto abortInstruction
endif
(mem1, error) ← ReadInstMemory(pAddr1,
attributes, 8'b11111111)
if error then
EXCVADDR ← vAddr1
Exception (InstructionFetchErrorCause)
goto abortInstruction
endif
inst ← (mem1||mem0)((b+2)||3'b111)..(b||3'b000)
endif
-- now have a 24-bit instruction (8 bits undefined if 16-bit), break it into fields
op0 ← inst3..0
t ← inst7..4
s ← inst11..8
r ← inst15..12
op1 ← inst19..16
op2 ← inst23..20
imm8 ← inst23..16
imm12 ← inst23..12
imm16 ← inst23..8
offset ← inst23..6
n ← inst5..4
m ← inst7..6
-- compute nextPC (may be overridden by branches, etc.)
nextPC ← PC + (030 || (if op03 then 2'b10 else 2'b11))
if LCOUNT ≠ 032 and CLOOPENABLE and nextPC = LEND then
LCOUNT ← LCOUNT − 1
nextPC ← LBEG
endif
-- execute instruction
Inst()
checkIcount ()
abortInstruction:
PC ← nextPC
Big-endian instruction fetch is defined as follows for a 64-bit fetch width (other fetch
sizes are similar):
goto abortInstruction
endif
inst ← (mem0||mem1)(p0||3'b111)..(p2||3'b000)
endif
-- now have a 24-bit instruction (8 bits undefined if 16-bit), break it into fields
op0 ← inst23..20
t ← inst19..16
s ← inst15..12
r ← inst11..8
op1 ← inst7..4
op2 ← inst3..0
imm8 ← inst7..0
imm12 ← inst11..0
imm16 ← inst15..0
offset ← inst17..0
n ← inst19..18
m ← inst17..16
-- compute nextPC (may be overridden by branches, etc.)
nextPC ← PC + (030 || (if op03 then 2'b10 else 3'b11))
if LCOUNT ≠ 032 and CLOOPENABLE and nextPC = LEND then
LCOUNT ← LCOUNT − 1
nextPC ← LBEG
endif
-- execute instruction
Inst()
checkIcount ()
abortInstruction:
PC ← nextPC
3.6 Reset
When the processor emerges from the reset state, it initializes many registers. The ISA
guarantees the values of some states after reset but leaves many others undefined.
Actual Xtensa processor implementations will often define the values of state left
undefined by the ISA. Chapter 5, "Processor State" on page 205 contains information
about each state value, including the value to which it is reset.
Load instructions form a virtual address by adding a base register and an 8-bit unsigned
offset. This virtual address is translated to a physical address if necessary. The physical
address is then used to access the memory system (often through a cache). The memo-
ry system returns a data item (either 32, 64, or 128 bits, depending on the configura-
tion). The load instructions then extract the referenced data from that memory item and
either zero-extend or sign-extend the result to be written into a register. Unless the
Unaligned Exception Option is enabled, the processor does not handle misaligned data
or trap when a misaligned address is used; instead it simply loads the aligned data item
containing the computed virtual address. This allows the funnel shifter to be used with a
pair of loads to reference data on any byte address.
Only the loads L32I, L32I.N, and L32R can access InstRAM and InstROM locations.
Because the operation of caches is implementation-specific, this manual does not pro-
vide a formal specification of cache access.
endif
(pAddr, attributes, cause) ← ltranslate(vAddr, CRING)
if invalid(attributes) then
EXCVADDR ← vAddr
Exception (cause)
goto abortInstruction
endif
p ← pAddr2..1 xor msbFirst2
(mem64, error) ← ReadMemory(pAddr31..3, attributes,
(2'b00)3-p||2'b11||(2'b00)p)
mem16 ← mem64(p||4'b1111)..(p||4'b0000)
Load16 ← (mem16, error)
endfunction Load16
Store instructions are similar to load instructions in address formation. Store memory
errors are not synchronous exceptions; it is expected that the memory system will use
an interrupt to indicate an error on a store.
Memory[pAddr]23..16 ← data6423..16
endif
if bytemask3 then
Memory[pAddr]31..24 ← data6431..24
endif
if bytemask4 then
Memory[pAddr]39..32 ← data6439..32
endif
if bytemask5 then
Memory[pAddr]47..40 ← data6447..40
endif
if bytemask6 then
Memory[pAddr]55..48 ← data6455..48
endif
if bytemask7 then
Memory[pAddr]63..56 ← data6463..56
endif
endprocedure WriteMemory
undefined(1-p)||5'b00000||data32||undefinedp||5'b00000)
endprocedure Store32Ring
Xtensa implementations can perform ordinary load and store operations in any order, as
long as loads return the last (as defined by program execution order) values stored to
each byte of the load address for a single processor and a simple memory. This flexibili-
ty is appropriate because most memory accesses require only these semantics and
some implementations may be able to execute programs significantly faster by exploit-
ing non-program order memory access. The Xtensa ISA only requires that implementa-
tions follow a simplified version of the Release Consistency model1 of memory access
ordering, although many implement stricter orderings for simplicity. For more on the
Xtensa memory order semantics, see "Multiprocessor Synchronization Option" on page
74.
However, some load and store instructions are executed not just to read and write stor-
age, but to cause some side effects on some other part of the system (for example,
another processor or an I/O device). In C and C++, such variables must be declared
volatile. Loads and stores to such locations must be executed in program order. The
Xtensa ISA therefore provides an instruction that can be used to give program ordering
of load and store memory accesses.
The MEMW instruction causes all memory and cache accesses (loads, stores, acquires,
releases, prefetches, and cache operations, but not instruction fetches) before itself in
program order to access memory before all memory and cache accesses (but not in-
struction fetches) after. At least one MEMW should be executed in between every load or
store to a volatile variable. The Multiprocessor Synchronization Option provides
some additional instructions that also affect memory ordering in a more focused fashion.
MEMW has broader applications than these other instructions (for example, when reading
and writing device registers), but it also may affect performance more than the synchro-
nization instructions.
The EXTW instruction is similar to MEMW, but it separates all external effects of instruc-
tions before the EXTW in program order from all external effects of instructions after the
EXTW in program order. EXTW is a superset of MEMW, and includes memory accesses in
what it orders.
Table 3–14 shows the memory ordering instructions in the Core Architecture.
1. Kourosh Gharachorloo, Dan Lenoski, James Laudon, Phillip Gibbons, Anoop Gupta, and John Hennessy, “Memory consistency and event order-
ing in scalable shared-memory multiprocessors,” Proceedings of the 17th Annual International Symposium on Computer Architecture, pages 15-
26, May 1990.
The unconditional branch instruction, J, has a longer range (PC-relative) than condition-
al branches. Calls have a slightly longer range because they target 32-bit aligned
addresses. In addition, jump and call indirect instructions provide support for case
dispatch, function variables, and dynamic linking.
The branch instructions in Table 3–16 compare a register operand against zero, an im-
mediate, or a second register value and conditional branch based on the result of the
comparison. Compound compare and branch instructions improve code density and
performance compared to other ISAs. All branches are PC-relative; the immediate field
contains the difference between the target PC and the current PC plus four. The use of a
PC-relative offset of minus three to zero is illegal and reserved for future use.
The encodings for the branch immediate constant (b4const) field and the branch
unsigned immediate constant (b4constu) fields, shown in Table 3–17 and Table 3–18,
specify one of the sixteen most frequent compare immediates for each type of constant.
MOVI sets a register to a constant encoded in the instruction. The conditional move
instructions shown in Table 3–19 are used for branch avoidance.
The arithmetic instructions that Table 3–20 lists include add and subtract with a small
shift for address calculations and for synthesizing constant multiplies. The ADDMI in-
struction is included for extending the range of load and store instructions.
The bitwise logical instructions in Table 3–21 provide a core set from which other logi-
cals can be synthesized. Immediate forms of these instructions are not provided be-
cause the immediate would be only four bits.
The shift instructions in Table 3–22 provide a rich set of operations while avoiding critical
timing paths. See Section 3.3.2 on page 25 for more information.
Table 3–23 contains processor control instructions. The RSR.*, WSR.*, and XSR.*
instructions read, write, and exchange Special Registers for both the Core Architecture
and the architectural options, as detailed in Table 5–128 on page 209. They save and
restore context, process interrupts and exceptions, and control address translation and
attributes. The XSR.* instruction reads and writes both the Special Register, and
AR[t]. It combines the RSR.* and WSR.* operations to exchange the Special Register
with AR[t]. The XSR.* instruction is not present in T1030 and earlier processors.
The xSYNC instructions synchronize Special Register writes and their uses. See
Chapter 5 for more information on how xSYNC instructions are used. These synchroni-
zation instructions are separate from the synchronization instructions used for multipro-
cessors, which are described in Section 4.3.12 on page 74.
On some Xtensa implementations the latency of RSR is greater than one cycle, and so it
is advantageous to schedule uses of the RSR result away from the RSR to avoid an
interlock.
The point at which WSR.* or XSR.* to most Special Registers affects subsequent in-
structions is not defined (SAR and ACC are exceptions). In these cases, Table 5–128 on
page 209 explains how to ensure the effects are seen by a particular point in the instruc-
tion stream (typically involving the use of one of the ISYNC, RSYNC, ESYNC, or DSYNC
instructions). A WSR.* or XSR.* followed by a RSR.* of the same register must be sep-
arated by an ESYNC instruction to guarantee the value written is read back. A WSR.PS or
XSR.PS followed by a RSIL also requires an ESYNC instruction.
4. Architectural Options
This chapter defines the Xtensa ISA options. Each option adds some associated config-
uration resources and capabilities. Some options are dependent on the implementation
of other options. These interdependencies, if any, are listed as Prerequisites at the be-
ginning of the description of each option. The additional parameters required to define
the option, the new state and instructions added by the option, and any other new fea-
tures (such as exceptions) added by the option are listed and the operation of the option
is described.
"Options for Additional Instructions" on page 53 lists options whose primary function is
to add new instructions to the processor’s instruction set, including:
The Code Density Option on page 53 adds 16-bit encodings of the most frequently
used 24-bit instructions for higher code density.
The Loop Option on page 54 adds a “zero overhead loop,” which requires neither
the extra instruction for a branch at the end of a loop nor the additional delay slots
that would result from the taken branch. A few fixed cycles of overhead mean that
each iteration of the loop pays no cost for the loop branch.
The Extended L32R Option on page 56 allows an additional choice in the address-
ing mode of the L32R instruction.
The 16-bit Integer Multiply Option on page 57 adds signed and unsigned 16x16
multiplication instructions that produce 32-bit results.
The 32-bit Integer Multiply Option on page 58 adds signed and unsigned 32x32
multiplication instructions that produce high and low parts of a 64-bit result.
The 32-bit Integer Divide Option on page 59 implements signed and unsigned 32-
bit division and remainder instructions.
The MAC16 Option on page 60 adds multiply-accumulate functions that are useful
in digital signal processing (DSP).
The Miscellaneous Operations Option on page 62 provides a series of instruc-
tions useful for some applications, but which are not necessary for others. By mak-
ing these optional, the Xtensa architecture allows the designer to choose only those
additional instructions that benefit the application.
The Coprocessor Option on page 63 allows the grouping of certain states in the
processor and adds an enable bit, which allows for lazy context switching.
The Boolean Option on page 65 adds a set of Boolean registers, which can be set
and cleared by user instructions and that can be used as branch conditions.
The Floating-Point Coprocessor Option on page 67 adds a floating-point unit for
single precision floating point.
The Multiprocessor Synchronization Option on page 74 adds acquire and re-
lease instructions with specific memory ordering relationships to the other Xtensa
memory access instructions.
The Conditional Store Option on page 77 adds a compare and swap type atomic
operation to the instruction set.
"Options for Interrupts and Exceptions" on page 82 lists options whose primary function
is to add and control exceptions and interrupts, including:
The Exception Option on page 82 adds the basic functions needed for the proces-
sor to take exceptions.
The Relocatable Vector Option on page 98 adds the ability for the exception vec-
tors to be relocated at run time.
The Unaligned Exception Option on page 99 adds an exception for memory ac-
cesses that are not aligned by their own size. They may then be emulated in soft-
ware.
The Interrupt Option on page 100 builds upon the Exception Option to add a flexi-
ble software prioritized interrupt system.
The High-Priority Interrupt Option on page 106 adds a hardware prioritized inter-
rupt system for higher performance.
The Timer Interrupt Option on page 110 adds timers and interrupts, which are
caused when the timer expires.
"Options for Local Memory" on page 111 lists options whose primary function is to add
different kinds of memory, such as RAMs, ROMs, or caches to the processor, including:
The Instruction Cache Option on page 115 adds an interface for a direct-mapped
or set-associative instruction cache.
The Instruction Cache Test Option on page 116 adds instructions to access the in-
struction cache tag and data.
The Instruction Cache Index Lock Option on page 117 adds per-index locking to
the instruction cache.
The Data Cache Option on page 118 adds an interface for a direct-mapped or set-
associative data cache.
The Data Cache Test Option on page 121 adds instructions to access the data
cache tag.
The Data Cache Index Lock Option on page 122 adds per-index locking to the
data cache.
The Instruction RAM Option on page 124 adds an interface for a local instruction
memory.
The Instruction ROM Option on page 125 adds an interface for a local instruction
Read Only Memory.
The Data RAM Option on page 126 adds an interface for a local data memory.
The Data ROM Option on page 126 adds an interface for a local data read-only
memory.
The XLMI Option on page 127 adds an interface with the timing of the local memory
interfaces, but with a full enough signal set to support non-memory devices.
The Hardware Alignment Option on page 128 adds the ability for the hardware to
handle unaligned accesses to data memory.
The Memory ECC/Parity Option on page 128 provides the ability to add parity or
ECC to cache and local memories.
"Options for Memory Protection and Translation" on page 138 lists options whose prima-
ry function is to control access to and manage memory, including:
The Region Protection Option on page 150 adds protection on memory in eight
segments.
The Region Translation Option on page 156 adds protection on memory in eight
segments and allows translations from one segment to another.
The MMU Option on page 158 adds full paging virtual memory management hard-
ware.
"Options for Other Purposes" on page 179 lists options that do not fall conveniently into
one of the other groups, including:
The Windowed Register Option on page 180 adds additional physical AR regis-
ters and a mapping mechanism, which together lead to smaller code size and higher
performance.
The Processor Interface Option on page 194 adds a bus interface used by memo-
ry accesses, which are to locations other than local memories. It is used for cache
misses for cacheable addresses as well as for cache bypass memory accesses.
The Miscellaneous Special Registers Option on page 195 provides one to four
scratch registers within the processor readable and writable by RSR, WSR, and XSR,
which may be used for application-specific exceptions and interrupt processing
tasks.
The Thread Pointer Option on page 196 provides a Special Register that may be
used for a thread pointer.
The Processor ID Option on page 196 adds a register that software can use to dis-
tinguish which of several processors it is running on.
The Debug Option on page 197 adds instructions-counting and breakpoint excep-
tions for debugging by software or external hardware.
The Trace Port Option on page 203 architectural features for supporting hardware
tracing of the processor.
The primary reason to disable the Code Density Option (16-bit instructions) is to provide
maximum opcode space for extensions. The primary reason to disable the other options
listed above is reduce the processor core area.
The choice of Cache, RAM, or ROM Options for instruction and data depends on the
characteristics of the application. RAM is not as flexible as Cache, but it requires slightly
less area because tags are not required. RAM may also be desirable when performance
predictability is required. ROM is even less flexible than RAM, but avoids the need to
load the memory and offers some protection from program errors and tampering.
This option adds 16-bit encodings of the most frequently used 24-bit instructions. When
a 24-bit instruction can be encoded into a 16-bit form, the code-size savings is signifi-
cant.
Prerequisites: None
Incompatible options: None
Compatibility note: The additions made by this option were once considered part of
the core architecture, thus compatibility with binaries for previous hardware might
require the use of this option. Many available third-party software packages includ-
ing some currently supported operating systems require the Code Density Option.
4.3.1.2 Branches
The Loop Option adds the ability for the processor to execute a zero-overhead loop
where the number of iterations (not counting an early exit) can be determined prior to
entering the loop. This capability is useful in digital signal processing applications where
the overhead of a branch in a heavily used loop is unacceptable. A single loop instruc-
tion defines both the beginning and end of a loop, as well as a count of how many times
the loop will execute.
Prerequisites: None
Incompatible options: None
Compatibility note: The additions made by this option were once considered part of
the core architecture, thus compatibility with binaries for previous hardware might
require the use of this option. Many available third-party software packages includ-
ing some currently supported operating systems require the Loop Option.
Table 4–28 and Table 4–29 show this option’s architectural additions.
LBEG and LEND are undefined after processor reset. LCOUNT is initialized to zero after
processor reset.
There is a restriction on instruction alignment for zero-overhead loops. The first instruc-
tion after the LOOP instruction, which begins at the address written to LBEG by the LOOP
instruction, must be entirely contained within a naturally aligned, power of two sized unit
of a particular size. That size is the next larger power of two equal to or greater than the
instruction length, but not less than 4 bytes. Thus a 16-bit instruction, if it is the first in a
loop, may be at 0 mod 4, 1 mod 4, or 2 mod 4. A 24-bit instruction, if it is the first in a
loop, may be at 0 mod 4 or at 1 mod 4. As an example of a potential larger instruction, a
64-bit instruction must be aligned at 0 mod 8.
The last instruction of the loop must not be a call, ISYNC, WAITI, or RSR.LCOUNT. If the
last instruction of the loop is a taken branch, then the value of LCOUNT is undefined.
Thus, a taken branch may be used to exit the loop (in which case the value of LCOUNT is
irrelevant), but not to iterate within the loop.
Loops are disabled when PS.EXCM is set in Xtensa Exception Architecture 2 and above.
This prevents program code from maliciously or accidentally setting LEND to an address
in an exception handler and then causing the exception, thereby transitioning to Ring 0
while retaining control of the processor.
The processor includes the following to compute the PC of the next instruction:
The semantics above have some non-obvious consequences. A taken branch to the ad-
dress in LEND does not cause a transfer to LBEG. Thus a taken branch to the LEND in-
struction can be used to exit the loop prematurely. This is why a call instruction as the
last instruction of a loop will not do the obvious thing (the return will branch to the LEND
address and exit the loop). To conditionally begin the next loop iteration, a branch to a
NOP before LEND may be used.
The Extended L32R Option adds functionality to the standard L32R instruction. The
standard L32R instruction has an offset that can reach as far as 256kB below the current
PC. In the case where an instruction RAM approaches or exceeds 256kB in size, ac-
cessing literal data becomes much more difficult. This option is intended to ease the ac-
cess to literal data by providing an optional separate literal base register.
Prerequisites: None
Incompatible options: MMU Option (page 158)
The literal base (LITBASE) register contains 20 upper bits, which define the location of
the literal base and one enable bit (En). When the enable bit is clear, the L32R instruc-
tion loads a literal at a negative offset from the PC. When the enable bit is set, the L32R
instruction loads a literal at a negative offset from the address formed by the 20 upper
bits of literal base and 12 lower bits of 12’h000. See the L32R instruction description in
Chapter 6. Figure 4–7 shows the LITBASE register format.
31 12 11 1 0
20 11 1
The enable bit of the literal base register is cleared after reset. The remaining bits are
undefined after reset.
This option provides two instructions that perform 16×16 multiplication, producing a 32-
bit result. It is typically useful for digital signal processing (DSP) algorithms that require
16 bits or less of input precision (32 bits of input precision is provided by the 32-bit Inte-
ger Multiply Option) and do not require more than 32-bit accumulation (as provided by
the MAC16 Option). Because a 16×16 multiplier is one-fourth the area of a 32×32 multi-
plier, this option is less costly than the 32-bit Integer Multiply Option. Because it lacks an
accumulator and data registers, it is less costly than the MAC16 Option.
Prerequisites: None
Incompatible options: None
See Also "MAC16 Option" on page 60 and "32-bit Integer Multiply Option" on page
58
Table 4–31 shows this option’s architectural additions. There are no configuration pa-
rameters associated with the MUL16 Option and no additional processor state.
This option provides instructions that implement 32-bit integer multiplication as instruc-
tions. This provides single instruction targets for the multiplication operators of program-
ming languages such as C. When this option is not enabled, the Xtensa compiler uses
subroutine calls to implement 32-bit integer multiplication. Note that various algorithms
may be used to implement multiplication, and some hardware implementations may be
slower than the software implementations for some operand values. Implementations
may allow a choice of algorithms through configuration parameters to optimize among
area, speed, and other characteristics.
There is one sub-option within this option: Mul32High. It controls whether the MULSH
and MULUH instructions are included or not. For some implementations, generating the
high 32 bits of the product requires additional hardware, and so disabling this sub-option
may reduce cost.
Prerequisites: None
Incompatible options: None
See Also: "MAC16 Option" on page 60 and "16-bit Integer Multiply Option" on page
57
Table 4–32 and Table 4–33 show this option’s architectural additions. This option adds
no new processor state.
This option provides instructions that implement 32-bit integer division and remainder
operations. When this option is not enabled, the Xtensa compiler uses subroutine calls
to implement division and remainder. Note that various algorithms may be used to imple-
ment these instructions, and some hardware implementations may be slower than the
software implementations for some operand values.
Prerequisites: None
Incompatible Options: None
Table 4–34 through Table 4–36 show this option’s architectural additions. This option
adds no new processor state. This option does add a new exception, Integer Divide by
Zero, which is raised when the divisor operand of a QUOS, QUOU, REMS, or REMU instruc-
tion contains zero.
The MAC16 Option adds multiply-accumulate functions that are useful in DSP and other
media-processing operations. The option adds a 40-bit accumulator (ACC), four 32-bit
data registers (MR[n]), and 72 instructions.
The multiplier operates on two 16-bits operands from either the address registers (AR) or
MAC16 registers (MR). Each operand may be taken from either the low or high half of a
register. The result of the operation is placed in the 40-bit accumulator. The MR regis-
ters and the low 32 bits and high 8 bits of the accumulator are readable and writable with
the RSR, WSR, and XSR instructions. MR[0] and MR[1] can be used as the first multiplier
input, and MR[2] and MR[3] can be used as the second multiplier input. Four of the 72
added instructions can load the MR registers with 32-bit values from memory in parallel
with multiply-accumulate operations.
The accumulator (ACC) and data registers (MR) are undefined after reset.
Prerequisites: None
Incompatible options: None
Table 4–37 and Table 4–38 show this option’s architectural additions.
The CLAMPS instruction, implemented with the Miscellaneous Operations Option, is use-
ful in conjunction with the MAC16 Option. It allows clamping results to 16 bits before
storing to memory.
Table 4–39 and Table 4–40 show this option’s architectural additions.
processors. After the Coprocessor Option is added, specific coprocessors, such as the
Floating-Point Coprocessor Option, can be added, along with system-specific instruc-
tions for coprocessor operations.
Prerequisites: Exception Option (page 82)
Incompatible options: None
Table 4–41 and Table 4–42 show this option’s architectural additions.
RUR and WUR are not created by the Coprocessor Option, but rather by TIE language
constructs. They provide a uniform way for reading and writing miscellaneous state add-
ed via the TIE language. The TIE user_register construct associates TIE state reg-
isters with RUR/WUR register numbers in 32-bit quantities. RUR reads 32 bits of TIE state
into an address register, and WUR writes 32 bits to a TIE state register from an address
register. The ISA does not define the result of additional bits read by RUR when fewer
than 32 bits of TIE state are associated with the user register.
The TIE compiler automatically generates for each coprocessor the assembly code to
save the state associated with a coprocessor to memory and to restore coprocessor
state from memory.
Tensilica reserves user register numbers for RUR and WUR in the range 192 to 255.
The CPENABLE register allows a “lazy” context switch of the coprocessor state. Any in-
struction that references coprocessor n state (not including the shared Boolean regis-
ters) when that coprocessor’s enable bit (bit n) is clear raises a
CoprocessornDisabled exception. CPENABLE can be cleared on context switch, and
the exception used to unload the previous task’s coprocessor state and load the current
task’s. The appropriate CPENABLE bit is then set by the exception handler, which then
returns to execute the coprocessor instruction. An RSYNC instruction must be executed
after writing CPENABLE before executing any instruction that references state controlled
by the changed bits of CPENABLE. This register is undefined after reset.
If a single instruction references state from more than one coprocessor not enabled in
CPENABLE, then one of CoprocessornDisabled exceptions is raised. The prioritiza-
tion among multiple CoprocessornDisabled exceptions is implementation-specific.
This option makes a set of Boolean registers available, along with branches and other
operations that refer to them. Multiple coprocessors and other TIE language extensions
can use this set.
Prerequisites: None
Incompatible options: None
Table 4–43 and Table 4–44 show this option’s architectural additions.
4.3.10.2 Booleans
A coprocessor test or comparison produces a Boolean result. The Boolean Option pro-
vides 16 single-bit Boolean registers for storing the results of coprocessor comparisons
for testing in conditional move and branch instructions. Boolean logic may replace
branches in some situations. Compared to condition codes used by other ISAs, these
Booleans eliminate the bottleneck of having only a single place to store comparison re-
sults. It is possible, for example, to do multiple comparisons before the comparison re-
sults are used. For Single-Instruction Multiple-Data (SIMD) operations, Booleans pro-
vide up to 16 simultaneous compare results and conditionals.
Boolean-producing instructions generate only one sense of the condition (for example, =
but not ≠); all Boolean uses allow for complementing of the Boolean. Multiple Booleans
may be combined into a single Boolean using the ANY4, ALL4, and so forth instructions.
For example, this is useful after a SIMD comparison to test if any or all of the elements
satisfy the test, such as testing if any byte of a word is zero. ANY2 and ALL2 instructions
are not provided; ANDB and ORB provide this functionality given bs+0 and bs+1 as argu-
ments.
The Boolean registers are accessible from C using the xtbool, xtbool2, xtbool4,
xtbool8, and xtbool16 data types. See the Xtensa C and C++ Compiler User’s
Guide for details.
The Floating-Point Coprocessor Option adds the logic and architectural components
needed for IEEE754 single-precision floating-point operations. These operations are
useful for DSP that requires >16 bits of precision, such as audio compression and de-
compression. Also, DSP algorithms for less precise data are more easily coded using
floating-point, and good performance is obtainable when programming in languages
such as C.
Prerequisites: Coprocessor Option (page 63) and Boolean Option (page 65)
Incompatible options: None
Table 4–45 through Table 4–46 show this option’s architectural additions.
31 30 23 22 0
s exp fraction
1 8 23
The other data format is a signed, 32-bit integer used by the FLOAT.S, TRUNC.S,
ROUND.S, FLOOR.S, and CEIL.S instructions.
IEEE754 uses a sign-magnitude format, with a 1-bit sign, an 8-bit exponent with bias
127, and a 24-bit significand formed from 23 stored bits representing the binary digits to
the right the binary point, and an implicit bit to the left of the binary point (0 if exponent is
zero, 1 if exponent is non-zero). Thus, the value of the number is:
Thus, the representation for 1.0 is 0x3F800000, with a sign of 0, exp of 127, a zero frac-
tion, and an implicit 1 to the left of the binary point.
The Xtensa ISA includes IEEE754 signed-zero, infinity, quiet NaN, and sub-normal rep-
resentations and processing rules. The ISA does not include IEEE754 signaling NaNs or
exceptions. Integer ⇔ floating-point conversions include a binary scale factor to make
conversion into and out of fixed-point formats faster.
Table 4–45 summarizes the processor state added by the floating-point coprocessor.
The FR register file consists of 16 registers of 32 bits each and is used for all data com-
putation. Load and store instructions transfer data between the FR’s and memory. The
FCR register file has one field that may be changed at run-time to control the operation
of various instructions. Table 4–47 lists FCR fields and their associated meanings. The
format of FCR is
31 12 11 7 6 5 4 3 2 1 0
reserved ignore V Z O U I RM
20 5 1 1 1 1 1 2
The FSR register file provides the status flags required by IEEE754. These flags are set
by any operation that raises a non-enabled exception (see Section 4.3.11.4). Enabled
exceptions abort the operation with a floating-point exception and the flags are not writ-
ten:
31 12 11 10 9 8 7 6 0
reserved V Z O U I ignore
20 1 1 1 1 1 7
Most architectures have a combined floating-point control and status register, instead of
separate registers. In high-performance pipelines, this combination can compromise
performance, as reads and writes must access all bits, even ones that are not required
by the program. Xtensa’s FCR may be read and written without waiting for the results of
pending floating-point operations. Writes to FCR affect subsequent floating-point opera-
tions, but there is usually little performance cost from this dependency. Only reads of
FSR need cause a significant pipeline interlock.
FCR and FSR are organized to allow implementation with a single 32-bit physical regis-
ter. The separate register numbers affect only the bits read and written of this underlying
physical register. It is also possible for software to bitwise logical OR the RUR’s of FCR
and FSR to create the appearance of a single register and to write this combined value
to FCR and FSR.
The reserved bits of FCR and FSR must store the last value written, but if that value is
non-zero, this causes all floating-point operations to raise a floating-point exception.
This allows future extensions to define additional control values that if used in earlier im-
plementations, can be emulated in software.
Current implementations neither raise exceptions enabled by FCR bits nor set flag bits in
FSR. They also do not raise an exception when one of the reserved bits of FCR or FSR is
non-zero.
The floating-point instructions are defined in Table 4–49 and Table 4–50. The instruc-
tions operate on data in the floating-point register file, which consists of 16 32-bit regis-
ters.
The floating-point ISA requires a triple read-port FR register file for the MADD.S and
MSUB.S operations.
When multiple processors are used in a system, some sort of communication and syn-
chronization between processors is required. (Note that multiprocessor synchronization
is distinct from pipeline synchronization between instructions as represented by the
ISYNC, RSYNC, ESYNC, and DSYNC instructions, despite the name similarity). In some
cases, self-synchronizing communication, such as input and output queues, is used. In
other cases, a shared memory model is used for communication, and it is necessary to
provide instruction-set support for synchronization because shared memory does not
provide the required semantics. The Multiprocessor Synchronization Option is designed
for this shared memory case.
Prerequisites: None
Incompatible Options: None
The Xtensa ISA requires that valid programs follow a simplified version of the Release
Consistency model of memory access ordering. Xtensa implementations may perform
ordinary load and store operations to non-overlapping addresses in any order. Loads
and stores to overlapping addresses on a single processor must be executed in program
order. This flexibility is appropriate because most memory accesses require only these
The Xtensa version of Release Consistency is adapted from Memory Consistency and
Event Ordering in Scalable Shared-Memory Multiprocessors by Gharachorloo et. al. in
the Proceedings of the 17th Annual International Symposium on Computer Architecture,
1990, from which the following three definitions are directly borrowed:
A load by processor i is considered performed with respect to processor k at a point
in time when the issuing of a store to the same address by processor k cannot affect
the value returned by the load.
A store by processor i is considered performed with respect to processor k at a point
in time when an issued load to the same address by processor k returns the value
defined by this store (or a subsequent store to the same location).
An access is performed when it is performed with respect to all processors.
Using these definitions, Xtensa places the following requirements on memory access:
Before an ordinary load or store access is allowed to perform with respect to any
other processor, all previous acquire accesses must be performed, and
Before a release access is allowed to perform with respect to any other processor,
all previous ordinary load, store, acquire, and release accesses must be performed,
and
Before an acquire is allowed to perform with respect to any other processor, all pre-
vious acquire accesses must be performed.
Many Xtensa implementations will adopt stricter memory orderings for simplicity. How-
ever, programs should not rely on any stricter memory ordering semantics than those
specified here.
L32AI and S32RI are 32-bit load and store instructions with acquire and release se-
mantics. These instructions are useful for controlling the ordering of memory references
in multiprocessor systems, where different memory locations may be used for synchro-
nization and data, so that precise ordering between synchronization references must be
maintained. Other load and store instructions may be executed by processor implemen-
tations in any order that produces the same uniprocessor result.
The MEMW instruction is somewhat similar in that it enforces load and store ordering, but
is less selective. MEMW is intended for implementing C’s volatile attribute, and not for
high performance synchronization between processors.
L32AI is used to load a synchronization variable. This load will be performed before any
subsequent load, store, acquire, or release is begun. This ensures that subsequent
loads and stores do not see or modify data that is protected by the synchronization vari-
able.
S32RI is used to store to a synchronization variable. This store will not begin until all
previous loads, stores, acquires, or releases are performed. This ensures that any loads
of the synchronization variable that see the new value will also find all protected data
available as well.
Here, incount and outcount are synchronization variables, and buffer is a shared
data variable. producer’s writes to incount and consumer’s writes to outcount
must use S32RI and producer’s reads of outcount and consumer’s reads of
incount must use L32AI. If producer’s write to incount were done with a simple
S32I, the processor or memory system might reorder the write to buffer after the write
to incount, thereby allowing consumer to see the wrong data. Similarly, if
consumer’s read of incount were done with a simple L32I, the processor or memory
system might reorder the read to buffer before the read of incount, also causing
consumer to see the wrong data.
When the atomic operation reaches the PIF bus, it causes a Read-Compare-Write
(RCW) transaction on the PIF, which is different from normal reads and writes.
Table 4–52 through Table 4–53 show this option’s architectural additions.
Semaphores and other exclusion operations are equally simple to create using S32C1I.
There are many possible atomic memory primitives. S32C1I was chosen for the Xtensa
ISA because it can easily synthesize all other primitives that operate on a single memory
location. Many other primitives (for example, test and set, or fetch and add) are not as
universal. Only primitives that operate on multiple memory locations are more powerful
than S32C1I. Note that there can be subtle issues with some algorithms if between a
read and an S32C1I, there are multiple changes to the target which bring the value
back to the original one.
If the address of the RCW transaction targets the Inbound PIF port of another
Xtensa processor, the targeted Xtensa processor has the Conditional Store Option
and the Data RAM Option configured, and the RCW address targets the DataRAM,
the RCW will be performed atomically on the target processor’s DataRAM. No exter-
nal logic other than PIF bus interconnects is necessary to allow an Xtensa processor
to atomically access a DataRAM location in another Xtensa processor in this way.
Internal Operation — Xtensa processors with the Conditional Store Option and the
Data Cache Option configured can execute the S32C1I instruction by allocating and
filling the line in the cache and accessing the location atomically there. No external
logic is necessary in this case. Internal Operation may be the only method available
for certain memory types or it may be directed by the ATOMCTL register.
4.3.13.4 The Atomic Operation Control Register (ATOMCTL) under the Conditional Store
Option
The ATOMCTL register exists in some implementations of the Conditional Store Option to
control how the S32C1I instruction interacts with the cache and with the PIF bus. Imple-
mentations without the ATOMCTL register allow only one behavior per memory type.
Table 4–54 shows the ATOMCTL register. Table 4–54 describes the fields of the
ATOMCTL register. See Section 4.3.13.4 above for the meaning of the codes in the table.
31 6 5 4 3 2 1 0
reserved WB WT BY
24 2 2 2
ATOMCTL is defined after processor reset as shown in Table 5–186 on page 237.
An older, fixed operation, Xtensa processor which operates on all cacheable and bypass
regions by RCW transaction may be emulated by setting the ATOMCTL register to 0x15.
One which operates only on bypass regions by RCW transaction may be emulated by
setting the ATOMCTL register to 0x01.
Bits of the ATOMCTL register are present even when they correspond to a memory type
which is not configured in the Xtensa processor. For example, a processor configured
without a Data Cache will still contain the fields WB and WT and those fields may contain
any value. But in this case, no cacheable memory will be addressable and so it will not
be possible to make use of these fields.
In an Xtensa processor with the Data RAM Option configured, the ATOMCTL register
does not affect the "Local Memory" use model or the receiving of Inbound PIF transac-
tions as described under the "RCW Transaction" use model in Section 4.3.13.3.
With regard to the memory ordering defined for L32AI and S32RI in Section 4.3.12.1,
S32C1I plays the role of both acquire and release. That is, before the atomic pair of
memory accesses can perform, all ordinary loads, stores, acquires, and releases must
have performed. In addition, before any following ordinary load, store, acquire, or re-
lease can be allowed to perform, the atomic pair of the S32C1I must have performed.
This allows the conditional store to make atomic changes to variables with ordering re-
quirements, such as the counts discussed in the example in Section 4.3.12.3.
There are many ways of handling these conditions ranging from ignoring the conditions
or freezing the clock and asserting an output signal to multi-threaded self-handling of ex-
ceptional conditions. The Exception Option provides for the self-handling of instruction
exceptions and reset. Its self-handling mechanisms for these can be extended by the
Relocatable Vector Option and the Unaligned Exception Option. In addition, it provides a
foundation for additional options such as the Interrupt Option, the High-Priority Interrupt
Option, or the Timer Interrupt Option. Again, the Debug Option can be added to provide
for hardware debugging.
The Exception Option implements basic functions needed in the management of all
types of exceptional conditions. These conditions are handled by the processor itself by
redirecting execution to an exception vector to handle the condition with the possibility of
returning to continue execution at the original code stream. The option only fully imple-
ments the management of a subset of exceptional conditions. Additional options provid-
ing additional exception types use the Exception Option as a foundation.
Prerequisites: None
Incompatible options: None
Table 4–55 through Table 4–58 show this option’s architectural additions.
A broad set of interrupts and exceptions can be handled by the processor itself under
the Exception Option. Table 4–59 through Table 4–62 list the types of exceptional condi-
tions other than reset that can be handled under the Exception Option either natively or
with the help of an additional option. In each table, the first column contains the name of
the condition. The second column contains a description of the condition and the third
column contains both the option required for the condition to be handled and the name
of the vector to which execution will be redirected. Reset is provided by the Exception
Option and redirects execution to ResetVector.
4.4.1.3 The Miscellaneous Program State Register (PS) under the Exception Option
The PS register contains miscellaneous fields that are grouped together primarily so that
they can be saved and restored easily for interrupts and context switching. Figure 4–8
shows its layout and Table 4–63 describes its fields. Section 5.3.5 “Processor Status
Special Register” describes the fields of this register in greater detail. The processor ini-
tializes these fields on processor reset: PS.INTLEVEL is set to 15, if it exists and
PS.EXCM is set to 1, and the other fields are set to zero.
31 19 18 17 16 15 12 11 8 7 6 5 4 3 0
CALLINC
EXCM
WOE
UM
13 1 2 4 4 2 1 1 4
The fields of the PS register listed in Table 4–63 affect many functions in the processor
through these variables:
The current interrupt level (CINTLEVEL) defines which levels of interrupts are currently
enabled and which are not. Interrupts at levels above CINTLEVEL are enabled. Those at
or below CINTLEVEL are disabled. To enable a given interrupt, CINTLEVEL must be
less than its level, and its INTENABLE bit must be 1. The level is defined by:
CINTLEVEL ← max(PS.EXCM∗EXCMLEVEL,PS.INTLEVEL)
PS.EXCM and PS.INTLEVEL are part of the PS register in Table 4–63. EXCMLEVEL is
defined in Table 4–74. CINTLEVEL is also used by the Debug Option.
The current ring (CRING) determines which ASIDs from the RASID register will cause a
privilege violation. ASIDs with position (in RASID) equal to or greater than CRING may
be used in translation while those with position less than CRING will cause a privilege vi-
olation. Privileged instructions may only be executed if CRING is zero. CRING is defined
by:
CRING ← if (MMU Option configured && PS.EXCM = 0) then PS.RING else 0
The current window overflow enable (CWOE) defines whether window overflow excep-
tions are currently enabled. It is defined by:
CWOE ← if PS.EXCM then 0 else PS.WOE
The current loop enable (CLOOPENABLE) determines whether the loop-back function of
the zero-overhead loop instruction is enabled or not.
CLOOPENABLE ← PS.EXCM = 0
4.4.1.5 The Exception Cause Register (EXCCAUSE) under the Exception Option
After an exception that redirects execution to one of the general exception vectors
(UserExceptionVector, KernelExceptionVector, or DoubleExceptionVec-
tor), the EXCCAUSE register contains a value that specifies the cause of the last excep-
tion. Figure 4–9 shows the EXCCAUSE register. Table 4–64 describes the 6-bit binary-
value encodings for the register. EXCCAUSE is undefined after processor reset.
31 6 5 0
reserved EXCCAUSE
26 6
Exceptions that redirect execution to other vectors that do not use EXCCAUSE may either
report details in a different cause register or may have only a single cause and no need
for additional cause information.
4.4.1.6 The Exception Virtual Address Register (EXCVADDR) under the Exception Option
The exception virtual address (EXCVADDR) register contains the virtual byte address that
caused the most recent fetch, load, or store exception. Table 4–64 shows, for every ex-
ception cause value, whether or not the exception virtual address register will be set.
This register is undefined after processor reset. Because EXCVADDR may be changed
by any TLB miss, even if the miss is handled entirely by processor hardware, code that
counts on it not changing value must guarantee that no TLB miss is possible by using
only static translations for both instruction and data accesses. Figure 4–10 shows the
EXCVADDR register format.
31 0
32
4.4.1.7 The Exception Program Counter (EPC) under the Exception Option
The exception program counter (EPC) register contains the virtual byte address of the
instruction that caused the most recent exception or the next instruction to be executed
in the case of a level-1 interrupt. This instruction has not been executed. Software may
restart execution at this address by using the RFE instruction after fixing the cause of the
exception or handling and clearing the interrupt. This register is undefined after proces-
sor reset and its value might change whenever PS.EXCM is 0.
The Exception Option defines only one EPC value (EPC[1]). The High-Priority Interrupt
Option extends the EPC concept by adding one EPC value per high-priority interrupt
level (EPC[2..NLEVEL+NNMI]).
31 0
32
4.4.1.8 The Double Exception Program Counter (DEPC) under the Exception Option
The double exception program counter (DEPC) register contains the virtual byte ad-
dress of the instruction that caused the most recent double exception. A double excep-
tion is one that is raised when PS.EXCM is set. This instruction has not been executed.
Many double exceptions cannot be restarted, but those that can may be restarted at this
address by using an RFDE instruction after fixing the cause of the exception.
The DEPC register exists only if the configuration parameter NDEPC=1. If DEPC does not
exist, the EPC register is used in its place when a double exception is taken and when
the RFDE instruction is executed. The consequence is that it is not possible to recover
from most double exceptions. NDEPC=1 is required if both the Windowed Register
Option and the MMU Option are configured. DEPC is undefined after processor reset.
31 0
32
4.4.1.9 The Exception Save Register (EXCSAVE) under the Exception Option
The exception save register (EXCSAVE[1]) is simply a read/write 32-bit register intend-
ed for saving one AR register in the exception vector software. This register is undefined
after processor reset and there are many software reasons its value might change
whenever PS.EXCM is 0.
The Exception Option defines only one exception save register (EXCSAVE[1]). The
High-Priority Interrupt Option extends this concept by adding one EXCSAVE register per
high-priority interrupt level (EXCSAVE[2..NLEVEL+NNMI]).
31 0
32
Under the Exception Option, exceptional conditions are handled by saving some state
and redirecting execution to one of a set of exception vector locations as listed in
Table 4–59 through Table 4–62 along with ResetVector. This section looks at this pro-
cess from the other end and describes how the code at a vector can determine the na-
ture of the exceptional condition that has just occurred.
Table 4–65 shows, for each vector, how the code can determine what has happened.
The first column lists the possible vectors, not just for the Exception Option itself, but
also for other options that add on to the Exception Option. For vectors which can be
reached for more than one cause, the second column indicates the register containing
the main indicator of that cause. The third column indicates other registers that may
contain secondary information under that vector. The last column shows the option that
is required for the vector and the other listed registers to exist.
The three exception vectors that use EXCCAUSE for the primary cause information form
a set called the “general vector.” If PS.EXCM is set when one of the exceptional condi-
tions is raised, then the processor is already handling an exceptional condition and the
exception goes to the DoubleExceptionVector. Only a few double exceptions are
recoverable, including a TLB miss during a register window overflow or underflow ex-
ception. For these, EXCCAUSE (and EXCSAVE in Table 4–66) must be well enough un-
derstood not to need duplication. Otherwise (PS.EXCM clear), if PS.UM is set the excep-
tion goes to the UserExceptionVector, and if not the exception goes to the
KernelExceptionVector. The Exception Option effectively defines two operating
modes: user vector mode and kernel vector mode, controlled by the PS.UM bit. The
combination of user vector mode and kernel vector mode is provided so that the user
vector exception handler can switch to an exception stack before processing the excep-
tion, whereas the kernel vector exception handler can continue using the kernel stack.
Single or multiple high-priority interrupts can be configured for any hardware prioritized
levels 2..6. These will redirect to the InterruptVector[i] where “i” is the level. One
of those levels, often the highest one, can be chosen as the debug level and will redirect
execution to InterruptVector[d] where “d” is the debug level. The level one higher
than the highest high-priority interrupt can be chosen as an NMI, which will redirect exe-
cution to InterruptVector[n] where “n” is the NMI level (2..7).
InterruptVector[3]
InterruptVector[4]
InterruptVector[5]
InterruptVector[6]
InterruptVector[7]
KernelExceptionVector
UserExceptionVector
DoubleExceptionVector
Table 4–66 shows, for each vector in the first column, which registers are involved in the
process of taking the exception and returning from it for that vector. Since there is no re-
turn from the ResetVector, it has no entries in the other four columns of this table.
Otherwise all entries have a second column entry of where the PC is saved and a fifth
column entry of the instruction which should be used for returning. The third column
shows where the current PS register value is saved before being changed, while the
fourth column shows where the handler may find a scratch register. Note that the gener-
al vector entries and the window vector entries modify the PS only in ways that their re-
spective return instructions undo, and therefore there is no required PS save register.
The window vector entries do not need scratch space because they are loading and
storing a block of AR registers that they can use for scratch where they need it.
The taking of an exception under the Exception Option has the following semantics:
procedure Exception(cause)
if (PS.EXCM & NDEPC=1) then
DEPC ← PC
nextPC ← DoubleExceptionVector
elseif PS.EXCM then
EPC[1] ← PC
nextPC ← DoubleExceptionVector
elseif PS.UM then
EPC[1] ← PC
nextPC ← UserExceptionVector
else
EPC[1] ← PC
nextPC ← KernelExceptionVector
endif
EXCCAUSE ← cause
PS.EXCM ← 1
endprocedure Exception
When a given instruction causes multiple exceptions, the priority order for choosing the
exception to be reported is listed below from highest priority to lowest. In cases where it
is possible to have more than one occurrence of the same cause within the same in-
struction, the priority among the occurrences is undefined.
Pre-Instruction Exceptions:
Non-maskable interrupt
High-priority interrupt (including debug exception for DEBUG INTERRUPT)
Level1InterruptCause
Fetch Exceptions:
Instruction-fetch translation errors
- InstTLBMultiHitCause
- InstTLBMissCause
- InstFetchPrivilegeCause
- InstFetchProhibitedCause
InstructionFetchErrorCause (Instruction-fetch address or instruction data errors)
ECC/parity exception for Instruction-fetch
Decode Exceptions:
IllegalInstructionCause
PrivilegedCause
SyscallCause (SYSCALL instruction)
Debug exception for BREAK (BREAK, BREAK.N instructions)
Divide by Zero
Exceptions are grouped in the priority list by what information is necessary to determine
whether or not the exception is to be raised. The pre-instruction exceptions may be eval-
uated before the instruction begins because they require nothing but the PC of the in-
struction. Fetch exceptions are encountered in the process of fetching the instruction.
Decode exceptions may be evaluated after obtaining the instruction itself. Execute regis-
ter exceptions require internal register state and execute memory exceptions involve the
process of accessing the memory on which the instruction operates.
Exceptions are not necessarily precise. On some implementations, some exceptions are
raised after subsequent instructions have been executed. In such implementations, the
EXCW instruction can be used to prevent unwanted effects of imprecise exceptions. The
EXCW instruction causes the processor to wait until all previous instructions have taken
their exceptions, if any.
Interrupts have an implicit EXCW; when an interrupt is taken, all instructions prior to the
instruction addressed by EPC have been executed and any exceptions caused by those
instructions have been raised. Interrupts are listed at the top of the priority list. Because
the relative cycle position of an internal instruction and an interrupt pin assertion is not
well-defined, the priority of interrupts with respect to exceptions is not truly well-defined
either.
This option splits Exception Vectors into two groups and adds a choice of two base ad-
dresses for one group and a Special Register as a base for the other group.
Prerequisites: Exception Option (page 82)
Incompatible options: None
Under the Relocatable Vector Option, exception vectors are more restricted than they
are without it. The vectors are organized into two groups, a "Static" group and a "Dy-
namic" group. Within each group there is a required order among the vectors which ex-
ist. The list immediately after Table 4–65 (page 94) indicates both the group and the or-
der within the group. Some implementations may place an upper bound on the size of
each group of vectors as measured by the difference between the address of the high-
est numbered vector in the group and the address of the lowest numbered vector in the
group.
The Static group of vectors is not movable under software control. Two base addresses
for the Static group are set by the designer at configuration time and an input pin of the
processor is sampled at reset to determine which of the two configured addresses will
be used. The base address will not change after reset. The offsets from this base are
also chosen at configuration time and will not change.
The Dynamic group of vectors is movable under software control. The Special Register,
VECBASE, described in Table 5–155 on page 224, holds the current base for the Dynam-
ic group. The special register resets to a value set by the designer at configuration time
but is freely writable using the WSR.VECBASE instruction. The offsets from the base
must increase in the order indicated by Table 4–66 and are also set by the designer at
configuration time.
This option causes an exception to be raised on any unaligned memory access whether
it is generated by core architecture memory instructions, by optional instructions, or by a
designer’s TIE instructions.1 With system software cooperation, occasional unaligned
accesses can be handled correctly.
1. In the T1050 release, which was the first for the Unaligned Exception Option, only Core Architecture memory instructions raise the unaligned
exception.
Cache line oriented instructions such as prefetch and cache management instructions
will not raise the unaligned exception. Special instructions such as LICW that use a gen-
erated address for something other than an actual memory address also will not raise
the exception. Individual instruction listings list the unaligned exception when it can be
raised by that instruction.
Memory access instructions will raise the exception when address and size indicate it.
Any address that is not a multiple of the size associated with the instruction will raise the
unaligned exception whether or not the access crosses any particular size boundary. For
example, an L16UI instruction that generates the address 32’h00000005, will raise
the unaligned exception, even though the access is entirely within a single 32-bit ac-
cess.
The Interrupt Option implements level-1 interrupts. These are asynchronous exceptions
on processor input signals or software exceptions. They have the lowest priority of all in-
terrupts. Level-1 interrupts are handled differently than the high-priority interrupts at pri-
ority levels 2 through 6 or NMI. The Interrupt Option is a prerequisite for the High-Priority
Interrupt Option, Timer Interrupt Option, and Debug Option.
Certain aspects of high-priority interrupts are specified along with those of level-1 inter-
rupts in the Interrupt Option. Specifically, the following parameters are specified:
NINTERRUPT—Total number of level-1 plus high-priority interrupts.
INTTYPE[0..NINTERRUPT-1]—Interrupt type (level, edge, software, or internal)
for level-1 plus high-priority interrupts.
INTENABLE—Interrupt-enable mask for level-1 plus high-priority interrupts.
Nevertheless, high-priority interrupts specified in the Interrupt Option are not operational
without implementation of the High-Priority Interrupt Option.
Prerequisites: Exception Option (page 82)
Incompatible options: None
Table 4–69 through Table 4–72 show this option’s architectural additions.
Interrupt types (INTTYPE in Table 4–70) can be any of the values listed in Table 4–73.
The column labeled “Priority” shows the possible range of priorities for the interrupt type.
The column labeled “Pin” indicates whether there is an Xtensa core pin associated with
the interrupt, while the column labeled “Bit” indicates whether or not there is a bit in the
INTERRUPT and INTENABLE Special Registers corresponding to the interrupt. The last
two columns indicate how the interrupt may be set and how it may be cleared.
Software can manipulate the interrupt-enable bits (INTENABLE register) and then set
PS.INTLEVEL back to 0 to re-enable other interrupts, and thereby create arbitrary prior-
itizations. This is illustrated by the following C++ code:
class Interrupt {
public:
uint32_t bit;
void handler();
};
class Level1Interrupt {
struct InterruptGroup {
} priority[NPRIORITY];
public:
void handler();
};
void
Level1Interrupt::handler ()
uint p;
if (p == 0)
return;
// PS.INTLEVEL are both written and both used in the same pipe stages
do {
i = priority[p].intlist.end(); i++) {
// interrupt i is asserted
break;
// check if any more priority p interrupts arrived while we were servicing the previous batch
interrupts = rsr(INTERRUPT);
With respect to level-1 interrupts, the processor takes an interrupt when any level-1 in-
terrupt, i, satisfies:
The process of taking an interrupt does not clear the interrupt request. The process
does set PS.EXCM to 1, which disables level-1 interrupts in the interrupt handler. Typi-
cally, PS.EXCM is reset to 0 by the handler, after it has set up the stack frame and
masked the interrupt. This allows other level-1 interrupts to be serviced. For level-sensi-
tive interrupts, the handler must cause the source of the interrupt to deassert its interrupt
request before re-enabling the interrupt. For edge-triggered interrupts or software inter-
rupts, the handler clears the interrupt condition by writing to the INTCLEAR register.
The WAITI instruction sets the current interrupt level in the PS.INTLEVEL register. In
some implementations it also powers down the processor’s logic, and waits for an inter-
rupt. After executing the interrupt handler, execution continues with the instruction fol-
lowing the WAITI.
The INTENABLE register and the software and edge-triggered bits of the INTERRUPT
register are undefined after processor reset.
The RSIL instruction reads the PS register and sets the interrupt level. It is typically
used as follows:
Certain aspects of high-priority interrupts are specified along with those of level-1 inter-
rupts in the Interrupt Option, including the total number of level-1 plus high-priority inter-
rupts (NINTERRUPT), the interrupt type for level-1 plus high-priority interrupts
(INTTYPE), the interrupt-enable mask for level-1 plus high-priority interrupts
(INTENABLE), and the interrupt-request register for level-1 plus high-priority interrupts
(INTERRUPT).
Prerequisites: Interrupt Option (page 100)
Incompatible options: None
Table 4–74 through Table 4–76 show this option’s architectural additions.
The total number of level-1 plus high-priority interrupts (NINTERRUPT) and the interrupt
type for level-1 plus high-priority interrupts (INTTYPE) are specified in Table 4–70 on
page 101. The type of each high-priority interrupt level may be edge-triggered, level-
sensitive, timer, write-error, or software.
The interrupt-enable mask for level-1 plus high-priority interrupts (INTENABLE) and the
interrupt-request register for level-1 plus high-priority interrupts (INTERRUPT) are speci-
fied in Table 4–71 on page 101.
The total number of interrupt levels is NLEVEL+NNMI (see Table 4–74). Specific interrupt
numbers are assigned interrupt levels using the LEVEL parameter in Table 4–74. A non-
maskable interrupt may be configured with the NNMI parameter in Table 4–74. The non-
maskable interrupt signal, if implemented, will be edge-triggered. Unlike other edge-trig-
gered interrupts, there is no need to reset the NMI interrupt by writing to INTCLEAR.
Each high-priority interrupt level has three registers used to save processor state, as
shown in Table 4–75. The processor sets EPC[i] and EPS[i] when the interrupt is tak-
en. EXCSAVE[i] exists for software. The RFI instruction reverses the interrupt process,
restoring processor state from EPC[i] and EPS[i].
The number of high-priority interrupt levels is expected to be small, due to the cost of
providing separate exception-state registers for each level. Interrupt numbers that share
level 1 are not limited to a single priority, because software can manipulate the interrupt-
enables bits (INTENABLE register) to create arbitrary prioritizations.
where level[i] is the configured interrupt level of interrupt number i. Each level of
high-priority interrupt has its own interrupt vector (InterruptVector in Table 4–74).
Interrupt numbers that share a level (and associated vector) can read the INTERRUPT
register (and INTENABLE) with the RSR instruction to determine which interrupt(s) raised
the exception. The non-maskable interrupt (NMI), if implemented, is taken regardless of
the current interrupt level (CINTLEVEL) or of INTENABLE.
The value of CINTLEVEL is set to at least EXCMLEVEL whenever PS.EXCM=1. Thus, all
interrupts at level EXCMLEVEL and below are masked during the time PS.EXCM=1. This
is done to allow high-level language coding with the Windowed Register Option of inter-
rupt handlers for interrupts whose level is not greater than EXCMLEVEL. High-priority in-
terrupts with levels at or below EXCMLEVEL are often called medium-priority interrupts.
The interrupt latency is somewhat lower for levels greater than EXCMLEVEL, but han-
dlers are more flexible for those whose level is not greater than EXCMLEVEL.
There are other conditions besides those in this section that can postpone the taking of
an interrupt. For more descriptions on these, refer to a specific Xtensa processor data
book.
The example below checks for interrupts. This is the checkInterrupts() procedure
called in the code example shown in Section 3.5.4 “Instruction Fetch” on page 29. The
procedure itself checks for interrupts and takes the highest priority interrupt that is pend-
ing.
For NMI level interrupts, the no masking is done, but the edge sensor (made from
NMIinput and lastNMIinput) is explicitly included to avoid repeating the NMI every
cycle.
procedure checkInterrupts()
if chkinterrupt(NLEVEL+NNMI) then
takeinterrupt[NLEVEL+NNMI]
elseif chkinterrupt(NLEVEL+NNMI-1) then
.
.
.
elseif chkinterrupt(2) then
takeinterrupt[2]
elseif chkinterrupt(1) then
Exception (Level1InterruptCause)
endif
endprocedure checkInterrupts
function chkinterrupt(level)
function takeinterrupt(level)
EPC[level] ← PC
EPS[level] ← PS
PC ← InterruptVector[level]
PS.INTLEVEL ← level
PS.EXCM ← 1
endfunction takeinterrupt
The Timer Interrupt Option is an in-core peripheral option for Xtensa processors. The
Timer Interrupt Option can be used to generate periodic interrupts from a 32-bit counter
and up to three 32-bit comparators. One counter period typically represents a number of
seconds of elapsed time, depending on the clock rate at which the processor is config-
ured.
Prerequisites: Interrupt Option (page 100)
Incompatible options: None
Table 4–77 and Table 4–78 show this option’s architectural additions.
For most applications, only one CCOMPARE register is required, because it can easily be
shared for multiple uses. Applications that require a greater range of counting than that
provided by the 32-bit CCOMPARE register can maintain a 64-bit cycle count and com-
pare the upper bits in software.
This subsection describes general characteristics of caches that are referred to in multi-
ple later subsections about specific cache options.
In the cache documentation a “line” is the smallest unit of data that can be moved be-
tween the cache and other parts of the system. If the cache is “direct-mapped,” each
byte of memory may be placed in only one position in the cache. In a direct-mapped
cache, the “index” refers to the portion of the address that is necessary to identify the
cache line containing the access.
A cache is “set-associative” if there is more than one location in the cache into which
any given line may be placed. It is “N-way set-associative” if there are N locations into
which any given line may be placed. The set of all locations into which one line may be
placed is called a “set” and the “index” refers to the portion of the address that is neces-
sary to identify the set containing the access. The various locations within the set that
are capable of containing a line are called the “ways” of the set. And the union of the Nth
way of each set of the cache is the Nth “way” of the cache.
For example, a 4-way set-associative, 16k-byte cache with a 32-byte line size contains
512 lines. There are 128 sets of 4 lines each. The index is a 7-bit value that would most
likely consist of Address<11:5> and is used to determine what set contains the line. The
cache consists of 4 ways, each of which is 4k-bytes in size. A set represents 128 bytes
of storage made up of four lines of 32 bytes each.
Figure 4–14 shows the instruction- and data-cache tag format for Xtensa. The number of
bits in the tag is a configuration parameter. So that all lines may be differentiated, the tag
field must always be at least 32−log2(CacheBytes/CacheWayCount) bits wide. If
an MMU with pages smaller than a way of the cache is used, the tag field must also be
at least 32−log2(MinPageSize) bits wide. The actual tag field size is the maximum of
these two values. The bits used in the tag field are the upper bits of the virtual address
left justified in the register (the most significant bit of the register represents the most
significant bit of the virtual address, bit 31). For example:
A 16 kB direct-mapped cache would have an 18-bit tag field.
A 16 kB 2-way associative cache would have a 19-bit tag field.
A 16 kB 2-way associative cache in conjunction with an MMU with a 4kB minimum
page size would have a 20-bit tag field.
The V bit is the line valid bit; 0 → invalid, 1 → valid. The three flag bits exist only for cer-
tain cache configurations. Any of the flag bits in Figure 4–14 not used in a particular con-
figuration are reserved for future use and writing nonzero values to them gives unde-
fined behavior. If the cache is set-associative, then bit[1] is the F bit and is used for
cache miss refill way selection. If the cache is a data cache with writeback functionality,
then the lowest remaining bit is the D bit, or dirty bit, and is used to signify whether the
cache contains a value more recent than its backing store and must be written back. If
the Index Lock Option is selected for that cache, the lowest remaining bit is the L bit, or
lock bit, and is used to signify whether or not the line is locked and may not be re-
placed.1
31 4 3 2 1 0
n 28-n 3 1
Figure 4–14. Instruction and Data Cache Tag Format for Xtensa
There are two types of cache prefetch instructions. Normal prefetch instructions make
no change in the architecturally visible state but simply attempt to move cache lines
closer to the processor core. Any exception that might be raised causes the instruction
to become a NOP rather than actually raising an exception. This allows prefetch instruc-
tions to be used without penalty in places where their addresses may not represent legal
memory locations.
IPF attempts to move cache lines to the instruction cache. DPFR, DPFRO, DPFW, and
DPFWO attempt to move cache lines to the data cache. The differences are that the *R*
versions indicate that a write is not expected to the location in the immediate future while
the *W* versions indicate that a write to the location is likely in the near future. The *O
versions indicate that the most likely behavior is that the location is accessed in the near
future, but that it is not worth keeping after that access as another access is not expect-
ed. DPFWO indicates that either a write or a read followed by a write is expected soon.
The *O versions may be placed in different cache ways or kept in a separate buffer in
some implementations.
The second type of prefetch instructions, prefetch and lock instructions, are only avail-
able under their respective Cache Index Lock Options. They also do not change the op-
eration of memory loads and stores and they affect only cache tag state, which affects
only future invalidation or line replacement operations on these lines. They are heavy-
weight operations and, unlike normal prefetch instructions, are only expected to be exe-
cuted by code that sets up the caches for best performance.
The functions iprefetch and dprefetch are described below. Because they modify
no architectural state, they are described only by comments.
1. Note that the three flag bits are added sequentially from the right. The bits that exist are always contiguous with each other and with the V bit on
the right. For the instruction cache, the valid combinations are 0-L-F, 0-0-F, and 0-0-0 because the instruction cache cannot be writeback and the
Index Lock Option is only available for set-associative caches. For the data cache, the valid combinations are 0-L-F, 0-0-F, 0-0-0, L-D-F, 0-D-F, and
0-0-D, which are the same three with and without the dirty bit inserted in its order.
if lock then
else
-- no exception raised
-- try to move the line specified by vAddr/pAddr into the instruction cache
endif
endfunction iprefetch
if lock then
-- no exception raised
if once then
else
-- try to move the line specified by vAddr/pAddr into the data cache
endif
else
-- no exception raised
if once then
else
-- try to move the line specified by vAddr/pAddr into the data cache
endif
endif
endfunction dprefetch
The Instruction Cache Option adds on-chip first-level instruction cache. The Instruction
Cache Option also adds a few new instructions for prefetching and invalidation.
Prerequisites: Processor Interface Option (page 194)
Incompatible options: None
Table 4–79 through Table 4–80 show this option’s architectural additions.
See Section 5.7 “Caches and Local Memories” on page 240 for more information about
synchronizations required when using the instruction cache.
The Instruction Cache Test Option is currently added to every processor that has an In-
struction Cache Option; therefore, it is not actually a separate option. It adds instructions
capable of reading and writing the tag and data of the instruction cache. These instruc-
tions are intended to be used in testing the instruction cache, rather than in operational
code and may not be implemented in a binary compatible way in all future processors.
Prerequisites: Processor Interface Option (page 194) and Instruction Cache Option
(page 115)
Incompatible options: None
The instruction-cache access instructions must be fetched from a region of memory that
has the bypass attribute. Use an ISYNC instruction before transferring back to cached
instruction space. See Section 5.7 “Caches and Local Memories” for more information
about synchronizations required when using the instruction cache.
The Instruction Cache Index Lock Option adds the capability of individually locking each
line of the instruction cache. This option may only be added to a cache, which has two or
more ways. One bit is added to the instruction cache tag RAM format. The Instruction
Cache Index Lock Option also adds new instructions for locking and unlocking lines.
Prerequisites: Processor Interface Option (page 194) and Instruction Cache Option
(page 115)
Incompatible options: None
See Section 5.7 “Caches and Local Memories” for more information about synchroniza-
tions required when using the instruction cache.
The Data Cache Option adds on-chip first-level data cache. It supports prefetching, writ-
ing back, and invalidation.
Table 4–83 and Table 4–84 show this option’s architectural additions.
See Section 5.7 “Caches and Local Memories” for more information about synchroniza-
tions required when using the data cache.
If IsWriteback, there is a dirty bit added to the data cache tag RAM format. The at-
tributes described in Section 4.6.3.3 and Section 4.6.5.10 are then capable of setting a
region of memory to be either write-back or write-through. If not IsWriteback, both at-
tribute settings result in write-through semantics.
When a region of memory is marked write-back, any store that hits in the cache writes
only the cache (setting the dirty bit, if it is not already set) and does not send a write on
the PIF. Any store that does not hit in the cache causes a miss. When the line is filled,
the semantics of a cache hit described above are followed. If a dirty line is evicted to use
the space in the cache, the entire line will be written on the PIF. The DHWB, DHWBI, DI-
WB, and DIWBI instructions will also write back a line if it is marked dirty.
The Data Cache Test Option is currently added to every processor, which has a Data
Cache Option and therefore, is not actually a separate option. It adds instructions capa-
ble of reading and writing the tag of the data cache. These instructions are intended to
be used in testing the data cache, rather than in operational code and may not be imple-
mented in a binary compatible way in all future processors.
Prerequisites: Processor Interface Option (page 194) and Data Cache Option (page
118)
Incompatible options: None
There are no instructions to access the data-cache data array. Normal loads and stores
can be used for this purpose with the isolate attribute.
See Section 5.7 “Caches and Local Memories” for more information about synchroniza-
tions required when using the data cache.
The Data Cache Index Lock Option adds the capability of individually locking each line
of the data cache. One bit is added to the data cache tag RAM format. The Data Cache
Index Lock Option also adds new instructions for locking and unlocking lines.
Prerequisites: Processor Interface Option (page 194) and Data Cache Option (page
118)
Incompatible options: None
See Section 5.7 “Caches and Local Memories” for more information about synchroniza-
tions required when using the data cache.
The RAM and ROM options both provide internal memories that are part of the proces-
sor’s address space and are accessed with the same timing as cache. These memories
should not be confused with system RAM and ROM located outside of the processor,
which are often larger, and may be used for both instructions and data, and shared be-
tween processors and other processing elements.
The basic configuration parameters are the size and base address of the memory. It is
possible to configure cache, RAM, and ROM independently for both instruction and da-
ta, however some implementations may require an increased clock period if multiple in-
struction or multiple data memories are specified, or if the memory sizes are large. It is
sometimes appropriate for the system designer to instead place RAMs and ROMs exter-
nal to the processor and access these through the cache.
Every Instruction and Data RAM and ROM is always required to be naturally aligned
(aligned on a boundary of a power of two which is equal to or larger than the size of the
RAM/ROM) in physical address space. The mapping from virtual address space to phys-
ical address space must have the property that the Index bits of the RAM/ROM are iden-
tity mapped. This is a slightly less restrictive condition than requiring that the RAM/ROM
must be contiguous and naturally aligned in virtual address space but this latter condi-
tion will always meet the requirement.
Instruction RAM can be referenced as data only by the L32I, L32R and S32I instruc-
tions and Instruction ROM referenced as data only by the L32I and L32R instructions.
This functionality is provided for initialization and test purposes, for which performance
is not critical, so these operations may be significantly slower on some Xtensa imple-
mentations. Most Xtensa code makes extensive use of L32R instructions, which load
values from a location relative to the current PC. For this to perform well for code located
in an instruction RAM or ROM, some sort of data memory (either internal or external)
should be located within the 256 KB range of the L32R instruction or else the Extended
L32R Option should be used.
Table 4–87 summarizes the restrictions on instruction and data RAM and ROM access.
The exceptions listed assume no memory protection exception has already been raised
on the access.
Table 4–88 shows this option’s configuration parameters. There are no processor state
or instruction additions.
Instruction RAM may be accessed as data using the L32I, L32R, and S32I instruc-
tions. The operation of other loads and stores on InstRAM addresses is not defined.
S32I is useful for copying code into the InstRAM; L32I is useful for diagnostic testing of
InstRAM, and L32R allows constants to be loaded from InstRAM if no data memory is
within range. While L32I, L32R, and S32I to InstRAM are defined, on many implemen-
tations these accesses are much slower than references to data RAM, ROM, or cache,
and thus the use of InstRAM for data storage is not recommended.
Table 4–89 shows this option’s configuration parameters. There are no processor state
or instruction additions.
Instruction ROM may be accessed as data using the L32I and L32R instructions. The
operation of other loads on InstROM addresses is not defined. L32I is useful for diag-
nostic testing of InstROM, and L32R allows constants to be loaded from InstROM if no
data memory is within range. While L32I and L32R to InstROM are defined, on many
implementations these accesses are much slower than references to data RAM, ROM,
or cache, and thus the use of InstROM for data storage is not recommended.
This option provides an internal, read-write data memory. It is typically useful as the only
processor data store (no data cache) when all of the data for an application will fit in a
small memory, or as an additional data store in parallel with the cache for data that must
be constant access time for performance reasons.
Prerequisites: None
Incompatible options: None
Table 4–90 shows this option’s configuration parameters. There are no processor state
or instruction additions.
In the absence of the Extended L32R Option it is recommended that processors with
data RAM or ROM and no data cache be configured with the DataRAMPAddr or
DataROMPAddr below the lowest instruction address and above the highest instruction
address minus 256 KB, so that the L32R literals can be stored in RAM or ROM for fast
access. The processor will fetch L32R literals from the instruction RAM, or ROM, but in
many implementations several cycles are required for the fetch, making the use of this
feature undesirable. The Extended L32R Option allows less restricted placement.
This option provides an internal, read-only data memory. It is typically useful as an addi-
tional data store in parallel with the cache for data that must be constant access time for
performance reasons.
Prerequisites: None
Incompatible options: None
Table 4–91 shows this option’s configuration parameters. There are no processor state
or instruction additions.
The XLMI Option, or Xtensa Local Memory Interface Option, allows the attachment of
hardware other than caches, RAMs, and ROMs into the pipeline of the processor rather
than on the processor interface bus. The advantage of the XLMI is that the latency is
lower. The disadvantage is that speculation must be explicitly allowed for on loads. The
XLMI port contains signals that inform external devices after the fact concerning whether
a load was or was not speculative. Stores are never speculative. Refer to a specific
Xtensa processor data book for more detail.
Prerequisites: None
Incompatible options: None
Instructions may not be fetched from an XLMI interface. The virtual and physical ad-
dresses of the entire XLMI region must be identical in all bits.
Table 4–92 shows this option’s configuration parameters. There are no processor state
or instruction additions.
The Hardware Alignment Option adds hardware to the processor which allows loads and
stores to work correctly at any arbitrary alignment. It does this by making multiple ac-
cesses where necessary and combining the results. Unaligned accesses are still slower
than aligned accesses, but this option is more efficient than the Unaligned Exception
Option with software handler. In addition, the Hardware Alignment Option will work in sit-
uations where a software handler is difficult to write (for example, a load and operate in-
struction).
Prerequisites: Unaligned Exception Option (page 99)
Incompatible options: None
The Hardware Alignment Option builds on the Unaligned Exception Option so that al-
most all potential LoadStoreAlignmentCause exceptions are handled transparently
by hardware instead. A few situations, which are never expected to happen in real soft-
ware, still raise a LoadStoreAlignmentCause exception. In order to properly handle
all TLB misses and other exceptions, the priority of the LoadStoreAlignmentCause
exception is lower when the Hardware Alignment Option is present than when it is not.
Exception priorities are listed in Section 4.4.1.11.
The Memory ECC/Parity Option allows the local memories and caches of Xtensa pro-
cessors to be protected against errors by either parity or error correcting code (ECC). It
does not affect the processor interface and system memories must maintain their own
error detection and correction. Local memories must be wide enough to contain the ad-
ditional bits required. The generation and checking of parity or ECC is done in the
Xtensa core through a combination of hardware and software mechanisms.
Prerequisites: Exception Option (page 82)
Incompatible options: None
Each memory may be protected or not protected individually. All protected instruction
memories must use a single protection type (parity or ECC). Likewise, all protected data
memories must use a single protection type. For parity protection, data memories re-
quire one additional bit per byte while instruction memories require one additional bit per
four bytes and cache tags require one additional bit per tag. For ECC protection, instruc-
tion memories require 7 additional bits per 32-bit word, data memories require 5 addi-
tional bits per byte, and cache tags require 7 additional bits per tag.
The core computes parity or ECC bits on every store without doing a read-modify-write.
On every load or instruction fetch, these bits are checked and an exception is raised for
parity errors or for uncorrectable ECC errors. For correctable errors, a control bit in the
memory error status register (Table 4–94) indicates whether to raise an exception or
simply correct the value to be used (but not the value in memory) and continue. In addi-
tion, correctable ECC errors assert an output pin which may be used as an interrupt. Im-
plementations may or may not implement hardware correction. If they do not implement
it, the exception is always raised.
Table 4–93 through Table 4–95 show this option’s architectural additions.
Three registers are used to maintain information about a memory error. They are updat-
ed for memory errors which do not raise an exception, as well as those which do. The
memory error status register (MESR), shown in Figure 4–15 with further description in
Table 4–98, contains control bits that control the operation of memory errors and status
bits that hold information about memory errors that have occurred.
Under normal operation, check bits are always calculated and written to local memories.
When ECC is enabled, an uncorrectable error, or a correctable error for which the
MESR.DataExc or MESR.InstExc bit is set, will raise an exception whenever it is en-
countered during either a load or a dirty castout. Inbound PIF operations return an error
when appropriate but the error will not be noted by the local processor. Correctable er-
rors during a dirty castout when MESR.DataExc is clear may, in some implementations,
correct the error on the fly without setting MESR.RCE or associated status.
When ECC is enabled and either the MESR.DataExc bit or the MESR.InstExc bit is
clear or the MESR.MemE bit is set, hardware may be able to correct an error without rais-
ing an exception. This may cause MESR.RCE (along with many other fields),
MESR.DLCE, or MESR.ILCE to be set by hardware at an arbitrary time.
In addition, an external pin reflects the state of MESR.RCE and can be connected to an
interrupt input on the Xtensa processor itself or on another processor. This interrupt may
be at a much lower priority than the memory error exception handler, but it can still re-
pair the memory itself and/or log the error much as the memory error exception handler
might. MESR.RCE must be cleared by software to return the external pin to zero and to
re-arm the mechanism for recording correctable errors.
31 30 29 28 27 24 23 22 21 20 19 18 17 16 15 12 11 10 9 8 7 6 5 4 3 2 1 0
DataExc
ErrEnab
ErrTest
MemE
DLCE
ILCE
DME
RCE
2 2 4 2 2 2 2 4 1 1 1 1 1 1 1 1 2 1 1
The memory error check register (MECR), shown in Figure 4–16 with further description
in Table 4–97, contains syndrome bits that indicate what error occurred. For data memo-
ries, all four check fields are used so that all bytes may be covered. For instruction
memories or for cache tags, only the Check 0 field is used.
When the ErrEnab bit of the MESR register is set and the RCE or MemE bit of the MESR
register is turned on, this register contains error syndromes. For parity memories, the er-
ror syndrome is ’1’ corresponding to a parity error and ’0’ corresponding to no parity er-
ror. For ECC memories, the error syndrome is a set of bits equal in length to the number
of check bits associated with that portion of memory. The bits are all zero where there is
no error. Non-zero values give more information about which bit or bits are in error. The
exact encoding depends on the implementation. See the Xtensa Microprocessor Data
Book for more information on the encoding.
When the ErrTest bit of the MESR register is set, MECR is loaded by every L32I,
L32I.N, LICT, LICW, and LDCT instruction with the actual check bits which have been
read from memory. When the ErrTest bit of the MESR register is set, the fields of MECR
are used by the S32I, S32I.N, SICT, SICW, and SDCT instructions to write the memory
check bits. Operation of other memory access instructions is not defined when ErrTest
is set. Operation is not defined if both ErrEnab and ErrTest are set.
Error addresses are reported with reference to the 32-bit word containing the error re-
gardless of the size of the access and for all errors MEVADDR contains an address
aligned to 32-bits. For data memories, the check field(s) in MECR corresponding to the
damaged byte(s) contains a non-zero syndrome. For tag memories and instruction
memories, the Check 0 field of MECR contains the syndrome for the entire word. Errors
in portions of the word not actually used by the access may or may not be reported in
MECR.
31 29 28 24 23 21 20 16 15 13 12 8 7 6 0
3 5 3 5 3 5 1 7
The memory error virtual address register (MEVADDR), shown in Figure 4–17, contains
address information regarding the location of the error. Table 4–98 details its contents as
a function of two fields of the MESR register. For errors in cache tags and for errors in
castout data, MEVADDR contains only index information. Along with the Way Number
field in MESR, this allows the incorrect memory bits to be located. For errors in instruc-
tions or data being accessed, MEVADDR contains the full virtual address used by the in-
struction. Along with other status information, MEVADDR is written when the ErrEnab bit
of the MESR register is set and the RCE or MemE bit of the MESR register is turned on.
31 0
32
Three of the new registers created by this option are used in order to be able to take a
memory error exception at any time and return. As an exception, memory error cannot
be masked except by the MESR.ErrEnab bit. Whenever the exception is taken, the PC
of the instruction taking the error is saved in the MEPC register, the PS register is saved
in the MEPS register, and the MESAVE register is available for software use in the excep-
tion handler.
When an actual memory error exception is taken, the MEPC and MEPS registers are load-
ed with the original values of PC and PS, and then PS.INTLEVEL is raised to NLEVEL so
that all interrupts except NMI are masked and the PS.EXCM bit is set so that an ordinary
exception will cause a double exception. When hardware corrects a correctable memory
error, these actions are not taken, allowing memory error corrections even in the memo-
ry error exception handler.
A memory error exception may be taken at any time. This means that, even without
hardware correction, a memory error can be handled any time except during a memory
error handler. With hardware correction, only an uncorrectable memory error taken dur-
ing a handler for another uncorrectable memory error is fatal.
procedure MemoryError
return if !MESR.ErrEnab
exc ← ParityError | UncorrectableECCError
exc ← 1 if !MESR.MemE & MESR.InsExc & AccessType = IFetch
exc ← 1 if !MESR.MemE & MESR.DatExc & AccessType ≠ IFetch
MESR.ILCE ← 1 if exc & MESR.RCE & MESR.AccessType = IFetch
MESR.DLCE ← 1 if exc & MESR.RCE & MESR.AccessType ≠ IFetch
MESR.ILCE ← 1 if !exc & MESR.RCE & AccessType = IFetch
MESR.DLCE ← 1 if !exc & MESR.RCE & AccessType ≠ IFetch
Section 4.6.1.1 gives an overview of the basic memory translation scheme used in
Xtensa processors. Section 4.6.1.2 gives an overview of the basic memory protection
scheme used in Xtensa processors, and Section 4.6.1.3 gives an overview of the con-
cept of attributes. These subsections take a broader view of the overall process and in-
dicate the direction future memory protection and translation options may take.
This subsection presents an overview of the thinking behind the memory translation in
the available options. It also provides insight into the kinds of extensions that are likely
in the future.
The available memory protection and translations options that support virtual-to-physical
address translation do so via an instruction TLB and a data TLB. (“TLB” was originally
an acronym for translation lookaside buffer, but this meaning is no longer entirely accu-
rate; in this document TLB simply means the translation hardware.) These two hardware
structures may, in some configurations, act as translation caches that are refilled by
hardware from a common page table structure in memory. In other configurations, a TLB
may be self-sufficient for its translations, and no page tables are required.
A TLB consists of several entries, each of which maps one page (the page size may
vary with each entry). Virtual-to-physical address translation consists of searching the
TLB for an entry that matches the most significant bits of the virtual address and replac-
ing those bits with bits from the TLB entry. The least significant bits of the virtual address
are identical between the virtual and physical addresses. The translation input and out-
put are called the virtual page number (VPN) and the physical page number (PPN) re-
spectively. The TLB search also involves matching the address space identifier (ASID)
bits of the TLB entry to one of the current ASIDs stored in the RASID register (more on
this below). The number of bits not translated is determined by the page size, which can
be dynamically programmed from a set of configuration specified values. The TLB entry
also supplies some attribute bits for the page, including bits that determine the cache-
ability of the page’s data, whether it is writable or not, and so forth. This is illustrated in
Figure 4–18.
It is illegal for more than one TLB entry to match both the virtual address and the ASID.
This is true even if the entries have different ASIDs which match at different ring levels.
Software is responsible for making sure the address range of all TLB entries visible ac-
cording to the ASID values in the RASID register never overlap. Implementations may
detect this situation and take a MultiHit exception in this situation to aid in debugging.
The instruction and data TLBs can be configured independently for most parameters,
which is appropriate because the instruction and data references of processors can
have fairly different requirements, and in some systems additional flexibility may be ap-
propriate on one but not the other. However, when the two TLBs both refill from the com-
mon memory page table, the associated parameters are shared.
Virtual Address
ASID3
ASID2 VABITS-1 0
RASID
ASID1
VPN Page Index
ASID0
TLB
PABITS-1 0
The TLBs are N-way set-associative structures with heterogeneous “ways” and a config-
urable N. Each way has its own parameters, such as the number of entries, page
size(s), constant or variable virtual address, and constant or variable physical address
and attributes. It is the ability to specify constant translations in some or all of the ways
that allows Xtensa’s TLBs to span smoothly from a fixed memory map to a fully pro-
grammable one. Fully or partially constant entries can be converted to logic gates in the
TLB at significantly lower cost than a run-time programmable way. In addition, even pro-
cessors with generally programmable MMUs often have a few hardwired translations.
Xtensa can easily represent these hardwired translations with its constant TLB entries.
Xtensa actually requires a few constant TLB entries to provide translation in some cir-
cumstances, such as at reset and during exception handling.
The virtual address input to the TLBs is actually the catenation of an address space
identifier (ASID) specified in a processor register with the 32-bit virtual address from the
fetch, load, or store address calculation. ASIDs allow software to change the address
space seen by the processor (for example, on a context switch) with a simple register
write without changing the TLB contents. The TLB stores an ASID with each entry, and
so can simultaneously hold translations for multiple address spaces. The number of
ASID bits is configurable. ASIDs are also an integral part of protection, as they specify
the accessibility of memory by the processor at different privilege levels, as described in
the next section.
Xtensa TLBs do not have a separate valid bit in each entry. Instead, a reserved ASID
value of 0 is used to indicate an invalid entry. This can be viewed as saving a bit, or as
almost doubling the number of ASIDs for the same number of hardware bits stored in a
TLB entry.
Each way of a TLB is configured with a list of page sizes (expressed as the number of
bits in a page index). If the list has one element, the page size for that way is fixed. If the
list has more than one element, the page size of the way may be varied at runtime via
the ITLBCFG or DTLBCFG registers. When AutoRefill ways have programmable page
size, the PTE has a page size field (the value is an index into the PTEPageSizes con-
figuration parameter), and hardware refill restricts the refill way selection to ways pro-
grammed with a page size matching the page size in the PTE. When looking up an ad-
dress in the TLB, each way’s page size determines which bits are used to select one of
the way’s entries for comparison: vAddrP+log2(IndexCount)-1..P is the way index where P is
the number of bits configured or programmed for the way page size.
Many processors implement two levels of privilege, often called kernel and user, so that
the most privileged code need not depend on the correctness of less privileged code.
The operating system kernel has access to the entire processor, but disables access to
certain features while application code runs to prevent the application from accessing or
corrupting the kernel or other applications. This mechanism facilitates debugging and
improves system reliability.
Some processors implement multiple levels of decreasing privilege, called rings, often
with elaborate mechanisms for switching between rings. The Xtensa processor provides
a configurable number of rings (RingCount), but without the elaborate ring-to-ring tran-
sition mechanisms. When configured with two rings, it provides the common kernel/user
modes of operation, with Ring 0 being kernel and Ring 1 being user. With three or four
rings configured, the Xtensa processor provides the same functionality as more ad-
vanced processors, but with the requirement that ring-to-ring transitions must be provid-
ed by Ring 0 (kernel) software.
Without the MMU Option, or with the MMU Option and RingCount = 1, the Xtensa pro-
cessor has a single level of privilege, and all instructions are always available.
With RingCount > 1, software executing with CRING = 0 (see Table 4–63 on page 87
and the description of PS.EXCM) is able to execute all Xtensa instructions; other rings
may only execute non-privileged instructions. The only distinction between the rings
greater than zero is those created by software in the virtual-to-physical translations in
the page table. The name “ring” is derived from an accessibility diagram for a single pro-
cess such as that shown in Figure 4–19. At Ring 0 (that is, when CRING = 0), the pro-
cessor can access all of the current process’ pages (that is, Ring 0 to RingCount-1
pages). At Ring 1 it can access all Ring 1 to RingCount-1 pages. Thus, when the pro-
cessor is executing with Ring 1 privileges, its address space is a subset of that at Ring 0
privilege, as Figure 4–19 illustrates. This concentric nesting of privilege levels continues
to ring
RingCount-1, which can access only ring RingCount-1 pages.
It is illegal for more than one TLB entry to match both the virtual address and the ASID.
This is true even if the entries have different ASIDs which match at different ring levels.
One ring’s mapping cannot not override another.
It is illegal for two or more TLB entries to match a virtual address, even if they are at dif-
ferent ring levels; one ring’s mapping cannot not override another.
Systems that require only traditional kernel/user privilege levels can, of course, config-
ure RingCount to be 2. However, rings can also be useful for sharing. Many operating
systems implement the notion of multiple threads sharing an address space, except for
a small number of per-thread pages. Such a system could use Ring 0 for the shared ker-
nel address space, Ring 1 for per-process kernel address space, Ring 2 for shared ap-
plication address space, and Ring 3 for per-thread application address space.
Ring 1
••
•
N-1
Each Xtensa ring has its own ASID. Ring 0’s ASID is hardwired to 1. The ASIDs for
Rings 1 to RingCount-1 are specified in the RASID register. The ASIDs for each ring
in RASID must be different. Each ASID has a single ring level, though there may be
many ASIDs at the same ring level (except Ring 0). This allows nested privileges with
sharing such as shown in Figure 4–20. The ring number of a page is not stored in the
TLB; only the ASID is stored. When a TLB is searched for a virtual address match, the
ASIDs of all rings specified in RASID are tried. The position of the matching ASID in
RASID gives the ring number of the page. If the page’s ring number is less than the pro-
cessor’s current ring number (CRING), then the access is denied with an exception (ei-
ther InstFetchPrivilegeCause or LoadStorePrivilegeCause, as appropriate).
Ring 0
Ring 1 Ring 1
•• •• ••
• • •
Why not store the ring number of the page in the TLB, and then use a single ASID for all
rings, instead of having an ASID per ring? Because the latter allows sharing of TLB en-
tries, and the former does not. For example, it is desirable at the very least to reuse the
same TLB entries for all kernel mapped addresses, instead of having the same PTEs
loaded into the TLB with different ASIDs. The Xtensa mechanism is more general than
adding a “global” bit to each entry (to ignore the ASID match) in that it allows finer gran-
ularity, as Figure 4–20 illustrates, not just all or nothing.
The kernel typically assigns ASIDs dynamically as it runs code in different address spac-
es. When no more ASIDs are available for a new address space, the kernel flushes the
Instruction and Data TLBs, and begins assigning ASIDs anew. For example, with
ASIDBits = 8 and RingCount = 2, a TLB flush need occur at most every 254 context
switches, if every context switch is to a new address space.
Note that CRING = 0 is the only requirement for privileged instructions to execute and
CRING is the only field that controls access to memory. The PS.UM bit is named User
Vector Mode and has nothing to do with privilege for either instructions or memory ac-
cess. It controls only which exception vector is taken for general exceptions.
Both page table entries (PTEs) and TLB entries store attribute bits that control whether
and how the processor accesses memory. The number of potential attributes required
by systems is large; to encode all the access capabilities required by any potential sys-
tem would make this field too big to fit into a 4-byte PTE. However, the subset of values
required for any particular system is usually much smaller. Each memory protection and
translation option has a set of attributes, each of which encodes a set of capabilities
from Table 4–99 for loads along with a set for stores and a set for instruction fetches.
More capabilities are likely to be added in future implementations.
The assignment of capabilities to the attribute field of PTEs may be done with only one
encoding for each distinct set of capabilities, or in such a way that each characteristic
has its own bit, or anything in between. Often, single bits are used for a valid bit and a
write-enable. For a valid bit, all of the attribute values with this bit zero would specify the
Invalid characteristic so that any access causes an InstFetchProhibitedCause,
LoadProhibitedCause, or StoreProhibitedCause exception, depending on the
type of access. Similarly for the write-enable bit, all attribute values with write-enable
zero would specify the Invalid characteristic to cause a StoreProhibitedCause
exception on any store.
For systems that implement demand paging, software requires a page dirty bit to indi-
cate that the page has been modified and must be written back to disk if it is replaced.
This may be provided by creating a write-enable bit as described above, and using it as
the per-page dirty bit. The first write to a clean (non-dirty) page causes a
StoreProhibitedCause exception. The exception handler checks one of the soft-
ware bits, which indicates whether the page is really writable or not; if it is, it then sets
the hardware write-enable bit in both the TLB and the page table, and continues execu-
tion.
All accesses to memory, whether to cache, local memories, XLMI, or PIF and whether
caused by instruction fetch, the instructions themselves, or hardware TLB refill, follow
certain steps. Following is a short description of these steps; each is discussed in more
detail in Section 4.6.2.1 through Section 4.6.2.6.
1. Choose the TLB: Determine from the instruction opcode or the reason for hard-
ware access, which TLB if any, is used for the access (see Section 4.6.2.1 on
page 146 for details).
2. Lookup in the TLB: In that TLB, find an entry whose virtual page number
matches the upper bits of the virtual address of the access and, for appropriate
options, whose ASID matches one of the entries in the RASID register. Exactly
one match is needed to continue beyond this point, although exceptions may be
handled and the memory access process restarted (see Section 4.6.2.2 on
page 147 for details).
3. Check the access rights: If the attribute is invalid or, for appropriate options, if
the ring corresponding the ASID matched in the RASID register is too low, raise
an exception. The operating system may, among other choices, modify the TLB
entries and retry the access (see Section 4.6.2.3 on page 148 for details).
4. Direct the access to local memory: If the physical address of the access
matches an instruction RAM or ROM, a data RAM or ROM, or an XLMI port then
direct the access to that local memory or XLMI. An exception is possible at this
stage for certain conditions, such as attempting to write to a ROM (see
Section 4.6.2.4 on page 148 for details).
5. Direct the access to PIF: For the given cache configuration and using the at-
tribute, determine whether to execute the required access on the processor in-
terface bus (PIF) and make that access if necessary (see Section 4.6.2.5 on
page 150 for details).
6. Direct the access to cache: Using the cache that corresponds to the TLB in
Step 1 above, look up the memory location in the cache, using the value if it is
there. If not, fill the cache from the PIF and then do the access (see
Section 4.6.2.6 on page 150 for details).
Logically, the steps are done in order. The TLB lookup is done first (in steps 1 through 3
above) and the memory access afterwards (in steps 4 through 6 above). For perfor-
mance reasons, they are actually done in parallel. This has two consequences:
1. First, the virtual and physical addresses of an access to an XLMI port must be iden-
tical so that the full address can be provided at the desired time.
2. Second, for all other local memory accesses and cacheable addresses, the index
bits of the cache or local memory must be the same in both virtual and physical ad-
dress. This means that caches which contain ways larger than the smallest page
size in the system require “page coloring” as described in Section 4.6.1.1 on
page 139.
For local memories, the second consequence requires a similar restriction on how they
can be mapped. Note that local memories do not require that sequential virtual pages be
mapped to sequential physical pages, but only that each virtual page be mapped to a
physical page with which it shares the values of index bits.
For the purposes of understanding exceptions raised by memory accesses, all the steps
above are done sequentially and the first exception encountered takes priority over later
ones. For performance reasons, again, all steps are done in parallel and the results pri-
oritized afterward.
Several instructions do not actually address memory. They simply use the bits of an ad-
dress to access a cache and do something directly to it. The following groups of instruc-
tions have this property:
- III, IIU
- DII, DIU, DIWB, DIWBI
- LICT, SICT, LICW, SICW
- LDCT, SDCT
For each of these instructions, no TLB is accessed and the remainder of the steps are
not followed. No memory access exceptions are possible as the addresses are not really
addresses but only pointers to cache locations.
For the data accesses of instructions IHI, IHU, IPF, and IPFL, as well as all instruction
fetches, the instruction TLB is used for subsequent steps.
For the data accesses of all other instructions and for the hardware TLB refill accesses
(regardless of which TLB is being refilled) the data TLB is used for subsequent steps.
The above choices are reflected in Table 4–100 in the second column.
For compatibility the two TLBs should never give conflicting translations or protection at-
tributes for any access as future processors may implement them with only a single set
of entries.
Each TLB lookup takes a virtual address as an operand and produces a physical ad-
dress, a lookup ring, and attributes as a result. This process is described in more detail
in Section 4.6.1.1. Each way of the TLB is read using the appropriate address bits for
that way as index bits. For variable sized ways, the ITLBCFG or DTLBCFG register helps
determine which address bits are the index bits.
For options without ASIDs (Region Protection Option), a way matches the access if its
virtual page number (VPN) matches the VPN of the access. The lookup ring produced is
defined to be 0.
For options with ASIDs (MMU Option), a way matches the access if its Virtual Page
Number (VPN) matches the VPN of the access and the ASID of the way matches one of
the ASIDs in the RASID register. The lookup ring is determined by which ASID in the
RASID register is matched. Because the four entries in the RASID register are required
to be different and non-zero, the lookup ring is well determined.
There should not be a match for more than one of the ways. However, this condition cur-
rently raises an InstTLBMultiHitCause or a LoadStoreTLBMultiHitCause ex-
ception as a debugging aid. If two entries contain the same VPN, but different ASIDs,
they may co-exist in the TLB at the same time as long as the RASID never contains both
ASIDs at the same time.
If none of the ways match, options without auto-refill ways (Region Protection Option)
will raise an InstTLBMissCause or a LoadStoreTLBMissCause exception so that
system software can take appropriate action and possibly retry the access. Options with
auto-refill ways (MMU Option) will, automatically in hardware, use PTEVADDR to access
page tables in memory and replace an entry in one of the auto-refill ways. The access
will then be automatically retried. An error of any sort during the automatic refill process
If no exception is raised, the physical page number and attributes of the matching entry
along with the lookup ring defined above are the results of the lookup and the access
continues with the next step.
First, the lookup ring of the entry is checked against the ring of the access. The ring of
the access is usually CRING, but for L32E and S32E, for example, it is PS.RING instead.
If the lookup ring of the entry is smaller than the ring of the access, an
InstFetchPrivilegeCause or a LoadStorePrivilegeCause exception is raised.
This situation means that an instruction has attempted access to a region of memory at
a lower numbered ring than the one for which it has privilege.
Second, the attribute of the lookup is checked for validity. If the attribute is not valid, an
exception is raised. If the access chose the Instruction TLB in Section 4.6.2.1, it raises
an InstFetchProhibitedCause exception. If it chose the data TLB, it raises either a
LoadProhibitedCause exception or a StoreProhibitedCause exception, depend-
ing on whether it was a load or a store.
If no exception is raised, the access continues with the next step using the physical ad-
dress and the attribute (which is known to be valid for access, but may still affect how
caches are used).
The physical address of each access is compared to the address ranges of any instruc-
tion RAM, instruction ROM, data RAM, data ROM, or XLMI options that may exist in the
processor. Table 4–100 indicates what will happen in the case that an access initiated
by what is indicated in the Instruction column (which will use the TLB in the second col-
umn) if its address compares to an (abbreviated) option in one of the last six columns.
OK means the access is completed normally. NOP means the access is completed but
by its nature does nothing. IFE and LSE mean that an exception is raised. TLBI and
TLBD mean that an InstTLBMissCause or a LoadStoreTLBMissCause exception is
raised. Undef means the behavior is not defined.
Using the definition of guarded in Table 4–99, instruction-fetch accesses are never
guarded. Stores are always guarded. Loads to instruction RAM, instruction ROM, data
RAM, and data ROM are never guarded. These ports are assumed to be connected only
to devices with memory semantics so that no guarding is needed for loads. Loads to
XLMI are only guarded in the sense that the load will be retired only under the conditions
for a guarded access. For all these memories, assertion of the memory enable is no
guarantee that the load was needed.
If none of the comparisons produces a match, the access continues with the next step
using the physical address and the attribute.
The access is sent to the processor interface if any of the following is true:
The attribute indicates that the cache should be bypassed.
The chosen TLB in Section 4.6.2.1 and in Table 4–100 is the ITLB and the Instruc-
tion Cache Option is not configured.
The chosen TLB in Section 4.6.2.1 and in Table 4–100 is the DTLB and the Data
Cache Option is not configured.
Using the definition of guarded in Table 4–99 on page 144, instruction-fetch accesses to
the PIF are never guarded. Stores to the PIF are always guarded. Loads that are sent to
the PIF under this section (without being cached) are guarded if the attribute says that
they should be.
If the conditions of this section are not met, the access is cached and continues with the
next step using the physical address and the attribute.
The access is cached. The attribute determines how the cache operates, including the
possibility of a write-through to the PIF.
The concept of guarding cannot be carried out for loads through the cache. Extra bytes
have been loaded simply to fill the cache line and the line may have been filled long be-
fore the access. Inherently, the line is filled a different number of times than an access is
executed and the line may be invalidated or evicted at any time and refilled later. Cach-
ing should not be used on ranges of memory address where guarding is important.
The simplest of the options, the Region Protection Option, provides a protection field for
each of the eight 512 MB regions in the address space. The field can allow access to the
region and it can set caching characteristics for the region, such as whether or not the
cache is used and if it is write-through or write-back.
Prerequisites: Exception Option (page 82)
This simple option is built from the capabilities discussed in the introduction
(Section 4.6.1). It uses RingCount = 1, so the processor can always execute privileged
instructions. It sets ASIDBits to 0, which disables the ASID feature. The instruction
and data TLBs are programmed to each have one way of eight entries, and the VPNs
(virtual page numbers) and PPNs (physical page numbers) of these entries are constant
and hardwired to the identity map (that is, PPN = VPN). Only the attributes are not con-
stant; they are writable using the WITLB and WDTLB instructions.
Table 4–101 through Table 4–103 show this option’s architectural additions.
During normal operation when instructions and data are being accessed from memory,
only lookups are being done in the TLBs. For maintenance of the TLBs, however, the
entries in the TLBs are accessed by the instructions in Table 4–103. Note that unused
bits at Bit 12 and above are ignored on write, and zero on read, so that those bits may
simply contain the address for access to all ways of both TLBs. Unused bits at Bit 11 and
below are required to be zero on write and undefined on read for forward compatibility.
The format of the as register used in all instructions in the table is shown in Figure 4–21.
The upper three bits are used as an index among the TLB entries just as they would be
when addressing memory. They are the Virtual Page Number (VPN) or upper three bits
of address. The remaining bits are ignored.
31 29 28 0
VPN Ignored
3 29
Figure 4–21. Region Protection Option Addressing (as) Format for WxTLB, RxTLB1, & PxTLB
The WITLB and WDTLB instructions write the TLB entries. The as register is formatted
according to Figure 4–21, while the at register is formatted according to Figure 4–22.
The attribute for the region is described in detail in Section 4.6.3.3. The remaining bits
are ignored or required to be zero.
After modifying any TLB entry with a WITLB instruction, an ISYNC must be executed be-
fore executing any instruction from that region. In the special case of the WITLB chang-
ing the attribute of its own region, the ISYNC must immediately follow the WITLB and
both must be within the same memory region and, if the region is cacheable, within the
same cache line.
31 12 11 4 3 0
20 8 4
Figure 4–22. Region Protection Option Data (at) Format for WxTLB
The RITLB0 and RDTLB0 instructions exist under this option but do not return interest-
ing information because the entire VPN is used as an index. The as register is formatted
according to Figure 4–21. The read instructions return zero in the at register.
The RITLB1 and RDTLB1 instructions return the at data format in Figure 4–23. The At-
tribute for the region is described in detail in Section 4.6.3.3. The VPN is returned in the
upper three bits as the Physical Page Number (PPN) because there is no translation.
The remaining bits are zero or undefined. The as register is formatted according to
Figure 4–21.
31 29 28 12 11 4 3 0
3 17 8 4
Figure 4–23. Region Protection Option Data (at) Format for RxTLB1
The PITLB and PDTLB instructions exist under this option but do not return interesting
information because all accesses hit in the respective TLBs and the TLBs have only a
single way. The as register is formatted according to Figure 4–21. The TLB probe in-
structions return the at data format in Figure 4–24. The VPN is returned in the upper
bits. The low bit is set because the probe always hits and the remaining bits are zero or
undefined.
31 29 28 12 11 1 0
3 17 11 1
Figure 4–24. Region Protection Option Data (at) Format for PxTLB
The IITLB and IDTLB instructions exist under this option and their as register is for-
matted according to Figure 4–21, but they have no effect because the entries cannot be
removed from the respective TLBs.
The memory attributes written into the TLB entries by the WxTLB instructions and read
from them by the RxTLB1 instructions control access to memory and, where there is a
cache, how the cache is used. Table 4–104 shows the meanings of the attributes for in-
struction fetch, data load, and data store. For a more detailed description of the memory
access process and the place of these attributes in it, see Section 4.6.2.
The first column in Table 4–104 indicates the attribute attribute from the TLB while the
remaining columns indicate various effects on the access. The columns are described in
the following bullets:
Attr — the value of the 4-bit Attribute field of the TLB entry.
Rights — whether the TLB entry may successfully translate a data load, a data
store, or an instruction fetch.
- The first character is an r if the entry is valid for a data load and a dash ("-")if
not.
- The second character is a w if the entry is valid for a data store and a dash
("-")if not.
- The third character is an x if the entry is valid for an instruction fetch and a dash
("-")if not.
If the translation is not successful, an exception is raised.
Local memory accesses (including XLMI) consult only the Rights column.
WB — some rows are split by whether or not the configured cache is writeback or
not. Rows without an entry apply to both cache types.
Meaning for Cache Access — the verbal description of the type of access made to
the cache.
Access Cache — indicates whether the cache provides the data.
- The first character is an h if the cache provides the data when the tag indicates
hit and a dash ("-")if it does not.
- The second character is an m if the cache provides the data when the tag indi-
cates a miss and a dash ("-")if it does not. This capability is used only for Iso-
late mode.
Fill Cache — indicates whether an allocate and fill is done to the cache if the tag in-
dicates a miss.
- The first character is an r if the cache is filled on a data load and a dash ("-")if
it is not.
- The second character is a w if the cache is filled on a data store and a dash ("-
")if it is not.
- The third character is an x if the cache is filled on an instruction fetch and a
dash ("-")if it is not.
Writes to local memories are never Write-Thru. In most implementations, a write-thru will
only occur after any needed cache fill is complete.
All attribute entries in the ITLB and DTLB are set to cache bypass (4’h2) after reset.
In the absence of the Instruction Cache Option, Cached regions behave as Bypass re-
gions on instruction fetch. In the absence of the Data Cache Option, Cached regions be-
have as Bypass regions on data load or store. If the Data Cache is not configured as
writeback (Section 4.5.5.1 on page 119) Attributes 4 and 5 behave as Attribute 1 instead
of as they are listed in Table 4–104.
After changing the attribute of any memory region with a WITLB instruction, an ISYNC
must be executed before executing any instruction from that region. In the special case
of the WITLB changing the attribute of its own region, the ISYNC must immediately fol-
low the WITLB and both must be within the same cache line.
After changing the attribute of a region by WDTLB, the operation of loads from and stores
to that region are undefined until a DSYNC instruction is executed.
Building on the Region Protection Option is the Region Translation Option, which adds a
virtual-to-physical translation on the upper three bits of the address. Thus, each of the
eight 512 MB regions, in addition to the attributes provided by the Region Protection Op-
tion, may be redirected to access a different region of physical address space.
Prerequisites: Exception Option (page 82) and Region Protection Option (page 150)
Incompatible options: MMU Option (page 158)
With this option, the Physical Page Numbers (PPNs) of each of the TLB entries is now
writable instead of constant and identity mapped. In this way, the same region of memo-
ry may be accessed with different attributes by the use of different virtual addresses.
This simple option is built from the capabilities discussed in the introduction (see
Section 4.6.1). It uses RingCount = 1, so the processor can always execute privileged
instructions. It sets ASIDBits to 0, which disables the ASID feature. The instruction
and data TLBs are programmed to each have one way of eight entries, and only the at-
tributes and Physical Page Numbers (PPNs) are not constant; they are writable using
the WITLB and WDTLB instructions.
There are no new exceptions, no new state registers, and no new Instructions added to
those in the Region Protection Option. The TLB entries contain three additional bits of
state. Access to these bits is described in Section 4.6.4.2.
During normal operation when instructions and data are being accessed from memory,
only lookups are being done in the TLBs. For maintenance of the TLBs, however, the
entries in the TLBs are accessed by the instructions in Table 4–103 on page 151. Note
that unused bits at Bit 12 and above are ignored on write and zero on read so that those
bits may simply contain the address for access to all ways of both TLBs. Unused bits at
Bit 11 and below are required to be zero on write and undefined on read for forward
compatibility.
The register formats used by the TLB instructions are very similar to those described in
Section 4.6.3.2 for the Region Protection Option. The only difference is the presence of
a Physical Page Number (PPN) in the upper three bits of the WxTLB, RxTLB1, and
PxTLB register formats.
The format of the as register used in all instructions in the table is shown in Figure 4–25.
The upper three bits are used as an index among the TLB entries just as they would be
when addressing memory. They are the Virtual Page Number (VPN) or upper three bits
of address. The remaining bits are ignored.
31 29 28 0
VPN Ignored
3 29
Figure 4–25. Region Translation Option Addressing (as) Format for WxTLB, RxTLB1, & PxTLB
The WITLB and WDTLB instructions write the TLB entries. The as register is formatted
according to Figure 4–25, while the at register is formatted according to Figure 4–26.
The attribute for the region is described in detail in Section 4.6.3.3 on page 154. The re-
maining bits are ignored or required to be zero.
After modifying any TLB entry with a WITLB instruction, an ISYNC must be executed be-
fore executing any instruction from that region. In the special case of the WITLB chang-
ing the attribute of its own region, the ISYNC must immediately follow the WITLB and
both must be within the same memory region and, if the region is cacheable, within the
same cache line.
After modifying any TLB entry with a WDTLB instruction, the operation of loads from and
stores to that region are undefined until a DSYNC instruction is executed.
31 12 11 4 3 0
3 17 8 4
Figure 4–26. Region Translation Option Data (at) Format for WxTLB
The RITLB0 and RDTLB0 instructions exist under this option but do not return interest-
ing information because the entire VPN is used as an index. The as register is formatted
according to Figure 4–25. The read instructions return zero in the at register.
The RITLB1 and RDTLB1 instructions return the at data format in Figure 4–27. The at-
tribute for the region is described in detail in Section 4.6.3.3. The Physical Page Number
(PPN) is returned in the upper three bits. The remaining bits are zero or undefined. The
as register is formatted according to Figure 4–25.
31 29 28 12 11 4 3 0
3 17 8 4
Figure 4–27. Region Translation Option Data (at) Format for RxTLB1
The PITLB and PDTLB instructions return the at data format in Figure 4–28. The Virtual
Page Number (VPN) is returned in the upper bits. The low bit is set because the probe
always hits, and the remaining bits are zero or undefined. The as register is formatted
according to Figure 4–25. These instructions work for their intended purpose, but do not
provide useful information under this simple option because the TLBs always hit and
have only a single way.
31 29 28 1 0
3 17 11 1
Figure 4–28. Region Translation Option Data (at) Format for PxTLB
The IITLB and IDTLB instructions exist under this option and their as register is for-
matted according to Figure 4–25, but they have no effect because the entries cannot be
removed from the respective TLBs.
The memory attributes written into the TLB entries by the WxTLB instructions and read
from them by the RxTLB1 instructions are exactly the same as under the Region Protec-
tion Option.
As with the Region Protection Option, all attributes in both TLBs are set to cache bypass
(4’b0010) after reset. In addition, the translation entries in both TLBs are set to identity
map after reset.
The MMU Option is a memory management unit created to run protected operating sys-
tems such as Linux on the Xtensa processor with demand paging hardware with a mem-
ory-based page table.
Prerequisites: Exception Option (page 82)
Incompatible options: Region Protection Option (page 150), Extended L32R Option
(page 56)
This option is also built from the capabilities discussed in the introduction
(Section 4.6.1). It uses RingCount = 4 and only Ring 0 may execute privileged instruc-
tions. The option sets ASIDBits to 8, which allows for lower TLB management over-
head.
The instruction and data TLBs are programmed to have seven and ten ways, respective-
ly (see Section 4.6.5.3). Some of the ways are constants; others can be set to arbitrary
values. Still others auto-refill from a page table in memory that contains 4-byte PTEs,
each mapping a 4kB page with a 20-bit PPN, a 2-bit ring number, a 4-bit attribute, and 6
bits reserved for software. For a programmer’s view of the MMU, refer to the Xtensa
Microprocessor Programmer’s Guide.
Table 4–105 through Table 4–108 show this option’s architectural additions.
This section describes the address and data formats needed for reading and writing the
instruction and data TLBs.
PTEVADDR
Because four ways of each TLB are configured as AutoRefill, the MMU Option supports
hardware refill of the TLB from a page table (Section 4.6.5.9). The base virtual address
of the current page table is specified in the PTEBase field of the PTEVADDR register.
When read, PTEVADDR returns the PTEBase field in its upper bits as shown in
Figure 4–29, EXCVADDR31..12 in the field labeled VPN below followed by two zero bits.
When PTEVADDR is written, only the PTEBase field is modified. PTEVADDR is undefined
after reset. Figure 4–29 shows the PTEVADDR register format.
31 22 21 2 1 0
PTEBase VPN 0
10 20 2
RASID
The Ring ASID (RASID) register holds the current ASIDs for each ring. The register is
divided into four 8-bit sections, one for each ASID. The Ring 0 ASID is hardwired to 1.
The operation of the processor is undefined if any two of the four ASIDs are equal or if
it contains an ASID of zero. RASID is 32’h04030201 after reset. Figure 4–30 shows
the RASID register format.
31 24 23 16 15 8 7 0
8 8 8 8
ITLBCFG
Because one or three ways of the instruction TLB are configured with variable page siz-
es (depending on whether IVARWAY56 is, respectively, fixed or variable), the ITLBCFG
register specifies the page size for those ways. Regardless of IVARWAY56, the Size
field in bits[17:16] of the register controls the size of the entries in Way 4 and has the
values 2’b00 = 1 MB, 2’b01 = 4 MB, 2’b10 = 16 MB, and 2’b11 = 64 MB. If IVARWAY56 is
Variable, the Sz field in bit[20] of the register controls the size of the entries in Way 5 and
has the values 1’b0 = 128MB and 1’b1 = 256MB. If IVARWAY56 is Variable, the Sz field
in bit[24] of the register controls the size of the entries in Way 6 and has the values 1’b0
= 512MB and 1’b1 = 256MB. MBZ means “must be zero”. The entire TLB way should be
invalidated when its size is changed. The ITLBCFG register is zero after reset. The fol-
lowing shows the ITLBCFG register format.
31 25 24 23 21 20 19 18 17 16 15 0
7 1 3 1 2 2 16
DTLBCFG
Because one or three ways of the data TLB are configured with variable page sizes (de-
pending on whether DVARWAY56 is, respectively, fixed or variable), the DTLBCFG regis-
ter specifies the page size for those ways. Regardless of DVARWAY56, the Size field in
bits[17:16] of the register controls the size of the entries in Way 4 and has the values
2’b00 = 1 MB, 2’b01 = 4 MB, 2’b10 = 16 MB, and 2’b11 = 64 MB. If DVARWAY56 is Vari-
able, the Sz field in bit[20] of the register controls the size of the entries in Way 5 and
has the values 1’b0 = 128MB and 1’b1 = 256MB. If DVARWAY56 is Variable, the Sz field
in bit[24] of the register controls the size of the entries in Way 6 and has the values 1’b0
= 512MB and 1’b1 = 256MB. MBZ means “must be zero”. The entire TLB way should be
invalidated when its size is changed. The DTLBCFG register is zero after reset.
Figure 4–31 shows the DTLBCFG register format.
31 25 24 23 21 20 19 18 17 16 15 0
7 1 3 1 2 2 16
The instruction TLB is 7-way set-associative. Ways 0-3 are AutoRefill ways used for
hardware refill of 4 kB page table entries from the page table when no matching TLB en-
try is found. The AutoRefill ways contain a total of either 16 entries (four per way) or 32
entries (eight per way) depending on NIREFILLENTRIES. Way 4 is a variable size way
of four entries and is used for mapping large pages of 1 MB, 4 MB, 16 MB, or 64 MB as
configured by the ITLBCFG register. The ASID fields in these ways are set to zero (in-
valid) after reset.
Way 5 (IVARWAY56 Fixed), with two constant entries, statically maps the 128 MB region
32'hD0000000–32'hD7FFFFFF to the first 128 MB of physical memory
(32'h00000000–32'h07FFFFFF) as cached memory (attribute 4’h7 as described in
Section 4.6.5.10), and the next 128 MB region (32'hD8000000–32'hDFFFFFFF) to
the same 128 MB of physical memory as cache bypassed memory (attribute 4’h3 as de-
scribed in Section 4.6.5.10). The ASID entries for both entries is 8’h01. These 128 MB
regions are intended for the operating system kernel’s first 128 MB of code and data
(see Figure 4–32). Using a pair of large static mappings reduces the load on the de-
mand refill portion of the instruction TLB and also provides access using two attributes
for the same memory. Physical memory above the first 128 MB is accessed via dynami-
cally mapped virtual address space.
Way 5 (IVARWAY56 Variable), is a variable size way of four entries and is used for map-
ping very large pages of 128 MB or 256 MB as configured by the ITLBCFG register. The
ASID fields in this way are set to zero (invalid) after reset. This way may be used to em-
ulateWay 5 (IVARWAY56 Fixed), or it may be used for a more flexible arrangement.
Way 6 (IVARWAY56 Fixed), also with 2 constant entries, statically maps the 256 MB re-
gion 32'hE0000000–32'hEFFFFFFF to the last 256 MB of physical memory
(32'hF0000000–32'hFFFFFFFF) as cached memory (attribute 4’h7 as described in
Section 4.6.5.10), and the next 256 MB region (32'hF0000000–32'hFFFFFFFF) to
the same 256MB of physical memory as cache bypassed memory (attribute 4’h3 as de-
scribed in Section 4.6.5.10). The ASID entries for both entries is 8’h01. These 256 MB
regions are intended for addressing the system peripherals (for example, a PCI or other
I/O bus) and system ROM (see Figure 4–32).
Way 6 (IVARWAY56 Variable), is a variable size way of eight entries and is used for
mapping very large pages of 512 MB or 256 MB as configured by the ITLBCFG register.
The ASID fields in this way are set one and the Attribute fields in this way are set to 4’h2
(Bypass) after reset, and the other fields are set so that this way directly maps all of
memory after reset. This way may be used to emulate Way 6 (IVARWAY56 Fixed), it may
be used to effectively "turn off" the ITLB, or it may be used for a more flexible arrange-
ment.
The data TLB is 10-way set-associative. It has the same seven ways as the instruction
TLB above (using DTLBCFG/DVARWAY56, instead of ITLBCFG/IVARWAY56), with the
addition of Ways 7-9, which are single-entry ways for 4 kB pages. These ways are in-
tended to hold translations required to map the page table for hardware refill and for en-
tries that are not to be replaced by refill. The ASID fields in these ways are set to zero
(invalid) after reset.
All ASID fields in the ITLB and DTLB, except those in Way 5 & Way 6, are set to zero (in-
valid) after reset. ASID fields in Way 5 are set to zero (invalid) after reset if
IVARWAY56/DVARWAY56 is Variable.
The memory map is determined by the TLB configurations given in Section 4.6.5.3.
Figure 4–32 shows a graphical representation of the constant translations in Way 5 and
Way 6 when IVARWAY56 and DVARWAY56 are Fixed, as well as the regions that are
mapped by more flexible ways than these. Way 5 and Way 6 may be used to emulate
this same arrangement when IVARWAY56 and DVARWAY56 are Variable.
Virtual Physical
FFFFFFFF FFFFFFFF
bypass peripherals
F0000000 F0000000
cached
E0000000
D8000000 bypass
D0000000 cached
mapped
08000000
00000000 00000000
Figure 4–32. MMU Option Address Map with IVARWAY56 and DVARWAY56 Fixed
This configuration provides both bypass and cached access to peripherals. Bypass ac-
cess is used for devices and cached access is used for ROMs, for example. It also pro-
vides bypass and cached access to the low 128 MB of memory. This allows system soft-
ware to access its memory without competing with user code for other TLB entries.
These are available after reset. The large page way (Way 4) and the auto-refill ways
(Ways 0-3) may be used to map as much additional space as desired (Section 4.6.5.9).
In the data TLB, Ways 7-9 may be used to map single pages so that they are always
available.
During normal operation when instructions and data are being accessed from memory,
only lookups are being done in the TLBs. For maintenance of the TLBs, however, the
entries in the TLBs are accessed by the instructions in Table 4–108 on page 160.
Writing the TLB with the WITLB and WDTLB instructions requires the formats for the as
and at registers shown in Figure 4–33 and Figure 4–34. These figures show, in parallel,
the formats for different ways of the cache and different conditions. For Ways 0-3, there
are two conditions that depend on the configuration parameter NIREFILLENTRIES or
NDREFILLENTRIES (see Figure 4–105 on page 159) and can have the values of 16 or
32 auto-refill entries per TLB (four or eight per TLB way). For Way 4, there are four con-
ditions, which are the four values of the respectiveITLBCFG or DTLBCFG fields and indi-
cate the size of pages currently contained within that way. Ways 5 and 6 can be Fixed or
Variable as determined by the IVARWAY56 and DVARWAY56 parameters. If they are vari-
able then there are still two conditions which are the two values of the respective ITLB-
CFG or DTLBCFG fields and indicate the size of pages currently contained within that
way. Each row, then, contains the format for the way and condition indicated in the left
column. Note that writing to Way-5 and Way-6 when the IVARWAY56 and DVARWAY56
parameters are "Fixed" causes no changes because those ways are constant.
The format of the as register used for the WITLB and WDTLB instructions is shown in
Figure 4–33. The low order four bits contain the way to be accessed. The upper bits
contain the Virtual Page Number (VPN). For clarity, the Index bits are separated out
from the rest of the VPN in this figure. Note that unused bits at Bit 12 and above are ig-
nored so that those bits may simply contain the address for access to all ways of both
TLBs. Unused bits at Bit 11 and below are reserved for forward compatibility. They may
either be zero or they may be the result of the probe instruction (Section 4.6.5.7).
Way 31 30 29 28 27 26 25 24 23 22 21 20 19 15 14 13 12 11 4 3 2 1 0
The format of the at register used for the WITLB and WDTLB instructions is shown in
Figure 4–34. The low order four bits contain the attribute to be written (see
Section 4.6.5.10). The two bits above those contain the ring for which this TLB entry is
to be written. The ASID taken from the RASID register (see Section 4.6.5.2) correspond-
ing to this ring is stored with the TLB entry. It is not possible to write an entry with an
ASID which is not currently in the RASID register. The upper bits contain the Physical
Page Number (PPN) of the translation. Way-5 and Way-6 are constant ways when the
IVARWAY56 and DVARWAY56 parameters are "Fixed": The PPN remains as described in
Section 4.6.5.3, the ASID is not written but always matches Ring 0, and the attribute re-
mains as described in Section 4.6.5.3, no matter what is in register at. As with the ad-
dress format, unused bits at Bit 12 and above are ignored so that a 20-bit PPN may be
used with all ways of the TLB, and unused bits at Bit 11 and below are required to be
zero for forward compatibility.
Way 31 29 28 27 26 25 24 23 22 21 20 19 18 17 12 11 6 5 4 3 0
31 29 28 27 26 25 24 23 22 21 20 19 18 17 12 11 6 5 4 3 0
After modifying any TLB entry with a WITLB instruction, an ISYNC must be executed be-
fore executing any instruction that depends on the modification. The ITLB entry currently
being used for instruction fetch may not be changed.
After modifying any TLB entry with a WDTLB instruction, the operation of loads and
stores that depend on that TLB entry are undefined until a DSYNC instruction is execut-
ed.
Reading the TLB with the RITLB0, RITLB1, RDTLB0, and RDTLB1 instructions requires
the formats for the as and at registers shown in Figure 4–35 through Figure 4–37.
These figures show, in parallel, the formats for different ways of the cache and different
conditions. For Ways 0-3, there are two conditions that depend on the configuration pa-
rameter NIREFILLENTRIES or NDREFILLENTRIES (see Figure 4–105 on page 159)
and can have the values of 16 or 32 auto-refill entries per TLB (four or eight per TLB
way). For Way 4, there are four conditions, which are the four values of the respec-
tiveITLBCFG or DTLBCFG fields and indicate the size of pages currently contained within
that way. Ways 5 and 6 can be Fixed or Variable as determined by the IVARWAY56 and
DVARWAY56 parameters. If they are variable then there are still two conditions which are
the two values of the respective ITLBCFG or DTLBCFG fields and indicate the size of
pages currently contained within that way. Each row, then, contains the format for the
way and condition indicated in the left column.
The format of the as register used for the RITLB0, RITLB1, RDTLB0, and RDTLB1 in-
structions is shown in Figure 4–35. The low order four bits contain the way to be access-
ed. Besides the Way bits, only the Index bits are needed for reading the TLB. Depending
on the TLB way being accessed, and other conditions such as the size assigned to the
variable size way or the number of auto refill entries in the TLB, different bits of address
may be needed as shown. Note that unused bits at Bit 12 and above are ignored so that
an entire 20-bit VPN may be used when accessing all ways of both TLBs. Unused bits at
Bit 11 and below are reserved for forward compatibility. They may either be zero or they
may be the result of the probe instruction (Section 4.6.5.7).
Way 31 29 28 27 26 25 24 23 22 21 20 19 15 14 13 12 11 4 3 2 1 0
31 29 28 27 26 25 24 23 22 21 20 19 15 14 13 12 11 4 3 2 1 0
Figure 4–35. MMU Option Addressing (as) Format for RxTLB0 and RxTLB1
Because reading generates more information than can fit in one 32-bit register, there are
two read instructions that return different values. The data resulting from the RITLB0
and RDTLB0 instructions is shown in Figure 4–36. The low bits contain the ASID stored
with the entry, while the upper bits contain the Virtual Page Number (VPN) without the
Index bits that were used in the address of the read. Unused bits at Bit 12 and above of
the data result of these instructions are defined to be zero so that the entire 20-bit field
may always be used as a VPN whatever the size of the way. Unused bits at Bit 11 and
below are undefined for forward compatibility.
Way 31 30 29 28 27 26 25 24 23 22 21 15 14 13 12 11 8 7 0
31 30 29 28 27 26 25 24 23 22 21 15 14 13 12 11 8 7 0
The data resulting from the RITLB1, and RDTLB1 instructions is shown in Figure 4–37.
The low order four bits contain the attribute stored with the TLB entry (Section 4.6.5.10).
The upper bits contain the Physical Page Number (PPN) of the entry. Unused bits at Bit
12 and above of the data result of these instructions are defined to be zero so that the
entire 20-bit field may always be used as a PPN, whatever the size of the way. Unused
bits at Bit 11 and below are undefined for forward compatibility.
Way 31 29 28 27 26 25 24 23 22 21 20 19 12 11 4 3 0
31 29 28 27 26 25 24 23 22 21 20 19 12 11 4 3 0
Probing the TLB with the PITLB and PDTLB instructions requires the formats for the as
and at registers shown in Figure 4–38 and Figure 4–39. Unlike writing and reading the
TLBs as explained in the previous two sections, the operation of probing a TLB begins
without knowing the way containing the sought after value. The formats do not, there-
fore, vary with the way being accessed. The probe instructions answer the question of
what entry in this TLB, if any, would be used to translate an access with a particular ad-
dress from a particular ring. The sought for address is given in the as register as shown
in Figure 4–38 and the ring is given by PS.RING (not CRING, so that while PS.EXCM is
set, a probe may be done for a user program). If, for example, there is an entry that
matches in address, but its ASID does not match any ASID in the RASID register, or an
entry that matches in address, but the ASID corresponds in the RASID register to a ring
of lower number than the current PS.RING, the probe will not return a hit.
The format of the as register used for the PITLB and PDTLB instructions is shown in
Figure 4–38. Any address may be used as input to the probe instructions.
31 0
Probe Address
32
The data resulting from the PITLB and PDTLB instructions is shown in Figure 4–39 and
Figure 4–40. The low three/four bits contain the Way (if any), which would be used to
translate the address and the next bit up is set if there is a translation in the TLB, and
clear if there is not. Some bits are undefined for forward compatibility but the result is
such that, if Hit=1, it may be used as the as register for WxTLB, RxTLB0, RxTLB1, or
IxTLB.
31 12 11 4 3 2 0
20 8 1 3
31 12 11 5 4 3 0
20 7 1 4
Invalidating the TLB with the IITLB and IDTLB instructions requires the formats for the
as register shown in Figure 4–41. This figure shows, in parallel, the formats for different
ways of the cache and different conditions. For Ways 0-3, there are two conditions that
depend on the configuration parameter NIREFILLENTRIES or NDREFILLENTRIES
(Figure 4–105) and can have the values of 16 or 32 auto-refill entries per TLB (4 or 8 per
TLB way). For Way 4, there are four conditions, which are the four values of the respec-
tiveITLBCFG or DTLBCFG fields and indicate the size of pages currently contained within
that way. Ways 5 and 6 can be Fixed or Variable as determined by the IVARWAY56 and
DVARWAY56 parameters. If they are variable then there are still two conditions which are
the two values of the respective ITLBCFG or DTLBCFG fields and indicate the size of
pages currently contained within that way. Each row, then, contains the format for the
way and condition indicated in the left column. Note that invalidating Way-5 and Way-6
when the IVARWAY56 and DVARWAY56 parameters are "Fixed" causes no changes be-
cause those ways are constant.
The format of the as register used for the IITLB and IDTLB instructions is shown in
Figure 4–41. The low order four bits contain the way to be accessed. The upper bits
contain at least the Index from the Virtual Page Number (VPN). Note that unused bits at
Bit 12 and above are ignored so that those bits may simply contain the address for ac-
cess to all ways of both TLBs. Unused bits at Bit 11 and below are reserved for forward
compatibility. They may either be zero or they may be the result of the probe instruction
(Section 4.6.5.7 on page 171).
Invalidation of an entry sets the corresponding ASID to zero so that it no longer re-
sponds when an address is looked up in the TLB.
Way 31 30 29 28 27 26 25 24 23 22 21 20 19 15 14 13 12 11 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 15 14 13 12 11 4 3 2 1 0
After modifying any TLB entry with a IITLB instruction, an ISYNC must be executed be-
fore executing any instruction that depends on the modification. After modifying any TLB
entries with an IDTLB instruction, the operation of loads from and stores that depend on
that TLB entry are undefined until a DSYNC instruction is executed.
When no TLB entry matches the ASIDs and the virtual address presented to the MMU,
the MMU attempts to automatically load the appropriate page table entry (PTE) from the
page table and write it into the TLB in one of the AutoRefill ways. This hardware- gener-
ated load from the page table itself requires virtual-to-physical address translation,
which executes at Ring 0 so that it has access to the page table and uses the DTLB. An
error of any sort during the automatic refill process will cause an InstTLBMissCause
or a LoadStoreTLBMissCause exception to be raised so that system software can
take appropriate action and possibly retry the access. This combination of hardware and
software refill gives excellent performance while minimizing processor complexity. If the
second translation succeeds, the PTE load is done through the DataCache, if one is
configured, and the attributes for the page containing the PTE enable such a cache ac-
cess. The PTE’s Ring field is then used as an index into the RASID register, and the re-
sulting ASID is written together with the rest of the PTE into the TLB.
Xtensa’s TLB refill mechanism requires the page table for the current address space to
reside in the current virtual address space. The PTEBase field of the PTEVADDR register
gives the base address of the page table. On a TLB miss, the processor forms the virtual
address of the PTE by catenating the PTEBase portion of PTEVADDR, the Virtual Page
Number (VPN) bits of the miss virtual address, and 2 zero bits. The bits used from
PTEVADDR and from the virtual address are configuration dependent; the exact calcula-
tion for 4-byte PTEs is
PTEVADDR31..22||vAddr31..12||2'b00
The format of the PTEs is shown in Figure 4–42. The most significant bits hold the Phys-
ical Page Number (PPN), the translation of the virtual address corresponding to this en-
try. The Sw bits are available for software use in the page table (they are not stored in
the TLB). The Ring field specifies the privilege level required to access this page; this is
used to choose one of the four ASIDs from RASID when the TLB is written. The attribute
field gives the access attributes for this page (see Section 4.6.5.10).
31 12 11 6 5 4 3 0
20 6 2 4
For example, if PTEVADDR is set to 32’hCFC00000, then the virtual address space be-
tween there and 32’hCFF3FFFF is used as the page table. That page table is mapped
by the 832 entries between 32’hCFF3F000 and 32’hCFF3FCFF. The translation for the
page at 32’hCFF3F000 is placed in one of the single-entry ways of the data TLB. (The
accesses that might have used the remaining 192 PTE entries on that page would al-
ready have been translated by one of the constant ways.) Many of those 832 entries
may be marked invalid and the physical address space required for the page table may
be made very small.
In systems with large memories, the above maximum configuration may be improved in
performance by mapping the entire page table into the constant way (Way 5). If
PTEVADDR is set to 32’hD4000000, for example, the virtual address space between
there and 32’hD433FFFF, which maps to the physical address space between
32’h04000000 and 32’h0433FFFF (between 64 MB and about 68 MB) is used for a
flat page table mapping all of memory. Any TLB miss will now be handled by the hard-
ware refill as the translation for the PTE will be handled by the constant way. The disad-
vantage is that over 3 MB of memory must be allocated to the page table.
In a small system, where all processes are limited to the first 8 MB of virtual space,
PTEVADDR might be set to 32’hCFC00000 and two of the single entry ways set to map
the page at 32’hCFC00000 and the page at 32’hCFC01000. One or both pages of
PTEs could be used for translations and the hardware refill would always succeed for le-
gal addresses.
Currently available hardware supports the memory attributes described in this section.
T1050 hardware supported somewhat different memory attributes, which are described
in Section A.5 “MMU Option Memory Attributes”. System software may use the subset of
attributes (1, 3, 5, 7, 12, 13, and 14) which have not changed to support all Xtensa pro-
cessors.
The memory attributes discussed in this section apply both to attribute values written in
and read from the TLBs (see Section 4.6.5.5 and Section 4.6.5.6) and to attribute values
stored in the PTE entries and written into the AutoRefill ways of the TLBs (see
Section 4.6.5.9).
For a more detailed description of the memory access process and the place of these at-
tributes in it, see Section 4.6.2.
Table 4–109 shows the meanings of the attributes for instruction fetch, data load, and
data store. For a more detailed description of the memory access process and the place
of these attributes in it, see Section 4.6.2.
The first column in Table 4–109 indicates the attribute from the TLB while the remaining
columns indicate various effects on the access. The columns are described in the follow-
ing bullets:
Attr — the value of the 4-bit Attribute field of the TLB entry.
Rights — whether the TLB entry may successfully translate a data load, a data
store, or an instruction fetch.
- The first character is an r if the entry is valid for a data load and a dash ("-")if
not.
- The second character is a w if the entry is valid for a data store and a dash
("-")if not.
- The third character is an x if the entry is valid for an instruction fetch and a dash
("-")if not.
If the translation is not successful, an exception is raised.
Local memory accesses (including XLMI) consult only the Rights column.
WB — some rows are split by whether or not the configured cache is writeback or
not. Rows without an entry apply to both cache types.
Meaning for Cache Access — the verbal description of the type of access made to
the cache.
Access Cache — indicates whether the cache provides the data.
- The first character is an h if the cache provides the data when the tag indicates
hit and a dash ("-")if it does not.
- The second character is an m if the cache provides the data when the tag indi-
cates a miss and a dash ("-")if it does not. This capability is used only for Iso-
late mode.
Fill Cache — indicates whether an allocate and fill is done to the cache if the tag in-
dicates a miss.
- The first character is an r if the cache is filled on a data load and a dash ("-")if
it is not.
- The second character is a w if the cache is filled on a data store and a dash ("-
")if it is not.
- The third character is an x if the cache is filled on an instruction fetch and a
dash ("-")if it is not.
Guard Load — refers to the guarded attribute as described in Table 4–99 on
page 144. Stores are always guarded and instruction fetches are never guarded,
but loads are guarded where there is a “yes” in this column. Local memory loads are
not guarded.
Write Thru — indicates whether a write is done through the PIF interface.
- The first character is an h if a Write Thru occurs when the tag indicates hit and a
dash ("-")if it does not.
- The second character is an m if a Write Thru occurs when the tag indicates a
miss and a dash ("-")if it does not.
Writes to local memories are never Write-Thru. In most implementations, a write-thru will
only occur after any needed cache fill is complete.
In the absence of the Instruction Cache Option, Cached regions behave as Bypass re-
gions on instruction fetch. In the absence of the Data Cache Option, Cached regions be-
have as Bypass regions on data load or store. If the Data Cache is not configured as
writeback (Section 4.5.5.1 on page 119) Attributes 4, 5, 6, and 7 behave as Attributes 8,
9, 10, and 11 respectively instead of as they are listed in Table 4–109.
The following functions are used in the operation sections of the individual instruction
definitions:
function ltranslate(vAddr, ring)
ltranslate ← (pAddr, attributes, cause)
endfunction ltranslate
function ASID(ring)
ASID ← RASIDring*8+ASIDBits-1..ring*8
endfunction ASID
function InstPageBits(wi)
sizecodebits ← ceil(log2(InstTLB[wi].PageSizeCount))
sizecode ← IPAGESIZEwi*4+sizecodebits-1..wi*4
InstPageBits ← InstTLB[wi].PageBits[sizecode]
endfunction InstPageBits
function SplitInstTLBEntrySpec(spec)
wih ← ceil(log2(InstTLBWayCount)) − 1
wi ← specwih..0
eil ← InstPageBits(wi)
eih ← eil + log2(InstTLB[wi].IndexCount)
ei ← speceih..eil
vpn ← specInstTLBVAddrBits-1..eih+1
SplitInstTLBEntrySpec ← (vpn, ei, wi)
endfunction SplitInstTLBEntrySpec
The Windowed Register Option replaces the simple 16-entry AR register file with a larg-
er register file from which a window of 16 entries is visible at any given time. The window
is rotated on subroutine entry and exit, automatically saving and restoring some regis-
ters. When the window is rotated far enough to require registers to be saved to or re-
stored from the program stack, an exception is raised to move some of the register val-
ues between the register file and the program stack. The option reduces code size and
increases performance of programs by eliminating register saves and restores at proce-
dure entry and exit, and by reducing argument-shuffling at calls. It allows more local
variables to live permanently in registers, reducing the need for stack-frame mainte-
nance in non-leaf routines.
Xtensa ISA register windows are different from register windows in other instruction
sets. Xtensa register increments are 4, 8, and 12 on a per-call basis, not a fixed incre-
ment as in other instruction sets. Also, Xtensa processors have no global address regis-
ters. The caller specifies the increment amount, while the callee performs the actual in-
crement by the ENTRY instruction. The compiler uses an increment sufficient to hide the
registers that are live at the point of the call (which the compiler can pack into the fewest
possible at the low end of the register-number space). The number of physical registers
is 32 or 64, which makes this a more economical configuration. Sixteen registers are vis-
ible at one time. Assuming that the average number of live registers at the point of call is
6.5 (return address, stack pointer, and 4.5 local variables), and that the last routine uses
12 registers at its peak, this allows nine call levels to live in 64 registers (8×6.5+12=64).
As an example, an average of 6.5 live registers might represent 50% of the calls using
an increment of 4, 38% using an increment of 8, and 12% using an increment of 12.
Prerequisites: Exception Option (page 82)
Incompatible options: None
The rotation of the 16-entry visible window within the larger register file is controlled by
the WindowBase Special Register added by the option. The rotation always occurs in
units of four registers, causing the number of bits in WindowBase to be log2(NAREG/4).
Rotation at the time of a call can instantly save some registers and provide new regis-
ters for the called routine. Each saved register has a reserved location on the stack, to
which it may be saved if the call stack extends enough farther to need to re-use the
physical registers. The WindowStart Special Register, which is also added by the option
and consists of NAREG/4 bits, indicates which four register units are currently cached in
the physical register file instead of residing in their stack locations. An attempt to use
registers live with values from a parent routine raises an Overflow Exception which
saves those values and frees the registers for use. A return to a calling routine whose
registers have been previously saved to the stack raises an Underflow Exception which
restores those values. Programs without wide swings in the depth of the call stack save
and restore values only occasionally.
Table 4–110 through Table 4–113 show this option’s architectural additions.
The WindowBase Special Register gives the position of the current window into the
physical register file. In the instruction descriptions, AR[i] is a short-hand for a refer-
ence to the physical register file AddressRegister defined as follows:
The WindowStart Special Register gives the state of physical registers (unused or part
of a window). WindowStart is used both to detect overflow and underflow on register
use and procedure return, as well as to determine the number of registers to be saved in
a given stack frame when handling exceptions and switching contexts. There is one bit
in WindowStart for each four physical registers. This bit is set if those four registers
are AR[0] to AR[3] for some call. WindowStart bits are set by ENTRY and cleared by
RETW.
The WindowBase and WindowStart registers are undefined after processor reset, and
should be initialized by the reset exception vector code.
Figure 4–43 through Figure 4–45 show three functionally identical implementations of
windowed registers. Figure 4–43 shows the concept of how the registers are addressed.
Figure 4–44 shows logic with the same functional result but with little or no penalty paid
in timing for the addition of the WindowBase value. Figure 4–45 shows a third version of
the logic with the same functional result but with no timing loss at all caused by the addi-
tion of the WindowBase value.
WindowBase
4
Inst
32
64:1
2
64:1
t 4 6 32
00 +
2 4
s 4 6
00 +
4 32 x 64
64 32-bit
registers
WindowBase
4
4:1
Inst 32
16:1
2
4:1
4
16:1
t 4 32
00 +
2 4
s 4
4
00 4 +
32 x 64
64 32-bit
registers
WindowBase
4
16:1
Inst 32
16:1
16:1
16:1
t 4 32
s 4
32 x 64
64 32-bit
registers
The ENTRY instruction moves the register window, but does not guarantee that all the
registers in the current window are available for use. Instead, the processor waits for the
first reference to an occupied physical register before triggering a window overflow. This
prevents unnecessary overflows, because many routines do not use all 16 of their virtual
registers. Figure 4–46 shows the state of the register file just prior to a reference that
causes an overflow. The WS(n) notation shows which WindowStart bits are set in this
example, and gives the distance to the next bit set (that is, the number of registers
stored for the corresponding stack frame). In the figure, “rmax” indicates the maximum
register that the current procedure uses and “Base” is an abbreviation for WindowBase.
Note that registers are considered in groups of four here.
WS(1)WS(2) WS(3) WS WS(2) WS(1)WS(2) WS(2)
Invalid
Active regs
Base
Base Base+ +16
rmax
Window
where ref() is 1 if the register is used by the instruction, and 0 otherwise, and
WindowCheck is defined as follows:
WindowBase ← m
endif
endprocedure WindowCheck
A single instruction may raise multiple window overflow exceptions. For example, sup-
pose that registers 4..7 of the current window still contain a previous call frame’s val-
ues (WindowStartWindowBase+1 is set), and 8..15 are part of the subroutine called by
that frame (WindowStartWindowBase+2 is also set), and an instruction references regis-
ter 10. The processor will raise an exception to spill registers 4..7 and then return to
retry the instruction, which will then raise another exception to spill registers 8..15. On
return from this overflow handler, the reference will finally succeed.
The register window mechanics of the {CALL, CALLX}{4,8,12}, ENTRY, and {RETW,
RETW.N} instructions are:
CALLn/CALLXn
WindowCheck (2'b00, 2'b00, n)
PS.CALLINC ← n
AR[n||2'b00] ← n || (PC + 3)29..0
ENTRY s, imm12
AR[PS.CALLINC||s1..0] ← AR[s] − (017||imm12||03)
WindowBase ← WindowBase + (02||PS.CALLINC)
WindowStartWindowBase ← 1
In the definition of ENTRY above, the AR read and the AR write refer to different registers.
RETW/RETW.N
n ← AR[0]31..30
nextPC ← PC31..30 || AR[0]29..0
owb ← WindowBase
m ← if WindowStartWindowBase-4’b0001 then 2’b01
elsif WindowStartWindowBase-4’b0010 then 2’b10
elsif WindowStartWindowBase-4’b0011 then 2’b11
else 2’b00
if n = 2’b00 | (m ≠ 2’b00 & m ≠ n) | PS.WOE=0 | PS.EXCM=1 then
-- undefined operation
-- may raise illegal instruction exception
else
WindowBase ← WindowBase − (02||n)
if WindowStartWindowBase ≠ 0 then
WindowStartowb ← 0
else
-- Underflow exception
PS.EXCM ← 1
EPC[1] ← PC
PS.OWB ← owb
nextPC ← if n = 2'b01 then WindowUnderflow4
else if n = 2'b10 then WindowUnderflow8
else WindowUnderflow12
endif
endif
The RETW opcode assignment is such that the s and t fields are both zero, so that the
hardware may use either AR[s] or AR[t] in place of AR[0] above. Underflow is de-
tected by the caller’s window’s WindowStart bit being clear (that is, not valid).
Figure 4–47 shows the register file just before a RETW that raises an underflow excep-
tion. window overflow and window underflow exceptions leave PS.UM unchanged.
WS
Invalid Invalid
Active Regs
Base +16
Valid Data
Base Base+rmax
Window
While the procedure-call protocol is a matter for the compiler and ABI, the Xtensa ISA,
and particularly the Windowed Register Option was designed with the following goals in
mind:
Provide highly efficient call/return (measured in both code size and execution time)
Support per-call register window increments
Use a single stack for both register save/restore and local variables
Support variable frame sizes (for example, alloca)
Support programming language exception handling (for example,
setjmp/longjmp, catch/throw, and so forth)
Support debuggers
Table 4–114 shows the register usage in the Windowed Register Option. Refer to
Section 8.1 “The Windowed Register and CALL0 ABIs” for a more complete description
of the Windowed Register ABI.
Calls to routines that use only a2..a3 as parameters may use the CALL4, CALL8, or
CALL12 instructions to save 4, 8, or 12 live registers. Calls to routines that use a2..a7
for parameters may use only CALL4 or CALL8. The following assembly language illus-
trates the call protocol.
The “highly efficient call/return” goal requires that there not be separate stack and frame
pointer registers in cases where they would differ by a constant (that is, no alloca is
used). There are simply not enough registers to waste. For routines that do call alloca,
the compiler will copy the initial stack pointer to another register and use that for ad-
dressing all locals.
p1 = alloca(n1);
will be implemented as
The botsize in the last statement allows the compiler to maintain a block of words at
the bottom of the stack (for example, this block might be for memory arguments to rou-
tines). The -16 is a constant of the call protocol; it puts 16 bytes of the bottom area be-
low the stack pointer (since they are infrequently referenced), leaving the limited range
of the ISA’s load/store offsets available for more frequently referenced locals.
Figure 4–48 and Figure 4–49 show the stack frame before and after alloca.
sp lp
bottom
sp-16
locals
lp
n1 bytes
p1
sp
bottom
sp-16
Figure 4–50 shows the stacking of frames when the stack grows downward, as on most
other systems. The window save area for a frame is addressed with negative offsets
from the next stack frame’s sp. Four registers are saved in the base save area. If more
than four registers are saved, they are stored at the top of the stack frame, in the extra
save area, which can be found with negative offsets from the previous stack frame’s sp.
This unusual split allows for simple backtrace while providing for a variable sized save
area.
locals i-1
Several of the goals listed on page 187 require that call stacks be backward-traceable.
That is, from the state of call[i], it must be possible to determine the state of
call[i-1]. It is best if the state of call[i] can be summarized in a single pointer (at
least when the registers have been saved), in which case this requirement is best de-
scribed as: There must be a means of determining the pointer for call[i-1] from the
pointer of call[i]. For managing register-window overflow or underflow, this method
should also be very efficient; it should not, for example, involve routine-specific informa-
tion or other table lookup (for example, frame size or stack offsets).
The Xtensa ISA represents the state of call[i] with its stack pointer (not the frame
pointer, as that is routine-specific and would cost too much to lookup). This can be made
to work even with alloca. Therefore it must be possible to read the stack pointer for
call[i-1] at a fixed offset from the stack pointer (not the frame pointer) for call[i].
Thus, the stack pointer for call[i-1] is stored in the area labeled “base save area i-1”
in Figure 4–48.
For efficiency, the call[i-1] stack pointer is only stored into call[i]’s frame when
call[i-1]’s registers are stored into the stack on overflow. This is sufficient for regis-
ter window underflow handling. Other back-tracing operations should begin by storing
registers of all call frames back into the stack.
The register-window call instructions only store the least-significant 30 bits of the return
address. Register-window return instructions leave the two most-significant bits of the
PC unchanged. Therefore, subroutines called using register window instructions must
be placed in the same 1 GB address region as the call.
4.7.1.6 Window Overflow and Underflow to and from the Program Stack
WindowOverflow8:
// On entry here: window rotated to call[j]; the registers to be
// saved are a0-a7; a8-a15 must be preserved
// a9 is call[j+1]’s stack pointer
s32e a0, a9, -16 // save a0 to call[j+1]’s frame
l32e a0, a1, -12 // a0 <- call[j-1]’s sp
s32e a1, a9, -12 // save a1 to call[j+1]’s frame
s32e a2, a9, -8 // save a2 to call[j+1]’s frame
s32e a3, a9, -4 // save a3 to call[j+1]’s frame
s32e a4, a0, -32 // save a4 to call[j]’s frame
s32e a5, a0, -28 // save a5 to call[j]’s frame
s32e a6, a0, -24 // save a6 to call[j]’s frame
s32e a7, a0, -20 // save a7 to call[j]’s frame
rfwo // rotates back to call[i] position
WindowUnderflow8:
// On entry here: a0-a7 are call[i].reg[0..7] and initially
// contain garbage, a8-a15 are call[i+1].reg[0..7],
// (in particular, a9 is call[i+1]’s stack pointer)
// and must be preserved
l32e a0, a9, -16 // restore a0 from call[i+1]’s frame
l32e a1, a9, -12 // restore a1 from call[i+1]’s frame
l32e a2, a9, -8 // restore a2 from call[i+1]’s frame
l32e a7, a1, -12 // a7 <- call[i-1]’s sp
l32e a3, a9, -4 // restore a3 from call[i+1]’s frame
l32e a4, a7, -32 // restore a4 from call[i]’s frame
l32e a5, a7, -28 // restore a5 from call[i]’s frame
l32e a6, a7, -24 // restore a6 from call[i]’s frame
l32e a7, a7, -20 // restore a7 from call[i]’s frame
rfwu
WindowOverflow12:
// On entry here: window rotated to call[j]; the registers to be
// saved are a0-a11; a12-a15 must be preserved
// a13 is call[j+1]’s stack pointer
s32e a0, a13, -16 // save a0 to call[j+1]’s frame
l32e a0, a1, -12 // a0 <- call[j-1]’s sp
WindowUnderflow12:
// On entry here: a0-a11 are call[i].reg[0..11] and initially
// contain garbage, a12-a15 are call[i+1].reg[0..3],
// (in particular, a13 is call[i+1]’s stack pointer)
// and must be preserved
l32e a0, a13, -16 // restore a0 from call[i+1]’s frame
l32e a1, a13, -12 // restore a1 from call[i+1]’s frame
l32e a2, a13, -8 // restore a2 from call[i+1]’s frame
l32e a11, a1, -12 // a11 <- call[i-1]’s sp
l32e a3, a13, -4 // restore a3 from call[i+1]’s frame
l32e a4, a11, -48 // restore a4 from end of call[i]’s frame
l32e a5, a11, -44 // restore a5 from end of call[i]’s frame
l32e a6, a11, -40 // restore a6 from end of call[i]’s frame
l32e a7, a11, -36 // restore a7 from end of call[i]’s frame
l32e a8, a11, -32 // restore a8 from end of call[i]’s frame
l32e a9, a11, -28 // restore a9 from end of call[i]’s frame
l32e a10, a11, -24 // restore a10 from end of call[i]’s frame
l32e a11, a11, -20 // restore a11 from end of call[i]’s frame
rfwu
The Processor Interface Option adds a bus interface used by memory accesses, which
are to locations other than local memories (page 123 through page 126). It is used for
cache misses for cacheable addresses (page 111 through page 122), as well as for
cache bypass memory accesses.
Direct memory access to local memories from outside may also be configured through
the bus interface added by the Processor Interface Option. The direct memory access
may either be top priority for highest bandwidth or intermediate priority for greatest effi-
ciency.
Prerequisites: None
Incompatible options: None
Historical note: The additions made by this option were once considered part of the
Core Architecture and so compatibility with previous hardware might require the use
of this option.
Refer to a specific Xtensa processor data book for more detail on the Processor Inter-
face Option.
Table 4–115 shows this option’s architectural additions (seeTable 4–64 on page 89 for
more). Note that asynchronous load/store errors are delivered via a configuration-de-
pendent interrupt.
The Miscellaneous Special Registers Option provides zero to four scratch registers with-
in the processor readable and writable by RSR, WSR, and XSR. These registers are privi-
leged. They may be useful for some application-specific exception and interrupt pro-
cessing tasks in the kernel. The MISC registers are undefined after reset.
Prerequisites: None
Incompatible options: None
Table 4–116 and Table 4–117 show this option’s architectural additions.
In some applications there are multiple Xtensa processors executing from the same in-
struction memory, and there is a need to distinguish one processor from another. This
option allows the system logic to provide each processor an identity by reading the PRID
register. The PRID value for each processor is typically in the range
0..NPROCESSORS-1, but this is not required. The PRID register is constant after reset.
Prerequisites: None
Incompatible options: None
The Debug Option implements instruction-counting and breakpoint exceptions for de-
bugging by software or external hardware. The option uses an interrupt level previously
defined in the High-Priority Interrupt Option. In some implementations, some debug in-
terrupts may not be masked by PS.INTLEVEL (see the Tensilica On-Chip Debugging
Guide). The Debug Option is useful when configuring a new (not previously debugged)
Xtensa processor configuration or for running previously untested software on a proces-
sor.
Prerequisites: High-Priority Interrupt Option (page 106)
Incompatible options: None
Some of the features listed below are added only when the OCD Option (see the Tensil-
ica On-Chip Debugging Guide) is configured in addition to the Debug Option. Those fea-
tures are included here, under the Debug Option, so that their architectural aspects are
documented, but marked as “available only with OCD Option.”
Table 4–120 through Table 4–122 show this option’s architectural additions.
The DEBUGCAUSE register contains a coded value giving the reason(s) that the proces-
sor took the debug exception. It is implementation-specific whether all applicable bits
are set or whether lower-priority conditions are undetected in the presence of higher-pri-
ority conditions.
For the priority of the bits in the DEBUGCAUSE register, see Section 4.4.1.11.
Figure 4–51 below shows the bits in the DEBUGCAUSE register, and Table 4–123 de-
scribes more fully the meaning of each bit.
31 12 11 8 7 6 5 4 3 2 1 0
The DEBUGCAUSE register is undefined after processor reset and when CINTLEVEL <
DEBUGLEVEL.
BREAK and BREAK.N are 24-bit and 16-bit instructions that simply raise a DEBUGLEVEL
exception with DEBUGCAUSE bit 3 or 4 set, respectively, when executed. Software can
replace an instruction with a breakpoint instruction to transfer control to a debug monitor
when execution reaches the replaced instruction.
The BREAK and BREAK.N instructions cannot be used on ROM code, and so the ISA
provides a configurable number of instruction-address breakpoint registers. When the
processor is about to complete the execution of the instruction fetched from virtual ad-
dress IBREAKA[i], and IBREAKENABLEi is set, it raises an exception instead. It is up
to the software to compare the PC to the various IBREAKA/IBREAKENABLE pairs to de-
termine which comparison caused the exception.
bytes is placed in one of the DBREAKA registers. The size of the covered block of bytes
is placed in the low bits of the corresponding DBREAKC register while the upper two bits
of the DBREAKC register contain an indication of which access types should raise the ex-
ception. The settings for each possible block size are shown in Table 4–124. The ‘x’ val-
ues under DBREAKA[i]5..0 allow any naturally aligned address to be specified for that
size. The result of other combinations of DBREAKC and DBREAKA is not defined.
When any of the bytes accessed by a load or store matches any of the bytes of the block
specified by one of the DBREAK[i] register pairs, the processor raises an exception in-
stead of executing the load or store. Specifically, “match” is defined as:
where sz is the number of bytes in the memory access. That is, both the first and last
byte of the memory access are masked by (126||DBREAKC[i]5..0). This operation aligns
both byte addresses to the DBREAK size indicated by DBREAKC[i]as in Table 4–124. If
the first or last masked address or any address between them matches DBREAKA[i]
then a match exists. Note that bits in DBREAKA[i]5..0 corresponding to clear bits in
DBREAKC[i]5..0 should also be clear.
For the DBREAK exception, the DBNUM field of the DEBUGCAUSE register records, as a
four bit encoded number, which of the possible DBREAK[i] registers raised the excep-
tion. If more than one DBREAK[i] matches, one of the ones that matched is recorded in
DBNUM.
The processor clears IBREAKENABLE on processor reset; the IBREAKA, DBREAKA, and
DBREAKC registers are undefined after reset.
Typically DEBUGLEVEL is set to NLEVEL (highest priority for maskable interrupts) to al-
low debugging of other exception handlers. DEBUGLEVEL may, in certain cases be set to
a lower level than NLEVEL.
The relation between the current interrupt level (CINTLEVEL, Table 4–63) and the spec-
ified debug interrupt level (DEBUGLEVEL, Table 4–120) determine whether debug inter-
rupts can be taken. All debug exceptions (ICOUNT, IBREAK, DBREAK, BREAK, BREAK.N)
are disabled when CINTLEVEL ≥ DEBUGLEVEL. In this case, the BREAK and BREAK.N
instructions perform no operation.
The ICOUNT register counts instruction completions when CINTLEVEL is less than
ICOUNTLEVEL. Instructions that raise an exception (including the ICOUNT exception) do
not increment ICOUNT. When ICOUNT would increment to 0, it instead generates an
ICOUNT exception. (See "The checkIcount Procedure" on page 203 for the formal spec-
ification.) Because ICOUNT has priority ahead of other exceptions (see
Section 4.4.1.11), it is taken even if another exception would have kept the instruction
from completing and, therefore, ICOUNT from incrementing.
When ICOUNTLEVEL is 1, for example, ICOUNT stops counting when an interrupt or ex-
ception occurs and starts again at the return. Neither the instruction not executed nor
the return increment ICOUNT, but the re-execution of the instruction does. By this
mechanism, the count of instructions can be made the same whether or not the interrupt
or exception is taken. When incrementing is turned on or off by RSIL, WSR.PS, or
XSR.PS instructions, the state of CINTLEVEL and ICOUNTLEVEL before the instruction
begins determines whether or not the increment is done, as well as whether or not the
exception is raised.
The purpose of the ICOUNTLEVEL register is to allow various levels of exception and in-
terrupt processing to be visible or invisible for debugging. An ICOUNTLEVEL setting of 1
causes single-stepping to ignore exceptions and interrupts, whereas setting it to
DEBUGLEVEL allows the programmer to debug exception and interrupt handlers. The
ICOUNTLEVEL register should only be modified while PS.INTLEVEL or PS.EXCM is
high enough that both before and after the change, ICOUNT is not incrementing.
This discussion applies for SZICOUNT=32. If SZICOUNT=2, then the upper bits appear
as all ones for all purposes of reading with RSR and for comparing. In that case,
WSR.ICOUNT affects only the lower two bits. The result is that the feature is really only
useful for single stepping because it cannot count very far. But in other respects it be-
haves in the same fashion.
ICOUNTLEVEL is undefined after reset. The ICOUNT register should be read or written
only when CINTLEVEL is greater than or equal to ICOUNTLEVEL, where the ICOUNT
register is not incrementing (see Table 5–173).
Like all special registers, the IBREAKA, IBREAKENABLE, DBREAKA, DBREAKC, and
ICOUNT registers are read and written using the RSR, WSR, and XSR instructions.
Figure 4–52 shows the format of the DBREAKC registers and Table 4–125 shows the
DBREAKC[i] register fields.
31 30 29 6 5 0
SB LB reserved MASK
1 1 6
The debug data register (DDR) allows communication between a debug supervisor exe-
cuting on the processor and a debugger executing on a remote host. To stop an execut-
ing program being debugged, the external debugger may use a debug interrupt. Debug
interrupts share the same vector as other debug exceptions
(InterruptVector[DEBUGLEVEL]), but are distinguished by the setting of the DI bit of the
DEBUGCAUSE register. Both the DDR register and the debug interrupt are only available
with the OCD option (see the Tensilica On-Chip Debugging Guide).
The INTENABLE register (see Section 4.4.4) does not contain a bit for the debug inter-
rupt.
procedure checkIcount ()
if CINTLEVEL < ICOUNTLEVEL then
if ICOUNT ≠ -1 then
ICOUNT ← ICOUNT + 1
elseif CINTLEVEL < DEBUGLEVEL then
-- Exception
DEBUGCAUSE ← 1
EPC[DEBUGLEVEL] ← PC
EPS[DEBUGLEVEL] ← PS
PC ← InterruptVector[DEBUGLEVEL]
PS.EXCM ← 1
PS.INTLEVEL ← DEBUGLEVEL
endif
endif
endprocedure checkIcount
The Trace Port Option provides outputs for tracing the processor’s activity without the
affect on processor timing that would happen with software profiling. For more informa-
tion on this option, see the Xtensa Microprocessor Data Book. Because the Trace Port
Option provides only additional outputs, it adds only the few architectural features listed
below.
Prerequisites: None
Incompatible options: None
The MMID register is a write only location whose contents affect the output to the trace
port and help in decoding the trace output by defining the which memory map is in force.
5. Processor State
The architectural state of an Xtensa machine consists of its AR register file, a PC, Special
Registers, User Registers, TLB entries, and additional register files (added by options
and designer’s TIE). The Windowed Register Option causes an increase in the physical
size of the AR register file but does not change the number of registers visible by instruc-
tions at any given time. To a lesser extent, caches and local memories can be consid-
ered in some ways to be architectural state. The subsections of this chapter cover each
of these categories of state in turn.
The Floating-Point Coprocessor Option adds the FR register file and two User Registers
called FCR and FSR. The Region Protection Option and the MMU Option add ITLB En-
tries and DTLB Entries. Other options add only Special Registers. Designer’s TIE may
add User Registers, and additional register files. Only the AR register file, the PC, and
SAR are in all Xtensa processors.
Table 5–127 contains an alphabetical list of all Tensilica-defined registers that make up
Xtensa processor state, including the registers added by all architectural options. The
Special Register number column of most entries contains a Special Register number,
which can be looked up in Section 5.3 for more information. The last column contains a
reference where more information can be found in the pages following the table.
These general registers are named address registers (AR) to distinguish them from the
many different types of data registers that can be added to the instruction set
(Section 5.6). Although the AR registers can be used to hold data as well, they are in-
volved with both the instruction set and the execution pipeline in such a way as to make
them ideally suited to contain addresses and the information used to compute address-
es. They are ideally suited to computing branch conditions and targets as well, and as
such fill the role of general registers in the Xtensa instruction set.
When the Windowed Register Option is enabled, there are actually more than sixteen
registers in the AR register file. The windowed register ABI, described in Section 8.1,
can be used in combination with the Windowed Register Option to make use of the addi-
tional registers and avoid many of the register saves and restores that would normally
be associated with calls and returns. This improves both the speed and the code density
of Xtensa processors.
Reads from and writes to the AR register file are always interlocked by hardware. No
synchronization instructions are ever required by them.
Section 5.3.1 describes the process of reading and writing these special registers, while
the sections that follow describe groups of specific Special Registers in more detail. A
table is included for each special register, which includes information specific to that
special register. The gray shaded rows describe the information that is contained in the
unshaded rows immediately below them.
The first row shows the Special Register number, the Name (which is used in the RSR.*,
WSR.*, and XSR.* instruction names), a short description, and the value immediately
after reset.
The second row shows the Option that creates the Special Register, the count or num-
ber of such special registers, the number of bits in the special register, whether access
to the register is privileged (requires CRING=0) or not, and whether XSR.* is a legal in-
struction or not. The Option that creates the Special Register is described in Chapter 4
including more information on each Special Register.
The third row shows the function of the WSR.* and RSR.* instructions for this Special
Register. The function of the XSR.* instruction is the combination of the RSR.* and the
WSR.* instructions.
The fourth row shows the other instructions that affect or are affected by this Special
Register.
The last row of each Special Register’s table shows what SYNC instructions are
required when using this Special Register. If no SYNC instructions are ever required, the
row is left out. On the left is an instruction or other action that changes the value of the
Special Register. On the right is an instruction or other action that makes use of the val-
ue of the Special Register. If a SYNC instruction is required for this pair of operations to
work as they should, it is listed in the middle. Wherever a DSYNC is required an ISYNC,
RSYNC, or ESYNC can also be used. Wherever an ESYNC is required an ISYNC or RSYNC
can also be used. Wherever an RSYNC is required an ISYNC can also be used. Note that
the 16-bit versions (*.N) of 24-bit instructions are not listed separately but always have
exactly the same requirements. Versions T1050 and before required additional SYNC
instructions in some cases as described in Section A.8 on page 621.
Because of the importance of its subfields, the PS Special Register is a special case. Its
subfields are listed in the same format as special registers. The synchronizations need-
ed simply because the register has been written are listed under the entire register,
while the synchronizations needed because the value of a subfield has been changed
are listed under the subfield.
The RSR.*, WSR.*, and XSR.* instructions access the special registers. The accesses
to the Special Registers act as separate instructions in many ways. For the full instruc-
tion name, replace the ‘*’ in the instructions with the name as given in the Special
Register Tables in this section.
Each RSR.* instruction moves a value from a Special Register to a general (AR) regis-
ter. Each WSR.* instruction moves a value from a general (AR) register to a Special Reg-
ister. Each XSR.* instruction exchanges the values in a general (AR) register and a Spe-
cial Register. Some Special Registers do not allow this exchange. The Special Register
tables in this section show which do and do not allow this exchange. The exchange
takes place with the two reads taking place first, and then the two writes. In some cases,
the write of a Special Register can affect other behavior of the processor. In general, this
behavior change does not occur until after the instruction (including XSR.*) has com-
pleted execution.
Some of the Special Registers have interactions with other instructions or with hardware
execution. These interactions are also listed in the Special Register tables in this sec-
tion. Because modification of many Special Registers is an unusual occurrence, syn-
chronization instructions are used to ensure that their values have propagated every-
where before certain other actions are allowed to take place. Some of the interlocks
would be costly in performance or in gates if done in hardware, and the synchronization
instructions can be the most efficient solution.
The Loop Option adds the three registers shown in Table 5–129 through Table 5–131 for
controlling zero overhead loops. When the PC reaches LEND, it executes at LBEG in-
stead and decrements LCOUNT. When LCOUNT reaches zero, the loop back does not oc-
cur.
The MAC16 Option adds the six registers described in Table 5–132 through
Table 5–134.
The SAR Special Register is included in the Xtensa Core Architecture, while the BR,
LITBASE, and SCOMPARE1 Special Registers are added by the options shown along
with other information about them in Table 5–135 through Table 5–138.
The Processor Status Special Register is made up of multiple fields with different pur-
poses within the processor. They are combined into one register to simplify the saving
and restoring of state for exceptions, interrupts, and context switches. Table 5–139
describes the register as a whole, while Table 5–140 through Table 5–146 describe the
individual pieces of the register in a similar format.
The synchronization section of Table 5–139 gives requirements that must be met when-
ever the PS register is written regardless of whether any of its bits are changed. The
synchronization sections of Table 5–140 through Table 5–146 give requirements that
must be met only if that portion of the PS register is being modified.
The Windowed Register Option Special registers are described in Table 5–147 and
Table 5–148.
The Special Registers for managing memory are described in Table 5–149 through
Table 5–152.
The Special Registers that provide information for the handling of an exception are
described in Table 5–153 through Table 5–159.
The Special Registers that save the PC and PS values and an initial register value for
each of the levels are described in Table 5–160 through Table 5–162.
The Special Registers that manage interrupt handling are described in Table 5–169
through Table 5–172.
The Special Registers that manage instruction counting and cycle counting, including
timer interrupts are described in Table 5–173 through Table 5–176.
The Special Registers that manage the handling of breakpoint exceptions are described
in Table 5–177 through Table 5–180.
The Special Registers for other purposes are described in Table 5–181 through
Table 5–186.
Use the RUR.* and WUR.* instructions to access the user registers. The accesses to
the User Registers act as separate instructions in many ways. Replace the ‘*’ in the in-
structions with the name of the User Register as specified by the designer or given in
Table 5–189 and Table 5–190.
RUR.* instructions move values from a User Register to a general (AR) register. WUR.*
instructions move values from a general (AR) register to a User Register. The User Reg-
isters are fully interlocked in hardware and do not need SYNC instructions.
Table 5–188 throughTable 5–190 list detailed information for each of the User Registers
that Tensilica Options define.
The first row shows the User Register number, the name (which is used in the RUR.*,
WUR.* instruction names), a short description, and the value immediately after reset.
The second row shows the Option that creates the User Register, the count or number
of such User Registers, the number of bits in the User Register, and whether access to
the register is privileged (requires CRING=0) or not. The option that creates the User
Register is described in Chapter 4 including more information on each User Register.
The third row shows the function of the WUR.* and RUR.* instructions for this User Reg-
ister.
The fourth row shows the other instructions that affect or are affected by this User Reg-
ister.
The last row of each User Register’s table shows that SYNC instructions are not
required.
User Registers 0-223 are reserved for designer’s use, and are never used by Tensilica
Options. User Registers 224-255 can be used by a designer but their use may prohibit
compatibility with some Tensilica-provided Options either now or in the future. Additional
state registers may be added without built-in access instructions.
These entries are accessed by special instructions for reading and writing the entries.
There are also instructions for probing to see if an entry exists that will match a particu-
lar virtual address. In addition, there are instructions for invalidating particular entries.
The instructions added for these purposes are listed under the Region Protection Option
and the MMU Option.
After changing an Instruction TLB entry, an ISYNC must be executed before executing
any instruction that is accessed using that TLB. After changing a data TLB entry, a
DSYNC must be executed before any load or store that uses that entry (see
Section 4.6.3.3, Section 4.6.4.2, Section 4.6.5.5, and Section 4.6.5.8 for more detailed
information).
As shown in Table 5–127, the Floating-Point Coprocessor Option creates the FR register
file, which is an instance of this capability in a Tensilica-provided Option. The FR register
file contains sixteen registers of 32 bits each in support of the floating point instruction
set. There is no windowing in the FR register file.
Reads from and writes to these additional register files are always interlocked by hard-
ware. No synchronization instructions are ever required by them.
The contents of these additional register files are undefined after reset.
Section 4.5.2 through Section 4.5.12 describe the options for adding caches and local
memories to Xtensa processors.
In addition, because the instruction unit of the Xtensa processor fetches ahead, syn-
chronization instructions are needed whenever an instruction local memory or instruc-
tion cache is modified before it can be certain that the instruction fetch engine will see
the changes. For local memories, this means an ISYNC instruction is needed after any
change to the instruction memory and before the execution of any instruction involved in
the change. For instruction caches, this means an ISYNC instruction is needed after any
change to the cache data, or the cache tag (including the invalidation required when
main memory that could possibly be held in the icache is modified) and before the exe-
cution of any instruction involved in the change.
The operation of all instructions to data local memory or data cache is fully interlocked in
hardware. And except for the instruction fetch discussed above, the operation of all in-
structions to instruction local memory or instruction cache is fully interlocked in hard-
ware. Loads and stores, tag accesses, cache invalidations, cache line locks/unlocks,
prefetches, and write backs all operate in order to the same cache locations because of
the hardware interlocking. Accesses to different addresses are not necessarily in order
(see Section 4.3.12.1).
Both the data and the tag stores of instruction caches and data caches are ordinary syn-
chronous SRAMs, which are not expected to be defined after reset.
This chapter describes, in alphabetical order, each of the Xtensa ISA instructions in the
Core Architecture described in Chapter 3, or in Architecture Options described in
Chapter 4.
Before reading this chapter, Tensilica recommends reviewing the notation defined in
Table 2–6 on page 21, Uses Of Instruction Fields.
Note that instructions with a “Required Configuration Option” specification other than
“Core Architecture” are illegal if the corresponding option is not enabled, and will raise
an illegal instruction exception.
The instruction word included with each instruction is the little-endian version (see
Section 2.1 “Bit and Byte Order” and Chapter 7 "Instruction Formats and Opcodes" on
page 569). The big-endian instruction word may be determined for any instruction by
separating the little-endian instruction word at the vertical bars and reassembling the
pieces in the reverse order. For example, following is the little-endian instruction word
shown on page 273 for the BEQI instruction:
23 16 15 12 11 8 7 6 5 4 3 0
imm8 r s 0 0 1 0 0 1 1 0
8 4 4 2 2 4
Following is the derived big-endian instruction word for the BEQI instruction:
0 3 4 5 6 7 8 11 12 15 16 23
0 1 1 0 1 0 0 0 s r imm8
4 2 2 4 4 8
The format listed after the instruction word at the top of each instruction page can also
be used along with Section 7.1 “Formats” to derive the big-endian encoding.
For each instruction, the exceptions that can possibly result from its execution are listed.
Because many of the potential exceptions are common to a large number of instruc-
tions, exception groups are used to save space and improve understanding. Following
are the common exception groups that are referenced in the instructions. A reference to
one of these groups means that any of the exceptions in the group can be raised by that
instruction. Note that the groups often include previous groups.
EveryInst Group:
GenExcep(InstructionFetchErrorCause) if Exception Option
GenExcep(InstTLBMissCause) if Region Protection Option or MMU Option
GenExcep(InstTLBMultiHitCause) if Region Protection Option or MMU Option
GenExcep(InstFetchPrivilegeCause) if Region Protection Option or MMU Option
GenExcep(InstFetchProhibitedCause) if Region Protection Option or MMU Option
MemoryErrorException on Instruction-fetch if Memory ECC/Parity Option
DebugExcep(ICOUNT) if Debug Option
DebugExcep(IBREAK) if Debug Option
EveryInstR Group:
EveryInst Group (see page 244)
WindowOverExcep if Windowed Register Option
Memory Group:
EveryInstR Group (see page 244)
GenExcep(LoadStoreErrorCause) if Exception Option
GenExcep(LoadStoreTLBMissCause) if Region Protection Option or MMU Option
GenExcep(LoadStoreTLBMultiHitCause) if Region Protection Option or MMU Option
GenExcep(LoadStorePrivilegeCause) if Region Protection Option or MMU Option
MemoryErrorException on non-Instruction-fetch if Memory ECC/Parity Option
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 0 0 0 0 0 r 0 0 0 1 t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ABS ar, at
Description
ABS calculates the absolute value of the contents of address register at and writes it to
address register ar. Arithmetic overflow is not detected.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 1 0 1 0 r s 0 0 0 1 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ABS.S fr, fs
Description
Operation
FR[r] ← abss(FR[s])
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 0 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ADD calculates the two’s complement 32-bit sum of address registers as and at. The
low 32 bits of the sum are written to address register ar. Arithmetic overflow is not
detected.
ADD is a 24-bit instruction. The ADD.N density-option instruction performs the same
operation in a 16-bit encoding.
Assembler Note
The assembler may convert ADD instructions to ADD.N when the Code Density Option is
enabled. Prefixing the ADD instruction with an underscore (_ADD) disables this optimiza-
tion and forces the assembler to generate the wide form of the instruction.
Operation
Exceptions
15 12 11 8 7 4 3 0
r s t 1 0 1 0
4 4 4 4
Assembler Syntax
Description
This performs the same operation as the ADD instruction in a 16-bit encoding.
ADD.N calculates the two’s complement 32-bit sum of address registers as and at. The
low 32 bits of the sum are written to address register ar. Arithmetic overflow is not
detected.
Assembler Note
The assembler may convert ADD.N instructions to ADD. Prefixing the ADD.N instruction
with an underscore (_ADD.N) disables this optimization and forces the assembler to
generate the narrow form of the instruction.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 1 0 0 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
ADDI calculates the two’s complement 32-bit sum of address register as and a constant
encoded in the imm8 field. The low 32 bits of the sum are written to address register at.
Arithmetic overflow is not detected.
The immediate operand encoded in the instruction can range from -128 to 127. It is de-
coded by sign-extending imm8.
Assembler Note
The assembler may convert ADDI instructions to ADDI.N when the Code Density
Option is enabled and the immediate operand falls within the available range. If the im-
mediate is too large the assembler may substitute an equivalent sequence. Prefixing the
ADDI instruction with an underscore (_ADDI) disables these optimizations and forces
the assembler to generate the wide form of the instruction or an error instead.
Operation
Exceptions
15 12 11 8 7 4 3 0
r s t 1 0 1 1
4 4 4 4
Assembler Syntax
Description
ADDI.N is similar to ADDI, but has a 16-bit encoding and supports a smaller range of
immediate operand values encoded in the instruction word.
ADDI.N calculates the two’s complement 32-bit sum of address register as and an
operand encoded in the t field. The low 32 bits of the sum are written to address regis-
ter ar. Arithmetic overflow is not detected.
The operand encoded in the instruction can be -1 or one to 15. If t is zero, then a value
of -1 is used, otherwise the value is the zero-extension of t.
Assembler Note
The assembler may convert ADDI.N instructions to ADDI. Prefixing the ADDI.N instruc-
tion with an underscore (_ADDI.N) disables this optimization and forces the assembler
to generate the narrow form of the instruction. In the assembler syntax, the number to
be added to the register operand is specified. When the specified value is -1, the assem-
bler encodes it as zero.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 1 0 1 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
ADDMI extends the range of constant addition. It is often used in conjunction with load
and store instructions to extend the range of the base, plus offset the calculation.
ADDMI calculates the two’s complement 32-bit sum of address register as and an oper-
and encoded in the imm8 field. The low 32 bits of the sum are written to address register
at. Arithmetic overflow is not detected.
The operand encoded in the instruction can have values that are multiples of 256 rang-
ing from -32768 to 32512. It is decoded by sign-extending imm8 and shifting the result
left by eight bits.
Assembler Note
In the assembler syntax, the value to be added to the register operand is specified. The
assembler encodes this into the instruction by dividing by 256.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 1 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ADDX2 calculates the two’s complement 32-bit sum of address register as shifted left by
one bit and address register at. The low 32 bits of the sum are written to address regis-
ter ar. Arithmetic overflow is not detected.
ADDX2 is frequently used for address calculation and as part of sequences to multiply by
small constants.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 0 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ADDX4 calculates the two’s complement 32-bit sum of address register as shifted left by
two bits and address register at. The low 32 bits of the sum are written to address reg-
ister ar. Arithmetic overflow is not detected.
ADDX4 is frequently used for address calculation and as part of sequences to multiply by
small constants.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 1 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ADDX8 calculates the two’s complement 32-bit sum of address register as shifted left by
3 bits and address register at. The low 32 bits of the sum are written to address register
ar. Arithmetic overflow is not detected.
ADDX8 is frequently used for address calculation and as part of sequences to multiply by
small constants.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 1 0 0 1 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ALL4 bt, bs
Description
ALL4 sets Boolean register bt to the logical and of the four Boolean registers bs+0,
bs+1, bs+2, and bs+3. bs must be a multiple of four (b0, b4, b8, or b12); otherwise the
operation of this instruction is not defined. ALL4 reduces four test results such that the
result is true if all four tests are true.
When the sense of the bs Booleans is inverted (0 → true, 1 → false), use ANY4 and an
inverted test of the result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 1 0 1 1 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ALL8 bt, bs
Description
ALL8 sets Boolean register bt to the logical and of the eight Boolean registers bs+0,
bs+1, … bs+6, and bs+7. bs must be a multiple of eight (b0 or b8); otherwise the oper-
ation of this instruction is not defined. ALL8 reduces eight test results such that the re-
sult is true if all eight tests are true.
When the sense of the bs Booleans is inverted (0 → true, 1 → false), use ANY8 and an
inverted test of the result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 1 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
AND calculates the bitwise logical and of address registers as and at. The result is
written to address register ar.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ANDB performs the logical and of Boolean registers bs and bt and writes the result to
Boolean register br.
When the sense of one of the source Booleans is inverted (0 → true, 1 → false), use
ANDBC. When the sense of both of the source Booleans is inverted, use ORB and an
inverted test of the result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 1 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ANDBC performs the logical and of Boolean register bs with the logical complement of
Boolean register bt, and writes the result to Boolean register br.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 1 0 0 0 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ANY4 bt, bs
Description
ANY4 sets Boolean register bt to the logical or of the four Boolean registers bs+0,
bs+1, bs+2, and bs+3. bs must be a multiple of four (b0, b4, b8, or b12); otherwise the
operation of this instruction is not defined. ANY4 reduces four test results such that the
result is true if any of the four tests are true.
When the sense of the bs Booleans is inverted (0 → true, 1 → false), use ALL4 and an
inverted test of the result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 1 0 1 0 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ANY8 bt, bs
Description
ANY8 sets Boolean register bt to the logical or of the eight Boolean registers bs+0,
bs+1, … bs+6, and bs+7. bs must be a multiple of eight (b0 or b8); otherwise the oper-
ation of this instruction is not defined. ANY8 reduces eight test results such that the re-
sult is true if any of the eight tests are true.
When the sense of the bs Booleans is inverted (0 → true, 1 → false), use ALL8 and an
inverted test of the result.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 0 0 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BALL branches if all the bits specified by the mask in address register at are set in ad-
dress register as. The test is performed by taking the bitwise logical and of at and the
complement of as, and testing if the result is zero.
The target instruction address of the branch is given by the address of the BALL instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If any of the
masked bits are clear, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BALL) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 0 0 0 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BANY branches if any of the bits specified by the mask in address register at are set in
address register as. The test is performed by taking the bitwise logical and of as and at
and testing if the result is non-zero.
The target instruction address of the branch is given by the address of the BANY instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If all of the
masked bits are clear, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BANY) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 0 1 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BBC branches if the bit specified by the low five bits of address register at is clear in ad-
dress register as. For little-endian processors, bit 0 is the least significant bit and bit 31
is the most significant bit. For big-endian processors, bit 0 is the most significant bit and
bit 31 is the least significant bit.
The target instruction address of the branch is given by the address of the BBC instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the specified
bit is set, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BBC) disables this
feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
8 4 4 4 4
Assembler Syntax
Description
BBCI branches if the bit specified by the constant encoded in the bbi field of the in-
struction word is clear in address register as. For little-endian processors, bit 0 is the
least significant bit and bit 31 is the most significant bit. For big-endian processors bit 0
is the most significant bit and bit 31 is the least significant bit. The bbi field is split, with
bits 3..0 in bits 7..4 of the instruction word, and bit 4 in bit 12 of the instruction word.
The target instruction address of the branch is given by the address of the BBCI instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the specified
bit is set, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BBCI) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
8 4 4 4 4
Assembler Macro
Assembler Syntax
Description
BBCI.L is an assembler macro for BBCI that always uses little-endian bit numbering.
That is, it branches if the bit specified by its immediate is clear in address register as,
where bit 0 is the least significant bit and bit 31 is the most significant bit.
Assembler Note
For little-endian processors, BBCI.L and BBCI are identical. For big-endian processors,
the assembler will convert BBCI.L instructions to BBCI by changing the encoded imme-
diate value to 31-imm.
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 1 0 1 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BBS branches if the bit specified by the low five bits of address register at is set in ad-
dress register as. For little-endian processors, bit 0 is the least significant bit and bit 31
is the most significant bit. For big-endian processors, bit 0 is the most significant bit and
bit 31 is the least significant bit.
The target instruction address of the branch is given by the address of the BBS instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the specified
bit is clear, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BBS) disables this
feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
8 4 4 4 4
Assembler Syntax
Description
BBSI branches if the bit specified by the constant encoded in the bbi field of the in-
struction word is set in address register as. For little-endian processors, bit 0 is the least
significant bit and bit 31 is the most significant bit. For big-endian processors, bit 0 is the
most significant bit and bit 31 is the least significant bit. The bbi field is split, with bits
3..0 in bits 7..4 of the instruction word, and bit 4 in bit 12 of the instruction word.
The target instruction address of the branch is given by the address of the BBSI instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the specified
bit is clear, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BBSI) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
8 4 4 4 4
Assembler Macro
Assembler Syntax
Description
BBSI.L is an assembler macro for BBSI that always uses little-endian bit numbering.
That is, it branches if the bit specified by its immediate is set in address register as,
where bit 0 is the least significant bit and bit 31 is the most significant bit.
Assembler Note
For little-endian processors, BBSI.L and BBSI are identical. For big-endian processors,
the assembler will convert BBSI.L instructions to BBSI by changing the encoded imme-
diate value to 31-imm.
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 0 1 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
The target instruction address of the branch is given by the address of the BEQ instruc-
tion plus the sign-extended 8-bit imm8 field of the instruction plus four. If the registers
are not equal, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BEQ) disables this
feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 6 5 4 3 0
imm8 r s 0 0 1 0 0 1 1 0
8 4 4 2 2 4
Assembler Syntax
Description
BEQI branches if address register as and a constant encoded in the r field are equal.
The constant values encoded in the r field are not simply 0..15. For the constant values
that can be encoded by r, see Table 3–17 on page 41.
The target instruction address of the branch is given by the address of the BEQI instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the register is
not equal to the constant, execution continues with the next sequential instruction.
Assembler Note
The assembler may convert BEQI instructions to BEQZ or BEQZ.N when given an imme-
diate operand that evaluates to zero. The assembler will substitute an equivalent se-
quence of instructions when the label is out of range. Prefixing the instruction mnemonic
with an underscore (_BEQI) disables these features and forces the assembler to gener-
ate an error instead.
Operation
Exceptions
23 12 11 8 7 6 5 4 3 0
imm12 s 0 0 0 1 0 1 1 0
12 4 2 2 4
Assembler Syntax
Description
BEQZ branches if address register as is equal to zero. BEQZ provides 12 bits of target
range instead of the eight bits available in most conditional branches.
The target instruction address of the branch is given by the address of the BEQZ instruc-
tion, plus the sign-extended 12-bit imm12 field of the instruction plus four. If register as
is not equal to zero, execution continues with the next sequential instruction.
Assembler Note
The assembler may convert BEQZ instructions to BEQZ.N when the Code Density
Option is enabled and the branch target is reachable with the shorter instruction. The
assembler will substitute an equivalent sequence of instructions when the label is out of
range. Prefixing the instruction mnemonic with an underscore (_BEQZ) disables these
features and forces the assembler to generate the wide form of the instruction and an
error when the label is out of range).
Operation
Exceptions
15 12 11 8 7 4 3 0
imm63..0 s 1 0 imm65..4 1 1 0 0
4 4 4 4
Assembler Syntax
Description
This performs the same operation as the BEQZ instruction in a 16-bit encoding. BEQZ.N
branches if address register as is equal to zero. BEQZ.N provides six bits of target
range instead of the 12 bits available in BEQZ.
The target instruction address of the branch is given by the address of the BEQZ.N in-
struction, plus the zero-extended 6-bit imm6 field of the instruction plus four. Because
the offset is unsigned, this instruction can only be used to branch forward. If register as
is not equal to zero, execution continues with the next sequential instruction.
Assembler Note
The assembler may convert BEQZ.N instructions to BEQZ. The assembler will substitute
an equivalent sequence of instructions when the label is out of range. Prefixing the in-
struction mnemonic with an underscore (_BEQZ.N) disables these features and forces
the assembler to generate the narrow form of the instruction and an error when the label
is out of range.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 0 0 s 0 1 1 1 0 1 1 0
8 4 4 4 4
Assembler Syntax
BF bs, label
Description
The target instruction address of the branch is given by the address of the BF instruction
plus the sign-extended 8-bit imm8 field of the instruction plus four. If the Boolean register
bs is true, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BF) disables this
feature and forces the assembler to generate an error when the label is out of range.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 0 1 0 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BGE branches if address register as is two’s complement greater than or equal to ad-
dress register at.
The target instruction address of the branch is given by the address of the BGE instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the address
register as is less than address register at, execution continues with the next sequen-
tial instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BGE) disables this
feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 6 5 4 3 0
imm8 r s 1 1 1 0 0 1 1 0
8 4 4 2 2 4
Assembler Syntax
Description
BGEI branches if address register as is two’s complement greater than or equal to the
constant encoded in the r field. The constant values encoded in the r field are not sim-
ply 0..15. For the constant values that can be encoded by r, see Table 3–17 on page 41.
The target instruction address of the branch is given by the address of the BGEI instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the address
register as is less than the constant, execution continues with the next sequential
instruction.
Assembler Note
The assembler may convert BGEI instructions to BGEZ when given an immediate oper-
and that evaluates to zero. The assembler will substitute an equivalent sequence of in-
structions when the label is out of range. Prefixing the instruction mnemonic with an un-
derscore (_BGEI) disables these features and forces the assembler to generate an error
instead.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 0 1 1 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BGEU branches if address register as is unsigned greater than or equal to address reg-
ister at.
The target instruction address of the branch is given by the address of the BGEU instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the address
register as is unsigned less than address register at, execution continues with the next
sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BGEU) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 6 5 4 3 0
imm8 r s 1 1 1 1 0 1 1 0
8 4 4 2 2 4
Assembler Syntax
Description
BGEUI branches if address register as is unsigned greater than or equal to the constant
encoded in the r field. The constant values encoded in the r field are not simply 0..15.
For the constant values that can be encoded by r, see Table 3–18 on page 42.
The target instruction address of the branch is given by the address of the BGEUI in-
struction plus the sign-extended 8-bit imm8 field of the instruction plus four. If the ad-
dress register as is less than the constant, execution continues with the next sequential
instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BGEUI) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 12 11 8 7 6 5 4 3 0
imm12 s 1 1 0 1 0 1 1 0
12 4 2 2 4
Assembler Syntax
Description
BGEZ branches if address register as is greater than or equal to zero (the most signifi-
cant bit is clear). BGEZ provides 12 bits of target range instead of the eight bits available
in most conditional branches.
The target instruction address of the branch is given by the address of the BGEZ instruc-
tion plus the sign-extended 12-bit imm12 field of the instruction plus four. If register as is
less than zero, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BGEZ) disables
this feature and forces the assembler to generate an error in this case.
Operation
if AR[s]31 = 0 then
nextPC ← PC + (imm121120||imm12) + 4
endif
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 1 0 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BLT branches if address register as is two’s complement less than address register at.
The target instruction address of the branch is given by the address of the BLT instruc-
tion plus the sign-extended 8-bit imm8 field of the instruction plus four. If the address
register as is greater than or equal to address register at, execution continues with the
next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BLT) disables this
feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 6 5 4 3 0
imm8 r s 1 0 1 0 0 1 1 0
8 4 4 2 2 4
Assembler Syntax
Description
BLTI branches if address register as is two’s complement less than the constant encod-
ed in the r field. The constant values encoded in the r field are not simply 0..15. For the
constant values that can be encoded by r, see Table 3–17 on page 41.
The target instruction address of the branch is given by the address of the BLTI instruc-
tion plus the sign-extended 8-bit imm8 field of the instruction plus four. If the address
register as is greater than or equal to the constant, execution continues with the next
sequential instruction.
Assembler Note
The assembler may convert BLTI instructions to BLTZ when given an immediate oper-
and that evaluates to zero. The assembler will substitute an equivalent sequence of in-
structions when the label is out of range. Prefixing the instruction mnemonic with an un-
derscore (_BLTI) disables these features and forces the assembler to generate an error
instead.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 1 1 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BLTU branches if address register as is unsigned less than address register at.
The target instruction address of the branch is given by the address of the BLTU instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the address
register as is greater than or equal to address register at, execution continues with the
next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BLTU) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 6 5 4 3 0
imm8 r s 1 0 1 1 0 1 1 0
8 4 4 2 2 4
Assembler Syntax
Description
BLTUI branches if address register as is unsigned less than the constant encoded in
the r field. The constant values encoded in the r field are not simply 0..15. For the
constant values that can be encoded by r, see Table 3–18 on page 42.
The target instruction address of the branch is given by the address of the BLTUI in-
struction, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the ad-
dress register as is greater than or equal to the constant, execution continues with the
next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BLTUI) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 12 11 8 7 6 5 4 3 0
imm12 s 1 0 0 1 0 1 1 0
12 4 2 2 4
Assembler Syntax
Description
BLTZ branches if address register as is less than zero (the most significant bit is set).
BLTZ provides 12 bits of target range instead of the eight bits available in most condi-
tional branches.
The target instruction address of the branch is given by the address of the BLTZ instruc-
tion, plus the sign-extended 12-bit imm12 field of the instruction plus four. If register as
is greater than or equal to zero, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BLTZ) disables
this feature and forces the assembler to generate an error in this case.
Operation
if AR[s]31 ≠ 0 then
nextPC ← PC + (imm121120||imm12) + 4
endif
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 1 0 0 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BNALL branches if any of the bits specified by the mask in address register at are clear
in address register as (that is, if they are not all set). The test is performed by taking the
bitwise logical and of at with the complement of as and testing if the result is non-zero.
The target instruction address of the branch is given by the address of the BNALL in-
struction, plus the sign-extended 8-bit imm8 field of the instruction plus four. If all of the
masked bits are set, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BNALL) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 0 0 1 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
The target instruction address of the branch is given by the address of the BNE instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the registers
are equal, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BNE) disables this
feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 16 15 12 11 8 7 6 5 4 3 0
imm8 r s 0 1 1 0 0 1 1 0
8 4 4 2 2 4
Assembler Syntax
Description
BNEI branches if address register as and a constant encoded in the r field are not
equal. The constant values encoded in the r field are not simply 0..15. For the constant
values that can be encoded by r, see Table 3–17 on page 41.
The target instruction address of the branch is given by the address of the BNEI instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the register is
equal to the constant, execution continues with the next sequential instruction.
Assembler Note
The assembler may convert BNEI instructions to BNEZ or BNEZ.N when given an imme-
diate operand that evaluates to zero. The assembler will substitute an equivalent se-
quence of instructions when the label is out of range. Prefixing the instruction mnemonic
with an underscore (_BNEI) disables these features and forces the assembler to gener-
ate an error instead.
Operation
Exceptions
23 12 11 8 7 6 5 4 3 0
imm12 s 0 1 0 1 0 1 1 0
12 4 2 2 4
Assembler Syntax
Description
BNEZ branches if address register as is not equal to zero. BNEZ provides 12 bits of tar-
get range instead of the eight bits available in most conditional branches.
The target instruction address of the branch is given by the address of the BNEZ instruc-
tion, plus the sign-extended 12-bit imm12 field of the instruction plus four. If register as
is equal to zero, execution continues with the next sequential instruction.
Assembler Note
The assembler may convert BNEZ instructions to BNEZ.N when the Code Density
Option is enabled and the branch target is reachable with the shorter instruction. The
assembler will substitute an equivalent sequence of instructions when the label is out of
range. Prefixing the instruction mnemonic with an underscore (_BNEZ) disables these
features and forces the assembler to generate the BNEZ form of the instruction and an
error when the label is out of range.
Operation
Exceptions
15 12 11 8 7 4 3 0
imm63..0 s 1 1 imm65..4 1 1 0 0
4 4 4 4
Assembler Syntax
Description
This performs the same operation as the BNEZ instruction in a 16-bit encoding. BNEZ.N
branches if address register as is not equal to zero. BNEZ.N provides six bits of target
range instead of the 12 bits available in BNEZ.
The target instruction address of the branch is given by the address of the BNEZ.N in-
struction, plus the zero-extended 6-bit imm6 field of the instruction plus four. Because
the offset is unsigned, this instruction can only be used to branch forward. If register as
is equal to zero, execution continues with the next sequential instruction.
Assembler Note
The assembler may convert BNEZ.N instructions to BNEZ. The assembler will substitute
an equivalent sequence of instructions when the label is out of range. Prefixing the in-
struction mnemonic with an underscore (_BNEZ.N) disables these features and forces
the assembler to generate the narrow form of the instruction and an error when the label
is out of range.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 0 0 s t 0 1 1 1
8 4 4 4 4
Assembler Syntax
Description
BNONE branches if all of the bits specified by the mask in address register at are clear in
address register as (that is, if none of them are set). The test is performed by taking the
bitwise logical and of as with at and testing if the result is zero.
The target instruction address of the branch is given by the address of the BNONE in-
struction, plus the sign-extended 8-bit imm8 field of the instruction plus four. If any of the
masked bits are set, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BNONE) disables
this feature and forces the assembler to generate an error in this case.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 1 0 0 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
This instruction simply raises an exception when it is executed and PS.INTLEVEL <
DEBUGLEVEL. The high-priority vector for DEBUGLEVEL is used. The DEBUGCAUSE reg-
ister is written as part of raising the exception to indicate that BREAK raised the debug
exception. The address of the BREAK instruction is stored in EPC[DEBUGLEVEL]. The s
and t fields of the instruction word are not used by the processor; they are available for
use by the software. When PS.INTLEVEL ≥ DEBUGLEVEL, BREAK is a no-op.
The BREAK instruction typically calls a debugger when program execution reaches a
certain point (a “breakpoint”). The instruction at the breakpoint is replaced with the
BREAK instruction. To continue execution after a breakpoint is reached, the debugger
must re-write the BREAK to the original instruction, single-step by one instruction, and
then put back the BREAK instruction again.
Writing instructions requires special consideration. See the ISYNC instruction for more
information.
When it is not possible to write the instruction memory (for example, for ROM code), the
IBREAKA feature provides breakpoint capabilities (see Debug Option).
Software can also use BREAK to indicate an error condition that requires the program-
mer’s attention. The s and t fields may encode information about the situation.
Assembler Note
The assembler may convert BREAK instructions to BREAK.N when the Code Density
Option is enabled and the second imm is zero. Prefixing the instruction mnemonic with
an underscore (_BREAK) disables this optimization and forces the assembler to gener-
ate the wide form of the instruction.
Operation
Exceptions
15 12 11 8 7 4 3 0
1 1 1 1 s 0 0 1 0 1 1 0 1
4 4 4 4
Debug Option (See Section 4.7.6 on page 197) and Code Density Option (See
Section 4.3.1 on page 53)
Assembler Syntax
BREAK.N 0..15
Description
Assembler Note
The assembler may convert BREAK.N instructions to BREAK. Prefixing the BREAK.N
instruction with an underscore (_BREAK.N) disables this optimization and forces the
assembler to generate the narrow form of the instruction.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 0 1 s 0 1 1 1 0 1 1 0
8 4 4 4 4
Assembler Syntax
BT bs, label
Description
The target instruction address of the branch is given by the address of the BT instruc-
tion, plus the sign-extended 8-bit imm8 field of the instruction plus four. If the Boolean
register bs is false, execution continues with the next sequential instruction.
Assembler Note
The assembler will substitute an equivalent sequence of instructions when the label is
out of range. Prefixing the instruction mnemonic with an underscore (_BT) disables this
feature and forces the assembler to generate an error when the label is out of range.
Operation
if BRs then
nextPC ← PC + (imm8724||imm8) + 4
endif
Exceptions
23 6 5 4 3 0
offset 0 0 0 1 0 1
18 2 4
Assembler Syntax
CALL0 label
Description
CALL0 calls subroutines without using register windows. The return address is placed in
a0, and the processor then branches to the target address. The return address is the
address of the CALL0 instruction plus three.
The target instruction address must be 32-bit aligned. This allows CALL0 to have a larg-
er effective range (-524284 to 524288 bytes). The target instruction address of the call is
given by the address of the CALL0 instruction with the least significant two bits set to
zero plus the sign-extended 18-bit offset field of the instruction shifted by two, plus
four.
The RET and RET.N instructions are used to return from a subroutine called by CALL0.
See the CALLX0 instruction (page 304) for calling routines where the target address is
given by the contents of a register.
To call using the register window mechanism, see the CALL4, CALL8, and CALL12 in-
structions.
Operation
AR[0] ← PC + 3
nextPC ← (PC31..2 + (offset1712||offset) + 1)||00
Exceptions
23 6 5 4 3 0
offset 0 1 0 1 0 1
18 2 4
Assembler Syntax
CALL4 label
Description
CALL4 calls subroutines using the register windows mechanism, requesting the callee
rotate the window by four registers. The CALL4 instruction does not rotate the window it-
self, but instead stores the window increment for later use by the ENTRY instruction. The
return address and window increment are placed in the caller’s a4 (the callee’s a0), and
the processor then branches to the target address. The return address is the address of
the next instruction (the address of the CALL4 instruction plus three). The window incre-
ment is also stored in the CALLINC field of the PS register, where it is accessed by the
ENTRY instruction.
The target instruction address must be a 32-bit aligned ENTRY instruction. This allows
CALL4 to have a larger effective range (−524284 to 524288 bytes). The target instruc-
tion address of the call is given by the address of the CALL4 instruction with the two
least significant bits set to zero plus the sign-extended 18-bit offset field of the instruc-
tion shifted by two, plus four.
See the CALLX4 instruction for calling routines where the target address is given by the
contents of a register.
Use the RETW and RETW.N instructions to return from a subroutine called by CALL4.
The window increment stored with the return address register in a4 occupies the two
most significant bits of the register, and therefore those bits must be filled in by the sub-
routine return. The RETW and RETW.N instructions fill in these bits from the two most sig-
nificant bits of their own address. This prevents register-window calls from being used to
call a routine in a different 1GB region of the address space.
See the CALL0 instruction for calling routines using the non-windowed subroutine proto-
col.
The caller’s a4..a15 are the same registers as the callee’s a0..a11 after the callee
executes the ENTRY instruction. You can use these registers for parameter passing. The
caller’s a0..a3 are hidden by CALL4, and therefore you can use them to keep values
that are live across the call.
Operation
Exceptions
23 6 5 4 3 0
offset 1 0 0 1 0 1
18 2 4
Assembler Syntax
CALL8 label
Description
CALL8 calls subroutines using the register windows mechanism, requesting the callee
rotate the window by eight registers. The CALL8 instruction does not rotate the window
itself, but instead stores the window increment for later use by the ENTRY instruction.
The return address and window increment are placed in the caller’s a8 (the callee’s a0),
and the processor then branches to the target address. The return address is the ad-
dress of the next instruction (the address of the CALL8 instruction plus three). The win-
dow increment is also stored in the CALLINC field of the PS register, where it is access-
ed by the ENTRY instruction.
The target instruction address must be a 32-bit aligned ENTRY instruction. This allows
CALL8 to have a larger effective range (−524284 to 524288 bytes). The target instruc-
tion address of the call is given by the address of the CALL8 instruction with the two
least significant bits set to zero, plus the sign-extended 18-bit offset field of the in-
struction shifted by two, plus four.
See the CALLX8 instruction for calling routines where the target address is given by the
contents of a register.
Use the RETW and RETW.N instructions to return from a subroutine called by CALL8.
The window increment stored with the return address register in a8 occupies the two
most significant bits of the register, and therefore those bits must be filled in by the sub-
routine return. The RETW and RETW.N instructions fill in these bits from the two most sig-
nificant bits of their own address. This prevents register-window calls from being used to
call a routine in a different 1GB region of the address space.
See the CALL0 instruction for calling routines using the non-windowed subroutine proto-
col.
The caller’s a8..a15 are the same registers as the callee’s a0..a7 after the callee exe-
cutes the ENTRY instruction. You can use these registers for parameter passing. The
caller’s a0..a7 are hidden by CALL8, and therefore you may use them to keep values
that are live across the call.
Operation
Exceptions
23 6 5 4 3 0
offset 1 1 0 1 0 1
18 2 4
Assembler Syntax
CALL12 label
Description
CALL12 calls subroutines using the register windows mechanism, requesting the callee
rotate the window by 12 registers. The CALL12 instruction does not rotate the window it-
self, but instead stores the window increment for later use by the ENTRY instruction. The
return address and window increment are placed in the caller’s a12 (the callee’s a0),
and the processor then branches to the target address. The return address is the ad-
dress of the next instruction (the address of the CALL12 instruction plus three). The win-
dow increment is also stored in the CALLINC field of the PS register, where it is access-
ed by the ENTRY instruction.
The target instruction address must be a 32-bit aligned ENTRY instruction. This allows
CALL12 to have a larger effective range (−524284 to 524288 bytes). The target instruc-
tion address of the call is given by the address of the CALL12 instruction with the two
least significant bits set to zero, plus the sign-extended 18-bit offset field of the in-
struction shifted by two, plus four.
See the CALLX12 instruction for calling routines where the target address is given by
the contents of a register.
The RETW and RETW.N instructions return from a subroutine called by CALL12.
The window increment stored with the return address register in a12 occupies the two
most significant bits of the register, and therefore those bits must be filled in by the sub-
routine return. The RETW and RETW.N instructions fill in these bits from the two most sig-
nificant bits of their own address. This prevents register-window calls from being used to
call a routine in a different 1GB region of the address space.
See the CALL0 instruction for calling routines using the non-windowed subroutine proto-
col.
The caller’s a12..a15 are the same registers as the callee’s a0..a3 after the callee exe-
cutes the ENTRY instruction. You can use these registers for parameter passing. The
caller’s a0..a11 are hidden by CALL12, and therefore you may use them to keep values
that are live across the call.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 6 5 4 3 0
0 0 0 0 0 0 0 0 0 0 0 0 s 1 1 0 0 0 0 0 0
4 4 4 4 2 2 4
Assembler Syntax
CALLX0 as
Description
CALLX0 calls subroutines without using register windows. The return address is placed
in a0, and the processor then branches to the target address. The return address is the
address of the CALLX0 instruction, plus three.
The target instruction address of the call is given by the contents of address register as.
The RET and RET.N instructions return from a subroutine called by CALLX0.
To call using the register window mechanism, see the CALLX4, CALLX8, and CALLX12
instructions.
Operation
nextPC ← AR[s]
AR[0] ← PC + 3
Exceptions
23 20 19 16 15 12 11 8 7 6 5 4 3 0
0 0 0 0 0 0 0 0 0 0 0 0 s 1 1 0 1 0 0 0 0
4 4 4 4 2 2 4
Assembler Syntax
CALLX4 as
Description
CALLX4 calls subroutines using the register windows mechanism, requesting the callee
rotate the window by four registers. The CALLX4 instruction does not rotate the window
itself, but instead stores the window increment for later use by the ENTRY instruction.
The return address and window increment are placed in the caller’s a4 (the callee’s a0),
and the processor then branches to the target address. The return address is the ad-
dress of the next instruction (the address of the CALLX4 instruction plus three). The win-
dow increment is also stored in the CALLINC field of the PS register, where it is access-
ed by the ENTRY instruction.
The target instruction address of the call is given by the contents of address register as.
The target instruction must be an ENTRY instruction.
See the CALL4 instruction for calling routines where the target address is given by a PC-
relative offset in the instruction.
The RETW and RETW.N instructions return from a subroutine called by CALLX4.
The window increment stored with the return address register in a4 occupies the two
most significant bits of the register, and therefore those bits must be filled in by the sub-
routine return. The RETW and RETW.N instructions fill in these bits from the two most sig-
nificant bits of their own address. This prevents register-window calls from being used to
call a routine in a different 1GB region of the address space.
See the CALLX0 instruction for calling routines using the non-windowed subroutine
protocol.
The caller’s a4..a15 are the same registers as the callee’s a0..a11 after the callee exe-
cutes the ENTRY instruction. You can use these registers for parameter passing. The
caller’s a0..a3 are hidden by CALLX4, and therefore you may use them to keep values
that are live across the call.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 6 5 4 3 0
0 0 0 0 0 0 0 0 0 0 0 0 s 1 1 1 0 0 0 0 0
4 4 4 4 2 2 4
Assembler Syntax
CALLX8 as
Description
CALLX8 calls subroutines using the register windows mechanism, requesting the callee
rotate the window by eight registers. The CALLX8 instruction does not rotate the window
itself, but instead stores the window increment for later use by the ENTRY instruction.
The return address and window increment are placed in the caller’s a8 (the callee’s a0),
and the processor then branches to the target address. The return address is the ad-
dress of the next instruction (the address of the CALLX8 instruction plus three). The win-
dow increment is also stored in the CALLINC field of the PS register, where it is access-
ed by the ENTRY instruction.
The target instruction address of the call is given by the contents of address register as.
The target instruction must be an ENTRY instruction.
See the CALL8 instruction for calling routines where the target address is given by a PC-
relative offset in the instruction.
The RETW and RETW.N (page 482) instructions return from a subroutine called by
CALLX8.
The window increment stored with the return address register in a8 occupies the two
most significant bits of the register, and therefore those bits must be filled in by the sub-
routine return. The RETW and RETW.N instructions fill in these bits from the two most sig-
nificant bits of their own address. This prevents register-window calls from being used to
call a routine in a different 1GB region of the address space.
See the CALLX0 instruction for calling routines using the non-windowed subroutine pro-
tocol.
The caller’s a8..a15 are the same registers as the callee’s a0..a7 after the callee exe-
cutes the ENTRY instruction. You can use these registers for parameter passing. The
caller’s a0..a7 are hidden by CALLX8, and therefore you may use them to keep values
that are live across the call.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 6 5 4 3 0
0 0 0 0 0 0 0 0 0 0 0 0 s 1 1 1 1 0 0 0 0
4 4 4 4 2 2 4
Assembler Syntax
CALLX12 as
Description
CALLX12 calls subroutines using the register windows mechanism, requesting the
callee rotate the window by 12 registers. The CALLX12 instruction does not rotate the
window itself, but instead stores the window increment for later use by the ENTRY in-
struction. The return address and window increment are placed in the caller’s a12 (the
callee’s a0), and the processor then branches to the target address. The return address
is the address of the next instruction (the address of the CALLX12 instruction plus
three). The window increment is also stored in the CALLINC field of the PS register,
where it is accessed by the ENTRY instruction.
The target instruction address of the call is given by the contents of address register as.
The target instruction must be an ENTRY instruction.
See the CALL12 instruction for calling routines where the target address is given by a
PC-relative offset in the instruction.
The RETW and RETW.N instructions return from a subroutine called by CALLX12.
The window increment stored with the return address register in a12 occupies the two
most significant bits of the register, and therefore those bits must be filled in by the sub-
routine return. The RETW and RETW.N instructions fill in these bits from the two most sig-
nificant bits of their own address. This prevents register-window calls from being used to
call a routine in a different 1GB region of the address space.
See the CALLX0 instruction for calling routines using the non-windowed subroutine
protocol.
The caller’s a12..a15 are the same registers as the callee’s a0..a3 after the callee exe-
cutes the ENTRY instruction. These registers may be used for parameter passing. The
caller’s a0..a11 are hidden by CALLX12, and therefore may be used to keep values that
are live across the call.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 1 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 1 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
CLAMPS tests whether the contents of address register as fits as a signed value of
imm+1 bits (in the range 7 to 22). If so, the value is written to address register ar; if not,
the largest value of imm+1 bits with the same sign as as is written to ar. Thus CLAMPS
performs the function
y ← min(max(x, −2imm), 2imm−1)
CLAMPS may be used in conjunction with instructions such as ADD, SUB, MUL16S, and
so forth to implement saturating arithmetic.
Assembler Note
The immediate values accepted by the assembler are 7 to 22. The assembler encodes
these in the t field of the instruction using 0 to 15.
Operation
sign ← AR[s]31
AR[r] ← if AR[s]30..t+7 = sign24-t
then AR[s]
else sign25-t||(not sign)t+7
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 0 1 1 0 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
DHI invalidates the specified line in the level-1 data cache, if it is present. If the specified
address is not in the data cache, then this instruction has no effect. If the specified ad-
dress is present, it is invalidated even if it contains dirty data. If the specified line has
been locked by a DPFL instruction, then no invalidation is done and no exception is
raised because of the lock. The line remains in the cache and must be unlocked by a
DHU or DIU instruction before it can be invalidated. This instruction is useful before a
DMA write to memory that overwrites the entire line.
DHI forms a virtual address by adding the contents of address register as and an 8-bit
zero-extended constant value encoded in the instruction word shifted left by two. There-
fore, the offset can specify multiples of four from zero to 1020. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation encounters an error (for example, protection violation), the
processor raises an exception (see Section 4.4.1.5 on page 89) as if it were loading
from the virtual address.
Assembler Note
To form a virtual address DHI calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (022||imm8||02)
(pAddr, attributes, cause) ← ltranslate(vAddr, CRING)
if invalid(attributes) then
EXCVADDR ← vAddr
Exception (cause)
else
dhitinval(vAddr, pAddr)
endif
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
imm4 0 0 1 0 0 1 1 1 s 1 0 0 0 0 0 1 0
4 4 4 4 4 4
Data Cache Index Lock Option (See Section 4.5.7 on page 122)
Assembler Syntax
Description
DHU performs a data cache unlock if hit. The purpose of DHU is to remove the lock creat-
ed by a DPFL instruction. Xtensa ISA implementations that do not implement cache lock-
ing must raise an illegal instruction exception when this opcode is executed.
DHU checks whether the line containing the specified address is present in the data
cache, and if so, it clears the lock associated with that line. To unlock by index without
knowing the address of the locked line, use the DIU instruction.
DHU forms a virtual address by adding the contents of address register as and a 4-bit
zero-extended constant value encoded in the instruction word shifted left by four. There-
fore, the offset can specify multiples of 16 from zero to 240. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation encounters an error (for example, protection violation), the
processor raises an exception (see Section 4.4.1.5 on page 89) as if it were loading
from the virtual address.
Assembler Note
To form a virtual address DHU calculates the sum of address register as and the imm4
field of the instruction word times 16. Therefore, the machine-code offset is in terms of
16 byte units. However, the assembler expects a byte offset and encodes this into the
instruction by dividing by 16.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (024||imm4||04)
(pAddr, attributes, cause) ← ltranslate(vAddr, CRING)
if invalid(attributes) then
EXCVADDR ← vAddr
Exception (cause)
else
dhitunlock(vAddr, pAddr)
endif
endif
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 0 1 0 0 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
This instruction forces dirty data in the data cache to be written back to memory. If the
specified address is not in the data cache or is present but unmodified, then this instruc-
tion has no effect. If the specified address is present and modified in the data cache, the
line containing it is written back, and marked unmodified. This instruction is useful be-
fore a DMA read from memory, to force writes to a frame buffer to become visible, or to
force writes to memory shared by two processors.
DHWB forms a virtual address by adding the contents of address register as and an 8-bit
zero-extended constant value encoded in the instruction word shifted left by two. There-
fore, the offset can specify multiples of four from zero to 1020. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation encounters an error (for example, protection violation), the
processor raises an exception (see Section 4.4.1.5 on page 89) as if it were loading
from the virtual address.
Assembler Note
To form a virtual address DHWB calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
Implementation Notes
Some Xtensa ISA implementations do not support write-back caches. For these imple-
mentations, the DHWB instruction performs no operation.
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 0 1 0 1 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
DHWBI forces dirty data in the data cache to be written back to memory. If the specified
address is not in the data cache, then this instruction has no effect. If the specified ad-
dress is present and modified in the data cache, the line containing it is written back.
After the write-back, if any, the line containing the specified address is invalidated if
present. If the specified line has been locked by a DPFL instruction, then no invalidation
is done and no exception is raised because of the lock. The line is written back but re-
mains in the cache unmodified and must be unlocked by a DHU or DIU instruction before
it can be invalidated. This instruction is useful in the same circumstances as DHWB and
before a DMA write to memory or write from another processor to memory. If the line is
certain to be completely overwritten by the write, you can use a DHI (as it is faster), but
otherwise use a DHWBI.
DHWBI forms a virtual address by adding the contents of address register as and an
8-bit zero-extended constant value encoded in the instruction word shifted left by two.
Therefore, the offset can specify multiples of four from zero to 1020. If the Region Trans-
lation Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation encounters an error (for example, protection violation), the
processor raises an exception (see Section 4.4.1.5 on page 89) as if it were loading
from the virtual address.
Assembler Note
To form a virtual address, DHWBI calculates the sum of address register as and the
imm8 field of the instruction word times four. Therefore, the machine-code offset is in
terms of 32-bit (4 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by four.
Operation
Exceptions
Implementation Notes
Some Xtensa ISA implementations do not support write-back caches. For these imple-
mentations DHWBI is identical to DHI.
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 0 1 1 1 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
DII uses the virtual address to choose a location in the data cache and invalidates the
specified line. If the chosen line has been locked by a DPFL instruction, then no invalida-
tion is done and no exception is raised because of the lock. The line remains in the
cache and must be unlocked by a DHU or DIU instruction before it can be invalidat-
ed.The method for mapping the virtual address to a data cache location is implementa-
tion-specific. This instruction is primarily useful for data cache initialization after power-
up.
DII forms a virtual address by adding the contents of address register as and an 8-bit
zero-extended constant value encoded in the instruction word shifted left by two. There-
fore, the offset can specify multiples of four from zero to 1020. The virtual address
chooses a cache line without translation and without raising the associated exceptions.
Assembler Note
To form a virtual address, DII calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
if CRING ≠ 0 then
Exceptions
Implementation Notes
x ← ceil(log2(DataCacheBytes))
y ← log2(DataCacheBytes ÷ DataCacheWayCount)
z ← log2(DataCacheLineBytes)
The additional ways invalidated in some implementations mean that care is needed in
using this instruction with write-back caches. Dirty data in any way (at the specified in-
dex) of the cache will be lost and not just dirty data in the specified way. Because the in-
struction is primarily used at reset, this will not usually cause any difficulty.
23 20 19 16 15 12 11 8 7 4 3 0
imm4 0 0 1 1 0 1 1 1 s 1 0 0 0 0 0 1 0
4 4 4 4 4 4
Data Cache Index Lock Option (See Section 4.5.7 on page 122)
Assembler Syntax
Description
DIU uses the virtual address to choose a location in the data cache and unlocks the
chosen line. The purpose of DIU is to remove the lock created by a DPFL instruction.
The method for mapping the virtual address to a data cache location is implementation-
specific. This instruction is primarily useful for unlocking the entire data cache. Xtensa
ISA implementations that do not implement cache locking must raise an illegal instruc-
tion exception when this opcode is executed.
To unlock a specific cache line if it is in the cache, use the DHU instruction.
DII forms a virtual address by adding the contents of address register as and a 4-bit
zero-extended constant value encoded in the instruction word shifted left by four. There-
fore, the offset can specify multiples of 16 from zero to 240. The virtual address chooses
a cache line without translation and without raising the associated exceptions.
Assembler Note
To form a virtual address DIU calculates the sum of address register as and the imm4
field of the instruction word times 16. Therefore, the machine-code offset is in terms of
16 byte units. However, the assembler expects a byte offset and encodes this into the
instruction by dividing by 16.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (024||imm4||04)
dindexunlock(vAddr)
endif
Exceptions
Implementation Notes
x ← ceil(log2(DataCacheBytes))
y ← log2(DataCacheBytes ÷ DataCacheWayCount)
z ← log2(DataCacheLineBytes)
23 20 19 16 15 12 11 8 7 4 3 0
imm4 0 1 0 0 0 1 1 1 s 1 0 0 0 0 0 1 0
4 4 4 4 4 4
Data Cache Option (See Section 4.5.5 on page 118) (added in T1050)
Assembler Syntax
Description
DIWB uses the virtual address to choose a line in the data cache and writes that line
back to memory if it is dirty. The method for mapping the virtual address to a data cache
line is implementation-specific. This instruction is primarily useful for forcing all dirty data
in the cache back to memory. If the chosen line is present but unmodified, then this in-
struction has no effect. If the chosen line is present and modified in the data cache, it is
written back, and marked unmodified. For set-associative caches, only one line out of
one way of the cache is written back. Some Xtensa ISA implementations do not support
writeback caches. For these implementations DIWB does nothing.
This instruction is useful for the same purposes as DHWB, but when either the address is
not known or when the range of addresses is large enough that it is faster to operate on
the entire cache.
DIWB forms a virtual address by adding the contents of address register as and a 4-bit
zero-extended constant value encoded in the instruction word shifted left by four. There-
fore, the offset can specify multiples of 16 from zero to 240. The virtual address chooses
a cache line without translation and without raising the associated exceptions.
Assembler Note
To form a virtual address DIWB calculates the sum of address register as and the imm4
field of the instruction word times 16. Therefore, the machine-code offset is in terms of
16 byte units. However, the assembler expects a byte offset and encodes this into the in-
struction by dividing by 16.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (024||imm4||04)
dindexwriteback(vAddr)
endif
Exceptions
Implementation Notes
x ← ceil(log2(DataCacheBytes))
y ← log2(DataCacheBytes ÷ DataCacheWayCount)
z ← log2(DataCacheLineBytes)
Some Xtensa ISA implementations do not support write-back caches. For these imple-
mentations, the DIWB instruction has no effect.
23 20 19 16 15 12 11 8 7 4 3 0
imm4 0 1 0 1 0 1 1 1 s 1 0 0 0 0 0 1 0
4 4 4 4 4 4
Data Cache Option (See Section 4.5.5 on page 118) (added in T1050)
Assembler Syntax
Description
DIWBI uses the virtual address to choose a line in the data cache and forces that line to
be written back to memory if it is dirty. After the writeback, if any, the line is invalidated.
The method for mapping the virtual address to a data cache location is implementation-
specific. If the chosen line is already invalid, then this instruction has no effect. If the
chosen line has been locked by a DPFL instruction, then dirty data is written back but no
invalidation is done and no exception is raised because of the lock. The line remains in
the cache and must be unlocked by a DHU or DIU instruction before it can be invalidat-
ed. For set-associative caches, only one line out of one way of the cache is written back
and invalidated. Some Xtensa ISA implementations do not support write-back caches.
For these implementations DIWBI is similar to DII but invalidates only one line.
This instruction is useful for the same purposes as the DHWBI but when either the ad-
dress is not known, or when the range of addresses is large enough that it is faster to
operate on the entire cache.
DIWBI forms a virtual address by adding the contents of address register as and a 4-bit
zero-extended constant value encoded in the instruction word shifted left by four. There-
fore, the offset can specify multiples of 16 from zero to 240. The virtual address chooses
a cache line without translation and without raising the associated exceptions.
Assembler Note
To form a virtual address, DIWBI calculates the sum of address register as and the
imm4 field of the instruction word times 16. Therefore, the machine-code offset is in
terms of 16 byte units. However, the assembler expects a byte offset and encodes this
into the instruction by dividing by 16.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (024||imm4||04)
dindexwritebackinval(vAddr)
endif
Exceptions
Implementation Notes
x ← ceil(log2(DataCacheBytes))
y ← log2(DataCacheBytes ÷ DataCacheWayCount)
z ← log2(DataCacheLineBytes)
23 20 19 16 15 12 11 8 7 4 3 0
imm4 0 0 0 0 0 1 1 1 s 1 0 0 0 0 0 1 0
24 4 4 4 4 4
Data Cache Index Lock Option (See Section 4.5.7 on page 122)
Assembler Syntax
Description
DPFL performs a data cache prefetch and lock. The purpose of DPFL is to improve per-
formance, and not to affect state defined by the ISA. Xtensa ISA implementations that
do not implement cache locking must raise an illegal instruction exception when this op-
code is executed. In general, the performance improvement from using this instruction is
implementation-dependent.
DPFL checks if the line containing the specified address is present in the data cache,
and if not, it begins the transfer of the line from memory to the cache. The line is placed
in the data cache and the line marked as locked, that is not replaceable by ordinary data
cache misses. To unlock the line, use DHU or DIU. To prefetch without locking, use the
DPFR, DPFW, DPFRO, or DPFWO instructions.
DPFL forms a virtual address by adding the contents of address register as and a 4-bit
zero-extended constant value encoded in the instruction word shifted left by four. There-
fore, the offset can specify multiples of 16 from zero to 240. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation encounters an error (for example, protection violation), the
processor raises one of several exceptions (see Section 4.4.1.5 on page 89).
Assembler Note
To form a virtual address, DPFL calculates the sum of address register as and the imm4
field of the instruction word times 16. Therefore, the machine-code offset is in terms of
16 byte units. However, the assembler expects a byte offset and encodes this into the
instruction by dividing by 16.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (024||imm4||04)
(pAddr, attributes, cause) ← ltranslate(vAddr, CRING)
if invalid(attributes) then
EXCVADDR ← vAddr
Exception (cause)
else
dprefetch(vAddr, pAddr, 0, 0, 1)
endif
endif
Exceptions
Implementation Notes
If, before the instruction executes, there are not two available DataCache ways at the re-
quired index, a Load Store Error exception is raised.
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 0 0 0 0 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
DPFR performs a data cache prefetch for read. The purpose of DPFR is to improve per-
formance, but not to affect state defined by the ISA. Therefore, some Xtensa ISA imple-
mentations may choose to implement this instruction as a simple “no-operation” instruc-
tion. In general, the performance improvement from using this instruction is
implementation-dependent.
In some Xtensa ISA implementations, DPFR checks whether the line containing the
specified address is present in the data cache, and if not, it begins the transfer of the
line from memory. The four data prefetch instructions provide different “hints” about how
the data is likely to be used in the future. DPFR indicates that the data is only likely to be
read, possibly more than once, before it is replaced by another line in the cache.
DPFR forms a virtual address by adding the contents of address register as and an 8-bit
zero-extended constant value encoded in the instruction word shifted left by two. There-
fore, the offset can specify multiples of four from zero to 1020. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation or memory reference encounters an error (for example, pro-
tection violation or non-existent memory), the processor performs no operation. This al-
lows the instruction to be used to speculatively fetch an address that does not exist or is
protected without either causing an error or allowing inappropriate action.
Assembler Note
To form a virtual address, DPFR calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 0 0 1 0 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
DPFRO performs a data cache prefetch for read once. The purpose of DPFRO is to im-
prove performance, but not to affect state defined by the ISA. Therefore, some Xtensa
ISA implementations may choose to implement this instruction as a simple “no-opera-
tion” instruction. In general, the performance improvement from using this instruction is
implementation-dependent.
In some Xtensa ISA implementations, DPFRO checks whether the line containing the
specified address is present in the data cache, and if not, it begins the transfer of the
line from memory. Four data prefetch instructions provide different “hints” about how the
data is likely to be used in the future. DPFRO indicates that the data is only likely to be
read once before it is replaced by another line in the cache. In some implementations,
this hint might be used to select a specific cache way or to select a streaming buffer
instead of the cache.
DPFRO forms a virtual address by adding the contents of address register as and an 8-
bit zero-extended constant value encoded in the instruction word shifted left by two.
Therefore, the offset can specify multiples of four from zero to 1020. If the Region Trans-
lation Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation or memory reference encounters an error (for example, pro-
tection violation or non-existent memory), the processor performs no operation. This al-
lows the instruction to be used to speculatively fetch an address that does not exist or is
protected without either causing an error or allowing inappropriate action.
Assembler Note
To form a virtual address, DPFRO calculates the sum of address register as and the
imm8 field of the instruction word times four. Therefore, the machine-code offset is in
terms of 32-bit (4 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by four.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 0 0 0 1 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
DPFW performs a data cache prefetch for write. The purpose of DPFW is to improve per-
formance, but not to affect the ISA state. Therefore, some Xtensa ISA implementations
may choose to implement this instruction as a simple “no-operation” instruction. In gen-
eral, the performance improvement from using this instruction is implementation-depen-
dent.
In some Xtensa ISA implementations, DPFW checks whether the line containing the
specified address is present in the data cache, and if not, begins the transfer of the line
from memory. Four data prefetch instructions provide different “hints” about how the
data is likely to be used in the future. DPFW indicates that the data is likely to be written
before it is replaced by another line in the cache. In some implementations, this fetches
the data with write permission (for example, in a system with shared and exclusive
states).
DPFW forms a virtual address by adding the contents of address register as and an 8-bit
zero-extended constant value encoded in the instruction word shifted left by two. There-
fore, the offset can specify multiples of four from zero to 1020. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation or memory reference encounters an error (for example, pro-
tection violation or non-existent memory), the processor performs no operation. This al-
lows the instruction to be used to speculatively fetch an address that does not exist or is
protected without either causing an error or allowing inappropriate action.
Assembler Note
To form a virtual address DPFW calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offsets and encodes this
into the instruction by dividing by four.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 0 0 1 1 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
DPFWO performs a data cache prefetch for write once. The purpose of DPFWO is to im-
prove performance, but not to affect the ISA state. Therefore, some Xtensa ISA imple-
mentations may choose to implement this instruction as a simple “no-operation” instruc-
tion. In general, the performance improvement from using this instruction is
implementation-dependent.
In some Xtensa ISA implementations, DPFWO checks whether the line containing the
specified address is present in the data cache, and if not, begins the transfer of the line
from memory. Four data prefetch instructions provide different “hints” about how the
data is likely to be used in the future. DPFWO indicates that the data is likely to be read
and written once before it is replaced by another line in the cache. In some implementa-
tions, this write hint fetches the data with write permission (for example, in a system with
shared and exclusive states). The write-once hint might be used to select a specific
cache way or to select a streaming buffer instead of the cache.
DPFWO forms a virtual address by adding the contents of address register as and an
8-bit zero-extended constant value encoded in the instruction word shifted left by two.
Therefore, the offset can specify multiples of four from zero to 1020. If the Region Trans-
lation Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation or memory reference encounters an error (for example, pro-
tection violation or non-existent memory), the processor performs no operation. This al-
lows the instruction to be used to speculatively fetch an address that does not exist or is
protected without either causing an error or allowing inappropriate action.
Assembler Note
To form a virtual address DPFWO calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
DSYNC
Description
DSYNC waits for all previously fetched WSR.*, XSR.*, WDTLB, and IDTLB instructions to
be performed before interpreting the virtual address of the next load or store instruction.
This operation is also performed as part of ISYNC, RSYNC, and ESYNC.
Operation
dsync()
Exceptions
23 12 11 8 7 6 5 4 3 0
imm12 s 0 0 1 1 0 1 1 0
12 4 2 2 4
Assembler Syntax
Description
ENTRY is intended to be the first instruction of all subroutines called with CALL4, CALL8,
CALL12, CALLX4, CALLX8, or CALLX12. This instruction is not intended to be used by a
routine called by CALL0 or CALLX0.
The stack frame size is specified as the 12-bit unsigned imm12 field in units of eight
bytes. The size is zero-extended, shifted left by 3, and subtracted from the caller’s stack
pointer to get the callee’s stack pointer. Therefore, stack frames up to 32760 bytes can
be specified. The initial stack frame size must be a constant, but subsequently the
MOVSP instruction can be used to allocate dynamically-sized objects on the stack, or to
further extend a constant stack frame larger than 32760 bytes.
The windowed subroutine call protocol is described in Section 4.7.1.5 on page 187.
Assembler Note
In the assembler syntax, the number of bytes to be subtracted from the stack pointer is
specified as the immediate. The assembler encodes this into the instruction by dividing
by eight.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ESYNC
Description
ESYNC waits for all previously fetched WSR.*, and XSR.* instructions to be performed
before the next instruction uses any register values. This operation is also performed as
part of ISYNC and RSYNC. DSYNC is performed as part of this instruction.
This instruction is appropriate after WSR.EPC* instructions. See the Special Register
Tables in Section 5.3 on page 208 for a complete description of the uses of the ESYNC
instruction.
Operation
esync()
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
EXCW
Description
EXCW waits for any exceptions of previously fetched instructions to be handled. Some
Xtensa ISA implementations may have imprecise exceptions; on these implementations
EXCW waits until all previous instruction exceptions are taken or the instructions are
known to be exception-free. Because the instruction execution pipeline and exception
handling is implementation-specific, the operation section below specifies only a call to
the implementation’s ExceptionWait function.
Operation
ExceptionWait()
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
4 4 4 4 4 4
Assembler Syntax
Description
EXTUI performs an unsigned bit field extraction from a 32-bit register value. Specifically,
it shifts the contents of address register at right by the shift amount shiftimm, which is
a value 0..31 stored in bits 16 and 11..8 of the instruction word (the sa fields). The
shift result is then ANDed with a mask of maskimm least-significant 1 bits and the result
is written to address register ar. The number of mask bits, maskimm, may take the val-
ues 1..16, and is stored in the op2 field as maskimm-1. The bits extracted are there-
fore sa+op2..sa.
The operation of this instruction when sa+op2 > 31 is undefined and reserved for future
use.
Operation
mask ← 031-op2||1op2+1
AR[r] ← (032||AR[t])31+sa..sa and mask
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 0 1 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
EXTW
Description
complete (or perform as described in Section 4.3.12.1 on page 74) before either
- any subsequent load, store, acquire, release, prefetch, or cache instructions; or
- external effects of the execution of any following instruction is visible at the pins
of the Xtensa processor (not including instruction prefetch or TIE Queue pops)
is allowed to begin.
Operation
extw()
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 0 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
FLOAT.S converts the contents of address register as from signed integer to single-pre-
cision format, rounding according to the current rounding mode. The converted integer
value is then scaled by a power of two constant value encoded in the t field, with 0..15
representing 1.0, 0.5, 0.25, …, 1.0÷s32768.0. The scaling allows for a fixed point nota-
tion where the binary point is at the right end of the integer for t=0 and moves to the left
as t increases until for t=15 there are 15 fractional bits represented in the fixed point
number. The result is written to floating-point register fr.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 0 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 1 1 0 0 s 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Region Protection Option (see Section 4.6.3 on page 150) or MMU Option (see
Section 4.6.5 on page 158)
Assembler Syntax
IDTLB as
Description
IDTLB invalidates the data TLB entry specified by the contents of address register as.
See Section 4.6 on page 138 for information on the address register formats for specific
Memory Protection and Translation Options. The point at which the invalidation is effect-
ed is implementation-specific. Any translation that would be affected by this invalidation
before the execution of a DSYNC instruction is therefore undefined.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
(vpn, ei, wi) ← SplitDataTLBEntrySpec(AR[s])
DataTLB[wi][ei] ← InvalidDataTLBEntry
endif
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 1 1 1 0 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
IHI performs an instruction cache hit invalidate. It invalidates the specified line in the in-
struction cache, if it is present. If the specified address is not in the instruction cache,
then this instruction has no effect. If the specified line is already invalid, then this instruc-
tion has no effect. If the specified line has been locked by an IPFL instruction, then no
invalidation is done and no exception is raised because of the lock. The line remains in
the cache and must be unlocked by an IHU or IIU instruction before it can be invalidat-
ed. Otherwise, if the specified line is present, it is invalidated.
This instruction is required before executing instructions from the instruction cache that
have been written by this processor, another processor, or DMA. The writes must first be
forced out of the data cache, either by using DHWB or by using stores that bypass or
write through the data cache. An ISYNC instruction should then be used to guarantee
that the modified instructions are visible to instruction cache misses. The instruction
cache should then be invalidated for the affected addresses using a series of IHI in-
structions. An ISYNC instruction should then be used to guarantee that this processor’s
fetch pipeline does not contain instructions from the invalidated lines.
IHI forms a virtual address by adding the contents of address register as and an 8-bit
zero-extended constant value encoded in the instruction word shifted left by two. There-
fore, the offset can specify multiples of four from zero to 1020. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation encounters an error (for example, protection violation), the
processor raises one of several exceptions (see Section 4.4.1.5 on page 89). The trans-
lation is done as if the address were for an instruction fetch.
Assembler Note
To form a virtual address, IHI calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
imm4 0 0 1 0 0 1 1 1 s 1 1 0 1 0 0 1 0
4 4 4 4 4 4
Instruction Cache Index Lock Option (See Section 4.5.4 on page 117)
Assembler Syntax
Description
IHU performs an instruction cache unlock if hit. The purpose of IHU is to remove the
lock created by an IPFL instruction. Xtensa ISA implementations that do not implement
cache locking must raise an illegal instruction exception when this opcode is executed.
IHU checks whether the line containing the specified address is present in the instruc-
tion cache, and if so, it clears the lock associated with that line. To unlock by index with-
out knowing the address of the locked line, use the IIU instruction.
IHU forms a virtual address by adding the contents of address register as and a 4-bit
zero-extended constant value encoded in the instruction word shifted left by four. There-
fore, the offset can specify multiples of 16 from zero to 240. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation encounters an error (for example or protection violation), the
processor takes one of several exceptions (see Section 4.4.1.5 on page 89). The trans-
lation is done as if the address were for an instruction fetch.
Assembler Note
To form a virtual address, IHU calculates the sum of address register as and the imm4
field of the instruction word times 16. Therefore, the machine-code offset is in terms of
16 byte units. However, the assembler expects a byte offset and encodes this into the
instruction by dividing by 16.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (024||imm4||04)
(pAddr, attributes, cause) ← ftranslate(vAddr, CRING)
if invalid(attributes) then
EXCVADDR ← vAddr
Exception (cause)
else
ihitunlock(vAddr, pAddr)
endif
endif
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 1 1 1 1 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
III performs an instruction cache index invalidate. This instruction uses the virtual
address to choose a location in the instruction cache and invalidates the specified line.
The method for mapping the virtual address to an instruction cache location is imple-
mentation-specific. If the chosen line is already invalid, then this instruction has no
effect. If the chosen line has been locked by an IPFL instruction, then no invalidation is
done and no exception is raised because of the lock. The line remains in the cache and
must be unlocked by an IHU or IIU instruction before it can be invalidated. This instruc-
tion is useful for instruction cache initialization after power-up or for invalidating the
entire instruction cache.
III forms a virtual address by adding the contents of address register as and an 8-bit
zero-extended constant value encoded in the instruction word shifted left by two. There-
fore, the offset can specify multiples of four from zero to 1020. The virtual address
chooses a cache line without translation and without raising the associated exceptions.
Assembler Note
To form a virtual address, III calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (022||imm8||02)
iindexinval(vAddr, pAddr)
endif
Exceptions
Implementation Notes
x ← ceil(log2(InstCacheBytes))
y ← log2(InstCacheBytes ÷ InstCacheWayCount)
z ← log2(InstCacheLineBytes)
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 0 1 0 0 s 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Region Protection Option (see Section 4.6.3 on page 150) or MMU Option (see
Section 4.6.5 on page 158)
Assembler Syntax
IITLB as
Description
IITLB invalidates the instruction TLB entry specified by the contents of address register
as. See Section 4.6 on page 138 for information on the address register formats for spe-
cific Memory Protection and Translation options. The point at which the invalidation is
effected is implementation-specific. Any translation that would be affected by this invali-
dation before the execution of an ISYNC instruction is therefore undefined.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
(vpn, ei, wi) ← SplitInstTLBEntrySpec(AR[s])
InstTLB[wi][ei] ← InvalidInstTLBEntry
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
imm4 0 0 1 1 0 1 1 1 s 1 1 0 1 0 0 1 0
4 4 4 4 4 4
Instruction Cache Index Lock Option (See Section 4.5.4 on page 117)
Assembler Syntax
Description
IIU uses the virtual address to choose a location in the instruction cache and unlocks
the chosen line. The purpose of IIU is to remove the lock created by an IPFL instruc-
tion. The method for mapping the virtual address to an instruction cache location is
implementation-specific. This instruction is primarily useful for unlocking the entire
instruction cache. Xtensa ISA implementations that do not implement cache locking
must raise an illegal instruction exception when this opcode is executed.
To unlock a specific cache line if it is in the cache, use the IHU instruction.
IIU forms a virtual address by adding the contents of address register as and a 4-bit
zero-extended constant value encoded in the instruction word shifted left by four. There-
fore, the offset can specify multiples of 16 from zero to 240. The virtual address chooses
a cache line without translation and without raising the associated exceptions.
Assembler Note
To form a virtual address IIU calculates the sum of address register as and the imm4
field of the instruction word times 16. Therefore, the machine-code offset is in terms of
16 byte units. However, the assembler expects a byte offset and encodes this into the
instruction by dividing by 16.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (024||imm4||04)
iindexunlock(vAddr)
endif
Exceptions
Implementation Notes
x ← ceil(log2(InstCacheBytes))
y ← log2(InstCacheBytes ÷ InstCacheWayCount)
z ← log2(InstCacheLineBytes)
23 20 19 16 15 12 11 8 7 6 5 4 3 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
4 4 4 4 2 2 4
Assembler Syntax
ILL
Description
ILL is an opcode that is guaranteed to raise an illegal instruction exception in all imple-
mentations.
Operation
Exception(IllegalInstructionCause)
Exceptions
15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 0 0 1 1 0 1 1 0 1
4 4 4 4
Code Density Option (See Section 4.3.1 on page 53) and Exception Option (See
Section 4.4.1 on page 82)
Assembler Syntax
ILL.N
Description
Operation
Exception(IllegalInstructionCause)
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 1 s 1 1 0 0 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
IPF performs an instruction cache prefetch. The purpose of IPF is to improve perfor-
mance, but not to affect state defined by the ISA. Therefore, some Xtensa ISA imple-
mentations may choose to implement this instruction as a simple “no-operation” instruc-
tion. In general, the performance improvement from using this instruction is
implementation-dependent. In some implementations, IPF checks whether the line con-
taining the specified address is present in the instruction cache, and if not, it begins the
transfer of the line from memory to the instruction cache. Prefetching an instruction line
may prevent the processor from taking an instruction cache miss later.
IPF forms a virtual address by adding the contents of address register as and an 8-bit
zero-extended constant value encoded in the instruction word shifted left by two. There-
fore, the offset can specify multiples of four from zero to 1020. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation or memory reference encounters an error (for example, pro-
tection violation, or non-existent memory), the processor performs no operation. This
allows the instruction to be used to speculatively fetch an address that does not exist or
is protected without either causing an error or allowing inappropriate action. The transla-
tion is done as if the address were for an instruction fetch.
Assembler Note
To form a virtual address, IPF calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
imm4 0 0 0 0 0 1 1 1 s 1 1 0 1 0 0 1 0
4 4 4 4 4 4
Instruction Cache Index Lock Option (See Section 4.5.4 on page 117)
Assembler Syntax
Description
IPFL performs an instruction cache prefetch and lock. The purpose of IPFL is to
improve performance, but not to affect state defined by the ISA. Xtensa ISA implementa-
tions that do not implement cache locking must raise an illegal instruction exception
when this opcode is executed. In general, the performance improvement from using this
instruction is implementation-dependent as implementations may not overlap the cache
fill with the execution of other instructions.
In some implementations, IPFL checks whether the line containing the specified
address is present in the instruction cache, and if not, begins the transfer of the line from
memory to the instruction cache. The line is placed in the instruction cache and marked
as locked, so it is not replaceable by ordinary instruction cache misses. To unlock the
line, use IHU or IIU. To prefetch without locking, use the IPF instruction.
IPFL forms a virtual address by adding the contents of address register as and a 4-bit
zero-extended constant value encoded in the instruction word shifted left by four. There-
fore, the offset can specify multiples of 16 from zero to 240. If the Region Translation
Option (page 156) or the MMU Option (page 158) is enabled, the virtual address is
translated to the physical address. If not, the physical address is identical to the virtual
address. If the translation encounters an error (for example, protection violation), the
processor raises one of several exceptions (see Section 4.4.1.5 on page 89). The trans-
lation is done as if the address were for an instruction fetch. If the line cannot be cached,
an exception is raised with cause InstructionFetchErrorCause.
Assembler Note
To form a virtual address, IPFL calculates the sum of address register as and the imm4
field of the instruction word times 16. Therefore, the machine-code offset is in terms of
16 byte units. However, the assembler expects a byte offset and encodes this into the
instruction by dividing by 16.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (024||imm4||04)
(pAddr, attributes, cause) ← ftranslate(vAddr, CRING)
if invalid(attributes) then
EXCVADDR ← vAddr
Exception (cause)
else
iprefetch(vAddr, pAddr, 1)
endif
endif
Exceptions
Implementation Notes
If there are not two available InstCache ways at the required index before the instruction
executes, an exception is raised.
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ISYNC
Description
ISYNC waits for all previously fetched load, store, cache, TLB, WSR.*, and XSR.*
instructions that affect instruction fetch to be performed before fetching the next instruc-
tion. RSYNC, ESYNC, and DSYNC are performed as part of this instruction.
The proper sequence for writing instructions and then executing them is:
write instructions
use DHWB to force the data out of the data cache (this step may be skipped if write-
through, bypass, or no allocate stores were used)
use ISYNC to wait for the writes to be visible to instruction cache misses
use multiple IHI instructions to invalidate the instruction cache for any lines that
were modified (this step is not appropriate if the affected instructions are in InstRAM
or cannot be cached)
use ISYNC to ensure that fetch pipeline will see the new instructions
This instruction also waits for all previously executed WSR.* and XSR.* instructions that
affect instruction fetch or register access processor state, including:
WSR.LCOUNT, WSR.LBEG, WSR.LEND
WSR.IBREAKENABLE, WSR.IBREAKA[i]
WSR.CCOMPAREn
See the Special Register Tables in Section 5.3 on page 208 and Section 5.7 on
page 240, for a complete description of the ISYNC instruction’s uses.
Operation
isync()
Exceptions
Implementation Notes
23 6 5 4 3 0
offset 0 0 0 1 1 0
18 2 4
Assembler Syntax
J label
Description
J performs an unconditional branch to the target address. It uses a signed, 18-bit PC-
relative offset to specify the target address. The target address is given by the address
of the J instruction plus the sign-extended 18-bit offset field of the instruction plus
four, giving a range of -131068 to +131075 bytes.
Operation
nextPC ← PC + (offset1714||offset) + 4
Exceptions
23 6 5 4 3 0
offset 0 0 0 1 1 0
18 2 4
Assembler Macro
Assembler Syntax
J.L label, an
Description
J.L is an assembler macro which generates exactly a J instruction as long as the offset
will reach the label. If the offset is not long enough, the assembler relaxes the instruction
to a literal load into an followed by a JX an.. The AR register an may or may not be
modified.
Exceptions
23 20 19 16 15 12 11 8 7 6 5 4 3 0
0 0 0 0 0 0 0 0 0 0 0 0 s 1 0 1 0 0 0 0 0
4 4 4 4 2 2 4
Assembler Syntax
JX as
Description
Operation
nextPC ← AR[s]
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 0 0 s t 0 0 1 0
8 4 4 4 4
L8UI is an 8-bit unsigned load from memory. It forms a virtual address by adding the
contents of address register as and an 8-bit zero-extended constant value encoded in
the instruction word. Therefore, the offset ranges from 0 to 255. Eight bits (one byte) are
read from the physical address. This data is then zero-extended and written to address
register at.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 0 0 1 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
L16SI is a 16-bit signed load from memory. It forms a virtual address by adding the con-
tents of address register as and an 8-bit zero-extended constant value encoded in the
instruction word shifted left by 1. Therefore, the offset can specify multiples of two from
zero to 510. Sixteen bits (two bytes) are read from the physical address. This data is
then sign-extended and written to address register at.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation, non-existent memory), the processor raises one
of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the least significant address bit is ig-
nored; a reference to an odd address produces the same result as a reference to the ad-
dress minus one. With the Unaligned Exception Option, such an access raises an
exception.
Assembler Note
To form a virtual address, L16SI calculates the sum of address register as and the
imm8 field of the instruction word times two. Therefore, the machine-code offset is in
terms of 16-bit (2 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by two.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 0 1 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
L16UI is a 16-bit unsigned load from memory. It forms a virtual address by adding the
contents of address register as and an 8-bit zero-extended constant value encoded in
the instruction word shifted left by 1. Therefore, the offset can specify multiples of two
from zero to 510. Sixteen bits (two bytes) are read from the physical address. This data
is then zero-extended and written to address register at.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the least significant address bit is ig-
nored; a reference to an odd address produces the same result as a reference to the ad-
dress minus one. With the Unaligned Exception Option, such an access raises an
exception.
Assembler Note
To form a virtual address, L16UI calculates the sum of address register as and the
imm8 field of the instruction word times two. Therefore, the machine-code offset is in
terms of 16-bit (2 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by two.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 0 1 1 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
L32AI is a 32-bit load from memory with “acquire” semantics. This load performs before
any subsequent loads, stores, acquires, or releases are performed. It is typically used to
test a synchronization variable protecting a critical region (for example, to acquire a
lock).
L32AI forms a virtual address by adding the contents of address register as and an
8-bit zero-extended constant value encoded in the instruction word shifted left by two.
Therefore, the offset can specify multiples of four from zero to 1020. 32 bits (four bytes)
are read from the physical address. This data is then written to address register at.
L32AI causes the processor to delay processing of subsequent loads, stores, acquires,
and releases until the L32AI is performed. In some Xtensa ISA implementations, this
occurs automatically and L32AI is identical to L32I. Other implementations (for exam-
ple, those with multiple outstanding loads and stores) delay processing as described
above. Because the method of delay is implementation-dependent, this is indicated in
the operation section below by the implementation function acquire.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Assembler Note
To form a virtual address, L32AI calculates the sum of address register as and the
imm8 field of the instruction word times four. Therefore, the machine-code offset is in
terms of 32-bit (4 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by four.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 1 0 0 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
L32E is a 32-bit load instruction similar to L32I but with semantics required by window
overflow and window underflow exception handlers. In particular, memory access check-
ing is done with PS.RING instead of CRING, and the offset used to form the virtual ad-
dress is a 4-bit one-extended immediate. Therefore, the offset can specify multiples of
four from -64 to -4. In configurations without the MMU Option, there is no PS.RING, and
L32E is similar to L32I with a negative offset.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Assembler Note
To form a virtual address, L32E calculates the sum of address register as and the r field
of the instruction word times four (and one extended). Therefore, the machine-code
offset is in terms of 32-bit (4 byte) units. However, the assembler expects a byte offset
and encodes this into the instruction by dividing by four.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (126||r||02)
ring ← if MMU Option then PS.RING else 0
(mem32, error) ← Load32Ring(vAddr, ring)
if error then
EXCVADDR ← vAddr
Exception (LoadStoreErrorCause)
else
AR[t] ← mem32
endif
endif
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 0 1 0 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
L32I is a 32-bit load from memory. It forms a virtual address by adding the contents of
address register as and an 8-bit zero-extended constant value encoded in the instruc-
tion word shifted left by two. Therefore, the offset can specify multiples of four from zero
to 1020. Thirty-two bits (four bytes) are read from the physical address. This data is then
written to address register at.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation, non-existent memory), the processor raises one
of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
L32I is one of only a few memory reference instructions that can access instruction
RAM/ROM.
Assembler Note
The assembler may convert L32I instructions to L32I.N when the Code Density
Option is enabled and the immediate operand falls within the available range. Prefixing
the L32I instruction with an underscore (_L32I) disables this optimization and forces
the assembler to generate the wide form of the instruction.
To form a virtual address, L32I calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
15 12 11 8 7 4 3 0
imm4 s t 1 0 0 0
4 4 4 4
Assembler Syntax
Description
L32I.N is similar to L32I, but has a 16-bit encoding and supports a smaller range of
offset values encoded in the instruction word.
L32I.N is a 32-bit load from memory. It forms a virtual address by adding the contents
of address register as and a 4-bit zero-extended constant value encoded in the instruc-
tion word shifted left by two. Therefore, the offset can specify multiples of four from zero
to 60. Thirty-two bits (four bytes) are read from the physical address. This data is then
written to address register at.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
L32I.N is one of only a few memory reference instructions that can access instruction
RAM/ROM.
Assembler Note
The assembler may convert L32I.N instructions to L32I. Prefixing the L32I.N instruc-
tion with an underscore (_L32I.N) disables this optimization and forces the assembler
to generate the narrow form of the instruction.
To form a virtual address, L32I.N calculates the sum of address register as and the
imm4 field of the instruction word times four. Therefore, the machine-code offset is in
terms of 32-bit (4 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by four.
Operation
Exceptions
23 8 7 4 3 0
imm16 t 0 0 0 1
16 4 4
Assembler Syntax
Description
L32R is a PC-relative 32-bit load from memory. It is typically used to load constant
values into a register when the constant cannot be encoded in a MOVI instruction.
L32R forms a virtual address by adding the 16-bit one-extended constant value encoded
in the instruction word shifted left by two to the address of the L32R plus three with the
two least significant bits cleared. Therefore, the offset can always specify 32-bit aligned
addresses from -262141 to -4 bytes from the address of the L32R instruction. 32 bits
(four bytes) are read from the physical address. This data is then written to address
register at.
In the presence of the Extended L32R Option (Section 4.3.3 on page 56) when LIT-
BASE[0] is clear, the instruction has the identical operation. When LITBASE[0] is set,
L32R forms a virtual address by adding the 16-bit one extended constant value encoded
in the instruction word shifted left by two to the literal base address indicated by the up-
per 20 bits of LITBASE. The offset can specify 32-bit aligned addresses from -262144 to
-4 bytes from the literal base address.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
L32R is one of only a few memory reference instructions that can access instruction
RAM/ROM.
Assembler Note
In the assembler syntax, the immediate operand is specified as the address of the loca-
tion to load from, rather than the offset from the current instruction address. The linker
and the assembler both assume that the location loaded by the L32R instruction has not
been and will not be accessed by any other type of load or store instruction and optimiz-
es according to that assumption.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 1 1 0 0 0 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
LDCT at, as
Description
LDCT is not part of the Xtensa Instruction Set Architecture, but is instead specific to an
implementation. That is, it may not exist in all implementations of the Xtensa ISA.
LDCT is intended for reading the RAM array that implements the data cache tags as part
of manufacturing test.
LDCT uses the contents of address register as to select a line in the data cache, reads
the tag associated with this line, and writes the result to address register at. The value
written to at is described under Cache Tag Format in Section 4.5.1.2 on page 112.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
index ← AR[s]dih..dil
AR[t] ← DataCacheTag[index]
endif
Exceptions
Implementation Notes
x ← ceil(log2(DataCacheBytes))
y ← log2(DataCacheBytes ÷ DataCacheWayCount)
z ← log2(DataCacheLineBytes)
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 1 0 0 0 0 0 0 w s 0 0 0 0 0 1 0 0
4 4 4 4 4 4
LDDEC mw, as
Description
LDDEC loads MAC16 register mw from memory using auto-decrement addressing. It
forms a virtual address by subtracting 4 from the contents of address register as. 32 bits
(four bytes) are read from the physical address. This data is then written to MAC16
register mw, and the virtual address is written back to address register as.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Operation
vAddr ← AR[s] − 4
(mem32, error) ← Load32(vAddr)
if error then
EXCVADDR ← vAddr
Exception (LoadStoreErrorCause)
else
MR[w] ← mem32
AR[s] ← vAddr
endif
Exceptions
Memory Load Group (see page 244)
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 0 0 0 0 0 0 0 w s 0 0 0 0 0 1 0 0
4 4 4 4 4 4
LDINC mw, as
Description
LDINC loads MAC16 register mw from memory using auto-increment addressing. It
forms a virtual address by adding 4 to the contents of address register as. 32 bits (four
bytes) are read from the physical address. This data is then written to MAC16 register
mw, and the virtual address is written back to address register as.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Operation
vAddr ← AR[s] + 4
(mem32, error) ← Load32(vAddr)
if error then
EXCVADDR ← vAddr
Exception (LoadStoreErrorCause)
else
MR[w] ← mem32
AR[s] ← vAddr
endif
Exceptions
Memory Load Group (see page 244)
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 1 0 0 0 0 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
LICT at, as
Description
LICT is not part of the Xtensa Instruction Set Architecture, but is instead specific to an
implementation. That is, it may not exist in all implementations of the Xtensa ISA.
LICT is intended for reading the RAM array that implements the instruction cache tags
as part of manufacturing test.
LICT uses the contents of address register as to select a line in the instruction cache,
reads the tag associated with this line, and writes the result to address register at. The
value written to at is described under Cache Tag Format in Section 4.5.1.2 on
page 112.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
index ← AR[s]iih..iil
AR[t] ← InstCacheTag[index]
endif
Exceptions
Implementation Notes
x ← ceil(log2(InstCacheBytes))
y ← log2(InstCacheBytes ÷ InstCacheWayCount)
z ← log2(InstCacheLineBytes)
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 1 0 0 1 0 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
LICW at, as
Description
LICW is not part of the Xtensa Instruction Set Architecture, but is instead specific to an
implementation. That is, it may not exist in all implementations of the Xtensa ISA.
LICW is intended for reading the RAM array that implements the instruction cache as
part of manufacturing test.
LICW uses the contents of address register as to select a line in the instruction cache
and one 32-bit quantity within that line, reads that data, and writes the result to address
register at.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
index ← AR[s]iih..2
AR[t] ← InstCacheData [index]
endif
Exceptions
Implementation Notes
x ← ceil(log2(InstCacheBytes))
y ← log2(InstCacheBytes ÷ InstCacheWayCount)
z ← log2(InstCacheLineBytes)
23 16 15 12 11 8 7 4 3 0
imm8 1 0 0 0 s 0 1 1 1 0 1 1 0
8 4 4 4 4
Assembler Syntax
Description
LOOP sets up a zero-overhead loop by setting the LCOUNT, LBEG, and LEND special
registers, which control instruction fetch. The loop will iterate the number of times speci-
fied by address register as, with 0 causing the loop to iterate 232 times. LCOUNT, the
current loop iteration counter, is loaded from the contents of address register as minus
one. LEND is the loop end address and is loaded with the address of the LOOP instruc-
tion plus four, plus the zero-extended 8-bit offset encoded in the instruction (therefore,
the loop code may be up to 256 bytes in length). LBEG, the loop begin address, is loaded
with the address of the following instruction (the address of the LOOP instruction plus
three).
After the processor fetches an instruction that increments the PC to the value contained
in LEND, and LCOUNT is not zero, it loads the PC with the contents of LBEG and decre-
ments LCOUNT. LOOP is intended to be implemented with help from the instruction fetch
engine of the processor, and therefore should not incur a mispredict or taken branch
penalty. Branches and jumps to the address contained in LEND do not cause a loop
back, and therefore may be used to exit the loop prematurely. Likewise, a return from a
call instruction as the last instruction of the loop would not trigger loop back; this case
should be avoided.
There is no mechanism to proceed to the next iteration of the loop from the middle of the
loop. The compiler may insert a branch to a NOP placed as the last instruction of the loop
to implement this function if required.
Because LCOUNT, LBEG, and LEND are single registers, zero-overhead loops may not be
nested. Using conditional branch instructions to implement outer level loops is typically
not a performance issue. Because loops cannot be nested, it is usually inappropriate to
include a procedure call inside a loop (the callee might itself use a zero-overhead loop).
To simplify the implementation of zero-overhead loops, the LBEG address, which is the
LOOP instruction address plus three, must be such that the first instruction must entirely
fit within a naturally aligned four byte region or, if the instruction is larger than four bytes,
a naturally aligned region which is the next power of two equal to or larger than the
instruction. When the LOOP instruction would not naturally be placed at such an
address, the insertion of NOP instructions or adjustment of which instructions are 16-bit
density instructions is sufficient to give it the required alignment.
The automatic loop-back when the PC increments to match LEND is disabled when
PS.EXCM is set. This prevents non-privileged code from affecting the operation of the
privileged exception vector code.
Assembler Note
When the label is out of range, the assembler may insert a number of instructions to
extend the size of the loop. Prefixing the instruction mnemonic with an underscore
(_LOOP) disables this feature and forces the assembler to generate an error in this case.
Operation
LCOUNT ← AR[s] − 1
LBEG ← PC + 3
LEND ← PC + (024||imm8) + 4
Exceptions
Implementation Notes
In some implementations, LOOP takes an extra clock for the first loop back of certain
loops. In addition, certain instructions (such as ISYNC or a write to LEND) may cause an
additional cycle on the following loop back.
23 16 15 12 11 8 7 4 3 0
imm8 1 0 1 0 s 0 1 1 1 0 1 1 0
8 4 4 4 4
Assembler Syntax
Description
LOOPGTZ sets up a zero-overhead loop by setting the LCOUNT, LBEG, and LEND special
registers, which control instruction fetch. The loop will iterate the number of times speci-
fied by address register as with values ≤ 0 causing the loop to be skipped altogether by
branching directly to the loop end address. LCOUNT, the current loop iteration counter, is
loaded from the contents of address register as minus one. LEND is the loop end
address and is loaded with the address of the LOOPGTZ instruction plus four, plus the
zero-extended 8-bit offset encoded in the instruction (therefore, the loop code may be
up to 256 bytes in length). LBEG, the loop begin address, is loaded with the address of
the following instruction (the address of the LOOPGTZ instruction plus three). LCOUNT,
LEND, and LBEG are still loaded even when the loop is skipped.
After the processor fetches an instruction that increments the PC to the value contained
in LEND, and LCOUNT is not zero, it loads the PC with the contents of LBEG and decre-
ments LCOUNT. LOOPGTZ is intended to be implemented with help from the instruction
fetch engine of the processor, and therefore should not incur a mispredict or taken
branch penalty. Branches and jumps to the address contained in LEND do not cause a
loop back, and therefore may be used to exit the loop prematurely. Similarly, a return
from a call instruction as the last instruction of the loop would not trigger loop back; this
case should be avoided.
There is no mechanism to proceed to the next iteration of the loop from the middle of the
loop. The compiler may insert a branch to a NOP placed as the last instruction of the loop
to implement this function if required.
Because LCOUNT, LBEG, and LEND are single registers, zero-overhead loops may not be
nested. Using conditional branch instructions to implement outer level loops is typically
not a performance issue. Because loops cannot be nested, it is usually inappropriate to
include a procedure call inside a loop (the callee might itself use a zero-overhead loop).
To simplify the implementation of zero-overhead loops, the LBEG address, which is the
LOOP instruction address plus three, must be such that the first instruction must entirely
fit within a naturally aligned four byte region or, if the instruction is larger than four bytes,
a naturally aligned region which is the next power of two equal to or larger than the
instruction. When the LOOP instruction would not naturally be placed at such an
address, the insertion of NOP instructions or adjustment of which instructions are 16-bit
density instructions is sufficient to give it the required alignment.
The automatic loop-back when the PC increments to match LEND is disabled when
PS.EXCM is set. This prevents non-privileged code from affecting the operation of the
privileged exception vector code.
Assembler Note
When the label is out of range, the assembler may insert a number of instructions to
extend the size of the loop. Prefixing the instruction mnemonic with an underscore
(_LOOPGTZ) disables this feature and forces the assembler to generate an error in this
case.
Operation
LCOUNT ← AR[s] − 1
LBEG ← PC + 3
LEND ← PC + (024||imm8) + 4
if AR[s] ≤ 032 then
nextPC ← PC + (024||imm8) + 4
endif
Exceptions
Implementation Notes
In some implementations, LOOPGTZ takes an extra clock for the first loop back of certain
loops. In addition, certain instructions (such as ISYNC or a write to LEND) may cause an
additional cycle on the following loop back.
23 16 15 12 11 8 7 4 3 0
imm8 1 0 0 1 s 0 1 1 1 0 1 1 0
8 4 4 4 4
Assembler Syntax
Description
LOOPNEZ sets up a zero-overhead loop by setting the LCOUNT, LBEG, and LEND special
registers, which control instruction fetch. The loop will iterate the number of times speci-
fied by address register as with the zero value causing the loop to be skipped altogether
by branching directly to the loop end address. LCOUNT, the current loop iteration
counter, is loaded from the contents of address register as minus 1. LEND is the loop
end address and is loaded with the address of the LOOPNEZ instruction plus four plus
the zero-extended 8-bit offset encoded in the instruction (therefore, the loop code may
be up to 256 bytes in length). LBEG is loaded with the address of the following instruc-
tion (the address of the LOOPNEZ instruction plus three). LCOUNT, LEND, and LBEG are
still loaded even when the loop is skipped.
After the processor fetches an instruction that increments the PC to the value contained
in LEND, and LCOUNT is not zero, it loads the PC with the contents of LBEG and decre-
ments LCOUNT. LOOPNEZ is intended to be implemented with help from the instruction
fetch engine of the processor, and therefore should not incur a mispredict or taken
branch penalty. Branches and jumps to the address contained in LEND do not cause a
loop back, and therefore may be used to exit the loop prematurely. Similarly a return
from a call instruction as the last instruction of the loop would not trigger loop back; this
case should be avoided.
There is no mechanism to proceed to the next iteration of the loop from the middle of the
loop. The compiler may insert a branch to a NOP placed as the last instruction of the loop
to implement this function if required.
Because LCOUNT, LBEG, and LEND are single registers, zero-overhead loops may not be
nested. Using conditional branch instructions to implement outer level loops is typically
not a performance issue. Because loops cannot be nested, it is usually inappropriate to
include a procedure call inside a loop (the callee might itself use a zero-overhead loop).
To simplify the implementation of zero-overhead loops, the LBEG address, which is the
LOOP instruction address plus three, must be such that the first instruction must entirely
fit within a naturally aligned four byte region or, if the instruction is larger than four bytes,
a naturally aligned region which is the next power of two equal to or larger than the
instruction. When the LOOP instruction would not naturally be placed at such an ad-
dress, the insertion of NOP instructions or adjustment of which instructions are 16-bit
density instructions is sufficient to give it the required alignment.
The automatic loop-back when the PC increments to match LEND is disabled when
PS.EXCM is set. This prevents non-privileged code from affecting the operation of the
privileged exception vector code.
Assembler Note
When the label is out of range, the assembler may insert a number of instructions to
extend the size of the loop. Prefixing the instruction mnemonic with an underscore
(_LOOPNEZ) disables this feature and forces the assembler to generate an error in this
case.
Operation
LCOUNT ← AR[s] − 1
LBEG ← PC + 3
LEND ← PC + (024||imm8) + 4)
if AR[s] = 032 then
nextPC ← PC + (024||imm8) + 4
endif
Exceptions
Implementation Notes
In some implementations, LOOPNEZ takes an extra clock for the first loop back of certain
loops. In addition, certain instructions (such as ISYNC or a write to LEND) may cause an
additional cycle on the following loop back.
23 16 15 12 11 8 7 4 3 0
imm8 0 0 0 0 s t 0 0 1 1
8 4 4 4 4
Assembler Syntax
Description
LSI is a 32-bit load from memory to the floating-point register file. It forms a virtual ad-
dress by adding the contents of address register as and an 8-bit zero-extended constant
value encoded in the instruction word shifted left by two. Therefore, the offset can spec-
ify multiples of four from zero to 1020. Thirty-two bits (four bytes) are read from the
physical address. This data is then written to floating-point register ft.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Assembler Note
To form a virtual address, LSI calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 0 0 0 s t 0 0 1 1
8 4 4 4 4
Assembler Syntax
Description
LSIU is a 32-bit load from memory to the floating-point register file with base address
register update. It forms a virtual address by adding the contents of address register as
and an 8-bit zero-extended constant value encoded in the instruction word shifted left by
two. Therefore, the offset can specify multiples of four from zero to 1020. Thirty-two bits
(four bytes) are read from the physical address. This data is then written to floating-point
register ft and the virtual address is written back to address register as.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Assembler Note
To form a virtual address, LSIU calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 1 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
LSX is a 32-bit load from memory to the floating-point register file. It forms a virtual
address by adding the contents of address register as and the contents of address
register at. 32 bits (four bytes) are read from the physical address. This data is then
written to floating-point register fr.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 1 1 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
LSXU is a 32-bit load from memory to the floating-point register file with base address
register update. It forms a virtual address by adding the contents of address register as
and the contents of address register at. 32 bits (four bytes) are read from the physical
address. This data is then written to floating-point register fr and the virtual address is
written back to address register as.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MAX computes the maximum of the twos complement contents of address registers as
and at and writes the result to address register ar.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 1 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MAXU computes the maximum of the unsigned contents of address registers as and at
and writes the result to address register ar.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
MEMW
Description
MEMW ensures that all previous load, store, acquire, release, prefetch, and cache instruc-
tions perform before performing any subsequent load, store, acquire, release, prefetch,
or cache instructions. MEMW is intended to implement the volatile attribute of lan-
guages such as C and C++. The compiler should separate all volatile loads and
stores with a MEMW instruction. ISYNC should be used to cause instruction fetches to
wait as MEMW will have no effect on them.
Operation
memw()
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MIN computes the minimum of the twos complement contents of address registers as
and at and writes the result to address register ar.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 0 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MINU computes the minimum of the unsigned contents of address registers as and at,
and writes the result to address register ar.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Macro
Assembler Syntax
MOV ar, as
Description
MOV is an assembler macro that uses the OR instruction (page 466) to move the contents
of address register as to address register ar. The assembler input
MOV ar, as
expands into
OR ar, as, as
ar and as should not specify the same register due to the MOV.N restriction.
Assembler Note
The assembler may convert MOV instructions to MOV.N when the Code Density Option is
enabled. Prefixing the MOV instruction with an underscore (_MOV) disables this optimiza-
tion and forces the assembler to generate the OR form of the instruction.
Operation
AR[r] ← AR[s]
Exceptions
15 12 11 8 7 4 3 0
0 0 0 0 s t 1 1 0 1
4 4 4 4
Assembler Syntax
MOV.N at, as
Description
MOV.N is similar in function to the assembler macro MOV, but has a 16-bit encoding.
MOV.N moves the contents of address register as to address register at.
The operation of the processor when at and as specify the same register is undefined
and reserved for future use.
Assembler Note
The assembler may convert MOV.N instructions to MOV. Prefixing the MOV.N instruction
with an underscore (_MOV.N) disables this optimization and forces the assembler to
generate the narrow form of the instruction.
Operation
AR[t] ← AR[s]
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 1 0 1 0 r s 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
MOV.S fr, fs
Description
MOV.S moves the contents of floating-point register fs to floating-point register fr. The
move is non-arithmetic; no floating-point exceptions are raised.
Operation
FR[r] ← FR[s]
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 0 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MOVEQZ performs a conditional move if equal to zero. If the contents of address register
at are zero, then the processor sets address register ar to the contents of address reg-
ister as. Otherwise, MOVEQZ performs no operation and leaves address register ar
unchanged.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 0 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 0 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MOVF moves the contents of address register as to address register ar if Boolean regis-
ter bt is false. Address register ar is left unchanged if Boolean register bt is true.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 0 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 1 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MOVGEZ performs a conditional move if greater than or equal to zero. If the contents of
address register at are greater than or equal to zero (that is, the most significant bit is
clear), then the processor sets address register ar to the contents of address register
as. Otherwise, MOVGEZ performs no operation and leaves address register ar
unchanged.
Operation
if AR[t]31 = 0 then
AR[r] ← AR[s]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 1 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
if AR[t]31 = 0 then
FR[r] ← FR[s]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
imm12b7..0 1 0 1 0 imm12b11..8 t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
MOVI sets address register at to a constant in the range -2048..2047 encoded in the
instruction word. The constant is stored in two non-contiguous fields of the instruction
word. The processor decodes the constant specification by concatenating the two fields
and sign-extending the 12-bit value.
Assembler Note
The assembler will convert MOVI instructions into a literal load when given an immediate
operand that evaluates to a value outside the range -2048..2047. The assembler will
convert MOVI instructions to MOVI.N when the Code Density Option is enabled and the
immediate operand falls within the available range. Prefixing the MOVI instruction with
an underscore (_MOVI) disables these features and forces the assembler to generate
an error for the first case and the wide form of the instruction for the second case.
Operation
AR[t] ← imm121120||imm12
Exceptions
15 12 11 8 7 6 4 3 0
imm73..0 s 0 imm76..4 1 1 0 0
4 4 4 4
Assembler Syntax
Description
MOVI.N is similar to MOVI, but has a 16-bit encoding and supports a smaller range of
constant values encoded in the instruction word.
MOVI.N sets address register as to a constant in the range -32..95 encoded in the
instruction word. The constant is stored in two non-contiguous fields of the instruction
word. The range is asymmetric around zero because positive constants are more fre-
quent than negative constants. The processor decodes the constant specification by
concatenating the two fields and sign-extending the 7-bit value with the logical and of its
two most significant bits.
Assembler Note
The assembler may convert MOVI.N instructions to MOVI. Prefixing the MOVI.N instruc-
tion with an underscore (_MOVI.N) disables this optimization and forces the assembler
to generate the narrow form of the instruction.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 0 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MOVLTZ performs a conditional move if less than zero. If the contents of address register
at are less than zero (that is, the most significant bit is set), then the processor sets ad-
dress register ar to the contents of address register as. Otherwise, MOVLTZ performs
no operation and leaves address register ar unchanged.
Operation
if AR[t]31 ≠ 0 then
AR[r] ← AR[s]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 0 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
if AR[t]31 ≠ 0 then
FR[r] ← FR[s]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 1 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MOVNEZ performs a conditional move if not equal to zero. If the contents of address reg-
ister at are non-zero, then the processor sets address register ar to the contents of ad-
dress register as. Otherwise, MOVNEZ performs no operation and leaves address
register ar unchanged.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 1 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 0 1 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
MOVSP at, as
Description
MOVSP provides an atomic window check and register-to-register move. If the caller’s
registers are present in the register file, this instruction simply moves the contents of
address register as to address register at. If the caller’s registers are not present,
MOVSP raises an Alloca exception.
MOVSP is typically used to perform variable-size stack frame allocation. The Xtensa ABI
specifies that the caller’s a0-a3 may be stored just below the callee’s stack pointer.
When the stack frame is extended, these values may need to be moved. They can only
be moved with interrupts and exceptions disabled. This instruction provides a mecha-
nism to test if they must be moved, and if so, to raise an exception to move the data with
interrupts and exceptions disabled. The Xtensa ABI also requires that the caller’s return
address be in a0 when MOVSP is executed.
Operation
if WindowStartWindowBase-0011..WindowBase-0001 = 03 then
Exception (AllocaCause)
else
AR[t] ← AR[s]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 1 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MOVT moves the contents of address register as to address register ar if Boolean regis-
ter bt is true. Address register ar is left unchanged if Boolean register bt is false.
Operation
if BRt then
AR[r] ← AR[s]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 1 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
if BRt then
FR[r] ← FR[s]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MSUB.S multiplies the contents of floating-point registers fs and ft, subtracts the prod-
uct from the contents of floating-point register fr, and then writes the difference back to
floating-point register fr. The computation is performed with no intermediate round.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 1 0 1 half 0 0 0 0 s t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MUL.AA.* as, at
Where * expands as follows:
MUL.AA.LL - for (half=0)
MUL.AA.HL - for (half=1)
MUL.AA.LH - for (half=2)
MUL.AA.HH - for (half=3)
Description
MUL.AA.* performs a two’s complement multiply of half of each of the address registers
as and at, producing a 32-bit result. The result is sign-extended to 40 bits and written to
the MAC16 accumulator.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 1 0 1 half 0 0 0 0 s 0 y 0 0 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MUL.AD.* as, my
Where * expands as follows:
MUL.AD.LL - for (half=0)
MUL.AD.HL - for (half=1)
MUL.AD.LH - for (half=2)
MUL.AD.HH - for (half=3)
Description
MUL.AD.* performs a two’s complement multiply of half of address register as and half
of MAC16 register my, producing a 32-bit result. The result is sign-extended to 40 bits
and written to the MAC16 accumulator. The my operand can designate either MAC16
register m2 or m3.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 0 0 1 half 0 x 0 0 0 0 0 0 t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MUL.DA.* mx, at
Where * expands as follows:
MUL.DA.LL - for (half=0)
MUL.DA.HL - for (half=1)
MUL.DA.LH - for (half=2)
MUL.DA.HH - for (half=3)
Description
MUL.DA.* performs a two’s complement multiply of half of MAC16 register mx and half
of address register at, producing a 32-bit result. The result is sign-extended to 40 bits
and written to the MAC16 accumulator. The mx operand can designate either MAC16
register m0 or m1.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 0 1 half 0 x 0 0 0 0 0 0 0 y 0 0 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MUL.DD.* mx, my
Where * expands as follows:
MUL.DD.LL - for (half=0)
MUL.DD.HL - for (half=1)
MUL.DD.LH - for (half=2)
MUL.DD.HH - for (half=3)
Description
MUL.DD.* performs a two’s complement multiply of half of the MAC16 registers mx and
my, producing a 32-bit result. The result is sign-extended to 40 bits and written to the
MAC16 accumulator. The mx operand can designate either MAC16 register m0 or m1.
The my operand can designate either MAC16 register m2 or m3.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 1 0 0 0 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 0 0 0 0 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 1 1 0 half 0 0 0 0 s t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MULA.AA.* as, at
Where * expands as follows:
MULA.AA.LL - for (half=0)
MULA.AA.HL - for (half=1)
MULA.AA.LH - for (half=2)
MULA.AA.HH - for (half=3)
Description
MULA.AA.* performs a two’s complement multiply of half of each of the address regis-
ters as and at, producing a 32-bit result. The result is sign-extended to 40 bits and add-
ed to the contents of the MAC16 accumulator.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 1 1 0 half 0 0 0 0 s 0 y 0 0 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MULA.AD.* as, my
Where * expands as follows:
MULA.AD.LL - for (half=0)
MULA.AD.HL - for (half=1)
MULA.AD.LH - for (half=2)
MULA.AD.HH - for (half=3)
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 0 1 0 half 0 x 0 0 0 0 0 0 t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MULA.DA.* mx, at
Where * expands as follows:
MULA.DA.LL - for (half=0)
MULA.DA.HL - for (half=1)
MULA.DA.LH - for (half=2)
MULA.DA.HH - for (half=3)
Description
MULA.DA.* performs a two’s complement multiply of half of MAC16 register mx and half
of address register at, producing a 32-bit result. The result is sign-extended to 40 bits
and added to the contents of the MAC16 accumulator. The mx operand can designate
either MAC16 register m0 or m1.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 1 0 half 0 x w s t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
Description
First, it performs a two’s complement multiply of half of MAC16 register mx and half of
address register at, producing a 32-bit result. The result is sign-extended to 40 bits and
added to the contents of the MAC16 accumulator. The mx operand can designate either
MAC16 register m0 or m1.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
The MAC16 register source mx and the MAC16 register destination mw may be the
same. In this case, the instruction uses the contents of mx as the source operand prior to
loading mx with the load data.
Operation
vAddr ← AR[s] − 4
(mem32, error) ← Load32(vAddr)
if error then
EXCVADDR ← vAddr
Exception (LoadStoreErrorCause)
else
m1 ← if half0 then MR[0||x]31..16 else MR[0||x]15..0
m2 ← if half1 then AR[t]31..16 else AR[t]15..0
ACC ← ACC + (m11524||m1) × (m21524||m2)
AR[s] ← vAddr
MR[w] ← mem32
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 1 0 half 0 x w s t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
Description
First, it performs a two’s complement multiply of half of MAC16 register mx and half of
address register at, producing a 32-bit result. The result is sign-extended to 40 bits and
added to the contents of the MAC16 accumulator. The mx operand can designate either
MAC16 register m0 or m1.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
The MAC16 register source mx and the MAC16 register destination mw may be the
same. In this case, the instruction uses the contents of mx as the source operand prior to
loading mx with the load data.
Operation
vAddr ← AR[s] + 4
(mem32, error) ← Load32(vAddr)
if error then
EXCVADDR ← vAddr
Exception (LoadStoreErrorCause)
else
m1 ← if half0 then MR[0||x]31..16 else MR[0||x]15..0
m2 ← if half1 then AR[t]31..16 else AR[t]15..0
ACC ← ACC + (m11524||m1) × (m21524||m2)
AR[s] ← vAddr
MR[w] ← mem32
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 1 0 half 0 x 0 0 0 0 0 0 0 y 0 0 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MULA.DD.* mx, my
Where * expands as follows:
MULA.DD.LL - for (half=0)
MULA.DD.HL - for (half=1)
MULA.DD.LH - for (half=2)
MULA.DD.HH - for (half=3)
Description
MULA.DD.* performs a two’s complement multiply of half of each of the MAC16 regis-
ters mx and my, producing a 32-bit result. The result is sign-extended to 40 bits and add-
ed to the contents of the MAC16 accumulator. The mx operand can designate either
MAC16 register m0 or m1. The my operand can designate either MAC16 register m2 or
m3.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 1 1 0 half 0 x w s 0 y 0 0 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
Description
First, it performs a two’s complement multiply of half of the MAC16 registers mx and my,
producing a 32-bit result. The result is sign-extended to 40 bits and added to the con-
tents of the MAC16 accumulator. The mx operand can designate either MAC16 register
m0 or m1. The my operand can designate either MAC16 register m2 or m3.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
The MAC16 register destination mw may be the same as either MAC16 register source
mx or my. In this case, the instruction uses the contents of mx and my as the source oper-
ands prior to loading mw with the load data.
Operation
vAddr ← AR[s] − 4
(mem32, error) ← Load32(vAddr)
if error then
EXCVADDR ← vAddr
Exception (LoadStoreErrorCause)
else
m1 ← if half0 then MR[0||x]31..16 else MR[0||x]15..0
m2 ← if half1 then MR[1||y]31..16 else MR[1||y]15..0
ACC ← ACC + (m11524||m1) × (m21524||m2)
AR[s] ← vAddr
MR[w] ← mem32
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 1 0 half 0 x w s 0 y 0 0 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
Description
First, it performs a two’s complement multiply of half of each of the MAC16 registers mx
and my, producing a 32-bit result. The result is sign-extended to 40 bits and added to the
contents of the MAC16 accumulator. The mx operand can designate either MAC16 reg-
ister m0 or m1. The my operand can designate either MAC16 register m2 or m3.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
The MAC16 register destination mw may be the same as either MAC16 register source
mx or my. In this case, the instruction uses the contents of mx and my as the source
operands prior to loading mw with the load data.
Operation
vAddr ← AR[s] + 4
(mem32, error) ← Load32(vAddr)
if error then
EXCVADDR ← vAddr
Exception (LoadStoreErrorCause)
else
m1 ← if half0 then MR[0||x]31..16 else MR[0||x]15..0
m2 ← if half1 then MR[1||y]31..16 else MR[1||y]15..0
ACC ← ACC + (m11524||m1) × (m21524||m2)
AR[s] ← vAddr
MR[w] ← mem32
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 0 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MULL performs a 32-bit multiplication of the contents of address registers as and at,
and writes the least significant 32 bits of the product to address register ar. Because the
least significant product bits are unaffected by the multiplicand and multiplier sign, MULL
is useful for both signed and unsigned multiplication.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 1 1 1 half 0 0 0 0 s t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MULS.AA.* as, at
Where * expands as follows:
MULS.AA.LL - for (half=0)
MULS.AA.HL - for (half=1)
MULS.AA.LH - for (half=2)
MULS.AA.HH - for (half=3)
Description
MULS.AA.* performs a two’s complement multiply of half of each of the address regis-
ters as and at, producing a 32-bit result. The result is sign-extended to 40 bits and
subtracted from the contents of the MAC16 accumulator.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 1 1 1 half 0 0 0 0 s 0 y 0 0 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MULS.AD.* as, my
Where * expands as follows:
MULS.AD.LL - for (half=0)
MULS.AD.HL - for (half=1)
MULS.AD.LH - for (half=2)
MULS.AD.HH - for (half=3)
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 0 1 1 half 0 x 0 0 0 0 0 0 t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MULS.DA.* mx, at
Where * expands as follows:
MULS.DA.LL - for (half=0)
MULS.DA.HL - for (half=1)
MULS.DA.LH - for (half=2)
MULS.DA.HH - for (half=3)
Description
MULS.DA.* performs a two’s complement multiply of half of MAC16 register mx and half
of address register at, producing a 32-bit result. The result is sign-extended to 40 bits
and subtracted from the contents of the MAC16 accumulator. The mx operand can
designate either MAC16 register m0 or m1.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 1 1 half 0 x 0 0 0 0 0 0 0 y 0 0 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
MULS.DD.* mx, my
Where * expands as follows:
MULS.DD.LL - for (half=0)
MULS.DD.HL - for (half=1)
MULS.DD.LH - for (half=2)
MULS.DD.HH - for (half=3)
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 1 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
MULSH performs a 32-bit two’s complement multiplication of the contents of address reg-
isters as and at and writes the most significant 32 bits of the product to address register
ar.
Operation
tp ← (AR[s]3132||AR[s]) × (AR[t]3132||AR[t])
AR[r] ← tp63..32
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 0 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
tp ← (032||AR[s]) × (032||AR[t])
AR[r] ← tp63..32
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 0 0 0 0 0 r 0 0 0 0 t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
NEG ar, at
Description
NEG calculates the two’s complement negation of the contents of address register at
and writes it to address register ar. Arithmetic overflow is not detected.
Operation
AR[r] ← 0 − AR[t]
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 1 0 1 0 r s 0 1 1 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
NEG.S fr, fs
Description
Operation
FR[r] ← −s FR[s]
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 1 1 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
NOP
Description
This instruction performs no operation. It is typically used for instruction alignment. NOP
is a 24-bit instruction. For a 16-bit version, see NOP.N.
Assembler Note
The assembler may convert NOP instructions to NOP.N when the Code Density Option is
enabled. Prefixing the NOP instruction with an underscore (_NOP) disables this optimiza-
tion and forces the assembler to generate the wide form of the instruction.
Operation
none
Exceptions
Implementation Notes
In some implementations NOP is not an instruction but only an assembler macro that
uses the instruction “OR An, An, An” (with An a convenient register).
15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 0 0 0 1 1 1 1 0 1
4 4 4 4
Assembler Syntax
NOP.N
Description
Assembler Note
The assembler may convert NOP.N instructions to NOP. Prefixing the NOP.N instruction
with an underscore (_NOP.N) disables this optimization and forces the assembler to
generate the narrow form of the instruction.
Operation
none
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 1 1 1 0 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
NSA at, as
Description
NSA calculates the left shift amount that will normalize the twos complement contents of
address register as and writes this amount (in the range 0 to 31) to address register at.
If as contains 0 or -1, NSA returns 31. Using SSL and SLL to shift as left by the NSA
result yields the smallest value for which bits 31 and 30 differ unless as contains 0.
Operation
sign ← AR[s]31
if AR[s]30..0 = sign31 then
AR[t] ← 31
else
b4 ← AR[s]30..16 = sign15
t3 ← if b4 then AR[s]15..0 else AR[s]31..16
b3 ← t315..8 = sign8
t2 ← if b3 then t37..0 else t315..8
b2 ← t37..4 = sign4
t1 ← if b2 then t23..0 else t27..4
b1 ← t33..2 = sign2
b0 ← if b1 then t11 = sign else t13 = sign
AR[t] ← 027||((b4||b3||b2||b1||b0) − 1)
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 1 1 1 1 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
NSAU at, as
Description
NSAU calculates the left shift amount that will normalize the unsigned contents of
address register as and writes this amount (in the range 0 to 32) to address register at.
If as contains 0, NSAU returns 32. Using SSL and SLL to shift as left by the NSAU result
yields the smallest value for which bit 31 is set, unless as contains 0.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
OEQ.S compares the contents of floating-point registers fs and ft for IEEE754 equality.
If the values are ordered and equal then Boolean register br is set to 1, otherwise br is
set to 0. IEEE754 specifies that +0 and −0 compare as equal. IEEE754 floating-point
values are ordered if neither is a NaN.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 0 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
OLE.S compares the contents of floating-point registers fs and ft. If the contents of fs
are ordered with, and less than or equal to the contents of ft, then Boolean register br
is set to 1, otherwise br is set to 0. According to IEEE754, +0 and −0 compare as equal.
IEEE754 floating-point values are ordered if neither is a NaN.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
OLT.S compares the contents of floating-point registers fs and ft. If the contents of fs
are ordered with and less than the contents of ft then Boolean register br is set to 1,
otherwise br is set to 0. According to IEEE754, +0 and −0 compare as equal. IEEE754
floating-point values are ordered if neither is a NaN.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
OR ar, as, at
Description
OR calculates the bitwise logical or of address registers as and at. The result is written
to address register ar.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ORB performs the logical or of Boolean registers bs and bt, and writes the result to
Boolean register br.
When the sense of one of the source Booleans is inverted (0 → true, 1 → false), use
ORBC. When the sense of both of the source Booleans is inverted, use ANDB and an
inverted test of the result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 1 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ORBC performs the logical or of Boolean register bs with the logical complement of
Boolean register bt and writes the result to Boolean register br.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 1 1 0 1 s t 0 0 0 0
4 4 4 4 4 4
Region Translation Option (page 156) or the MMU Option (page 158)
Assembler Syntax
PDTLB at, as
Description
PDTLB searches the data TLB for an entry that translates the virtual address in address
register as and writes the way and index of that entry to address register at. If no entry
matches, zero is written to the hit bit of at. The value written to at is implementation-
specific, but in all implementations a value with the hit bit set is suitable as an input to
the IDTLB or WDTLB instructions. See Section 4.6 on page 138 for information on the re-
sult register formats for specific memory protection and translation options.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
(match, vpn, ei, wi) ← ProbeDataTLB(AR[s])
if match > 1 then
EXCVADDR ← AR[s]
Exception (LoadStoreTLBMultiHit)
else
AR[t] ← PackDataTLBEntrySpec(match, vpn, ei, wi)
endif
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 0 1 0 1 s t 0 0 0 0
4 4 4 4 4 4
Region Translation Option (page 156) or the MMU Option (page 158)
Assembler Syntax
PITLB at, as
Description
PITLB searches the Instruction TLB for an entry that translates the virtual address in
address register as and writes the way and index of that entry to address register at. If
no entry matches, zero is written to the hit bit of at. The value written to at is implemen-
tation-specific, but in all implementations a value with the hit bit set is suitable as an in-
put to the IITLB or WITLB instructions. See Section 4.6 on page 138 for information on
the result register formats for specific memory protection and translation options.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
(match, vpn, ei, wi) ← ProbeInstTLB(AR[s])
if match > 1 then
EXCVADDR ← AR[s]
Exception (InstructionFetchTLBMultiHit)
else
AR[t] ← PackInstTLBEntrySpec(match, vpn, ei, wi)
endif
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 1 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
QUOS performs a 32-bit two’s complement division of the contents of address register as
by the contents of address register at and writes the quotient to address register ar.
The ambiguity which exists when either address register as or address register at is
negative is resolved by requiring the product of the quotient and address register at to
be smaller in absolute value than the address register as. If the contents of address reg-
ister at are zero, QUOS raises an Integer Divide by Zero exception instead of writing a
result. Overflow (-2147483648 divided by -1) is not detected.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 0 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
QUOU performs a 32-bit unsigned division of the contents of address register as by the
contents of address register at and writes the quotient to address register ar. If the con-
tents of address register at are zero, QUOU raises an Integer Divide by Zero exception
instead of writing a result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 1 0 1 1 s t 0 0 0 0
4 4 4 4 4 4
Region Translation Option (page 156) or the MMU Option (page 158)
Assembler Syntax
RDTLB0 at, as
Description
RDTLB0 reads the data TLB entry specified by the contents of address register as and
writes the Virtual Page Number (VPN) and address space ID (ASID) to address register
at. See Section 4.6 on page 138 for information on the address and result register for-
mats for specific memory protection and translation options.
Operation
AR[t] ← RDTLB0(AR[s])
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 1 1 1 1 s t 0 0 0 0
4 4 4 4 4 4
Region Translation Option (page 156) or the MMU Option (page 158)
Assembler Syntax
RDTLB1 at, as
Description
RDTLB1 reads the data TLB entry specified by the contents of address register as and
writes the Physical Page Number (PPN) and cache attribute (CA) to address register
at. See Section 4.6 on page 138 for information on the address and result register for-
mats for specific memory protection and translation options.
Operation
AR[t] ← RDTLB1(AR[s])
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
REMS performs a 32-bit two’s complement division of the contents of address register as
by the contents of address register at and writes the remainder to address register ar.
The ambiguity which exists when either address register as or address register at is
negative is resolved by requiring the remainder to have the same sign as address regis-
ter as. If the contents of address register at are zero, REMS raises an Integer Divide by
Zero exception instead of writing a result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 0 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
REMU performs a 32-bit unsigned division of the contents of address register as by the
contents of address register at and writes the remainder to address register ar. If the
contents of address register at are zero, REMU raises an Integer Divide by Zero excep-
tion instead of writing a result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 0 1 1 0 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RER at, as
Description
RER reads one of a set of "External Registers". It is in some ways similar to the RSR.*
instruction except that the registers being read are not defined by the Xtensa ISA and
are conceptually outside the processor core. They are read through processor ports.
Address register as is used to determine which register is to be read and the result is
placed in address register at. When no External Register is addressed by the value in
address register as, the result in address register at is undefined. The entire address
space is reserved for use by Tensilica. RER and WER are managed by the processor core
so that the requests appear on the processor ports in program order. External logic is re-
sponsible for extending that order to the registers themselves.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
Read External Register as defined outside the processor.
endif
Exceptions
23 20 19 16 15 12 11 8 7 6 5 4 3 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
4 4 4 4 2 2 4
Assembler Syntax
RET
Description
RET returns from a routine called by CALL0 or CALLX0. It is equivalent to the instruction
JX A0
RET exists as a separate instruction because some Xtensa ISA implementations may
realize performance advantages from treating this operation as a special case.
Assembler Note
The assembler may convert RET instructions to RET.N when the Code Density Option is
enabled. Prefixing the RET instruction with an underscore (_RET) disables this optimiza-
tion and forces the assembler to generate the wide form of the instruction.
Operation
nextPC ← AR[0]
Exceptions
15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 0 0 0 0 0 1 1 0 1
4 4 4 4
Assembler Syntax
RET.N
Description
RET.N is the same as RET in a 16-bit encoding. RET returns from a routine called by
CALL0 or CALLX0.
Assembler Note
The assembler may convert RET.N instructions to RET. Prefixing the RET.N instruction
with an underscore (_RET.N) disables this optimization and forces the assembler to
generate the narrow form of the instruction.
Operation
nextPC ← AR[0]
Exceptions
23 20 19 16 15 12 11 8 7 6 5 4 3 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0
4 4 4 4 2 2 4
Assembler Syntax
RETW
Description
RETW returns from a subroutine called by CALL4, CALL8, CALL12, CALLX4, CALLX8, or
CALLX12, and that had ENTRY as its first instruction.
RETW uses bits 29..0 of address register a0 as the low 30 bits of the return address
and bits 31..30 of the address of the RETW as the high two bits of the return address.
Bits 31..30 of a0 are used as the caller’s window increment.
RETW subtracts the window increment from WindowBase to return to the caller’s regis-
ters. It then checks the WindowStart bit for this WindowBase. If it is set, then the
caller’s registers still reside in the register file, and RETW completes by clearing its own
WindowStart bit and jumping to the return address. If the WindowStart bit is clear,
then the caller’s registers have been stored into the stack, so RETW signals one of win-
dow underflow’s 4, 8, or 12, based on the size of the caller’s window increment. The un-
derflow handler is invoked with WindowBase decremented, a minor exception to the
rule that instructions aborted by an exception have no side effects to the operating state
of the processor. The processor stores the previous value of WindowBase in PS.OWB so
that it can be restored by RFWU.
The window underflow handler is expected to restore the caller’s registers, set the
caller’s WindowStart bit, and then return (see RFWU) to re-execute the RETW, which
will then complete.
underflow exception will be raised as described above, but if the wrong first one is set,
the state is not legal.) Some implementations raise an illegal instruction exception in
these cases as a debugging aid.
Assembler Note
The assembler may convert RETW instructions to RETW.N when the Code Density
Option is enabled. Prefixing the RETW instruction with an underscore (_RETW) disables
this optimization and forces the assembler to generate the wide form of the instruction.
Operation
n ← AR[0]31..30
nextPC ← PC31..30||AR[0]29..0
owb ← WindowBase
m ← if WindowStartWindowBase-4’b0001 then 2’b01
elsif WindowStartWindowBase-4’b0010 then 2’b10
elsif WindowStartWindowBase-4’b0011 then 2’b11
else 2’b00
if n=2’b00 | (m≠2’b00 & m≠n) | PS.WOE=0 | PS.EXCM=1 then
-- undefined operation
-- may raise illegal instruction exception
else
WindowBase ← WindowBase − (02||n)
if WindowStartWindowBase ≠ 0 then
WindowStartowb ← 0
else
-- Underflow exception
PS.EXCM ← 1
EPC[1] ← PC
PS.OWB ← owb
nextPC ← if n = 2'b01 then WindowUnderflow4
else if n = 2'b10 then WindowUnderflow8
else WindowUnderflow12
endif
endif
Exceptions
15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 0 0 0 0 1 1 1 0 1
4 4 4 4
Code Density Option (See Section 4.3.1 on page 53) and Windowed Register Option
(See Section 4.7.1 on page 180)
Assembler Syntax
RETW.N
Description
Assembler Note
The assembler may convert RETW.N instructions to RETW. Prefixing the RETW.N instruc-
tion with an underscore (_RETW.N) disables this optimization and forces the assembler
to generate the narrow form of the instruction.
Operation
n ← AR[0]31..30
nextPC ← PC31..30||AR[0]29..0
owb ← WindowBase
m ← if WindowStartWindowBase-4’b0001 then 2’b01
elsif WindowStartWindowBase-4’b0010 then 2’b10
elsif WindowStartWindowBase-4’b0011 then 2’b11
else 2’b00
if n=2’b00 | (m≠2’b00 & m≠n) | PS.WOE=0 | PS.EXCM=1 then
-- undefined operation
-- may raise illegal instruction exception
else
WindowBase ← WindowBase − (02||n)
if WindowStartWindowBase ≠ 0 then
WindowStartowb ← 0
else
-- Underflow exception
PS.EXCM ← 1
EPC[1] ← PC
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 1 1 1 1 0 0 0 0 s0 0 0 0 1 0 0 0 0
4 4 4 4 4 4
Debug Option (See Section 4.7.6 on page 197) and OCD, Implementation-Specific
Assembler Syntax
RFDD
Description
This instruction is used only in On-Chip Debug Mode and exists only in some implemen-
tations. It is an illegal instruction when the processor is not in On-Chip Debug Mode.
See the Tensilica On-Chip Debugging Guide for a description of its operation.
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RFDE
Description
RFDE returns from an exception that went to the double exception vector (that is, an ex-
ception raised while the processor was executing with PS.EXCM set). It is similar to RFE,
but PS.EXCM is not cleared, and DEPC, if it exists, is used instead of EPC[1]. RFDE sim-
ply jumps to the exception PC. PS.UM and PS.WOE are left unchanged.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
elsif NDEPC=1 then
nextPC ¨ DEPC
else
nextPC ← EPC[1]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Debug Option (See Section 4.7.6 on page 197) and OCD, Implementation-Specific
Assembler Syntax
RFDO
Description
This instruction is used only in On-Chip Debug Mode and exists only in some implemen-
tations. It is an illegal instruction when the processor is not in On-Chip Debug Mode.
See the Tensilica On-Chip Debugging Guide for a description of its operation.
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RFE
Description
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
PS.EXCM ← 0
nextPC ← EPC[1]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 1 level 0 0 0 1 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RFI 0..15
Description
RFI returns from a high-priority interrupt. It restores the PS from EPS[level] and
jumps to the address in EPC[level]. Level is given as a constant 2..(NLEVEL+NNMI)
in the instruction word. The operation of this opcode when level is 0 or 1 or greater than
(NLEVEL+NNMI) is undefined.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
nextPC ← EPC[level]
PS ← EPS[level]
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RFME
Description
RFME returns from a memory error exception. It restores the PS from MEPS and jumps to
the address in MEPC. In addition, the MEME bit of the MESR register is cleared.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
nextPC ← MEPC
PS ← MEPS
MESR.MEME ← 0
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 1 0 1 0 r s 0 1 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RFR ar, fs
Description
RFR moves the contents of floating-point register fs to address register ar. The move is
non-arithmetic; no floating-point exceptions are raised.
Operation
AR[r] ← FR[s]
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RFUE
Description
RFUE exists only in Xtensa Exception Architecture 1 (see Section A.2 “Xtensa Exception
Architecture 1” on page 611). It is an illegal instruction in current Xtensa implementa-
tions.
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RFWO
Description
RFWO returns from an exception that went to one of the three window overflow vectors. It
sets PS.EXCM back to 0, clears the WindowStart bit of the registers that were spilled,
restores WindowBase from PS.OWB, and then jumps to the address in EPC[1]. PS.UM
is left unchanged.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
PS.EXCM ← 0
nextPC ← EPC[1]
WindowStartWindowBase ← 0
WindowBase ← PS.OWB
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 1 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RFWU
Description
RFWU returns from an exception that went to one of the three window underflow vectors.
It sets PS.EXCM back to 0, sets the WindowStart bit of the registers that were reload-
ed, restores WindowBase from PS.OWB, and then jumps to the address in EPC[1].
PS.UM is left unchanged.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
PS.EXCM ← 0
nextPC ← EPC[1]
WindowStartWindowBase ← 1
WindowBase ← PS.OWB
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 0 0 1 1 s t 0 0 0 0
4 4 4 4 4 4
Region Translation Option (page 156) or the MMU Option (page 158)
Assembler Syntax
RITLB0 at, as
Description
RITLB0 reads the instruction TLB entry specified by the contents of address register as
and writes the Virtual Page Number (VPN) and address space ID (ASID) to address reg-
ister at. See Section 4.6 on page 138 for information on the address and result register
formats for specific memory protection and translation options.
Operation
AR[t] ← RITLB0(AR[s])
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 0 1 1 1 s t 0 0 0 0
4 4 4 4 4 4
Region Translation Option (page 156) or the MMU Option (page 158)
Assembler Syntax
RITLB1 at, as
Description
RITLB1 reads the instruction TLB entry specified by the contents of address register as
and writes the Physical Page Number (PPN) and cache attribute (CA) to address regis-
ter at. See Section 4.6 on page 138 for information on the address and result register
formats for specific memory protection and translation options.
Operation
AR[t] ← RITLB1(AR[s])
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 imm4 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
ROTW -8..7
Description
ROTW adds a constant to WindowBase, thereby moving the current window into the
register file. ROTW is intended for use in exception handlers and context switch code.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
WindowBase ← WindowBase + imm4
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 0 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 1 1 0 imm4 t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
RSIL first reads the PS Special Register (described in Table 4–63 on page 87, PS Reg-
ister Fields), writes this value to address register at, and then sets PS.INTLEVEL to a
constant in the range 0..15 encoded in the instruction word. Interrupts at and below the
PS.INTLEVEL level are disabled.
On some Xtensa ISA implementations the latency of RSIL is greater than one cycle,
and so it is advantageous to schedule uses of the RSIL result later.
The instruction following the RSIL is guaranteed to be executed at the new interrupt
level specified in PS.INTLEVEL, therefore it is not necessary to insert one of the SYNC
instructions to force the interrupt level change to take effect.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
AR[t] ← PS
Exceptions
23 20 19 16 15 8 7 4 3 0
0 0 0 0 0 0 1 1 sr t 0 0 0 0
4 4 8 4 4
Assembler Syntax
RSR.* at
RSR at, *
Description
RSR.* reads the Special Registers that are described in Section 3.8.10 “Processor Con-
trol Instructions” on page 45. See Section 5.3 on page 208 for more detailed information
on the operation of this instruction for each Special Register.
The contents of the Special Register designated by the 8-bit sr field of the instruction
word are written to address register at. The name of the Special Register is used in
place of the ‘*’ in the assembler syntax above and the translation is made to the 8-bit sr
field by the assembler.
RSR is an assembler macro for RSR.* that provides compatibility with the older versions
of the instruction containing either the name or the number of the Special Register.
A WSR.* followed by an RSR.* to the same register should be separated with ESYNC to
guarantee the value written is read back. On some Xtensa ISA implementations, the la-
tency of RSR.* is greater than one cycle, and so it is advantageous to schedule other
instructions before instructions that use the RSR.* result.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
RSYNC
Description
RSYNC waits for all previously fetched WSR.* instructions to be performed before inter-
preting the register fields of the next instruction. This operation is also performed as part
of ISYNC. ESYNC and DSYNC are performed as part of this instruction.
Operation
rsync()
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 0 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
No Option - instructions created from the TIE language (See Section 4.3.9.2 “Coproces-
sor Context Switch” on page 64)
Assembler Syntax
RUR.* ar
RUR ar, *
Description
RUR.* reads TIE state that has been grouped into 32-bit quantities by the TIE
user_register statement. The name in the user_register statement replaces the
“*” in the instruction name and causes the correct register number to be placed in the st
field of the encoded instruction. The contents of the TIE user_register designated by
the 8-bit number 16*s+t are written to address register ar. Here s and t are the
numbers corresponding to the respective fields of the instruction word.
RUR is an assembler macro for RUR.*, which provides compatibility with the older
version of the instruction.
Operation
AR[r] ← user_register[st]
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 0 0 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
S8I is an 8-bit store from address register at to memory. It forms a virtual address by
adding the contents of address register as and an 8-bit zero-extended constant value
encoded in the instruction word. Therefore, the offset has a range from 0 to 255. Eight
bits (1 byte) from the least significant quarter of address register at are written to mem-
ory at the physical address.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 0 1 s t 0 0 1 0
8 4 4 4 4
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the least significant bit of the
address is ignored. A reference to an odd address produces the same result as a refer-
ence to the address, minus one. With the Unaligned Exception Option, such an access
raises an exception.
Assembler Note
To form a virtual address, S16I calculates the sum of address register as and the imm8
field of the instruction word times two. Therefore, the machine-code offset is in terms of
16-bit (2 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by two.
Operation
vAddr ← AR[s] + (023||imm8||0)
Store16 (vAddr, AR[t]15..0)
Exceptions
Memory Store Group (see page 245)
23 16 15 12 11 8 7 4 3 0
imm8 1 1 1 0 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
From a memory ordering point of view, the atomic pair of accesses has the characteris-
tics of both an acquire and a release. That is, the atomic pair of accesses does not begin
until all previous loads, stores, acquires, and releases have performed. The atomic pair
must perform before any following load, store, acquire, or release may begin.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
S32C1I does both a load and a store when the store is successful. However, memory
protection tests check for store capability and the instruction may raise a
StoreProhibitedCause exception, but will never raise a LoadProhibited Cause exception.
Assembler Note
To form a virtual address, S32C1I calculates the sum of address register as and the
imm8 field of the instruction word times four. Therefore, the machine-code offset is in
terms of 32-bit (4 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by four.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 1 0 0 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
S32E is a 32-bit store instruction similar to S32I, but with semantics required by window
overflow and window underflow exception handlers. In particular, memory access check-
ing is done with PS.RING instead of CRING, and the offset used to form the virtual ad-
dress is a 4-bit one-extended immediate. Therefore, the offset can specify multiples of
four from -64 to -4. In configurations without the MMU Option, there is no PS.RING and
S32E is similar to S32I with a negative offset.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Assembler Note
To form a virtual address, S32E calculates the sum of address register as and the r field
of the instruction word times four (and one extended). Therefore, the machine-code
offset is in terms of 32-bit (4 byte) units. However, the assembler expects a byte offset
and encodes this into the instruction by dividing by four.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
vAddr ← AR[s] + (126||r||02)
ring ← if MMU Option then PS.RING else 0
Store32Ring (vAddr, AR[t], ring)
endif
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 1 0 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
S32I is a 32-bit store from address register at to memory. It forms a virtual address by
adding the contents of address register as and an 8-bit zero-extended constant value
encoded in the instruction word shifted left by two. Therefore, the offset can specify mul-
tiples of four from zero to 1020. The data to be stored is taken from the contents of ad-
dress register at and written to memory at the physical address.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an er-
ror (for example, protection violation or non-existent memory), the processor raises one
of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
S32I is one of only a few memory reference instructions that can access instruction
RAM.
Assembler Note
The assembler may convert S32I instructions to S32I.N when the Code Density
Option is enabled and the imm8 operand falls within the available range. Prefixing the
S32I instruction with an underscore (_S32I) disables this optimization and forces the
assembler to generate the wide form of the instruction.
To form a virtual address, S32I calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
15 12 11 8 7 4 3 0
imm4 s t 1 0 0 1
4 4 4 4
Assembler Syntax
Description
S32I.N is similar to S32I, but has a 16-bit encoding and supports a smaller range of
offset values encoded in the instruction word.
S32I.N is a 32-bit store to memory. It forms a virtual address by adding the contents of
address register as and an 4-bit zero-extended constant value encoded in the instruc-
tion word shifted left by two. Therefore, the offset can specify multiples of four from zero
to 60. The data to be stored is taken from the contents of address register at and written
to memory at the physical address.
S32I.N is one of only a few memory reference instructions that can access instruction
RAM.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Options, such an access raises an exception.
Assembler Note
The assembler may convert S32I.N instructions to S32I. Prefixing the S32I.N instruc-
tion with an underscore (_S32I.N) disables this optimization and forces the assembler
to generate the narrow form of the instruction.
To form a virtual address, S32I.N calculates the sum of address register as and the
imm4 field of the instruction word times four. Therefore, the machine-code offset is in
terms of 32-bit (4 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by four.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 1 1 1 s t 0 0 1 0
8 4 4 4 4
Assembler Syntax
Description
S32RI is a store barrier and 32-bit store from address register at to memory. S32RI
stores to synchronization variables, which signals that previously written data is
“released” for consumption by readers of the synchronization variable. This store will not
perform until all previous loads, stores, acquires, and releases have performed. This
ensures that any loads of the synchronization variable that see the new value will also
find all previously written data available as well.
S32RI forms a virtual address by adding the contents of address register as and an
8-bit zero-extended constant value encoded in the instruction word shifted left by two.
Therefore, the offset can specify multiples of four from zero to 1020. S32RI waits for
previous loads, stores, acquires, and releases to be performed, and then the data to be
stored is taken from the contents of address register at and written to memory at the
physical address. Because the method of waiting is implementation dependent, this is
indicated in the operation section below by the implementation function release.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without theUnaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Assembler Note
To form a virtual address, S32RI calculates the sum of address register as and the
imm8 field of the instruction word times four. Therefore, the machine-code offset is in
terms of 32-bit (4 byte) units. However, the assembler expects a byte offset and encodes
this into the instruction by dividing by four.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 1 1 0 0 1 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SDCT at, as
Description
SDCT is not part of the Xtensa Instruction Set Architecture, but is instead specific to an
implementation. That is, it may not exist in all implementations of the Xtensa ISA.
SDCT is intended for writing the RAM array that implements the data cache tags as part
of manufacturing test.
SDCT uses the contents of address register as to select a line in the data cache and
writes the contents of address register at to the tag associated with that line. The value
written from at is described under Cache Tag Format in Section 4.5.1.2 on page 112.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
index ← AR[s]dih..dil
DataCacheTag[index] ← AR[t]
endif
Exceptions
Implementation Notes
x ← ceil(log2(DataCacheBytes))
y ← log2(DataCacheBytes ÷ DataCacheWayCount)
z ← log2(DataCacheLineBytes)
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 0 0 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SEXT takes the contents of address register as and replicates the bit specified by its
immediate operand (in the range 7 to 22) to the high bits and writes the result to address
register ar. The input can be thought of as an imm+1 bit value with the high bits irrele-
vant and this instruction produces the 32-bit sign-extension of this value.
Assembler Note
The immediate values accepted by the assembler are 7 to 22. The assembler encodes
these in the t field of the instruction using 0 to 15.
Operation
b ← t+7
AR[r] ← AR[s]b31−b||AR[s]b..0
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 1 0 0 0 1 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SICT at, as
Description
SICT is not part of the Xtensa Instruction Set Architecture, but is instead specific to an
implementation. That is, it may not exist in all implementations of the Xtensa ISA.
SICT is intended for writing the RAM array that implements the instruction cache tags as
part of manufacturing test.
SICT uses the contents of address register as to select a line in the instruction cache,
and writes the contents of address register at to the tag associated with that line. The
value written from at is described under Cache Tag Format in Section 4.5.1.2 on
page 112.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
index ← AR[s]iih..iil
InstCacheTag[index] ← AR[t]
endif
Exceptions
Implementation Notes
x ← ceil(log2(InstCacheBytes))
y ← log2(InstCacheBytes ÷ InstCacheWayCount)
z ← log2(InstCacheLineBytes)
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 1 0 0 1 1 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SICW at, as
Description
SICW is not part of the Xtensa Instruction Set Architecture, but is instead specific to an
implementation. That is, it may not exist in all implementations of the Xtensa ISA.
SICW is intended for writing the RAM array that implements the instruction cache as part
of manufacturing tests.
SICW uses the contents of address register as to select a line in the instruction cache,
and writes the contents of address register at to the data associated with that line.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
index ← AR[s]iih..iiw
InstCacheData [index] ← AR[t]
endif
Exceptions
Implementation Notes
x ← ceil(log2(InstCacheBytes))
y ← log2(InstCacheBytes ÷ InstCacheWayCount)
z ← log2(InstCacheLineBytes)
The width of the instruction cache RAM may be more than 32 bits depending on the con-
figuration. In that case, some implementations may write the same data replicated
enough times to fill the entire width of the RAM.
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SIMCALL
Description
The value in address register a2 is the request code. Most codes request host system
call services while others are used for special purposes such as debugging. Arguments
needed by host system calls will be found in a3, a4, and a5 and a return code will be
stored to a2 and an error number to a3.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 0 0 0 0 1 r s 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SLL ar, as
Description
SLL shifts the contents of address register as left by the number of bit positions speci-
fied (as 32 minus number of bit positions) in the SAR (shift amount register) and writes
the result to address register ar. Typically the SSL or SSA8L instructions are used to
specify the left shift amount by loading SAR with 32-shift. This transformation allows
SLL to be implemented in the SRC funnel shifter (which only shifts right), using the SLL
data as the most significant 32 bits and zero as the least significant 32 bits. Note the
result of SLL is undefined if SAR > 32.
Operation
sa ← SAR5..0
AR[r] ← (AR[s]||032)31+sa..sa
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 sa4 0 0 0 1 r s sa3..0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SLLI shifts the contents of address register as left by a constant amount in the range
1..31 encoded in the instruction. The shift amount sa field is split, with bits 3..0 in bits
7..4 of the instruction word and bit 4 in bit 20 of the instruction word. The shift amount is
encoded as 32−shift. When the sa field is 0, the result of this instruction is undefined.
Assembler Note
The shift amount is specified in the assembly language as the number of bit positions to
shift left. The assembler performs the 32-shift calculation when it assembles the in-
struction word. When the immediate operand evaluates to zero, the assembler converts
this instruction to an OR instruction to effect a register-to-register move. To disable this
transformation, prefix the mnemonic with an underscore (_SLLI). If imm evaluates to
zero when the mnemonic has the underscore prefix, the assembler will emit an error.
Operation
AR[r] ← (AR[s]||032)31+sa..sa
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 1 1 0 0 0 1 r 0 0 0 0 t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SRA ar, at
Description
SRA arithmetically shifts the contents of address register at right, inserting the sign of
at on the left, by the number of bit positions specified by SAR (shift amount register) and
writes the result to address register ar. Typically the SSR or SSA8B instructions are used
to load SAR with the shift amount from an address register. Note the result of SRA is un-
defined if SAR > 32.
Operation
sa ← SAR5..0
AR[r] ← ((AR[t]31)32||AR[t])31+sa..sa
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 sa4 0 0 0 1 r sa3..0 t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SRAI arithmetically shifts the contents of address register at right, inserting the sign of
at on the left, by a constant amount encoded in the instruction word in the range 0..31.
The shift amount sa field is split, with bits 3..0 in bits 11..8 of the instruction word,
and bit 4 in bit 20 of the instruction word.
Operation
AR[r] ← ((AR[t]31)32||AR[t])31+sa..sa
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 0 0 0 0 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SRC performs a right shift of the concatenation of address registers as and at by the
shift amount in SAR. The least significant 32 bits of the shift result are written to address
register ar. A shift with a wider input than output is called a funnel shift. SRC directly per-
forms right funnel shifts. Left funnel shifts are done by swapping the high and low oper-
ands to SRC and setting SAR to 32 minus the shift amount. The SSL and SSA8B instruc-
tions directly implement such SAR settings. Note the result of SRC is undefined if SAR >
32.
Operation
sa ← SAR5..0
AR[r] ← (AR[s]||AR[t])31+sa..sa
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 1 0 0 0 1 r 0 0 0 0 t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SRL ar, at
Description
SRL shifts the contents of address register at right, inserting zeros on the left, by the
number of bits specified by SAR (shift amount register) and writes the result to address
register ar. Typically the SSR or SSA8B instructions are used to load SAR with the shift
amount from an address register. Note the result of SRL is undefined if SAR > 32.
Operation
sa ← SAR5..0
AR[r] ← (032||AR[t])31+sa..sa
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 1 r sa t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SRLI shifts the contents of address register at right, inserting zeros on the left, by a
constant amount encoded in the instruction word in the range 0..15. There is no SRLI
for shifts ≥ 16. EXTUI replaces these shifts.
Assembler Note
The assembler converts SRLI instructions with a shift amount ≥ 16 into EXTUI. Prefixing
the SRLI instruction with an underscore (_SRLI) disables this replacement and forces
the assembler to generate an error.
Operation
AR[r] ← (032||AR[t])31+sa..sa
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 0 0 1 1 s 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SSA8B as
Description
SSA8B sets the shift amount register (SAR) for a left shift by multiples of eight (for exam-
ple, for big-endian (BE) byte alignment). The left shift amount is the two least significant
bits of address register as multiplied by eight. Thirty-two minus this amount is written to
SAR. Using 32 minus the left shift amount causes a funnel right shift and swapped high
and low input operands to perform a left shift. SSA8B is similar to SSL, except the shift
amount is multiplied by eight.
SSA8B is typically used to set up for an SRC instruction to shift bytes. It may be used with
big-endian byte ordering to extract a 32-bit value from a non-aligned byte address.
Operation
SAR ← 32 − (0||AR[s]1..0||03)
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 0 0 1 0 s 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SSA8L as
Description
SSA8L sets the shift amount register (SAR) for a right shift by multiples of eight (for ex-
ample, for little-endian (LE) byte alignment). The right shift amount is the two least sig-
nificant bits of address register as multiplied by eight, and is written to SAR. SSA8L is
similar to SSR, except the shift amount is multiplied by eight.
SSA8L is typically used to set up for an SRC instruction to shift bytes. It may be used with
little-endian byte ordering to extract a 32-bit value from a non-aligned byte address.
Operation
SAR ← 0||AR[s]1..0||03
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 0 1 0 0 sa3..0 0 0 0 sa4 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SSAI 0..31
Description
SSAI sets the shift amount register (SAR) to a constant. The shift amount sa field is split,
with bits 3..0 in bits 11..8 of the instruction word, and bit 4 in bit 4 of the instruction
word. Because immediate forms exist of most shifts (SLLI, SRLI, SRAI), this is primari-
ly useful to set the shift amount for SRC.
Operation
SAR ← 0||sa
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 0 1 0 0 s t 0 0 1 1
8 4 4 4 4
Assembler Syntax
Description
SSI is a 32-bit store from floating-point register ft to memory. It forms a virtual address
by adding the contents of address register as and an 8-bit zero-extended constant value
encoded in the instruction word shifted left by two. Therefore, the offset can specify mul-
tiples of four from zero to 1020. The data to be stored is taken from the contents of float-
ing-point register ft and written to memory at the physical address.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Assembler Note
To form a virtual address, SSI calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
23 16 15 12 11 8 7 4 3 0
imm8 1 1 0 0 s t 0 0 1 1
8 4 4 4 4
Assembler Syntax
Description
SSIU is a 32-bit store from floating-point register ft to memory with base address regis-
ter update. It forms a virtual address by adding the contents of address register as and
an 8-bit zero-extended constant value encoded in the instruction word shifted left by two.
Therefore, the offset can specify multiples of four from zero to 1020. The data to be
stored is taken from the contents of floating-point register ft and written to memory at
the physical address. The virtual address is written back to address register as.
If the Region Translation Option (page 156) or the MMU Option (page 158) is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Assembler Note
To form a virtual address, SSIU calculates the sum of address register as and the imm8
field of the instruction word times four. Therefore, the machine-code offset is in terms of
32-bit (4 byte) units. However, the assembler expects a byte offset and encodes this into
the instruction by dividing by four.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 0 0 0 1 s 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SSL as
Description
SSL sets the shift amount register (SAR) for a left shift (for example, SLL). The left shift
amount is the 5 least significant bits of address register as. 32 minus this amount is writ-
ten to SAR. Using 32 minus the left shift amount causes a right funnel shift, and swapped
high and low input operands to perform a left shift.
Operation
sa ← AR[s]4..0
SAR ← 32 − (0||sa)
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 0 0 0 0 s 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SSR as
Description
SSR sets the shift amount register (SAR) for a right shift (for example, SRL, SRA, or SRC).
The least significant five bits of address register as are written to SAR. The most signifi-
cant bit of SAR is cleared. This instruction is similar to a WSR.SAR, but differs in that only
AR[s]4..0 is used, instead of AR[s]5..0.
Operation
sa ← AR[s]4..0
SAR ← 0||sa
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 1 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SSX is a 32-bit store from floating-point register ft to memory. It forms a virtual address
by adding the contents of address register as and the contents of address register at.
The data to be stored is taken from the contents of floating-point register fr and written
to memory at the physical address.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 1 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SSXU is a 32-bit store from floating-point register ft to memory with base address regis-
ter update. It forms a virtual address by adding the contents of address register as and
the contents of address register at. The data to be stored is taken from the contents of
floating-point register fr and written to memory at the physical address. The virtual ad-
dress is written back to address register as.
If the Region Translation Option (page 156) or the MMU Option (page 158)is enabled,
the virtual address is translated to the physical address. If not, the physical address is
identical to the virtual address. If the translation or memory reference encounters an
error (for example, protection violation or non-existent memory), the processor raises
one of several exceptions (see Section 4.4.1.5 on page 89).
Without the Unaligned Exception Option (page 99), the two least significant bits of the
address are ignored. A reference to an address that is not 0 mod 4 produces the same
result as a reference to the address with the least significant bits cleared. With the Un-
aligned Exception Option, such an access raises an exception.
Operation
vAddr ← AR[s] + (AR[t])
Store32 (vAddr, FR[r])
AR[s] ← vAddr
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 0 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SUB calculates the two’s complement 32-bit difference of address registers as and at.
The low 32 bits of the difference are written to address register ar. Arithmetic overflow is
not detected.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 1 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 1 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SUBX2 calculates the two’s complement 32-bit difference of address register as shifted
left by 1 bit and address register at. The low 32 bits of the difference are written to
address register ar. Arithmetic overflow is not detected.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 0 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SUBX4 calculates the two’s complement 32-bit difference of address register as shifted
left by two bits and address register at. The low 32 bits of the difference are written to
address register ar. Arithmetic overflow is not detected.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
SUBX8 calculates the two’s complement 32-bit difference of address register as shifted
left by three bits and address register at. The low 32 bits of the difference are written to
address register ar. Arithmetic overflow is not detected.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
SYSCALL
Description
When executed, the SYSCALL instruction raises a system-call exception, redirecting ex-
ecution to an exception vector (see Section 4.4.1 on page 82). Therefore, SYSCALL in-
structions never complete. EPC[1] contains the address of the SYSCALL and ICOUNT is
not incremented. The system call handler should add 3 to EPC[1] before returning from
the exception to continue execution.
The program may pass parameters to the system-call handler in the registers. There are
no bits in SYSCALL instruction reserved for this purpose. See Section 8.2.2 “System
Calls” on page 597 for a description of software conventions for system call parameters.
Operation
Exception (SyscallCause)
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 0 0 1 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 1 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
UEQ.S compares the contents of floating-point registers fs and ft. If the values are
equal or unordered then Boolean register br is set to 1, otherwise br is set to 0. Accord-
ing to IEEE754, +0 and −0 compare as equal. IEEE754 floating-point values are
unordered if either of them is a NaN.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 0 1 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
UFLOAT.S converts the contents of address register as from unsigned integer to single-
precision format, rounding according to the current rounding mode. The converted inte-
ger value is then scaled by a power of two constant value encoded in the t field, with
0..15 representing 1.0, 0.5, 0.25, …, 1.0÷s32768.0. The scaling allows for a fixed point
notation where the binary point is at the right end of the integer for t=0, and moves to
the left as t increases until for t=15 there are 15 fractional bits represented in the fixed
point number. The result is written to floating-point register fr.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 1 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ULE.S compares the contents of floating-point registers fs and ft. If the contents of fs
are less than or equal to or unordered with the contents of ft, then Boolean register br
is set to 1, otherwise br is set to 0. IEEE754 specifies that +0 and −0 compare as equal.
IEEE754 floating-point values are unordered if either of them is a NaN.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
ULT.S compares the contents of floating-point registers fs and ft. If the contents of fs
are less than or unordered with the contents of ft, then Boolean register br is set to 1,
otherwise br is set to 0. IEEE754 specifies that +0 and −0 compare as equal. IEEE754
floating-point values are unordered if either of them is a NaN.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 1 1 0 0 half 0 0 0 0 s t 0 1 0 0
4 4 4 4 4 4
Assembler Syntax
UMUL.AA.* as, at
Where * expands as follows:
UMUL.AA.LL - for (half=0)
UMUL.AA.HL - for (half=1)
UMUL.AA.LH - for (half=2)
UMUL.AA.HH - for (half=3)
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 1 1 0 1 1 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 0 1 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 0 0 0 0 0 0 0 1 1 1 imm4 0 0 0 0 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
WAITI 0..15
Description
WAITI sets the interrupt level in PS.INTLEVEL to imm4 and then, on some Xtensa ISA
implementations, suspends processor operation until an interrupt occurs. WAITI is typi-
cally used in an idle loop to reduce power consumption. CCOUNT continues to increment
during suspended operation, and a CCOMPARE interrupt will wake the processor.
When an interrupt is taken during suspended operation, EPC[i] will have the address
of the instruction following WAITI. An implementation is not required to enter suspended
operation and may leave suspended operation and continue execution at the following
instruction at any time. Usually, therefore, the WAITI instruction should be within a loop.
The combination of setting the interrupt level and suspending operation avoids a race
condition where an interrupt between the interrupt level setting and the suspension of
operation would be ignored until a second interrupt occurred.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
PS.INTLEVEL ← imm4
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 1 1 1 0 s t 0 0 0 0
4 4 4 4 4 4
Region Translation Option (page 156) or the MMU Option (page 158)
Assembler Syntax
WDTLB at, as
Description
WDTLB uses the contents of address register as to specify a data TLB entry and writes
the contents of address register at into that entry. See Section 4.6 on page 138 for in-
formation on the address and result register formats for specific memory protection and
translation options. The point at which the data TLB write is effected is implementation-
specific. Any translation that would be affected by this write before the execution of a
DSYNC instruction is therefore undefined.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
(vpn, ei, wi) ← SplitDataTLBEntrySpec(AR[s])
(ppn, sr, ring, ca) ← SplitDataEntry(wi, AR[t])
DataTLB[wi][ei].ASID ← ASID(ring)
DataTLB[wi][ei].VPN ← vpn
DataTLB[wi][ei].PPN ← ppn
DataTLB[wi][ei].SR ← sr
DataTLB[wi][ei].CA ← ca
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 0 0 0 1 1 1 s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
WER at, as
Description
WER writes one of a set of "External Registers". It is in some ways similar to the WSR.*
instruction except that the registers being written are not defined by the Xtensa ISA and
are conceptually outside the processor core. They are written through processor ports.
Address register as is used to determine which register is to be written and address reg-
ister at provides the write data. When no External Register is addressed by the value in
address register as, no write occurs. The entire address space is reserved for use by
Tensilica. RER and WER are managed by the processor core so that the requests appear
on the processor ports in program order. External logic is responsible for extending that
order to the registers themselves.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
Write External Register as defined outside the processor.
endif
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
1 1 1 1 1 0 1 0 r s 0 1 0 1 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
WFR fr, as
Description
WFR moves the contents of address register as to floating-point register fr. The move is
non-arithmetic; no floating-point exceptions are raised.
Operation
FR[r] ← AR[s]
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 1 0 0 0 0 0 1 1 0 s t 0 0 0 0
4 4 4 4 4 4
Region Translation Option (page 156) or the MMU Option (page 158)
Assembler Syntax
WITLB at, as
Description
WITLB uses the contents of address register as to specify an instruction TLB entry and
writes the contents of address register at into that entry. See Section 4.6 on page 138
for information on the address and result register formats for specific memory protection
and translation options. The point at which the instruction TLB write is effected is imple-
mentation-specific. Any translation that would be affected by this write before the execu-
tion of an ISYNC instruction is therefore undefined.
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
(vpn, ei, wi) ← SplitInstTLBEntrySpec(AR[s])
(ppn, sr, ring, ca) ← SplitInstEntry(wi, AR[t])
InstTLB[wi][ei].ASID ← ASID(ring)
InstTLB[wi][ei].VPN ← vpn
InstTLB[wi][ei].PPN ← ppn
InstTLB[wi][ei].SR ← sr
InstTLB[wi][ei].CA ← ca
endif
Exceptions
23 20 19 16 15 8 7 4 3 0
0 0 0 1 0 0 1 1 sr t 0 0 0 0
4 4 8 4 4
Assembler Syntax
WSR.* at
WSR at, *
Description
WSR.* writes the special registers that are described in Section 3.8.10 “Processor Con-
trol Instructions” on page 45. See Section 5.3 on page 208 for more detailed information
on the operation of this instruction for each Special Register.
The contents of address register at are written to the special register designated by the
8-bit sr field of the instruction word. The name of the Special Register is used in place
of the ‘*’ in the assembler syntax above and the translation is made to the 8-bit sr field
by the assembler.
WSR is an assembler macro for WSR.* that provides compatibility with the older versions
of the instruction containing either the name or the number of the Special Register.
The point at which WSR.* to certain registers affects subsequent instructions is not al-
ways defined (SAR and ACC are exceptions). In these cases, the Special Register Tables
in Section 5.3 on page 208 explain how to ensure the effects are seen by a particular
point in the instruction stream (typically involving the use of one of the ISYNC, RSYNC,
ESYNC, or DSYNC instructions). A WSR.* followed by an RSR.* to the same register
should be separated with an ESYNC to guarantee the value written is read back. A
WSR.PS followed by RSIL also requires an ESYNC.
Operation
Exceptions
23 20 19 16 15 8 7 4 3 0
1 1 1 1 0 0 1 1 sr t 0 0 0 0
4 4 8 4 4
No Option - instructions created from the TIE language (See Section 4.3.9.2 “Coproces-
sor Context Switch” on page 64)
Assembler Syntax
WUR.* at
WUR at,*
Description
WUR.* writes TIE state that has been grouped into 32-bit quantities by the TIE
user_register statement. The name in the user_register statement replaces the
“*” in the instruction name and causes the correct register number to be placed in the st
field of the encoded instruction. The contents of address register at are written to the
TIE user_register designated by the 8-bit sr field of the instruction word.
WUR is an assembler macro for WUR.* that provides compatibility with the older version
of the instruction.
Operation
user_register[sr] ← AR[t]
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 0 1 1 0 0 0 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
XOR calculates the bitwise logical exclusive or of address registers as and at. The
result is written to address register ar.
Operation
Exceptions
23 20 19 16 15 12 11 8 7 4 3 0
0 1 0 0 0 0 1 0 r s t 0 0 0 0
4 4 4 4 4 4
Assembler Syntax
Description
XORB performs the logical exclusive or of Boolean registers bs and bt and writes the
result to Boolean register br.
When the sense of one of the source Booleans is inverted (0 → true, 1 → false), use an
inverted test of the result. When the sense of both of the source Booleans is inverted,
use a non-inverted test of the result.
Operation
Exceptions
23 20 19 16 15 8 7 4 3 0
0 1 1 0 0 0 0 1 sr t 0 0 0 0
4 4 8 4 4
Assembler Syntax
XSR.* at
XSR at, *
Description
XSR.* simultaneously reads and writes the special registers that are described in
Section 3.8.10 “Processor Control Instructions” on page 45. See Section 5.3 on
page 208 for more detailed information on the operation of this instruction for each
Special Register.
The contents of address register at and the Special Register designated by the immedi-
ate in the 8-bit sr field of the instruction word are both read. The read address register
value is then written to the Special Register, and the read Special Register value is writ-
ten to at. The name of the Special Register is used in place of the ‘*’ in the assembler
syntax above and the translation is made to the 8-bit sr field by the assembler.
XSR is an assembler macro for XSR.*, which provides compatibility with the older ver-
sions of the instruction containing either the name or the number of the Special Register.
The point at which XSR.* to certain registers affects subsequent instructions is not al-
ways defined (SAR and ACC are exceptions). In these cases, the Special Register Tables
in Section 5.3 on page 208 explain how to ensure the effects are seen by a particular
point in the instruction stream (typically involving the use of one of the ISYNC, RSYNC,
ESYNC, or DSYNC instructions). An XSR.* followed by an RSR.* to the same register
should be separated with an ESYNC to guarantee the value written is read back. An
XSR.PS followed by RSIL also requires an ESYNC. In general, the restrictions on XSR.*
include the union of the restrictions of the corresponding RSR.* and WSR.*.
Operation
Exceptions
7.1 Formats
The following sections show the named opcode formats for instruction encodings. The
field names in these formats are used in the opcode tables in Section 7.3.1. The format
names are used throughout this document. Each chart shows both big-endian and little-
endian encodings with bits numbered appropriately for that endianness. The vertical
bars in the formats indicate the points at which the opcode is separated, reversed in or-
der, and reassembled to arrive at the opposite endianness format.
7.1.1 RRR
0 3 4 7 8 11 12 15 16 19 20 23
4 4 4 4 4 4
23 20 19 16 15 12 11 8 7 4 3 0
4 4 4 4 4 4
7.1.2 RRI4
0 3 4 7 8 11 12 15 16 19 20 23
4 4 4 4 4 4
23 20 19 16 15 12 11 8 7 4 3 0
4 4 4 4 4 4
7.1.3 RRI8
0 3 4 7 8 11 12 15 16 23
4 4 4 4 8
23 16 15 12 11 8 7 4 3 0
8 4 4 4 4
7.1.4 RI16
0 3 4 7 8 23
4 4 16
23 8 7 4 3 0
16 4 4
7.1.5 RSR
0 3 4 7 8 15 16 19 20 23
4 4 8 4 4
23 20 19 16 15 7 4 3 0
4 4 8 4 4
7.1.6 CALL
0 3 4 5 6 23
4 2 18
23 6 5 4 3 0
18 2 4
7.1.7 CALLX
0 3 4 5 6 7 8 11 12 15 16 19 20 23
4 2 2 4 4 4 4
23 20 19 16 15 12 11 8 7 4 3 0
4 4 4 4 2 2 4
7.1.8 BRI8
0 3 4 5 6 7 8 11 12 15 16 23
4 2 2 4 4 8
23 16 15 12 11 8 7 4 3 0
8 4 4 2 2 4
7.1.9 BRI12
0 3 4 5 6 7 8 11 12 23
4 2 2 4 12
23 12 11 8 7 4 3 0
12 4 2 2 4
7.1.10 RRRN
0 3 4 7 8 11 12 15
4 4 4 4
15 12 11 8 7 4 3 0
4 4 4 4
7.1.11 RI7
0 3 4 7 8 11 12 15
4 4 4 4
15 12 11 8 7 6 4 3 0
4 4 4 4
7.1.12 RI6
0 3 4 7 8 11 12 15
4 4 4 4
15 12 11 8 7 6 5 4 3 0
4 4 4 4
01xx MAC16D — Table 7–221 CALLN — Table 7–232 SI — Table 7–233 B — Table 7–238
10xx L32I.NN — page 380 S32I.NN — page 512 ADD.NN — page 249 ADDI.NN — page 252
Table 7–193. QRST (from Table 7–192) Formats RRR, CALLX, and RSR (t, s, r, op2 vary)
op1 xx00 xx01 xx10 xx11
00xx RST0 — Table 7–194 RST1 — Table 7–205 RST2 — Table 7–209 RST3 — Table 7–210
01xx EXTUI — page 344 CUST0 — Section 7.3.2 CUST1 — Section 7.3.2
10xx LSCXP — Table 7–211 LSC4 — Table 7–212 FP0F — Table 7–213 FP1F — Table 7–215
Table 7–194. RST0 (from Table 7–193) Formats RRR and CALLX (t, s, r vary)
op2 xx00 xx01 xx10 xx11
00xx ST0 — Table 7–195 AND — page 259 OR — page 466 XOR — page 564
01xx ST1 — Table 7–202 TLB — Table 7–203 RT0 — Table 7–204 reserved
10xx ADD — page 248 ADDX2 — page 254 ADDX4 — page 255 ADDX8 — page 256
11xx SUB — page 542 SUBX2 — page 544 SUBX4 — page 545 SUBX8 — page 546
Table 7–195. ST0 (from Table 7–194 Formats RRR and CALLX (t, s vary)
r xx00 xx01 xx10 xx11
00xx SNM0 — Table 7–196 MOVSPW — page 427 SYNC — Table 7–199 RFEIX — Table 7–200
01xx BREAKX — page 293 SYSCALLX — page 547 (s,t=0) RSILX — page 498 WAITIX — page 556 (t=0)
10xx ANY4P — page 262 ALL4P — page 257 ANY8P — page 263 ALL8P — page 258
Table 7–196. SNM0 (from Table 7–195) Format CALLX (n, s vary)
m 00 01 10 11
ILL — page 358 (s,n=0) reserved JR — Table 7–197 CALLX — Table 7–198
11xx MEMW — page 409 (s=0) EXTW — page 345 (s=0) reserved reserved
Table 7–201. RFET (from Table 7–200) Format RRR (no bits vary)
s xx00 xx01 xx10 xx11
00xx RFEX — page 487 RFUEX — page 491 RFDEX — page 485 reserved
Table 7–202. ST1 (from Table 7–194) Format RRR (t, s vary)
r xx00 xx01 xx10 xx11
00xx SSR — page 539 (t=0) SSL — page 538 (t=0) SSA8L — page 532 (t=0) SSA8B — page 531 (t=0)
01xx SSAI — page 533 (t=0) reserved RER — page 477 WER — page 558
Table 7–203. TLB (from Table 7–194) Format RRR (t, s vary)
r xx00 xx01 xx10 xx11
00xx reserved reserved reserved RITLB0 — page 494
01xx IITLB — page 355 (t=0) PITLB — page 470 WITLB — page 560 RITLB1 — page 495
11xx IDTLB — page 348 (t=0) PDTLB — page 469 WDTLB — page 557 RDTLB1 — page 474
Table 7–204. RT0 (from Table 7–194) Format RRR (t, r vary)
s xx00 xx01 xx10 xx11
00xx NEG — page 457 ABS — page 246 reserved reserved
Table 7–205. RST1 (from Table 7–193) Format RRR (t, s, r vary)
op2 xx00 xx01 xx10 xx11
00xx SLLI — page 525 SRAI — page 527
01xx SRLI — page 530 reserved XSR — page 566 ACCER — Table 7–206
10xx SRC — page 528 SRL — page 529 (s=0) SLL — page 524 (t=0) SRA — page 526 (s=0)
11xx MUL16U — page 437 MUL16S — page 436 reserved IMP — Table 7–207
Table 7–206. ACCER (from Table 7–205) Format RRR (t, s vary)
op2 xx00 xx01 xx10 xx11
00xx RER — page 477
01xx
10xx WER — page 558
11xx
Table 7–207. IMP (from Table 7–205) Format RRR (t, s vary) (Section 7.3.3)
r xx00 xx01 xx10 xx11
00xx LICT — page 388 SICT — page 519 LICW — page 390 SICW — page 521
Table 7–209. RST2 (from Table 7–193) Format RRR (t, s, r vary)
op2 xx00 xx01 xx10 xx11
00xx ANDBP — page 260 ANDBCP — page 261 ORBP — page 467 ORBCP — page 468
10xx MULLI — page 450 reserved MULUHI — page 456 MULSHI — page 455
11xx QUOUI — page 472 QUOSI — page 471 REMUI — page 476 REMSI — page 475
Table 7–210. RST3 (from Table 7–193) Formats RRR and RSR (t, s, r vary)
op2 xx00 xx01 xx10 xx11
00xx RSR — page 500 WSR — page 561 SEXTU — page 518 CLAMPSU — page 312
01xx MINU — page 410 MAXU — page 407 MINUU — page 411 MAXUU — page 408
10xx MOVEQZ — page 415 MOVNEZ — page 425 MOVLTZ — page 423 MOVGEZ — page 419
11xx MOVFP — page 417 MOVTP — page 428 RUR — page 503 WUR — page 563
Table 7–211. LSCX (from Table 7–193) Format RRR (t, s, r vary)
op2 xx00 xx01 xx10 xx11
00xx LSXF — page 402 LSXUF — page 404 reserved reserved
Table 7–212. LSC4 (from Table 7–193) Format RRI4 (t, s, r vary)
op2 xx00 xx01 xx10 xx11
00xx L32E — page 376 reserved reserved reserved
Table 7–213. FP0 (from Table 7–193) Format RRR (t, s, r vary)
op2 xx00 xx01 xx10 xx11
00xx ADD.SF — page 250 SUB.SF — page 543 MUL.SF — page 435 reserved
10xx ROUND.SF — page 497 TRUNC.SF — page 548 FLOOR.SF — page 347 CEIL.SF — page 311
11xx FLOAT.SF — page 346 UFLOAT.SF — page 550 UTRUNC.SF — page 555 FP1OPF — Table 7–214
Table 7–214. FP1OP (from Table 7–213) Format RRR (s, r vary)
t xx00 xx01 xx10 xx11
00xx MOV.SF — page 414 ABS.SF — page 247 reserved reserved
01xx RFRF — page 490 WFRF — page 559 NEG.SF — page 458 reserved
Table 7–215. FP1 (from Table 7–193) Format RRR (t, s, r vary)
op2 xx00 xx01 xx10 xx11
00xx reserved UN.SF — page 554 OEQ.SF — page 463 UEQ.SF — page 549
01xx OLT.SF — page 465 ULT.SF — page 552 OLE.SF — page 464 ULE.SF — page 551
10xx MOVEQZ.SF — page 416 MOVNEZ.SF — page 426 MOVLTZ.SF — page 424 MOVGEZ.SF — page 420
Table 7–216. LSAI (from Table 7–192) Formats RRI8 and RRI4 (t, s, imm8 vary)
r xx00 xx01 xx10 xx11
00xx L8UI — page 369 L16UI — page 372 L32I — page 378 reserved
01xx S8I — page 504 S16I — page 505 S32I — page 510 CACHEC — Table 7–217
10xx reserved L16SI — page 370 MOVI — page 421 L32AIY — page 374
11xx ADDI — page 251 ADDMI — page 253 S32C1IY — page 506 S32RIY — page 514
Table 7–217. CACHE (from Table 7–216) Formats RRI8 and RRI4 (s, imm8 vary)
t xx00 xx01 xx10 xx11
00xx DPFRC — page 331 DPFWC — page 335 DPFROC — page 333 DPFWOC — page 337
01xx DHWBC — page 317 DHWBIC — page 319 DHIC — page 313 DIIC — page 321
11xx IPFC — page 360 ICEC — Table 7–219 IHIC — page 349 IIIC — page 353
Table 7–218. DCE (from Table 7–217) Format RRI4 (s, imm4 vary)
op1 xx00 xx01 xx10 xx11
00xx DPFLL — page 329 reserved DHUL — page 315 DIUL — page 323
Table 7–219. ICE (from Table 7–217) Format RRI4 (s, imm4 vary)
op1 xx00 xx01 xx10 xx11
00xx IPFLL — page 362 reserved IHUL — page 351 IIUL — page 356
Table 7–220. LSCI (from Table 7–192) Format RRI8 (t, s, imm8 vary)
r xx00 xx01 xx10 xx11
00xx LSIF — page 398 reserved reserved reserved
Table 7–221. MAC16 (from Table 7–192) Format RRR (t, s, r, op1 vary)
op2 xx00 xx01 xx10 xx11
00xx MACID — Table 7–222 MACCD — Table 7–226 MACDD — Table 7–224 MACAD — Table 7–225
01xx MACIA — Table 7–223 MACCA — Table 7–227 MACDA — Table 7–228 MACAA — Table 7–229
Table 7–222. MACID (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx reserved reserved reserved reserved
Table 7–223. MACIA (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx reserved reserved reserved reserved
Table 7–224. MACDD (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx reserved reserved reserved reserved
01xx MUL.DD.LL — page 434 MUL.DD.HL — page 434 MUL.DD.LH — page 434 MUL.DD.HH — page 434
10xx MULA.DD.LL — page 445 MULA.DD.HL — page 445 MULA.DD.LH — page 445 MULA.DD.HH — page 445
11xx MULS.DD.LL — page 454 MULS.DD.HL — page 454 MULS.DD.LH — page 454 MULS.DD.HH — page 454
Table 7–225. MACAD (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx reserved reserved reserved reserved
01xx MUL.AD.LL — page 432 MUL.AD.HL — page 432 MUL.AD.LH — page 432 MUL.AD.HH — page 432
10xx MULA.AD.LL — page 439 MULA.AD.HL — page 439 MULA.AD.LH — page 439 MULA.AD.HH — page 439
11xx MULS.AD.LL — page 452 MULS.AD.HL — page 452 MULS.AD.LH — page 452 MULS.AD.HH — page 452
Table 7–226. MACCD (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx reserved reserved reserved reserved
Table 7–227. MACCA (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx reserved reserved reserved reserved
Table 7–228. MACDA (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx reserved reserved reserved reserved
01xx MUL.DA.LL — page 433 MUL.DA.HL — page 433 MUL.DA.LH — page 433 MUL.DA.HH — page 433
10xx MULA.DA.LL — page 440 MULA.DA.HL — page 440 MULA.DA.LH — page 440 MULA.DA.HH — page 440
11xx MULS.DA.LL — page 453 MULS.DA.HL — page 453 MULS.DA.LH — page 453 MULS.DA.HH — page 453
Table 7–229. MACAA (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx UMUL.AA.LL — page 553 UMUL.AA.HL — page 553 UMUL.AA.LH — page 553 UMUL.AA.HH — page 553
01xx MUL.AA.LL — page 431 MUL.AA.HL — page 431 MUL.AA.LH — page 431 MUL.AA.HH — page 431
10xx MULA.AA.LL — page 438 MULA.AA.HL — page 438 MULA.AA.LH — page 438 MULA.AA.HH — page 438
11xx MULS.AA.LL — page 451 MULS.AA.HL — page 451 MULS.AA.LH — page 451 MULS.AA.HH — page 451
Table 7–230. MACI (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx LDINC — page 387 (t=0) reserved reserved reserved
Table 7–231. MACC (from Table 7–221) Format RRR (t, s, r vary)
op1 xx00 xx01 xx10 xx11
00xx LDDEC — page 386 (t=0) reserved reserved reserved
Table 7–232. CALLN (from Table 7–192) Format CALL (offset varies)
n 00 01 10 11
CALL0 — page 297 CALL4 — page 298 CALL8 — page 300 CALL12 — page 302
Table 7–233. SI (from Table 7–192) Formats CALL, BRI8 and BRI12(offset varies)
n 00 01 10 11
J — page 366 BZ — Table 7–234 BI0 — Table 7–235 BI1 — Table 7–236
Table 7–234. BZ (from Table 7–233) Format BRI12 (s, imm12 vary)
m 00 01 10 11
BEQZ — page 274 BNEZ — page 290 BLTZ — page 286 BGEZ — page 281
Table 7–235. BI0 (from Table 7–233) Format BRI8 (s, r, imm8 vary)
m 00 01 10 11
BEQI — page 273 BNEI — page 289 BLTI — page 283 BGEI — page 278
Table 7–236. BI1 (from Table 7–233) Formats BRI8 and BRI12 (s, r, imm8 vary)
m 00 01 10 11
ENTRYW — page 340 B1 — Table 7–237 BLTUI — page 285 BGEUI — page 280
Table 7–237. B1 (from Table 7–236) Format BRI8 (s, imm8 vary)
r xx00 xx01 xx10 xx11
00xx BFP — page 276 BTP — page 296 reserved reserved
10xx LOOP — page 392 LOOPNEZ — page 396 LOOPGTZ — page 394 reserved
Table 7–238. B (from Table 7–192) Format RRI8 (t, s, imm8 vary)
r xx00 xx01 xx10 xx11
00xx BNONE — page 292 BEQ — page 272 BLT — page 282 BLTU — page 284
01xx BALL — page 264 BBC — page 266 BBCI — page 267
10xx BANY — page 265 BNE — page 288 BGE — page 277 BGEU — page 279
11xx BNALL — page 287 BBS — page 269 BBSI — page 270
Table 7–239. ST2 (from Table 7–192) Formats RI7 and RI6 (s, r vary)
t xx00 xx01 xx10 xx11
00xx MOVI.NN — page 422
01xx
10xx BEQZ.NN — page 275
Table 7–240. ST3 (from Table 7–192) Format RRRN (t, s vary)
r xx00 xx01 xx10 xx11
00xx MOV.NN — page 413 reserved reserved reserved
Table 7–241. S3 (from Table 7–240) Format RRRN (no fields vary)
t xx00 xx01 xx10 xx11
00xx RET.NN — page 479 RETW.NWN — page 482 BREAK.NN — page 295 NOP.NN — page 460
CUST0 and CUST1 opcode encodings shown in Table 7–193 are permanently reserved
for designer-defined opcodes. In the future, customers who use these spaces exclusive-
ly for their own designer-defined opcodes will be able to add new Tensilica-defined op-
tions without changing their opcodes or binary executables.
The encodings for the r field sub-opcodes of the IMP family of opcodes, which are im-
plementation-specific Cache-Option opcodes, are shown in Table 7–207. The IMP fami-
ly of opcodes is reserved for these implementation-specific instructions. For a descrip-
tion of these instructions, see Chapter 6.
This chapter describes Tensilica’s software tool support of the Xtensa ISA and the con-
ventions used by software.
These two ABIs share much in common and diverge mostly in the areas of stack frame
layout and general-purpose register usage. The basic data type sizes and alignments
are identical, and the argument passing and return value conventions are nearly the
same.
Table 8–242 shows the general-purpose register usage for the windowed register ABI.
Registers a0 and a1 are reserved for the return address and stack pointer, respectively.
They must always contain those values, because they are used for stack unwinding in
debuggers and exception handling. Incoming arguments are stored in registers a2
through a7. The location of outgoing arguments depends on the window size.
The stack frame layout for the windowed register ABI is shown in Figure 8–53. The stack
grows down, from high to low addresses. The stack pointer (SP) must be aligned to 16-
byte boundaries. A stack-frame pointer (FP) may (but is not required to) be allocated in
register a7. For example, it may be needed when the routine contains a call to alloca.
If a frame pointer is used, its value is equal to the original stack pointer (immediately af-
ter entry to the function), before any alloca space allocation.
The register-spill overflow area is equal to N–4 words, where N can be 4, 8, or 12 as de-
termined by the largest CALLN or CALLXN in the function. For details, see “Windowed
Procedure-Call Protocol” on page 187.
The stack pointer SP should only be modified by ENTRY and MOVSP instructions. If some
other instruction modifies SP, any values in the register-spill area will not be moved. An
exception to this rule is when setting the initial stack pointer for a new stack, where the
register-spill area is guaranteed to be empty and where MOVSP cannot safely be used.
SP
Register-Spill Area
(4 words)
Register-Spill Overflow
(0 to 8 words)
Local Variables
alloca Space
SP
Register-Spill Area
Low (4 words)
Memory
Table 8–243 shows the general-purpose register usage for the CALL0 ABI. The stack
pointer in register a1 and registers a12–a15 are callee-saved, but the rest of the regis-
ters are caller-saved. Register a0 holds the return address upon entry to a function, but
unlike the windowed register ABI, it is not reserved for this purpose and may hold other
values after the return address has been saved. Function arguments are passed in reg-
isters a2 through a7.
The stack frame layout for the CALL0 ABI is the same as for the windowed register ABI,
except without the reserved register-spill areas. (Registers will need to be saved to the
stack, but there is no convention for where in the frame to place that storage.) Like the
windowed register ABI, the stack grows down and the stack pointer must be aligned to
16-byte boundaries. The optional stack-frame pointer is also used in the same way, but
it is placed in register a15 with the CALL0 ABI.
Table 8–244 shows the data-type sizes and their alignment. The maximum alignment for
user-defined types is 16 bytes.
Arguments are passed in both registers and memory. In general, the first six words of ar-
guments go in the AR register file, and any remaining arguments go on the stack. For a
CALLN instruction (where N is 0 for the CALL0 ABI, or where N is 4, 8, or 12 for the win-
dowed register ABI) the caller places the first arguments in registers AR[N+2] through
AR[N+7]. (Note that this implies that CALL12 can only be used when there are two
words of arguments or less; only AR[N+2] and AR[N+3] can be used when N=12.) The
callee receives these arguments in AR[2] through AR[7].
If there are more than six words of arguments, the additional arguments are stored on
the stack beginning at the caller’s stack pointer and at increasingly positive offsets from
the stack pointer. That is, the caller stores the seventh argument word (after the first six
words in registers) at [sp + 0], the eighth word at [sp + 4], and so on. The callee can ac-
cess these arguments in memory beginning at [sp + FRAMESIZE], where FRAMESIZE
is the size of the callee’s stack frame.
All arguments consist of an integral number of 4-byte words. Thus, the minimum argu-
ment size is one word. Integer values smaller than a word (that is, char and short) are
stored in the least significant portion of the argument word, with the upper bits set to
zero for unsigned values or sign-extended for signed values.
When a value larger than 4 bytes is passed in registers, the ordering of the words is the
same as the byte ordering. With little endian ordering, the least significant word goes in
the first register. With big endian ordering, the most significant word comes first.
Each argument must be passed entirely in registers or entirely on the stack; an argu-
ment cannot be split with some words in registers and the remainder on the stack. If an
argument does not fit entirely in the remaining unused registers, it is passed on the
stack and those registers remain unused.
Arguments must be properly aligned. If the type of the argument requires 4-byte or less
alignment, this requirement has no effect; all arguments have at least 4-byte alignment
anyway. If an argument requires 8-byte alignment and is passed in registers, the first
word must be in an even-numbered register. This sometimes requires leaving an odd-
numbered register unused. Similarly, if an argument requires 16-byte alignment and is
passed in registers, the first word must be in the first argument register (AR[N+2]); oth-
erwise, it is passed on the stack. If an argument is passed in memory, the memory loca-
tion must have the alignment required by the argument type.
Structures and other aggregate types are passed by value. The preceding rules apply to
structures in the same way as scalars. If a structure is small enough to be passed in reg-
isters, the words of the structure are placed in registers according to their order in mem-
ory. A variable-sized structure is always passed on the stack and any remaining argu-
ment registers go unused. If the size of a structure is not an integral number of words,
padding is inserted at one end of the structure. For structures smaller than a word, the
padding is always in the most-significant part of the word. A structure larger than a word
is padded in the last bytes of the last argument word, so that the structure is contiguous
when the registers are stored to consecutive words of memory.
Values of user-defined TIE types cannot be passed as arguments. (That is, they cannot
be arguments of procedure calls; they may still be used as arguments of certain intrinsic
functions and macros that do not correspond to real procedure calls.)
Values of four words or less are returned in registers. The callee places the return value
in registers beginning with AR[2] and continuing up to (and including) AR[5], depending
on the size of the value. For a CALLN instruction (where N is 0 for the CALL0 ABI, or
where N is 4, 8, or 12 for the windowed register ABI) the caller receives these values in
registers AR[N+2] through AR[N+5]. (Note that, as with arguments, this limits the use of
CALL12 instructions. A CALL12 instruction can only be used when the return value is
two words or less; only AR[N+2] and AR[N+3] can be used when N=12.)
Return values smaller than a word are stored in the least-significant part of AR[2], with
the upper bits set to zero for unsigned values or sign-extended for signed values.
Values larger than four words are returned by invisible reference. The caller passes a
pointer as an invisible first argument and the callee stores the return value in the memo-
ry referenced by the pointer. The memory allocated by the caller must have the appropri-
ate size and alignment for the return value.
Even though values of user-defined types cannot be passed as arguments, they are al-
lowed as return values. If a procedure returns such a value, it is stored in the first regis-
ter of the register file associated with that user-defined type.
Variable argument lists are handled in the same way as other arguments. There is no
change to the calling convention for functions with variable argument lists.
In addition to the general-purpose AR register file, Xtensa processors may contain a va-
riety of other register files, special registers, and TIE states (which may be mapped to
user registers). The conventions for saving and restoring these registers across function
calls vary. Some are caller-saved, which means that a function does not need to save
those registers to the stack before modifying them, because it can assume that the call-
er has already saved them. For callee-saved registers, the responsibility is reversed and
the callee function must save the original values of the registers that it modifies. Some
other registers are global — any changes to their values persist across function calls —
and for some others, the usage conventions are not specified.
Unless otherwise specified, the default convention is that all registers are caller-saved.
The exceptions are:
When using the CALL0 ABI, several of the AR registers are callee-saved (see
Table 8–243 on page 589).
No convention is specified for the use of TIE states — the programmer can decide
how to use TIE states. If you are using TIE states together with cooperative (non-
preemptive) context switching, be careful that your use of TIE states matches the
assumptions of the operating system. The operating system may assume that TIE
states need not be saved when a context switch primitive is invoked; that is, it may
assume that TIE states are caller-saved.
The following special registers and user registers are global: LITBASE,
THREADPTR, and FCR. These registers are used for special purposes and typically
keep the same values across function calls.
As a consequence of the LOOP special registers (LBEG, LEND, and LCOUNT) being call-
er-saved, the LOOP instructions should not be used for loops containing function calls.
Doing so would require saving and restoring the LOOP registers around the call, which
would overwhelm the advantage of the LOOP instructions.
Some languages (including C with a GCC extension) allow nested functions. A function
A nested inside another function B must be able to access the local variables of both A
and B. Implementing this requires that when B calls A, it must somehow pass to A infor-
mation to allow locating B’s stack frame. Some implementations of nested functions use
a data structure known as a “display” for this purpose. GCC uses the simpler alternative
of passing a “static chain” as an invisible argument to the nested function. The static
chain is simply a pointer to the caller’s stack frame. This approach is preferable to using
a display as long as functions are not deeply nested.
Because nested functions may be called indirectly through pointers, the caller may not
be able to detect when it is calling a nested function. Therefore, the invisible static chain
argument must be passed in a reserved location where it does not interfere with the oth-
er arguments. For the CALL0 ABI, the static chain is passed in register a8. For the win-
dowed register ABI, there are no registers available to hold the static chain, and the
stack locations at positive offsets from SP are all used for passing normal arguments.
The solution is to store the static chain on the stack at a negative offset from the caller’s
stack pointer. The first four words below SP are reserved as a register save area, so the
static chain is passed in the fifth word below SP. That is, the caller places the static chain
in memory at [SP–20], and the callee reads it from [SP + FRAMESIZE – 20] where
FRAMESIZE is the size of the callee’s stack frame.
When the address of a nested function is stored into a pointer, the compiler actually
emits code to dynamically create a small piece of executable code known as a “trampo-
line”, and the pointer is set to reference the trampoline. When an indirect call is made
through the pointer, the trampoline code sets the value of the static chain and then
transfers control to the nested function. The trampoline code is allocated on the stack —
this implies that it must be possible to execute code stored in the region of memory hold-
ing the stack. For example, when using nested functions that have their addresses
taken, the stack cannot be located in a separate data memory.
This positioning of the static chain for the windowed register ABI has an implication for
exception handlers. If an exception occurs after the static chain has been written but
before the ENTRY instruction in the callee, the contents of memory from [SP–20] through
[SP–1] must be preserved by the handler. Because of the register overflow save area,
the contents of memory from [SP–16] to [SP–1] must be preserved regardless, so the
presence of the static chain simply adds one more word of memory that must be pre-
served.
If the initial procedure executed by the thread does not store any data in the initial stack
frame, and if all the call instructions in the initial procedure use the CALL0 ABI or a win-
dow size of four, then the initial stack frame can be empty and requires no setup. The
default C runtime initialization code meets these conditions, so that the stack can be ini-
tialized simply by setting the stack pointer to the high end of the reserved memory.
If the thread begins with some other code that may execute a CALL8 or CALL12 instruc-
tion or that requires storage on the stack, the initial frame must be constructed before
jumping to the initial procedure. The size of the initial frame is equal to the sum of the lo-
cal storage requirements and the extra save area. The stack pointer should be initialized
to the high end of the reserved memory less the size of the initial frame. Furthermore,
assuming the thread begins executing with only the current register window loaded, the
base save area at (sp – 16) must be initialized as if it had been written by a window
overflow. Specifically, the stack pointer value stored at (sp – 12) must be set to the high
end of the reserved stack area plus 16 bytes. This allows subsequent window overflows
to locate the extra save area in the initial stack frame.
The return address register (a0) for the first procedure on the stack must be explicitly
set to zero. This is used to mark the top of the stack for use by stack unwinding code.
The following code is an example of how the stack may be initialized to allow CALL8 (but
not CALL12) in the initial thread:
movi a0, 0
movi sp, stackbase + stacksize - 16
addi a4, sp, 32 // point 16 past extra save area
s32e a4, sp, -12 // access to extra save area
call8 firstfunction
The following code is an example of how the stack may be initialized to allow CALL12
and “loc” bytes of locals and parameters in the initial thread (loc is a multiple of 16):
movi a0, 0
movi sp, stackbase + stacksize - loc - 32
addi a4, sp, loc + 48 // point 16 past extra save area
s32e a4, sp, -12 // access to extra save area
call12 firstfunction
The break (24-bit) instruction has two immediate 4-bit operands, and the break.n
(narrow, 16-bit) instruction has one immediate 4-bit operand. These operands (informal-
ly called “break codes” in this section) can be used to convey relevant information to the
debug exception handler. Their exact meaning is a matter of convention. However,
some of the tools and software (debuggers, OS ports, and so forth) used with Xtensa
cores necessarily make use of the break instructions, so some conventions had to be
established. The conventions that have been adopted are described in this section.
Half of the break codes are reserved for use by software provided by Tensilica and its
partners, leaving the remaining half for “user-defined” purposes. Note that making use of
user-defined break codes usually requires special OS or monitor support, or at least
having control of the debug exception handler (or of the external OCD software when
OCD mode is enabled). Break code allocations are described in Table 8–245.
Break codes have been allocated for a number of planted breakpoints (breakpoints that
replace some arbitrary pre-existing instruction, usually under control of a debugger or
related software, and usually temporarily) and coded breakpoints (breakpoints explicitly
coded in the assembly source).
Planted breakpoints have a narrow (16-bit) and a wide (24-bit) version. Because 24-bit
instructions exist in all Xtensa processors, instructions 24-bits or wider may be replaced
with a 24-bit BREAK instruction. With the density option, the narrow version (BREAK.N)
must generally be used when replacing an existing narrow instruction. Otherwise a wide
break instruction would overwrite two sequential instructions, the second of which could
be the (now corrupted) target of a branch. Note that without the density option, only the
wide form of the break instruction can be used because the narrow version does not
exist.
A number of coded breakpoints have been defined to provide a means of making vari-
ous exceptions (that is, illegal instructions, load/store errors, and so forth) visible to the
debugger, which does not otherwise see these types of exceptions through the debug
exception vector. These breakpoints necessarily require support from the OS (or RTOS).
They are typically invoked by the OS for those exceptions and interrupts that neither the
OS nor the application handles, thus providing an opportunity for a debugger (if one is
active) to catch the condition. If the OS has its own mechanism for handling unregis-
tered exceptions and interrupts, the relevant coded breakpoint is normally invoked be-
fore this mechanism (there often is no well-defined “after”). Thus, it is very important that
the debug exception handler treat the coded breakpoint as a no-op if no debugger is ac-
tive, to let the OS follow its default course of action. By convention, any break 1,x in-
struction must be skipped and ignored if no debugger is active. If the debug exception
handler (or OCD software if OCD mode is enabled) detects the presence of a debugger,
it will transfer control to the debugger. Otherwise, it must immediately resume execution
at the instruction following the break (which requires incrementing EPC[DEBUGLEVEL]
by two for break.n or by three for break), in effect making the break a no-op.
Another essential requirement for break 1,0 through break 1,5 is that the OS in-
voke these coded breakpoints in exactly the same context (core state) as when the ex-
ception was entered (except, necessarily, for PC and EXCSAVEn). This allows the de-
bugger to know the exact state of the core at the time the exception (or interrupt)
occurred, without requiring any OS dependency. For example, when detecting an un-
handled level-1 user exception, the OS has typically saved (in EXCSAVE1 and possibly
memory) and modified only a few address registers; these registers must all be restored
prior to executing the break 1,1 instruction. The debug exception handler can then ex-
amine all registers as they were when the user exception occurred, including examining
EXCCAUSE to determine which exception occurred, and so forth. Similarly, following a
break 1,2 it can resolve which interrupt occurred using EPS[DEBUGLEVEL].INTLEV-
EL.
Coded breakpoints can always use the wide (24-bit) form of the break instruction, so
they were not allocated from the limited number of narrow break instructions.
The details of system calls are inherently dependent on the operating system, but there
are a few conventions that apply to all systems. The SYSCALL instruction has no imme-
diate operands, so the system call parameters are passed in registers. Each operating
system is free to define its own register usage for system call parameters, with the ex-
ception that the system call request code must always be in register a2.
The system call request code 0 must be defined for all systems that use the windowed
register ABI. (If the Xtensa processor configuration uses the CALL0 ABI, system call 0
need not be implemented.) The purpose of system call 0 is to flush the register windows
to the stack. It is often useful to have a portable and reasonably efficient means of flush-
ing register windows, such as when walking up the stack to find an exception handler.
This system call provides an easy way to flush the register windows on all systems.
In general, each operating system can define its own conventions for which general-pur-
pose registers may be modified by a system call, including which registers will hold any
return values or error codes. For system call 0 in particular, no return value is expected
and each operating system must guarantee that no general-purpose registers other than
a2 will be modified. The value in a2 upon return from system call 0 depends on the oper-
ating system.
Machine code generated by the assembler may include opcode replacements for certain
assembler opcodes. For example:
The assembler can turn ADD into ADD.N, or ADDI into ADDI.N, and so forth when
the density option is enabled.
The assembler substitutes a different instruction when an operand is out of range.
For example, it turns MOVI into L32R when the immediate is outside the range
-2048 to 2047.
By default, the assembler handles branches that won’t reach. For example, writing:
These transformations can be disabled by prefixing the instruction name with an under-
score (for example,_ADD) and with pseudo-ops. The assembler directives.begin and
.end with no-transform can also be used to enable and disable these transforma-
tions. See the GNU Assembler User’s Guide for more detail.
Table 8–246 specifies the preferred instruction idioms for common operations. These
idioms are specified using only core instructions; in some cases substituting density
instructions would be appropriate.
With the MAC16 Option, a portion of a real FIR filter might be:
input[next] = sample;// put sample into history array
acc = 0x4000; // for rounding
for (i = 0; i < n; i += 1) {
acc += input[i > next ? next-i+n : next-i] * coeff[i];
}
output[next] = acc >> 15;
next = next == N-1 ? 0 : next+1;
To simplify the coding, change the preceding to store data in the input array backward
so that the array references are all increments instead of decrements. Now convert it
into two loops to avoid the circular addressing:
input[next] = in;
acc = 0x4000;
j = 0;
for (i = next; i < N; i += 1, j += 1) {
acc += input[i] * coeff[j];
}
for (i = 0; i < next; i += 1, j += 1) {
acc += input[i] * coeff[j];
}
next = next == 0 ? N-1 : next-1;
and then implement the loops with two calls to an assembler subroutine:
mac16_dot (N - next, &input[next], &coeff[0]);
mac16_dot (next, &input[0], &coeff[N - next]);
// Exports
.global mac16_set_acc
.global mac16_acc
.global mac16_dot
#endif
#if __XTENSA_EB__
# define MULA00 mula.dd.hh
# define MULA22 mula.dd.ll
# define MULA02 mula.dd.hl
# define MULA20 mula.dd.lh
# define MULA00L mula.dd.hh.ldinc
# define MULA22L mula.dd.ll.ldinc
# define MULA02L mula.dd.hl.ldinc
# define MULA20L mula.dd.lh.ldinc
# define BBCI(_r,_b,_l) bbci _r, 31-(_b), _l
# define BBSI(_r,_b,_l) bbsi _r, 31-(_b), _l
#endif
#include <machine/specreg.h>
.text
BBCI(a3, 1, .diffwordalign)
// a[0] is misaligned, b[0] is aligned
ldincm0, a3 // a[0]
addi a3, a3, -2// undo overincrement, leave *a word-aligned
ldincm2, a4 // b[0]
addi a4, a4, -2// undo overincrement, leave *b misaligned
MULA20m0, m2 // add product of first values
addi a2, a2, -1// finished one iteration
.diffwordalign: // a[0] is now aligned, b[0] is misaligned
srli a5, a2, 2 // will do 4 MACs per inner loop iteration
ldincm3, a4 // m3 = b[0]:b[-1]
beqz a5, .diffmod4check// not even wind-up or wind-down
addi a5, a5, -1// (n/4)-1 inner loop iterations
// (1 iteration done in wind-up/wind-down)
// wind up
ldincm0, a3 // m0 = a[1]:a[0]
ldincm2, a4 // m2 = b[2]:b[1]
MULA02Lm1, a3, m0, m3// m1 = a[3]:a[2]; acc += a[0] * b[0]
MULA20Lm3, a4, m0, m2// m3 = b[4]:b[3]; acc += a[1] * b[1]
loopneza5, .diffloopend
.diffloop:// for i = 4; i < N-3; i += 4
MULA02Lm0, a3, m1, m2// m0 = a[i+1]:a[i+0]; acc += a[i-4+2]*b[i-
4+2]
MULA20Lm2, a4, m1, m3// m2 = b[i+2]:b[i+1]; acc += a[i-4+3]*b[i-
4+3]
MULA02Lm1, a3, m0, m3// m1 = a[i+3]:a[i+2]; acc += a[i+0]*b[i+0]
MULA20Lm3, a4, m0, m2// m3 = b[i+4]:b[i+3]; acc += a[i+1]*b[i+1]
.diffloopend:
// wind down
MULA02m1, m2 // acc += a[i+2] * b[i+2]
MULA20m1, m3 // acc += a[i+3] * b[i+3]
.diffmod4check:
BBCI(a2, 1, .diffmod2check)
// count is 2 mod 4
ldincm0, a3 // m0 = a[i+5]:a[i+4]
MULA02m0, m3 // acc += a[i+4] * b[i+4]
ldincm3, a4 // m3 = b[i+6]:b[i+5]
MULA20m0, m3 // acc += a[i+5] * b[i+5]
.diffmod2check:
BBCI(a2, 0, .diffret)
// count is 1 mod 2
ldincm0, a3 // m0 = a[i+7]:a[i+6]
MULA02m0, m3 // acc += a[i+6] * b[i+6]
.diffret:
retw
8.4 Performance
This book describes the Xtensa Instruction Set Architecture (ISA) but is not the refer-
ence for performance. The ISA is defined independently of its various implementations,
so that software that targets the ISA will run on any its implementations. The ISA in-
cludes features that are not required by some of its implementations, but which will be
important to include in software written today if it is to work on future implementations
(for example, using MEMW, EXTW, and EXCW). While correct software must adhere to the
ISA and not to the specifics of any of its implementations, it is sometimes important to
know the details of an implementation for performance reasons, such as scheduling in-
structions to avoid pipeline delays. This chapter provides an overview of performance
modeling.
It is important to have a model of processor performance for both code generation and
simulation. However, the interactions of multiple instructions in a processor pipeline can
be complex. It is common to simplify and describe pipeline and cache performance sep-
arately even though they may interact, because the information is used in different stag-
es of compilation or coding. We adopt this approach, and then separately describe some
of the interactions. It is also common to describe the pipelining of instructions with laten-
cy (the time an instruction takes to produce its result after it receives its inputs) and
throughput (the time an instruction delays other instructions independent of operand de-
pendencies) numbers, but this cannot accommodate some situations. Therefore, we
adopt a slightly more complicated, but more accurate model. This model focuses on pre-
dicting when one instruction issues relative to other instructions. An instruction issues
when all of its data inputs are available and all the necessary hardware functional units
are available for it. Issue is the point at which computation of the instruction’s results
begins.
1. This situation is called a “read after write” dependency. Other possible operand dependencies familiar to coders are “write after write” and “write after
read.”
interrupts, and memory management) the processor does not interlock. These situations
are called “hazards.” For correct operation, code generation must insert xSYNC instruc-
tions to avoid hazards by delaying the dependent instruction. The xSYNC series of in-
structions is designed to accomplish this delay in an implementation-independent man-
ner.
When an instruction is described as making one of its values available at the end of
some stage, this refers to when the computation is complete, and not necessarily the
time that the actual processor state is written. It is usual to delay the state write until at
least the point at which the instruction is committed (that is, cannot be aborted by its
own or an earlier instruction’s exception). In some implementations the state write is de-
layed still further to satisfy resource constraints. However, the delay in writing the actual
processor state is usually invisible; most processors will detect the use of an operand
that has been produced by one instruction and is being used by another even though the
processor state has not been written, and forward the required value from one pipeline
stage to the other. This operation is called bypass.
Instructions may be delayed in a pipeline for reasons other than operand dependencies.
The most common situation is for two or more instructions to require a particular piece of
the processor’s hardware (called a “functional unit”) to execute. If there are fewer copies
of the unit than instructions that need to use the unit in a given cycle, the processor must
delay some of the instructions to prevent the instructions from interfering with each oth-
er. For example, a processor may have only one read port for its data cache. If instruc-
tion IC uses this read port in its stage 4 and instruction ID uses the read port in its stage
3, then it would not be possible to issue IC in cycle 10 and ID in cycle 11, because they
would both need to use the data cache read port in cycle 14. Typically, the processor
would delay ID’s issue into the pipeline by one cycle to avoid conflict with IC.
Modern processor pipeline design tends to avoid the use of functional units in varying
pipeline stages by different instructions and to fully pipeline functional unit logic. This
means that most instructions would conflict with each other on a shared functional unit
only if they issued in the same cycle. However, there are usually still a small number of
cases in which a functional unit is used for several cycles. For example, floating-point or
integer division may iterate for several cycles in a single piece of hardware. In this case,
once a divide has started, it is not possible to start another divide until the first has left
the iterative hardware. This is illustrated in Figure 8–55.
IA A0 A1 A2 A3
bypass of X from IA to IB
IB attempted B0 B1 B2 B3
IB attempted B0 B1 B2 B3
IB issued B0 B1 B2 B3
value for X needed (1) but not available
value for X needed (1) bypassed from IA
IA issues in cycle T+0, IB issues in cycle T+0+max(3−1+1,0) = T+3
IA A0 A1 A2 A3
IB attempted B0 B1 B2 B3
IB issued B0 B1 B2 B3
Many implementations of the Xtensa processor use a 5-stage pipeline capable of exe-
cuting at most one instruction per cycle. The pipeline stages are described in
Table 8–247. The first stage, I, is partially decoupled from the next, R, and R is partially
decoupled from the last three stages, E, M, and W, which operate in lock-step. If an inter-
lock condition is detected in the R stage, then in the next cycle the instruction is retried in
R and a no-op is sent on to the E stage. If an instruction is held in R, then the word
fetched in I is captured in a buffer.
The three primary implications of the Xtensa pipeline are shown in Figure 8–56.
Instructions that depend on an ALU result can execute with no delay because their
result is available at the end of E and is needed at the beginning of E by the depen-
dent instruction.
Instructions that depend on load instruction results must issue two cycles after the
load because the load result is available at the end of its M stage and is needed at
the beginning of E by the dependent instruction. For best performance, code gener-
ation should put an independent instruction in between the load and any instruction
that uses the load result.
Finally, the branch decision occurs in E, and for taken branches must affect the I
stage of the target fetch, and so there are two fetched fall-through instructions that
are killed on taken branches.
The base processor uses 32-bit aligned fetches from the instruction cache/RAM/ROM.
Processors with instructions larger than 32 bits in size use fetches big enough to fetch at
least one instruction per cycle. If the target of a branch is an instruction that crosses a
fetch boundary, then two fetches will be required before the entire instruction is avail-
able, and so the target instruction will begin three cycles after the branch instead of two.
For best performance, code generation should align 24-bit targets of frequently taken
branches on 0 or 1 mod 4 byte boundaries, and 16-bit targets on 0, 1, or 2 mod 4 byte
boundaries.
The processor avoids overflowing its write buffer by interlocking in the R stage on stores
when the write buffer is full or might become full from stores in the E and M stages.
Cycle T+ 0 T+ 1 T+ 2 T+ 3 T+ 4 T+ 5 T+ 6 T+ 7
From0 (ALU) I R E M W
ALU to use
From1 (Load) I R E M W
Load to use
From2 I R E M W
From3 (Branch) I R E M W
Taken branch delay
From4 (killed by taken branch) I R E M
To0 I R
Refer to a specific Xtensa processor data book for detailed descriptions of processor
performance and tables of pipeline stages where operands are used and defined.
The biggest difference between the two is that where XEA2 has a bit, PS.EXCM, that
causes certain effects in the hardware that are useful on entering and leaving excep-
tions and interrupts, XEA1 has that functionality bundled into the setting of the
PS.INTLEVEL field. There is no provision for either ring protection or double exceptions
in XEA1.
The following fields of the PS register (see page 87) are different in XEA1:
There is no PS.EXCM field in XEA1
There is no PS.RING field in XEA1
PS.INTLEVEL always exists in XEA1 (added by the Exception Option) instead of
appearing with the Interrupt Option. In this case CINTLEVEL is 0 for normal opera-
tion and 1 when executing in an exception handler.
Some of the functions surrounding the fields of the PS register are also different from
later behavior (see Section 4.4.1.3). In XEA1:
CEXCM ← PS.INTLEVEL ≠ 0
CRING ← 0
CINTLEVEL ← PS.INTLEVEL
CWOE ← PS.WOE
CLOOPENABLE ← 1
In XEA1, the PS register is reset to the value 028||14, which is different from what is giv-
en in Section 3.6 for XEA2.
Instead of the semantics shown in Section 4.4.1.10, exceptions have the following se-
mantics in Xtensa Exception Architecture 1 (XEA1):
procedure Exception(cause)
EPC[1] ← PC
PS.INTLEVEL ← 1
n ← if WindowStartWindowBase+1 then 2’b01
else if WindowStartWindowBase+2 then 2’b10
else if WindowStartWindowBase+3 then 2’b11
else 2’b00
if PS.UM then
EXCCAUSE ← cause
nextPC ← UserExceptionVector
PS.UM ← 0
PS.WOE ← 0
elseif n ≠ 2’b00 then
PS.OWB ← WindowBase
PS.WOE ← 0
m ← WindowBase + (2'b00||n)
nextPC ← if WindowStartm+1 then WindowOverflow4
else if WindowStartm+2 then WindowOverflow8
else WindowOverflow12
WindowBase ← m
else
EXCCAUSE ← cause
nextPC ← KernelExceptionVector
-- note PS.WOE left unchanged
-- note PS.UM is already 0
endif
endprocedure Exception
The intent of the window checks in Xtensa Exception Architecture 1 is to allow the kernel
exception handler to use CALLX12 without taking an exception. This allows the handler
to “save” 12 registers using the windowed-register mechanism instead of using 12 loads
and 12 stores. This results in low-overhead kernel exceptions. When the window over-
flow exception is invoked instead of the requested exception, the RFWO from the handler
will attempt to re-execute the instruction that caused the original exception, and this time
the kernel exception handler will be invoked. This feature has proved difficult to use in
operating systems.
User vector mode exceptions work differently because it is usually necessary to switch
stacks when going from the program stack to the exception stack, and this involves stor-
ing all windows to the program stack.
Instead of the semantics shown in Section 4.7.1.3, window checks have the following
semantics in Xtensa Exception Architecture 1 (XEA1):
The procedure for taking an ICOUNT interrupt is different from the one given in
Section 4.7.6.8. Instead of setting PS.EXCM, it clears PS.WOE and PS.UM as shown
here:
procedure checkIcount ()
if CINTLEVEL < ICOUNTLEVEL then
if ICOUNT ≠ -1 then
ICOUNT ← ICOUNT + 1
elseif CINTLEVEL < DEBUGLEVEL then
EPC[DEBUGLEVEL] ← PC
EPS[DEBUGLEVEL] ← PS
DEBUGCAUSE ← 1
PC ← InterruptVector[DEBUGLEVEL]
PS.WOE ← 0
PS.UM ← 0
PS.INTLEVEL ← DEBUGLEVEL
endif
endif
endprocedure checkIcount
In XEA1 the BREAK and BREAK.N instructions do not affect PS.EXCM, since it does not
exist, but set PS.UM ← 0 and PS.WOE ← 0 instead.
In XEA1 the RETW and RETW.N instructions are not affected by and do not affect PS.EX-
CM, since it does not exist. In the underflow case, before setting
EPC[1] ← PC, these instructions set PS.WOE ← 0 and PS.INTLEVEL ← 1 instead.
In XEA1 the RFE instruction does not affect PS.EXCM, since it does not exist, but sets
PS.INTLEVEL ← 0 instead. In XEA1, it is used only to return from exceptions that went
to the kernel exception vector.
XEA1 supports the RFUE instruction, which is nearly identical to the RFE instruction but
sets PS.UM ← 1 and PS.WOE ← 1 in addition. A partial description is given in
Chapter 6, page 243. The following instruction entry shows the RFUE instruction that is
not fully described in Chapter 6. Note that an ESYNC instruction needs to be used be-
tween a WSR/XSR.EPC1 and an RFUE instruction.
Instruction Word
23 0
0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 0 0 0 0
24
Assembler Syntax
RFUE
Description
RFUE returns from an exception that went to the UserExceptionVector (that is, a
non-window synchronous exception or level-1 interrupt that occurred while the proces-
sor was executing with PS.UM set). It sets PS.UM back to 1, clears PS.INTLEVEL back
to 0, sets PS.WOE back to 1, and then jumps to the address in EPC[1].
Operation
if CRING ≠ 0 then
Exception (PrivilegedInstructionCause)
else
PS.UM ← 1
PS.INTLEVEL ← 0
PS.WOE ← 1
nextPC ← EPC[1]
endif
Exceptions
In XEA1 the RFWO and RFWU instructions do not affect PS.EXCM, since it does not exist,
but set PS.INTLEVEL ← 0 and PS.WOE ← 1 instead.
The exception virtual address register, EXCVADDR, does not exist in XEA1. There are no
memory management tables to refill and so it is not absolutely necessary. On other
memory exceptions, system software must decode the instruction to determine the
memory address involved if it wishes to know.
There is never a DEPC register in XEA1. Double exceptions are not generally recover-
able in XEA1 and often not detectable.
The RSIL instruction is typically used for executing a region of code at a new level:
In XEA1, the Options for Memory Protection and Translation in Section 4.6 and the cor-
responding TLB management instructions are not available. Instead, functionality similar
to the Region Protection Option described in Section 4.6.3 is available through the
cache attribute register. Table 9-249 shows the cache attribute register and its addition
as a Special Register.
The following table shows the Cache Attribute Special Register as it is implemented in
XEA1 and described as current Special Registers are described in Chapter 5.
The single register controls protection for all of memory and for both instruction and data
fetches. As shown in Figure 9-57, the register consists of eight 4-bit attribute fields. For
any memory access, one of the attrn (attribute) fields is chosen for both instruction
and data accesses by the following algorithm:
b ← vAddr31..29
cacheattr ← CACHEATTR(b||2'b11)..(b||2'b00)
This allows the cache attributes to be separately specified for each 512MB of address
space, just as with the attributes in the Region Protection Option described in
Section 4.6.3. And as with that option, no translation of addresses is done.
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
4 4 4 4 4 4 4 4
The resulting attribute is interpreted for both cache and local memory accesses as de-
scribed in Section 4.6.3.3, except that writeback caches are not available. It is in this
sense that the Region Protection Option is upward compatible with XEA1.
After changing the attribute of a region by WSR to CACHEATTR, the operation of instruc-
tion fetch from that region is undefined until an ISYNC instruction is executed. Thus soft-
ware should not change the cache attribute of the region containing the current PC.
After changing the attribute of a region by WSR to CACHEATTR, the operation of loads
from and stores to that region are undefined until a DSYNC instruction is executed.
else
usehit ← ca ≠ 4'd2
allocate ← ca = 4'd1 or ca = 4'd3 or ca = 4'd4
writethru ← undefined
isolate ← ca = 4'd14
guard ← 0
coherent ← 0
prefetch ← 0
streaming ← 0
lcadecode ← streaming||prefetch||coherent||guard
||isolate||writethru||allocate||usehit||0
endif
endfunction lcadecode
This change was made to make it easier to separate errors caused by the system from
errors caused by the Xtensa processor itself during debugging. If exception code is up-
graded so that exceptions with EXCCAUSE set to values 12-15 are routed to the code
that handled EXCCAUSE 2 and 3 as appropriate, then the previous functionality is re-
tained.
A.4 ICOUNTLEVEL
The ICOUNTLEVEL Special Register is undefined after reset instead of 4’hF, beginning
with the RA-2004.1 release. This change should not cause any difficulty as the behavior
is the same after reset since PS.INTLEVEL is 4’hF.
Beginning with the RA-2004.1 release, this trio of instructions was replaced with an indi-
vidual trio of instructions for each Special Register. For example, the new instructions for
accessing the LBEG register are called RSR.LBEG, WSR.LBEG, and XSR.LBEG. The new
instructions take only one operand, which is the AR register. The old version of the in-
structions continues to be supported as an assembler macro that translates to the new
ones.
The old trio of instructions was legal whether or not the Special Register accessed was
defined in the particular implementation and, therefore, never produced an illegal in-
struction exception. Each of the new, much larger set of instructions is associated with a
particular Special Register, and therefore is legal only if the associated register is de-
fined. Each of the trio of instructions for an undefined register raises an illegal instruction
exception when execution is attempted.
Rather than list several hundred individual instructions, Chapter 6 lists the instructions
as RSR.*, WSR.*, and XSR.* and references the list of Special Registers in Chapter 5.
Index
Numerics Architecture
16-bit instructions enhancements, adding.................................1
code density option .................................... 53 exceptions and interrupts ...........................32
16-bit Integer Multiply Option......................... 57 load instructions .........................................33
benefit for DSP algorithms ......................... 57 memory ......................................................27
32-bit Integer Divide Option ........................... 59 memory ordering ........................................39
32-bit Integer Multiply Option......................... 58 processor control instructions ....................45
A processor-configuration parameters ..........23
ABI registers .....................................................24
CALL0 ...................................................... 587 reset state ..................................................32
Windowed Register .................................. 587 store instructions ........................................36
Access rights, checking ............................... 148 Argument passing, ABI ................................590
Accessing Arithmetic instructions....................................43
memory ............................................ 144, 145 Assembler opcodes .....................................598
peripherals ............................................... 165 Assembly code ............................................598
ACCHI special register........................... 61, 214 ATOMCTL
ACCLO special register........................... 61, 214 register fields..............................................81
Adding ATOMCTL special register.......................78, 237
architectural enhancements ......................... 1 Atomic memory accesses ..............................77
bus interface ............................................ 194 Attaching hardware to processor pipeline....127
caches to processor ................................. 111 Attribute .......................................................144
exceptions and interrupts ........................... 82 Attributes, overview of .................................144
instructions for data cache ....................... 121 Auto-refill......................................................141
memory to processor ............................... 111 PTE format ...............................................174
new instructions to instruction set .............. 53 TLB ways .................................................174
Additional register files ................................ 240 B
Address Backward-traceable call stacks ...................191
register file ................................................. 24 Battery-operated systems, Xtensa ISA..........11
space, and protection fields ..................... 150 Big-endian
translation, virtual-to-physical................... 139 byte ordering ..............................................18
Address Registers (AR).......................... 24, 208 fetch semantics ..........................................31
Addressing notation ......................................................17
format for TLB .......... 152, 157, 167, 169, 172 opcode formats ........................................569
modes ........................................................ 28 Bit and byte order, notation............................17
Alignment................................................. 98, 99 Bitwise logical instructions .............................44
and data formats ........................................ 26 Boolean Option ..............................................65
and data types ......................................... 589 Boolean registers...........................................65
AllocaCause ....................................... 89, 181 BR special register .................................65, 215
Application Binary Interface (ABI)........ 180, 587 Branching.......................................................65
Application-specific processors, creating....... 13 Break codes, reserved.................................595
AR Register File ....................................... 8, 208 Break instruction operands ..........................595
Architectural Breakpoint
enhancements, adding................................. 1 coded .......................................................595
state of an Xtensa machine ..................... 205 instruction operand conventions ..............596
Debug Option ...............................................197 Example, FIR Filter with MAC16 Option ..... 600
instruction counting...................................201 EXCCAUSE special register.................... 84, 224
DEBUGCAUSE register...................................198 Exception
DEBUGCAUSE special register ..............198, 226 cause priority list........................................ 96
Debugger cause register ............................................ 89
coded breakpoints ....................................595 cause, numerical list .................................. 89
executing on remote host .........................203 exception groups ..................................... 243
Debugging semantics ............................................ 93, 96
facilitating .................................................142 state special registers.............................. 226
visibility, ICOUNTLEVEL register ..............201 support special registers.......................... 223
DEBUGLEVEL................................................197 vector....................................................... 144
exception ..................................................199 wait (EXCW) .............................................. 343
setting .......................................................201 Exception Option ........................................... 82
Definitions Double Exception Prog Counter (DEPC)
Notations ................................................... xix register....................................................... 92
Terms ........................................................ xix exception causes ....................................... 89
Delaying dependent instruction....................606 Exception Prog Counter (EPC) register..... 91
Demand paging............................................145 Exception Save Register ........................... 92
hardware ..................................................158 exception semantics ............................ 93, 96
Density option ..............................................595 Exception Virtual Address (EXCVADDR).... 91,
DEPC special register .............................84, 227 137
Design flow, Xtensa .......................................15 kernel vector mode .................................... 93
Designers, Xtensa Processor Generator .......13 operating modes........................................ 93
Determining if store succeeded, S32C1I.......78 Program State (PS) register....................... 87
Development and verification tools ..................5 user vector mode....................................... 93
Devices ........................................................127 Exception Prog Counter (EPC) register ........ 91
Digital Signal Processing, see DSP Exception Save Register ............................... 92
Direct memory access to local memories ....194 Exception vector
DivAlgorithm .............................................59 list of vectors........................................ 94, 95
Divide .............................................................59 DoubleExceptionVector ..................... 83
Double Exception Prog Counter (DEPC) regis- Exception Registers................................... 95
ter ...................................................................92 Information Registers ................................ 94
DoubleExceptionVector........83, 85, 86, 89 InterruptVector2..7........................ 107
DSP................................................................54 KernelExceptionVector ..................... 83
16-bit integer multiply option.......................57 ResetVector ..................................... 83, 85
for more than 16 bits of precision ...............67 UserExceptionVector.......................... 83
multiply-accumulate....................................60 WindowOverflow12 .............................. 181
DSYNC instruction, TLB entries.....................239 WindowOverflow4 ................................ 181
DTLB entries, processor state......................239 WindowOverflow8 ................................ 181
DTLBCFG register and MMU Option.............162 WindowUnderflow12 ............................ 181
DTLBCFG special register.....................160, 223 WindowUnderflow4 .............................. 181
E WindowUnderflow8 .............................. 181
ECC .............................................................128 Exception Virtual Address register ........ 91, 137
ENTRY Exceptions and interrupts.............................. 32
instruction, moving register window..........184 adding and controlling ............................... 82
Windowed Register Option.......................186 priority of.................................................... 96
EPC1 special register .............................84, 226 Exchange Special Register (XSR.SAR)......... 26
EPC2..7 special register.....107, 226, 227, 228 Exclusive access with S32C1I instruction .... 78
EPS2..7 special register.....................107, 227 EXCMLEVEL................... 88, 107, 108, 109, 197
S INTENABLE......................................102, 231
S32C1I instruction INTERRUPT..............................102, 229, 230
and exclusive access ................................. 78 ITLBCFG ..........................................160, 223
and memory ordering ................................. 81 LBEG...................................................55, 212
ATOMCTL Register...................................... 80 LCOUNT ......................................................55
use models................................................. 79 LEND...................................................55, 213
SAR special register ..................................... 215 LITBASE ....................................57, 216, 382
Saturation of integer values ........................... 62 M0..3 ................................................61, 214
Schedule of Pipeline ...................................... 14 MISC0..3 ........................................196, 236
SCOMPARE1 special register .................. 78, 216 MMID.................................................204, 235
Scratch registers.......................................... 196 MR .......................................................61, 214
Scratch registers readable and writable ...... 195 PRID.................................................197, 235
Self-modifying code, unsupported ............... 240 PS .......................................................84, 217
Shift Amount Register (SAR).......................... 25 PS.CALLINC....................................182, 220
Shift instructions ...................................... 25, 44 PS.EXCM ....................................................84
Sign Extension............................................... 62 PS.INTLEVEL .........................101, 217, 218
Single-instruction shifts.................................. 25 PS.OWB ............................................182, 220
Single-stepping ............................................ 201 PS.RING ..........................................160, 219
Software Interrupt ........................................ 100 PS.UM ................................................84, 219
Special Registers................................. 208, 620 PS.WOE ............................................182, 220
Special registers .......................................... 205 PTEVADDR ........................................160, 222
numerical list of special registers ............. 209 RASID ..............................................160, 222
reading and writing................................... 211 SAR...........................................................215
ACCHI ................................................ 61, 214 SCOMPARE1........................................78, 216
ACCLO ................................................ 61, 214 THREADPTR..............................................196
ATOMCTL ............................................ 78, 237 VECBASE ....................................................99
BR....................................................... 65, 215 WindowBase....................................181, 221
CCOMPARE................................................ 233 WindowStart .................................181, 221
CCOMPARE0..2 ....................................... 111 Specifying
CCOUNT ............................................ 111, 232 high-priority interrupts ..............................108
CPENABLE.......................................... 64, 236 interrupts ..................................................102
DBREAKA0..1 ................................. 198, 235 Stack............................................................180
DBREAKC0..1 ................................. 198, 234 frame ................................................587, 589
DDR................................................... 198, 236 initialization, ABI.......................................594
DEBUGCAUSE ................................... 198, 226 pointer (SP) ..............................................587
DEPC .................................................. 84, 227 State
DTLBCFG .......................................... 160, 223 see also Registers
EPC1 .................................................. 84, 226 additional register files .............................240
EPC2..7 .......................... 107, 226, 227, 228 caches and local memories......................240
EPS2..7 .......................................... 107, 227 defining new ...............................................14
EXCCAUSE.......................................... 84, 224 extensions ....................................................9
EXCSAVE1.......................................... 84, 228 general registers ......................................208
EXCSAVE2..7 ......................... 107, 228, 229 list of all registers .....................................205
EXCVADDR.................................. 84, 224, 225 list of special registers ..............................209
IBREAKA0..1 ................................. 198, 234 list of user registers ..........................237, 238
IBREAKENABLE ............................... 198, 233 Program Counter (PC) ..............................208
ICOUNT ............................................ 198, 231 special registers .......................................208
ICOUNTLEVEL ................................. 198, 232 TLB entries...............................................239
INTCLEAR........................................ 102, 230 user registers ...........................................237