Path: utzoo!mnetor!uunet!yale!mfci!root From: root@mfci.UUCP (SuperUser) Newsgroups: comp.arch Subject: Re: Fast 432 (!?) Message-ID: <370@m3.mfci.UUCP> Date: 27 Apr 88 13:34:03 GMT References: <2085@obiwan.mips.COM> Reply-To: mfci!colwell@uunet.UUCP (Robert Colwell) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 55 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