3.4. The Xtensa Program Counter

The Xtensa ISA employs a 32-bit program counter, which encompasses a 4-Gbyte address space. During a function call, only the lower 30 bits of the return address are saved, which restricts nested subroutines using function calls to a 1-Gbyte address space. (The other two address bits are used to store the amount of register-window translation: 0, 4, 8, or 12 entries.)

A function-call return restores the saved 30-bit return address and leaves the upper two bits of the program counter untouched. Thus related sets of function calls can operate in any of the four 1-Gbyte address spaces that comprise the overall 4-Gbyte space. Jump instructions, which use target addresses stored as 32-bit values in register-file entries, can shift program execution across the 1-Gbyte boundaries. This scheme reduces the number of memory accesses required to implement function calls, which improves the overall performance of the Xtensa ISA.

The resulting 1-Gbyte address restriction that the Xtensa ISA imposes on linked subroutines puts no real practical limits on the design of current-generation SOCs, which almost universally employ per-processor code footprints much smaller than 1 Gbyte. Per-processor SOC code footprints are unlikely to approach 1 Gbyte for many, many years. That’s simply too much code to run on any one embedded processor. From a system-design perspective, the inherent parallelism latent in such a tremendous amount of program code nearly always demands that the code be partitioned and distributed across multiple on-chip processors to reduce code complexity and thus diminish the occurrence of programming bugs, improve SOC performance, and reduce the on-chip processor clock rate.