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=