On 2010-10-30 01:12, <arcarlini at iee.org> wrote: Yes. And the virtual address space is divided into 4 parts (as you well know :-) ). P0, P1, S0 and S1. Only P0 and P1 is actually process local, while S0/S1 is system wide. Well, the design allows it to grow to 34 bits. Specific implementations might have limited it to 32 bits, but that's another story. Two different things here. The NVAX chip have two different formats of the page address. 21 bits or 25 bits. With 21 bits, you can only get 30 bit physical addresses (the old VAX model). With 25 bits, you get a total of 34 bits of physical address. Now, I don't know if the NVAX brought all 34 address bits out of the chip, but that is the size of the physical address created by the MMU anyway. The actual machines, such as the VAX 7000 on the other hand, clearly only allowed a max of 4G. Of that, 3.5G was for physical memory, and 0.5G was reserved as I/O space. But that is a design decision of a machine, and have less bearing on the architecture. It is a question of the bus used in the machine, as well as where I/O adapters will be present on the bus, and so on. I suspect all software running on a VAX7000 to always have the top two bits of the PFN in the PTE to always be zero. But the bits are there none the less. Anyhow, even with only 3.5G of physical memory, it will be more physical memory than any one process can have virtual memory on the VAX, since a process cannot be larger than 2G (P0,P1) Probably. It would be interesting to see the pinout of the NVAX chip, to see if they brought all 34 bits out on that chip. All existing VAXen restricted physical addresses to at most 32 bits, though. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol