Aucbvax.4577 fa.works utzoo!decvax!ucbvax!works Wed Oct 21 05:42:57 1981 WORKS Digest V1 #20 >From JSol@RUTGERS Wed Oct 21 05:11:17 1981 WorkS Digest Wednesday, 21 Sep 1981 Volume 1 : Issue 20 Today's Topics: Administrivia Where are the 32 Bit WorkStations? VideoDisks as Storage Devices Mesa Manual Query ---------------------------------------------------------------------- Date: 21 October 1981 0642-EDT (Wednesday) From: The New Moderator Subject: Hello! and Welcome to WorkS! Hello, Roger Duffey was a superlative moderator and it will not be an easy job trying to match the quality of service which he was famous for. I will, however, do my best and hope that I can at least comes close to the fine work Roger has done. There is no question that the ARPAnet community will miss his fine services as moderator. Once again, I wish to express my appreciation at being given the responsibility of maintaining this digest, and I hope that the transition between moderators will be as transparent to the readers as possible. Enjoy! JSol P.S. You can still send mail to , or you can send mail to if you prefer. Archives will continue to be maintained at MIT-AI, and additionally at Rutgers in the directory (at Rutgers, much of the WorkS archive is on tape, so if you desire back issues you should mail your request (or any list maintainence request) to or . ------------------------------ Date: 16 October 1981 1014-EDT (Friday) From: Hank Walker at CMU-10A (C410DW60) Subject: when are 32-bits coming CC: dreifu at wharton-10 I assume that the MC68000 doesn't count as a 32-bit machine. Intel has yet to ship any 432s, so it will be a while before any appear in personal computers. A VAX takes 400 kbits or more of microcode, and at least 500k transistors total to make even the slowest one. Even a chip-set must be fairly complex. The obvious thing that 32 bits gives you is a larger virtual address space. Lots of applications are hard up against existing limits, and must resort to memory management by hand, which is a royal pain. In addition, 32-bit processors usually have a more complex instruction set, addressing modes, etc, which allow them to perform better on a wide range of tasks (ignoring the RISC arguments). Examples are string and floating-point datatypes. The 432 includes a significant amount of OS support, as well as provide a capability architecture. Given the thickness of the architecture manuals, I don't know how well this will go over. 32-bit processors usually also have a larger physcial address space. Since 16 Mbytes and more memory will appear on personal computers in this decade, this is an important consideration. ------------------------------ Date: 19 October 1981 18:50 edt From: SSteinberg.SoftArts at MIT-Multics Subject: #19 and 32 bits The most important thing 32 bits buys is larger address space. It was annoying to have to pass around 16 bit pseudo-pointers on the IBM 1130 (back in '69) to address a data base larger than 64KB and it is still annoying to have to call the subroutine library in order to reference an item of data. Think of 32 bits as more object names one can use in programming. ------------------------------ Date: 20 Oct 1981 0030-PDT From: SCHIFFMAN at SRI-KL Subject: 32-bit micros, iAPX-432 based workstations cc: schiffman at SRI-KL To figure out how much an advantage a 32-bit micro would be, first figure out what a "32-bit" micro is -- There are several things in a computer which have a `size': 1) The width of the accumulators/general-registers (This is confusing in machines which allow concatenation of registers like the Z8000). Wide registers gets you shorter (faster) programs by eliminating extra `name' references for OPERANDS WHICH REQUIRE THAT PRECISION. Not surprisingly, 128-bit registers aren't very handy for programs which only do byte-boffing. In fact, wide registers HURT for programs which don't need the precision if having narrower registers means having more of them. The Z8000 tries to have its cake and eat it too. 2) The width of significant data paths such as the ALU. (How many bits can you add in one microcycle? Many machines have a N-bit ALU and an 2N-bit shifter.) Wide data-paths make atomic operations faster for operations which require the precision. All else being equal, however, the wider the data path gets, the slower it cycles (carry propagation). 3) The width of the processor/memory data interconnect. (How many bits can you fetch in one bus cycle?) Wide data interconnects to memory speed up operand fetches/writes which again, helps only on operands which need the precision. Luckily, if the instruction execution unit is at all clever, wide memory almost ALWAYS speeds up instruction fetches; this can be VERY significant. Unfortunately, for small systems, cost can be almost linearly proportional to memory bus width. Under these criteria.... CPU Register Data Path Memory bus Width (bits) Width (bits) Width (bits) ---------------------------------------------------------------------------- Z8000 64,32,16,8 16 16 MC68000 32 32 16 I8086 16,8 16 16 I8088 16,8 16 8 NS16000 32 32 16 iAPX-432 variable?, to 80 80? 16/user-prov. _____________________________________________________________________________ The table is straightforward, except for the 432. My understanding is that the 432 has no "general-registers", really. It does have many internal registers available at the microprogram level, at least some of which have to be 80 bits to hold results in Intel (IEEE draft) floating point `double-extended' format. As for the bus interface, this is rather complicated -- the 432's Bus Interface Unit can connect to user-designed memory systems of various types. I believe that the Intel evaluation boards use a 16-bit memory bus. So what about the 432 is 32-ish? Only the obvious, I think. As for its applicability in personal workstations, I think this is pretty dubious for the next few years. * A system including the 432 would be VERY expensive by workstation standards, even if Intel gave the chips away (which doesn't seem to be in their plans -- the set currently costs on the order of a kilobuck). Besides being very memory hungry, a realistic system requires an I/O processing symbiont higher in complexity than most current micro-computer systems. * A personal workstation system based on a 432 could very well be much SLOWER than a system based on (say) the 8086! Sorry folks, a full context switch on every subroutine call and a domain-check for every external reference is very expensive. Now if you had, say, four CPU sets in your workstation, you might very well win -- that is if all your compute-bound programs divided into four balanced processes. Intel seems to be saying that the 432 is intended for high-performance shared-database transaction processing systems. I say that if it's good for anything at all, its probably just that. -Allan ------------------------------ Date: 18 Oct 1981 (Sunday) 1506-EDT From: DREIFU at WHARTON-10 (Henry Dreifus) Subject: VideoDisks on Personal Workstations ? [Note: This message originally appeared on the VideoDisk discussion list -JSOL] Electronic Design for Sep-30, 1981 has a full artical on video-disk technology. Here are some highlights.... Corning has eraseable video disks using polarizers and stuff ! Medias being used include: Silver-halide, Tellurium,"Drexon Media", bismuth, rhodium, titanium, thermodegradable/metal film. Many are producing disks writable with semiconductor lasers (cheaper) Formerly it took a gas laser to produce enough power. (this is also due to improvments in laser technology)... Bill W ------------------------------ Date: 20 Oct 1981 1610-EDT From: PRSPOOL at RUTGERS Subject: MESA MANUAL Does anyone at XEROX-PARC ( or anywhere else ) know where I can get hold of a MESA manual ( or at least a fairly descriptive paper ). I recently noticed a referance to the MESA LANGUAGE MANUAL by James G. Mitchell, William Maybury and Richard Sweet of XEROX PARC, published in February, 1978. --Peter R. Spool Rutgers University ------------------------------ 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.