mark@mips.COM (Mark G. Johnson) (04/27/88)
In article <367@m3.mfci.UUCP>, colwell@m3.UUCP (Robert Colwell) writes > ... maybe it [the Intel 432] addressed issues that were just > too far in the future, and still are. The basic goal of the > machine was to trade off basic performance for other things > that were felt to be more important at the time, like programmer > productivity ... I don't quite agree. When the chips were on 2nd-pass silicon in June 1980 they hadn't yet been Marketing-Renamed to "iAPX-432" (they were still known as the Intel 8801, 8802, & 8803) and within Intel, they were felt to provide high performance computing. No `trade off performance for other things' at all ... the 8800 (later 432) was supposed to be fast. Here are some of the reasons that were being circulated within Intel: 1. The 8802 Execution Unit was pipelined and contained a full IEEE standard Floating Point set of hardware. This was rare indeed in 1980, and feeding data to/from the FP was pretty well thought out. It was, for example, better than the 8087/8086 interface (which came _after_ the 8800 / 432). 2. The chipset supported multiprocessing. Intel envisioned hooking up tens of 8800-sets to achieve high speeds. The scheme closely resembled Unix `pipes' (e.g. cat foo | tbl | eqn | troff ) with each program running on a different processor. 3. The 8803 was a dedicated hardware I/O processor, which was supposed to unburden the CPU(s). Of course, one could argue that the 8800 / 432 didn't achieve the performance goals that were desired. "The market" did indeed vote with its dollars on this point. But Intel seems *not* to have thought that they were trading away performance. Many of the 8800 designers are net-readers; perhaps they would identify themselves :-) and comment further. Regards, -- -Mark Johnson *** DISCLAIMER: Any opinions above are personal. *** UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mark TEL: 408-991-0208 US mail: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
root@mfci.UUCP (SuperUser) (04/27/88)
In article <2085@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes: >In article <367@m3.mfci.UUCP>, colwell@m3.UUCP (Robert Colwell) writes > > ... maybe it [the Intel 432] addressed issues that were just > > too far in the future, and still are. The basic goal of the > > machine was to trade off basic performance for other things > > that were felt to be more important at the time, like programmer > > productivity ... > >I don't quite agree. When the chips were on 2nd-pass silicon in June 1980 >they hadn't yet been Marketing-Renamed to "iAPX-432" (they were still >known as the Intel 8801, 8802, & 8803) and within Intel, they were felt >to provide high performance computing. No `trade off performance for >other things' at all ... the 8800 (later 432) was supposed to be fast. >Here are some of the reasons that were being circulated within Intel: > -Mark Johnson *** DISCLAIMER: Any opinions above are personal. *** > UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mark TEL: 408-991-0208 > US mail: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 Yes, you're right, if you go by the marketing hype of the time. In fact, I cringe when I re-read some of that stuff (and I had nothing to do with the design of the 432). But if you talk to the designers, they thought they were trading away some uni-processor performance for a large-system gain. That is, they understood (and I have to admit that not all of them would even go this far, so Mark's comment does apply to some of them) that there would be some loss in uniprocessor throughput vs. an "unencumbered" micro (680?0) due to the object-based overhead but that same object-orientation would allow transparent multiprocessing which would buy it back (in the environment for which the chip was intended.) Of course, even that didn't quite work out -- each 432 CPU (a pair of chips) talked to main memory via a bus which was asynchronous (so that all the 432's in a system didn't have to have a common clock) and slow as hell; something like 6 wait-states on average, and that on a cpu with a 4 MHz clock rate. I'm not sure why the bus had to be so slow, but maybe it had to do with the fault-tolerance aspects -- remember that this architecture had a lot of hooks built in for that, too. When I did performance modelling for the 432 I tried it at 0, 3, 6, and 10 waitstates just to evaluate the impact; the impact of this slow bus alone was HUGE, since the machine was memory-to-memory. Anyway, not to excuse silly (or wrong) marketing hype, but anybody who introduces a new chip and doesn't say "hey, boy, are we fast or what?" is going to look kinda suspicious these days. If you're too put off by the blatant early performance hype you may miss some really interesting ideas that were embodied in this machine. You may not be able to USE those ideas anytime soon, but who knows, someday...? Bob Colwell mfci!colwell@uunet.uucp Multiflow Computer 175 N. Main St. Branford, CT 06405 203-488-6090
jack@cs.glasgow.ac.uk (Mr Jack Campin) (04/29/88)
Expires: Sender: Followup-To: Keywords: >In article <367@m3.mfci.UUCP>, colwell@m3.UUCP (Robert Colwell) writes > ... maybe it [the Intel 432] addressed issues that were just > too far in the future, and still are. The basic goal of the > machine was to trade off basic performance for other things > that were felt to be more important at the time, like programmer > productivity ... Maybe it wasn't all to do with performance. Someone on our project considered using it back then, and was put off solely by the $50,000 Intel wanted for an Ada compiler. There may have been a lot of small startup companies for whom that sort of money meant choosing a Motorola or NatSemi CPU instead. -- ARPA: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk USENET: jack@cs.glasgow.uucp JANET:jack@uk.ac.glasgow.cs useBANGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack Mail: Jack Campin, Computing Science Dept., Glasgow Univ., 17 Lilybank Gardens, Glasgow G12 8QQ, SCOTLAND work 041 339 8855 x 6045; home 041 556 1878