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