Why Region Registers

From a post to comp.arch by Dale Morris, Chief Itanium Processor Architect

Here's some background for you on why we chose the RID + VA scheme in
Itanium, and why we settled on 8 region registers.

We wanted to design the address space mechanisms in Itanium in a general way
which would accomodate various OS address-space-layout approaches.  From
looking at various approaches that had been done before, and in particular,
at how those approaches were implemented in HW, we decided that most
approaches had very similar HW implementations, with different architectural
access to the implemented structures. So, we looked for an approach that had
about the same HW complexity as any of the previous approaches, but which
could be mapped onto any of the earlier approaches fairly simply.

SAS designs typically have had some sort of process ID register which was
then used along with the VA for translation lookup.  This approach avoided
the need to purge the TLBs on context switch (as very early designs did).

MAS designs typically tried to further improve TLB coverage by allowing
shared portions of the address space (like syscall entrypoints into the
kernel, shared libraries, shared objects, etc.) to use the same TLB entry
(as opposed to aliasing the object into multiple individual address spaces,
allowing for a single copy in memory but requiring multiple TLB mappings).

A two-level lookup approach, with a fairly large number of segment
descriptors, wasn't attractive because of the impact on basic load latency.
But a very small number of descriptors (region IDs) that could be held in
fast registers seemed to address much of the overlap of prior approaches
that we wanted.  For simple SAS systems, you could use the RIDs as process
IDs, and if you wanted to avoid aliasing syscall entrypoints into process
address spaces, you could use a separate region for the kernel.

The difference between 1 and a small number of regions (say 8) didn't have
much impact on HW complexity or timing. Because RID changes are fairly
infrequent, 1st level TLBs could be "pre-validated" based on the current
region register values, and hence no RID matching would be required for
1st-level cache load-use latency.

PA-RISC had a segmented scheme with 4 "space ID" registers. When it was
later extended to 64-bit, these weren't as important in terms of gaining
access to a larger than 32-bit virtual address space, but there were still a
number of important 32-bit applications that used them.  (Space registers in
PA-RISC were unprivileged.)  For compatibility reasons, it was attractive to
have at least 4 region registers that the PA space registers could be mapped
onto.

For flexibility, we decided that 8 region registers would be best.  Hardware
studies showed that this number would not impact any cycle-time critical
paths, and the additional granularity allowed for more flexibility in terms
of shared objects, etc. (For example, a shared object portion of the address
space need only occupy 1/8th of the potential address space, rather that
1/4.)

You're certainly right about the aspect of preferred page sizes, and OSs on
Itanium do make use of this to selectively size data pages differently from
code pages, etc.

Remember, too, that 64-bit development was still pretty young (it still is,
I would argue) at the time that Itanium was developed, and we wanted to
ensure that the architecture could grow with the industry's use of 64 bit
spaces.

OK, there's a bit of background for you.  There are certainly a lot of
approaches in the architecture design address space support; the approach we
took in Itanium is just one.  But, the flexibility has turned out to be very
valuable in the porting and efficient tuning of various OSs for Itanium -
HP-UX, Linux, Windows, OpenVMS, etc.

- Dale Morris
  Chief Itanium processor architect
  Hewlett-Packard 

IA64wiki: WhyRegionRegisters (last edited 2009-12-10 03:13:47 by localhost)

Gelato@UNSW is sponsored by
the University of New South Wales National ICT Australia The Gelato Federation Hewlett-Packard Company Australian Research Council
Please contact us with any questions or comments.