Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site alberta.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!alberta!jeff From: jeff@alberta.UUCP (C. J. Sampson) Newsgroups: net.arch,net.micro.16k,net.micro.68k Subject: Re: 24 bit vs. 32 bit address space Message-ID: <420@alberta.UUCP> Date: Sat, 2-Mar-85 23:39:46 EST Article-I.D.: alberta.420 Posted: Sat Mar 2 23:39:46 1985 Date-Received: Mon, 4-Mar-85 20:16:04 EST References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP> <2393@nsc.UUCP> <295@cmu-cs-spice.ARPA> Reply-To: jeff@alberta.UUCP (C. J. Sampson) Organization: his Personal Computer Lines: 29 Xref: watmath net.arch:918 net.micro.16k:243 net.micro.68k:628 Summary: If you use vs(n) virtual memory, you don't need 32 bits. In article <295@cmu-cs-spice.ARPA> skef@cmu-cs-spice.ARPA (Skef Wholey) writes: >If your operating system and VM hardware let you have sparse virtual address >spaces, there's a world of difference between 24 and 32 address bits. When >one can carve up his address space in any way he pleases, those extra address >bits can mean the difference between clean, efficient storage allocation and >contorted, inefficient storage allocation. > >With a large address space, I should be able to allocate and deallocate stuff >anywhere I want without penalty. Sparse addressing lets me do that. I can >have lots of tables grow very large without running into each other. With >a 32 bit address space, I should be able to have 16 tables that each have 256 >megabytes to grow in. With a 24 bit address space, each table would have only >one megabyte to grow in. If just one of those tables becomes larger than >that, then I'm screwed. Ah, but if you are using vs(n) implementation, this whole thing doesn't really matter. Every process has a full address space that starts at 0, and the MMU maps any page in VM to the correct page in real memory, and then pulls the data out of it. You can grow as much as you like because you have the whole address space. The only way 24 bits is going to get you in trouble here is if you have something that grows to bigger than 2^24 bytes of memory. (Don't laugh. Look at what happened to the IBM 370.) Since the National MMU supports vs(n), there should be no problem here. If you use vs(1) anyway, you are doing it the wrong way to begin with. ===================================================================== Curt Sampson ihnp4!alberta!jeff --------------------------------------------------------------------- "It looked like something resembling white marble, which was probably what is was: something resembling white marble."