[Info-vax] OpenVMS I64 V8.1 "Evaluation Release"?

[Johnny Billquist]

On 2012-03-22 13.34, John Reagan wrote:
>
>
> "Fritz Wuehler" wrote in message
> news:e6bb2c71b6a2c5bb14d63db75f094b50 at msgid.frell.theremailer.net...
>
>
>> You guys are getting a little off track. The comment was no CPU today can
>> address 64 bits of physical RAM, which I don't believe is true.
>
> OK, here's another approach. We know for sure that no Itanium (or Alpha)
> has enough address pins to address 64bits of physical memory. Last time
> I looked, the largest was 50 bits physical, 54 bits virtual. I can't see
> why any chip implementation (I'm not talking architecture, but
> implementation) would waste the on-chip real estate and pin outs (or
> funky multi-cycle multiplexed addressing scheme) to support memory that
> can't be bought, powered, cooled, or even accessed in a reasonable cycle
> time.
>
> The largest IBM zEnterprise machine I found online (the M80) only
> supports 3TB of physical memory. I couldn't find hard evidence in some
> IBM document to give actual chip implementation address pins, but I
> won't believe it until I see it.

I searched around (thanks for the hints) on that machine. And that is 
what is addressable by the system. It does not tell how much a single 
CPU can address, which is (obviously) not 3 TB. That is not a power of 
2, so the actual answer for what one z196 CPU can address is less than 3 
TB. I've yet to find the actual answer (all my searching have not turned 
out an definitive answer, but it might be 64 GB, if my guessing based on 
some circumstantial information is correct. That would mean 36 address 
pins on that CPU.

> I'm not even sure that any 64-bit chip will let you populate the entire
> 64-bit VIRTUAL address space. Alpha and Itanium won't support it. Again,
> the problem is that if you create a full VIRTUAL 64-bit address space,
> it will not be backed by physical memory, but rather you need disk space
> for a paging file. Then you are back to the same problem. Compute the
> amount of hard drives/NAS boxes, you'd need to give you 2**64 bytes of
> backing store. Too expensive, too hot, too big, etc. And that's just for
> one virtual address space. Try two. Oh yeah, don't forget the dump file
> (or the time to compress one into a "smaller" dump file).

Also a point, yes.
But the point of having a large virtual address space is the ability to 
be able to load stuff in there with less chance of interfering with 
other parts in the virtual address space. Not neccesarily actually using 
64 bits of virtual address space at the same time.

Most 32-bit machines don't have 4 GB of physical memory to back that 
virtual address space either. And besides, since you are running several 
programs at the same time, each one of them could potentially have 4 GB 
of virtual address space, and you are *never* going to have the virtual 
address space of all concurrent processes backed by ram at the same time.

	Johnny