Aucbvax.4891
fa.works
utzoo!decvax!ucbvax!works
Sun Nov 1 22:34:01 1981
WORKS Digest V1 #28
>From JSol@RUTGERS Sun Nov 1 22:21:22 1981
WorkS Digest Monday, 2 Nov 1981 Volume 1 : Issue 28
Today's Topics: Lisp Machine Language Support
Demand Paging On iAPX 432
Backing Out Of An Auto{inc|dec} Instruction
Symbolics 3600
Altos & Dorados & LispMs & Dolphins
Paging (Or Lack Thereof) On The MC68000
----------------------------------------------------------------------
Date: 1 November 1981 23:38-EST
From: The Moderator <JSOL AT RUTGERS>
Subject: Administrivia
[Due to a small hardware problem, some of you received multiple
copies of Friday's digest (V1 #27), sorry -JSOL]
------------------------------
Date: 30 October 1981 01:49-EST
From: Daniel L. Weinreb <DLW AT MIT-AI>
Subject: Languages and Lisp Machines
Eric Cooper is correct: Symbolics will support Pascal, Fortran 77, and
C on the 3600. This may work by actual translation into Lisp, or by
translation into an intermediate representation inside the compiler.
------------------------------
Date: 30 October 1981 0755-EDT
From: Hank Walker at CMU-10A
Subject: autoinc/dec
It isn't that hard to implement autoinc/dec. The 11/780 has an RLOG
stack containing 9 locations of 5 bits each (I think). Whenever you
do an autoinc or dec, you push the inc or dec value on the stack. On
a fault (any kind of fault), the microcode pops the stack values and
reverses the operations. I can think of lots hairy problems with
backing out of instructions than this.
------------------------------
Date: 30 Oct 1981 (Friday) 1154-EST
From: FRANKEL at HARV-10
Subject: Re: Demand paging on iAPX 432
To: Schiffman at SRI-KL
cc: FRANKEL
The intel iAPX 432 does not support any form of demand paging, but,
rather, has a fairly primitive segmentation scheme. This scheme
allows segments to either be entirely swapped in or not in memory at
all. The dual 68000 implementation allows for true demand paging with
the restrictions already enumerated. Other 68000 solutions include
restricting the instructions that a compiler will generate so that the
page fault address can be detected and the code resumed (using only
one 68000). Motorola is in the process of coming out with a new 68000
that corrects the "bus error" problem and some really minor
annoyances.
Jamie Frankel
------------------------------
Date: 31 October 1981 02:51 est
From: HGBaker.Symbolics at MIT-Multics
Subject: Symbolics 3600
36-bit machine, 2^28 word address space (1 billion bytes)
32-bit immediate (non-consed) integers, IEEE float
instruction fetch unit
instruction + stack cache
2^24 word physical address capability
512K words memory/card
4-5 slots for memory cards
67, 160, 300+ Mbyte winchesters
10 Mbit Ethernet
800 rows of 1000 dots B/W
1K x 1K color, 8 bits/pixel
68000 I/O controller
Multibus.
basic configuration <$60K RYLAND ETHERNET PROTOCOLS ------------------------------ FOR CORP 1981 FROM: SRI-KL AT AVAILABILITY 31 10. AND REASONABLENESS. QUANTITY OCT TO 1019-PST <RYLAND DATE: CHRIS SUBJECT FROM XEROX>
Subject: one last apologia; query for high-end users
In response to Peter Deutsch's mail, I should once more emphasize that
my initial flame was mostly in reaction to the world's tendency to
adulate the Alto; as Peter pointed out, the folks at XEROX knew long
ago that they had outgrown the machine, but I don't think that's clear
to the world at large. I didn't intend to slight XEROX. And, yes,
the Dorado certainly "whup[s his] ass" off the current Lisp Machine,
though it's a little hard to determine the relative speeds, given the
different word sizes and internal data path sizes.
Now, my query, addressed to those of you who are contemplating using
personal machines for high-end, mostly stand-alone computational
needs, i.e., AI (speech, robotics, vision), VLSI design, physics,
etc.: what is your sense about the language base you'll need for your
work? This begins to approach "theological" issues, but I still think
it's an interesting topic.
For example, my feeling (shared by some, I hope) is that the only two
languages worth considering are Lisp and Smalltalk (I'm ignoring the
idea of embedding well-known languages such as Fortran and C in a Lisp
or other environment, to support those who don't want to deal with the
host language). The Lisp Machine and the Dolphin provide two rather
distinct approaches to the environment, but both provide Lisp. The
Dolphin, running Interlisp, is "pure" Lisp in the sense that it makes
no concessions in the arena of object-oriented programming. The Lisp
Machine is heavily object-oriented, with perhaps the most flexible of
all classification schemes imaginable, Flavors. The problem I see
with this dichotomized world of Lisp and Flavors is that, though
people are hard at work turning more and more of the Lisp Machine
world into objects which are dealt with via message-passing, there
will always be the basic objects such as fixnums (integers) and conses
which aren't objects in the Flavor sense. This fundamental dichotomy
can't be good, in that it requires two different styles of programming
and thus requires some additional and perhaps needless complexity.
Of course, there are those who must use Lisp, so the Dolphin and the
Lisp Machine appear to be the only hope we've got. (The SpiceLisp
PERQ is still a question-mark, but it's hard to imagine it being as
powerful as the other two, in nearly any sense of the word "power".)
Now, Smalltalk presents us with a choice: it is certainly as capable
as Lisp, though it certainly requires a distinct approach to most
problems, and yet it is probably 1-2 years away from even beginning to
be used widely. And, it's not clear that it will enjoy the same
popularity in the research community that Lisp does (for whatever
reasons, which probably won't be technical). Further, it will
probably be 1 year at least before it is solidly up on an acceptable
machine, such as the Dolphin, Lisp Machine, or what-have-you hardware.
Can you wait for something which isn't a sure bet yet?
Yet, Smalltalk also appears to have a good chance to be widely
available on every imaginable size of machine, which can only bode
well for the availability of good software, people versed in the
language, transport- ability of research software into the "real
world" (and vice-versa), etc. For example, it is confirmedly rumored
that DEC is basing their personal VAX's system software (the SUVAX) on
Smalltalk, and this system has a rather good graphics interface. Of
course, HP, Tektronix, Apple, and DEC have been working with the
pre-release of Smalltalk for nearly a year now, so that provides
further reason to believe that it will have acceptance in the
industry.
Enough speculation. Comments?
------------------------------
Date: 31 Oct 1981 0143-PST
From: SCHIFFMAN at SRI-KL
Subject: Re: Demand paging on iAPX 432
To: FRANKEL at HARV-10
cc: schiffman at SRI-KL
The Intel iAPX 432 does not support any form of demand
paging, but, rather, has a fairly primitive segmentation
scheme. This scheme allows segments to either be entirely
swapped in or not in memory at all.
``Primitive segmentation''??
When you think about it, pages are only fixed-size segments that must
"either be entirely in memory, or not at all". Segmentation is
clearly a more "sophisticated" quantum of memory management because
objects don't come in fixed sizes. Unfortunately for computer
architecture, it is difficult to ALLOCATE memory if you don't pretend
they do.
The 432, which can have umpteen thousand segments defined at a time,
(with each one being a typed protection domain) is considerably more
sophisticated when it comes to virtual memory management than any
other microprocessor will be for a LONG time. In fact, it is more
sophisticated than [almost] ANY existing computer's memory management
architecture.
Of course, the implementation is such that only a few segment
descriptors are cached simultaneously, which leads to poor
performance.
In fact, I think that the 432 is going to suffer for a long time due
to its lack of "primitiveness".
-Allan
------------------------------
Date: 1 November 1981 02:28-EST
From: Leonard N. Foner <FONER AT MIT-AI>
Subject: Paging on the MC68000
Yes, there is a definite problem with paging with the MC68000 chip.
I worked on a design team about a year ago that, among other things,
was going to implement a virtual memory system using the MC68000 as
its CPU. Among various problems we ran across (such as only ONE
interlocked instruction, when you really needed at least two) was the
problem of paging.
As it turns out, the MC68000 does not save enough state on such a
fault to be able to recover completely. It misses about two status
bits. I don't have my manual handy, and it's been a while since I
looked at this problem (the project ended about 9 months ago), but it
most definitely would not do paging right. This made it quite
difficult to come up with a robust paging system.
The general idea we came up with was that paging on the MC68000 was
easily possible if certain instructions were avoided (or, alternately,
could be guaranteed never to fault upon execution, a rather diffcult
constraint).
If people are interested, I will go back through my old design notes
and see exactly what the problem was. It was not insurmountable (since
we figured out at least one way around it, as I recall), but it was
definitely an inconvenience.
I don't know about this system with two MC68000's in it, but from the
description it sounds like they're using one chip to keep track of
state for the other... a klugy solution at best, of course, but
better than having to eliminate virtual memory as an option.
Note that, even using two processors and having one wait for the other
to handle paging, you can keep track of the most recently paged-out
pages in memoyr and so decrease your hits on disk paging. VAX/VMS,
for instance, does this. Then you can do a fast (no disk activity)
page for most faults (VMS hits almost all the time except for programs
that do a LOT of random paging, which is rare... and demand-zero
pages (i.e., fulll of zeroes because they've not been used yet) are
easy to do without any disk access). The only time the processor
waits is when a fault really has to involve the disk. Then you're
stuck, since you can't run any other processes while that happens.
Have fun. if you want more info, ask and ye shall receive...
eventually.
<LNF>
[By the way, your message in yesterday's digest appeared with a From:
field of simply Goldberg. Since I don't know where you are, this goes
to the whole list without mailing to you directly, which is somewhat
impolite of me but necessary under the circumstances. JSol: if
Goldberg is at Rutgers, please make sure that the @RUTGERS winds up on
the message...]
[Oops - that makes two apologies this digest. A record? -JSOL]
------------------------------
Date: 1 Nov 1981 (Sunday) 2224-EST
From: FRANKEL at HARV-10
Subject: Re: Demand paging on iAPX 432
To: Schiffman at SRI-KL
cc: FRANKEL
When segmentation is the only form of memory management, it must be
used for both protection and typing, and storage allocation. The
advantage of having both segmentation and paging is that there are two
distinct mechanisms to handle the two problems. It is often true that
segmentation alone is sufficient to solve both, but not always. The
problem with paging is that the context of the data areas of the
original problem is lost and the memory management unit must attempt
to ascertain the working set of pages the program is using. The
problem with segmentation is that it is often the case that only a
small section of a object is to be touched yet the whole object must
be swapped in.
In the 432, the segments are limited to 64K -- too small for many
large arrays used in various applications {This problem can be
resolved by using levels of arrays of pointers to achieve the desired
size}. On the other hand, if one would attempt to implement LISP on
the 432, one would find that there are not enough segments to allow
each dotted pair or even each list to be a separate segment.
In many respects there are a large number of existing computers with
at least as sophisticated an MMU.
The 432 is certainly a large accomplishment for microprocessors and
(except for its poor performance) should find good acceptance in the
Pascal/Ada market.
Jamie Frankel
------------------------------
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.
