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

[glen herrmannsfeldt]

John Reagan <johnrreagan at earthlink.net> 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.

Yes, to me physical address includes pins on the package.

The profitable lifetime of a chip is short enough that there is no
reason to add pins that won't be needed so soon. They might put more
pads on the chip than pins on the package, but not that many.

If you only call it real address, then there only need to be bits
reserved in the page table.

> 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'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.  

That is why you need the five levels of table. You can fill up parts
of the address space, leaving holes. Some put the OS at the highest
addresses, and user programs at low addresses, with nothing in between.

VAX uses the high two bits of addressing space to divide into four
different regions. 

> 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).

-- glen