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