donn@sdchema.UUCP (12/17/83)
Some people have expressed interest in the results of the MicroMole Workstation survey, so I forthwith and hereby present them to the net under the severe caveat that what I say represents (mainly) hearsay and is not necessarily the opinion of my employers. I should also say that I am a programmer with a very shallow understanding of hardware, and almost all of my Unix experience has come on DEC machines. Keep in mind that several people have given me information that they would rather not be made public, so when I seem vague or circumspect, it is intentional and not the result of all the sleep I have lost over the last couple weeks... First, the MicroMole. We are a so-called Research Resource of the National Institutes of Health. We are normally funded to provide software and hardware to important projects in biochemistry which need it, both locally and nationwide. NIH funded the UCSD RR for two five-year grant periods, during which we were among the first to write Unix software to take advantage of Evans and Sutherland Picture Systems I and II, the Floating Point Systems Array Processor AP-120B, and lots of other little odds and ends. At the end of the second grant period, NIH said in effect that we had become too stodgy and parochial, and that they would not renew our grant unless we came up with something new and original which could be useful to scientists all across the country, not just in San Diego. We worked hard and came up with the idea that we could put together a standardized workstation which could be sold at cost to both large and small chemistry and biology departments of universities, and would run a large collection of software which currently only works on our very expensive equipment. The workstations would have fast color graphics, an array processor and a microprocessor running Unix, and would cost under $80K (including educational and perhaps quantity discounts). This workstation was eventually named the MicroMole. NIH sent a committee to UCSD for a one-day visit to look at our prototype. At that time the prototype had rather a different configuration from what we are looking at now, but for informational purposes I will describe it: CPU: Pacific Microsystems, Inc. PM68D, Multibus Array Processor: Analogic AP-500 Graphics: Silicon Graphics, Inc. IRIS Tape: Cipher 9-track autoloading 1600bpi Disk: Fujitsu M2312 (84 Mb) (plus various things like device controllers, smart terminal, serial ports, modem, printer, plotter, Ethernet, etc.) (This package was (and is) rather more expensive than we'd like. Also it was not really integrated -- the AP-500 Multibus interface was not available and the PM system does not run Berkeley Unix and hence has no networking, needed to run the IRIS. The AP and the IRIS were thus hung off one of our VAXen.) Unfortunately the site committee didn't appear to know much about computers, and when we saw the report they made we had some severe reservations. We communicated these to the folks at NIH, and they agreed that we had not been treated fairly; so rather than funding the new project, we were given interim funding (no equipment money, no new salary money) and a 6-month wait before they are ready to consider our proposal again. This wait has been both a disaster and a blessing. For example, we had been anticipating gearing up to port 4.2 to the Pacific Microsystems board. Before we learned of the delay I wrote an article to the network seeking support for a 4.2 port to the 68K that would require no license fees apart from the usual Bell and Berkeley money, and got an overwhelming response. Because of the delay, we haven't been able to devote any time or money to this project due to insufficient manpower: we have gone from three full-time staff programmers down to one (me) because some of us have not wanted to wait for NIH and there is better money out in the commercial world. So a fun and valuable project has potentially gone down the tubes because of missed communication with NIH. Instead we have spent part of the time looking at other systems, and have found that since we put together our prototype, things have been getting cheaper and more reliable. The delay may actually help us produce a better system. In this note I will describe the various microprocessors and microprocessor vendors we have looked at and give the net some idea of what we heard from and about them. Please keep in mind that the prices are sometimes preliminary, out of date, or even out of a hat: if you are considering buying one of these (or not buying one!) be sure to get current quotations from the source. * Motorola 68000-based systems In the group of systems we have looked at, these come in three flavors: Multibus, VME and proprietary bus. I will describe three Multibus machines that we have the most information on. Pacific Microsystems PM68D -- Advantages: Cheap; reputed to have a good design (based on Sun). Supports up to 8 Mb (?) dual-ported memory between P2-bus and Multibus -- dual-ported memory seems on its way to becoming a standard feature of most 68K systems. Uses 68010 chip -- also a new standard. Easy to configure with Multibus peripherals. Disadvantages: Runs only Unisoft V7 Unix, despite a design for paging. Someone (perhaps us) will have to do a VMUNIX port to it to take advantage of this. They have had some problems in the past in supplying flakey peripherals from other manufacturers, but are reputed to be over this now. I don't have detailed pricing on them but should be able to make a good system with hard disk, Ethernet, 1/2 inch tape for $25K or so. Sun Microsystems Sun II -- Advantages: SMI is THE Berkeley Unix company. Has dual-ported memory, up to 4 MB (standard 1 Mb). 10 Mhz 68010 processor. Supports Ethernet. Available with high resolution b/w bitmapped monitor, and/or medium resolution color. SMD disks supported, and 1/2 inch tape. IEEE floating point hardware. Custom VLSI RasterOp hardware. Disadvantages: Said to be very slow compared to PM system. Same peripheral hardware problems as PM. No vector hardware available. High prices for peripherals and memory -- we figured at least $35K for a version with adequate memory, floating point, Fuji 84 Mb disk, 1/4 inch tape, no bitmapped monitor. It's $17K for a diskless WS with 1 Mb memory, b/w monitor, Ethernet. Source licenses are available: $15K for commercial users, $1K for academic. Does not include memory management software, basic graphics software or C compiler. Silicon Graphics IRIS -- Advantages: This comes as a WS and/or a stand-alone "terminal". The terminal is a 68000-based color graphics system with high-speed vector generation allowing real-time 3-D perspective transformations on a high resolution color display; very well suited to our Picture System-based graphics software. Uses custom VLSI "Geometry Engine". Also capable of high speed raster operations. Communicates to a host via Ethernet using XNS protocol -- host must run 4.2 BSD Unix. The WS is very Sun-like and runs/will run 4.2 BSD Unix. When the product becomes available the WS and the "terminal" will occupy the same card cage (and the same bus?), allowing high speed communication. Friendly people at SGI are a plus. Disadvantages: No floating point option. Fortran and Pascal sold separately. Not cheap. The high speed color graphics is quite reasonable (especially given the price of a PS300) but 68K memory is very expensive ($6K / Mb). An IRIS "terminal" with host Ethernet and host software runs ~ $45K. A combined IRIS WS with adequate memory, a 46 Mb disk and an Ethernet will run you ~ $65K plus $6K for a 1/4 inch tape required on at least one WS at each installation. I have no rumors for the prices on other peripherals (1/2 inch tape, 404 Mb disk). Not having seen a WS (although I have seen IRIS "terminals"), I have no idea what the speed will be for normal Unix applications. Both SMI and SGI have or are planning to have University discounts. (The IRIS University discount is 25% right now -- it will decrease to 15% in January, so they are a bargain for the time being.) * National Semiconductor 16032-based systems People have voiced a number of complaints about the 68K instruction set and architecture on the net. My feeling is that the 68K is a bad dream of a PDP11, with 32-bit registers added to make it look more advanced than it is. The 16K is to the VAX what the 68K is to the PDP -- and the 16K is the better for it. Unfortunately the 68K family has a large head start on the 16K in terms of market penetration and speed refinements. Here are some differences between the 68K and the 16K: 68K must distiguish data and | 16K has no such restrictions. address registers. | | 68K instructions are 16-bit | 16K instructions are byte-aligned. word aligned. | | 68K has C "char" and "short" | 16K has char, short and long address displacements. | displacements. | 68K has no bit field or string | 16K has these. instructions. | | 68K has very little instruction | 16K has symmetry on the level of symmetry; few instructions work | the VAX. generally on all data types. | | 68K byte-swaps (the infamous | 16K has VAX (i.e. correct) byte order. NUXI problem). | Oh well, I'm belaboring the point. On to the vendors. I have much less information on 16K vendors than on 68K vendors -- a number of companies are in the unnanounced stage (I can think of at least 3 off the top of my head, but of course I'm not supposed to say who they are) and are planning on early '84 products. Some general information: there are the same main three bus flavors for 16Ks as for 68Ks; I can actually cite names for each type -- LMC makes 16K machines on a Multibus, Elite makes 16Ks on the VME bus and National itself makes 16Ks on a proprietary bus. At least two vendors have tried to put 16Ks on the Unibus, but DEC has threatened to sue, so they will never appear. (Anybody remember CalData?) There are no 4.2 ports to the 16K yet, but at least one has promised to appear at Uniforum and certainly others are in the works. (Two 4.1 ports have been done, one at National and one at HCR.) The 16K products are aimed squarely at the VAX market -- one manufacturer says that their product will amount to a VAX11/750 for under $10K. National Semiconductor SYS16 -- Advantages: Supported by the vendor. Runs Genix, a flavor of 4.1 BSD. Has paging memory, up to 4.25 Mb main memory. Has high performance IEEE floating point instructions (optional). Supports software module features of the architecture. Disadvantages: Ghastly proprietary bus. 10 Mhz chips only available in-house; shipped products contain 6 Mhz. I didn't get any prices or relative performance under normal Unix load. 10 Mhz 16Ks perform at similar speeds to 10 Mhz 68Ks in benchmarks I have seen, although code density for 16Ks is much superior (as much as 35%) so 16Ks are actually performing fewer instructions in these benchmarks. I have materials on LMC and Elite somewhere but I can't seem to locate them right now. LMC has a 4.1 BSD Unix port by HCR; I have heard that the port isn't all that great, partly because HCR does not want to be in the Berkeley Unix business (hence a 4.2 BSD is unlikely -- anyone at HCR care to correct me?). Elite does not run Unix and has no plans to; they apparently have some home-grown operating system. I can't remember any speed or price quotations, except that VME systems in general are supposed to be faster (and smaller) than Multibus. * DEC MicroVAX-based systems DEC is coming out with its MicroVAX line and we thought it would be worthwhile having a look at what would come with it. DEC MicroVAX-I -- Advantages: Supported by DEC. Compatible with the ever-popular VAX line. Runs 4.2 BSD (soon). Lots of peripherals will be available. Disadvantages: VERY slow. Perhaps 1/2 the speed of current 68Ks, maybe less. Runs with a Q-bus, also reputed to be slow. Some VAX instructions are missing and must be implemented in software: "D" floating point, "CMPC3/5" and a few other string instructions, plus some miscellaneous instructions. DEC's support for Unix as seen in sales brochures is rather lukewarm. DEC's MicroVAX sales people seem to want to make life hard for system integrators. Prices are hard to get, but I have heard someone say that a system with 1 Mb memory, a small Winchester, Ethernet and Unix will cost ~ $20K. That's about all I'm prepared to type right now... Comments, suggestions, and corrections are strongly appreciated. Several people have sent me more information and impressions (I'm especially thankful to Steve Haflich at MIT) and I will summarize those at some later date (when I get back from vacation in January). Donn Seeley UCSD Chemistry Dept. RRCF ucbvax!sdcsvax!sdchema!donn 32 52' 30"N 117 14' 25"W (619) 452-4016 sdcsvax!sdchema!donn@noscvax
rees@apollo.UUCP (Jim Rees) (12/20/83)
I assume that Donn was joking when he said that byte order in NS16032 system is correct and that in a 68000 it is backwards. Neither order is inherently superior to the other, of course. What is important is that the order be consistent within a particular implementation, and I believe it is for both of these processors. Motorola does number their bits backwards from the way they order their bytes. I don't know the reason for this, but since they have no bit-field instructions it doesn't make a lot of difference.