Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!bbn!bbn.com!slackey From: slackey@bbn.com (Stan Lackey) Newsgroups: comp.arch Subject: Re: 64-bit addresses Message-ID: <52895@bbn.COM> Date: 2 Mar 90 14:50:43 GMT References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <753@dgis.dtic.dla.mil> <3606@uceng.UC.EDU> <757@dgis.dtic.dla.mil> <4852@scolex.sco.COM> <29718@brunix.UUCP> <20534@netnews.upenn.edu> Sender: news@bbn.COM Reply-To: slackey@BBN.COM (Stan Lackey) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 40 In article <20534@netnews.upenn.edu> iyengar@grad2.cis.upenn.edu.UUCP (Anand Iyengar) writes: >In article <29718@brunix.UUCP> phg@cs.brown.edu (Peter H. Golde) writes: >>One might note that implementing a 64-bit address space >>with 64 KB pages and 8 bytes/page in the page table requires >>2 billion megabytes of page-table space. Hmmmmm..... There is a cost of virtual memory. It takes memory space for page tables, code space for the software for paging, performance when you miss, and both hardware and software complexity to make them work. It is the most common single cause of ECOs, both hardware and software. Why do we pay all those costs? For the functionality. Imagine a new architecture that runs physical only. (for rec.humor.funny, I guess.) Note that to map a 32-bit virtual address space [fully] with 4K byte pages requires four megabytes for just the lowest level. It doesn't sound like much today, but at the time the VAX came out, one megabyte of physical address was a LOT. We are not asking for 64 bit addressing to build full 64-bit address spaces tomorrow, neither virtual nor physical. The early 32-bit machines typically had far fewer than 32 bits of physical address. We are asking to not do what happened the last time - kludge more bits into a 16-bit architecture with nonsense like segments, making us go to all the trouble to make it work, then eventually increasing real addressing later, making us do the work over again, the way it should have been done in the first place. We would like a clean path for the future. It's OK to give us 64 bits of virtual address but only say 40 or 48 bits of physical address for say 1992 or 1993. Let technical needs drive up the number of physical address bits over time. I have stayed out of this one up to now. But one thing I can see (besides the desire to build large systems of processors that communicate though the use of a unified memory addressing scheme, BBN-style) is the ability to map the entire file system into a user's virtual address space. Naturally, I am assuming the architecture is fully functional, with the ability to share page tables, and page page tables. -Stan