Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site spuxll.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!whuxlm!spuxll!ech
From: ech@spuxll.UUCP (Ned Horvath)
Newsgroups: net.micro
Subject: Re: 4->8->16->32->64? bit micros
Message-ID: <597@spuxll.UUCP>
Date: Sun, 23-Dec-84 23:51:00 EST
Article-I.D.: spuxll.597
Posted: Sun Dec 23 23:51:00 1984
Date-Received: Mon, 24-Dec-84 05:18:52 EST
Organization: AT&T Information Systems, South Plainfield NJ
Lines: 42

There are perfectly good reasons for wanting larger address SPACES even
though one does not expect to have very-much-larger physical memories.
The venerable MULTICS provides an excellent example of a very elegant design
cramped by an inadequate address size; more recent experimental systems
(HYDRA and the Cambridge CAP) provide other examples.

When one wishes to have what is conceptually a two-dimensional address space --
(segment, offset) in the MULTICS case or (capability, offset) in the other
examples -- it is very nice to, among other things, remove the distinction
between "file" and "segment"; the capability-based systems tend to create
even more "segments" (a capability may be thought of as a segment with
additional protection information -- yes I know that is an oversimplification,
no flames please!).

Now, it is pretty clear that 16 bits is inadequate as a file offset; the early
MULTICS hardware had 18 bit offsets and, even given a 36-bit word, segments
were limited to about a megabyte.  A 24-bit byte offset is probably not
adequate by today's standards: you could't treat even a small disk slice
as a single segment.  32 bits might be adequate for most purposes.

Looking at the other dimension, the capability systems create and destroy large
numbers of small objects: one calls "services" by passing them capabilities
to small objects (conceptually, one passes arguments in capabilities) and
gets results similarly contained.  A 16-bit capability namespace might be
barely adequate.  If one wanted to have "lots" of simultaneously open
files -- er, segments -- even that might not be enough.

All of the foregoing presumes that a high-powered memory-mapping unit, and the
ability to address the entire memory hierarchy as if it were all RAM, is a
good idea.  Personally, I like it a lot, and I think I have established that
a minimum of 48 bit addresses -- preferably 64, perhaps even 96 -- would be
nice to support the abstraction properly.

Now, before this raises a lot of needless flaming, I should note that this
does NOT imply that every instruction need generate 96-bit addresses.  The
CAP system, for example, held capabilities in registers, and relied on the
compiler to keep both the number of registers and the instruction-word size
down to a reasonable level; the MMU uses an associative memory of modest size,
also: it works.  For more data, consult the CAP monograph, or (perhaps more
accessible) the '77 SIGOPS proceedings.

=Ned=