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