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 <DLW AT MIT-AI>
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 <FURUTA WASHINGTON AT>
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 <MIKE.BMD70@BRL>
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 <WORKS>
directory -JSOL]
------------------------------
End of WorkS Digest
*******************
-------
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
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.
