Text File

Aucbvax.5733 fa.works utcsrgv!utzoo!decvax!ucbvax!works Tue Jan 12 17:17:15 1982 WorkS Digest V2 #2 >From JSol@RUTGERS Wed Jan 6 12:59:59 1982 Works Digest Wednesday, 6 Jan 1982 Volume 2 : Issue 2

Today's Topics: The SUN Workstation Multics - Paging Using Segments APPLE 68000 Rumor Answered & Query - 60010 With Paging ----------------------------------------------------------------------

Date: 4 Jan 1982 04:27:26-PST From: pratt@Shasta at Sumex-Aim Subject: Sun paging (and status)

To answer the question about paging on the Sun:

While the Sun does indeed have paging it is not demand paging, at least not with the 68000 processor. The paging unit serves two purposes: to provide hardware support for memory allocation at 2K (page) granularity, and as a place holder for the 68010, the promised VM 68000. The Sun is designed to perform demand paging with the 68010 as currently spec'd by Motorola.

Given the inability of the 68000 to work on other things while waiting for a page in the twin-processor solution, not to mention the additional complexity of that solution, we decided not to go the twin-processor route. (This isn't the NIH syndrome, Forest Baskett was kicking around the twin-processor 68000 idea at Stanford two or three years ago.) We felt that a more satisfactory approach was to build a non-demand pager for non-VM applications and shift our attention to the VM applications when the 68010 appeared.

While VM would be nice right now for our purposes, we are still managing to develop a lot of our software without it. You can make up for no VM to a considerable extent by being rather more generous with memory; Unix runs nicely on a Sun with 768K of memory, the size Sun I have in my office at the moment. (That doesn't count the 128K of graphics memory). However it WOULD make our programming a lot easier if we had VM. (Motorola, take notice.)

This may be a good opportunity to fill people in on what's been happening lately with the Sun project.

Hardware Status:

All three Multibus boards comprising the basic Sun workstation have reached the production revision of their PC boards. The processor board has been in production for several months and by now there are over a hundred of them in the field, mostly delivered to other customers of the licensees besides Stanford. The graphics board has been in production for about a month, and limited quantities are appearing. The Ethernet interface was just debugged last week and will now go into production. (About time, Stanford has only a dozen right now. This is holding up our using our processor boards, which aren't much use without the network. We are very dependent these days on Ethernet.)

Manufacture:

Various components of the Sun are presently licensed to some half dozen companies. CadLinc is licensed to manufacture all three boards and will bring out a completely packaged workstation with mouse and Star-like 17" landscape mode display. Forward Technology have delivered most of the processor boards to date, followed (I think) by Pacific Microcomputer, although Codata recently produced 50 processor boards. Imagen also produces processor boards, mainly for use in their Canon laser printer interface.

The graphics board is licensed to Forward and CadLinc. The Ethernet board is licensed to CadLinc, and will also be produced by VSI.

Of the above manufacturers, only CadLinc is presently in a position to offer a complete packaged Sun. Stanford has been quoted a price of $6800 from CadLinc for complete Suns (including mouse). However it would cost Stanford only $4900 + labor to plug in assembled and tested boards (at prices available to Stanford) and bolt the packaging, power supply, and card cage together, where labor = 1/2 day at the most, so we're not inclined to take the $6800 figure as the rock bottom price for Suns at Stanford.

Use

At Stanford we presently have 10 Suns in operation. Three are graphics workstations, three more are Ethertips (terminal concentrators with 16 lines on two of them, 32 lines on a third), one is a "bridge" (pseudo-Gateway), one a software development station, one the LOTS workstation, a partially built 16-processor teaching tool that presently can work as another Tip, and one at my home. We also have all the boards and other parts for three more graphics workstations, though the demand for Ethernet interfaces in other applications may delay putting these into service, at least on the Ethernet.

Some Suns are in operation at Lucasfilm, I don't know how many. They use mainly processor boards, disks, serial line connections, and octal uart cards as DZ-11 equivalents. Jim Lawson there tells me they are starting to rely on Sun Unix as much as on UCB Vax Unix for software development.

Imagen is delivering its first printers now, with Sun processor boards in them.

Codata have shipped quite a number (50?) of their CTS-300 workstations, which use the Sun processor board but their own graphics.

I don't know what the hundred or more other processor boards are being used for, or by whom.

Software:

Unix: John Seamons of Lucasfilm brought up Jim Gula's MIT Nu Unix on the Sun. We have an Ethernet based version of this Unix running at Stanford, using a large file on a Vax (Shasta@SUNet) as a disk accessed via the Xerox Leaf file access protocol. (This must be one of the more remote filesystems for Unices doing remote physical io. However I have a more remote one: a Unix running at my home via a 10 mile 1200 baud phone line, good for debugging Unix when you're stuck at home though hopeless for actually using Unix.)

Emacs: John Seamons has James Gosling's Unix Emacs running on the Sun, which he says runs a trifle slower than the speed we are accustomed to on the Vax.

Network software. We have Xerox Pup protocols running at Stanford, namely RTP/BSP for user telnet and Sequin/Leaf for most other applications. However we intend to go to IP/TCP ASAP.

Benchmarks: Never trust a benchmark. However I did a number of C benchmarks for a broad spectrum of nonnumeric programs (eight queens, Floyd's shortest path algorithm, a Lisp-like environment in which I ran merge sort, algebraic differentiation, and disjunctive-normal-form translation), and for all of them came up on the Sun with 70-75% the performance of the same C programs on Diablo, a Vax 11/780, with -O (optimizer on) for both machines' compilers. Floating point however loses badly on the Sun, as do arrays with dimensions not a power of two (essentially a compiler problem).

Literature:

Andy Bechtolsheim, Forest Baskett, and I have this weekend been putting the finishing touches to "The SUN Workstation: Hardware Architecture" and will be distributing copies this week. Requests to avb@sail or pratt@score.

Vaughan Pratt

[Thanks also go to AVB@SU-AI for announcing the SUN Handbook -JSol]

------------------------------

Date: 4 Jan 1982 13:55:58-PST From: decvax!duke!unc!smb at Berkeley In-real-life: Steven M. Bellovin Location: University of North Carolina at Chapel Hill Subject: Multics Cc: FONER@MIT-AI

Multics is a good example of how not to design a large-address space machine, at least not in the future. (Disclaimer: the following is based on my own experience 5 years ago on a Multics system at the Rome Air Development Center, and on Organick's book on Multics, which I recommend as a reference. If anything I say is grossly wrong or out of date, I'm sure some kind folks will point out my errors without *too* much laughter.)

A Multics address is really an ordered pair, consisting of a segment number and an offset into that segment. As I recall, the offset is about 18 bits, yielding a maximum segment size of 256K. The system supports a large number of simultaneously available segments. Address arithmetic does *not* carry from the offset into the segment number; hence the proper view is that the system provides multiple address spaces, rather than one large one. When one *initiates a segment* (more below), the system converts the name of the segment into a segment number, and returns a pointer to the base of the segment; after that, it may be addressed like any other part of memory.

Files, stack space, heap space, and external subroutines are all segments. When a file is opened, or a procedure is called for the first time, the appropriate segment is initiated. Appropriate spells are cast over various tables, etc., to avoid operating system overhead on subsequent calls to the same procedure. The system is fairly smart about breaking the linkage between a segment number and a particular segment, as when a particular procedure is recompiled; users doing sophisticated things can trip over this, however.

The two big things this buys you are (a) runtime binding of procedure calls (there is a linker, though, for packages); and (b) a file can be accessed like any other part of memory. The classic example of how the latter can be used is file copying: one initiates the two files (the PL/I library will properly initialize structure descriptors), and then just do a structure assignment.

The place where all this falls down is large files. 256K is just not enough -- nor are we likely to see address spaces large enough -- to handle the size files people will want to manipulate. Multics handles large files as "multisegment files", a horrible kludge. Such files cannot be accessed as primary memory; special access methods must be used. Back when I was using Multics, many of the system utilities didn't understand about such beasts, and hence could not be used on multisegment files. But it isn't clear to me that enough bits could have been allocated. Historically, essentially every machine ever built (or its program-compatible successors) has run out of address space bits; furthermore, such bits are a scarce resource for the machine architect. To expect a general-purpose CPU to reserve enough bits to address the large files we can expect to use in the future just isn't reasonable; the alternative would slow down performance the rest of the time.

------------------------------

Date: 5 January 1982 02:42-EST From: John C. Gilmore <GNU AT MIT-AI> Subject: 68000 Apple rumor response; (unrelated) 68010 with paging query

My sources told me that the Apple IV would have a pair of 68000's -- one to run just the keyboard and bitmap display, the other to do the "work". It would run smalltalk. I don't know the resolution or the mouse quality, storage size, interfaces, etc. Presumably it would not support paging until Motorola fixes the chip.

On that topic, I heard a number recently -- 68010 -- which was supposed to be the version that supports page faults. Does anyone have any further info?

------------------------------

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.