Aucbvax.5751
fa.works
utcsrgv!utzoo!decvax!ucbvax!works
Tue Jan 12 21:17:26 1982
WorkS Digest V2 #4
>From JSOL@USC-ECLB Tue Jan 12 20:21:18 1982
Works Digest Sunday, 10 Jan 1982 Volume 2 : Issue 4
Today's Topics: What Is A WorkStation
Multics
256kB Chip & TandyCorp Announcement Rumors
68xxx - What's Happening At Motorola
----------------------------------------------------------------------
Date: 12 January 1982 12:15-PST
From: The Moderator <JSOL AT USC-ECLB>
Subject: Administrivia - AAAAUUUUUGGGGGHHHH!!!!
The new software also broke in very unfriendly ways, but it is
still better than truncated messages. Please bear with us while we put
the peices back together. If you are missing digests, please send a
message to WorkS-REQUEST asking me to resend you that issue. If you
get random messages (about problems with receiving mail from the
arpanet), please ignore them. I am on the recipient list, so I know
when these messages occur. If you receive multiple digests for Issue
4, please ignore them as well and accept my apologies, I have no idea
how many of them have actually been delivered. Starting with issue 5 I
would like to hear about any problem you have, thank you for your
cooperation in this matter.
I'm very sorry that this happened, please excuse any garbage
in your mailfile caused by this unfortunate problem!
Cheers,
JSol
------------------------------
Date: 9 January 1982 00:09-EST
From: Andrew S. Cromarty <CROM AT MIT-AI>
Subject: WorkStations?
I received several informative responses to my request for details on
the SUN. Among the most striking features of those responses, though,
was an assortment of comments suggesting that the SUN didn't have
paging or segmentation, that it did have segmentation and paging but
not virtual memory, and that it was "never intended to be a
workstation".
Some of those remarks may be attributable to inadequate press given to
the SUN (including by the SUN designers themselves, I suspect), but
they also suggest two questions that this dialogue has been talking
around for many months without (I think) addressing directly:
1. Why virtual memory? (This question was actually asked, or at least
implied, by FONER on 25-Dec.) Particularly when physical memory prices
are approaching dirt-cheaphood and address spaces for micros are in
the megabyte range (and certainly in the 100K range without any
problem), do we need virtual memory? Consider: there's an overhead in
the translation through paging tables and so forth, so it doesn't come
for free, even when supported in hardware (which still isn't free
itself, and requires maintenance, additional design effort, and so
forth.) Sure, RAM isn't free either, but those 64K bit chips are about
$7 each. I'm not suggesting that we abandon virtual memory; I'm
questioning what its virtues are in a WorkStation. Are the
applications we're going to run in PWS's going to be impeded or
impossible without it, or enhanced by it? Will it make a significant,
cost-effective difference?
2. What is a workstation? There seems to be a considerable difference
of opinion. Does a PWS have to be as powerful as a Lisp Machine in
order to qualify? (If so, not many will.) If the SUN can run Xenix
(the 16-bit Unix clone) including Unix Emacs, support some local
graphics, and handle some computation on its own plus network to a
file server, for example, is it still not a WorkStation?
A legitimate response to the latter question might be "Does it matter
what we call it?", but for the fact that Personal WorkStations are
presumably what the WorkS dialogue is about. Elsewhere I am part of a
group which meets regularly to discuss PWS's in all their gory detail,
and it seems difficult for us to get away from the question of what
one is; usually we find ourselves left with answers that sound
something like "It's whatever functionality I want sitting on my
desk", which can serve as a useful design touchstone but is hardly a
rigorous specification.
Similarly, I suggest that virtual memory is worth discussing here
precisely because there is apparently disagreement among WorkS
participants as to whether virtual memory techniques and problems are
germane to a WorkStation dialogue (even when the discussion centers on
implementations in PWS's). Are demand paging or segmentation really
needed for the applications we'll be running on these machines? Yes,
segmentation can provide protection and memory management for
object-oriented systems (for example), or even just for large programs
in general, but is that what we'll be using WorkStations for? Or will
they be used mostly for text-editing? Perhaps the Xerox star is just a
slick special-application turnkey system, the exception rather than
the rule among PWS's, and all we'll generally want to use these
systems for is relatively simple applications, saving large jobs for
larger, faster processors that the box on your desk can't, perhaps
even shouldn't try to, compete with.
If we are the (admittedly self-appointed) experts on WorkStations and
can't decide (that is, agree) on what fundamental features and
architecture they should have, who will? (I shudder at the thought of
leaving it to IBM, or even DEC.)
Any takers?
cheers, asc
[I would like to see some discussion on the subject of exactly "What
is a WorkStation." -JSol]
------------------------------
Date: 8 January 1982 22:03-EST
From: Daniel L. Weinreb <DLW AT MIT-AI>
Subject: Multics
Most explanations of Multics that I have seen on the net have been
somewhere between misinformed and completely wrong. However, Steven
Bellovin's description of the Multics virtual memory system is quite
correct. There are only two things I'd like to add. First of all,
the ability to dynamically link subroutines is one of the most
important things that Multics is about, and is (as far as I'm
concerned) the single most important thing about the segmentation
scheme. Secondly, the limitation on segment size is indeed a pain,
but it is not completely debilitating. In particular, programs
("object segments", to use the official term) never run into this
limitation; only data files do. And while 256K is not totally
gigantic, it does suffice for most purposes. Some people do run into
the problem; many (most) never actually encounter it.
When I had an opportunity to work on building a similar system, I did
participate in the creation of an improved design, which is being used
in the S-1 architecture at Lawrence Livermore. Without going into
gross detail, the boundary between the segment number and the offset
in an S-1 address "floats" such that you can have a lot of little
segments as well as a few really big segments in your address space.
The total pointer size is 31 bits, and you can have as few as one
segment, or as many as 16K segments (or maybe it's 32K). This still
isn't enough, but we only had 31 bits in which to work; if you really
wanted to feel that the problem was solved, I'd follow the example of
an experimental project at HP Labs that I once heard about in which
addresses were 96 bits: 48 bits each of segment number and offset.
------------------------------
Date: 9 January 1982 12:56-EST
From: Hal Abelson <HAL MIT-MC AT>
Subject: rumors
I hear from a reliable source that Tandy will announce their new
6800-based machine on January 19.
I've also heard tell of a company that is currently working on a 256K
byte (yes, BYTE) chip that they expect to be marketing next year.
Again, the source of the rumor is reliable. What do people think
about the credibility of this claim?
------------------------------
Date: 9 Jan 1982 10:24:22-PST
From: pratt@Shasta at Sumex-Aim
Subject: 68xxx devices
Cc: pratt
While I was in Austin this week I took the opportunity to talk to John
Zolnowsky at Motorola about 68xxx parts. Here's the scoop on three
promised chips.
68010
This is the VM 68000. A long time back (> 6 mo.) Motorola promised
this samples of this chip for August 82. It is reassuring that with
this date now only half as far away Motorola has not felt it necessary
to postpone it significantly. They expect to be have working silicon
then themselves, and to be making samples available in September.
68020
This is a sort of successor to the 68000, available around the third
quarter of 83. It features:
(i) 32-bit data bus
(ii) 24-bit address bus for the 84-pin version and 32 for the
100-pin version.
(iii) Bit-extraction operations, akin to the PDP-10
load-byte/deposit-byte operations. Current plan is that the
descriptor word giving the left and right boundaries of the field can
go in either the instruction stream or a register.
(iv) Higher-density version of the HMOS process (if you care).
(v) 10 MHz clock (i.e. no faster, pity).
68881
This is a floating point processor that one attaches to the 680x0,
also available around the third quarter of 83. It features:
(i) IEEE standard floating point operations.
(ii) 5 usec multiply.
Vaughan Pratt
------------------------------
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.
