Aucbvax.5747
fa.works
utcsrgv!utzoo!decvax!ucbvax!works
Tue Jan 12 19:52:49 1982
WorkS Digest V2 #3
>From JSOL@USC-ECLB Tue Jan 12 18:03:48 1982
Works Digest Saturday, 9 Jan 1982 Volume 2 : Issue 3
Today's Topics: Administrivia - All Moved In
Large Address Spaces - Multics & IBM
----------------------------------------------------------------------
Date: 8 Jan 1981 16:06-PST
From: The Moderator <JSOL AT USC-ECLB>
Subject: All Moved In...
Many thanks for being patient with me while I moved from
Rutgers to USC-ECL. Mail to WorkS may now be sent to
WorkS@USC-ECLB, in addition to the normal addresses, WorkS@MIT-AI and
WorkS@Rutgers.
The archives are now in the directory <JSOL.WORKS> at USC-ECLB. Volume
1 in its Entirety is stored in <JSOL.WORKS>VOLUME-1.TXT. Current
issues are stored in <JSOL.WORKS>WORKS.RECENT.
In addition, I am now testing new software used to distribute WorkS.
Please report any problems (truncated or garbled digests or
multiple digests received) to me with great dilligency
(WorkS-Request@USC-ECLB).
------------------------------
Date: 6 January 1982 01:11 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: Large address spaces
Sender: COMSAT.SoftArts at MIT-Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: Leonard N. Foner <FONER AT MIT-AI>
There are actually a few related concepts:
Uniform addressing --
This is used by both Multics and the IBM/38 among others.
It means that one can just name an object and need not
worry about how to acccess it, i.e. via memory or via a
file system. This is closely related to object-oriented
architectures, though Multics represents an earlier
approach and deals better with large objects than small
ones.
Large address space:
This means that the set of objects that can be named is
sufficiently large and can be represented in a virtual
memory.
Large memory:
This simply means that one does not have to spend most of
the time developing strategies to fit inside of a small
machine. Of course, when one has a small machine reality
can impinge. A large address space with a small memory
can be inefficient, but this is relative. The concept of
a working set is real and effective.
Memory based communication:
This is important in Multics, but can present problems in
distributed architectures. But is it actually possible to
distribute a memory based system. Message based
communication is simpler to distributed since all one need
do is implement the interfaces and thus can support
communications among heterogeneous components.
These concepts are all relevenet to work stations. Basically,
having a large uniform address space with sufficient physical
resource to support it greatly reduces the cost of
implementation and makes for a more effective implementation.
I think Star attempts to do this, but doesn't have enough
physical memory to make the best use of its architecture -- at
least in the first implementation.
------------------------------
Date: 6 January 1982 01:14 est
From: SSteinberg.SoftArts at MIT-Multics
Subject: large address spaces
I know that Multics uses its large address space well. A
workstation designed which uses its large address space is the
LISP machine being sold by Symbolics. My feeling is that it is
possible to write software for poorly designed hardware running
horrid operating systems but there is no need to do so. It is
possible to waste time with dippy address spaces and
atavistically designed operating systems but it is a lot easier
to just concentrate on new applications.
------------------------------
Date: 6 January 1982 23:00 est
From: Frankston.SoftArts at MIT-Multics
Subject: Re: Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: decvax!duke!unc!smb at UCB-C70, FONER at MIT-AI
While this not a Multics forum..
The comment that the Multics segmentation scheme fails because
it does not handle large files is wrong. This is saying that
it fails because the scheme does not support record files,
indexed files or whatever. In fact, these are all objects that
normally use program mediated access (i.e., an I/O system).
The fact that Multics streamlines the simple cases and provides
efficient mechamisms for implementing files (i.e. directories
of segments -- the multisegment files) does not meant that it
is bad, just that programmers fall into the trap of using the
nonmediated direct access to segments because it is there, not
because it is appropriate for a particular application.
It is also a FEATURE that segments and offsets are independent.
If increasing the offset did go over into the next segment,
errors in address arithmetic could result in bashing some bits
in some utterly unrelated an innocent object. Since offsets,
not segment numbers, are normally used in program address
calculations bad programs would only clobber the segment they
owned, not another one. This random clobber is particularly
nasty because it can go undiscovered for years -- long after
the cause and knowledge about how to recover has been lost.
This is not to say that Multics is perfect, but much of the bad
press is undeserved.
------------------------------
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.
