Text File

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 <jgoerzen@complete.org> 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.