Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cmu-cs-spice.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!rochester!cmu-cs-pt!cmu-cs-spice!skef
From: skef@cmu-cs-spice.ARPA (Skef Wholey)
Newsgroups: net.arch,net.micro.16k,net.micro.68k
Subject: 24 bit vs. 32 bit address space
Message-ID: <295@cmu-cs-spice.ARPA>
Date: Mon, 25-Feb-85 08:40:15 EST
Article-I.D.: cmu-cs-s.295
Posted: Mon Feb 25 08:40:15 1985
Date-Received: Wed, 27-Feb-85 21:08:42 EST
References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP>, <2393@nsc.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 45
Xref: watmath net.arch:864 net.micro.16k:221 net.micro.68k:606


    From: chuqui@nsc.UUCP (The Phantom)
    ...there really isn't much that a 32bit address gives you that a 24bit
    address doesn't also give you in a manufactured product EXCEPT a marketing
    tool. 

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.

It's true that in Vax-like VM systems, where your address space must be
divided into relatively few contiguous segments, one is very unlikely to
run into any difference between 24 or 32 bit addressing.  But programmers
on such a machines have to live with the fact that all their storage
allocation has to follow more or less a stack discipline.

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.

Very large address spaces have distinct advantage over smaller ones if sparse
addressing can be employed.  If not, few people are going to notice.  But the
combination of big and sparse makes a lot of things easier.

The place where all this hits home for me is implementing Lisp.  Franz Lisp
and Common Lisp on the Vax go through a good bit of contortion to do things
like allocate large arrays and do garbage collection in one contiguous chunk
of pages.  Common Lisp under Accent (on the Perq and soon other machines) has
a very clean storage allocator and garbage collector that takes advantage of
Accent's support for sparse address spaces.

Some non-Lisp uses of sparse addressing are co-routine stacks and big I/O
buffers.  There are many, many, others, I'm sure.

--Skef

-- 
uucp: ...!seismo!cmu-cs-spice!skef
arpa: skef@CMU-CS-Spice