🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22740

Re: 64-bit addresses

#22740
From: Stan Lackey
Date: Fri, 02 Mar 1990 14:50
40 lines
2881 bytes
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
Technical Details
Message-ID: <52895@bbn.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!bbn!bbn.com!slackey
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <753@dgis.dtic.dla.mil> <WAYNE.90Feb11165528@dsndata.uucp> <3606@uceng.UC.EDU> <757@dgis.dtic.dla.mil> <4852@scolex.sco.COM> <29718@brunix.UUCP> <20534@netnews.upenn.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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> <WAYNE.90Feb11165528@dsndata.uucp> <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