Text File

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 <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.