set architecture) with N-bit integer registers and N (or nearly N) address bits, ignoring sizes of buses or floating-point registers. Many 32-bit ISAs have 64- or 80-bit floating-point registers and implementations with 8-, 16-, 32-, 64-, or 128-bit buses. Sometimes marketers have gotten this confused. I use the term 64/32-bit here to differentiate the newer microprocessors from the older 64-bit word-oriented supercomputers, as the software issues are somewhat different. In the same sense, the Intel 80386 might have been called a 32/16- bit CPU, as it retained complete support for the earlier 16-bit model.
ibm 370/145 PhotograPh by selbst gezeichnet, Dec PDP-11/20 anD Dec PDP-11/20 PhotograPh by Jay r. Jaeger
Why 2N-bits? People sometimes want wider-word computers to improve performance for parallel bit operations or data movement. If one needs a 2N- bit operation (add, multiply, and so on), each can be done in one instruction on a 2N-bit CPU, but requires longer sequences on an N-bit CPU. These are straightforward low-level performance issues. The typical compelling reason for wider words, however, has been the need to increase address bits, because code that is straightforward and efficient with enough address bits may need global restructuring to survive fewer bits.
Addressing—virtual and real—in a general-purpose system. User virtual addresses are mapped to real memory addresses, possibly with intervening page faults whereby the operating system maps the needed code or data from disk into memory. A user program can access at most VL (virtual limit) bytes, where VL starts at some hardware limit, then sometimes loses more space to an operating system. For example, 32-bit systems easily have VLs of 4, 3. 75, 3. 5, or 2GB. A given program execution uses at most PM (program memory) bytes
iBm 370/145 main memory no longer core, but DRAM, 1 Kbit/chip
of virtual memory. For many programs PM can differ greatly according to the input, but of course PM ≤ VL.
The RL (real limit) is visible to the operating system and is usually limited by the width of physical address buses. Sometimes mapping hardware is used to extend RL beyond a too-small “natural” limit (as happened in PDP-11s, described later). Installed AM (actual memory) is less visible to user programs and varies among machines without needing different versions of the user program.
Most commonly, VL ≥ RL ≥ AM. Some programs burn virtual address space for convenience and actually perform acceptably when PM >> AM: I’ve seen cases where 4: 1 still worked, as a result of good locality. File mapping can increase that ratio further and still work. On the other hand, some programs run poorly whenever PM > AM, confirming the old proverb, “Virtual memory is a way to sell real memory.”
Sometimes, a computer family starts with VL ≥ RL ≥ AM, and then AM grows, and perhaps RL is increased in ways visible only to the operating system, at which point VL << AM. A single program simply cannot use easily buyable memory, forcing work to be split and making it more difficult. For example, in Fortran, the declaration REAL X (M, M, M) is a three-dimensional array. If M = 100, X needs 4MB, but people would like the same code to run for M = 1,000 (4GB), or 6,300 ( 1,000GB). A few such systems do exist, although they are not cheap. I once had a customer complain about lack of current support for 1,000GB of real memory, although later the customer was able to buy such a system and use that memory in one program. After that, the customer complained about lack of 10,000GB support…
Of course, increasing AM in a multi-tasking system is still useful in improving the number of memory-resident tasks or reducing paging overhead, even if each task is still limited by VL. Operating system code is always simplified if it can directly and simply address all installed memory without having to manage extra memory maps, bank registers, and so on.
Running out of address bits has a long history.
The oft-quoted George Santayana is apropos here: “Those who do not remember the past are condemned to repeat it.”
Mainframes. IBM S/360 mainframes (circa 1964; see accompanying Chronology sidebar) had 32-bit registers, of which only 24 bits were used in addressing, for a limit of 16MB of core memory. This was considered immense at the time. A “large” mainframe offered at most 1MB of memory, although a few “huge” mainframes could provide 6MB. Most S/360s did not support virtual memory, so user programs generated physical addresses directly, and the installed AM was partitioned among the operating system and user programs. The 16MB limit was unfortunate, but ignoring (not trapping) the high-order 8 bits was worse. Assembly language programmers cleverly packed 8-bit flags with 24-bit addresses into 32- bit words.
As virtual addressing S/370s (1970) enabled programs that were larger than physical memory allowed, and as core gave way to DRAM (1971), the 16MB limit grew inadequate. IBM 370XA CPUs (1983) added 31-bit addressing mode, but retained a (necessary) 24-bit mode for upward compatibility. I had
DEc PDP-11/45 separate instruction+data (64KI + 64KD); 248KB maximum real memory
unix
PDP-11/45, operating system rewritten in C; IP16
c
integer data types: int, char; C on other machines (36-bit Honeywell 6000, IBM 370, others)
unix sixth edition: 24-bit maximum file size (16MB)
References:
Archives