Aucbvax.4929 fa.works utzoo!decvax!ucbvax!works Mon Nov 2 23:52:21 1981 WorkS Digest V1 #29 >From JSol@RUTGERS Mon Nov 2 23:40:01 1981 WorkS Digest Tuesday, 3 Nov 1981 Volume 1 : Issue 29 Today's Topics: Programming Languages Dual CPU Paging Implementations Paging Vs. Segmentation Demand Paging On The iAPX 432 More On The Alto User's Handbook ---------------------------------------------------------------------- Date: 2 November 1981 02:51-EST From: Daniel L. Weinreb Subject: Programming languages I agree that Smalltalk's uniform use of message passing for all operations is more simple and elegant than the Lisp Machine's mixed use of simple (non-generic) function calls and (generic) message passing. However, I think that it would be very hard (though maybe not impossible) to use message passing everywhere without sacrificing a great deal of speed. In practice, it does not seem to hurt is much; the language has function calls and it has message sends, and both do argument-passing the same way; the only difference is that in one case you name a function directly, and in the other you specify an object and a message name, and the flavor system finds the function (the "method") for you. We use function calling for simple things, and full message passing when the modularity is interesting enough to require the added flexibility and control that message passing gives you. ------------------------------ Date: 2 November 1981 11:26 est From: Sibert at MIT-Multics (W. Olin Sibert) Subject: dual CPU paging implementations Sender: Sibert.Multics at MIT-Multics In the ones I'm familiar with, the implementation is very simple: the "problem" CPU simply experiences a VERY long memory cycle (many milliseconds) when it tries to access a page which the outboard memory management unit sees is not in core. No state saving, or complicated deductions about the processor status are required. The "supervisor" CPU simply waits all the time until the MMU notifies it that it should bring in a page, at which point it runs, does the I/O, restarts the other CPU, and goes back to sleep. This didn't work reliably with some early MOS microprocessors because they couldn't stand to have the processor clock stopped for more than about 5 milliseconds or so. This is really a pretty cheap way to implement paging, all things considered. The two CPUs run from the same memory, using the same bus, and CPUs are switched by tri-state buffers. CPU chips are pretty cheap (even 68000s), compared to total system cost. It's true that this doesn't do "real" multitasking on page faults, but the system can still do real multitasking on other events, like demand disk I/O and timers. ------------------------------ Date: 2 November 1981 11:35 est From: Sibert at MIT-Multics (W. Olin Sibert) Subject: paging and segmentation Sender: Sibert.Multics at MIT-Multics Ah, but there IS a fundamental distinction between paging and segmentation, to wit: Segmentation is a mechanism for helping the programmer manage information, and paging is a mechanism for helping the computer system manage information. A computer system uses paging in order to appear to have a larger quantity of physical memory than it was given by its manufacturer. In systems where the virtual and physical address spaces are comparable in size (the IBM 370, for example), this primarily manifests itself in the ability to multiplex several processes with the appearance that each has all the system memory available to it. In systems where the virtual address space is much larger (such as the VAX), it also provides the appearance of much more memory to individual processes. Segmentation, on the other hand, is a way for programmers to treat a single region of storage, of arbitrary size, as an object. Depending on the implementation, these objects may see many different uses-- if segments are cheap and plentiful, they can be used in a much more versatile fashion. When a system provides only one of these mechanisms, it must be twisted to provide the facilities of both. For instance, PDP-11 and VAX addressing is used to provide both the compartmentalization of segmentation and the load-based memory management of paging. Ideally, the two mechanisms should be completely independent; the effects of paging should never be directly visible to the programmer. This is usually not quite true; for instance, in Multics, segments are expensive, largely because each segment must be an integral number of pages, at 4K bytes each. Another problem is the allocation of segments in a linear address space: as long as the address space in which segments are allocated is large enough, garbage collection is rare, though fragmentation will be a problem. In a small address space, segments must be constantly moved and compacted to get free space. This problem is eliminated (but at a cost) by using paging to permit pages of a segment to be allocated anywhere in memory. Note that yet a third level of indirection can be imagined, which would permit pieces of segments to be relocated transparently, yet still not be a multiple of the pagesize in length, so that segments could be allocated in pieces throughout a large linear virtual address space, which was itself paged. This gets complicated, though, and one must draw the line somewhere. It would be possible, for instance, to implement an APX-432 paging system which used a dual processor approach to give the "problem" processor the appearance of as much actual physical memory as the chip can address, and use a "supervisor" processor (not necessarily a 432) to read in pages from disk when they are found to be missing. This would let the 432 programmer use segments with wild and gay abandon, never explicitly reading them in. ------------------------------ Date: 2 November 1981 20:25 est From: Frankston.SoftArts at MIT-Multics Subject: Re: Demand paging on iAPX 432 Reply-To: Frankston at MIT-Multics (Bob Frankston) cc: SCHIFFMAN at SRI-KL, FRANKEL at Harv-10, schiffman at SRI-KL Paging ^= Segmentation Segmentation is address space management technique, though it is often treated as a second level of paging. Paging is a memory management technique used by the system, though some systems are not careful about layering and let it show through to the users. Guess we need new words to avoid confusion not only due to word inflation but architectures like the IBM /38 and probably the iAPX 432 which do not make sharp distinctions. ------------------------------ Date: 2 Nov 1981 14:42 PST From: Taft at PARC-MAXC Subject: Re: The Alto User's Handbook In-reply-to: FURUTA's message of 23 Oct 1981 1607-PDT To: Richard Furuta cc: jeff at WASHINGTON, Dake, Swinehart, Lampson, Taylor, Taft Your message announcing the availability of the Alto User's Handbook received rather wide distribution (for example, I believe it appeared in the WorkS digest). I would appreciate it if you would convey the following clarification to Editor-people and any other lists you know about to which your original message was distributed. While the Alto User's Handbook has indeed been cleared for distribution outside Xerox, it has not been brought out as a PARC external report. Our present supply of Handbooks is limited, and we do not have the resources to satisfy the large demand that would be generated by a public release. Our past practice has been to sell Handbooks, at cost, to organizations that have Altos (principally at CMU, MIT, Stanford, and University of Rochester). But even this is ending, since we are no longer actively developing or maintaining Alto software at PARC; consequently, we are unlikely to reprint the Handbook again. People who do not have Altos may be interested in more general technical reports on the Alto and Alto-based software, available in the open literature. The most comprehensive report on the architecture of the Alto itself is "Alto: a personal computer", which appears in the recently-published second edition of "Computer Structures: Principles and Examples", edited by Siewiorek, Bell, and Newell (McGraw-Hill). Additional good sources of papers relating to the Alto and follow-on machines include the last two years' SOSP proceedings and several issues of CACM. We have published a number of PARC external reports on Alto-based systems. These are available on request, though again we are unable to satisfy an enormous demand. Many university and company libraries subscribe to the PARC report series, so you may be able to find copies in your library. Ed Taft Computer Science Laboratory, Xerox PARC ------------------------------ Date: 2 Nov 81 22:09:31-EDT (Mon) From: Michael Muuss Subject: Re: WORKS Digest V1 #28 JSol - I keep hearing about Smalltalk. Is there a good blurb online, or something in the recent press that I can sneak a peek at? Seems like there are enough enthusiasts out there, but it's new to me... -Mike [Don't look at me, I don't know much about it (except that it has been discussed on WorkS). You are invited to peruse the WorkS archives at MIT-AI, in DUFFEY;WORKS ARCHIV, or at Rutgers, in the directory -JSOL] ------------------------------ End of WorkS Digest ******************* ------- ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.