Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch,net.micro.16k,net.micro.68k Subject: Re: 24 bit vs. 32 bit address space Message-ID: <863@peora.UUCP> Date: Fri, 26-Apr-85 08:29:14 EDT Article-I.D.: peora.863 Posted: Fri Apr 26 08:29:14 1985 Date-Received: Mon, 29-Apr-85 14:18:09 EDT References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 50 Xref: watmath net.arch:1122 net.micro.16k:327 net.micro.68k:734 hammond@petrus.UUCP (Rich Hammond at Bell Communications Research, Inc), responding to my comments comparing and contrasting pipes with shared memory, writes: > No, pipes have synchronization, which you don't get with shared > memory alone. Well, not with conventional shared memory. I must admit having an unusual interest in this area, since my Doctoral dissertation was on the subject of making synchronization operations be integrated with shared memory access. A practical implementation of such a facility (it preceeded my own research, which was involved with using Dijkstra's `weakest precondition' to characterize shared memory access in order to facilitate correctness proofs where shared memory is involved) is found in the Denelcor HEP machines. > Wait, memory-mapped I/O is not the same as viewing a device as a segment. Here we just differ on our views of device access. A serial byte-stream device, such as a serial port to a tty, cannot be read randomly. You could assign "addresses" to each byte coming in, but this wouldn't do much for you, since you can't go forward and read n bytes ahead of your current character, or backward and read previous characters (unless you copy them into a random-access memory, of course). When you treat a device as a segment, you are just integrating the addressing of the device into the machine instruction set, so that the address that appears in a machine instruction (or more accurately, a memory-access operation via the user-level instruction set) can specify an address on a random-access device other than conventional RAM. The fact that primary memory is generally the only random-access device addressable directly through all the instruction set's addressing modes and instructions causes it to be perceived differently than all other devices. But it's not; it's a device like any other (subject to the usual device- specific constraints of volatility, etc, of course). The point you raised in your comments, however, is one of the major reasons why it generally is given this special status; if all the storage locations in a machine are all namable in the same name space, the number of bits required to represent the name space can be fairly large. On the other hand, you aren't required to use all the bits in all your instructions; they could, for instance, just appear in the translation tables for mapping virtual to physical addresses, with the virtual addresses having a much smaller number of bits than the physical address. This is the reverse of what we usually see now; but it doesn't have to be that way. -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642