Spaces

Virtual addressing on PA-RISC is based on spaces. A virtual address is composed of a space identifier, which is either 16 or 32 bits long (depending on the hardware model), and a 32-bit offset within the space. Therefore, each space can contain up to 4 gigabytes, and there is a large supply of spaces.

	NOTE: In the 64-bit mode architecture each application is provided a flat virtual address space of 2** 64 bytes, which is divided into four quadrants. Each quadrant is mapped into this global virtual address space by means of four space registers, which are under the control of the operating system.

Every program on an HP-UX system is assigned two spaces when it is loaded for execution by the operating system: one for code, and one for data. The HP-UX operating system makes the code space read only, so that it can be shared whenever several processes are executing the same program. The data space is writable by the new process, and is private to that process; that is, every process has a unique data space.

The actual space identifiers assigned to these two spaces can vary from one execution of the program to the next; these numbers cannot be determined at compile time or link time. Generally, programmers do not need to be concerned with the space identifiers, since the operating system places them in two reserved space registers, where they remain for the duration of program execution. The identifier of the code space is placed in space register 4 (%sr4) and the identifier of the data space is placed in space register 5 (%sr5).

When writing an assembly language program, declare a space named $TEXT$ for executable code, and a space named $PRIVATE$ for modifiable data. Constant data or literals that you do not plan to modify during program execution, can be placed in either space. Placing constant data in the $TEXT$ space decreases the size of the nonsharable part of your program and improves the overall efficiency of the operating system.

The particular space registers mentioned above play an important role in virtual addressing. While many of the branching instructions, such as BL, BLR, and BV, are capable of branching only within the currently executing code space (called PC-space), two of the branching instructions, BE and BLE, require that you specify a space register as well as an offset. These instructions allow you to branch to code executing in a different space. On HP-UX systems, normally all code for a program is contained in one space, so all BE and BLE instructions should be coded to use %sr4.

In contrast, the memory reference instructions, such as LDW and STW, allow a choice between two forms of addressing: long and short. With long addressing, you can choose any of the space registers 1 through 3 for the space identifier part of the virtual address. The space offset is formed as the sum of an immediate displacement and the contents of a general register. With short addressing, one of the space registers between 4 through 7 is chosen automatically, based on the high-order two bits of the base register. Each space addressed by these four space registers is effectively divided into four quadrants, with a different quadrant of each space accessible via short addressing.

On HP-UX systems, all of a program's code is placed in quadrant zero of the $TEXT$ space, or %sr4, (space offsets from 0 through 0x3FFFFFFF). The data is placed in quadrant one of the $PRIVATE$ space, or %sr5 (space offsets from 0x40000000 through 0x7FFFFFFF). Therefore, literal data in the code space and modifiable data in the data space can be addressed using the short addressing technique, without any concern for the space registers.

The identifier for shared memory segments, including shared library text, is placed into space register 6 (%sr6). Shared memory and shared library text are placed into quadrant two of the shared memory space (offsets 0x80000000 through 0xBFFFFFFF). The identifier for system code is placed into space register 7 (%sr7). System code is placed into quadrant three of the system space (offsets 0xC0000000 through 0xFFFFFFFF). Table 3-1 “Memory Layout on HP-UX” shows the memory layout on HP-UX.

You can define spaces other than $TEXT$ and $PRIVATE$ in a program file by declaring a special kind of space called an unloadable space. Unloadable spaces are treated as normal spaces by the linker, but as the name implies, are not actually loaded when a program is executed. Unloadable spaces are typically used by compilers to store extra information within a program file. The most common example of an unloadable space is $DEBUG$, which is used to hold symbolic debugging information.

The sort key attribute allows the programmer to control the placement of a space relative to the other spaces. The linker places spaces with lower sort keys in front of spaces with higher sort keys.

The .SPACE directive is used to declare spaces. The assembly language programmer is not required to fill one space before beginning another. When a space is first declared, the Assembler begins filling that space. The .SPACE directive can also be used to return to a previously declared space, and the Assembler continues to fill it as if there had been no intervening spaces.